Cockroach Labs의 시니어 엔지니어 Adam Storm과 Rafi Shamim은 2026년 4월부터 다섯 달 동안 코딩 에이전트 여러 개를 교육 병원처럼 운영했어요. 회사 전체가 바꾼 개발 방식이 아니라, 두 사람이 따로 시작한 실험이에요. 이슈는 환자, 코드 병합은 퇴원, 사람은 '내과 과장(Chief of Medicine)'이라고 불렀어요. 두 사람은 밤새 에이전트들을 돌리고 아침에 결과를 검토해요. 원문은 “A full day of meetings can now lead to 10 high quality merged PRs.”라고 적었어요. 회의로 하루를 다 써도 품질 좋은 코드 변경(PR) 10개를 합칠 수 있게 됐다는 뜻이에요. 그런데 두 사람은 같은 글에 「가르치지 않는 교육 병원을 만들었다(We built a teaching hospital that doesn't really teach)」라는 절을 따로 두고, 이 방식이 신입에게는 잘 맞지 않는다고 적었어요.
두 사람은 AI 에이전트들에게 계획·구현·검토를 나눠 맡기고, 계획을 검토받기 전에는 코드를 쓰지 못하게 했어요
두 사람이 만든 파이프라인의 이름은 MOLT Sinai예요. MOLT는 이 회사가 파는 데이터베이스 이전 도구이고, Sinai는 그 도구를 개발하는 에이전트 병원이에요. 에이전트 역할은 15개이고, 모두 GitHub Actions와 이슈 라벨로 움직여요. 이슈 하나는 다음 순서를 거쳐요.
- Triage Nurse
들어온 이슈를 분류해요. - Fellow
문제를 진단하고 계획을 쓴 뒤, 승인된 계획대로 구현해요. - Review Attending
Fellow와는 별개로 띄운 에이전트가 계획과 코드를 검토하고, 부족하면 일을 Fellow에게 돌려보내요. - Discharge Nurse
코드가 아니라, 검토가 절차대로 이뤄졌는지를 감사해요. - Chief of Medicine(사람)
에이전트끼리 풀지 못한 일을 받아 결정하고, 그 결정을 다음 판단의 선례로 남겨요.
규칙의 중심은 “No code before a plan, no plan without review.”예요. 계획 없이는 코드를 쓰지 않고, 검토받지 않은 계획으로는 구현하지 않는다는 뜻이에요. 에이전트에게는 “Don't improvise.”라고 적어 두었고, 테스트를 끄거나 약하게 바꾸는 일은 금지했어요. 검토자는 변경을 뺀 상태에서 새 테스트가 실패하는지부터 확인하고, 변경이 1,000줄을 넘으면 나눠요.
이 설계가 실제로 효과를 내는지는 아직 확인되지 않았어요. Storm은 Hacker News에서 작성자와 검토자를 나눈 설계를 두고 “we haven't validated that it does”라고 답했고, 구성 요소를 하나씩 빼 보는 비교 실험(ablation)도 하지 않았다고 했어요. 이 일이 두 사람의 “side project”라는 점도 밝혔어요.
그렇게 새 데이터베이스 지원을 붙이는 일을 에이전트들이 이틀에 끝냈고, 그동안 에이전트끼리 55번 퇴짜를 놓으며 사람에게는 두 번만 물었어요
2026년 4월의 어느 수요일 저녁, 두 사람은 MOLT에 IBM Db2 데이터베이스 지원을 붙이는 이슈 하나(“Support Db2 LUW for convert/fetch/verify #526”)를 병원에 넣었어요. 계획을 쓰는 Fellow는 이 이슈를 하위 이슈 15개로 나누고, 무엇을 먼저 만들지 순서를 짰어요. 금요일 오후에 일이 끝났을 때 하위 이슈는 32개로 늘어 있었고, PR 27개가 합쳐졌어요.
그사이 Review Attending은 Fellow의 일을 55번 돌려보냈어요. 에이전트끼리 풀지 못해 상위 단계로 넘긴 문제는 9건이었고, 그중 사람인 Chief까지 간 것은 2건이었어요. 사람이 쓴 코드는 없었고, 토큰 비용은 4,172달러였어요.
회사는 2024년에 같은 도구에 Oracle 지원을 붙인 일과 이 작업을 비교했어요. 원문은 그때 “the equivalent work took 9 months, and cost around $160K in engineering time”이라고 적고, 이번 작업을 “164x faster, and 38x cheaper”, 곧 164배 빠르고 38배 싸다고 표현했어요. 두 일은 서로 다른 데이터베이스를 지원하는 기능이고, 원문은 '같은 몫의 일'이라고만 했어요. VarOps 칼럼의 Rex Factor는 이 수치를 회사의 주장으로 읽어야 한다고 썼어요. 회사가 2024년의 사람 비용과 2026년의 토큰 비용을 맞대었고, Db2에 든 사람 시간은 셈에서 뺐으며, 빠르다고 한 쪽의 코드는 아직 검증 중이라는 이유예요. Hacker News의 tujux는 16만 달러를 9개월로, 4,172달러를 이틀로 나눠 하루 단가를 셈하면 사람 쪽은 약 600달러, 에이전트 쪽은 약 2,086달러라서 하루로 치면 에이전트가 더 비싸다고 했어요. thomascountz는 사람에게 드는 비용은 급여보다 크다고 반박했어요.
다만 처음 만든 Db2 코드는 사람이 검토하지 않아 아직 확인 중이고, 그 뒤로는 모든 코드 변경을 사람이 승인한 다음에 합쳤어요
저자들은 병원을 처음 시험하던 동안 “we weren't reviewing any of the code that the hospital wrote”라고 밝혔어요. 병원이 쓴 코드를 사람이 하나도 검토하지 않았다는 뜻이고, 그래서 Db2 코드의 정확성은 지금 확인하고 있어요. 테스트 커버리지는 회사에서 가장 잘 테스트된 PostgreSQL 지원과 같은 수준이라고 적었어요.
자율로 돌린 첫 주가 지난 뒤, 두 사람은 'human approval mode'를 켜서 에이전트가 낸 모든 코드 변경을 사람이 승인한 다음에야 합치게 했어요. 원문은 “It was only in this mode that we could be certain that the code was high enough quality to ship to customers.”라고 적었어요. 이 방식으로 돌릴 때만 고객에게 내보낼 만큼 품질이 좋다고 확신할 수 있었다는 말이에요. 원문은 Db2 작업을 사람이 코드를 검토하지 않던 첫 시험 때의 일로 적었지만, 그 시험이 자율로 돌린 첫 주와 같은 기간인지는 날짜가 공개 설명에 없어 알 수 없어요. 이때부터 에이전트가 코드를 쓰는 동안 사람이 맡는 일은 승인과 판단이 됐어요.
아래 운영 숫자는 실제 제품 저장소가 아니라, 두 사람이 따로 둔 사본 저장소(미러 저장소)에서 센 것이에요. 기간은 2026년 4월 21일부터 9월 11일까지이고, 이 기간에는 사람 승인 없이 자율로 돌린 첫 주도 들어 있어요.
| 항목 | 숫자 |
|---|---|
| 합친 코드 변경(PR) | 1,238개 |
| 합친 뒤 나중에 되돌린 변경 | 7개 |
| 처리를 마친 이슈 | 1,322개 |
| 에이전트가 다른 에이전트를 위해 만든 이슈 | 1,299개 |
| 사람 Chief에게 간 이슈 | 92건 |
| PR 크기 중앙값 | 527줄 추가 |
| 4월 이후 Claude 토큰 비용 | 13만 5천 달러 남짓 |
되돌린 7개는 이미 합친 변경을 나중에 취소한 숫자예요. 앞에서 본 55번은 합치기 전에 검토 단계에서 돌려보낸 횟수라서, 둘은 서로 다른 단계의 숫자예요.
빨라진 만큼 사람의 몫이 사라지지는 않았어요. 이슈는 보통 병원에 하루나 이틀 머무는데, 원문은 그 시간이 “often dominated by the time spent waiting on a human reviewer”라고 적었어요. 대부분 사람 검토자를 기다리는 시간이라는 뜻이에요. VarOps는 이 대목을 근거로, 코드를 만드는 비용은 줄었지만 그 코드를 믿는 비용은 사람의 검토로 옮겨 갔다고 봤어요. 저자들은 이슈 하나에 평균 약 84달러가 들었다고 적었지만, 토큰 비용 13만 5천 달러를 어떤 이슈 수로 나눴는지는 밝히지 않았어요. VarOps는 표에 나온 이슈 1,322개나 PR 1,238개로 나누면 100달러가 넘는다고 지적했어요.
검토가 길어진 사례도 있었어요. 급하다고 표시된 한 줄 수정(이슈 1777)은 이틀 동안 재작업을 11번 거쳤어요. 주석 정리, PR 설명의 틀린 주장, 계획과의 작은 차이, 테스트 품질, 리베이스 두 번, 워크플로 실패 두 번, 사람 승인 단계가 차례로 걸렸어요. 두 사람은 그 뒤 재작업이 정해진 횟수를 넘으면 자동으로 멈추고 더 위 단계로 넘기는 장치를 만들었어요. 검토자가 매번 새로운 막히는 문제를 지적한 재작업이 4번 연달아 나오거나, 의미 있는 재작업이 모두 합쳐 6번이 되면 넘겨요. 다만 이 장치가 효과를 냈다는 데이터는 아직 없다고 적었어요.
이 방식은 경험으로 판단할 줄 아는 시니어에게 맞춰져 있어서, 판단을 아직 배우는 신입에게는 잘 맞지 않는다고 두 사람은 적었어요
저자들은 이 병원이 누구를 위해 만들어졌는지 숨기지 않았어요. 원문은 MOLT Sinai를 “exactly what you'd expect to see built by two senior engineers (with over 40 years of collective industry experience)”라고 소개해요. 경력을 합쳐 40년이 넘는 시니어 엔지니어 둘이 만들 법한 바로 그 구조라는 뜻이에요. 회의로 꽉 찬 날에도 PR 10개를 합칠 수 있다는 문장 바로 다음에 이 단락이 이어져요.
일정이 꽉 차 있지도 않고, 수십 년 경험으로 쌓은 소프트웨어 판단력도 아직 없는 신입은 어떨까요? 이 모델이 그들에게도 맞을까요? 짧게 말하면, 신입의 필요를 다 채우지는 못해요.
(But what about the new-grad who doesn't have a full calendar, the software engineering judgment that decades of experience buys...? How does the model work for them? In short, it doesn't fully meet their needs.)
이 구조에서 사람이 맡는 일은 Chief의 일이에요. 에이전트끼리 풀지 못한 92건을 받아 결정하고, 모든 병합을 승인하고, 다음 판단의 기준이 될 선례를 남겨요. 선례는 사람만 만들고, 에이전트는 Chief에게 문제를 올리기 전에 그 선례 기록부터 읽어요. 계획을 쓰고 구현하는 단계는 Fellow 에이전트가 맡아요. 원문이 신입에게 부족하다고 짚은 것은 바로 이 승인과 결정에 필요한 '경험으로 쌓은 판단'이에요.
Storm은 교육 병원이라는 비유에도 한계를 그었어요. 그는 Hacker News에서 “medical students learn to become doctors. Cheaper models never learn to become more capable models, so the metaphor is not apt.”라고 답했어요. 의대생은 의사가 되지만, 값싼 모델이 더 뛰어난 모델로 자라지는 않으니 비유가 딱 맞지는 않는다는 말이에요. 이 병원에서 배우며 자랄 수 있는 쪽은 에이전트가 아니라 사람이고, 지금 구조에는 사람이 판단을 연습할 자리가 Chief밖에 없어요.
그래서 두 사람은 신입이 계획을 직접 쓰고, 그 계획을 에이전트 검토자 앞에서 변호하게 하는 기능을 만들고 있어요
두 사람은 사람이 분류된 이슈를 가져가 계획을 직접 쓰고, 그 계획을 병원의 에이전트들에게 검토받는 기능을 “currently working on”, 곧 지금 만드는 중이라고 적었어요. 지금 Fellow 에이전트가 맡는 계획 쓰기를 사람이 대신 맡고, 검토는 그대로 Review Attending 같은 에이전트 검토자가 하는 구도예요. 검토하는 동안 사람은 자기 결정을 변호하라는 요구를 받고, 다른 선택지를 생각해 보라는 반박을 받아요. 검토를 통과한 계획으로 코드를 직접 쓸 수도 있어요. 작은 수정은 손으로, 나머지는 대화형 LLM 세션으로 써요.
계획 검토 단계에서 중요한 문제를 잡은 사례도 원문에 있어요. 고객 로그에서 호스트 이름과 데이터베이스 이름을 지우는 수정이 있었어요. Review Attending은 코드가 아니라 그 수정의 계획을 검토하다가, 정보가 여전히 새어 나갈 수 있는 작은 틈을 찾았어요. 저자들은 코드 검토 단계였다면 이 틈을 잡을 가능성이 “highly unlikely”, 곧 매우 낮았다고 적었어요. 검토받은 계획이 반려되는 비율은 10% 미만이었어요. 원문의 사례로 보면, 중요한 판단은 코드를 쓰기 전 계획을 쓰고 검토하는 단계에서 나와요.
저자들은 신입용 기능의 목적을, 신입이 코드베이스를 익히고 구현의 장단점을 그때그때 저울질하며 그 결과로 나온 코드 검토에서 평가받게 하는 것이라고 적었어요. 다만 이 기능은 아직 결과가 없는 계획이에요. 신입 몇 명이 참여하는지, 무엇이 나아졌는지는 공개 설명에 없어요. 이 글은 마이그레이션 도구를 파는 회사의 엔지니어링 블로그이고 채용 링크가 붙어 있으며, 파이프라인은 Anthropic의 Claude 모델로 돌아가요. 원문은 “we'll still need people with sound judgement and critical thinking skills.”로 끝나요. 건전한 판단력과 비판적 사고력을 갖춘 사람은 여전히 필요하다는 말이에요.
신입은 코드를 직접 쓰고 검토받으며 판단을 익혀 왔어요. 코드 쓰기를 에이전트에게 맡기는 팀이라면, 그 연습 자리를 따로 만들지 않는 한 신입이 판단을 배울 곳이 없어요. 두 사람의 실험이 찾은 자리는 코드를 쓰기 전 단계예요. 계획을 직접 쓰고, 그 계획을 에이전트 검토자 앞에서 변호하는 일이에요.
