에이전트의 자체 보고를 신뢰하지 마세요: 대신 로그를 읽으세요

제 첫 번째 에이전트 대시보드는 에이전트들이 자신들의 작업 내용을 보고하는 것에 의존했습니다. 만약 에이전트가 작업을 했지만 아무것도 보고하지 않으면, 사무실은 비어 보였습니다. 그것이 9월 21일의 디자인이었습니다. 사흘과 수많은 추가 기능들로 인해, 저는 처음부터 재설계를 요청하게 되었습니다.

모니터링하는 대상에 의존하는 상태판은 그 대상이 조용해지면 공백으로 남습니다. 해결책은 에이전트들에게 아무것도 묻지 않는 것이었습니다.

이것이 들어맞는 곳 (Where this fits)

Refmade는 제가 혼자 만들고 있는 데스크톱 앱으로, 사용자의 Claude Code와 Codex 세션이 무엇을 하고 있는지 작은 사무실 형태로 보여줍니다. 이 앱은 Anthropic이나 OpenAI와 관련 없는 독립적인 앱입니다. Claude Code 및 Codex 에이전트들이 제 지시에 따라 대부분의 코드를 작성했으며, 저는 계획하고 결정하고 검토했습니다. UI는 현재 한국어이며, 이는 이 시리즈에서 나중에 변경될 예정입니다.

이전 시리즈에서는: 첫 번째 사무실은 제가 9월 20일에 구축한 에이전트 팀을 위한 대시보드였고 (게시물 1), 이후 며칠 동안 그 범위는 게스트북, 선물, 그리고 266개 품목의 코스메틱 가챠로 확장되었습니다 (게시물 2). 이 게시물은 제가 그것을 중단한 날에 관한 것입니다.

처음부터 재설계를 요청했던 날

9월 25일, 저는 기존의 것과 첫 번째 계획을 비교하고 에이전트들에게 제품이 방향을 잃었다고 말했습니다. 제가 원했던 것은 간단했습니다: 오케스트레이션(orchestration)과 로컬 CLI가 실제로 어떻게 실행되는지 보는 것, 작업이 완료되는 것을 느끼는 것, 다른 사람들의 사무실을 엿보는 것, 그리고 각 에이전트의 작업과 핸드오프(hand-offs)를 보는 것이었습니다. 저는 패치가 아닌, 처음부터 재설계를 요청했습니다.

디자인 문서는 진단으로 시작합니다. 9월 21일부터 25일 사이에 제품은 미니 홈페이지, 선물, 보상 상자 가챠, 토큰 피라미드, 공개 마을, 게시물 번역, 그리고 웹에서 PC로 실행되는 작업들로 채워졌습니다. 각각의 기능들은 '내 AI 팀이 지금 무엇을 하고 있는가?'라는 하나의 질문으로부터 제품을 더욱 멀어지게 만들었습니다.

그날 저는 네 가지 디자인 질문에 답했습니다. 중앙 그림으로 한 사무실 바닥을 배치하고, 다른 사람들의 사무실은 친구들에게만 보이도록 했습니다. 웹 뷰는 읽기 전용(read-only)으로 유지하며 터미널에서 오케스트레이션(Orchestration)만 수행합니다. 범위는 디자인 문서와 움직이는 프로토타입에 한정되었고, 기존 코드는 전혀 건드리지 않았습니다. '친구에게만 보이는' 아이디어는 9월 27일까지 살아남았는데, 이는 6 이후의 시점입니다.

디자인 변경: 질문하지 말고 관찰하기

첫 번째 디자인은 다음과 같았습니다.

BEFORE (Sep 21)                      AFTER (Sep 25)
agent --보고서 작성--> 보드       CLI --세션 로그 작성--> 디스크
보고서 없음 = 빈 사무실             사무실이 로그를 읽음 (읽기 전용)
...

Claude Code와 Codex는 이미 모든 세션을 로컬 파일에 기록합니다. 이 파일들은 세션 시작 시점, 각 단계에서 어떤 도구가 호출되었는지, 누가 누구에 의해 서브 에이전트(sub-agent)를 생성했는지, 그리고 추론을 통해 요청이 언제 끝났는지를 보여줍니다. 따라서 새로운 규칙은 다음과 같았습니다. 하나의 세션은 하나의 팀입니다. 메인 세션이 팀장 역할을 합니다. 각 서브 에이전트는 팀원이며, 메타데이터 파일의 parentAgentId를 통해 부모와 연결되고, workflowPhase가 어떤 워크플로우 단계에 속하는지 알려줍니다. 각 책상 위의 모니터는 그 에이전트가 무엇을 하는지에 따라 색상이 바뀌는데, 이는 오직 도구 이름(tool's name)으로부터만 결정됩니다.

개인 정보 보호 측면은 신뢰성 측면만큼이나 중요했습니다. 디자인에 따르면 사무실은 타임스탬프, 도구 이름, 부모 링크 및 요청 경계로 작동하며, 프롬프트, 코드 또는 파일 경로를 읽지 않습니다. 저는 라이브 리더(live reader)가 존재하기 전에 문서에 이 경계를 명시했는데, 왜냐하면 사용자의 프롬프트가 필요한 대시보드는 다른 제품이기 때문입니다. 나중에 출시된 리더는 순수성이 조금 떨어집니다: 규칙을 적용하기 위해 메모리 내의 일부 텍스트를 보고하며, 로컬 페이지를 위해 세션 제목, 폴더 이름, 그리고 한 문장의 결과를 유지합니다. Post 4에서는 무엇을 보는지와 무엇을 유지하는지 목록화했습니다.

프로토타입이 재현한 내용

저는 그날 라이브 리더를 만들지 않았습니다. 9월 25일 프로토타입은 새로운 규칙을 통해 제가 실제로 사용했던 Claude Code 로그 중 90분 분량(한국 시간으로 9월 24일 02:00부터 03:30까지)을 재생했습니다. 추출기(extractor)는 메시지 텍스트, 경로, 도구 인수는 제외합니다.

32개의 "경유(passes)"는 워크플로우 레이블에서 추론된 것입니다(추출기가 레이블이 일치하고 시간이 맞으면 한 에이전트에서 다음 에이전트로 작업을 전달하므로), 따라서 이는 측정치가 아닌 추측으로 간주해 주십시오. 다른 개수는 추출기 스크립트에서 나온 것이며, 프로토타입이 재생하는 재현 파일과 일치합니다.

제가 프로토타입 스크린샷을 보여드릴 수 없는 이유는 그 안에 있는 팀 이름들이 제 기계의 실제 세션 제목이기 때문입니다. 대신 아래 두 장의 캡처는 현재 앱에서 가져온 것이며, 제가 출시 노트에 사용하는 공개 데모 데이터를 사용했습니다. 이들은 아이디어가 성장한 후의 모습, 즉 사무실이 근무하는 사람 수, 완료된 요청 수, 그리고 저를 기다리는 요청 수를 보여줍니다.

Refmade의 사무실 헤더, 데모 데이터. 한국어로는 "답변이 필요한 작업 1건"(배너), "내 사무실", "근무 중인 사람 9명", "완료된 요청 0건", "제가 답변해야 할 것 1건"으로 표시됩니다.

게임 테마의 팀 패널, 데모 데이터: "진행 중인 임무. 2개 팀이 근무 중입니다. 제가 답변해야 할 것이 1건 있습니다." 작업 이름인 "고객 문의 회신 분류"는 가짜입니다.

제가 삭제한 것들

처음부터 재설계한다는 것은 제거 목록을 의미했고, 그 제거 목록은 기능 목록보다 더 길었습니다.

디자인 문서는 제거된 코드가 삭제되는 대신 구현이 시작될 때 아카이브 폴더로 이동한다고 명시합니다.

두 가지 제한 사항

첫째, 관찰(observation)은 계획을 알 수 없습니다. 세션 로그는 남은 단계가 몇 개인지 알려주지 않기 때문에, 관찰된 팀은 진행률 백분율을 절대 얻을 수 없습니다. 오직 저의 refmade run 명령을 통해 시작된 팀만이 자신의 계획("5단계 중 3단계 완료")을 알고 있으며, 그 팀만이 진행 카운트를 가지고 있습니다. 저는 지어낸 숫자보다는 누락된 숫자가 더 좋다고 생각했습니다.

둘째, 보드는 "완료된 요청(finished requests)"이라고만 하고 절대 "성공한(succeeded)"이라고 하지 않습니다. 요청은 Claude Code가 턴을 끝낼 때 완료됩니다. 후속 4번 항목이 다른 경우들을 다룹니다. 작업의 질이 좋았는지 여부는 로그가 답할 수 없는 별개의 질문입니다. 이 용어 사용 방식이 그 구분을 유지하고 있습니다.

또 하나의 위험 요소는 제 코드 밖에 존재합니다. 로그들은 각각 공급업체(vendor)의 내부 형식이며, 버전 업데이트로 인해 변경될 수 있습니다. 이를 읽는 것은 제가 따라잡을 수 있을 만큼 형태가 충분히 유사하게 유지된다는 베팅과 같습니다.

검토 및 여전히 미흡했던 부분

독립적인 디자인 검토 결과 프로토타입에 10점 만점에 6점을 주었으며, 8가지 문제를 지적했습니다. 저는 이 8가지 문제 모두를 수정했습니다: 패널이 다시 렌더링될 때 초점이 다른 곳으로 이동하는 현상, 모바일에서 완료된 보드가 잘리는 현상, 텍스트에 대한 최소 11px 설정, "내 차례"와 "질문 대기 중"의 색상이 너무 유사한 점, 그리고 타임라인에 대한 키보드 제어 기능입니다. 검사 결과 디자인-린트(design-lint) 실패는 0건이었고, 360px에서 1920px까지 수평 스크롤도 없었습니다. 하지만 여전히 미흡한 부분이 있습니다. 브리프 자체 목록에 따르면, 캐릭터가 걸을 때 워킹 프레임이 없는 직선으로 움직이는 점, 아트는 9월 21일 자산의 임시적인 잘라 붙인(cut-up) 형태라는 점, 그리고 프로토타입 속 세 명의 친구들은 가상의 예시였다는 점입니다.

다음 게시물에서는 독자가 요청을 도구 결과와 어떻게 구분하는지, 실제 서브 에이전트로부터 파생된 포크(fork)를 언제 인식하는지, 그리고 요청이 실제로 언제 끝나는지에 대해 다룰 예정입니다. 앱 링크는 이 시리즈의 마지막 게시물에 포함될 것입니다.

자체 에이전트의 상태 보드를 위해 무엇을 더 신뢰하시겠습니까? 그들이 자신이 했다고 말하는 것입니까, 아니면 파일에 기록된 것이라고 하더라도 그것을 신뢰하겠습니까? 설령 파일 형식이 당신 아래에서 변경될 수 있다 할지라도요?