버그 하나를 “환자”로 본다면?
AI 코딩 에이전트에게 버그 수정을 맡겨보신 적 있으세요? 간단한 건 곧잘 고치는데, 조금만 복잡해져도 증상만 덮는 패치를 내놓거나 엉뚱한 곳을 고치고는 “해결했습니다!”라고 자신 있게 말하는 경우가 많죠. 분산 데이터베이스 CockroachDB를 만드는 Cockroach Labs가 이 문제에 꽤 재미있게 접근했어요. 버그는 환자처럼, 코딩 에이전트들은 의료팀처럼 다루면서 5개월 동안 일종의 “병원”을 운영해본 거예요.
이 실험이 흥미로운 건 “어떤 모델이 더 똑똑한가”가 아니라 “에이전트들이 일하는 구조를 어떻게 짜야 하는가”를 다룬다는 점이에요. 이제 쓸 만한 에이전트는 여럿이라, 결과의 차이는 모델보다 일하는 구조에서 더 크게 나거든요. 구체적인 역할 분담과 결과 수치는 원문에 자세히 나와 있으니 꼭 읽어보시길 추천해요. 여기서는 왜 하필 “병원”이라는 비유가 잘 맞는지, 그리고 우리 팀에는 어떻게 응용할 수 있을지를 중심으로 풀어볼게요.
왜 하필 CockroachDB였을까
CockroachDB는 여러 서버에 데이터를 나눠 저장하면서도 하나의 DB처럼 동작하게 만드는 분산 SQL 데이터베이스예요. 이런 시스템의 버그는 악명이 높아요. 네트워크가 잠깐 끊긴 순간, 두 노드가 동시에 리더가 되려는 찰나, 특정 타이밍에만 터지는 경쟁 상태(race condition, 여러 작업이 동시에 같은 자원에 접근하면서 생기는 문제) 같은 것들이라 재현 자체가 어렵거든요. 게다가 CockroachDB는 정기적으로 대규모 통합 테스트를 돌리고 실패하면 이슈가 자동으로 등록되는 구조라, “가끔씩만 실패하는 테스트(flaky test)” 이슈가 끊임없이 쌓여요.
딱 응급실 상황이에요. 환자(버그)는 계속 들어오는데 모두 똑같이 위급한 것도 아니고, 증상만 봐서는 원인을 알 수 없고, 의사(엔지니어) 수는 한정돼 있죠.
병원 비유가 잘 맞는 이유
병원은 “불확실한 문제를 여러 전문가가 나눠서 다루는 시스템”을 오랫동안 다듬어온 조직이에요. 개발팀이 배울 게 많죠.
트리아지(중증도 분류): 응급실은 들어온 순서가 아니라 위급한 순서대로 환자를 봐요. 버그도 마찬가지예요. 데이터 손상 가능성이 있는 버그와 로그 메시지 오타를 같은 줄에 세우면 안 되죠. 에이전트가 처음 할 일은 고치는 게 아니라 분류하는 거예요.
차트(진료 기록): 병원에서는 누가 언제 어떤 검사를 했고 결과가 뭐였는지 다 기록해요. 다음 당직 의사가 이어받을 수 있게요. 에이전트는 세션이 끝나면 기억을 잃어요. 그래서 조사 과정과 가설, 실패한 시도를 이슈에 차곡차곡 남겨두는 게 정말 중요해요. 그래야 다음 에이전트나 사람이 처음부터 다시 하지 않거든요.
전문의 협진: 병원에서는 의사 한 명이 다 보지 않고 영상의학과, 내과, 외과가 나눠서 봐요. 에이전트도 하나에게 다 맡기기보다 재현 담당, 원인 분석 담당, 수정 담당, 리뷰 담당처럼 역할을 나누면 각자 다루는 맥락이 깔끔해지고 서로의 실수도 잡아낼 수 있어요.
진단 먼저, 처방은 나중: 열이 난다고 해열제부터 주면 원인을 놓치죠. 테스트를 통과시키려고 타임아웃만 늘리거나 에러를 삼켜버리는 “증상 치료” 패치를 막으려면, 원인 진단부터 문서로 남기게 강제하는 게 효과적이에요.
주치의의 서명: 최종 처방은 면허 있는 의사가 책임져요. 에이전트가 만든 수정도 결국 사람 엔지니어가 검토하고 승인해야 하죠.
업계 맥락
GitHub Copilot 코딩 에이전트는 이슈를 할당하면 알아서 PR을 만들고, Claude Code는 서브에이전트로 역할을 나눌 수 있어요. OpenAI Codex도 클라우드에서 여러 작업을 병렬로 돌리고요. 도구는 이미 충분해요. 그런데 대부분의 팀은 여전히 “에이전트 하나에 이슈 하나 던지기” 수준으로 쓰고 있죠. Cockroach Labs의 실험은 여러 에이전트를 실제 대규모 코드베이스의 실제 버그 흐름에 몇 달 동안 붙여본 사례예요. 데모가 아니라 운영 관점의 교훈을 준다는 게 이 실험의 가치예요.
한국 개발자에게 주는 시사점
큰 조직이 아니어도 이 구조는 바로 따라 해볼 수 있어요. 먼저 버그 리포트 템플릿을 정리하세요. 재현 방법, 기대 결과, 실제 결과, 로그가 정리돼 있으면 에이전트의 성공률이 확 올라가요. 다음으로 에이전트에게 바로 고치라고 하지 말고 “진단 보고서부터 이슈 댓글로 남겨줘”라고 해보세요. 사람이 그 진단을 보고 맞다고 판단하면 그때 수정을 맡기는 거예요. 그리고 재시도 추가, 타임아웃 증가, 예외 무시처럼 증상만 덮는 수정은 리뷰에서 특히 의심하는 습관을 들이면 좋아요.
마무리
한줄 정리: 에이전트에게 버그를 맡길 때 중요한 건 더 똑똑한 의사 한 명이 아니라 분류, 기록, 협진, 승인이 돌아가는 병원 시스템이에요.
여러분 팀은 AI 에이전트에게 버그 수정을 어디까지 맡기고 계신가요? 에이전트가 “증상만 치료”해서 곤란했던 경험이 있다면 공유해주세요!
🔗 출처: Hacker News