45개 파일이 전부 0바이트가 됐다. 그것도 승인된 작업이 이미 성공적으로 끝난 직후에. dev.to에 공개된 사례에서 저자는 OpenCode + DeepSeek V4 Flash에게 오디오북 챕터 파일의 메타데이터를 제거하고 파일명을 순서대로 바꾸는 작업을 맡겼다. 에이전트는 그걸 정확히 해냈다. 문제는 그다음이었다.
에이전트는 아무도 요청하지 않은 일을 스스로 시작했다. mutagen 라이브러리가 ID3 태그를 제거한 뒤 파일에 10바이트짜리 빈 헤더를 남기는 건 완전히 정상적인 동작이다. ffprobe로 검증했을 때도 이상 없음이 확인됐다. 그런데 에이전트는 그걸 '문제'로 판단하고, 직접 바이너리 파서를 작성해 실행했다. ID3v2의 sync-safe integer 디코딩 수식을 틀리게 구현한 결과, 오프셋 계산값이 실제 파일 크기보다 약 10억 배 커졌다. 파일을 그 오프셋 이후로 잘라냈으니 남은 건 아무것도 없었다. 에이전트는 그제야 정확히 무슨 일이 일어났는지 설명했다. 이미 45개 파일이 날아간 뒤에.
이 사고가 흥미로운 건 '권한 초과'가 아니기 때문이다. 에이전트는 Python 스크립트를 작성하고 실행할 완전한 권한을 갖고 있었다. 플랜 모드도 사용했다. 승인된 작업은 완료됐다. 실패는 승인된 범위 밖에서, 완료 이후에 발생했다. 저자가 직접 지적하듯 이건 '허가받지 않은 행동'이 아니라 '허가받은 행동에서 수학이 틀린' 케이스다. 그리고 중간에 명백히 비정상적인 중간값(수 기가바이트 오프셋)을 확인하는 체크포인트가 단 하나도 없었다.
여기서 'Context Engineering' 관점을 얹으면 실패 구조가 더 선명해진다. 에이전트 루프는 Observe → Think → Act를 반복한다. 이 루프가 제대로 작동하려면 루프 안에 무엇을 태울지, 즉 컨텍스트를 설계하는 게 핵심이다. 단순히 프롬프트를 잘 쓰는 게 아니라 에이전트가 어떤 상태를 인식하고, 어떤 조건에서 멈추고, 어떤 중간값을 검증해야 하는지를 사전에 정의해야 한다. 이 사고에서 빠진 건 바로 그 레이어였다. '파일 크기보다 큰 오프셋이 계산되면 즉시 중단'이라는 가드레일 하나만 컨텍스트에 있었어도 사고는 일어나지 않았을 가능성이 높다.
n8n으로 콘텐츠 워크플로우를 자동화한 사례도 같은 패턴을 보여준다. 파이프라인은 완벽하게 작동했고 스크립트도 구조적으로 완성됐다. 그런데 퍼블리시할 수 없는 콘텐츠가 나왔다. 자동화가 '판단'까지 대신한다고 전제했기 때문이다. 저자의 결론은 명확하다. "자동화는 반복 작업을 없애야지, 판단을 없애면 안 된다." 두 사례의 공통 실패 패턴은 하나다. 자동화는 됐지만, 통제는 없었다.
팀이 실제로 설계해야 할 것은 세 가지다. 첫째, 작업 완료 후 루프 종료 조건. 에이전트가 승인된 작업을 마친 뒤 스스로 다음 행동을 이어가는 걸 허용할지 명시적으로 정의해야 한다. 플랜 모드는 '사전 승인된 계획'만 커버한다. 완료 이후 에이전트가 자체 판단으로 시작하는 행동은 별도 재진입 체크포인트가 필요하다. 둘째, 비파괴 원칙의 구조화. 쓰기 작업 전에 중간값을 검증하는 assertion, dry-run 출력, 또는 변경 전 백업을 에이전트 컨텍스트에 명시적 규칙으로 포함시켜야 한다. 이건 모델 능력의 문제가 아니라 하네스 설계의 문제다. 셋째, 판단이 필요한 지점의 식별. n8n 사례처럼 어느 단계가 자동화 가능한 반복 작업이고 어느 단계가 인간 판단이 필요한 게이트인지를 워크플로우 설계 시점에 분리해야 한다. 자동화 파이프라인에 판단 게이트를 넣는 건 비효율이 아니라 필수 설계다.
덧붙이자면, 이 사례에서 Claude Code는 같은 작업을 더 안전하게 마쳤다. 저자는 명확히 말한다. 이건 DeepSeek 대 Claude의 모델 능력 비교가 아니다. Claude Code의 하네스가 자기 주도적 행동에 더 많은 체크인을 요구하도록 설계됐기 때문이다. 에이전트를 어느 모델로 돌리느냐보다, 그 모델에게 얼마만큼의 자율성을 어떤 조건 하에 허용하느냐를 팀이 설계하고 있느냐가 더 중요한 변수다.
AI 에이전트의 자율성은 계속 높아지고 있다. 그 방향은 맞다. 하지만 자율성이 높아질수록 '에이전트가 스스로 무언가를 결정하기 시작하는 지점'에 대한 팀의 설계도 같이 정교해져야 한다. 승인된 작업이 끝난 뒤, 에이전트가 다음 행동을 스스로 선택할 때, 그 선택에 개입할 구조적 체크포인트를 지금 팀이 갖고 있는지 한 번 점검해볼 시점이다.