코크로치랩스가 코딩 에이전트를 병원처럼 운영해 Db2 이전을 이틀에 끝냈다
코크로치랩스가 CockroachDB 마이그레이션 도구인 MOLT에 코딩 에이전트 파이프라인을 붙여 5개월간 운영한 결과를 공개했다. 파이프라인은 '가르치는 병원(teaching hospital)'을 본떠 만들었고 이름도 그에 맞춰 MOLT Sinai다. 이슈는 환자로, 머지는 퇴원으로 취급하며, 진료과에 해당하는 역할별 에이전트가 단계마다 계획과 리뷰, 검증을 강제한다. 5개월 동안 이 파이프라인이 처리한 코드는 100만 줄을 넘었고, 되돌린 횟수는 모두 7번이었다.
가장 눈에 띄는 사례는 IBM Db2 지원 추가다. 4월의 어느 수요일 저녁에 시작해 금요일 오후에 끝났다. Db2는 상용 관계형 데이터베이스 가운데 가장 오래된 축에 속하고 SQL 방언과 타입 체계가 복잡하며 자체 와이어 프로토콜을 쓴다. 그래서 스키마 변환기, 행을 끌어와 적재하는 Fetch 경로, 적재 후 비교하는 Verify 경로, vendoring한 ANTLR 문법, CI용 도커 이미지, 1만 줄이 넘는 테스트 픽스처가 새로 필요했다. 사람이 작성한 코드는 한 줄도 없었고 토큰 비용은 4,172달러였다. 2024년 Oracle 지원을 추가할 때 9개월과 약 16만 달러의 엔지니어링 시간이 들었다는 점을 감안하면 164배 빠르고 38배 저렴한 셈이다.
작업은 GitHub 이슈 하나에서 출발했다. 계획 담당 에이전트가 이를 한 번에 다루기엔 너무 크다고 판단해 15개의 하위 이슈와 명시적 의존성 그래프로 쪼갰다. 기반 작업, 타입 시스템, 행 반복자, Fetch, Verify, Convert, CI, 테스트 데이터 순이다. 그중 두 개는 다시 너무 크다고 판단돼 한 번 더 분해됐다. 작업 도중 에이전트들은 스스로를 상대로 픽스처 누락, 타입 매핑 버그, 격리 수준 수정 같은 이슈를 십여 개 더 등록했다. 부모 이슈가 닫힐 때까지 하위 이슈 32개가 열렸고 PR 27개가 머지됐으며, 리뷰에서 작업이 55번 반려됐고 9건이 에스컬레이션됐다. 그중 2건은 사람에게 올라갔다. 테스트 커버리지는 가장 잘 테스트된 방언인 PostgreSQL 기준과 동등한 수준이었다.
배경에는 품질에 대한 문제의식이 있다. 에이전트가 코드를 빠르게 찍어내는 것 자체는 더 이상 특별하지 않다. 업계에서는 처리량을 앞세운 소프트웨어 팩토리 실험이 잇따르고 있다. 하지만 마이그레이션 도구의 자잘한 버그 하나가 고객 데이터를 망가뜨릴 수 있는 상황에서 중요한 질문은 '시간당 PR이 몇 개인가'가 아니라 '우리가 직접 머지하기 부끄러운 PR이 몇 개인가'였다. 그래서 처리량 최적화 스웜 대신, 능력이 고르지 않은 인력이 고위험 작업을 수행하고 인계와 2차 소견이 의무화된, 인계가 부실할 때 무슨 일이 벌어지는지에 대한 연구가 축적된 모델을 골랐다. 그것이 병원이다.
역할 구성은 실제 병원 조직을 닮았다. 트리아지 간호사, 펠로우, 리뷰 담당 어텐딩, 퇴원 간호사가 핵심 흐름을 맡고, 30분마다 돌며 막힌 환자를 찾는 차지 너스, main이 깨지면 모든 워크플로를 잠그는 감염 관리, 주간 프로세스 리뷰와 사후 회의를 여는 안전 부서, 새 작업을 제안하는 연구 부서가 주변을 감싼다. 사람 책임자는 Chiefs of Medicine에 해당한다.
구현은 전부 GitHub Actions 위에서 돌아간다. 환자의 상태는 이슈 라벨과 진행 기록용 스크래치 파일에 담긴다. 각 단계는 해당 라벨이 붙으면 시작하는 워크플로이고, 끝나면 다음 라벨을 써서 다음 단계를 깨운다. 계획이 거부되면 작업 검토 단계로, CI가 실패하거나 변경 요청이 들어오면 치료 단계로 되돌아간다. 에이전트는 역할별 프롬프트를 받아 움직이고, 이슈 차트 파일에 <!-- SINAI:TREATMENT_PLAN --> 같은 센티넬을 포함한 구조화된 노트를 남겨 뒤에 오는 에이전트가 파싱할 수 있게 한다. 안전장치의 뼈대는 두 가지 규칙이다. 계획 없이는 코드를 쓰지 않고, 리뷰 없는 계획은 통과시키지 않는다.
개발자 입장에서 이 사례가 주는 힌트는 화려한 오케스트레이션 프레임워크가 아니라 상태 관리 방식이다. 이슈 라벨을 상태 머신으로 쓰고 GitHub Actions를 단계 실행기로 쓰는 구조는 기존 저장소와 CI 위에 그대로 얹을 수 있다. 또 하나는 게이트의 위치다. 코드 생성 이후가 아니라 계획 단계에서 리뷰를 강제한 것이 회귀를 줄이는 데 결정적이었다. 데이터 마이그레이션처럼 실패 비용이 큰 작업을 에이전트에 맡기려는 팀이라면 참고할 만한 패턴이다.
다만 저자들 스스로 이 구조가 스웜보다 저렴하지도, 단일 에이전트보다 단순하지도 않다고 인정한다. 병원 메타포를 따른 대가로 관료주의와 대기 시간, 비용 같은 익숙한 단점도 함께 따라온다. 그럼에도 데이터베이스를 만드는 입장에서는 품질을 위해 지불할 만한 비용이라는 것이 이들의 판단이다.