환자처럼 버그를 치료하고 의료팀처럼 에이전트를 코딩하며 보낸 5개월

4월의 수요일 저녁부터 금요일 오후 사이에, Cockroach Labs가 데이터베이스를 CockroachDB로 마이그레이션하는 데 사용하는 도구인 __MOLT__는 IBM Db2 소스에서 마이그레이션할 수 있는 기능을 갖추게 되었습니다.

Db2는 최초의 상용 관계형 데이터베이스 중 하나로, 풍부한 SQL 방언(dialect), 복잡한 타입 시스템(type system), 그리고 네이티브 와이어 프로토콜(wire protocol)을 가지고 있습니다. Db2를 MOLT에 지원한다는 것은 새로운 스키마 컨버터(schema converter), 행을 가져와 CockroachDB로 넣기 위한 새로운 Fetch 경로, 로드된 후 비교하기 위한 새로운 Verify 경로, 패키징된 ANTLR 문법(grammar), CI용 Docker 이미지, 그리고 1만 개가 넘는 테스트 고정 장치(test fixtures)를 의미했습니다. 저희가 2024년에 MOLT 도구에 Oracle 지원을 추가했을 때, 동등한 작업에는 9개월이 걸렸고 엔지니어링 시간으로 약 $160K의 비용이 들었습니다.

Db2는 2일도 채 걸리지 않았으며, 인간은 코드를 작성하지 않았습니다. 토큰 청구액은 $4172였는데, 이는 164배 더 빠르고 38배 더 저렴했습니다.

모든 것은 단 하나의 GitHub 이슈로 시작되었습니다. 이 이슈에는 요청 사항이 기술되어 있었습니다:

그러자 계획 에이전트(planning agent)가 이를 읽고, 한 번에 처리하기에는 너무 크다고 판단하여 명시적인 의존성 그래프(dependency graph)를 가진 15개의 하위 이슈로 분해했습니다. 먼저 기반을 다지고, 다음으로 타입 시스템, 그 다음 행 반복자(row iterator), 그리고 Fetch, Verify, Convert, CI, 테스트 데이터 순이었습니다. 두 개의 하위 이슈는 자체 작업 과정에서 너무 크다고 판단되어 다시 분해되었습니다. 이 과정에서 에이전트들은 자신들의 작업에 대해 또 다른 12개의 이슈를 제기했습니다: 고정 장치 누락(fixture gaps), 타입 매핑 버그(type-mapping bug), 그리고 격리 수준 수정(isolation-level fix) 등이었습니다. 부모 이슈가 닫힐 무렵, 그 아래로 32개의 하위 이슈가 열렸고, 27개의 풀 리퀘스트(pull requests)가 병합되었으며, 리뷰어들은 작업을 55번 되돌려 보냈고, 9개의 이슈는 에스컬레이션되어 그중 2개가 인간에게 전달되었습니다. PostgreSQL(저희가 가장 많이 테스트한 방언)을 기준으로 측정한 테스트 커버리지(test coverage)는 동등했습니다.

하지만 이 모든 것이 어떻게 이루어졌을까요? 무엇이 이것을 추진했고, 더 중요하게는 결과물이 높은 품질임을 보장하는 것은 무엇이었을까요? Db2 지원 문제를 제기하기 전에, 우리는 'MOLT Sinai'라고 부르는 코딩 병원을 먼저 구축했습니다. MOLT은 CockroachDB의 마이그레이션 도구 세트 이름이며, 파이프라인을 병원에 모델링하기로 결정하자마자, MOLT Sinai는 거부할 수 없는 좋은 합성어였습니다. 왜냐하면 Mount Sinai는 우리가 살고 있는 토론토와 뉴욕 양쪽에 모두 있는 저명한 교육 병원이기 때문입니다. 그 이름은 붙었고, 어휘도 마찬가지였습니다. 이슈(Issues)는 환자이고, 머지(Merging)는 퇴원입니다. 담당하는 인간들은 의학 과장들(Chiefs of Medicine)입니다.

에이전트들이 많은 코드를 빠르게 작성하는 것은 이 이야기에만 국한된 것이 아닙니다. 소프트웨어 공장들이 산업 전반에 걸쳐 생겨나고 있기 때문입니다 (OpenAI의 __이곳__처럼). 우리 사례에서 독특한 점은 그 에이전트들과 메인 브랜치 사이에 무엇이 있었는지, 왜 그것을 병원처럼 보이도록 구축했는지, 그리고 5개월 동안 실제 작업에 적용했을 때 무슨 일이 벌어졌는지입니다.

교육 병원이 필요한 이유

Copy Icon

코딩 에이전트들의 문제는 그들이 코드를 작성할 능력이 충분함에도 불구하고, 잘 테스트되고 유지보수가 가능하며 원하는 범위 내의 프로덕션급(production-grade) 코드를 생성하는 것을 신뢰하기 어렵다는 것입니다. 에이전트를 실행하는 것은 비교적 저렴하지만, 그 코드가 고객의 손에 들어갈 것이라면 이는 별다른 위안이 되지 못합니다. 우리는 에이전트가 실행되는 시간이 더 오래 걸리더라도 (심지어 10배 더 오래 걸리더라도) CockroachDB로 고객 마이그레이션 과정에서 잘못된 데이터가 전달되는 것보다는 훨씬 나을 것입니다. 속도도 중요하지만, 품질이 훨씬, 훨씬 더 중요합니다.

지난 1년간 에이전트 코딩을 자동화하려는 여러 시도가 있었으며, 그중 다수는 처리량(throughput)에 최적화되어 있었습니다. 예를 들어, __Gas Town__은 병합 처리 계층(merge-handling layer)을 갖추고 코드베이스에 여러 에이전트를 병렬로 실행하여 충돌을 해결합니다. 이는 코드가 얼마나 빨리 작성되는지가 병목 현상일 때 좋은 설계입니다. 그리고 Cursor의 실험 중에는 SQLite를 너무 빠르게 재구축해서 변경량을 처리하기 위해 자체 버전 관리 시스템을 작성해야 했던 사례가 있습니다. 흥미로운 실험이지만, 분명히 사용자에게 품질 좋은 데이터베이스 코드를 배포하도록 설계된 것은 아닙니다. 대부분의 초기 에이전트 자동화 실험에서 주된 동기는 속도였습니다.

저희의 동기는 달랐습니다. 저희는 __분산 SQL 데이터베이스(distributed SQL database)__와 해당 데이터베이스로 워크로드를 마이그레이션하기 위한 일련의 도구를 구축하고 있습니다. 마이그레이션 도구의 사소한 버그가 모든 것보다 정확성을 유지해야 하는 데이터베이스로 데이터를 전송하는 과정에서 누군가의 데이터를 손상시킬 수 있습니다. 그 결과, 저희가 신경 쓴 질문은 '시간당 몇 개의 PR(Pull Request)을 처리할 수 있는가?'가 아니라, '이 PR들 중 우리 스스로 병합했다가 창피함을 느낄 만한 것은 얼마나 될까?'였습니다. 이렇게 관점을 재정립하자, 처리량에 최적화된 에이전트 군집은 좋은 모델이 아니라는 것이 명확해졌습니다.

그래서 저희는 역량이 고르지 않은 직원들이 수행하는 높은 위험도의 작업을 관리하고, 필수적인 인계(handoffs)와 필수적인 제2의 의견(second opinions), 그리고 인계가 부실할 때 무엇이 잘못되는지에 대한 문헌을 다루는 모델을 찾았습니다. 그리고 저희는 교육 병원(teaching hospital)에 도착했습니다.

이 비유를 통해 다음과 같은 역할들을 얻게 되었습니다:

핵심 주변에는 병원에 한 번이라도 있었거나 (또는 영화 <피트>(The Pitt)를 본 적이 있다면) 기대할 수 있는 다른 행위자들이 있습니다. 30분마다 순회하며 고립된 환자를 찾는 담당 간호사(Charge Nurse), 주요 장비가 고장 날 경우 건물 내 모든 워크플로우를 잠글 수 있는 감염 통제 에이전트(Infection Control agent), 매주 프로세스 검토를 작성하고 사고 후 회의를 진행하는 안전 부서(Safety Department), 그리고 새로운 작업을 제안하는 연구 부서(Research Department) 등이 있습니다.

우리는 이것이 스웜(swarm)보다 저렴하거나 단일 에이전트보다 간단하다고 주장하지는 않습니다. 하지만 이는 둘 중 어느 것보다 더 높은 품질의 제품을 만들어냅니다. 데이터베이스 비즈니스에 종사하는 경우, 여러분은 그 품질에 비용을 지불할 준비가 되어 있습니다. 아래에서 보듯이, 이것은 또한 교육 병원의 유감스러운 측면(관료주의, 대기 시간, 그리고 비용) 일부를 가져오지만, 우리는 그것이 가치 있는 트레이드오프라고 믿습니다.

구축 방식

Copy Icon

병원 내 모든 것은 GitHub Actions으로 운영됩니다. 모든 환자의 상태는 이슈의 레이블뿐만 아니라 병원이 각 환자의 진행 상황을 추적하기 위해 생성하는 일부 임시 파일에 존재합니다.

각 단계는 “label in”이 해당 이슈에 도달할 때 시작되는 GitHub 워크플로우입니다. 에이전트가 작업을 완료하면 “label out”을 작성하고, 이 레이블이 다음 단계의 “label in”이 됩니다. 점선 화살표는 작업을 되돌립니다: 작업 검토를 위한 거부된 계획, 빨간 CI 실행 또는 요청된 치료 변경 사항, 그리고 최고 책임자(Chief)에게까지 멈춘 단계가 있습니다.

표시되지 않은 내용: 네 개의 부서는 자체 일정에 따라 이 흐름 외부에서 운영됩니다. 담당 간호사(Charge Nurse)는 중단된 단계를 재실행하고, 감염 통제팀(Infection Control)은 주요 시설이 고장 날 때 병원을 폐쇄하며, 연구 및 안전 부서(Research and Safety)는 새로운 이슈와 정책 PR을 제출하여, 다른 모든 환자처럼 최고 책임자를 통해 들어옵니다.

레이블을 적용하는 것은 GitHub 워크플로우를 실행하고 역할별 프롬프트를 로드하여 에이전트가 병원의 직원처럼 행동하게 합니다. 작업 완료 후, 에이전트는 해당 이슈의 차트가 포함된 파일에 구조화된 메모를 추가하고 흐름에서 다음 레이블을 적용합니다. 이 메모는 나중에 다른 에이전트가 찾고 구문 분석할 수 있도록 <!-- SINAI:TREATMENT_PLAN -->과 같은 신호(sentinel)를 담고 있습니다.

몇 가지 기본적인 병원 규칙들은 스킬에 인코딩되어 대부분의 안전성을 제공합니다:

계획 없이 코딩하지 않고, 검토 없는 계획도 없다. Fellow가 무엇이든 고치기 전에, 먼저 문제를 재현하고(reproduce), 감별 진단(differential diagnosis)을 수행하며(병원 용어를 사용), 이를 좁히는 목표 조사(targeted investigation)를 실행하고, 치료 계획을 게시해야 합니다. 이 계획에는 진단, 변경할 파일, 추가할 테스트, 위험 요소, 미해결 질문 등이 포함됩니다. 검토 담당 의사(Review Attending)라는 다른 에이전트 인스턴스가 오류를 수정하는 것보다는 결함을 찾는 것에 초점을 맞춘 프롬프트를 실행하며 이 계획을 읽고 승인하거나 거부합니다. 그래야만 치료가 시작됩니다. 우리는 이 게이트(gate)를 추가했는데, 잘못된 수정을 자신 있게 구현하는 에이전트가 자신의 계획을 확인하기 위해 멈추는 것보다 훨씬 더 많은 시간과 토큰을 낭비하기 때문입니다.

즉흥적으로 행동하지 마십시오. 치료 도중에 범위가 변경되면, Fellow는 멈추고 수정된 계획을 게시한 다음 계획 검토 단계로 돌아갑니다. 스킬 파일의 지침은 두 단어입니다:

절대 허둥대지 마세요(Never flail). 동료(Fellow)가 막히면, 더 열심히 하려고 노력하지 않습니다. 대신 I-PASS (Illness severity, Patient summary, Action list, Situation awareness, Synthesis) 인계서를 작성합니다. 이는 교육 병원에서 직접 차용한 구조화된 형식이며, 이후 전공의(Attending)에게 보고됩니다. 받는 에이전트는 작업을 시작하기 전에 이 인계서 내용을 자신이 이해한 바를 되돌려 적어야 합니다. 병원에서 I-PASS에 대한 연구는 의사나 간호사가 환자 정보를 표준화된 방식으로 기록할 경우 교대 근무 중 부작용 발생률을 50% 감소시킨다고 보고합니다. 저희 에이전트들도 동일한 프로토콜을 따릅니다.

퇴원 간호사가 검토자를 감사(audits)합니다. 병합(merge) 직전의 마지막 관문은 코드를 재검토하지 않습니다. 대신, 검토가 제대로 이루어졌는지 확인합니다: 승인 기록이 있는지, 검토 템플릿이 작성되었는지, 해결되지 않은 스레드가 없는지, CI가 녹색인지, 커밋 기록이 깨끗한지 등을 확인합니다. 자신이 무엇을 확인했는지 정확히 보여주는 체크리스트를 게시하며, 만약 어떤 항목도 확인할 수 없다면, 해당 항목에 빈칸으로 남기고 주석을 달아 퇴원(discharge) 처리가 실패합니다. 이러한 규칙은 통제권을 에이전트에게 넘길 때, 그들이 지시받은 대로 행동하는지 확인하고 싶기 때문에 존재하며, 때로는 그렇지 않을 수도 있습니다.

최고 책임자(Chief)를 괴롭히기 전에 선례를 확인하세요. 인간 최고 책임자가 내리는 일반화 가능한 모든 결정은 추가 불가 로그(append-only precedent log)에 기록됩니다. 에스컬레이션하려는 에이전트는 먼저 이 로그를 읽어야 하며, 만약 선례가 적용된다면, 에스컬레이션하는 대신 그 선례를 따르고 인용합니다. 선례는 오직 인간만이 만들 수 있습니다. 5개월 동안, 이는 에이전트가 최고 책임자에게 에스컬레이션하는 빈도를 줄였습니다.

배포된 내용

Copy Icon

저희가 MOLT Sinai에서 작업하기 시작했을 때, MOLT 도구가 빌드되는 저장소의 미러를 만들었습니다. 이 미러는 저희가 병원 모델의 효능을 테스트할 수 있는 시험장 역할을 했습니다. 4월 21일부터 9월 11일 사이에 그 저장소에서 발생한 일들은 다음과 같습니다:

5개월이 채 되지 않아 병원 파이프라인은 백만 줄 이상의 코드를 처리했으며, 이 코드들은 에이전트가 자신 있게 검토할 수 있을 만큼 작은 변경 단위로 분할되었습니다.

위 표에서 흥미로운 숫자를 하나 발견했을 수도 있습니다. 바로 1299입니다. 저장소에 접수된 문제 중 거의 절반은 병원이 자체적으로 생성한 것이었습니다. 예를 들어, decomposition children(분해 자녀), follow-ups the Fellow scoped out of a plan(펠로우가 계획에서 제외한 후속 조치), Research Department의 제안, Safety Department의 시정 조치 등이 그것입니다. 파이프라인은 스스로 백로그를 생성합니다. 인간이 무엇을 수용할지 결정하지만, 두 번째 달부터는 인간이 작업의 주요 원천이 아니게 되었습니다.

Db2 지원이 병원을 통해 처리한 첫 번째 대규모 기능이었지만, 이는 단지 실험에 불과했습니다. 자율 운영 첫 주가 지난 후, 우리는 '인간 승인 모드(human approval mode)'를 활성화했는데, 이 모드는 모든 머지(merge)가 인간의 검토 과정을 거치도록 요구합니다. 오직 이 모드에서만 코드가 고객에게 배포할 만큼 충분히 높은 품질임을 확신할 수 있었습니다. 병원이 이러한 추가적인 안전 계층을 갖게 되자, 우리는 병원이 진정으로 만들어진 목적에 맞는 작업, 즉 Postgres에서 CockroachDB로의 전체 마이그레이션을 사용자에게 안내하는 AI 기반 도구인 __Migration Assistant__를 구축하는 데 착수했습니다. 이 도구는 스키마 변환(schema conversion), 데이터 로드 및 검증(data load and verification), 루틴 변환(routine conversion) 등을 포함합니다. Migration Assistant는 현재 Postgres 마이그레이션에 대해 미리 보기(preview)로 제공되고 있으며, 병원 직원들이 거의 전적으로 작성했습니다.

비용

Copy Icon

MOLT Sinai를 운영하기 시작한 4월 이후, 이 시스템은 Claude 토큰으로 135,000달러가 조금 넘는 금액을 소비했으며, 이는 평균 환자(즉, GitHub 이슈)당 약 84달러에 해당합니다. 이슈들은 일반적으로 병원에서 하루에서 이틀 정도 머무르며, 종종 인간 검토자를 기다리는 시간에 의해 지배됩니다. LLM 모델의 관점에서 볼 때, 병원은 모델이 발전함에 따라 진화해 왔습니다.