에이전트가 짠 코드를 리뷰하지 마세요. 심문하세요.

해결책이 plan mode라는 점에는 동의하지 않아요. OpenCode 같은 것이 이 문제에 대한 완벽한 답이죠. 원래의 요청 사항인 '이유'를 포착하고, 과잉 설계나 추측을 피하기 위한 규칙들을 얼마든지 심어둘 수 있거든요. 모든 변경 사항은 아카이브에 저장되고, 제품이 출시됨에 따라 사양과 요구사항도 업데이트됩니다.

OpenCode를 쓰고 있는데 이런 기능이 있는 줄은 몰랐네. 어떻게 사용하는 거야?

솔직히 말해서, 에이전트가 10만 줄이나 작성하게 둔다면 너무 큰 단위로 작업하고 있는 거야.

난 여전히 코드를 직접 리뷰해. 코드 퀄리티보다는 실제 아키텍처에 더 집중하긴 하지만. 에이전트가 작업을 시작하기 전에 미리 계획을 아주 상세하게 짜두기 때문에 아키텍처는 대체로 괜찮은 편이야. 그래도 가끔씩 멍청한 짓을 할 때가 있어서 내가 지적하고 수정해줘야 하지.

네가 말한 심문 방식도 아마 비슷한 결과를 낼 것 같긴 한데, 난 AI한테 자기가 한 일을 보고하라고 시키는 걸 여전히 불신해. 보고서는 보통 우리가 처음에 계획한 대로 나오겠지만, 결국 네가 발견한 'LGTM 증후군'으로 돌아가게 될 거야. 에이전트가 자기가 저지른 별로인 부분들을 보고하지 않을 수도 있고, 확실하게 확인하려면 결국 내가 직접 코드를 훑어보는 수밖에 없거든.

이 방식의 문제는 모든 코드 리뷰에 사람이 개입해야 한다는 거야. 무슨 '취조' 기술 세션이라도 하는 것 같네. 의도는 알겠는데 난 그렇게까지 할 인내심은 없다.

솔직히 저는 그냥 리뷰 봇 군단을 줄 세워 둡니다. PR 전에 로컬 리뷰를 실행하고, 실제 사람이 하듯 작업을 수행하는 QA 에이전트를 거치게 하는데, 이게 실제로 많은 걸 잡아내요.

GitHub에서 PR을 초안으로 올리면, 거기서 여러 번의 리뷰 루프(coderabbit, codex 등)를 돌리고, 회귀 오류를 잡기 위해 QA 에이전트를 더 돌립니다.

자동화된 리뷰가 끝나면 제가 수동으로 리뷰를 하고, 승인이 나면 PR 초안 상태를 해제한 뒤 꽤 빡빡한 CI 체크를 돌리고, 그게 다 통과되면 병합합니다.

이 시스템을 조금씩 수정하고 있는데, 저한테는 아주 잘 작동하고 있어요.

수동 리뷰 단계 전까지는 전체 과정이 자동화되어 있습니다. 저는 로컬에서 Plane을 실행하고 에이전트들이 거기서 작업을 업데이트하게 해요. 사무실의 큰 TV에 띄워놓고 여러 보드를 한 번에 볼 수 있게 수정해서 실시간으로 업데이트되도록 했죠. 그래서 보드만 슥 봐도 백로그, 현재 작업 중인 것, 수동 리뷰 대기 중인 것을 바로 알 수 있습니다.

참고로 제가 말하는 수동 리뷰는 수백 줄의 코드를 일일이 파헤치는 게 아니라, 직접 기능을 사용해보고 앱 워크플로우를 실행하면서 문제를 확인하는 것을 의미합니다.

어느 정도 기술적이고 지적인 창업자로서 제가 에이전트와 일하는 방식이 딱 그렇습니다. 제가 많은 걸 잡아내지는 못하겠지만, 과도하게 설계되었거나 그냥 이상해 보이는 선택들에 대해서는 질문을 던지는 편이에요.

저는 에이전트 3개를 써서 이 문제를 해결했어요. 첫 번째는 제가 직접 소통하며 모든 기술적 요구사항을 티켓으로 만드는 PM 역할을 합니다. 두 번째는 솔루션을 설계하고 구축하죠. 마지막 리뷰어는 요구사항 문서에 접근할 수 있고, 두 번째 에이전트의 결정 과정에는 접근하지 않은 채 그 문서를 바탕으로 솔루션을 리뷰합니다.

난 에이전트한테 자기가 한 모든 작업에 대한 데모를 만들라고 시켜. 이걸 '증명 페이지(proof pages)'라고 부르지. 에이전트가 하는 말을 하나도 안 믿기 때문에 모든 컴포넌트에 대해 확실한 증거를 제시하라고 하는 거야. 그러면 에이전트가 모든 걸 시연하는 인터랙티브 요소가 포함된 방대한 문서를 만들어 줘.