한 AI는 코드를 작성하고 다른 AI는 리뷰합니다 — 변경을 언제 포기해야 할까요

AI 요약

정규직으로 일하면서 소규모 Shopify 앱 여러 개를 운영하는 작성자는 개발 작업 대부분을 AI에 맡기고 있습니다. 현재 사용 중인 방식은 한 모델이 변경 사항을 작성하고, 다른 모델이 작업 전에 합의한 번호 매긴 목록을 기준으로 검토하는 구조입니다. 검토 모델은 모든 항목을 통과시키거나 전체 변경을 실패 처리하며, 일부만 괜찮다는 식의 판정은 허용하지 않습니다.

■ 두 라운드 규칙과 실제 실패

작성자는 하루 동안 다섯 건의 리뷰를 마쳤고, 세 건은 통과했으며 두 건은 실패했습니다. 실패한 두 건의 점수는 각각 6개 항목 중 5개 통과, 10개 항목 중 6개 통과였습니다. 더 중요한 점은 두 변경 모두 앱 코드가 아니라 문서화된 지침에 대한 변경이었다는 것입니다. 그중 한 건에는 작성자가 스스로는 발견하지 못했을 실제 허점이 포함되어 있었습니다. 따라서 리뷰 실패는 단순한 잡음이 아니라, 사람이 놓칠 수 있는 문제를 잡아낸 결과이기도 합니다.

작성자는 최대 두 라운드까지만 허용합니다. 두 번째 시도에서도 통과하지 못하면 변경을 자신에게 넘기고, 추가 작업을 할 가치가 있는지 직접 판단합니다. 하지만 두 문장짜리 변경을 검토하는 데 두 라운드를 쓰면 오전 시간 전체가 사라질 수 있다는 점이 고민입니다. 실패가 발생했다는 사실은 진전처럼 보이지만, 모든 실패에 같은 횟수의 재시도를 배정하는 것이 효율적인지는 아직 결정하지 못했습니다.

■ 라운드 수보다 실패의 종류를 보라는 제안

상위 댓글에서는 재시도 횟수 자체가 잘못된 변수일 수 있다고 지적합니다. 한 가지 분류는 작성자의 의도나 명세에 관한 주장, 외부 세계가 실제로 어떻게 동작하는지에 관한 주장, 특정 기기·스토어의 throttling·quota처럼 재현하기 어려운 동작에 관한 주장입니다. 첫 번째 유형은 라운드를 늘리기보다 번호 매긴 목록과 요구사항을 다시 작성해야 합니다. 두 번째 유형은 리뷰로 판단하지 말고 API가 실제로 존재하는지, 플랫폼이 해당 동작을 지원하는지, 패키지의 type definition이 무엇을 말하는지 직접 검증해야 합니다. 세 번째 유형은 리뷰나 재시도로 해결하기 어렵기 때문에, 추측에 의존하지 않는 결정론적 경로를 선택해야 한다는 설명입니다.

이 댓글은 플랫폼 SDK의 메서드를 사용해 버튼을 눌러도 아무 일도 일어나지 않는 버그를 고친 사례도 제시합니다. 코드는 컴파일되고 실행됐지만 해당 메서드는 플랫폼 SDK의 두 주요 버전 전부터 제거된 상태였습니다. 코드가 실패를 포착해 fallback으로 넘어갔기 때문에 겉으로는 정상처럼 보였고, 어떤 리뷰어도 잡아내지 못했지만 패키지의 타입 정의를 확인하면 20초 안에 발견할 수 있었다고 합니다. 또 다른 사례에서는 rating API가 예외를 발생시키지 않았다는 이유로 true를 반환했지만, 운영체제가 표시 동작을 조용히 무시해 실제로는 아무것도 나타나지 않았습니다. 성공처럼 보이는 반환값과 실제 결과가 다르면, 실패 시 실행되어야 할 fallback도 동작하지 않을 수 있다는 문제입니다.

■ 검토를 명세 작성 전으로 앞당기기

다른 댓글은 실패가 실행 가능한지와 관찰 가능한지를 판단 기준으로 제시합니다. 검토자가 위반한 acceptance criterion을 직접 인용하고, 재현 가능한 테스트를 제시하며, 명세의 모호함과 구현 결함을 구분한다면 후속 라운드를 진행할 근거가 생깁니다. 반대로 두 번째 검토에서도 같은 증거만 반복된다면 변경을 버리거나 요구사항을 다시 작성해야 합니다. 이 방식에서는 두 라운드가 단순한 재시도 횟수가 아니라 의사결정 규칙이 됩니다.

특히 이번 사례처럼 검토 대상 자체가 번호 매긴 지침을 수정하는 작업이라면, 구현보다 먼저 명세를 검토하자는 제안이 나옵니다. 작성 전에 검토 모델에 지침 목록만 보여주고 모호한 부분을 찾게 하면, 6개 중 5개를 통과하는 정도의 실패를 실제 작성이 시작되기 전 2분 안에 발견할 수 있다는 설명입니다. 명세가 먼저 검토를 통과한 뒤에는 기존의 두 라운드 규칙을 그대로 적용할 수 있습니다.

또 다른 참여자는 리뷰의 이의 제기가 파일, 줄, 값, 실패할 것으로 예상되는 사례처럼 직접 확인할 수 있는 대상을 지목하는지 보라고 합니다. 구체적인 대상을 제시하면 다음 라운드에서 확인할 기준이 생기지만, 코드보다 산문을 검토할 때 흔한 판단형 이의 제기는 같은 문장을 두 모델이 반복해서 다르게 평가하게 만들 수 있습니다. 마지막 댓글은 5개 중 5개에 가까운 instruction 실패와 10개 중 6개인 실패를 구분하고, 재시도 예산을 영향 범위와 누락된 규칙의 존재 여부에 따라 배정하자고 제안합니다. 또한 나중에 버그나 지원 문의로 이어진 실패를 추적하면, 어떤 종류의 검토 실패에 추가 라운드를 투자할지 판단할 수 있다고 묻습니다.

■ Indie Hackers 반응

• @alexfleet — 저에게 가장 유용한 게이트는 실패가 실행 가능하고 관찰 가능한지 여부입니다. 리뷰어가 위반된 acceptance criterion을 인용하고, 재현 가능한 테스트를 가리키며, 명세의 모호함과 구현 결함을 구분합니까? 두 번째 패스에서 같은 증거가 나오면 변경을 버리거나 요구사항을 다시 작성하고, 새로운 실패 경로가 드러나면 계속 진행합니다. 그러면 두 라운드 예산은 단순한 재시도 횟수가 아니라 의사결정 규칙이 됩니다.

• @peptides8 — 두 실패가 모두 앱 코드가 아니라 작성된 지침에서 발생했다는 부분을 먼저 조치하겠습니다. 리뷰어가 번호 매긴 목록을 기준으로 변경을 평가하고, 그 변경 자체가 목록을 수정하는 것이라면 테스트 대상은 명세이며, 어떤 횟수의 작성 라운드도 명세 문제를 고치지 못합니다. 제가 도움을 받은 방법은 작성 전에 리뷰를 앞당기는 것이었습니다. 번호 매긴 목록만 리뷰어에게 주고 목록의 모호한 부분을 찾게 합니다. 그러면 5개 중 5개에 가까운 실패를 오전 시간이 아니라 2분의 비용으로 잡을 수 있습니다. 명세가 자체 검토를 통과한 뒤에는 두 라운드 규칙을 그대로 유지할 수 있습니다.

• @to21as — 제 판단 기준은 이의 제기가 제가 직접 확인할 수 있는 것을 지목하는지 여부입니다. 파일, 줄, 값, 또는 실패할 것이라고 주장하는 사례가 있습니까? 그렇다면 다음 라운드가 가치 있습니다. 두 번째 패스가 확인할 구체적인 대상이 생기고, 그 이의 제기가 맞는지 아닌지를 판별할 수 있기 때문입니다. 이의 제기가 판단에 불과하다면, 코드보다 산문에서 대부분 그렇듯 두 번째 라운드는 주사위를 다시 굴리는 일에 불과합니다. 두 모델은 문장이 바뀔 때까지 같은 줄에 계속 다른 판단을 내릴 것입니다. 이것은 DannieDan의 불충분하게 구체적인 명세라는 지점을 반대편에서 보여줍니다. 작성자의 리뷰어는 실패한 줄을 인용합니까, 아니면 판정만 제시합니까?

• @Shaid — 5개 중 5개에 가까운 instruction 실패와 10개 중 6개 실패는 구분할 만한 차이입니다. 저는 영향 범위와 실패가 누락된 규칙을 드러내는지에 따라 재시도 예산을 정하고, 다시 실행하기 전에 번호 매긴 목록을 고치겠습니다. 실패한 변경 중 나중에 버그나 지원 문의가 되는 항목을 추적하고 있는지도 궁금합니다.

원문: Indie Hackers / 번역·요약: Trawling