Mainlane은 엔지니어 한 명과 AI 에이전트 팀으로 일합니다. 그러면 당연히 이런 질문이 나옵니다. AI가 작성한 코드는 누가 검토할까요? 저희의 답은 그 코드를 쓰지 않은 또 다른 AI, 그리고 출시 여부를 결정하는 사람입니다.
루프의 흐름
- Claude 세션이 작업을 맡아 풀 리퀘스트를 엽니다.
- 별도의 리뷰어가 깨끗한 세션에서 시작합니다. 코드가 어떻게 작성됐는지 본 적이 없으므로, 작성자의 전제 없이 동료처럼 diff를 읽습니다.
- 리뷰어는 지적 사항을 세 단계로 남깁니다. 🔴 반드시 수정, 🟡 수정 권장, 🟢 있으면 좋음.
- 작성자 세션은 이를 수정하고 항목별로 답한 뒤, 마지막에 실행한 명령과 그 출력 결과를 담은 “검증(Verification)” 섹션을 붙입니다.
- 리뷰어는 새 head를 확인합니다. 지적 사항이 하나도 남지 않을 때까지, 🟢조차 없을 때까지 루프가 반복됩니다.
두 가지 규칙이 이 과정을 정직하게 지켜 줍니다. 지적 사항에 이의를 제기하려면 “괜찮습니다”가 아니라 측정값, 즉 숫자나 명령 출력, 테스트가 잡아내지 못하는 뮤턴트를 제시해야 합니다. 그리고 다섯 라운드가 지나면 루프가 멈추고 사람에게 묻기 때문에 끝없이 돌지 않습니다.
사람의 역할
어떤 에이전트도 머지하지 않습니다. 리뷰에 지적 사항이 없고 리뷰어가 본 바로 그 커밋에서 CI가 통과하면, 세션은 “ready to merge(머지 준비 완료)”라고 쓰고 기다립니다. 머지는 사람이 승인한 뒤에만, 그리고 그 커밋에 대해서만 이루어집니다.
무엇을 잡아내는가
이 웹사이트 저장소에서 있었던 실제 사례 몇 가지입니다.
- CI에 Lighthouse 검사를 추가한 풀 리퀘스트에서 리뷰어는 CSS 빌드 설정이 잘못된 폴더를 가리켜 레이아웃 스타일이 사이트에서 조용히 사라졌다는 점을 발견했습니다. Lighthouse도 접근성 검사기도 이를 잡아내지 못했습니다. 키보드 사용자에게 포커스된 요소를 가릴 수 있는 고정 언어 배너도 함께 찾아냈습니다.
- 데이터베이스 백업 복원 점검에서는 매일 실행되는 테스트가 복원된 데이터를 내보낸 데이터가 아니라 자기 자신과 비교하고 있었습니다. 행이 빠져도 절대 알아차리지 못했을 것입니다. 같은 리뷰에서 리드의 이메일을 로그에 출력할 수 있는 오류 메시지도 발견했습니다.
- Content Security Policy를 도입할 때는 브라우저 확장 프로그램에서 오는 보고 때문에 “일주일 동안 위반 없음”이라는 목표를 결코 달성할 수 없었을 것이고, 정책을 강제 적용하는 순간 블로그 글의 외부 이미지가 깨졌을 것입니다.
특이한 문제는 하나도 없었습니다. 금요일 저녁에 지친 사람이 놓치기 쉬운 종류의 문제였습니다.
숫자로 보면
2026년 10월 말 기준으로 이 루프는 8개 저장소에서 돌아가며, 머지된 풀 리퀘스트는 385개, 리뷰는 1,069건입니다. 비용 대부분은 작업 자체에 듭니다. 10월 마지막 주에는 토큰의 약 4분의 3이 구현에, 10분의 1 미만이 리뷰에 쓰였습니다.
한계
리뷰어는 작성자와 같은 종류의 모델이므로 같은 맹점을 가질 수 있습니다. 중요한 변경에 대한 사람의 리뷰를 대신하지 않으며, 풀 리퀘스트 안의 텍스트는 지시가 아닌 데이터로만 취급합니다. 대신 혼자 일하는 개발자 대부분이 건너뛰는 단계, 즉 모든 변경을 또 한 사람의 눈으로 확인하는 일을 대신합니다.