13개의 AI 에이전트가 병렬로 리뷰하면서, 내가 놓쳤을 치명적인 버그를 잡아냈다
저자: Kieran Klaassen (Cora의 총괄 매니저)
2026년 1월 23일
이 뉴스레터가 전달받은 것인가요? 구독하기를 통해 받은편지함으로 직접 받아보세요.
버그 리포트는 단순해 보였다: 한 사용자가 우리의 AI 기반 이메일 어시스턴트인 Cora에서 이메일 서명 포맷이 이상하다는 것을 발견했다. 나는 Claude Code에게 조사하고 수정하라고 요청했다. 다음 날 아침, 수정 사항은 27개의 파일을 건드렸고, 1,000줄 이상의 코드가 변경되었다. 나는 그 중 단 한 줄도 작성하지 않았다.
1년 전이었다면, 나는 오후 내내 그 코드를 읽었을 것이다. 한 줄씩, 파일별로, email_signature를 한 데이터베이스 테이블에서 다른 테이블로 옮기는 마이그레이션을 유심히 살펴보고, 피처 플래그의 모든 인스턴스를 Ctrl+F로 찾았을 것이다.
이번에는 15분 동안 결정을 내렸고, 코드는 단 하나의 버그도 없이 배포되었다.
AI 이전에 코드 리뷰란 팀원이 작성한 모든 줄을 읽는 것을 의미했다. 편집자가 원고를 검토하듯이 오타, 논리 오류, 스타일 불일치를 확인했다. 이제 내 코드 리뷰는 더 이상 코드를 읽는 것을 포함하지 않는다. 그리고 그 덕분에 문제를 더 잘 잡아내게 되었다.
이것이 컴파운드 엔지니어링 방식의 코드 리뷰다: 에이전트들이 병렬로 리뷰하고, 발견 사항은 결정으로 이어지며, 모든 수정 사항은 시스템에게 다음에 무엇을 잡아야 하는지 가르친다. 27개 파일을 건드린 서명 수정? 내가 저녁을 만드는 동안 13개의 전문화된 AI 리뷰어가 동시에 검토했다.
어떻게 설정했는지, 어떻게 내가 놓쳤을 치명적인 버그를 잡아냈는지, 그리고 커스텀 도구 없이도 어떻게 시작할 수 있는지 보여주겠다.
코드를 읽는 것은, 비록 짧게라도, 사물의 형태에 대한 감각을 주었다. 코드베이스가 너무 복잡해지고 있을 때 느낄 수 있었다. 수동 리뷰를 놓아버리면, 그 명확성을 잃을까 봐 걱정했고, 아키텍처가 나 없이 방황할까 봐 걱정했다.
하지만 수동 코드 리뷰는 더 이상 지속 가능하지 않다는 것도 깨달았다. 개발자가 200줄을 작성하면, 그 매니저는 그것을 읽는 데 20~40분을 쓸 수 있다. 코드 작성 시간 대 리뷰 시간의 비율은 5:1 또는 10:1을 유지한다—커피 한 잔을 들고 앉으면, 내가 끝날 때쯤 커피가 아직 따뜻할 것이다. AI가 그 비율을 깨뜨렸다. 코드를 생성하는 데 걸리는 시간은 급격히 줄었지만, 인간이 코드를 리뷰하는 데 걸리는 시간은 그렇지 않았다. 무언가를 포기해야 했다.
수동 리뷰에서의 전환은 천천히 일어났다. Claude Code가 일련의 수정을 실행했을 때, 나는 질문을 던지고, diff(무엇이 변경되었는지 보여주는 줄별 비교)를 읽었다. 만족스러우면, 숨을 참고 변경 사항을 메인 코드베이스에 병합했다.
아무것도 망가지지 않았다. 코드는 괜찮았다. Claude에게 그 추론을 설명하라고 요청하는 것—무엇을 바꿨는지, 왜 바꿨는지, 무엇이 망가질 수 있는지—이 diff를 스크롤하는 내 피곤한 눈보다 더 많은 것을 잡아낸다는 것이 밝혀졌다.
얼마 후, 그 꼼꼼한 읽기는 빠른 훑어보기로 바뀌었다. 훑어보기는 흘끗 보기로 바뀌었다. 결국 나는 질문을 던졌을 때쯤 이미 "병합"을 눌렀다는 것을 발견했다.
나는 여전히 코드가 얼마나 좋은지 이해했다—그 명확성은 그저 다른 방식으로 왔다. 코드를 읽어서 코드의 형태를 느끼는 대신, Claude Code를 심문함으로써 느꼈다:
kieran-reviewer의 피드백을 무시했어?"마지막 질문은 설명이 필요하다. kieran-reviewer는 내가 만든 AI 에이전트다—내 코드 선호도에 대해 훈련된 전문화된 리뷰어다. 예를 들어, 나는 복잡한 쿼리보다 단순한 쿼리를, 영리한 코드보다 명확한 코드를 선호한다는 것을 알고 있다. 이것은 내가 보기 전에 모든 풀 리퀘스트를 검토하는 13개의 리뷰어 중 하나다.
왜 그렇게 많은 에이전트가 필요할까? 단일 리뷰어는, 인간이든 AI든, 27개 파일 변경에서 모든 것을 잡아내지 못한다. 보안 전문가는 인증 갭을 발견하지만 데이터베이스 문제는 놓친다. 성능 전문가는 느린 쿼리를 잡지만 스타일 드리프트는 무시한다. 나는 각자가 잘하는 것에 집중하며 병렬로 작업하는 전문가들이 필요했다. 함께라면, 수동 리뷰에서 내가 놓칠 수 있는 것을 잡아낸다.
코드 리뷰를 위한 내 시스템은 컴파운드 엔지니어링 플러그인에 통합되어 있다. 이것은 Claude Code가 할 수 있는 것을 확장하는 코드베이스의 파일 세트다. 작동 방식은 다음과 같다.
슬래시 명령어는 터미널에 입력하는 단축키다—/workflows:review 또는 /workflows:plan처럼—워크플로우를 트리거한다. 각 워크플로우는 호출할 때 Claude가 무엇을 해야 하는지에 대한 지침이 담긴 마크다운 파일이다.
에이전트는 전문화된 AI 워커로, 각각 자체 마크다운 파일에 페르소나와 집중 영역이 정의되어 있다.
이메일 서명 수정을 위해, 나는 단일 명령어를 실행했다: /workflows:review, 이것은 목록에 있는 모든 에이전트를 한 번에 가동시켰다:
kieran-rails-reviewer - 내 개인 스타일 선호도 확인code-simplicity-reviewer - 과잉 엔지니어링 탐색data-integrity-guardian - 마이그레이션 중 데이터베이스 변경 검증 (데이터베이스 구조가 변경될 때)security-sentinel - 인증 우회 확인10분 후, 그들은 우선순위별로 순위가 매겨진 발견 사항을 가지고 돌아왔다.
에이전트들은 발견 사항을 생산한다. 하지만 이슈 목록은 유용하지 않다—나는 그것에 대해 무엇을 해야 하는지 알아야 한다. 그래서 다음 명령어를 실행한다: /triage
Triage는 13개 리뷰어의 모든 발견 사항을 가져와서, 심각도별로 순위를 매기고, 각각에 대해 나를 안내한다. 모든 발견 사항을 같은 방식으로 제시한다: 여기 문제가 있고, 왜 중요한지, 이제 무엇을 하고 싶은가?
나는 권장 사항을 수락할 수 있고 (시스템이 수정 작업을 생성한다), 건너뛸 수 있고 (처리할 가치가 없다), 또는 구체적인 지침을 제공할 수 있다.
서명 수정은 세 가지 발견 사항을 표면화했다. 첫 번째는 치명적이었다: 코드가 사용자 설정을 저장하는 위치를 옮겼지만, 한 파일이 여전히 이전 위치에서 찾고 있었다. 이것을 배포했다면, 초안 응답을 생성하려는 모든 사용자가 오류를 겪었을 것이다. 수정 자체는 사소하다—코드가 새 위치를 가리키도록 하면 된다—하지만 diff를 스크롤하면서는 절대 잡아내지 못했을 것이다.
두 번째는 정리였다. 이전 접근 방식에서 남겨진 사용되지 않는 코드 덩어리. 망가진 것은 아니었지만, 혼란스러웠다. 미래에 누군가가 코드를 읽게 된다면, 그것이 무엇을 위한 것인지 궁금해할 것이다. 이 변경도 승인했다.
세 번째는 사소한 지적—기술적으로는 맞지만 무해한 작은 중복. 건너뛰었다. 다음에 그 파일에 있을 때 정리하겠다.
세 가지 발견 사항을 받고 2분도 안 되어 세 가지 결정을 내렸다.
치명적인 발견 사항 하나만으로도 리뷰가 정당화되었다. 오후 6시에 1,000줄을 스크롤하면서 31번째 줄의 불일치하는 참조를 절대 잡아내지 못했을 것이다. 에이전트들은 몇 초 만에 잡아냈다.
서명 수정은 단순했어야 했다. 한 가지를 바꾸고 끝내면 된다. 하지만 때때로 코드 한 조각을 수정하면, 다른 것을 망가뜨리게 된다. 이것은 인간 개발자나 코딩 에이전트나 마찬가지다.
우리의 경우, 첫 번째 버전은 Gmail에서 서명 포맷을 수정했지만, 이메일의 일반 텍스트 버전을 망가뜨렸다. 일부 이메일 앱은 스타일이 적용된 텍스트를 표시하지 않고, 이제 그 사용자들은 읽을 수 있는 텍스트 대신 원시 포맷 코드를 보았다.
그래서 그것을 수정했다. 하지만 일반 텍스트 수정은 서명이 전혀 없는 사용자들에게 추가 빈 줄을 만들었다.
그래서 그것도 수정했다. 그런 다음 스타일이 과하게 적용된 마케팅 이메일에 답장할 때, 우리의 포맷 규칙이 인용된 텍스트에 누출되고 있다는 것을 발견했다. 사용자들은 메시지 본문에서 #outlook a { padding: 0; } 같은 의미 없는 텍스트를 보았다.
그것을 수정했다. 다음으로 Cora가 이메일 초안을 제안할 때마다 이메일 서명을 추가하고 있다는 것을 발견했다, 맨 끝에 한 번만이 아니라. 세 가지 옵션을 생성하면, 세 개의 서명이 생겼다. 또 다른 수정이 필요했다.
코드의 10개 버전. 원래 것을 수정하면서 도입한 4개의 버그. 그래서 27개 파일과 천 줄의 코드가 된 것이다. 다시 말하지만, 이것은 인간이든 AI든 모든 개발 과정의 정상적인 부분이다. 차이점은 여기서 우리가 배운 것을 코드화하여 다음에 같은 실수를 하지 않도록 할 수 있다는 것이다.
나는 그 버그들을 수정하는 데 15분을 썼다. 그런 다음 다시는 그것들을 보지 않도록 하는 데 또 15분을 썼다.
서명 난장판 후에, 우리는 refactor-email-content-rendering.md라는 문서를 만들었다. 이것은 우리 코드베이스에 있고, 우리가 배운 모든 것을 담고 있다:
그 문서는 이제 프로젝트의 일부다. 다음에 누군가가 이메일 렌더링을 건드릴 때—그것이 나든, 팀원이든, Claude든—AI가 먼저 읽는다.
이 워크플로우를 사용한 첫 주에, Claude는 반드시 틀린 것은 아니지만 내 선호를 반영하지 않는 접근 방식을 제시했다. 내가 "과잉 엔지니어링"이라고 생각하는 것을, 다른 엔지니어는 "견고한"이라고 부를 수 있다. 내가 놓친 패턴이라고 보는 것을, 다른 사람은 전혀 사용하지 않을 수 있다. 3개월이 지나고 50개 이상의 리뷰를 거친 지금, Claude의 계획은 대체로 내가 문제에 접근하는 방식을 반영한다.
더 나은 AI 모델은 모든 사람의 출력을 더 좋게 만든다. 하지만 당신의 시스템은 당신 팀 고유의 지식을 축적하기 때문에 더 좋아진다. 에이전트들은 당신의 선호를 배우고, 리뷰 프로세스는 당신의 사각지대를 드러낸다. 그것이 복리가 일어나는 곳이다.
그래서 50/50 규칙을 따르라: 시간의 절반은 출력을 리뷰하는 데, 절반은 교훈이 정착되도록 하는 데 써라.
대부분의 엔지니어는 모든 것을 읽어야 한다고 가정한다. 그 가정은 인간이 모든 코드를 작성했을 때는 말이 되었다. 하지만 더 이상은 아니다.
나는 대부분의 코드를 읽지 않고 이메일 서명 수정을 배포했다. 발견 사항을 리뷰하고 결정을 내렸다. Gmail의 스크린샷을 봤다. 하지만 이메일 콘텐츠를 추출하는 방법의 구현 세부 사항을 읽었나? 아니. 데이터베이스 변경이 엣지 케이스를 어떻게 처리하는지 추적했나? 아니.
그런데 기능은 작동한다. 사용자들은 적절하게 포맷된 서명을 받는다. 테스트—코드가 올바르게 동작하는지 확인하기 위해 모든 기능과 함께 작성하는 검사—가 모두 통과한다. 스크린샷이 올바르게 보인다. 수동 코드 리뷰를 놓아버리는 데 시간이 좀 걸렸지만, 결과가 스스로를 증명한다.
내가 한 거래는 모든 줄을 읽지 않겠다는 것이지만, 코드를 읽는 데 쓸 시간의 일부는 이제 시스템을 더 똑똑하게 만드는 데 간다. 이상한 포맷으로 가득 찬 마케팅 이메일에 대한 테스트 케이스를 추가하고 있다. "데이터가 있는 위치를 변경할 때, 그것을 읽는 모든 파일을 확인하라"를 에이전트들이 자동으로 시행하는 규칙으로 캡처하고 있다. 이렇게 하면, 이 코드를 건드리는 다음 사람—인간이든 AI든—은 내 실수를 반복하지 않는다.
아직 컴파운드 엔지니어링 플러그인이 없다면, 세 가지 질문으로 시작하라. AI가 생성한 출력—코드, 문서, 또는 전략 덱—을 승인하기 전에, AI에게 물어라:
2분이 걸리는 그 대화가 30분의 집중하지 않은 수동 검사가 놓쳤을 것을 표면화한다. AI는 까다로운 부분이 어디인지 안다. 그저 물어보지 않으면 자발적으로 말하지 않을 뿐이다.
그런 다음 50/50 규칙을 적용하라. 시간의 절반은 즉각적인 문제를 수정하는 데, 절반은 문서화하여 문제가 다시는 돌아오지 않도록 하는 데 써라.
이메일 서명 렌더링에 관련된 27개 파일은 다음 기능을 기다리고 있다. 나는 여전히 그것들을 전부 읽지 않을 것이다. 하지만 내가 끝나면, 시스템은 시작할 때보다 더 많이 알게 될 것이다.
Kieran Klaassen은 Every의 이메일 제품인 Cora의 총괄 매니저입니다. X에서 @kieranklaassen으로 또는 LinkedIn에서 팔로우하세요.
이와 같은 에세이를 더 읽으려면, Every를 구독하고, X에서 @every와 LinkedIn에서 팔로우하세요.
원문 출처: Every - Source Code