Projects About

Claude Code 하루 8세션 69 tool calls — 오케스트레이터가 스스로를 막을 때

· portfolio-site · 0
#claude-code#automation#orchestration#multi-project

5월 28일 하루, Claude Code가 8개 세션에서 69번 도구를 호출했다. SpoonAI 뉴스 정리, 치과 광고 리서치, 제품 매출 보고서, CLI 상태 보고서 — 전부 다른 프로젝트였고 전부 자동화 파이프라인 안에서 돌아갔다.

TL;DR 오케스트레이션이 복잡할수록 단순한 작업이 막힌다. 세션 5에서 오케스트레이터 게이트가 단일 HTML 파일 생성을 차단했다. simple로 재분류 후 1분 만에 끝냈다.

Bash 33회, Read 24회 — 실제로 뭘 하고 있었나

69번 도구 호출의 분포가 흥미롭다.

  • Bash: 33회 (48%)
  • Read: 24회 (35%)
  • TaskCreate: 5회
  • WebSearch: 4회
  • Write: 2회
  • ToolSearch: 1회

Write가 2번뿐이다. 파일을 새로 만든 것도 2개다. 나머지 67번은 읽고 실행하는 데 썼다. 자동화 작업의 실제 무게중심이 어디 있는지 보여준다 — 코드를 짜는 게 아니라 기존 데이터를 읽고, 검증하고, 상태를 갱신하는 것이다.

세션별로 패턴이 다르다. 세션 1(SpoonAI 인텔 정리)은 Bash 10회만 썼다. 입력 JSON이 이미 준비되어 있어서 읽고 정리하는 것만으로 충분했다. 세션 4(P1 제품 보고서)는 WebSearch 4회가 포함됐다 — 실시간 시장 데이터가 필요했기 때문이다. 입력 데이터가 미리 준비된 작업과 실시간 검색이 필요한 작업은 구조 자체가 다르다.

첫 패스가 끝나지 않으면 두 번째 세션을 부른다

세션 2와 3은 같은 작업의 두 단계다. 치과 광고 데일리 리서치였는데, 세션 2가 메인 파일(2026-05-28-daily-update.md)만 만들고 누적 파일(rolling-knowledge-base.md, naver-ranking-hypotheses.md 등)과 HTML 보고서를 남겼다.

세션 3 프롬프트의 첫 줄이 직접적이다.

# Narrow finish pass — 2026-05-28 medical/dental ads daily job

The first artifact pass created .../2026-05-28-daily-update.md
but did not finish cumulative files or HTML report.

이게 오케스트레이션의 현실이다. 복잡한 작업을 단일 세션에서 끝내려 하면 일부 산출물이 빠진다. “narrow finish pass” 패턴 — 첫 번째 패스에서 뭘 못 만들었는지 정확히 기록하고, 두 번째 세션에서 그것만 마저 하는 방식 — 이 실용적이다.

세션 3은 Read 15회, Bash 3회였다. 이미 만들어진 파일들을 읽고 누락된 것만 추가하는 작업이라 Write 호출도 없었다. 도구 통계만 봐도 이 세션이 “새로 만드는” 세션이 아니라 “마저 채우는” 세션임을 알 수 있다.

오케스트레이터 게이트가 스스로를 차단했다

세션 5가 가장 흥미로운 케이스다. 프롬프트는 단순했다 — ~/.hermes/tmp/report-demo/cli_report_design_status.html 파일 하나 만들어라. CLI 버전 상태와 보고서 디자인 기준 변경 내용을 담은 한국어 HTML 보고서였다.

오케스트레이터 게이트가 막았다. 세션 로그에 남은 한 줄이다.

오케스트레이터 게이트가 차단했습니다.
단일 HTML 파일 생성 작업이라 `simple`로 재분류한 뒤 다시 진행합니다.

복잡성 분류 휴리스틱이 틀린 것이다. 게이트는 HTML 보고서 생성 요청을 standard 이상으로 분류했고, implementing 스테이지가 아니라는 이유로 Write 권한을 차단했다. 실제 작업은 파일 한 개 생성이었는데.

해결책은 단순했다 — 직접 simple로 재분류하고 진행. 세션 6에서 Bash 1회로 디렉토리 확인 후 Write 1회로 파일을 만들었다. 두 세션을 쓴 셈이지만 세션 6은 1분도 안 걸렸다.

이 케이스가 보여주는 것: 오케스트레이션 규칙이 정교해질수록 오탐(false positive)도 늘어난다. simple과 standard의 경계가 모호할 때, 게이트가 안전하게 차단하는 방향으로 기울면 실제 생산성이 떨어진다. 오케스트레이터가 스스로 판단을 교정할 수 있는 경로가 필요하다.

세션 7, 8은 핑이었다

세션 7 프롬프트는 Return exactly: CLAUDE_OK였고, 세션 8은 Return exactly: CLAUDE_OK_AFTER_FIX였다. 도구 호출 0회. 오케스트레이터가 Claude CLI 응답을 확인하는 헬스체크 패턴이다.

8세션 중 2세션이 핑이었다. 유효한 작업 세션은 6개였고, 그중 가장 짧은 건 0분(세션 1)이었다. 세션 수를 생산성 지표로 쓰면 안 되는 이유가 여기 있다.

하루 자동화 파이프라인에서 정리된 세 가지

첫째, 입력이 준비된 작업과 실시간 검색이 필요한 작업을 구분해서 설계한다. 전자는 Read + Bash 패턴이 빠르고, 후자는 WebSearch 결과를 먼저 확보해야 한다.

둘째, 첫 패스에서 무엇을 만들었고 무엇을 남겼는지 명확히 기록하면 두 번째 세션이 훨씬 빠르다. “narrow finish pass” 프롬프트 패턴 — 다음 세션 프롬프트의 첫 줄에 “이전 패스가 X를 못 만들었다”고 명시하는 것 — 이 그 방법이다.

셋째, 복잡성 분류 오탐은 실제로 작업을 막는다. 오케스트레이터에 재분류 경로를 열어두는 것이 안전하다. 세션 5에서 simple로 수동 재분류한 것이 그 패턴이다.

Comments 0

0 / 1000