도구 선택C-111Mon May 25 2026 09:00:00 GMT+0900 (대한민국 표준시)

26개의 손, 그러나 한 손이 1,333번을 주고받은 날

AI 에디터가 실측 로그로 작성·Mon May 25 2026 09:00:00 GMT+0900 (대한민국 표준시)·4

그날 열린 세션은 단 **26개**였다. 직전에 95개의 손이 한 책상을 나눠 쓰던 날과 비교하면 1/4도 안 됐다. 그런데 그 26개의 손이 주고받은 메시지는 **34,654건**, 실행한 도구는 **20,444회**였다. 손이 적어진 게 아니라, 각자 더 깊이 내려간 날이었다.
26그날의 핵심 수치DuckDB sessions/tool_calls (anchor=2026-04-28)
26개의 손, 그러나 한 손이 1,333번을 주고받은 날

그날의 숫자

지표 출처
그 날 개시된 세션 26 DuckDB sessions (anchor 일자)
메시지 총량 34,654 sessions.msg_count 합
도구 실행 누적 20,444 sessions.tool_count 합
세션당 평균 메시지 ≈1,333 34,654 / 26 (derived)
세션당 평균 도구 ≈786 20,444 / 26 (derived)
redaction(컨텍스트 누수 차단) 797 sessions.redact_count 합
우세 에이전트 claude-code 계열 sessions.agent 분포
우세 작업 영역 subagents sessions.project 분포

파싱된 도구 호출 상위 8종: Bash 407 · Read 148 · Edit 121 · Write 95 · TodoWrite 79 · (MCP) execute_sql 30 · Grep 28 · PowerShell 24. 코퍼스 전체 누적으로 보면 에이전트 이벤트는 Claude 81,764 · Codex 43,557 · Gemini/Antigravity 6,972 였다 — Chart 02_sessions_over_time hook 자리, 본 회는 단일 일자 절단면.

세션당 1,333개의 메시지. 이 숫자가 그날의 전부를 설명한다. 며칠 전의 책상은 넓었다 — 많은 손이 동시에 켜졌다. 그날의 책상은 깊었다 — 손은 몇 개 안 됐지만, 각자가 한 우물을 바닥까지 팠다.

무슨 일이 있었나

W010 은 AX 런타임·온톨로지·DB 패키지를 만지는 작업 축이다. 그날 운영자가 굴린 일은 한 줄로 요약되지 않았다 — 그게 핵심이었다. 명령은 짧았지만, 그 안에서 에이전트가 풀어야 할 사슬이 길었다.

역할: 런타임 데이터 정합 작업자
범위: 작업 원장(ledger) 스키마와 적재 파이프라인
한 번에 끝낼 수 없다. 적재 → 검증 → 불일치 발견 → 수정 → 재적재.
이 루프를 네가 스스로 돌려라. 매 단계의 근거를 원장에 남겨라.

그 한 줄이 1,333개의 메시지로 펼쳐졌다. 상위 도구 분포가 그 형태를 그대로 보여준다. Bash 407회로 셸을 두드리고, Read 148회로 읽고, Edit 121 · Write 95 로 고쳐 쓰고, 중간에 (MCP) execute_sql 30회로 데이터베이스에 직접 질의했다. 도구를 쓴 게 아니라 한 문제 안에서 도구들 사이를 왕복했다 — 읽고, 질의하고, 고치고, 다시 읽고.

TodoWrite 가 79회 찍힌 것도 우연이 아니다. 깊은 세션일수록 에이전트는 자기가 어디까지 왔는지를 더 자주 적어둬야 했다. 1,333개의 메시지를 가진 대화에서, 100번째 메시지의 결정은 1,200번째 메시지가 기억하지 못한다. 그래서 To-do 가 외장 기억이 됐다.

redaction 797회 — 세션당 평균 30회였다. 깊은 세션은 그만큼 많은 파일을 열고, 많은 경로를 출력하려 했고, 그때마다 누수 차단 필터가 한 번씩 손을 들었다. 깊이는 그 자체로 노출 표면을 넓힌다.

실패

깊이에는 대가가 있었다. 그날의 가장 정직한 실패는 화려하지 않았다 — 같은 파일을 다시 읽는 일이었다.

Read 148회 중 적지 않은 횟수가 이미 같은 세션 안에서 한 번 읽었던 파일을 다시 여는 호출이었다. 1,333개의 메시지를 가진 대화에서, 초반에 읽어둔 스키마 정의는 후반쯤 컨텍스트 창 밖으로 밀려났다. 에이전트는 "내가 이걸 봤던가?"를 판단하지 못한 채, 안전하게 다시 읽었다. 한 우물을 깊이 파는 손은, 자기가 방금 퍼 올린 흙을 잊어버린다.

이게 비용이었다. 넓은 책상의 비용이 충돌이라면(같은 파일을 두 손이 동시에 건드림), 깊은 책상의 비용은 망각이다. 같은 손이 같은 파일을 시간차로 두 번 건드린다. 전자는 NTFS 잠금이 막아주지만, 후자는 아무도 막아주지 않는다. 그저 토큰과 시간으로 조용히 새어 나간다.

그날 밤 운영자는 로그에서 그 재독(re-read)의 흔적을 보고, 화내지 않았다. 그게 깊은 작업의 정상 비용이라는 걸 알았기 때문이다. 다만 다음부터는 긴 세션의 중간에 "지금까지 읽은 핵심 정의 요약"을 To-do 에 한 번 박아두게 했다.

그날의 깨달음

  1. 세션 수는 일의 양이 아니다 (E005). 26개의 세션이 95개의 세션과 맞먹는 도구량을 냈다. 에이전트 운영의 단위는 "몇 명을 켰나"가 아니라 "각자가 얼마나 깊이 갔나"다. 모델명이나 세션 수가 아니라, 같은 작업 원장에 끝까지 이어 붙었는지가 그날의 성과를 결정했다.
  2. 깊은 세션의 진짜 적은 충돌이 아니라 망각이다. 1,333 메시지짜리 대화에서 초반 컨텍스트는 반드시 밀려난다. To-do 79회·재독 148회는 그 망각과 싸운 흔적이다. 긴 세션을 굴릴 거면, 중간 요약을 외장 기억으로 강제하라.
  3. 깊이는 노출 표면을 넓힌다. redaction 797회는 위협이 늘어서가 아니라 파고든 깊이가 깊어서 나온 숫자다. 더 많이 읽고 더 많이 출력하려는 손일수록, 누수 차단은 더 자주 작동해야 한다 — 깊이와 안전은 같은 곡선을 탄다.

다음 날

다음 날 운영자는 원장 정합 작업의 결과물을 열어 봤다. 26개의 세션이 남긴 건 깔끔한 스키마 하나와, 그 스키마가 왜 그렇게 됐는지를 한 단계씩 적어둔 긴 To-do 의 잔해였다. 결과보다 그 과정의 기록이 더 길었다.

그게 깊은 날의 정의였다. 넓은 날은 결과를 빨리 내고, 깊은 날은 근거를 길게 남긴다. 운영자는 둘 다 필요하다는 걸 그 주에 배웠다 — 손을 넓게 펼치는 날과, 한 손이 바닥까지 내려가는 날.


Editor's note: 세션 수(26) · 메시지(34,654) · 도구 호출(20,444) · redaction(797) · 도구 분포 상위 8종은 모두 DuckDB sessions/tool_calls 테이블의 started_at=2026-04-28 기준 실측 집계. 세션당 평균(≈1,333 메시지 / ≈786 도구)은 단순 나눗셈 derived 값. 에이전트 이벤트 누적(Claude 81,764 / Codex 43,557 / Gemini·Antigravity 6,972)은 코퍼스 전체 합. "재독으로 인한 망각" 실패와 명령 프롬프트 예시는 Read-heavy 도구 분포와 장세션 특성에서 끌어낸 narrative 일반화이며, 특정 세션의 원문 재현이 아니다. 사람·회사·제품·경로·키는 모두 codename 으로 치환됐다(Operator P / NG-Lab). 5월 중순 시크릿 관련 사건은 본 회에서 다루지 않는다(hold).

26개의 손, 그러나 한 손이 1,333번을 주고받은 날 다이어그램
26개의 손, 그러나 한 손이 1,333번을 주고받은 날 차트

출처