세 가지 문제가 동시에 터진다
AI-First로 팀을 운영하다 보면 어느 순간 세 가지 문제가 한꺼번에 수면 위로 올라온다. AI 코딩 비용이 예상보다 빠르게 불어나고, 에이전트가 조용히 회귀(regression)를 통과시키며, PR에서 인간 리뷰어의 역할이 점점 얇아진다. 문제는 이 셋을 각각 '도구 선택' '평가 대시보드' '프로세스 정비'로 따로 풀려는 팀이 많다는 것이다. 실제로는 하나의 파이프라인 설계 결정이다.
비용: 프론티어 모델에 모든 태스크를 던지면 망한다
dev.to의 한 개발자는 Claude Fable 5가 출시 72시간 만에 규제로 오프라인 전환되는 사건을 겪으며 모델 라우팅의 중요성을 직접 체감했다고 밝혔다. 그가 공유한 수치는 단순하지만 충격적이다. 프론티어 모델(Fable/Opus급)은 코딩 태스크당 $5~15, 중간 모델(Sonnet급)은 $0.50~2다. 월 AI 코딩 비용을 $10K에서 $3K로 줄인 방법은 더 싼 모델로 일괄 교체가 아니었다. 태스크 유형별로 모델을 분리한 것이다.
실제로 추적해보면 전체 토큰의 60~70%는 Sonnet급으로도 충분히 처리 가능한 태스크에 쓰인다. 보일러플레이트 생성, 단위 테스트 작성, 문서화, 간단한 버그 수정이 여기 해당한다. 복잡한 아키텍처 결정, 멀티 파일 리팩토링, 레이스 컨디션 디버깅만 프론티어 모델이 필요하다. 이 분류를 팀 레벨의 라우팅 테이블로 명문화하지 않으면, 개발자마다 습관적으로 가장 강력한 모델을 쓰게 되고 비용은 통제 불능이 된다.
부가적으로, 단일 모델에 의존하는 파이프라인은 가용성 리스크도 떠안는다. 규제, 레이트 리밋, 프로바이더 장애—어느 하나라도 발생하면 파이프라인 전체가 멈춘다. 폴백 체인은 방어적 엔지니어링의 기본이다.
품질: 에이전트 평가를 대시보드에 두면 그건 박물관이다
"에이전트 평가가 있다"고 말하는 팀에게 어디서 실행되냐고 물으면 대부분 노트북이나 스프레드시트를 지목한다. dev.to의 또 다른 글은 이를 직설적으로 비판한다. 머지를 블로킹하지 못하는 평가는 장식품이다. 금요일에 배포한 코드에 대한 월요일 리포트는 평가가 아니라 사후 부검이다.
AI 에이전트는 코드 diff에 아무 변화가 없어도 동작이 바뀐다. 프로바이더가 모델 체크포인트를 롤링 업데이트하면 동일한 프롬프트가 다른 결과를 낸다. 리트리벌 인덱스가 재임베딩되면 에이전트가 오래된 데이터를 자신 있게 인용하기 시작한다. 이 변화는 코드 리뷰로 잡을 수 없다. CI 게이트만 잡는다.
실용적인 CI 에이전트 평가 게이트는 두 레이어로 구성된다. 첫째, 스코어러: 결정론적 검증(유효한 JSON, 금지 문구 없음, 필수 필드 존재)과 모델-as-저지(응답이 실제로 도움이 되었는가, 정책 준수 여부)를 결합한 pass/fail 신호. 둘째, 트레이스: 어떤 모델 콜이 실행됐고, 프롬프트가 실제로 어떻게 해석됐으며, 에이전트가 어떤 툴을 선택했는지의 실행 경로. 스코어만 있으면 '케이스 17이 실패했다'는 것만 안다. 트레이스가 있어야 '프롬프트 수정이 tool_selection을 search_db에서 web_fetch로 바꿨고 그래서 답변이 오래됐다'는 원인까지 파악한다. 점수만 주는 게이트는 팀이 결국 무시하게 된다.
비용 효율도 설계해야 한다. 모든 PR에 모델-as-저지를 돌리면 레이트 리밋에 걸리고 게이트 자체가 비활성화된다. 결정론적 검증은 매 커밋, 모델-as-저지는 핵심 케이스 세트에 한정하거나 야간 배치로 분리하는 것이 현실적이다.
리뷰: 인간이 마지막 승인자로 수렴하고 있다
dev.to의 한 기고자는 OSS 프로젝트에 PR을 올렸다가 리뷰 경험이 완전히 달라진 것을 체감했다. Copilot 제안, Vercel 프리뷰 피드백, CI 자동 코멘트가 대부분의 상호작용을 처리했고, 인간 메인테이너는 전체적인 방향을 확인한 뒤 최종 승인만 했다. 라인 바이 라인 토론은 없었다.
이 변화를 '인간 리뷰의 약화'로 보는 시각이 있지만, 나는 다르게 읽는다. 역할이 재정의되고 있다. 자동화가 처리하는 것은 형식 일관성, 회귀 검증, 배포 전 체크—반복적이고 명세가 명확한 작업이다. 인간 리뷰어가 집중해야 할 것은 아키텍처 의도, 팀 컨벤션과의 정합성, 비즈니스 맥락에서의 적절성이다. 문제는 많은 팀이 이 재정의를 명시적으로 설계하지 않는다는 점이다. 자동화가 늘어나는 속도에 그냥 떠밀려가다 보면, 인간 리뷰어가 '마지막 도장'을 찍는 역할로 수렴하고 정작 자신이 무엇을 검토해야 하는지 잃어버린다.
시사점: 세 문제는 하나의 파이프라인 설계다
비용·품질·리뷰 역할, 이 세 문제는 서로 연결된다. 태스크별 모델 라우팅을 설계하면 비용이 내려가고, 동시에 어떤 태스크가 어떤 품질 기준을 적용받아야 하는지의 매트릭스가 생긴다. CI에 에이전트 평가 게이트를 붙이면 자동화가 처리하는 품질 검증의 범위가 명확해지고, 그 범위 바깥—즉 인간 리뷰어가 실제로 봐야 할 것—이 자연스럽게 정의된다. 거꾸로, 인간 리뷰 역할을 먼저 재정의하면 CI 게이트가 커버해야 할 범위와 모델 선택 기준도 따라온다.
팀이 지금 당장 할 수 있는 것은 세 가지다. 첫째, 태스크 분류 테이블을 만들고 모델 라우팅 기준을 팀 문서에 명문화한다. 둘째, 에이전트 평가를 CI 파이프라인에 연결하고 non-zero exit으로 머지를 블로킹한다—스코어와 트레이스를 함께. 셋째, 인간 리뷰어가 검토할 항목 체크리스트를 자동화가 커버하는 것과 명시적으로 분리해서 정의한다.
전망: AI-First 파이프라인의 다음 단계
모델 성능 격차는 좁아지고 있다. 1~2년 내에 Sonnet급이 오늘의 Opus급 성능을 낼 가능성이 높다. 그러면 라우팅 테이블은 다시 써야 한다. 에이전트 평가 도구는 더 성숙해질 것이고, CI 게이트 구축 비용도 낮아진다. 리뷰 자동화는 더 깊어진다.
변하지 않는 것이 하나 있다. 파이프라인을 설계하는 것은 사람의 몫이라는 점이다. 어떤 태스크에 어떤 모델을 쓸지, 어떤 기준으로 배포를 막을지, 인간이 어떤 판단을 끝까지 쥐고 있을지—이 결정들은 AI가 대신 내려주지 않는다. AI-First 팀의 실력은 도구의 수가 아니라 이 설계의 명확성으로 측정된다.