에이전트가 코드를 작성하는 시대에 PR 검토를 사람을 위한 단계로 남기고, PR 전에 검토와 작동 증명을 완료하는 방법을 설명합니다.
에이전트가 이제 내 코드 대부분을 작성하고, 내 PR 대부분도 엽니다. 그리고 내가 작업하는 거의 모든 저장소에는 CodeRabbit, Copilot, 또는 Anthropic의 Code Review처럼 그들을 기다리는 AI 검토자가 있습니다. 한 에이전트가 PR을 열고, 그제야 다른 에이전트가 이를 검토합니다. 나는 이것이 거꾸로라고 생각합니다.
우리는 사람을 위해 설계된 프로세스를 վերց어 기계가 흉내 내도록 가르쳤습니다. 공정하게 말하면, 이런 검토자들은 실제 버그를 찾아내고1, 물론 모든 변경 사항은 하나를 거쳐야 합니다. 하지만 왜 PR이 열린 뒤까지 기다릴까요? 검토는 변경 사항을 만드는 과정의 일부여야 하며, 그것이 작동한다는 증거도 마찬가지입니다. 둘 다 갖추고 나면 에이전트가 다시 검토할 이유는 없고, 남는 검토는 사람을 위한 것입니다.
다른 이들도 비슷한 결론에 도달했습니다. 참고 자료를 보세요. iOS 앱에서는 이렇게 보입니다.
아직 계속 다듬고 있지만, 지금은 이렇게 합니다. 내 버그 수정 대부분은 /fix-issues 스킬을 거칩니다. 이 스킬은 Linear에서 다음 N개의 이슈를 가져와 각각 별도의 워크트리와 시뮬레이터에서 수정합니다. 검토는 PR을 열기도 전에 이루어집니다. 에이전트가 변경분에 대해 /code-review를 실행하고, 걸리는 문제를 수정한 뒤 다시 테스트합니다. 나는 이를 빠르게 유지하고 있으며, 지금까지는 충분했습니다. 이를 추가한 뒤 저장소의 AI 검토자는 11개의 PR 중 1개만 지적했고, 그것도 사소한 지적이었습니다. 이전에는 같은 종류의 수정 23개 중 10개를 지적했습니다.
하지만 변경분 검토는 바뀐 부분만 볼 뿐, 그 주변은 보지 못합니다. 그래서 두 번째 에이전트가 이 변경이 코드베이스에 어떻게 들어맞는지 살핍니다. 중복 코드, 재사용할 수 있었던 헬퍼, 따르지 않는 패턴, 또는 망가뜨릴 수 있는 호출자를 찾습니다. 이것이 내가 그렇지 않았다면 변경분을 읽으며 확인했을 내용입니다. 그렇다고 어느 검토도 변경 사항에 대한 내 확신의 근거는 아닙니다. 근거는 증명입니다.
나는 에이전트가 변경 사항이 작동한다고 말해 주기를 원하지 않습니다. 브랜치를 빌드하지 않고도 1분 안에 검증할 수 있는 무언가로 보여 주기를 원합니다.
그리 오래전만 해도 이는 모든 PR에 하기에는 너무 많은 작업이었을 겁니다. 이제 에이전트는 Xcode 27 MCP 서버와 시뮬레이터로 쉽게 수행합니다. 이는 내가 iPhone Duo에서의 Pocket Casts에서 스크린샷 1,700장을 만드는 데 사용한 것과 같은 환경입니다. 다음은 오른쪽에서 왼쪽으로 쓰는 언어에서 미니 플레이어의 진행 행을 수정한 #5539입니다.
PR에서 바로 가져온 RTL의 iPad 수정 전후 모습
이는 레이아웃 수정이므로 스크린샷만으로도 필요한 증명이 충분합니다. PR에는 나머지 내용도 있습니다. 근본 원인, 위험도, 테스트 단계, 그리고 결과입니다. 저장소의 AI 검토자는 여전히 이를 두 번 살펴봤지만 아무것도 찾지 못했습니다. 정확히 그래야 합니다. PR 전 검토가 이미 제 역할을 했기 때문입니다.
그렇다면 검토는 무엇을 위한 것일까요? 사람을 위한 것입니다. 무엇을 병합할지에 대한 책임은 당신에게 있고, AI는 어떤 것에도 책임질 수 없습니다.
1979년 IBM 내부 교육 자료에서 (Simon Willison을 통해)
따라서 타협할 수 없는 것은 두 가지입니다. 변경 사항이 작동한다는 증거와 병합을 책임지는 사람입니다. 코드를 읽는 일을 포함해 나머지는 모두 협상할 수 있습니다. 나는 항상 설명과 산출물을 검토하며, 작은 변경 사항의 경우 이들이 변경분보다 더 많은 것을 알려 주는 경우가 많습니다. 나는 에이전트에게 모든 PR의 위험도를 **위험도:** 낮음. 미니 플레이어의 진행/시간 행 레이아웃만 변경됩니다.처럼 평가하도록 요청하며, 이는 다음으로 연결됩니다.
나만 이렇게 하는 것은 아닙니다. Claude Code 팀도 동일한 세 단계, 즉 사람 승인 0회, 1회, 2회를 사용하며, 내가 빌려 온 규칙도 있습니다. “등급은 작성자가 아니라 변경 사항이 정한다.” 에이전트의 평가는 출발점일 뿐입니다. 스크립트가 변경분을 검사하며 등급을 올릴 수만 있게 합니다. 중요한 영역의 모든 변경 사항은 높음이고, 공유 코드, 기존 테스트, CI의 변경이나 몇 개를 넘는 파일의 변경은 최소한 중간입니다. 스크린샷은 화면에서 바뀐 것을 보여 줄 뿐, 변경분이 건드린 다른 부분까지 보여 주지는 않습니다.
차이는 무엇이 코드 검토를 건너뛸 수 있는가에 있습니다. 그들에게는 문서, 문구, 내부 전용 기능, 플래그 뒤에 있는 추가 변경 사항처럼 본질적으로 안전한 변경입니다. 나에게는 위의 RTL 사례처럼 사용자가 볼 수 있는 작은 수정도 포함됩니다. 스크린샷이 증거이기 때문입니다. 어느 쪽이든, 자신에게 정직해야 하며 변경 사항이 더 면밀한 검토를 받아야 할 때마다 등급을 올려야 합니다.
PR은 예전에는 짧은 설명과 변경분이었습니다. 이제는 설명이 변경분보다 더 중요합니다.
하지만 도구는 여전히 변경분을 중심으로 만들어져 있습니다. 내 PR에는 모든 것이 있지만, 여전히 너무 비공식적이고 기초적으로 느껴집니다. 그저 Markdown과 이모지 묶음일 뿐입니다2. 도구는 코드보다 그 밖의 모든 것에 더 집중해야 한다고 생각합니다.
이 중 일부는 이미 존재하며, 나는 Figma와 Linear MCP 서버처럼 몇 가지를 사용합니다. 다른 것들은 하나씩 통합해야 하고, 나는 더 완전한 해결책을 원합니다. 이상적으로는 앱의 온보딩 흐름처럼 변경 사항을 안내해 주어야 합니다. “여기를 누르고, 이것을 보세요.”
코드 검토는 팀이 무엇이 바뀌었는지 배우는 방식이기도 합니다. 이것이 Google이 처음에 이를 도입한 이유 중 하나였습니다. 버그를 찾는 것만이 유일한 목적은 아니었습니다. 따라서 코드 검토가 줄어들면 지식을 공유하고 코드베이스의 일관성을 유지할 기회도 줄어듭니다. 에이전트는 여기에서도 도움이 될 수 있습니다. 새 패턴이나 변경된 API 같은 중요한 내용만 담은 주간 요약과, 앱에서 무엇이 바뀌었는지 보여 주는 영상 시연을 보내도록 하세요.
그래도 코드베이스는 이해해야 합니다. 아키텍처, 한계, 중요한 부분을 이해하지 못하면 무엇을 보고 있는지 알 수 없기 때문입니다.
우리의 목표는 이전에 효과가 있었던 것을 맹목적으로 자동화하는 것이 아니라, 에이전트를 위한 더 많은 활용 사례를 찾는 것이어야 한다고 생각합니다. 에이전트가 코드를 작성한다면, 그것을 검토하고 증명하는 일도 작성의 일부일 뿐이며 모두 PR이 열리기 전에 일어납니다. 충분히 좋은 증거가 있다면 모든 변경분을 읽을 필요조차 없습니다. 남는 일은 사람을 위한 것입니다. 무엇을 병합할지 결정하고 그에 대한 책임을 지는 일입니다.
즐거운 배포 되세요!
