내가 자동화하지 않을 두 번째 에이전트

몇 주 전, 저는 제가 잠든 동안 운영 환경을 감시하는 루프에 대해 글을 썼습니다. 이는 20분마다 로그, 예산, 게임 데이터베이스를 스크래핑하고 문제가 발생하면 Telegram으로 알림을 보내는 claude -p 하트비트(heartbeat)입니다. 저는 그 글을 다음과 같은 가벼운 문장으로 마무리했습니다: 일단 문제를 파악하고 나면, Claude Code가 보통 스스로 해결할 수 있다.

그 말은 사실입니다. 할 수 있습니다. 다만 제가 허락하지 않을 뿐입니다.

모니터링은 사실 하나가 아니라 두 개의 에이전트로 이루어져 있습니다. 첫 번째는 루프(loop)입니다. 이 루프의 역할은 분류(triage)입니다: 에러를 수집하고, 앱 상태를 확인하며, 각 에러의 심각도를 결정하고, 일시적인 오류 때문에 제가 잠에서 깨지 않도록 노이즈를 요약본(digest)으로 묶는 것입니다. 그것이 바로 Marlow이며, 완전히 자율적(autonomous)입니다.

두 번째 에이전트는 실제로 트러블슈팅(troubleshoot)을 수행하는 에이전트입니다. 로그를 사용자 데이터, 액션 트레이스(action traces), 소스 코드와 연결하여 근본 원인(root cause)을 찾아내고, 수정 사항을 작성하며, 게임이 플레이 도중 멈춘 경우 데이터베이스를 패치합니다. 그 에이전트는 저의 맞춤형 Claude Code인 Simona이며, 저는 매번 직접 수동으로 제어합니다.

그 이유는 다음과 같습니다.

평범해 보이는 나쁜 하루

어제 루프는 제 AI Werewolf 게임의 에러 로그를 감시하며 2시간 동안 세 개의 요약 항목을 보냈습니다:

17:21Z: 37개의 새로운 에러 라인, 모두 알려진 노이즈 클래스에 해당 - 24분 동안 발생하는 talkToAll에서 캐릭터 M의 액션 실패. 하나의 게임이 브로드캐스트 재시도(broadcast-retry) 루프에 빠졌으나, 앱 전체의 장애는 아님. 긴급(urgent)에서 요약(digest)으로 등급 하향.

17:51Z: 9개의 Game action failed: D 에러, 그리고 6개의 경고: Ignoring invalid/duplicate GM-selected bots: [DeepSeekFlash]. GM이 잘못된 봇 이름을 선택함. 장애 없음.

18:21Z: 50개의 새로운 에러 라인, 동일한 게임 액션 실패 계열 - 12분 동안 발생하는 캐릭터 T의 투표 액션 실패. 그리고 DeepSeekFlash 경고 5개 추가 발생.

이 상황은 무섭게 느껴졌습니다. 최근에 제가 DeepSeek 모델들을 위한 JSON 출력 설정을 잘못했다는 사실을 발견했습니다. 구조화된 출력 (Structured Output)을 위한 전용 API 기능을 사용하는 대신, 프롬프트 지시 사항 (Prompt Instruction)을 사용하고 있었습니다. 그렇게 확인하던 중, DeepSeek Flash Reasoning 설정에서 버그를 발견했습니다. 그런데도 모니터링 시스템은 정확히 이 모델을 다시 지목했습니다.

이것이 제가 자가 수정 (Self-fixing)을 원하지 않는 이유입니다. 저는 무슨 일이 일어나고 있는지 이해해야 합니다. 제 코딩 AI가 아무리 똑똑하더라도, 구조화된 출력에 개선 사항이 있는지 확인하기 위해 최신 DeepSeek API를 직접 체크하지는 않을 것입니다. 제가 요청하지 않는 한, 모든 모델에 대해 JSON 파싱 (JSON Parsing) 코드를 통일시키지도 않을 것입니다.

루프 (Loop)는 제 역할을 다했습니다. 게임 액션 실패 (Game-action-failures)를 알려진 노이즈 클래스로 인식했고, 앱 전체의 문제는 아니라는 것을 확인했으며, 저를 깨우지 않았습니다. 그것은 설계된 대로 작동하는 지루한 에스컬레이션 (Escalation) 로직입니다. 또한 봇 이름 경고 역시 별개의 무해한 일로 올바르게 표시했습니다. 게임 마스터가 엔진이 인식하지 못하는 봇 이름을 입력한 것이었습니다.

그러니까... 실제 문제는 JSON 파싱이 아니라, 플레이어 이름에 대한 모델의 부족한 추론 (Reasoning) 또는 환각 (Hallucination)이었습니다. 정확해야 할 부분에서 존재하지 않는 이름을 반환했고, 게임 로직은 올바르게 실패했습니다. 하지만 왜 그랬을까요? 저는 LLM에 보내는 마지막 메시지에 모든 플레이어 이름을 추가하여 명령에 주입 (Inject)합니다. 이 방식은 매우 잘 작동합니다. 모델들은 목록에서 정확한 이름을 선택하는 데 절대 실패하지 않으니까요. 그런데 도대체 무엇이 문제일까요?

루프 안의 나 (Me in the loop)

알고 보니, 저는 그 이름들을 주입하지 않았습니다. 분명히 했다고 확신했지만, 아니었습니다. 이 특정 요청에서는 주입되지 않았습니다. 이는 엄청난 실수입니다. 프롬프트 엔지니어링 (Prompt-engineering) 로직을 단위 테스트 (Unit tests)로 커버하는 것은 상당히 어렵기 때문에, 이 로직은 테스트되지 않았습니다. 게다가 '바이브 코딩 (Vibe-coding)' 덕분에 이 코드를 오랫동안 들여다보지 않았습니다. 예전에는 모든 코드를 직접 작성했지만, 약 6개월 전 Claude Opus 4.8이 버그를 만들기 시작하지 않으면서 저는 포기했습니다. 작동할 때는 너무나 편리하니까요.

결국 그것이 문제였습니다. 코드의 실제 버그였고, 매우 까다로운 것이었죠. 모델은 하루 전체의 대화 기록에서 플레이어 이름을 추출하기 위해 최선을 다했고, 이는 대부분 잘 작동했습니다. 하지만 이 접근 방식은 긴 대화에서 환각 (hallucinations) 현상을 겪게 됩니다. 제가 처음에 그런 명령어들을 고안했던 이유이기도 합니다.

자가 수정 루프 (self-fix loop)가 이것을 찾아낼 가능성은 없습니다. 그저 비효율적인 패치들을 계속 덧붙이기만 할 뿐, 진짜 원인은 결코 찾아내지 못할 것입니다. 저는 제가 디버깅 (debugging)에 참여하는 것이 중요하다고 생각합니다. 그래야 아키텍처 (architecture)를 계속 인지할 수 있기 때문입니다. 그리고 사실 그렇게 어렵지도 않습니다. 저는 이 문제에 10분을 썼고, Simona는 일련의 새로운 테스트와 함께 수정 사항을 배포했습니다.

자동화의 꿈

현재 많은 사람들이 루프 (loop)에서 엔지니어를 제외하려고 시도합니다. 만약 당신이 상사에게 문제를 탐지할 뿐만 아니라 자율적으로 즉시 수정하는 것도 가능하다라고 말한다면, 그것은 당신의 다음 우선순위 과제가 될 것입니다. 당신이 여전히 최종 코드 변경 사항을 검토하니 괜찮다고 생각할 수도 있습니다. 테스트로 커버되니 더 괜찮다고 느낄 수도 있죠. 하지만... 문제의 심층부로 들어가지 않으면, 저는 전체 시스템이 어떻게 작동하는지 잊어버리기 시작합니다. 논리에 대한 저의 이해가 현실과 동떨어지게 됩니다. 이것이 자동화를 너무 과하게 밀어붙였을 때 치러야 하는 대가입니다. AI에 대해 읽기만 하고 현장에서 직접 실습하지 않는 것에 대한 대가 말입니다.