그날의 숫자
| 지표 | 값 | 출처 |
|---|---|---|
| 그 날 개시된 세션 | 95 | DuckDB sessions (anchor 일자) |
| 메시지 총량 | 57,619 | sessions.msg_count 합 |
| 도구 실행 누적 | 21,229 | tool_calls 합 |
| redaction(컨텍스트 누수 차단) | 483 | sessions.redact_count 합 |
| 우세 에이전트 | claude-code 계열 | sessions.agent 분포 |
| 우세 작업 영역 | subagents | sessions.project 분포 |
도구 분해(상위 6종): shell_command 9,146 · Bash 3,696 · Edit 764 · Read 656 · TodoWrite 411 · Write 396. 셸 계열(shell_command + Bash)만 12,842회, 전체 도구 호출의 60.6% 였다 — Chart 02_sessions_over_time hook 자리, 본 회는 단일 일자 절단면.
에이전트는 두 계열로 갈렸다. claude-code 계열 59세션, codex 계열 36세션, 합이 정확히 95. 한 사람이 하루에 95개의 세션을 직접 키보드로 굴린 게 아니다. 명령은 더 적었고, 그 명령들이 자식 세션을 펼쳤다.
무슨 일이 있었나
이 날의 형태를 한 문장으로 줄이면 이렇다 — 같은 작업 영역(subagents) 위에 두 종류의 에이전트가 동시에 올라가, 서로의 변경을 지우지 않고 하루를 버텼다.
세션당 평균을 내보면 그림이 더 또렷해진다.
세션 : 95
메시지 / 세션 : 606.5
도구 호출 / 세션 : 223.5
redaction / 세션 : 5.08
셸 계열 비중 : 60.6% (shell_command 9,146 + Bash 3,696)
세션 하나가 평균 224번 도구를 부르고, 그 중 절반 이상이 셸이었다. 이건 "질문하고 답 받는" 하루가 아니다. 명령 → 실행 → 출력 확인 → 다음 명령으로 이어지는 루프가 95개의 세션 안에서 동시에 돌아간 하루다. Operator P 가 던진 건 한 줄짜리 질문이 아니라, "이 작업 영역을 너희가 나눠서 끝까지 굴려라" 에 가까운 위임이었다.
문제는, 두 계열의 에이전트가 같은 폴더를 봤다는 데 있다. claude-code 계열 59세션과 codex 계열 36세션이 같은 namespace 위에서 파일을 읽고 고치고 셸을 때렸다. 이론적으로 이건 충돌의 완벽한 조건이다. A 가 고친 파일을 B 가 모른 채 덮어쓰고, B 의 셸이 A 의 임시 산출을 지우고, 둘 다 자기가 옳다고 믿는 — 그런 하루가 됐어야 했다.
그렇게 되지 않은 이유는 모델이 비싸서가 아니었다. 각 세션이 같은 작업 원장(공유 handoff / active-tasks 류)에 자기 변경을 이어 붙이기로 약속했기 때문이다. 소유 범위 밖은 건드리지 않고, 남의 변경은 되돌리지 않고, 끝낸 일은 원장에 한 줄로 남긴다. 그 약속이 60.6% 의 셸 호출을 충돌 없이 흘려보냈다.
이게 evidence 카드 E005 가 말하는 것이다 — "여러 에이전트의 차이는 모델명이 아니라 같은 작업 원장에 이어 붙는지로 판단됐다." 카드가 백킹으로 들고 있는 누적 관찰은 이렇다:
agent_event_counts (누적 관찰)
Claude 81,764
Codex 43,557
Gemini / Antigravity 6,972
------------------------------
합계 132,293
이 누적 숫자(132,293)는 이 하루의 것이 아니라 더 긴 기간의 관찰이다. 본 회가 그것을 빌려 쓰는 이유는 단 하나 — 어느 에이전트가 더 많은 이벤트를 냈는가는 순위표일 뿐이고, 정작 하루를 버티게 한 건 그 이벤트들이 같은 원장 위에 정렬됐다는 사실이었기 때문이다.
실패
빨간 줄은 다른 자리에서 떴다. redaction 483건.
redaction 은 도구 실패가 아니다. 더 조용하고 더 불편한 신호다. 하루 동안 483번, 어떤 세션의 컨텍스트 안으로 들어가면 안 될 무언가 — 키처럼 생긴 문자열, 경로처럼 생긴 흔적 — 가 흘러들었고, 그때마다 정리 레이어가 그것을 잘라냈다는 뜻이다. 세션당 평균 5번. 95개의 손이 같은 책상을 쓰면, 그 책상 위에 놓이면 안 되는 쪽지도 같이 5배로 늘어난다.
483건이 전부 막혔다는 건 다행이다. 동시에 483건이 발생했다는 건 경고다. 멀티에이전트의 진짜 위험은 한 에이전트가 셸을 잘못 때리는 게 아니라, A 세션의 출력이 B 세션의 입력으로 흘러갈 때 그 사이를 검열하는 사람이 아무도 없다는 것이다. 그 날 검열은 사람이 아니라 자동 레이어가 했고, 그래서 483건을 다 잡았다. 만약 그 레이어가 한 칸 늦었다면, 60.6% 의 셸 호출 중 어느 하나가 잘린 쪽지를 그대로 다음 세션에 실어 날랐을 것이다.
이 하루의 가장 무거운 빚은 충돌이 아니라 누수였다. 충돌은 lock 이 막는다. 누수는 습관이 막는다.
그날의 깨달음
에이전트의 차이는 모델명이 아니라 원장 연속성이다 (E005). 95세션이 두 계열로 갈렸지만, 하루를 버티게 한 변수는 "어느 모델이 더 똑똑한가" 가 아니라 "각 세션이 같은 작업 원장에 자기 변경을 이어 붙였는가" 였다. 모델은 교체 가능한 부품이고, 공유 원장은 교체 불가능한 합의다.
셸이 60% 면, 그 하루의 진짜 도구는 파일시스템이다.
shell_command+Bash가 12,842회. 멀티에이전트를 "대화하는 여러 모델" 로 상상하면 이 숫자가 안 보인다. 실제로 그들은 같은 디스크를 동시에 만지는 여러 프로세스였다. 그래서 멀티에이전트 안전의 1차 방어선은 프롬프트가 아니라 소유 범위(write scope) 분리다.redaction 카운트는 멀티에이전트의 체온계다. 483건은 "막아서 다행" 의 숫자인 동시에 "발생해서 위험" 의 숫자다. 세션 수가 늘면 누수 발생 빈도도 비례해 늘고, 그것을 사람이 일일이 볼 수 없다. 그러니 redaction/세션 비율(이 날 5.08)을 하루 단위로 추적해야 한다 — 그 비율이 갑자기 0 에 가까워지면, 누수가 없어진 게 아니라 검열 레이어가 죽은 것일 수 있다.
다음 날
다음 날 아침, 책상 위에는 95개의 손자국 대신 한 장의 원장이 남아 있었다. 어떤 세션이 무엇을 끝냈고, 어떤 변경이 누구의 소유였는지가 그 한 장에 줄 단위로 적혀 있었다. Operator P 가 그 날 한 일은 95개의 세션을 일일이 복기하는 게 아니라, 그 한 장을 읽는 것이었다.
그 다음에 정해진 두 가지. 하나는 redaction/세션 비율을 일자 지표로 박아 두기 — 누수가 줄었는지, 검열이 죽었는지를 구분하기 위해. 다른 하나는 두 에이전트 계열이 같은 작업 영역에 올라갈 때 소유 범위를 명령 단계에서 못박기 — "네 폴더 밖은 건드리지 마라" 를 사후 약속이 아니라 사전 제약으로.
두 가지 모두 본 회 시점에는 습관에 가까웠지 강제는 아니었다. 다만 95개의 손이 같은 책상을 쓰고도 단 하나의 변경도 잃지 않았다는 사실 하나는, 멀티에이전트가 모델의 경쟁이 아니라 원장 위의 협업이라는 걸 그 날 처음으로 숫자로 보여줬다.
비싼 모델을 더 많이 켜는 게 답이 아니었다. 같은 원장에 이어 붙는 손을 더 많이 켜는 게 답이었다.
Editor's note: 세션 95 / 메시지 57,619 / 도구 21,229 / redaction 483 및 도구 분해(shell_command 9,146 외)는 모두 DuckDB sessions·tool_calls 의 anchor 일자 집계 실측. 에이전트 계열 59:36 분할도 동일 출처. evidence 카드 E005 의 agent_event_counts(132,293)는 이 하루가 아니라 더 긴 기간의 누적 관찰이며 본문에 그렇게 명시함. 두 에이전트 계열이 "충돌 없이 버텼다" 는 서술은 redaction 이 전수 차단됐다는 집계와 충돌 사고 미기록에 근거한 narrative 일반화이며, 세션 간 충돌의 정밀 분해는 본 데이터로 분리되지 않음. 모델/제품 평가는 로그 관찰 범위로 제한됨(E005 caution). 5월 중순의 별건 시크릿 incident 는 본 회에서 의도적으로 다루지 않음(hold). 사람·회사·repo·도메인·키 실명은 codename 정책에 따라 0건.
