Open Code Review 사용법: 검토 범위와 지적 사항 확인하기
알리바바 Open Code Review의 검토 범위와 정밀도, 재현율을 이해하고, 작은 연습 코드에서 미리보기와 실제 검토 결과를 구분하는 방법을 안내합니다.
목차
세 줄로 먼저 읽기
이번 방문에서 한 편은 바로 볼 수 있습니다.
Open Code Review는 알리바바가 공개한 AI 코드 검토 도구입니다. 코드리뷰는 수정한 코드에 오류나 빠진 조건이 있는지 살펴보는 과정입니다. 터미널에서 ocr 명령으로 실행하며, Git의 변경 내역을 읽어 문제 후보와 위치를 제시합니다. Git은 파일의 변경 이력을 관리하는 도구입니다. 공식 저장소
이 글은 2026년 10월 4일 공식 문서를 기준으로 합니다. 첫 단계는 모델을 호출하지 않는 검토 범위 확인입니다. 결과에 지적이 없더라도 사람이 기대한 동작을 직접 확인하는 과정이 필요합니다.
어떤 일을 맡기는 도구인가요?
일반 코딩 에이전트가 작성과 수정 및 검토를 폭넓게 수행한다면, Open Code Review는 검토 절차에 집중합니다. 검토할 파일 선정과 규칙 적용을 프로그램이 처리하고, 문제 여부와 필요한 맥락 판단은 연결한 모델이 수행합니다.
공식 문서는 파일을 빠뜨리거나 위치를 잘못 지적하는 문제를 줄이기 위한 설계라고 설명합니다. 이는 모든 파일을 반드시 검토하거나 모든 결함을 찾는다는 보장은 아닙니다. 제외 규칙과 실행 결과를 함께 확인합니다.
프로젝트는 Apache-2.0 라이선스로 공개되어 있습니다. 라이선스가 회사의 코드 반출이나 도구 도입 승인을 대신하지는 않습니다. 모델을 어디에 연결하는지도 별도로 확인해야 합니다.
이 그림의 3M+는 코드리뷰 작업 수입니다. 모두 실제 결함으로 확정된 건수라는 뜻이 아닙니다. 다운로드와 사용자 수 역시 검토 정확도를 측정한 지표가 아닙니다.
정밀도와 재현율은 분모가 다릅니다
가상의 코드에 실제 결함 12개가 있다고 가정합니다. 도구가 10개를 지적했고 그중 진짜 결함이 6개라면 다음과 같습니다.
| 지표 | 계산 | 뜻 |
|---|---|---|
| 정밀도 | 6 ÷ 10 = 60% | 지적한 것 중 실제 결함의 비율 |
| 재현율 | 6 ÷ 12 = 50% | 실제 결함 중 찾은 비율 |
| 오탐 | 10 - 6 = 4개 | 결함이 아닌데 지적한 수 |
| 놓친 결함 | 12 - 6 = 6개 | 실제 결함 중 찾지 못한 수 |
F1은 정밀도와 재현율을 함께 반영하는 값입니다. 둘의 조화평균이며, 이 예에서는 2 × 0.6 × 0.5 ÷ (0.6 + 0.5)로 약 54.55%입니다. ‘코드 전체의 54.55%가 안전하다’는 뜻은 아닙니다.
공개 벤치마크는 해당 조건의 비교입니다
AACR-Bench는 여러 저장소의 코드 검토를 비교하는 평가입니다. 공개 데이터 카드에는 올바른 검토 의견 1,505개와 잘못된 의견 640개로 구성한 2,145개 의견의 데이터도 설명돼 있습니다. ‘10개 언어’는 한국어 같은 자연어가 아닌 프로그래밍 언어를 뜻합니다. 데이터 설명
공식 사이트의 공개 표에서 같은 모델인 Claude-4.6-Opus를 사용한 두 행을 읽으면 다음과 같습니다. 이는 제작 측이 공개한 비교이며 내 저장소에서 재현한 결과는 아닙니다.
| 검토 도구 | F1 | 정밀도 | 재현율 | 평균 시간 | 평균 토큰 |
|---|---|---|---|---|---|
| Open Code Review v1.3.1 | 25.10% | 33.90% | 20.00% | 1분 23초 | 385K |
| Claude Code v2.1.169 | 11.57% | 7.23% | 28.90% | 13분 6초 | 5,664K |
이 표에서는 전용 도구의 정밀도가 높고 재현율은 낮습니다. 그래서 ‘범용 도구는 항상 더 많이 찾는다’거나 ‘전용 도구가 모든 업무에서 더 좋다’고 일반화하지 않습니다. 표의 모델과 도구 버전도 현재 사용하는 조합과 같은지 봅니다. 공식 표의 원자료
토큰은 모델이 입력과 출력을 처리하는 단위이며 K는 천 단위입니다. 위 표의 비율은 385 ÷ 5,664, 약 6.8%로 약 14.7분의 1입니다. 상단 그림의 1,000개 PR 비교에 표시된 ‘9분의 1’과는 비교 대상이 다릅니다. PR은 코드 변경을 검토해 달라는 요청입니다. 입력과 출력 단가, 캐시 및 재시도에 따라 요금이 달라지므로 토큰 비율을 그대로 청구액 비율로 읽지 않습니다.
설치 전에 준비물을 확인합니다
npm 방식은 Git 2.41 이상과 Node.js 18 이상, npm이 필요합니다. Node.js는 자바스크립트를 실행하는 프로그램이고 npm은 패키지를 설치하는 도구입니다. 운영체제 터미널에서 현재 버전을 확인합니다.
git --version
node --version
npm --version명령을 찾지 못하거나 요구 버전보다 낮으면 해당 도구부터 준비합니다. 그다음 아래 명령으로 설치하고 실행 여부를 확인합니다. 공식 시작 안내
npm install -g @alibaba-group/open-code-review
ocr version
ocr --helpnpm 설치판은 자동 업데이트 기능이 있으므로 실제 검토 기록에는 실행한 버전을 남깁니다. Node.js 없이 사용하는 운영체제별 실행 파일도 제공합니다. 설치 경로 오류는 재설치를 반복하기 전에 터미널이 설치 위치를 찾는지 확인합니다. 설치와 업데이트 설명
첫 연습: 검토 대상 파일만 확인합니다
새 폴더 ocr-practice를 만들고 편집기로 age.js를 저장합니다. 아래 코드는 18세 이상을 허용하는 가상의 연습 규칙입니다. 실제 서비스의 나이 확인 방식은 다루지 않습니다. true는 조건을 만족한다는 참, false는 만족하지 않는다는 거짓을 뜻합니다.
function canJoin(age) {
return age >= 18;
}
console.log(canJoin(18));터미널에서 이 새 폴더를 연 뒤 기준 상태를 커밋합니다. 커밋은 변경 이력을 남기는 동작이며 외부 업로드가 아닙니다.
git init
git add age.js
git commit -m "Add age practice"Git 작성자 정보 오류가 나오면 본인의 Git 설정을 확인하고 커밋을 완료합니다. 이어 편집기에서 >=를 >로 바꾸고 저장합니다. >=는 이상, >는 초과라는 뜻입니다. 이번에는 일부러 경계값인 18에서 문제가 생기도록 바꾼 것입니다.
git diff -- age.js
ocr review --preview미리보기에서 age.js가 검토 대상인지, 제외됐다면 이유가 무엇인지 확인합니다. --preview는 모델을 호출하지 않고 대상과 제외 사유를 보여줍니다. 미리보기에 파일이 있다는 것과 결함을 찾아냈다는 것은 다릅니다. 미리보기 명령
기본 ocr review는 커밋할 대상으로 선택한 변경뿐 아니라 아직 선택하지 않은 변경과 새 파일도 포함합니다. 파일을 스테이징했다고 검토 범위가 그 파일로 제한되지는 않습니다. 변경분 대신 파일 전체를 볼 때는 ocr scan --path age.js --preview로 대상을 먼저 확인할 수 있습니다.
파일이 안 나오면 같은 폴더인지, 저장했는지, 이미 수정본을 다시 커밋하지 않았는지 확인합니다. 첫 연습은 ‘어느 파일의 어떤 변경을 검토할 예정인지’를 설명하면 완료입니다.
실제 AI 검토는 모델 연결 후 진행합니다
실제 검토까지 할 분은 허용된 제공자와 모델, 사용료 및 코드 전송 조건을 확인합니다. API 키는 모델 서비스에 접근하는 인증값입니다. 아래 대화형 설정에서 입력하고 블로그나 코드에 붙여 넣지 않습니다.
ocr config provider
ocr config model제공자 설정은 연결 시험도 수행합니다. 별도 API 요청이 가능한 계정인지 확인하며, 기존 채팅 구독만으로 모든 API 사용이 포함된다고 가정하지 않습니다.
연습 코드의 요구사항을 함께 전달하면 모델이 무엇을 기준으로 봐야 하는지 알 수 있습니다. 다음 명령은 미리보기와 달리 실제 모델을 호출합니다.
ocr review --background "18세 이상이면 canJoin이 true를 반환해야 합니다."파일로 결과를 남길 계획이면 위 명령 대신 아래 명령을 한 번 실행합니다. ../ocr-result.json은 연습 폴더의 한 단계 위에 저장하는 경로입니다. 두 명령을 모두 실행하면 검토도 두 번 수행합니다.
ocr review --background "18세 이상이면 canJoin이 true를 반환해야 합니다." --format json --output ../ocr-result.json검토를 끝낸 뒤에는 저장된 파일을 열어 봅니다. 같은 이름의 이전 결과가 있다면 이번 실행의 상태와 파일 갱신 여부를 확인합니다.
검토 결과에 age.js의 비교식과 18이 지적되는지 확인합니다. 반드시 같은 문구의 지적이 나온다고 보장할 수는 없습니다. 직접 실행해 확인할 수도 있습니다.
node age.js일부러 바꾼 > 상태에서는 false가 나옵니다. 요구사항상 기대값은 true이므로 결함을 재현한 것입니다. >=로 고치고 다시 실행해 true인지 확인합니다. AI가 지적하지 않았어도 이 검사는 필요합니다.
빈 결과와 실패를 구분합니다
JSON은 이름과 값을 일정한 형식으로 저장하는 데이터입니다. 결과의 comments는 지적 목록이지만, 이 목록 하나만 보지 않습니다.
| 항목 | 확인할 내용 |
|---|---|
status | 완료, 일부 완료, 실패 또는 제외 상태 |
summary.files_reviewed | 실제 검토한 파일 수 |
warnings | 특정 파일의 실패나 제한 |
comments | 파일, 줄 위치와 문제 설명 |
버전에 따라 상태 이름과 제공 필드는 다를 수 있습니다. skipped는 검토 대상이 없거나 지원되는 파일이 없는 경우도 포함합니다. 빈 지적 목록은 무결함 인증이 아닙니다. 종료 코드 0이어도 경고가 남을 수 있습니다. 결과 형식과 종료 상태
401이나 403 같은 연결 오류라면 인증과 접근 권한을 확인합니다. 코드 결함으로 해석하지 않습니다. 부분 실패라면 성공한 파일과 미검토 파일을 나눠 기록합니다.
위임 모드도 기존 AI의 사용량을 씁니다
위임 모드는 Open Code Review가 파일 선정과 규칙을 제공하고, 연결한 코딩 에이전트가 자신의 모델로 검토하는 방식입니다. OCR용 API 키를 별도로 넣지 않아도 되지만, 기존 AI의 구독 한도나 비용은 사용합니다.
ocr delegate preview
ocr delegate rule age.js위 두 명령은 검토 준비 정보를 얻는 단계입니다. 이것만 실행했다고 AI 검토까지 끝난 것은 아닙니다. 실제 검토는 해당 에이전트에 맡기는 절차가 필요합니다. 위임했다고 코드가 자동으로 사내에만 머무는 것도 아니며, 그 에이전트의 모델 연결과 전송 조건을 확인합니다. 위임 모드 안내
조건 하나를 바꿔 다시 확인합니다
연습 규칙을 ‘65세 이상 허용’으로 바꾸고 코드의 기준 숫자와 출력 입력도 65로 맞춥니다. > 상태에서는 false, >=에서는 true인지 확인합니다. 64, 65, 66도 각각 시험하면 경계 전후의 결과를 비교할 수 있습니다.
다음에 도구를 비교할 때는 같은 코드와 같은 요구사항으로 검토합니다. 어떤 지적을 실제 재현했는지, 무엇을 놓쳤는지, 걸린 시간과 사용량을 함께 적으면 공개 순위표와 내 업무의 차이를 알 수 있습니다.
Sources
제대로 이해했는지 한 문제로 확인해 볼까요?
답을 고르면 바로 풀이가 나와요.
결과의 comments가 빈 배열이면 무엇부터 확인하나요?
이 글이 도움이 되었나요?
메일, 회의록, 리포트처럼 반복되는 일을 AI로 자동화하는 순서와 안전장치를 다룹니다
코스 전체 보기 →
새 글과 AI 소식을 메일로 받아 보세요
AI가 바꾸는 일과 도구, 측정 실무 이야기를 매주 한 번 보내 드려요.