에이전트를 만드는 날, 손은 셸만 두드렸다

그날의 숫자

파싱된 도구 호출 상위 8종: shell_command 6,382 · Bash 1,184 · Edit 311 · TodoWrite 273 · Read 232 · js 186 · Write 163 · update_plan 139. 코퍼스 전체 누적으로 보면 에이전트 이벤트는 Claude 81,764 · Codex 43,557 · Gemini/Antigravity 6,972 였다 — Chart 02_sessions_over_time hook 자리, 본 회는 단일 일자 절단면.

며칠 전의 책상은 깊었다 — 26개의 손이 각자 한 우물을 바닥까지 팠다. 그날의 책상은 넓었다 — 74개의 손이 동시에 켜졌고, 그중 절반 넘는 손이 같은 동작을 반복했다. 셸을 열고, 명령을 던지고, 결과를 받고, 다시 셸을 열었다.

무슨 일이 있었나

그날 우세 작업 영역은 subagents 였다. 48개의 세션이 거기에 몰렸다. 풀어 쓰면 — 그날은 에이전트를 만드는 에이전트를 만드는 날이었다. 자식을 낳는 기계 자체를 손보는 작업. 운영자가 던진 명령은 짧았다.

역할: subagent 런타임 정비 작업자
범위: 작업 축 W010 — 에이전트 호출·등록·실행 경로
한 번에 끝낼 수 없다. 스캐폴딩 → 실행 → 로그 확인 → 수정 → 재실행.
이 루프를 네가 스스로 돌려라. 매 단계 셸로 직접 확인하고, 근거를 원장에 남겨라.

"셸로 직접 확인하고" — 이 한 구절이 6,382이라는 숫자의 정체였다. 에이전트를 만드는 일은 본질적으로 돌려 보는 일이다. 스캐폴드를 세운 뒤 진짜로 켜지는지, 자식이 부모에게 신호를 보내는지, 등록 경로가 끊기지 않았는지 — 이걸 확인하는 가장 빠른 방법은 셸이었다. 그래서 손은 Edit 311회로 고치고, 곧바로 shell_command 로 돌려 보고, 안 되면 다시 고치고 또 돌려 봤다.

shell_command 6,382 과 Bash 1,184 는 사실 같은 일을 하는 두 이름이다. 앞엣것은 Codex 계열이 셸을 부르는 이름이고, 뒤엣것은 Claude 계열이 셸을 부르는 이름이다. 둘을 합치면 7,566 — 그날 도구 호출의 **58.7%**가 "셸을 두드린다"는 단 하나의 원시 동작이었다. 모델이 둘이었지 손짓은 하나였다.

update_plan 139 와 TodoWrite 273 도 마찬가지였다. 하나는 Codex 가 계획을 적는 이름, 하나는 Claude 가 계획을 적는 이름. 또 같은 기능, 다른 라벨. 그날의 책상 위에는 같은 연장이 서로 다른 이름표를 달고 두 벌씩 놓여 있었다. 74개의 손을 지휘하려면, 운영자는 어느 자식이 어느 이름표를 읽는지를 알고 있어야 했다.

실패

넓은 날의 비용은 셸에서 새어 나왔다.

그날 redaction 이 364회 작동했다. 깊었던 날(797회)보다 적었지만, 성격이 달랐다. 깊은 날의 누수 표면은 "많이 읽어서" 넓어졌다. 넓은 날의 누수 표면은 "셸로 다 해서" 넓어졌다.

셸은 가장 정직하면서 가장 위험한 도구다. Read 로 파일을 열면 도구가 내용을 구조화해서 돌려주지만, 셸로 같은 파일을 열면 — 디렉토리째, 경로째, 환경 변수째 — 화면에 토해 낸다. 그날 6,382번의 셸 호출 중 일부는 절대경로를 stdout 으로 그대로 뱉으려 했고, 364번 누수 차단 필터가 손을 들어 그걸 가렸다.

가장 정직한 실패는 화려하지 않았다. 한 자식이 등록 경로가 맞는지 확인하려고 셸로 디렉토리를 통째로 출력했다. 그 출력에는 작업 공간의 전체 경로가 박혀 있었다. 필터가 그 줄을 가렸고, 자식은 가려진 출력을 받아서 다시 셸로 더 좁혀 물었다. 한 번에 끝낼 걸 두 번에 끝냈다. 셸 우선(shell-first) 습관은 빠르지만, 누수 표면을 호출 수만큼 선형으로 늘린다.

운영자는 그 흔적을 보고 화내지 않았다. 에이전트를 만드는 날에 셸이 절반인 건 정상이라는 걸 알았다. 다만 다음부터는 "확인은 셸로 하되, 파일 내용은 구조화 도구로 읽어라"는 한 줄을 명령에 박았다. Read 232회가 그날 끝까지 죽지 않고 살아 있었던 게 그 균형의 흔적이다.

그날의 깨달음

1. 에이전트의 차이는 모델명이 아니다 (E005). 그날 셸을 부른 이름은 둘(shell_command 6,382 / Bash 1,184)이었고, 계획을 적는 이름도 둘(update_plan 139 / TodoWrite 273)이었다. 모델이 달라서 이름이 다른 것뿐, 손짓은 같았다. 74개의 손이 한 결과로 모인 건 비싼 모델을 써서가 아니라, 같은 작업 원장(W010)에 끝까지 이어 붙는 약속이 지켜졌기 때문이다.
2. 넓은 날의 비용은 망각이 아니라 조율이다. 깊은 날엔 같은 손이 같은 파일을 잊고 두 번 읽었다(망각). 넓은 날엔 74개의 손이 같은 일을 다른 이름으로 불렀다(조율). 오케스트레이터의 일은 "어느 자식이 어느 이름표를 읽는가"를 매핑해 두는 것이다. 도구 이름이 통일되지 않은 함대에서, 통일은 사람이 머릿속에 들고 있어야 했다.
3. 셸은 가장 빠르고 가장 넓은 노출 표면이다. 셸 호출이 도구의 절반(49.6%)을 넘으면 redaction 도 그만큼 따라온다. 확인은 셸로, 읽기는 구조화 도구로 — 이 분리가 누수 표면을 줄인다. 빠른 손일수록 stdout 으로 더 많이 토해 낸다.

다음 날

다음 날 운영자는 그 74개의 세션이 남긴 결과를 열어 봤다. 에이전트를 만드는 에이전트가 한 단계 더 단단해져 있었다 — 자식이 등록되고, 부모에게 신호를 보내고, 원장에 자기 이름을 남기는 경로가 그날의 6,382번의 셸 두드림으로 다져졌다.

넓은 날은 빠르게 다지고, 깊은 날은 길게 기록한다. 운영자는 그 주에 두 가지를 다 했다. 74개의 손이 셸을 두드려 길을 닦은 날과, 26개의 손이 한 우물을 끝까지 판 날 — 둘은 같은 작업 축의 앞뒤 페이지였다.

Editor's note: 세션 수(74) · 메시지(32,209) · 도구 호출(12,878) · redaction(364) · 도구 분포 상위 8종 · 우세 에이전트(claude-code 54/74) · 우세 영역(subagents 48/74)은 모두 DuckDB sessions/tool_calls 테이블의 started_at=2026-04-27 기준 실측 집계. 세션당 평균(≈435 메시지 / ≈174 도구)과 셸 비중(49.6% / 합산 58.7%)은 단순 산술 derived 값. 에이전트 이벤트 누적(Claude 81,764 / Codex 43,557 / Gemini·Antigravity 6,972)은 코퍼스 전체 합. "절대경로를 출력하려다 필터에 가려진" 실패와 명령 프롬프트 예시는 셸 중심 도구 분포와 redaction 364회에서 끌어낸 narrative 일반화이며, 특정 세션 원문의 재현이 아니다. 사람·회사·제품·경로·키는 모두 codename 으로 치환됐다(Operator P / NG-Lab). 5월 중순 시크릿 관련 사건은 본 회에서 다루지 않는다(hold).