Claude Code를 팀에 붙이고 나서 가장 먼저 오는 신호는 대개 청구서다. '생산적으로 쓰고 있었는데 토큰이 왜 이렇게 나갔지?'라는 의문. dev.to의 한 개발자는 Claude Code 사용 패턴을 의도적으로 재설계해 토큰을 60% 줄이고 출력 품질까지 끌어올린 경험을 공유했다. 내용을 읽으면서 '이건 개인 팁이 아니라 팀 워크플로우 표준으로 박아야 할 것들'이라는 생각이 들었다.
비용이 새는 구조는 습관에서 온다
핵심 문제는 세션을 '지속되는 작업 공간'으로 쓰는 습관이다. 오전에 세션을 열고, 버그를 잡고, 점심을 먹고, 돌아와서 계속 이어가면 컨텍스트 윈도우에는 해결된 Docker 오류, 폐기된 접근법, 흘러간 아키텍처 논의가 쌓인다. 모델은 이 죽은 정보 전체를 추론의 배경으로 삼는다. 당연히 비용이 나가고, 출력 품질도 흐릿해진다.
해법은 세션을 공격적으로 리셋하되, 다음 세션에 넘길 컨텍스트를 5줄짜리 구조화된 핸드오프로 압축하는 것이다. 목적·관련 파일·제약사항·이미 실패한 것·기대 출력. 이 다섯 줄만 넘기면 모델은 잡음 없는 깨끗한 표면 위에서 작동한다. 여기에 '부정 프롬프트'를 더하면 효과가 배가된다. do not redesign the architecture, do not add dependencies, do not touch code outside the function I specified—이런 제약을 명시하지 않으면 모델은 '최대한 도움이 되는 방향'으로 범위를 스스로 확장한다. 작은 수정이 리팩터링이 되고, 핀포인트 변경이 시스템 개선 제안이 된다. 요청하지 않은 곳까지 손을 댄다.
프롬프트를 산업 장비 조작 지시처럼 쓰는 것도 같은 맥락이다. "이 접근법 어떻게 생각해?"는 모델에게 가능성 공간을 열어주는 초대장이다. 옵션, 트레이드오프, 철학적 고찰까지 전부 토큰으로 청구된다. "토큰 검증 로직에서 보안 이슈를 찾아라. 취약한 라인과 이유만 150단어 이내로 반환하라"처럼 동사·범위·제약·출력 크기를 명시하면 모델은 선택을 강요받고 결과적으로 더 날카로워진다.
단일 모델 신뢰는 구조적 취약점이다
비용 최적화 다음 단계는 품질 보증이다. AWS Heroes의 Anton Babenko가 공개한 다중 모델 합의 검증 플러그인은 이 문제를 정면으로 다룬다. 단일 모델에 마이그레이션 계획이나 대형 리팩터링을 물어보면 유창하고 자신감 있는 답변이 나온다. 문제는 유창함이 정확함을 보장하지 않는다는 것이다. 모델은 혼자이고, 루프 안에 반론이 없으므로 첫 번째 추측을 계획으로 합리화한다. 비용이 큰 실패는 거의 항상 문법 오류가 아니라 잘못된 추상화, 놓친 영향 반경, 상태를 깨뜨리는 마이그레이션 순서에서 온다. 실행 3시간 뒤에 발견된다.
claude-delegator의 /consensus 명령은 GPT, Gemini, Claude를 동일한 아티팩트에 독립적으로 돌린다. 핵심은 독립성이다. 각 모델은 별도 스레드에서 다른 모델의 리뷰를 전혀 보지 않고 각자 비판한다. 여기에 역할 분리를 더한다. Gemini는 Security Analyst로, GPT는 Architect로 돌리면 단순히 같은 모델을 두 번 돌리는 것보다 훨씬 다양한 카테고리의 오류를 잡아낸다. Claude는 이 이견들을 트리아지하고, 아티팩트를 수정하고, 세 모델이 모두 승인할 때까지 최대 5라운드를 반복한다. 합의가 안 되면 불일치를 솔직하게 보고한다. 합의를 가장하지 않는다는 점이 중요하다. 이 루프는 코드뿐 아니라 텍스트로 표현 가능한 모든 것—설계 문서, 런북, 의사결정 메모—에 적용 가능하다.
자동화 파이프라인의 마지막 레이어: AI PR 리뷰
토큰 최적화로 비용을 잡고, 다중 모델 합의로 품질을 보강했다면 이 루프를 CI/CD에 박아야 워크플로우가 완성된다. GemmaCI는 CodeRabbit 같은 유료 AI PR 리뷰어를 GitHub Actions + Gemma 오픈소스 모델로 대체하는 프로젝트다. PR diff를 요약하고, 변경 라인에 인라인 리뷰 코멘트를 달고, high/critical 이슈 발견 시 CI 체크를 실패시킨다. 단순히 LLM에게 diff를 던지는 수준이 아니라 모델 출력을 스키마 검증하고, 실제 변경 라인에 근거가 있는 finding만 게시한다는 점에서 실용성이 있다.
보안 설계도 눈에 띈다. pull_request_target을 기본적으로 사용하지 않고, publish 단계에서 trusted base branch 코드만 실행하며, artifact와 모델 출력을 신뢰하지 않는 데이터로 취급한다. 대형 모델 기반 SaaS와 완전히 동등한 품질을 기대하긴 어렵지만, 비용이 부담스러운 소규모 팀이나 사이드 프로젝트에서 워크플로우 파일 하나로 AI PR 리뷰를 붙일 수 있다는 것 자체가 진입 장벽을 크게 낮춘다.
시사점: 레이어를 쌓는 순서가 전략이다
세 가지를 조합하면 AI-First 개발 워크플로우의 실용적인 레이어가 나온다. 첫째, 세션 리셋과 프롬프트 구조화로 토큰 낭비를 제거한다. 둘째, 단일 모델 의존에서 벗어나 다중 모델 합의 검증으로 판단 품질을 높인다. 셋째, 이 검증 루프를 CI 파이프라인에 자동화해 개발자가 매번 수동으로 돌리지 않아도 되는 구조를 만든다.
팀에 이 구조를 도입할 때 현실적으로 따져야 할 것이 있다. 토큰 최적화 습관은 개인 훈련이라 온보딩 과정에서 명시적으로 가르치지 않으면 사람마다 편차가 크다. 다중 모델 합의는 단순 쿼리에 쓰면 오버킬이다. 마이그레이션, 대형 리팩터링, 아키텍처 결정처럼 '틀렸을 때 비용이 큰 판단'에만 적용하는 기준이 필요하다. GemmaCI 같은 오픈소스 AI 리뷰어는 모델 품질의 한계를 인지하고 쓰되, 리뷰어가 놓친 것을 사람이 백필하는 루틴을 병행해야 한다.
AI 도구를 쌓는 것 자체보다 '어느 레이어에 어떤 도구를 배치할 것인가'를 먼저 설계하는 팀이 실질적인 ROI를 가져간다. 더 비싼 모델이 아니라 더 나은 루프가 먼저다.