코드를 작성하는 속도는 더 이상 병목이 아니다. dev.to에 올라온 두 편의 글—Shipeasy 팀의 빌드 자동 수정 사례와 'Writing the code is no longer the bottleneck'—을 나란히 읽으면 같은 결론에 도달한다. 에이전트가 코드를 뽑는 문제는 사실상 해결됐다. 이제 팀 리드가 진짜 설계해야 할 것은 그 코드가 올바른지 검증하는 파이프라인과 그 검증 비용을 통제하는 구조다.
세 가지를 순서대로 짚는다. 자동 수정 에이전트 연결, 평가 파이프라인 내재화, 달러 상한 게이트 설치. 각각은 독립된 과제처럼 보이지만 실제로는 하나의 설계 흐름이다.
첫 번째: 빌드 실패를 사람이 아니라 파이프라인이 먼저 받게 하라
Shipeasy 팀이 공유한 구조는 단순하다. Cloud Build가 실패하는 순간 Pub/Sub 이벤트가 올라오고, 필터링된 push subscription이 Rails 컨트롤러를 깨우고, 컨트롤러가 Shipeasy ops 큐에 버그 티켓을 자동으로 생성한다. 거기서부터는 AI 에이전트가 로그를 읽고 패치를 작성해 PR을 연다. 엔지니어가 할 일은 이미 열려 있는 PR을 리뷰하고 머지하는 것뿐이다.
인상적인 건 구현 분량이 아니라 설계 철학이다. 이 팀은 새 인프라를 추가하지 않았다. 이벤트는 이미 Pub/Sub 버스에 올라오고 있었다. 서비스는 이미 webhook을 받고 있었다. 추가된 건 중간을 잇는 약 40줄의 Ruby 글루 코드뿐이다. 실제 픽스 사례도 명확하다. NODE_OPTIONS의 heap 크기를 4096에서 8192로 올리는 한 줄짜리 패치를, 백엔드를 전혀 모르는 팀원이 컨텍스트 없이 머지했다. 누군가 콘솔을 들여다보다 빨간 불을 발견하고, 로그를 파고, 수동으로 고치는 사이클은 사라졌다.
팀 리드 입장에서 이 사례가 던지는 질문은 하나다. 우리 팀의 빌드 실패는 지금 누가 먼저 받고 있나? 슬랙 알림을 보다가 누군가 발견하는 구조라면, 그 '발견 시간'과 '수동 수리 시간'의 합이 지금 팀에 부과되는 숨은 세금이다. 이 세금을 파이프라인으로 치환하는 것이 첫 번째 설계 과제다.
두 번째: '코드가 맞다'와 '시스템이 맞다'는 다른 검증이다
'Writing the code is no longer the bottleneck' 글의 핵심 사례는 뼈아프다. 시니어 엔지니어가 AI 워크플로우로 검색 인덱싱 파이프라인을 하루 만에 리팩터링했다. 코드는 깔끔했고, 팀 패턴을 따랐고, 유닛 테스트는 모두 초록이었다. 그런데 스테이징에 올렸더니 영국 리전의 검색 결과 관련도가 미묘하게 틀어졌다. 원인을 찾는 데 6일이 걸렸다. 레거시 주문 관리 모놀리스에 수년간 쌓인 VAT 포함 가격 처리 방식의 암묵적 규칙을, 생성된 코드가 알 방법이 없었던 것이다.
이 팀은 코딩에서 16시간을 절약했고 인시던트 채널에서 60시간을 썼다. 글쓴이 본인도 고백한다. 직전 주에 에이전트로 만든 내부 도구 데모를 보고 구현 속도에 감탄한 나머지 테스트 플랜도 보지 않고 파일럿을 승인했다고. "나는 파이어호스로 미검증 코드를 쏟아내는 걸 비판하고 있었는데, 노즐을 쥔 건 나였다."
여기서 팀 리드가 설계해야 할 것은 단순히 '테스트를 더 많이 쓰자'가 아니다. 문제는 검증의 레이어다. 유닛 테스트는 코드 수준의 정합성을 확인한다. 시스템 수준의 논리적 정합성, 특히 레거시 시스템과의 암묵적 계약은 전혀 다른 도구가 필요하다. 구체적으로 설계해야 할 것은 세 가지다.
섀도 배포(Shadow Deploy): AI가 생성한 코드를 실 트래픽에 바로 내보내지 않고, 프로덕션과 병렬로 실행해 결과를 비교하는 구조. 크래시 없이 조용히 틀어지는 논리적 드리프트는 섀도 배포만이 잡을 수 있다.
회귀 케이스 라이브러리: AI가 코드를 생성할 때마다 팀의 도메인 지식이 담긴 회귀 케이스를 자동으로 실행하는 파이프라인. 특히 레거시 시스템과 접점이 있는 경계 조건들—세금 계산, 화폐 단위, 지역별 비즈니스 룰—은 케이스화해서 CI에 박아둬야 한다.
가시성 레이어: 대시보드가 초록이어도 '관련도가 틀어지는' 것을 감지할 수 있는 비즈니스 메트릭 모니터링. 기술적 정상과 비즈니스적 정상은 다른 신호다.
이 세 가지가 없는 상태에서 AI 에이전트 생성 코드를 빠르게 머지하는 건, 속도를 높이는 게 아니라 인시던트를 예약하는 것이다.
세 번째: 퍼센트 게이트가 아니라 달러 상한을 CI에 박아라
AI 에이전트가 CI/CD에 깊이 들어올수록 반드시 따라오는 문제가 있다. LLM 호출 비용이다. dev.to에 올라온 또 다른 글 'Gate your CI on a dollar ceiling'은 이 문제를 실용적으로 짚는다. 대부분의 팀이 비용 게이트를 '이전 PR 대비 X% 초과 시 차단'으로 설계한다. 이건 개발자의 질문—"내가 더 나쁘게 만들었나?"—에 답하는 게이트다. 재무팀의 질문—"이번 달 청구서가 얼마 나와?"—에는 답하지 못한다.
퍼센트는 조용히 복리로 쌓인다. PR마다 3%씩 올라가는 워크플로우는 퍼센트 게이트를 매번 통과하면서 절대 비용은 선형으로 늘어난다. 그리고 어느 날 갑자기 인보이스가 터진다. 달러 게이트는 이걸 잡는다. 단일 실행 기준 최대 $N을 넘으면 빌드를 차단하는 구조다.
달러 게이트를 실제로 쓸 수 있게 만들려면 세 가지 조건이 필요하다. 첫째, 토큰 수가 아니라 실제 달러로 측정해야 한다. Opus 출력 토큰과 캐시된 Haiku 입력 토큰은 가격이 100배 차이다. 토큰 수만 보고 "2M 토큰 이하"라고 설정해봐야 아무도 실제 비용을 계산하지 않는다. 둘째, 워크플로우별로 상한을 다르게 설정해야 한다. 야간 전체 레포 감사와 PR당 린트 에이전트는 정당한 비용 구조 자체가 다르다. 글로벌 상한 하나로는 작은 잡은 너무 헐렁하고 큰 잡은 너무 빡빡해진다. 셋째, 헤드룸을 보여줘야 한다. "$0.50 상한 중 $0.43 사용—86%"를 매 실행마다 로그에 남기는 구조가 있어야, 한계에 부딪혀서 빌드가 깨지기 전에 상한을 조정할 수 있다. 그냥 차단만 하는 게이트는 팀이 결국 뜯어낸다.
이 글이 제안하는 mental model은 명확하다. 퍼센트 게이트와 달러 게이트는 경쟁 관계가 아니라 다른 실패 모드를 잡는 두 개의 독립된 방어선이다. 둘 다 CI에 들어가야 한다.
세 가지를 설계하지 않으면 생기는 일
자동 수정 에이전트가 없으면, 빌드 실패는 여전히 사람이 발견하고 사람이 고치는 큐에 쌓인다. 에이전트가 만들어내는 속도 이득이 수동 트리아지 비용으로 상쇄된다.
평가 파이프라인이 없으면, 에이전트가 뽑은 코드는 초록 유닛 테스트와 함께 머지되고 조용히 논리적으로 틀린 채로 운영에 들어간다. 6일짜리 인시던트는 예약된 것이나 다름없다.
달러 상한 게이트가 없으면, LLM 호출이 CI에 깊이 박힐수록 비용은 복리로 증가하고 재무팀이 묻는 순간 답을 못 한다.
세 가지는 서로 다른 위험을 막는다. 자동 수정은 수동 트리아지 비용을, 평가 파이프라인은 논리적 드리프트 리스크를, 달러 게이트는 비용 통제 불능을 막는다. 에이전트를 CI/CD에 붙이는 순간, 이 세 가지는 선택이 아니라 설계 체크리스트가 된다.
코드를 쓰는 속도가 올라간 팀이 다음으로 해야 할 일은 '더 많은 에이전트를 붙이는 것'이 아니다. 에이전트가 뽑은 결과물이 올바른지, 시스템과 논리적으로 정합한지, 그 검증 자체에 드는 비용을 감당할 수 있는지—이 세 질문에 파이프라인으로 답하는 것이다.