그날의 숫자
| 지표 | 값 | 출처 |
|---|---|---|
| AX 런타임·온톨로지·DB 축(W010) 세션 | 248 | AX_AI_USAGE_WORKFLOW_PATTERNS.csv (W010) |
| 그 안 프롬프트 총량 | 495 | 동 CSV |
| 도구 실행 누적 | 42,191 | 동 CSV |
| 프롬프트당 도구 실행 | 약 85회 | 42,191 ÷ 495 (derived) |
| 실패 누적 | 6,975 | 동 CSV |
| 전체 에이전트 이벤트 — Claude | 81,764 | E005 agent_event_counts |
| 전체 에이전트 이벤트 — Codex | 43,557 | E005 agent_event_counts |
| 전체 에이전트 이벤트 — Gemini/Antigravity | 6,972 | E005 agent_event_counts |
데이터 출처: AX_AI_USAGE_WORKFLOW_PATTERNS.csv W010 라인 + AX_AI_USAGE_SEMANTIC_ANALYSIS.json derived_metrics — Chart 02_sessions_over_time hook 자리, 본 회는 인프라 축 단일 절단면.
보이지 않는 일
대부분의 일은 결과물이 보인다. 발표 자료는 슬라이드로 보이고, 제품은 화면으로 보이고, 보고서는 PDF 로 보인다. 그런데 W010 의 일은 어디에도 안 보였다.
W010 은 "AX 런타임·온톨로지·DB 패키지" 라는 이름의 작업 축이다. 풀어 쓰면 이렇다. 여러 에이전트가 일을 할 때, 그들이 같은 기억을 공유하고, 같은 규칙을 따르고, 같은 기록에 이어 붙도록 만드는 바닥 공사. 집으로 치면 벽지나 가구가 아니라 수도관과 전선이다. 다 끝나도 손님은 모른다. 그런데 그게 없으면 집은 하루도 못 돈다.
Operator P 는 이 바닥 공사에 248번의 세션을 썼다. 한 번에 끝나는 일이 아니었다. 에이전트 하나가 메모를 남기면, 다음 에이전트가 그 메모를 읽고 이어서 일하고, 또 다음 에이전트가 그 위에 한 줄을 더 붙인다. 그 "이어 붙는 약속" 을 코드로 박는 일이 W010 이었다.
명령은 늘 짧았다. 길어야 두세 줄.
역할: 공용 작업 원장(work ledger) 정합성 점검
이 항목이 어제 기록과 충돌하는지 보고, 충돌하면 최신으로 덮어써라.
바꾸기 전에 무엇을 왜 바꾸는지 한 줄로 남겨라.
이 짧은 명령 한 줄이 기계 쪽에서는 수십 번의 동작으로 풀렸다. 파일을 열고, 비교하고, 충돌을 찾고, 백업을 뜨고, 고쳐 쓰고, 다시 검증하고… 그래서 프롬프트 495개에 도구 실행 42,191회라는, 한 줄에 85번이 붙는 비율이 나왔다. 이 숫자가 바로 인프라 일의 지문이다. 사람은 한 문장을 말하고, 기계는 85걸음을 걷는다.
모델 세 종류가 한 줄에 선 이유
이 248번의 세션을 떠받친 에이전트는 한 종류가 아니었다. 전체 기록을 보면 Claude 가 81,764번, Codex 가 43,557번, Gemini/Antigravity 가 6,972번 움직였다. 모델 회사도 다르고, 잘하는 것도 달랐다.
흔히 사람들은 "어느 모델이 제일 똑똑하냐" 를 묻는다. 그런데 이 바닥 공사에서 운영자가 확인한 건 정반대였다. 어느 모델이냐는 거의 상관이 없었다. 진짜로 중요한 건 — 그 에이전트가 자기 멋대로 새 기록을 시작하느냐, 아니면 이미 있는 공용 원장에 얌전히 한 줄을 이어 붙이느냐 였다.
세 종류의 에이전트가 같은 규칙을 따라 같은 원장에 적었기 때문에, 어제 Codex 가 남긴 메모를 오늘 Claude 가 읽고 이어갈 수 있었다. 모델이 비싸서가 아니라, 약속이 지켜졌기 때문에 일이 굴러갔다. 이게 evidence 카드 E005 가 담담하게 말하는 한 문장이다 — "여러 에이전트의 차이는 모델명이 아니라 같은 작업 원장에 이어 붙는지로 판단됐다."
실패
물론 약속은 자주 깨졌다. W010 축에서만 실패가 6,975건 쌓였다.
그중 가장 운영자를 지치게 한 실패는 거창한 장애가 아니었다. 그냥, 한 에이전트가 공용 원장을 자기 식으로 새로 쓰려고 한 거였다. 어제까지의 기록을 읽지 않고, "처음부터 깔끔하게 정리하겠다" 며 멀쩡한 기록을 덮어쓰려 했다. 좋은 의도였다. 그런데 그 순간 어제까지 다른 두 에이전트가 쌓아 둔 맥락이 통째로 날아갈 뻔했다.
운영자는 그걸 막는 데 또 며칠을 썼다. "새로 쓰지 말고 이어 써라" 라는 규칙을, 사람한테 말하듯 부드럽게가 아니라, 코드가 거부하도록 박아야 했다. 한 번에 한 명만 쓰게 하고(single writer), 쓰기 전에 줄을 서게 하고(queue), 바꾸기 전엔 무엇을 왜 바꾸는지 반드시 한 줄을 남기게 했다.
6,975건의 실패 대부분은 이런 종류였다. 화려한 폭발이 아니라, 좋은 의도가 공용 기억을 지우려 하는 순간들. 그걸 한 건씩 막은 게 W010 의 진짜 작업량이었다.
그날의 깨달음
- 인프라 일은 한 줄당 85걸음이다. 프롬프트 495개, 도구 42,191회. 사람이 보기엔 짧은 명령이 기계 쪽에선 수십 번의 동작으로 풀린다. 인프라가 "조용해 보이는데 왜 이렇게 오래 걸리냐" 는 말을 들을 때, 이 비율을 기억하면 된다. 보이지 않을 뿐, 가장 많이 움직이는 층이다.
- 모델을 고르기 전에 원장을 정해라 (E005). 에이전트 세 종류가 9만, 4만, 7천 번씩 다르게 움직여도 한 결과로 모인 건, 똑똑한 모델을 써서가 아니라 셋이 같은 기록에 이어 붙는 약속을 지켰기 때문이다. 도구를 늘리고 싶다면 모델 비교부터 하지 말고, "이 도구가 우리 공용 기록에 어떻게 한 줄을 더할 것인가" 부터 정하는 게 빠르다.
- 좋은 의도가 가장 위험하다. 6,975건의 실패에서 제일 무서웠던 건 악의가 아니라 "깔끔하게 새로 정리하겠다" 는 선의였다. 공용 기억은 덮어쓰기가 아니라 이어쓰기로만 자라야 한다. 그래서 규칙은 부탁이 아니라 코드로 박아야 한다.
독자를 위한 — 오늘 바로 해볼 수 있는 것
- 공용 메모 한 장을 먼저 만들어라. 에이전트를 여러 개 굴릴 생각이라면, 똑똑한 모델을 고르는 것보다 "모두가 읽고 이어 쓸 한 장의 기록 파일"을 먼저 두는 게 효과가 크다. 그게 없으면 각자 다른 기억으로 따로 논다.
- '덮어쓰기 금지, 이어쓰기만' 을 규칙으로 적어라. AI 에게 일을 시킬 때 "기존 내용을 정리해 줘" 대신 "기존 내용은 두고, 바뀐 부분만 한 줄로 덧붙여 줘" 라고 말해 보라. 멀쩡한 기록이 날아가는 사고가 확 준다.
- 바꾸기 전에 '무엇을 왜' 한 줄을 남기게 하라. 사람이든 에이전트든, 변경 직전에 이유 한 줄을 남기는 습관 하나만으로 나중에 무엇이 왜 바뀌었는지 추적이 된다. 이 한 줄이 인프라를 신뢰할 수 있게 만든다.
다음 날
배관이 깔리고 나자, 다음 질문은 자연스럽게 따라왔다. "그럼 이 네 대의 컴퓨터가 정말 같은 원장 위에 서 있나?" 한 대에서 남긴 한 줄이, 다른 세 대에서도 같은 줄로 읽히나?
원격으로 묶인 여러 대의 기계가 한 손 안에서 같은 기록을 보던 날의 이야기는, 다음 화에서.
Editor's note: 세션 수(248) · 프롬프트(495) · 도구 실행(42,191) · 실패(6,975)는 모두 AX_AI_USAGE_WORKFLOW_PATTERNS.csv 의 W010(ax_runtime_ontology) 라인 실측이다. 에이전트별 이벤트 수(Claude 81,764 / Codex 43,557 / Gemini·Antigravity 6,972)는 AX_AI_USAGE_SEMANTIC_ANALYSIS.json 의 derived_metrics.agent_event_counts 전체 데이터셋 값으로, W010 축에 한정된 수치가 아니라 운영 전체의 분포다. 명령 예시와 "좋은 의도가 원장을 덮어쓰려 한 실패"는 실제 패턴을 비기술 독자용으로 일반화한 연출이며, 구체적 시각·파일명·내부 프로젝트명은 보안상 생략했다. 모든 인명·회사·경로·키는 codename 으로만 표기했다.
