코드를 고친 뒤 리뷰를 통과했더라도 마지막 수정이 리뷰에 들어가지 않았다면 그 승인은 현재 코드를 설명하지 못합니다. 별도 리뷰어를 추가할 때 중요한 것은 리뷰 횟수와 함께 무엇을 검토했는지 남기는 일입니다.

OpenQodex는 코딩 에이전트의 변경을 별도 프로세스에서 검토합니다. 2026년 11월 1일 확인한 문서를 기준으로 설명하며, 이날 처음 출시됐다는 뜻은 아닙니다. 도구 설치나 모델 리뷰 실행은 하지 않았습니다.

작성자와 리뷰어를 분리하면 무엇이 달라지나

공식 설명의 흐름은 변경에 맞는 스캐너 실행, 후보 결함 발견, 별도 검증, 보고서 작성입니다. 후보에 인용한 코드가 실제 존재하는지도 스크립트로 확인합니다. 이는 근거 없는 파일·행 인용을 줄이는 장치이지, 그 줄이 결함이라는 논리를 증명하는 장치는 아닙니다.

별도 프로세스는 작성 세션의 결론을 그대로 승인하는 일을 줄일 수 있습니다. 그러나 같은 모델과 같은 누락된 명세를 공유하면 두 리뷰어가 같은 오류를 놓칠 수 있습니다. 프로세스가 독립적이라는 말과 오류 확률이 독립적이라는 말은 다릅니다.

도입 전에는 README의 호스트와 리뷰어 구분도 읽어야 합니다. Cursor·Cline에서 시작할 수 있어도 리뷰어는 Claude Code 또는 Codex입니다. 시작하는 도구가 곧 검토 모델이라는 가정은 맞지 않습니다.

리뷰 결과를 변경과 묶어야 하는 이유

다음은 OpenQodex 내부 코드가 아닌 교육용 최소 모델입니다. Node.js 18 이상에서 파일로 저장해 node receipt.mjs로 실행할 수 있습니다. 로컬 실행했으며 외부 서비스는 사용하지 않습니다.

const reviewed = { tree: 'snapshot-a', complete: true, verdict: 'passed' };
function canPromote(currentTree) {
  return reviewed.complete && reviewed.verdict === 'passed'
    && reviewed.tree === currentTree;
}
console.log('same snapshot:', canPromote('snapshot-a'));
console.log('edited snapshot:', canPromote('snapshot-b'));

same snapshot: true
edited snapshot: false

실제 시스템은 문자열 두 개보다 복잡합니다. 작업 트리, 미추적 파일, 대상 브랜치와 푸시할 커밋 범위를 어떤 식별자로 묶는지 확인해야 합니다. 이 예제는 암호학적 영수증도 Git hook 구현도 아니며 우회 방지를 보장하지 않습니다.

빠른 시작 문서는 기본 설정이 경고이고 차단은 설정이 필요하다고 설명합니다. 팀이 “리뷰 도구가 설치되어 있다”를 병합 정책으로 사용하려면, 실제 차단 조건과 설정 소유자를 따로 확인해야 합니다. 완료된 리뷰도 모든 버그가 없다는 뜻은 아닙니다.

추가로 찾은 결함만 세어 보기

도입 효과는 리뷰 댓글 수로 판단하기 어렵습니다. 다음은 편집부가 제안하는 비교 절차입니다. 수행한 성능 평가가 아닙니다.

  1. 과거에 수정한 버그의 수정 전 변경과 정상 변경을 함께 준비합니다. 비밀정보와 고객 데이터는 제거합니다.
  2. 기존 테스트·정적 분석 결과를 먼저 보관한 뒤 같은 변경에 별도 리뷰를 적용합니다.
  3. 새로운 발견이 재현되는지 담당자가 확인하고, 기존 도구가 이미 찾은 결함은 중복으로 셉니다.
  4. “리뷰만 추가로 찾은 재현 가능한 결함 수 / 전체 확인된 결함 수”와 잘못된 지적을 처리한 시간을 함께 기록합니다.

예를 들어 기존 도구가 8개, 별도 리뷰가 그중 6개와 새로운 2개를 찾았다면 리뷰의 추가 기여는 2개입니다. 이를 리뷰 재현율 100%라고 부르면 안 됩니다. 아직 발견되지 않은 결함의 수를 모르기 때문입니다. 정상 변경도 넣어야 불필요한 차단을 볼 수 있습니다.

계정을 재사용해도 데이터 경계는 남는다

보안 문서에 따르면 리뷰어가 읽는 코드는 로그인한 모델 서비스로 전달됩니다. 별도 키가 필요 없다는 설명은 추가 비용이 없거나 코드가 기기를 떠나지 않는다는 뜻이 아닙니다. 조직의 코드 반출 정책과 구독 사용량을 확인해야 합니다.

권한·역할을 나눠 운영하는 법은 멀티 에이전트의 작업 분해와도 연결됩니다. OpenQodex의 효용은 승인 문구를 하나 더 얻는 데 있지 않습니다. 현재 변경에 대한 근거를 남기고, 사람이 확인할 결함 후보를 기존 도구보다 얼마나 더 제공하는지 측정할 수 있을 때 도입 근거가 생깁니다.

아래 유료 강의는 에이전트 실행·검증 루프와 역할 전달을 다룹니다. OpenQodex 자체의 설치 실습이나 탐지 성능을 제공한다는 의미는 아닙니다.