claude -p 체이닝 6단계: Phase 2가 죽는 구조적 이유와 V3.5 우회 패턴

claude -p 체이닝 6단계 Phase 2 트랩과 V3.5 우회 패턴

📚 AI 직원 회사 빌드기 — 4부작 시리즈

36분짜리 자동화가 Phase 2에서 멈춘다

claude -p로 블로그 파이프라인을 체이닝하면 특정 단계에서 subprocess가 멈추고 stdout이 비어 돌아온다. returncode는 0이다. 에러 메시지도 없다. 타임아웃까지 그냥 블로킹된다.

이게 Phase 2 트랩이다. blog-draft 스킬이 프레임·제목 후보를 제안하고 “진행 시 Phase 3 시작”이라는 텍스트를 출력한 뒤, 사용자 승인을 기다린다. subprocess.run() 안에서 승인을 기다리면 타임아웃까지 블로킹되고, 결국 md 파일이 생성되지 않은 채 다음 단계로 못 넘어간다.

이 글은 V3 5-step 파이프라인이 V3.5 6-step으로 바뀐 설계 기록이다. 트랩이 왜 발생하는지 구조적으로 분석하고, 실제 코드 변경 3가지로 어떻게 우회했는지 정리한다.

이 신호가 보이면 Phase 2 트랩이다

다음 세 가지가 동시에 나오면 코드 버그가 아니라 트랩이다:

  • Step 2(blog-draft)가 항상 딱 720초에서 TimeoutExpired로 죽는다. 랜덤하게 실패하는 게 아니라 매번 정확히 timeout에서 죽는다.

  • stdout tail을 보면 “프레임 + 제목 제안” 텍스트가 마지막이고, 그 뒤로 아무것도 없다.

  • work_dir에 md 파일이 없어서 _latest_md_in()이 None을 반환한다.

세 가지가 맞아떨어지는 이유는 스킬 설계 vs 비대화형 실행 환경의 불일치에 있다. 스킬은 대화형 세션을 전제로 만들어져 있고, claude -p subprocess는 stdin을 한 번 주고 stdout을 기다리는 단방향 채널이다.

파이프라인 6단계 구조

V3은 blog_generate.py docstring 기준 “5-step chain”이었다:

Step 1. /blog-topic-dedup          timeout=240s  (≤3분)
Step 2. /blog-draft                timeout=720s  (≤10분)  ← Phase 2 트랩
Step 3. /writing-review-pipeline   timeout=900s  (≤15분)
Step 4. /blog-thumbnail            timeout=300s  (≤3분)   ← Phase 2 트랩
Step 5. /blog-publish              timeout=360s  (≤5분)
총 최대 36분

각 단계는 _run_skill()이 실행하는 독립 claude -p subprocess다:

proc = subprocess.run(
    [CLAUDE_BIN, "-p", "--dangerously-skip-permissions",
     "--output-format", "text"],
    input=prompt,
    capture_output=True,
    text=True,
    timeout=timeout_sec,
)

--dangerously-skip-permissions를 쓰는 이유는 스킬이 Chrome headless, cp, Python subprocess 등 Bash 명령을 실행하는데, acceptEdits 모드는 Bash 실행마다 프롬프트를 요구하기 때문이다. 비대화형 환경에서 프롬프트를 기다리면 역시 블로킹된다.

V3.5에서는 Step 4.5(inline-base64)가 추가되어 실질적으로 6단계가 됐다. 이 단계는 claude -p 호출이 아니라 순수 Python 코드다. Blogger 서버가 로컬 /tmp 경로에 접근할 수 없어서 이미지가 깨지는 문제를 파이프라인 레벨에서 처리한다.

시리즈 ②와의 충돌

여기서 시리즈 ②와 정면으로 부딪히는 결정을 짚고 가야 한다. ②에서는 “외부 부작용 통제, 인간 in the loop, 보수적 기본값”을 원칙으로 격상시켰다. Discord 승인 카드, launchd Disabled=true, 환경 변수 없으면 멈춤. 모두 “자동화는 사람이 명시적으로 켜야 작동한다”는 보수적 기본값의 구현체였다.

그런데 ③의 파이프라인은 --dangerously-skip-permissions로 권한을 전부 연다. Bash 실행, 파일 쓰기, 외부 명령. 한 번 시작되면 사람의 개입 없이 끝까지 간다. 표면적으로는 ②와 정확히 반대 방향이다.

이 충돌을 어떻게 봐야 하나. 두 가지 답이 가능하다.

한 가지는 “트레이드오프”라는 답이다. ②의 인간 in the loop는 외부에 부작용을 일으키는 단계(발행, API 호출)에 적용되고, ③의 자동 실행은 내부 콘텐츠 생성 단계에 적용된다. 끝에 가서 결과물이 Discord 승인 카드로 다시 사람에게 묻는다는 점에서 ②의 원칙은 파이프라인 출구에서 회복된다.

다른 답은 “임시 처방”이다. ②의 launchd Disabled=true가 1인 운영자 24시간 응답 가능 단계까지의 시한부 처방이라고 인정했다면, ③의 --dangerously-skip-permissions도 같은 시한부 처방이다. 비대화형 자동화에 대화형 스킬을 우겨넣은 sunk-cost 결정이 이 플래그를 강제하고 있다. 더 정직한 설계는 스킬 자체에 --non-interactive capability를 추가해 권한 모델과 분리하는 것이다.

지금 단계에서는 두 답이 다 맞다. ②의 출구 통제(Discord 승인)와 ③의 입구 자동화(권한 오픈)가 맞물려서 1인 운영이 가능한 거지, ③ 혼자 보면 ②의 원칙을 깬다는 사실은 글의 frame 안에서 명시되어야 한다.

Phase 2 트랩 3가지 해부

트랩 1: 승인 대기 (가장 흔함)

blog-draft 스킬은 Phase 2에서 프레임·제목 후보를 출력하고 “진행 시 Phase 3 시작”을 출력한 뒤 멈춘다. 대화형 세션에선 사용자가 “1번으로”라고 답하면 계속 진행한다. subprocess.run() 안에서는 답이 없으니 스킬이 그 자리에서 멈춘다. 720초 후 TimeoutExpired. returncode는 비정상이다.

blog-thumbnail 스킬도 동일한 구조다. “📐 썸네일 설계 제안” 출력 후 사용자 확인을 기다린다.

트랩 2: 격리 디렉토리 없음 (조용한 데이터 오염)

V3에서 모든 큐 항목이 동일한 /tmp/blog-drafts/를 공유했다. _latest_md_in()은 mtime 기준 가장 최근 파일을 반환하는데, 두 항목이 거의 동시에 실행되면 A가 B의 md 파일을 집어오는 오염이 발생했다. 에러 없이 통과해서 디버깅이 어렵다.

트랩 3: 이미지 경로 단절

thumbnail 스킬이 PNG를 /tmp/blog-shadcn/에 저장하고 md에 로컬 경로를 삽입한다. Blogger에 업로드하면 서버에서 /tmp에 접근 못 하니 이미지가 깨진다. 발행 단계까지 returncode=0으로 통과하기 때문에 Blogger 관리 화면을 직접 확인하기 전엔 모른다.

V3.5 우회 패턴 3가지

패턴 1: 프롬프트에 비대화형 모드 명시

스킬 코드를 수정하는 게 아니라, 호출 프롬프트에서 Phase 2를 건너뛰도록 지시한다. 스킬은 대화형·비대화형 양쪽에서 재사용돼야 하므로 스킬 내부를 건드리지 않는 게 낫다:

step4_prompt = (
    "**CRITICAL — NON-INTERACTIVE MODE**:\n"
    "- This is automated CI. **SKIP Phase 2 (user approval)** entirely.\n"
    "- Use sensible defaults: layout=3-card, colors=amber,emerald,sky.\n"
    "- Proceed directly Phase 1 → Phase 3 → Phase 4 → Phase 5 → Phase 6.\n"
    "- Do NOT output '📐 썸네일 설계 제안'. Do NOT ask for confirmation.\n"
)

이건 깔끔한 해결은 아니다. 호출자가 스킬 내부 Phase 구조를 알아야 우회 가능한 leaky abstraction이다. 정공법은 스킬에 --non-interactive 플래그를 추가해서 호출자가 명시하게 하는 것. 호출자가 5개로 늘어나는 시점에 옮길 부채로 남겨두고 있다.

패턴 2: 큐 ID 격리 디렉토리

큐 항목마다 별도 서브디렉토리를 만들어 파일 오염을 구조적으로 차단한다:

# V3: 공유 디렉토리 → 오염 가능
work_dir = DRAFT_DIR  # /tmp/blog-drafts/

# V3.5: 큐 항목별 격리
ts = _time.strftime("%Y%m%d-%H%M%S")
qid = item.get("id", "unknown")
work_dir = DRAFT_DIR / f"q{qid}-{ts}"
work_dir.mkdir(parents=True, exist_ok=True)

_latest_md_in(work_dir)가 항상 해당 항목의 파일만 보게 된다. 이 디렉토리 이름 패턴(q{qid}-{ts})은 로그에서 어느 큐 항목의 작업인지 추적하는 데도 유용하다.

패턴 3: Step 4.5 base64 인라이닝

발행 전 /tmp 경로 이미지를 모두 data URI로 교체한다. 정규식 2개로 md 이미지 태그와 HTML img 태그를 각각 처리한다:

_md_body = re.sub(
    r"!\[([^\]]*)\]\((/tmp/[^)]+\.(?:png|jpg|jpeg|gif|webp))\)",
    _replace_md_img,
    _md_body,
)
_md_body = re.sub(
    r'<img\s+[^>]*src="(/tmp/[^"]+\.(?:png|jpg|jpeg|gif|webp))"',
    _replace_html_img,
    _md_body,
)

이 단계를 파이프라인 레벨에 둔 이유는 thumbnail 스킬과 publish 스킬 양쪽을 수정하지 않아도 되기 때문이다. 스킬 수정은 다른 맥락에서의 동작도 바꾼다.

체이닝을 선택한 이유, 그리고 한계

단일 claude -p 호출에 모든 지시를 넣는 게 구조적으로 더 단순하다. Phase 2 트랩 같은 문제도 원천 차단된다. 굳이 6단계 체이닝을 선택한 이유는 두 가지다.

하나는 단계별 timeout과 실패 처리를 독립적으로 제어한다는 점. 900초짜리 writing-review-pipeline이 실패해도 앞 단계 결과를 버리지 않고 warning을 달고 계속 진행한다. 단일 프롬프트면 전체를 재실행해야 한다. 또 하나는 --add-dir로 단계별로 다른 파일시스템 권한을 부여한다는 점. 모든 권한을 처음부터 여는 것보다 세밀한 제어가 가능하다.

체이닝이 복잡도를 더하는 만큼 단계 격리와 세밀한 제어를 얻는 트레이드오프다. 파이프라인 복잡도가 감당 안 되면 단일 프롬프트로 돌아가는 게 맞다.

트랩 3가지를 우회한 이후 파이프라인은 cron/kickoff.sh의 실제 운영 환경에서 돌고 있다. Blogger draft 자동 업로드까지 에러 없이 통과하는 걸 확인했다. 남은 문제는 Step 3(writing-review-pipeline)의 실패율. 900초 timeout을 자주 초과하는데, 이건 review 스킬 내부 다중 에이전트 구조 문제로 체이닝 아키텍처와는 별개다.

6개월 후에도 살아남을 한 줄

이 글의 디테일은 빠르게 stale이 된다. claude -p의 플래그(--dangerously-skip-permissions, --output-format text, --add-dir)는 1년 안에 deprecate되거나 이름이 바뀔 가능성이 높다. 720초 timeout, 정규식 2개, “Phase 2”라는 고유명사. 모두 단명한다. blog-draft 스킬을 한 번 리팩터하면 이 글의 절반이 무의미해진다.

그래도 살아남을 한 줄이 있다.

대화형 UX 단위와 비대화형 실행 단위는 분리해서 설계하라.

스킬이든 에이전트든 함수든, 사용자 확인을 기다리는 추상화와 자동화 파이프라인의 한 단계가 같은 대상이면 트랩이 발생한다. MCP·A2A·in-process 메시지 패싱이 표준이 되어도 이 원칙은 그대로다. 에이전트 A가 에이전트 B를 호출했는데 B가 “사용자 확인 부탁드립니다”를 출력하고 멈추는 시나리오는 어떤 프로토콜에서도 발생할 수 있다.

claude -p 체이닝을 직접 구축한다면, Phase 2 트랩 3가지(승인 대기, 격리 디렉토리 없음, 이미지 경로 단절)를 처음부터 설계에 반영하는 게 낫다. 나중에 디버깅하는 비용이 상당하다.

관련 글:

태그: #ClaudeCode #블로그자동화 #파이프라인 #claude-p #개발노트 #subprocess #스킬체이닝

📚 AI 직원 회사 빌드기 — 4부작 시리즈

댓글

댓글 쓰기

이 블로그의 인기 게시물

Claude Opus 4.7 출시 총정리 — 뭐가 달라졌고 지금 써야 하나

결론: Claude Opus 4.7은 "전부 업그레이드"가 아니다. 에이전트 작업에선 4.6보다 확실히 강해졌지만, 일상 코딩은 Sonnet이 여전히 3~5배 싸다. 2026-04-16 출시 후 Claude Code에서 반나절 써본 결과 3가지 체감 변화와 Qwen 3.6과의 비교까지 정리한다. Opus 4.7 핵심 변화 3가지 4.6과 비교해 체감되는 지점은 세 곳이다. 1. 에이전트 작업 체류 시간이 길어졌다 단일 지시로 파일 여러 개를 연쇄 수정할 때 중간에 “다음 단계 확인해 드릴까요?” 같은 끊김이 줄었다. 4.6은 5~6 step에서 한 번씩 끊겼는데, 4.7은 10 step 이상을 한 번에 간다. 긴 리팩터링 작업에서 체감이 크다. 2. 코딩 벤치마크 점수 상승 Anthropic 공식 블로그의 차트 기준으로 SWE-bench Verified, Terminal-bench 모두 4.6보다 올랐다. 다만 이게 실사용 속도까지 보장하지는 않는다. 3. 반론에 더 단단해졌다 4.6은 “내 말이 맞다”고 밀면 바로 물러서는 경향이 있었다. 4.7은 근거를 다시 제시한다. 디버깅 대화에서 사람이 틀린 가정을 고집할 때 이 특성이 오히려 시간을 아낀다. Qwen 3.6-35B가 Opus 4.7을 이긴다고? 같은 날 Alibaba가 Qwen 3.6-35B-A3B(오픈소스)를 공개했다. Simon Willison이 자기 노트북에서 Qwen 3.6이 Opus 4.7보다 “더 나은 펠리컨 그림을 그렸다”는 글을 올려 HN 상위에 갔다. 이 결과를 어떻게 봐야 할까. 일부 작업에서는 오픈소스가 이긴다 — 이미지 생성, 특정 추론 과제 복잡한 에이전트·장문 코딩은 Opus 4.7이 여전히 우세 비용 관점 에서 오픈소스가 매력적이지만, API 없이 로컬 돌리려면 GPU 비용이 따로 든다 즉 “Opus 4.7 vs Qwen 3.6”은 “어느 게 ...
자세한 내용 보기

Claude Code로 블로그 발행 15분을 1줄로 — 해고 후 첫 자동화 경험

Claude Code로 블로그 자동 발행 스크립트를 만드는 방법이다. 마크다운 파일을 터미널에서 명령어 한 줄로 Blogspot에 발행한다. Google Cloud Console 설정 10분, Claude Code에 지시 20분, 테스트 5분이면 끝난다. 코드를 직접 쓰지 않고 Claude Code에게 지시만 해서 만들었다. Claude Code가 뭔가 터미널에서 “블로그 발행 자동화해줘”라고 치면 스크립트를 만들어주는 AI 코딩 도구다. Anthropic이 만들었다. IDE 플러그인이 아니라 독립 CLI 도구다. 프로젝트 폴더 전체를 읽고, 파일을 직접 생성하고 수정하고 실행까지 한다. 블로그 글 1편 올리는 데 15분이 걸렸다 Blogspot에 글을 올리려면 마크다운 → HTML 변환 → Blogger 접속 → 제목 입력 → HTML 모드 전환 → 본문 붙여넣기 → 라벨 설정 → 검색 설명 → 미리보기 → 발행. 1편에 15분. 한 달에 30편이면 7시간 이상을 “올리는 작업”에만 쓰는 셈이다. 글 쓰는 시간보다 올리는 시간이 더 길었다. 이걸 Claude Code에게 맡겼다. Claude Code에게 한 지시 터미널에서 Claude Code를 열고 이렇게 말했다: “마크다운 파일을 Blogger API v3으로 자동 발행하는 Python 스크립트를 만들어줘. frontmatter에서 제목, 라벨, 슬러그를 읽고, 마크다운을 HTML로 변환한 뒤, OAuth 2.0으로 인증해서 Blogger에 POST해줘. dry-run 옵션도 넣어줘.” Claude Code가 만든 것: publish.py 메인 스크립트 (약 200줄) requirements.txt 의존성 목록 config.json 설정 파일 OAuth(구글 로그인 인증) 흐름 (최초 1회 브라우저 인증 → 이후 자동) dry-run 모드 (발행 없이 HTML 미리보기) ...
자세한 내용 보기

맥 스튜디오 M4 Max 128GB 로컬 LLM 4개 속도 비교 — gemma4·llama3.3·qwen3 실측

이미지
결론: M4 Max 128GB에서 가장 빠른 건 120B가 아니라 26B Dense 모델이다. 이유는 MoE 구조의 메모리 접근 패턴. 4개 모델 실측(tok/s 기준) + ChatGPT Plus 쿼터 제약 우회 대안 정리. 타이틀이 약속한 반전, 왜 생겼나 gpt-oss:120b 는 117B 파라미터짜리 MoE 구조. 총량은 117B지만 토큰 생성 한 번에 활성화되는 건 5.1B 정도. 이론적으로는 작은 모델만큼 빨라야 한다. 현실은 달랐다. MoE는 토큰마다 활성화되는 “전문가”가 바뀐다. 그래서 모델 전체(65GB)가 메모리에 상주해야 하고, 토큰마다 접근 위치가 비국소적(non-local)으로 흩어진다. 활성 파라미터 5.1B라는 숫자만 보면 훨씬 빨라야 맞다. 실제로 요구되는 메모리 대역폭은 전체 모델 크기에 가깝다는 얘기. 이 비교에서 직접 확인한 결과다. 반면 gemma4:26b 는 Dense 모델. 26B가 전부 계산에 참여한다. 파라미터 수 자체는 많지만 메모리 접근이 선형적이라 Apple Silicon의 통합 메모리 대역폭(546GB/s)을 효율적으로 쓸 수 있다. 같은 하드웨어에서 Dense가 MoE를 앞지르는 지점이 여기. 맥에서 로컬 LLM 고를 때 “MoE니까 활성 파라미터 작으면 빠르겠지” 하는 직관이 깨지는 순간. 테스트 환경 하드웨어는 Mac Studio M4 Max, 통합 메모리 128GB, 메모리 대역폭 546GB/s. 런타임은 Ollama 0.20.7 (llama.cpp 기반). 동일 프롬프트 3종 — 짧은 한국어, 짧은 수학, 긴 코드 생성. Cold start(첫 로드)와 Warm(모델 올라간 상태)을 분리 측정. 결과 4-way 비교표. 단위 tokens/second(tok/s). Prompt eval은 프롬프트 입력 처리 속도(초당 토큰 몇 개를 읽어들이는가), Generation은 응답 생성 속도(초당 토큰 몇 개를 출력하는가). 모델 크기(디스크) 활성 파라미터 Cold Load ...
자세한 내용 보기