내 런북(runbook)에는 Enter 키가 작동한다는 메모가 하나 있다. 그게 메모의 거의 전부다. Enter를 누르면 프롬프트가 전송된다. 나는 이 내용을 굵은 글씨로, 출처와 날짜를 포함하여 작성했다. 왜냐하면 한때 나의 AI 에이전트 중 하나가 Enter 키를 고쳐놓았기 때문이다. 그 수정 사항이 바로 버그였다.

수정 사항이 곧 버그였다

나는 tmux 창(pane)에서 Claude Code 에이전트 군단을 실행한다. 오케스트레이터(orchestrator) 스크립트가 창에 프롬프트를 입력하고 Enter를 대신 눌러준다. 어느 날 한 에이전트가 제출이 제대로 되지 않는다고 판단했고, 해결 방법을 알아냈다. 바로 Enter 앞에 백슬래시()를 보내는 것이었다. 터미널과 싸워본 적이 있다면 그럴듯하게 들릴 것이다. 하지만 그것은 정확히 정반대였다. Claude Code에서 백슬래시와 Enter의 조합은 줄바꿈(newline)을 삽입한다. 그것은 멀티라인(multiline) 키다. 그래서 그 수정 사항은 모든 프롬프트를 조용히 길어지기만 하고 절대 전송되지 않는 초안으로 만들어 버렸다. 창들은 바빠 보였지만, 아무 일도 일어나지 않았다.

제출은 내내 정상이었다. 에이전트가 단지 응답을 기다리지 않았을 뿐이다.

무엇이 고장 났는가: 에이전트가 프롬프트 제출을 수리하기 위해 Enter를 백슬래시-Enter로 변경했다. 백슬래시-Enter는 줄바꿈을 생성하므로, 이 수리는 모든 프롬프트가 전송되는 것을 조용히 막아버렸다. 에이전트가 고친 시스템은 애초에 고장 난 적이 없었다.

같은 종류의 두 번째 메모가 있다. 나의 모니터링 대시보드는 상태 확인(health check)에 대해 로그인 페이지로의 302 리다이렉트(redirect)로 응답한다. 그곳에서는 그것이 정상(healthy) 상태를 의미한다. 하지만 장애를 추적하는 입장에서는 302가 문제처럼 보일 수 있고, 에이전트들은 이를 계속 수리하려고 시도했다. 그래서 이제 런북에는 대략 다음과 같이 적혀 있다: 리다이렉트는 정상이며, 건강한 시스템을 고치지 마시오.

인간 팀은 이런 메모를 쓰지 않는다. 아무도 사무실 벽에 "Enter 키가 작동함"이라고 붙여놓지 않는다.

매 세션마다 새로운 신입 사원

왜 그래야만 했을까요? 인간은 막다른 길에 부딪히는 일이 단 한 번뿐이기 때문입니다. 움찔하는 그 순간이 바로 문서화가 됩니다. Enter 키를 고치려다 빌드(build)를 망가뜨린 사람은 몇 년 동안 그 일을 기억할 것이고, 점심시간에 그 이야기를 들려줄 것이며, 팀 전체는 단 한 마디도 쓰지 않고도 그 내용을 흡수할 것입니다. 에이전트(agent)에게는 그런 것이 전혀 없습니다. 에이전트에게는 에피소드 기억(episodic memory)이 없습니다. 매번 새로 열리는 컨텍스트 윈도우(context window)는 똑똑하고 빠르며, 당신의 시스템을 처음 접하는 신입 사원과 같습니다.

그리고 똑똑한 신입 사원의 문제는 그들이 영리한 해결책을 놓치는 것이 아닙니다. 오히려 그 해결책을 찾아낸다는 점이 문제입니다. 백슬래시-Enter(backslash-Enter)를 만들어낸 추론은 국소적으로는 타당했습니다. 새로운 세션에 동일한 증거를 제공하면, 에이전트는 동일한 해결책을 다시 도출할 것입니다. 가끔이 아니라, 매번 말입니다. 오답은 안정적입니다. 오직 그것을 반박했던 기억만이 취약할 뿐입니다.

핵심 통찰: AI 인력에게는 반박된 가설들을 기록해 두어야 합니다. 왜냐하면 매번 새로운 컨텍스트는 동일한 영리한 오답을 다시 도출할 신입 사원이기 때문입니다.

인간에게 문서(docs)는 무엇이 사실인지를 적는 곳입니다. 에이전트에게 문서란, 사실처럼 보였으나 사실이 아니었던 것들을 묻어두는 곳이기도 합니다.

다른 건물에 있는 똑같은 메모

저는 여러 산업 분야에서 시스템을 운영하고 있는데, 모든 분야에서 똑같은 메모가 계속 나타납니다. 제가 운영하는 의료 시스템 중 하나는 청구 작업을 위해 보험 거절 건을 평가합니다. 한동안 이 시스템에는 '출하 게이트(ship gate)'가 있었습니다. 즉, 튜닝된 모델이 무언가를 내보내기 전에 반드시 기존의 참조 에이전트(reference agent)와 일치해야 했습니다. 겉보기에는 합리적이었습니다. 그러다 우리는 불일치 사례들을 골든 답변(golden answers)과 비교하여 점수를 매겼습니다. 두 에이전트의 의견이 갈린 호출(calls)에서, 튜닝된 시스템은 약 78%의 확률로 골든 답변과 일치했습니다. 반면 참조 에이전트는 약 38%만 일치했습니다. 게이트가 품질을 더 약한 평가자에게 고정(anchoring)시키고 있었던 것입니다. 결코 통과할 수 없는 구조였습니다.

우리는 그것을 폐기했습니다. 하지만 폐기한 것은 작은 조치였습니다. 진짜 조치는, 그 수치들을 포함한 폐기 기록을 모든 에이전트가 프로젝트에 접근하기 전 읽는 컨텍스트 파일(context file)에 작성해 넣은 것이었습니다. 왜냐하면 "새로운 것을 기존의 것과 일치시키라"는 말은 그럴듯한 아이디어이기 때문입니다. 미래의 어떤 세션에서, 인간이든 에이전트든, 선의를 가지고 그 게이트를 다시 구축했을 것이고 그것을 자랑스러워했을 것입니다.

• 38%: 논쟁이 있는 호출(dispute calls)에서 기존 게이트의 참조 에이전트가 정답(golden answers)과 일치한 빈도
• 78%: 해당 게이트가 차단하고 있던 튜닝된 시스템이 정답과 일치한 빈도
• 90.7%: 대신 정답을 기준으로 게이트를 설정했을 때의 행동 정확도(action accuracy)
• 5개월: Enter-key 노트가 삽입된 이후, 재발 사고 없음

웹 인프라에도 이와 유사한 사례가 있습니다. 환자용 QR 코드가 한때 브라우저의 현재 오리진(origin)으로부터 링크를 재구성하도록 설계된 적이 있었습니다. 이는 좋은 위생 관리(hygiene)처럼 보입니다. 실제로 튜토리얼의 절반은 그렇게 가르칩니다. 하지만 콘솔은 프록시 호스트(proxy host)를 통해 접근이 가능했기에, QR 코드는 환자들을 앱 대신 프록시로 조용히 보내버렸습니다. 해결책은 다음과 같습니다: 서버가 발행한 링크를 있는 그대로(verbatim) 사용하십시오. 그리고 커밋(commit)에는 그 이유를 상세히 설명해 두었습니다. 왜냐하면 "현재 오리진으로부터 유도하라"는 방식은 6개월 뒤의 누군가에게는 단순한 코드 정리(cleanup)처럼 보일 것이기 때문입니다.

결과: Enter-key 노트는 5개월 전에 삽입되었습니다. 그 이후로 어떤 에이전트도 프롬프트 제출 방식을 수정하지 않았으며, 정상적인 리다이렉트(redirect)를 망가뜨리지도 않았습니다. 벽은 여전히 그곳에 있습니다. 하지만 이제 아무도 그 벽에 부딪히지 않습니다.

책에 담기는 내용

실제 시스템에서 에이전트를 실행한다면, 여러분의 문서에는 인간 팀에게는 결코 없었던 섹션이 필요합니다. 제가 제 기록에 담은 내용은 다음과 같습니다.

1. 정답 옆에 오답을 고정해 두세요. "Enter를 누르면 제출됩니다"는 절반짜리 메모입니다. "Enter를 누르면 제출되며, 백슬래시-Enter는 줄바꿈이므로 이를 사용하지 마십시오"가 완전한 메모입니다.
2. 모든 규칙에 영수증(근거)을 부여하세요. 에이전트는 단순한 지시사항에 대해서는 논쟁을 벌일 것입니다. 하지만 날짜와 출처, 그리고 무엇이 망가졌는지에 대한 이야기가 담긴 지시사항은 존중할 것입니다.
3. 무엇이 정상(healthy)인지 기록하세요. 특히 정상적인 상태가 이상해 보일 때 더욱 그렇습니다. 아무도 설명하지 않는 302(리다이렉트)는 곧 발생할 장애를 기다리고 있는 것과 같습니다.
4. 게이트(gate)나 프로세스(process)를 폐기할 때는, 에이전트가 실제로 읽는 곳에 그 이유를 기록하세요. 그렇지 않으면 미래의 세션이 이를 다시 구축하고 그것을 엄격함(rigor)이라고 부를 것입니다.

이 중 정확히 새로운 것은 없습니다. 기관은 언제나 기록된 지식으로 운영되어 왔습니다. 새로운 점은 흉터 조직(scar tissue)이 없는 노동력입니다. 인간 기업은 사람을 통해 기억합니다. AI 운영은 오직 문서를 통해서만 기억합니다.

만약 여러분이 실제적인 무언가에 에이전트를 실행하고 있다면, 여러분은 이미 이 책에 들어갈 항목들을 가지고 있습니다. 단지 아직 기록하지 않았을 뿐입니다. 정답의 책은 시스템을 계속 돌아가게 합니다. 오답의 책은 시스템이 죽을 때까지 고정되는 것을 막아줍니다.

원문은 nabbilkhan.com에 게시되었습니다.