저는 OpenCode + DeepSeek V4 Flash에게 45개의 오디오북 챕터 파일에서 메타데이터를 제거하고 숫자로 이름을 변경해 달라고 요청했습니다. 모델은 이름 변경은 정확하게 수행했지만, 요청하지도 않았는데 무해한 잔여 바이트가 수정해야 할 문제라고 판단했습니다. 스스로 바이너리 파서 (binary parser)를 작성하더니 산술 계산을 약 9자릿수 정도 틀려버렸고, 결국 모든 파일을 0바이트로 만들어 버렸습니다. 결국 백업을 사용해야 했습니다. 타인의 IT 문제를 해결해 온 지 10년이 지났지만, 자동화 도구가 단순한 이름 변경 작업을 하려다 백업을 찾게 만든 것은 이번이 처음입니다.

이 글의 목차

• 실제 작업 내용
• 잘 수행된 부분
• 잘못된 부분
• 공식, 그리고 그것이 계산한 것
• 이것이 일반적인 "에이전트가 승인되지 않은 작업을 수행함"과 다른 실패인 이유
• 플랜 모드 (plan mode)가 이를 잡아낼 수 있었을까? 아니요, 바로 그게 핵심입니다
• 나를 구한 것
• 효과가 있었던 해결책은 다른 방식의 해결책이었다
• 교훈

실제 작업 내용

작고 기계적이며 범위가 명확한 작업이었습니다. 오디오북 플레이어가 45개의 파일로 구성된 책의 챕터 순서를 무시하는 문제가 있었습니다. 이전의 해결 시도(파일명 순서에 맞게 ID3 트랙 번호 태그를 다시 쓰는 것)로는 해결되지 않았기에, 다음 단계로 더 공격적인 방법을 택했습니다. 모든 태그를 완전히 제거하고, 모든 파일을 깨끗한 제로 패딩(zero-padded) 숫자(001.mp3, 002.mp3, ...)로 이름을 변경하여 충돌을 일으킬 수 있는 모든 정렬 정보의 소스를 한꺼번에 제거하는 것이었습니다.

제가 직접 파이썬 (Python) 스크립트를 실행하는 대신, 더 어려운 작업을 위해 Claude Code 구독을 아껴두고자 DeepSeek V4 Flash가 구동되는 OpenCode에 이 작업을 맡겼습니다. 실제 제거 작업은 mutagen(검증된 오디오 태깅 라이브러리)을 사용하는 파이썬 스크립트를 사용하도록 했습니다. 이는 빠르고 저렴한 모델 계층이 감독 없이도 처리해야 하는 전형적인 작업입니다.

잘 수행된 부분

잘 수행되었습니다. 스크립트가 실행되었고, mutagen이 ID3 태그를 깔끔하게 제거했으며, 파일들은 올바른 자연 정렬 (natural-sort) 순서로 이름이 변경되었고, 오디오 데이터 자체는 손상되지 않았습니다. ffprobe로 확인한 결과, 태그는 없고 순서는 정확하며 재생 가능한 파일들이었습니다. 작업 완료.

잘못된 부분

브리프(brief)에 없었던 부분은 다음과 같습니다. 대부분의 ID3 라이브러리와 마찬가지로 mutagen의 태그 삭제 기능은 파일 크기를 줄이지 않습니다. 이 라이브러리는 해당 바이트들을 물리적으로 잘라내는 대신, 10바이트의 빈 ID3v2 헤더(표준 매직 바이트(magic bytes)와 0으로 채워진 크기 필드)를 그대로 남겨둡니다. 이는 완전히 정상적인 동작입니다. ffprobe를 통해 이미 태그 프레임이 없음을 확인했습니다. 아무런 문제가 없었습니다.

에이전트는 원시 바이트(raw bytes)를 살펴보다가 ID3 매직 문자열이 여전히 존재하는 것을 보고, 오디오북 플레이어가 이를 보고 혼란을 느낄 수도 있다고 스스로 판단했습니다. 아무도 요청하지 않은 일이었습니다. 브리프의 내용은 "태그를 제거하고 이름을 변경하라"였지, "그 후 파일의 바이너리 구조(binary structure)를 수동으로 편집하라"가 아니었습니다. 그럼에도 불구하고 에이전트는 작업을 강행했고, 45개 파일 전체에서 ID3v2 헤더 바이트를 수동으로 찾아 제거하는 Python 스니펫(snippet)을 작성하여 실행했습니다.

공식, 그리고 그것이 계산한 것

ID3v2는 태그 크기를 싱크 세이프 정수(sync-safe integer) 방식으로 저장합니다. 4바이트를 사용하지만, 각 바이트의 하위 7비트만 사용합니다(상위 비트는 예약되어 있어, 크기 필드가 프레임 싱크 마커(frame sync marker)처럼 보이는 바이트 시퀀스를 실수로 포함하지 않도록 합니다). 이를 올바르게 디코딩(decoding)하려면 각 바이트를 독립적으로 시프트(shift)해야 합니다.

# 원래 의도되었어야 하는 방식:
size = (data[6] & 0x7F) << 21 | (data[7] & 0x7F) << 14 | (data[8] & 0x7F) << 7 | (data[9] & 0x7F)

실제로 작성된 코드:

# 실제로 작성된 방식:
size = 10
for j in range(6, 10):
...

언뜻 보기에는 충분히 비슷해 보일 수 있습니다. 하지만 그렇지 않습니다. 이 루프는 각 바이트를 고정된 비트 위치로 시프트하여 OR 연산을 수행하는 대신, 반복할 때마다 _누적된 전체 값_을 왼쪽으로 7비트씩 계속 시프트합니다. "전체를 다시 왼쪽으로 7비트 시프트"하는 과정을 네 번 반복하면 수치가 급격히 커집니다. 실제 헤더에 대한 올바른 계산 값(약 2.7 KB)이 약 2.6 GB로 계산되어 버린 것입니다.

스크립트는 이후 file_bytes = file_bytes[size:]와 동일한 작업을 수행하여, 계산된 오프셋 이후의 모든 내용을 디스크에 다시 썼습니다. 파일 자체보다 세 자릿수 더 큰 오프셋을 사용했기 때문에, '오프셋 이후의 모든 내용'은 아무것도 없었습니다. 결국 45개 파일 모두가 0바이트가 되었습니다.

심지어 제가 요청하지 않았는데도 스스로 오류를 감지하고 말했습니다: "죄송합니다. 바이너리 ID3 스트리핑 단계에서 치명적인 오류를 범했습니다. 동기화 안전 정수 파싱이 잘못되어 45개 파일 전체가 0으로 채워졌습니다." 이는 실제로 무엇이 잘못되었는지 정확하게 보고한 것입니다. 다만, 그 사실을 알기에 너무 늦게 도착했다는 점이 문제입니다.

이것이 일반적인 "에이전트가 무단으로 행동함"과는 다른 실패인 이유

저는 이전에 같은 도구로 더 작은 버전의 유사 사례를 경험한 적이 있습니다. OpenCode가 세션 로그아웃 시 요청하지 않은 '정리' 과정이라며 시작조차 하지 않은 SSH 터널을 종료시킨 것입니다. 그것은 범위(scope) 실패였습니다. 에이전트가 실제로 기능하는 무언가를 수행했지만, 아무도 요청한 것은 아니었습니다.

이번 경우는 범위 실패의 옷을 입고 있는 정확성(correctness) 실패입니다. (요청받지 않은 수동 바이너리 파서 작성이라는) 범위 위반이 기회를 만들었지만, 실제 피해는 완전한 확신과 자체 점검이 전혀 없는 상태에서 실행된 잘못된 산술 연산에서 비롯되었습니다. 아무것도 쓰기 전에 print(size)를 실행했다면, 몇 킬로바이트짜리 파일에 대해 수십억이라는 숫자가 표시되었을 것이고, 이 문제는 약 2초 만에 끝났을 것입니다. 하지만 그렇게 되지 않았습니다. 모델은 '문제를 식별했다'에서 '수정 사항을 작성했다'로 그리고 '수정 사항을 적용했다'까지 곧바로 넘어갔으며, 명백히 비상식적인 중간 값이 포착될 수 있는 체크포인트가 전혀 없었습니다.

이 지점이 바로 깊이 고민해 볼 만한 부분입니다. 더 엄격한 권한 설정(터널 사건의 해결책)이라 할지라도 이를 막지는 못했을 것입니다. 에이전트(Agent)는 이 프로젝트에서 Python을 작성하고 실행할 모든 권한을 가지고 있었습니다. 이번 실패는 "허용되지 않은 행동을 했다"가 아닙니다. "정확히 이 행동을 할 권한이 있었고, 수학적 계산을 틀렸으며, 결과를 확정하기 전에 스스로의 출력을 검토하도록 강제하는 장치가 아무것도 없었다"가 핵심입니다.

플랜 모드(Plan mode)가 이를 잡아낼 수 있었을까요? 아니요, 바로 그게 핵심입니다

저는 습관적으로 플랜 모드(Plan mode)를 사용합니다. 제안된 접근 방식을 검토하고, 승인한 다음, 실행하도록 하는 방식입니다. 이는 좋은 관행이며, 저도 이번에 이를 사용했습니다. 메타데이터를 제거하고 이름을 변경하는 계획(metadata-strip-and-rename plan)은 실행되기 전에 검토 및 승인되었습니다.

하지만 플랜 모드는 _당신이 승인한 계획_을 검토합니다. 이 이진(binary) "수정" 작업은 그 계획의 일부가 아니었습니다. 제가 무엇인가를 검토했을 당시에는 존재하지도 않았던 작업이었습니다. 그것은 승인된 작업이 이미 성공적으로 완료된 후, 모델이 실재하지도 않는 문제에 대해 스스로 촉발한 후속 조치로서 세션 중간에 만들어진 것이었습니다. 아직 제안되지 않은 행동에 대해서는 검토 체크포인트(review checkpoint)가 존재하지 않습니다.

따라서 아니요, 더 주의 깊게 검토한다고 해서 이를 잡아낼 수 있었을 것이라고 생각하지 않습니다. 편안한 결론은 아니지만, 해결책이 "다음에는 더 주의를 기울여라"인 것처럼 꾸미기보다는 차라리 솔직하게 말하겠습니다. 실제 격차는 구조적인 문제입니다. 세션은 승인된 계획을 완료한 후에도 계속 진행될 수 있으며, 모델이 스스로의 주도하에 다음에 무엇을 할지 결정할 때 다시 플랜 검토(plan-review) 단계로 진입하는 과정이 없습니다.

나를 구한 것

폴더에 다시 넣을 수 있는 책의 다른 복사본이 하나 더 있었습니다. 파일들이 다시 정상으로 돌아온 후, 저는 프로젝트를 Claude Code로 옮겼고 파일명 단축(filename shortening) 및 메타데이터 제거(metadata stripping)를 포함한 전체 파이프라인을 한 번에 다시 실행했습니다. 결과는 깔끔했습니다. 수동적인 바이트 수준(byte-level)의 우회 작업도, 예상치 못한 문제도 없었습니다. 이는 제가 실제 작업에서 두 도구를 모두 실행하며 확인한 내용과 일치합니다. 즉, 모델이 체크인(check in)하기 전에 수행할 수 있는 작업에 대한 가드레일(guardrails)인 Claude Code의 하네스(harness)가 OpenCode보다 단순히 더 엄격하다는 것입니다. 이는 모델로서의 DeepSeek와 Claude를 비교하는 것이 아닙니다. 이 파일들을 0바이트로 만든 것과 같은 자율적 행동이 실행될 기회를 갖기 전까지, 각 하네스가 얼마나 많은 자유(rope)를 허용하느냐에 대한 주장입니다.

효과가 있었던 해결책은 다른 해결책이었다

지나고 보니 이 모든 이진(binary) 우회 과정이 거의 무의미하게 느껴지게 만드는 부분이 여기 있습니다. Claude Code가 프로젝트를 처음 훑었을 때 OpenCode가 이미 시도했던 것과 동일한 아이디어, 즉 메타데이터를 제거하고 파일명을 정리하는 작업을 수행했습니다. 그것은 잘 작동했습니다. 하지만 그것이 챕터 순서 문제를 해결한 해결책은 아니었습니다. 문제를 해결한 것은 Claude가 실제 문제를 조사하여 저에게 m4b-tool을 안내하고, 그 후 merge 명령을 실행하여 45개의 챕터 파일을 하나의 연속된 .m4b 오디오북 파일로 합친 것이었습니다. 단 하나의 파일이 되었기에 어떤 플레이어도 순서를 재배치할 여지가 없었고, 첫 시도에 깔끔하게 작동했습니다.

교훈

저는 한동안 이 문제로 제자리를 맴돌았습니다. 왜냐하면 뻔한 답들이 통하지 않았기 때문입니다. "계획을 더 주의 깊게 검토하라"는 말은 효과가 없었습니다. 파괴적인 단계는 제가 검토한 어떤 계획에도 포함되어 있지 않았습니다. "더 똑똑한 모델을 사용하라"는 말은 확률을 줄일 수는 있겠지만 확률을 0으로 만들지는 못합니다. 어떤 모델이든 존재하지 않는 문제를 해결하기로 결정할 수 있고, 어떤 모델이든 산술 계산을 틀릴 수 있습니다. "권한을 제한하라"는 것은 다른 사건(에이전트가 자신이 시작하지도 않은 프로세스를 종료한 사건)에 대한 올바른 해결책이었지만, 여기에는 적용되지 않습니다. Python을 작성하고 실행하는 것은 이 작업에 정당하게 요구되는 사항이었습니다.

이야기를 다시 전달하는 과정에서 포함되어야 할 정직한 각주를 하나 더 덧붙이자면, ID3 관련 작업은 결국 아무런 의미가 없었습니다. 챕터 순서 문제는 태그나 바이트 오프셋 (byte offsets)과 관련된 것이 아니라, 파일들을 하나로 병합함으로써 해결되었습니다. 이 모든 바이너리 (binary) 우회 시도와 그로 인해 희생된 파일들은, 사실 처음부터 완전히 다른 해결책이 기다리고 있었던 문제에 봉사하느라 발생한 일이었습니다.

제가 내린 결론은 더 작고 덜 만족스럽지만, 가장 정직한 결론이라고 생각합니다: 에이전트 (agent)가 지시 사항(brief)을 벗어난 행동을 하기로 결정하는 순간을 내가 신뢰할 수 있게 예측하거나 포착할 수는 없다. 따라서 유일하고 지속 가능한 해결책은, 그 순간이 나에게 대체 불가능한 무언가를 앗아가지 못하도록 보장하는 것이다. 더 나은 경계심이 아니라, 더 나은 폭발 반경 (blast radius) 제어입니다.

구체적으로 말하면, "에이전트가 이 폴더에 쓰기 권한을 가지고 있다"는 것을 "나는 지금 당장 이 폴더의 모든 것을 잃어도 괜찮다"는 상태와 동일하게 취급해야 한다는 뜻입니다. 그리고 무언가 잘못된 후가 아니라, 작업이 시작되기 전에 다음과 같은 습관을 들여야 합니다:

• 다른 곳에 이미 백업되어 있지 않은 모든 작업에 대해서는, 원본이 아닌 일회용 복사본으로 작업할 것
• 작업이 얼마나 간단해 보이는지 또는 모델 (model)을 얼마나 신뢰하는지와 관계없이, 작업의 기계적인 첫 단계로서 스냅샷 (snapshot)을 찍거나 쓰기 전 복사 (copy-before-write)를 수행할 것
• "작은 이름 변경 작업"을 다른 어떤 작업보다 안전한 범주로 취급하지 말 것 — 이번 사건은 프로젝트 전체에서 가장 지루하고 위험도가 낮은 단일 작업으로 시작되었습니다.

저는 오디오북 챕터 순서 버그가 너무나 싫기 때문에 이 과정을 계속 자동화할 것입니다. 다만 다시는 유일한 복사본을 대상으로 지정하지 않을 뿐입니다. 이것이 실제 교훈입니다: 더 똑똑한 프롬프트 (prompt)도, 더 엄격한 검토 단계도 아닙니다. 그저 에이전트가 당신이 요청하지 않은 무언가를 발명할 수 있다고 가정하고, 기본적으로 그 상황에서도 생존할 수 있도록 만드는 것입니다.