파이썬 없이 마케팅 파이프라인을 돌린다고?
"이거 Claude한테 맡겨봤더니 진짜 되더라고요." 처음엔 반신반의했는데, dev.to에 올라온 everyrow.io 팀 사례를 읽고 생각이 바뀌었습니다. 매일 오전 8시, 18개 커뮤니티를 스캔하고, 스레드를 분류하고, 포럼 초안까지 만들어서 PR을 여는 파이프라인—이걸 Prefect도 Dagster도 아닌, 마크다운 파일 하나로 돌리고 있다는 겁니다.
더 놀라운 건 그 파이프라인을 "개발자가 아닌 보스가 영어로 직접 썼다"는 점이에요. SKILL.md에 "18개 스캐너를 백그라운드에서 병렬 실행해" 라고 적으면, Claude Code가 그걸 읽고 서브에이전트를 스폰합니다. 의존성 그래프는 문서 순서가 전부고요. Phase 2가 Phase 1 다음에 오는 건, Phase 2가 그 아래 적혀 있기 때문입니다. 사람이 자연스럽게 생각하는 방식 그대로죠.
물론 Prefect, Dagster를 대체한다는 얘기가 아닙니다. 센서, 큐, 컨커런시 풀이 필요한 대규모 프로덕션 워크로드라면 여전히 전통적인 오케스트레이터가 맞습니다. 하지만 "비교적 단순한 파이프라인을 빠르게 만들고, 누구나 수정할 수 있게 유지하고 싶다"면? 스캐폴딩에 쏟는 공수 대비 Claude Code의 트레이드오프는 진지하게 고민할 가치가 있습니다.
특히 에러 처리 방식이 흥미롭습니다. 전통적인 오케스트레이터의 retry는 "몇 번, 어떤 에러에, 얼마나 기다렸다가 재시도"를 미리 정의해야 하는데, Claude Code는 에러 메시지를 읽고 직접 판단합니다. 라이브러리가 없으면 apt-get install을 실행하고, API 응답 형식이 바뀌면 파싱 로직을 즉석에서 수정합니다. "서버가 죽었으니 기다려" vs. "이 접근법 자체가 안 되니 다른 방법 써" 를 구분하는 거죠. 무섭기도 하지만 강력한 특성입니다.
MCP가 이겼다, 그것도 압도적으로
Claude Code가 외부 API를 어떻게 호출하느냐도 팀 워크플로우의 핵심 변수입니다. dev.to의 벤치마크 실험이 이걸 수치로 보여줬는데, 결론이 꽤 명확합니다.
동일한 API 태스크를 6가지 방식(컨텍스트 없음, OpenAPI 스펙, MCP, 파이썬 클라이언트, CLI, PyPI SDK)으로 36회 실행한 결과, MCP가 두 API 모두에서 압승했습니다.
| 방식 | 평균 턴 수 | 평균 비용 | MCP 대비 |
|---|---|---|---|
| MCP | 2.0 | $0.03 | 1.0x |
| vibe-cli | 3.0~4.0 | $0.06~$0.07 | 2x |
| PyPI SDK | 4.0~9.7 | $0.07~$0.21 | 2.4x~7.1x |
| OpenAPI 스펙 | 3.7~8.3 | $0.07~$0.16 | 2.3x~5.6x |
왜 이런 차이가 날까요? 텔레메트리 로그가 답을 줍니다. 컨텍스트 없이 API를 호출하는 에이전트는 curl URL을 직접 조립하고, 토큰 인코딩과 싸우고, 응답 파싱을 시도합니다—8번의 tool call을 소모하면서. MCP는 단 한 줄입니다: mcp__api__convert_dataset input=dataset.json format=csv. URL 구성도, 인증 처리도, 파라미터 인코딩도 없습니다. 에이전트가 의도에서 결과로 바로 직행합니다.
다만 이 실험에는 중요한 단서가 붙습니다. "안정적이고 잘 정의된 API라면 MCP로 래핑하라", 하지만 "아직 개발 중인 API라면 CLI가 낫다"는 것입니다. CLI는 플래그를 추가하는 순간 에이전트가 즉각 발견하고 활용합니다. MCP 서버는 인터페이스를 미리 확정해야 하기 때문에 빠르게 변하는 개발 초기엔 오히려 족쇄가 됩니다. 또 한 가지 반직관적인 발견: OpenAPI 스펙을 통째로 주는 건 역효과였습니다. 정보는 많아졌는데 모호함은 줄지 않은 채 컨텍스트만 불어난 거죠.
실무 권고는 단순합니다. 프로덕션 API는 MCP, 개발 중인 API는 CLI, 생성된 파이썬 클라이언트는 에이전트에게 주지 말 것.
"AI가 잘 작동하고 있나요?"—이 질문에 대답하려면
Claude Code로 워크플로우를 만들고, MCP로 효율을 높였습니다. 그런데 진짜 어려운 질문이 남아 있습니다. "우리 팀에서 AI가 실제로 효과 있나요?"
저도 비슷한 고민을 했는데, dev.to에서 이걸 체계적으로 정리한 글을 봤습니다. 팀 AI 도입을 리딩한 개발자가 몇 달 만에 얻은 결론: 코드 수용률이나 생산성 퍼센테이지 같은 기존 지표는 아무 의미가 없다는 것입니다. 수용률 100%인 팀원이 다음 날 전부 지울 수도 있으니까요.
그가 제안한 대안이 AI 커버리지 맵입니다. 측정 단위를 "속도"가 아니라 "기능 개발의 각 단계를 AI가 얼마나 안정적으로 커버하는가"로 바꾸는 겁니다.
- Covered: 2명 이상의 팀원이 실제 사용하고 검증한 워크플로우가 존재. 에이전트가 태스크를 주도하고, 개발자는 리뷰 후 ship.
- Partial: AI가 돕긴 하는데 혼자 끌고 가진 못함. 문서는 있지만 검증이 불충분.
- Uncovered: 에이전트가 맹목적으로 시도. 개발자가 끊임없이 방향을 잡아줘야 함.
이 프레임이 강한 이유는, 팀의 시스템을 기술하기 때문입니다. "폼 컴포넌트 생성은 Covered"라는 말은, 우리 코드베이스 패턴을 학습한 서브에이전트와 검증 서브에이전트가 존재하고, 여러 팀원이 재현 가능한 결과를 냈다는 뜻입니다. AI 모델이 "원래 잘해서"가 아니라, 워크플로우가 설계되어 있기 때문에.
반대로 "버그 조사는 Uncovered"라는 건 모델을 바꿔야 한다는 게 아니라, 가설 수립 → 실패 테스트 작성 → 데이터 추적 이라는 명확한 디버깅 방법론을 서브에이전트에 인코딩하는 작업이 필요하다는 신호입니다. 경영진에게 AI ROI를 설명할 때도 "아마 잘 되는 것 같아요"가 아니라 "현재 12개 영역 중 7개 Covered, 3개 Partial, 2개 Uncovered이고 이번 분기 목표는 Partial 3개를 Covered로 올리는 것"이라고 말할 수 있게 되죠.
세 가지를 하나로 엮으면
이 세 가지 이야기—Claude Code 워크플로우 엔진, MCP 벤치마크, AI 커버리지 맵—는 사실 하나의 메시지를 가리킵니다.
AI-First 팀은 "더 좋은 AI 모델"을 기다리는 팀이 아니라, 오늘 가진 도구로 반복 가능한 워크플로우를 설계하는 팀입니다.
실무 테크 리드에게 제가 권하는 순서는 이렇습니다.
- 팀의 AI 커버리지 맵부터 그리세요. 어느 영역이 Covered고, 어디가 Uncovered인지 파악하는 게 출발점입니다.
- Covered 영역에는 MCP를 붙이세요. 안정된 내부 API, 자주 쓰는 외부 서비스를 MCP로 래핑하면 에이전트 비용과 실패율이 동시에 줄어듭니다.
- Partial 영역에는 Claude Code 스킬 파일을 작성하세요. 마크다운으로 워크플로우를 정의하고, 팀원 두 명이 검증하면 Covered로 올라갑니다.
"AI가 생성해준 걸 기반으로 우리가 다듬는" 모델은 이미 검증됐습니다. 남은 건 이걸 팀 전체의 시스템으로 만드는 것입니다. 커버리지 맵이 있으면 어디에 다음 스프린트를 투자할지, 어떤 MCP 서버를 먼저 만들지, 온보딩 때 뭘 먼저 가르칠지가 자연스럽게 보입니다. "AI가 잘 작동하고 있나요?"라는 질문에 숫자로 답할 수 있을 때, AI-First 팀이라고 부를 수 있지 않을까요.