하나의 모델로 모든 걸 하려는 시대는 끝났습니다
솔직히 말하면, 저도 한동안 "Claude 하나면 다 되지 않나?"라는 생각에 빠져 있었습니다. 그런데 dev.to에 올라온 한 개발자의 멀티 모델 워크플로우 실험기를 읽고 나서, AI-First 파이프라인의 핵심이 '어떤 모델을 쓰느냐'가 아니라 '어떤 단계에 어떤 모델을 배치하느냐'에 있다는 걸 다시 깨달았습니다. 이 개발자는 printraw라는 작은 기능 하나를 만들면서, 기획은 GPT-5.2에, 검증과 구현은 Claude Opus 4.6에 맡기는 5단계 파이프라인을 운용했습니다. 드라이버와 망치를 용도에 맞게 고르듯, 모델도 인지 태스크에 맞게 골라 쓰는 거죠.
결과가 인상적입니다. 검증 단계에서 Claude가 잡아낸 Rich 마크업 누수 버그 — console.print()로 "원문 그대로" 출력하면 Rich가 마크업 토큰을 해석해버리는 문제 — 는 단일 모델 워크플로우였다면 사용자 리포트로나 발견됐을 겁니다. 테스트 단계에서는 GPT와 Claude를 번갈아 투입하는 적대적 협업(adversarial collaboration) 패턴으로, 한 모델의 사각지대를 다른 모델이 잡아내는 구조를 만들었습니다. 이건 우리 팀에도 바로 도입할 수 있는 패턴입니다.
프롬프트를 '코드'로 관리하지 않으면, 프로덕션에서 터집니다
멀티 모델 파이프라인이 '어떤 AI를 쓸 것인가'의 문제라면, 프롬프트 관리는 '그 AI에게 무엇을 말할 것인가'의 문제입니다. Google의 샘플 코드 자동 생성 팀이 공유한 프로덕션 프롬프트 정렬 사례는, 프롬프트를 채팅이나 추측이 아니라 코드처럼 취급해야 한다고 못 박습니다. 영어(자연어)는 세미콜론 하나 빠져도 빌드가 깨지는 C++과 달리, 쉼표 하나로 의미가 뒤집히는 퍼지한 프로그래밍 언어니까요.
이 팀의 실천 원칙은 명확합니다. 프롬프트 전용 파일 분리(dotprompt 같은 도구 활용), 구조화된 출력(Structured Output) 스키마 정의로 LLM 응답의 형태를 보장, 그리고 페어 프롬프팅과 프롬프트 리뷰. 특히 "프롬프트 리뷰에서 요구사항 자체의 불일치가 발견되는 경우가 많다"는 지적이 핵심입니다. 코드 리뷰가 버그를 잡듯, 프롬프트 리뷰는 팀의 의도 불일치를 잡아냅니다. AI-First 팀이라면 PR에 프롬프트 변경 이력도 포함시키는 게 당연해져야 합니다.
Hooks: AI 에이전트에게 '안전벨트'를 채우는 법
모델을 잘 고르고, 프롬프트를 잘 관리해도, AI 에이전트가 git push --force main을 날리거나 ~/.ssh/id_rsa를 읽어버리면 끝입니다. Claude Code Hooks 활용 사례는 이 문제에 대한 실전 해법을 보여줍니다. PreToolUse와 PostToolUse 라이프사이클에 스크립트를 걸어, 위험한 명령은 사전 차단하고 모든 실행은 감사 로그로 남기는 구조입니다.
다섯 가지 Hook 중 실무에서 즉시 효과를 볼 수 있는 건 Git Safety Net(force push·hard reset 차단)과 Credential Guard(민감 경로 접근 차단), 그리고 Audit Logger(전체 도구 호출 기록)입니다. exit code 2를 반환하면 Claude가 해당 명령을 실행하지 않고, 에러 메시지를 보고 스스로 대안을 찾습니다. 이건 AI 에이전트와 협업할 때의 가드레일 패턴이고, 팀 단위로 ~/.claude/settings.json을 표준화하면 "AI가 뭘 했는지 모르겠다"는 불안을 구조적으로 제거할 수 있습니다.
워크플로우를 '그리면' AI가 더 잘 따릅니다
마지막 퍼즐은 시각화입니다. CLAUDE.md에 Mermaid 다이어그램을 도입한 사례는 EMNLP 2024의 FlowBench 연구를 인용하며, 플로차트가 자연어보다 LLM 에이전트의 워크플로우 준수율을 높인다는 점을 실증합니다. "lost in the middle" 현상 — 컨텍스트 중간에 묻힌 정보를 LLM이 놓치는 문제 — 을 플로차트의 구조적 문법이 완화해주는 겁니다.
핵심 공식은 다이어그램 + 산문(prose)의 결합입니다. 분기 로직은 Mermaid 플로차트로 그리고, '왜 이 순서인가'라는 판단 근거는 그 아래에 산문으로 붙입니다. 이 조합이 단일 포맷보다 에이전트 성능이 높다는 FlowBench의 결론은, 우리 팀의 CLAUDE.md 작성 방식을 바꿀 근거로 충분합니다.
네 개의 퍼즐을 조합하면 파이프라인이 됩니다
정리하면 이렇습니다. 멀티 모델 배치로 각 단계에 최적의 AI를 투입하고, 프롬프트의 코드화로 AI에 대한 지시를 버전 관리하며, Hooks로 안전장치를 걸어 에이전트의 위험 행동을 차단하고, Mermaid 시각화로 워크플로우 준수율을 높입니다. 이 네 가지는 각각 독립적으로도 가치가 있지만, 조합했을 때 비로소 프로덕션 레벨의 AI-First 개발 파이프라인이 됩니다.
"AI는 도구일 뿐 아니라 동료다"라고 팀원들에게 말해왔는데, 동료에게도 온보딩 문서가 필요하고, 권한 관리가 필요하고, 코드 리뷰가 필요합니다. 이 네 가지 실천법은 결국 AI 동료의 온보딩 프로세스입니다. 내일 팀 회의에서 이거 한번 같이 논의해보시죠. Claude한테 먼저 초안 잡아달라고 하면, 30분이면 우리 팀 맞춤형 파이프라인 설계가 나올 겁니다.