구글 포토에서 원드라이브로: PowerShell 스크립트를 이용한 개인 사진 아카이브 재정비

구글 드라이브가 점점 파일로 채워져서 용량을 업그레이드하라는 경고를 자주 받게 되었다. 가장 많은 용량을 차지하는 것은 구글 '포토'이다. 마이크로소프트 오피스 365 구독을 통해 소유하고 있는 1TB의 공간에 이를 옮기기로 결정하고 실제 실행에 옮긴 기록을 남기고자 한다. 이 파이프라인의 핵심은 구글 테이크아웃과 Windows PowerShell 스크립트이다. ChatGPT의 도움으로 개발한 이 스크립트의 특징은 글 마지막 부분에 소개하였다.

구글 테이크아웃은 구글 서비스에 등록된 모든 자료를 2GB 단위의 zip 파일로 분할하여 다운로드 링크를 제공한다. 나의 경우에는 총 93개의 파일이 생성되었다. 이 파일의 이름(001, 002...)은 연도순으로 붙여지는 것이 아님에 유의하자.

Zip 파일을 모두 다운로드하여 PC에서 압축을 해제한 뒤 그냥 원드라이브에 밀어 넣으면 되는가? 안타깝게도 구글 포토와 같이 촬영일자에 따른 미디어 정리라든가 앨범 정보 같은 것이 그대로 따라가지는 않는다. 따라서 PC에서 zip 파일을 받은 뒤 내부에 포함된 JSON 파일을 이용하여 각 미디어 파일을 연도별 폴더로 나누어 넣는 일이 핵심이다. 이 과정에서는 PowerShell 스크립트인 takeout_batch_year.ps1가 매우 중요한 역할을 하였다(개인 리포지토리로 이용하는 DokuWiki에서는 업로드할 수 있는 파일의 확장자를 제한하고 있기 때문에 zip으로 압축하여 올렸음). 이 스크립트는 여러 차례에 걸쳐 수정하면서 기능을 개선하였고 안정적인 동작을 하는 것을 최종적으로 확인하였다.... 아, 나중에 발견하였지만 꽤 심각한 문제점이 있었다. 이 글의 끝부분을 참조하기 바란다.

스크립트 작성에서는 로컬 PC에 저장 공간이 별로 많이 남지 않았다는 것을 고려하여 작동하도록 많은 신경을 썼다. 내 노트북 컴퓨터에서는 여유 공간이 별로 없어서 180GB가 넘는 총 93개의 zip 파일을 한꺼번에 다운로드하여 작업하는 것이 근본적으로 불가능하였다. 컴퓨터에 남은 여유 저장 공간을 점검하면서 일정 개수의 zip 파일을 다운로드하여 처리한 뒤 원드라이브 업로드 후에는 지워서 공간을 확보하고, 다음 차례의 zip 파일을 처리하는 방식으로 진행하는 것이 기본 아이디어였다.

그러나 ChatGPT와 더불어 개발 작업을 계속하면서 스크립트의 성능이 점점 좋아졌다. -ZipDir로 지정한 디렉토리에 다운로드한 파일을 계속 밀어 넣으면 스크립트는 자동적으로 -BatchSize 단위로 처리를 한 뒤 작업이 끝난 zip 파일을 다른 위치(-DestRoot 하위의 _processed 폴더)로 옮긴다. 반복문을 돌릴 필요도 없으며, 다음 배치 작업 전에 자동적으로 저장공간이 얼마나 남아 있는지 확인하여 안전한 수준이 아니면(-MinFreeGB로 지정한 값보다 적은 경우) 자동으로 작업을 중단한다. 사용자는 작업이 끝나서 다른 위치로 옮겨진 zip 파일을 이따금씩 지우면 된다.

스크립트는 Downloads 폴더에 두고 여기에서 PowerShell 창을 열어서 다음과 같이 명령어를 실행하면 된다. 첫 줄 명령어는 지금 열려 있는 PowerShell에서 .ps1 스크립트를 실행하기 위해 정책을 변경하는 명령으로서 현재 열린 창에서만 유효하다. 반복된 테스트에 의하면 -BatchSize는 4~8 정도가 적당한 것 같다. 빠른 압축 해제를 위해서 반드시 7-Zip이 필요하다. 이 유틸리티를 설치한 뒤 실행파일인 7z.exe의 위치를 Path 환경변수에 지정해야 한다.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

.\takeout_batch_year.ps1 `
  -ZipDir "C:\Users\jeong\Downloads\Takeout_Zip" `
  -DestRoot "C:\Users\jeong\Downloads\Photos_Backup\From_Google_Takeout" `
  -BatchSize 4 `
  -MinFreeGB 25

takeout_batch_year.ps1은 모든 미디어 파일에 대한 해시를 생성하여 한번 처리한 파일은 다시 작업하지 않는다. 따라서 작업 결과로 만들어진 _hashes_sha256.txt를 절대로 지워서는 안 된다. 1년이 지난 뒤 다시 구글 포토로부터 테이크아웃을 할 때, 증분 백업 같은 것은 지원하지 않는다. 지워지지 않고 남은 파일에 대해서 언제나 전체 백업을 할 뿐이다. 따라서 이 해시 파일은 유일한 작업 기록인 셈이니 이것 역시 작업 종류 후에는 원드라이브에 보관하는 것을 권장한다. zip 파일을 가져다가 똑같은 스크립트를 돌리면 압축 해제는 어쩔 수 없이 다시 돌겠지만, 해시에 이미 기록된 파일은 추가 작업을 하지 않는다.

그러므로 이번 이전 작업이 성공적으로 끝난 뒤에는 구글 포토에는 최근 5년 정도의 파일만 남겨 두는 것이 좋을 것이다. 

한 배치에 대한 작업이 끝난 뒤 Photos_Backup/From_Google_Takeout 아래에는 다음과 같이 연도별로 정리된 폴더가 생기고 미디어 파일은 그 아래에 분류된다. JSON 파일의 분석에 실패하면 자동으로 가장 최근 연도인 2026 폴더로 들어간다. 

스크립트 실행 후 연도별 폴더에 미디어 파일이 자동으로 분류되어 들어간다. 해시 파일과 문제점이 있는 파일의 기록이 여기에 남는다.

너무나 당연한 이야기지만 -ZipDir이나 DestRoot에 원드라이브를 지정해서는 안 된다. 스크립트 작업이 다 끝나면 C:\Users\jeong\Downloads\Photos_Backup\From_Google_Takeout은 폴더 그대로 원드라이브의 '사진' 폴더 하위로 보내면 된다. 

원드라이브는 구글 포토와 같은 수준의 앨범 작성이나 편집 기능 같은 것은 없다. 휴대폰에서 직접 원드라이브로 사진을 백업하게 만들면 휴대폰에 남아 있는 최신 사진의 경우 구글 포토와 비슷하게 관리할 수는 있다. 이는 PC에서는 원드라이브 -> 사진 -> Camera Roll에서 접근 가능하다. 오늘 글에서 설명한 아카이브 재정비 작업과는 별개이다. 

PowerShell 기반 takeout_batch_years.ps1 사진 아카이브 자동화 파이프라인의 주요 특징

• Google Takeout ZIP을 배치 처리
  • ZipDir에 있는 *.zip 전체를 정렬해 순차 처리
  • -BatchSize(기본 4)개씩 묶어서 반복 실행(자동으로 다음 배치로 넘어감)
• 배치별 임시 작업 폴더로 “누적 스캔” 방지
  • ZipDir\_work\<batchId>\... 형태로 배치 전용 작업 폴더 생성
  • 스캔 대상은 해당 배치 폴더만(이전 실행 잔여물로 미디어 수가 튀는 문제 방지)
  • -KeepWork 옵션이 없으면 배치 종료 후 작업 폴더 자동 삭제
• 7-Zip 우선 사용 + 미설치 시 Expand-Archive 폴백
  • 7z.exe를 PATH에서 찾으면 7-Zip으로 빠르게 추출
  • 없으면 PowerShell Expand-Archive로 추출(상대적으로 느림)
• 미디어 확장자만 선별 스캔
  • JPG/JPEG/PNG/GIF/WEBP/HEIC, MP4/MOV 등(스크립트의 $MediaExt 목록 기준)
• 연도 폴더 분류 로직(우선순위 명확)
  • 1순위: Takeout JSON의 photoTakenTime.timestamp 또는 creationTime.timestamp
  • 2순위: (JPG/JPEG 한정) EXIF DateTimeOriginal(0x9003) → 없으면 DateTime(0x0132)
  • 3순위: 최후 수단으로 파일 LastWriteTime.Year 사용
• JSON 매칭 성능 최적화
  • 폴더 단위로 JSON을 한 번만 읽어 dir → (basename→year) 캐시($JsonYearCache) 생성
  • 같은 폴더 내 파일은 캐시로 빠르게 연도 조회
• 중복 제거의 핵심: 파일 내용 기반 SHA-256 해시
  • Get-FileHash SHA256로 파일 내용을 해싱
  • _hashes_sha256.txt에 누적 저장하여 다음 배치/다음 실행에서도 중복 스킵
  • 파일명/폴더가 달라도 내용이 같으면 중복으로 제거됨
• 해시 DB 기록 안정화(버퍼링 + 재시도)
  • 해시를 메모리 버퍼($HashBuffer)에 모았다가 배치 끝에 한 번에 기록
  • Add-Content 실패 시 슬립을 두고 재시도(AppendTextWithRetry)
• 파일 이동 실패에 대한 복구 로직
  • Move-Item 실패 시 재시도(MoveWithRetry)
  • 그래도 실패하면 Copy-Item 재시도 후 원본 삭제(가능한 경우)
• 동일 파일명 충돌 방지
  • 대상 경로에 같은 이름이 있으면 __1, __2…를 붙여 저장(덮어쓰기 방지)
• 문제 파일은 멈추지 않고 건너뛰며 기록
  • 해시 계산 실패/해시 null/이동·복사 실패 등의 경우 처리 중단 없이 스킵
  • _bad_files.txt에 유형과 경로(및 일부 오류 메시지) 기록
• 디스크 여유공간 가드
  • -MinFreeGB(기본 25GB) 미만이면 배치를 진행하지 않음(안전 정지)
  • 배치 크기가 큰 경우 8→6→4로 자동 축소 시도 로직 포함
• 처리 완료 ZIP 관리
  • 기본: 처리한 ZIP을 ZipDir\_processed로 이동(재처리 방지)
  • 옵션: -DeleteZips 지정 시 처리한 ZIP을 삭제(주의 필요)
• 운영 로그가 명확
  • 배치 시작/추출/스캔된 미디어 개수/누적 해시 수/여유공간/ZIP 이동(또는 삭제) 등 타임스탬프 로그 출력
  • -VerboseLog 켜면 중복 스킵 등 상세 로그도 출력

이 스크립트는 아직 개선할 점이 남아 있다. 중복을 제거한 미디어 파일에 대해서 원본의 JSON 파일도 같이 가져와야 하지만, 현재는 미디어 파일만 최종 결과물로 남기게 되어 있기 때문이다. 고난의 시작! 더 큰 문제는 JSON이나 EXIF 정보가 있는 원본 미디어 파일임에도 불구하고 촬영일 정보를 제대로 추출하지 못하여 2026 fallback으로 분류되는 것이 상당히 많았다는 점이다. 지금은 이에 대한 개선 작업을 진행하고 있다. 결과는 다음번 글에 쓰도록 하겠다.

2026년 2월의 일본 여행, 그리고 원드라이브로 사진 자료를 옮기기 위한 준비 작업(Google Takeout)

설 연휴를 맞이하여 아내, 그리고 아들과 함께 일본 3박4일(2/14-2/17) 동안의 일본을 여행하고 돌아왔다. 아들이 항공권과 호텔 및 방문 코스를 전적으로 마련한 이른바 '효도 관광'이었다. 우리 부부가 지불한 것은 대부분의 식비와 현지 교통비 정도였다. 들른 곳은 교토와 오사카. 항공편은 일본의 저가항공인 피치항공을 이용하였다. 주요 방문지는 다음과 같다.

• 1일차: 오사카 덴포잔 마켓플레이스, 가이유칸 수족관('해유관'), 우메다 공중정원(기누타니 고지 천공 미술관 포함), 교토로 이동하여 1박
• 2일차: 청수사(기요미즈데라), 교토 국립박물관, 오사카로 이동하여 2박
• 3일차: 유니버셜 스튜디오 재팬
• 4일차: 오사카성, 카이요도 피규어 박물관, 오사카 역에서 호라이551 만두를 사는 것으로 끝

돌아온 뒤에 가족들과 구글 포토로 사진을 공유하는 것이 힘겨워서 원드라이브를 적극 활용하기로 하였다. 나는 겨우 200GB 용량의 구글 드라이브를 쓰고 있었고, 이미 기존 파일이 187GB나 차지하고 있었기 때문에 용량이 거의 다 되어간다는 경고성 메시지를 계속 받는 중이었다. 요금제를 더 올려도 되지만, 기왕 쓰고 있던 마이크로소프트 원드라이브(1TB)를 앞으로 적극 활용하기로 결심하고 휴대폰의 사진 백업을 구글 포토에서 원드라이브로 바꾸었다. 구글 포토의 자료는 구글 테이크아웃에서 2GB 크기의 다운로드 링크 형태로 최신 내보내기를 요청하였다. 어젯밤 9시에 시작한 백업은 오후 2시 반이 조금 못된 지금 93개의 패키지, 총 용량 187.13GB로 다운로드 가능한 형태로 준비가 다 되었다. 다운로드 링크가 유지되는 시간은 약 일주일.

구글 포토를 당장 버릴 생각은 없다. 사진을 편집하려면 웹브라우저나 모바일 환경 모두에서 구글 포토가 원드라이보다는 더 익숙하기 때문이다. 대신 많은 양의 사진을 공유하려면 하나씩 눌러서 모은 뒤 구글 포토로 공유하지 말고 일 기반으로 임시 앨범을 만들어서 그 링크를 공유하는 방식으로 바꾸기로 하였다. 구글 포토에서 직접 사진이나 동영상을 하나씩 골라 모은 뒤 직접 공유하면 한번에 100개 정도가 한계이다.

휴대폰 사진을 원드라이브로 백업한다는 것은 현재 휴대폰에 저장된 사진에만 해당한다. 따라서 휴대폰을 새로 구입한 시점 이후의 사진만 백업이 될 것이다. 구글 테이크아웃은 구글 계정에 보관된 내 모든 서비스의 데이터를 골라서 파일로 묶는 것이다. 이를 위해서는 폴더를 풀어서 하나씩 원드라이브에 수작업으로 밀어 넣어야 한다. 아래에서 소개하겠지만 압축을 푼 그대로 밀어 넣어서는 대단히 곤란하다!

휴대폰 사진의 백업이 끝난 뒤 원드라이브 앱을 열어보았다. 그런데 예상과 다르게 2004년에 찍은 사진도 들어 있었다. 아마 집PC에서 당시에 찍은 디지털 카메라의 사진을 정리하다가 자동으로 원드라이브에 업로드된 것으로 보인다. 마이크로소프트 오피스를 구독형으로 이용하면서도 저장 공간에 대해서는 그다지 신경을 쓰지 않았기에 이러한 사실을 잘 모르고 있었다.

구글 테이크아웃으로 받은 첫 번째 파일의 압축을 해제해 보았다. 총 2,747개의 파일이 들어 있었다. 폴더의 구조는 다음과 같았다.

C:\Users\정해영\Downloads\takeout-2026....001\Takeout\Google 포토

1번 파일이니 가장 오래전에 찍은 사진이 들어 있으리라 생각했는데, 앨범(폴더)만 정리되어 있었다. 그러면 가장 마지막 것인 93번째 패키지에 옛날 사진이 들어 있으리라. 가장 마지막 것이라서 파일 크기는 2GB가 아닌 1.45G였다.

그러나 마지막 번호의 ZIP파일에도 하위의 '앨범' 폴더 없이 노출된 사진은 하나도 없었다. 더욱 이해하기 어려운 것은 '2025년의 사진'에는 겨우 9개의 사진과 3개의 json 파일이 들어 있다는 점이었다. 2025년에 사진을 9장만 찍었을 리가 없는데? 챗GPT에 물어보니 앨범에 넣지 않은 사진만 Photos from 20XX 폴더로 들어간다고 하였다. 하지만 나는 그렇게 앨범을 적극적으로 만들지 않았었다. 그러면 사진이 어디로 갔는가? 사라진 것은 아니다. 백업본의 용량은 구글 드라이브의 용량과 거의 같기 때문이다. 차이가 있다면 메일이나 기타 문서일 것이다. 

수동으로 앨범을 만들지 않았더라도 구글 포토에는 숨겨진 앨범 생성 메커니즘이 있다고 한다. 예를 들어 한 번이라도 공유한 적이 있는 묶음이라면 구글 포토 내부에서는 앨범 객체로 관리한다는 것. 그리고 아카이브의 번호(001~093)은 사진 생성일과는 관계가 없다.

구글 Takeout은 조금이라도 그룹 정보가 있으면 앨범으로 보낸다(과잉 분류 성향).

따라서 이렇게 마련한 백업파일을 PC에서 풀어서 그대로 원드라이브에 올리면 사진 중복의 대혼란 파티가 열릴 수 있다. 구글 포토는 편집용으로 유지하되 사진의 장기 보존용으로만 원드라이브를 쓰겠다는 전략은 매우 합리적이며, 아주 조심스럽게 원드라이브로 옮기는 작업을 해야 한다. 챗GPT가 제안한 체크리스트는 다음과 같다. 여기에서 2~6에 해당하는 작업을 자동으로 해 주는 Windows PowerShell 스트립트를 만들고 테스트하느라 몇 시간을 소비하였다. 생각보다 수고가 많이 들어가는 작업이라서 별도의 글로 포스팅하였다(구글 포토에서 원드라이브로: PowerShell 스크립트를 이용한 개인 사진 아카이브 재정비).

OneDrive 사진 이전 체크리스트

1. Takeout ZIP 전체 다운로드 완료
2. 모든 ZIP 동일 폴더에 압축 해제
3. 사진/영상 파일만 별도 폴더 추출
4. 중복 파일 제거 실행
5. 촬영일 기준 연도 폴더 정리
6. OneDrive 폴더 구조 사전 생성
7. 연도별 순차 업로드
8. 웹에서 동기화 완료 확인
9. 휴대폰 Camera Roll과 분리 유지 

일본 여행 사진 중 몇 장을 소개하면서 글을 마무리하고자 한다.

돌아오는 날, 오사카역(우메다 지역)에서 간사이 공항으로 출발하는 하루카 특급열차를 타기 위해 21번 플랫폼을 찾는 여정은 너무나 험난하였다. 한국어 자격증이 있는 직원(청소원으로 보였음)이 가는 길을 친철히 설명하면서 길 초입에 같이 뛰어 주지 않았다면 아마 제 시간에 기차를 타지 못했을 것이다.  

시간이 별로 없습니다. 조또(ちょっと) 설명 드리겠습니다...

생명과학 분야의 AI-ready 데이터란 무엇인가?

들어가며

최근 생명과학과 인공지능(AI)의 결합은 더 이상 낯선 이야기가 아니다. 유전체 분석, 신약 개발, 단백질 구조 예측, 임상 데이터 분석 등 다양한 영역에서 AI는 이미 핵심 도구로 자리 잡고 있다. 그러나 한 가지 질문이 남는다.

“우리의 데이터는 과연 AI를 바로 학습시킬 수 있는 상태인가?”

이 질문에 답하기 위해 등장한 개념이 바로 AI-ready data이다.

---

AI-Ready Data의 의미

생명과학 분야에서 AI-ready data란 단순히 디지털 파일이 존재한다는 뜻이 아니다. AI 모델이 별도의 대규모 수작업 전처리 없이 즉시 학습과 추론에 활용할 수 있도록 구조화·정제·표준화·법적 정합성을 갖춘 데이터 상태를 의미한다.

즉, “데이터가 있다”는 것과 “AI가 쓸 수 있다”는 것은 전혀 다른 문제이다.

---

AI-Ready 데이터의 핵심 조건

• 기계가 읽을 수 있는 구조 (PDF 보고서가 아닌 구조화된 포맷)
• 표준화된 형식 (FASTQ, VCF, FHIR 등 국제 표준 기반)
• 용어·단위의 정렬(harmonization)
• 결측치 및 오류 정제
• 지도학습이 가능한 레이블 존재
• 법·윤리적 이용 근거 확보

이 중 어느 하나라도 빠지면, 데이터는 존재하더라도 AI-ready 상태라고 보기 어렵다.

---

분야별 예시

1. 유전체 데이터

유전체 분야에서는 다음과 같은 조건이 충족되어야 한다.

• 품질 검증(QC)이 완료된 FASTQ
• 정렬이 끝난 BAM 파일
• 동일 reference build 기준의 VCF
• 정형화된 phenotype 메타데이터
• IRB 또는 동의 기반의 합법적 이용 근거

reference genome이 섞여 있거나, 표현형 정보가 서술형 텍스트로만 존재한다면 AI 학습용 데이터로 사용하기 어렵다.

2. 신약 개발 및 단백질 구조 데이터

단백질 구조 파일의 형식이 일관되지 않거나, binding affinity 단위가 뒤섞여 있다면 AI 모델은 제대로 학습하기 어렵다. SMILES 표현의 표준화와 타깃 명칭의 정렬 또한 필수적이다.

3. 임상 및 바이오메디컬 데이터

• ICD, SNOMED 코드화
• 단위 통일
• FHIR 기반 구조화
• 비식별화 처리
• 시간 정보(timestamp) 정규화

임상 데이터는 특히 법적·윤리적 요건을 충족하지 않으면 AI-ready가 될 수 없다.

---

FAIR와 AI-Ready의 차이

FAIR 원칙(Findable, Accessible, Interoperable, Reusable)은 데이터 공유를 위한 기준이다. 반면 AI-ready는 한 걸음 더 나아가 “기계 학습이 가능한 상태”를 요구한다.

수치 일관성, feature 생성 가능성, 레이블 품질, 데이터 편향 관리까지 포함하는 개념이 AI-ready라고 할 수 있다.

---

데이터 성숙도 관점

단계	설명
Level 0	원자료(raw)
Level 1	정제 완료
Level 2	표준화
Level 3	메타데이터 완비
Level 4	ML 학습 즉시 가능
Level 5	대규모 foundation model 학습 가능

많은 국가 인프라는 Level 2~3에 머무르는 경우가 많다. 그러나 산업과 AI 모델은 Level 4~5를 요구한다. 이 간극이 현재 바이오 데이터 전략의 핵심 병목이다. 여기에서 제시한 6개 단계는 특정 표준 규격이 아니라 설명 목적으로 제시한 것이다.

---

맺음말

AI-ready data는 단순한 기술 용어가 아니다. 이는 데이터 표준, 품질 관리, 법적 정합성, 국가 전략, 그리고 미래 산업 경쟁력과 직결된 개념이다.

이제 질문은 하나로 정리된다.

“우리는 데이터를 저장하고 있는가, 아니면 AI를 준비시키고 있는가?”

AI-ready data의 단순한 현황 집계(따라서 많은 행정력을 낭비하게 되는)를 비판적으로 바라본 별도의 글('The Illusion of Measuring AI-Ready Data, AI 데이터는 숫자로 세어지는가')로 작성해 두었다. 데이터를 AI-ready 형태로 만드는 일, 심지어 데이터가 AI 활용 가능한 상태인지 판별하는 일 자체도 연구의 영역일 수 있다. 

---

이 글은 정해영의 아이디어를 바탕으로 AI(ChatGPT)의 도움을 받아 작성되었습니다. CC0 1.0으로 자유 이용 가능하며, 정확성 및 법적 책임은 보장하지 않습니다. This text was written with AI (ChatGPT) assistance based on the author’s ideas. Released under CC0 1.0. No guarantee of accuracy is provided, and no liability is assumed.

LUCY의 '아니 근데 진짜' 그럼 커버 연주 및 원곡과 비교하기

실제 드럼셋 앞에 앉아서 내가 이 '보이 밴드'의 곡 드럼 파트를 연주하는 영상을 기대하셨다면 여러분은 약간의 과대 광고에 낚인 셈이다. 그러나 이 글의 제목이 100% 거짓은 아니다! 나는 분명히 컴퓨터 앞에 앉아서 자작 드럼패턴 입력/편집/재생기(APS, Ardule Pattern Studio)를 사용하여 스텝 단위로 드럼 연주 데이터를 입력하여 넣었기 때문이다. 이를 『아니 근데 진짜』원곡의 뮤직 비디오와 비교한 영상을 만들어서 유튜브에 올렸다. 

녹음 및 영상 편집 작업을 자주 하는 편이 아니기 때문에 관련 프로그램을 쓰는데 아주 능숙하지는 못하다. OBS Studio의 설정이 살짝 틀어져 있어서 컴퓨터 화면을 완전히 꽉 채우지 못하던 문제를 이번 작업을 하면서 바로잡았다. 아래에 소개한 영상을 만들면서 나름대로 최선을 다했지만 LUCY의 유튜브 원본과 APS 화면은 오디오와 잘 일치하지 않는다. 두 종류의 오디오를 먼저 녹음한 뒤 아래 절반의 화면에서는 원본 뮤직비디오와 APS를 시연 목적으로만 보이기 위해 자체 소리는 죽이고 재생한 것이기 때문이다.

유튜브 영상과 APS를 완벽하게 싱크로나이즈하는 것은 근본적으로 불가능하다. 따라서 두 가지의 오디오 클립을 Audacity에서 위 아래로 배열한 뒤 유튜브의 것은 그대로 두고 APS 오디오 클립의 길이를 조정하였다. 이론적으로 BPM을 동일하게 맞추었다 해도 DAW를 쓰는 환경이 아니라서 마스터 클럭에 완벽하게 맞출 수는 없다. Audacity 3.7.7 기준으로 실제 작업한 방법은 이러하다. 두 오디오 클립을 펼쳐 놓은 뒤 조정할 클립을 선택한 다음 Efffect -> Pitch and Tempo > Change Tempo... 대화상자로 들어가면 전체 길이를 최소 10밀리초 단위로 늘이거나 줄일 수 있다. 만약 시작과 끝 부분에 슬레이트를 치듯이 오디오 '스파이크'를 만들어 놓는다면 더욱 쉽게 싱크로나이제이션이 가능할 것이다. 

Audacity에서 오디오 클립의 템포 조정. 어차피 드럼 녹음만 처리하는 것이라서 피치가 바뀌는 것에 신경을 쓸 필요가 없다.

녹음은 Audacity에서, 화면 녹화는 OBS Studio에서, 그리고 최종 편집은 OpenShot Video Editor에서... 전부 무료 프로그램이라서 기능에 분명히 한계가 있지만 취미 수준으로는 충분하다.

밴드에서 같이 활동하는 젊은 멤버들 덕분에 이런 젊은 취향의 곡에 흥미를 느끼고 연습을 하게 되었다. LUCY의『조깅』도 마음에 드는 곡이다. 50대 중반인(아직 중반이라고 주장하고 싶은) 내가 만약 방구석에서 계속 혼자만의 취미 음악활동에 몰두하였다면 이런 새로운 세계를 접하지 못했을 것이다. 젊은 멤버들에게 감사를!

원래 기타나 건반을 더 오래 다루었지만 내가 현실적으로 밴드에서 맡은 포지션은 베이스. LUCY 곡의 베이스는 초보자인 내가 커버하기에 쉽지 않다. 음율의『파도혁명』도 마찬가지였다. 이런 곡들은 오리지널 음원을 감상하기에는 좋지만 밴드가 현장에서 그 분위기를 살려서 연주하기는 쉽지 않다. 이런 어려움을 덜어주는 좋은 동반자는 바로 플레이댓케이팝이 제공하는 밴드용 편곡과 동영상이다. 드럼+기타+베이스+건반 단 4개의 악기만 가지고도 『아니 근데 진짜』연주가 가능하니까 말이다.

APS의 다음 단계 개발은 AKAI MPK MINI MKII 키보드를 실시간 드럼 패턴 입력기로 쓰도록 개량하는 일이다. 기본 설계는 마친 상태인데 아직 코드 패치는 적용하지 않았다. 좀 있으면 옷을 갈아입고 밤 달리기를 하러 나가야 하기 때문.

ChatGPT 자동 생성 이미지.

생각보다 방대해진 Ardule Drum Patternology 생태계(GitHub)를 정리하는 쉬운 문서와 그림 자료를 계속 만들어 가가야 되겠다.

APS StepSeq 기능의 사소한 수정

Ardule Pattern Studio의 StepSeq에 몇 가지 편집 기능을 추가하다 

곡 전체에 해당하는 드럼 패턴 데이터를 자작 프로그램의 스텝 시퀀서 기능으로 찍어 보고 나서 개선 아이디어가 몇 가지 떠올랐다. 마디(bar) 단위로 데이터를 전부 지우거나, row(악기) 또는 column(스텝, 즉 시간) 단위로 한꺼번에 지우는 기능이 있으면 정말 편리할 것 같았다.

• Shift + B(bar): 마디 전체 데이터 삭제
• Shift + R(row): 악기 전체 데이터 삭제
• Shift + C(column): 스텝 전체 데이터 삭제

모든 삭제 동작은 편집창에 띄운 해당 마디에서만 이루어진다.

Undo 기능은 별로 중요하지 않다. 저장하지 않고 상위 메뉴로 나갔다가 다시 'S'키를 눌러서 StepSeq 기능으로 들어오면 되니까 말이다. 

이런 소소한 편집 기능을 직접 만들고 있는 나 자신을 돌아보았다. 명령만 내리면 인공지능이 완벽한 수준의 음악을 만들어 주는 시대에 드럼 패턴 입용 스텝 시퀀서를 직접 코딩하고 있다니! 

드럼 악보 표기의 수수께끼

나는 드럼을 칠 줄 모르지만, 데이터를 직접 다루면서 드럼이라는 악기의 매력에 한층 더 다가간 것 같다. 정말 흥미로운 사실이지만 드럼 악보를 표기하는 방법은 아직도 완벽하게 통일되지 않았다고 한다. 인터넷을 검색하면 다음과 같이 드럼세트와 오선악보를 매칭시켜 놓은 그림이 자주 보인다. 누가 고안했는지 아주 이해하기 쉽다.

그림 출처: drumeo "How to read drum music (for beginners)"

심벌 계열의 악기는 특히 오선악보 표기법이 통일되어 있지 못하다. 국내외의 표기 관행이 다른 것도 문제이다. 예를 들어 내가 구한 드럼테라스의 <아니 근데 진짜> 드럼 악보(링크)를 보면 공부할 거리가 잔뜩 나온다. 이 악보 전체에서 라이드 심벌을 치라는 지시는 없었던 것 같다.

드럼 악보 표기의 수수께끼.

애초에 드럼이라는 악기의 연주 정보를 오선보로 표기하려는 시도 자체가 불가능한 것인지도 모른다. 라이드 심벌만 하더라도 컵과 엣지를 칠 때 매우 다른 소리가 나지 않는가? 이러한 상세한 지시사항은 음표가 아니라 글로 적어 놓아야 할 것이다. 디지털의 세계에서는 있을 수 없는 일이다. 기록과 재생에서 차이가 있을 수 없기 때문이다. 하지만 아날로그의 세계에서 기록이나 표준화는 그야말로 '최소한'일 뿐이다. 나머지를 이루는 대부분은 연주자의 재량에 맡겨질 뿐이며, 녹음된 음원도 일종의 레퍼런스인 셈이다.

어쩌면 내가 드럼 악보를 보면서 갖는 의문은 MIDI 프로그래밍 초급 교실에서 한번씩 다 훑고 지나가는 매우 기본적인 사항인지도 모른다. 그렇다 하더라도, 실제로 곡 전체의 리듬을 데이터로 다루고 직접 구현해 보지 않았다면 이런 질문에 도달하는 일은 없었을 것이다. 하드웨어-소프트웨어(펌웨어 포함)을 거쳐 오히려 드럼이라는 악기 연주의 본질에 더 가까이 다가갔다고나 할까.

APS로 만든 드럼 데이터 시험 연주

400개가 넘는 드럼 패턴 데이터(?)를 집대성하였으나 최신 기성곡에 딱 맞는 패턴을 골라서 쓰는 일은 쉽지 않다. Ardule Drum Patternology 생태계의 좋은 점은 드럼 패턴을 스텝 시퀀서에서 직접 입력할 수 있다는 것. 우리 밴드의 보컬리스트가 꼭 부르고 싶어 하는 LUCY의 <아니 근데 진짜>의 드럼 연주를 Ardule에서 생태계에서 구현해 보기로 하였다.

드럼 악보는 드럼테라스에서 사용에 제한 없이 제공하는 것(PDF 링크)을 입수하여 사용하였다. 드럼 악보 표기법을 잘 알지는 못하는 상태라서 약간의 어려움이 있었다. 특히 이 악보 체계에서는 크래시와 라이드 심벌을 때리는 방법을 구별하기가 어려웠다.

결국 보유한 패턴은 하나도 쓰지 못했고, 전부 새로 입력하였다. 하이햇의 닫힌 정도를 달리 하면서 타격하는 뉘앙스 차이를 완벽하게 반영하지는 못한다. 타격의 세기(velocity)도 0-약-중-강의 4단계가 전부이지만, 없는 것보다는 낫다. 총 35개의 패턴(2 마디 단위)를 입력하였다. 데이터를 입력하면서 APS 파이썬 스크립트에 남아 있던 약간의 버그를 수정하는 예기치 못한 좋은 일도 있었다.

섹션 정보를 넣을 수 있어서 곡 단위의 데이터 입력 및 편집이 쉽다. 이 곡에 사용한 패턴의 접두어는 'AGJ'이다. 아니 근데 진짜의 머릿글자를 대충 따서 사용하였다.

템포는 142 BPM으로 상당히 빠르며 결코 쉬운 곡은 아닌 것 같다. 나는 드럼 연주자가 아니므로 그 어려움을 어떻게 이해하겠는가. 유튜브에서 원곡의 영상과 함께 템포를 맞추어 재생하면서 촬영을 해 보았다. 키보드 조작으로 재생을 하였으니 두 사운드가 서로 완벽하게 싱크가 맞을 수는 없다. 유튜브 쇼츠로도 올렸지만 자막이 너무 커서 화면을 많이 가린다.

올해에는 드러머가 참여하기 어려운 공연에서 이 시스템이 쓰일 수 있을 것이라고 믿는다. 여기까지 온 것도 정말 큰 성취가 아닐 수 없다.