OpenCodeReview AI Code Review 실측: Git Diff·버그·보안·품질을 자동 검사하면 실제 프로젝트에서 몇 건이 나올까?

먼저: OpenCodeReview가 실제로 보는 것

이름만 보면 OpenCode(opencode serve 코딩 에이전트)와 한 덩어리로 들린다. 다른 제품이다. OpenCodeReview는 알리바바 내부에서 2년 쓰인 AI 리뷰 도우미의 CLI다. Git 변경을 읽고 구조화된 라인 댓글을 내며 NPE, 스레드 안전, XSS, SQL 인젝션 규칙을 내장하고 OpenAI / Anthropic 호환 엔드포인트에 붙는다. 저장소: alibaba/open-code-review. 문서: open-codereview.ai.

“잘했다고 칭찬하는 봇”이 필요하면 다른 도구를 봐라. 채팅 모델은 붙여 넣은 조각만 본다. 호출자도, 옆 파일의 락도 모른다. OpenCodeReview의 설계는 결정적 선별 + 깊은 Agent다. 볼 파일을 정하고 언어별 체크리스트를 넣은 뒤 Agent가 file_read와 검색으로 맥락을 가져온다.

이미 OpenCode 셀프호스트 4GB / 8GB / 16GB 글이 있다. 그건 코딩 에이전트 메모리 이야기다. 이 글은 ocr review만 다룬다. Git Diff, 버그, 보안, 품질을 자동 검사할 때 실제 프로젝트에서 몇 건이 나오는지.

공식 문구는 “수만 개발자, 수백만 결함”이다. 알리바바 규모 누적이고 다음 PR의 약속이 아니다. 머지 전 두 번째 눈이 필요하면 맞다. 기계 서명으로 프로덕션에 올리고 싶다면 README도 이 실측도 서명하지 않는다.

Git Diff를 읽는 세 모드

“Git Diff 자동 검사”로 온 독자가 알고 싶은 것은 “내가 무엇을 바꿨는가”다. CLI는 이를 서로 배타적인 세 모드로 나눈다. 섞으면 바로 에러다. 플래그: CLI Reference.

범위 모드는 merge-base를 쓴다. 사람이 PR을 보는 방식에 가깝다. main에 나중에 들어온 무관 커밋이 섞이지 않는다. 공식 GitHub Action도 같다. merge-base를 구한 뒤 ocr review --from MERGE_BASE --to HEAD_SHA --format json하고 라인 댓글을 붙인다.

네 번째는 ocr scan이다. 의미 있는 Git 이력이 없거나 낯선 디렉터리를 감사할 때 파일 전체를 본다. 토큰과 노이즈가 오른다. 일상 머지는 diff, 레거시 인수는 scan을 검토하라.

본 리뷰 전에 반드시 ocr review --preview. 필터만 돌고 모델 비용은 없다. 파일이 will_review인지 확장자·삭제·테스트 경로로 빠졌는지 보여 준다. 실측에서 이미지와 lockfile이 있는 PR은 “커 보이는” 파일의 절반이 LLM 전에 사라졌다. 맞다.

5분: 설치, 모델, preview

권장은 npm 글로벌이다. 공식 install.sh와 GitHub Release 정적 바이너리도 있다. Git은 ≥ 2.41. 모델이 없으면 ocr review는 댓글을 만들지 않는다(이미 쓰는 코딩 에이전트에 넘기는 Delegation Mode 제외).

npm install -g @alibaba-group/open-code-review
ocr version
ocr config provider
ocr config model
ocr llm test

cd /path/to/your-repo
ocr review --preview
ocr review --from main --to HEAD --format json --audience agent

설정은 ~/.opencodereview/config.json. CI에서는 ocr config set 또는 기존 ANTHROPIC_* / OCR_LLM_*. 댓글 언어는 ocr config set language Korean, 기본은 영어. 프로젝트 규칙은 .opencodereview/rule.json을 커밋할 수 있다. 키는 저장소에 넣지 마라.

npm 설치는 기본으로 백그라운드 업데이트(약 18분 쿨다운)를 한다. CI에서는 OCR_NO_UPDATE=1과 버전 고정. 세션은 ~/.opencodereview/sessions/. ocr viewer는 localhost:5483에서 재생용이지 공개 서비스가 아니다.

메모리 추정을 OpenCode 셀프호스트 글에서 베끼지 마라. 무거운 일은 LLM API와 병렬 Git 서브프로세스다. LSP를 상주시키지 않는다. --concurrency 기본은 8. 노트북을 닫으면 범위 리뷰가 중간에 죽는다. 깨어 있는 러너가 출장 노트북에서 한 판 거는 것보다 정직하다.

실측: 세 변경 팩에서 나온 것

같은 설정(OpenAI 호환, 중간 규모 채팅 모델, 시스템 규칙+프로젝트 규칙 병합)으로 실제로 PR이 되는 형태의 세 팩을 봤다. 장난감 10줄이 아니다. 각 팩은 --preview 후 ocr review --from --to --format json. 댓글을 필수·권고·스타일·오탐으로 나누었다. 한 번의 스냅샷이고 모델을 바꾸면 숫자는 흔들린다. 구성비가 합계보다 쓸모 있다.

필수 7건은 보안 3, 결함 4. 보안은 문자열 연결 쿼리, 이스케이프 없는 HTML 출력, 내부 오류 문구를 클라이언트에 반환. 결함은 nil을 객체처럼 사용, 락 없는 map 쓰기, %w 없이 원인이 사라지는 에러. 공식 규칙집(NPE, 스레드, XSS, SQL)에 그대로 떨어진다. 산문이 아니다.

권고 6건은 타임아웃 없음, 비멱등 재시도, 이메일이나 본문이 들어간 로그. 사람이 금요일 오후에 삼키는 종류다. Agent는 지치지 않는다.

스타일 10건이 가장 큰 통이다. 이름, 조기 반환, 함수 추출. 쓸모 있지만 신호를 희석한다. 손대지 않으면 3주 차에 리뷰 전체를 접는다. 시끄러운 PR 봇과 같은 병리다.

오탐 4건은 지루해서 좋다. 테스트 픽스처 SQL을 운영 인젝션으로 봄, 이미 파라미터화된 쿼리 재지적, Go 1.22 이후 고친 루프 변수. 4건 중 3건은 --preview 후 테스트 경로 제외로 사라진다. 모델보다 필터를 먼저 의심하라.

공식 예시 규모와도 맞다. 범위 리뷰 한 번은 “파일 9, 댓글 10여 개, 1분 전후, 토큰 2만 전후”가 흔하다. 이번은 독립 범위 세 개라 그 약 3배. 토큰 창의 약 80%를 먹는 단일 파일 diff는 LLM 전에 버린다. 거대 생성물과 lockfile은 preview에서 사라져야 하고 청구서에 남으면 안 된다.

버그·보안·품질: 잡는 것과 못 잡는 것

27건을 제목의 네 단어로 나누는 편이 “몇 건 발견”보다 사용법에 가깝다.

Agent가 파일 전체를 읽으므로 “초록 줄만”보다 한 단계 강하다. 공식의 “락 없는 map 쓰기”가 전형이다. diff는 대입 한 줄, 공유 상태는 파일 위에 이미 있다. diff 전용 봇은 놓치고 file_read가 맥락을 끌어온다. 패치만 보는 Copilot Review 계열과의 홍보 차이다. 그쪽은 빠르고 조용하며 파일 횡단이 약하다.

일부러 넣은 놓침도 봤다. 잘못된 할인식, 통화 필드 혼동, 승인 전에 열리면 안 되는 API. 댓글 제로. 모델에 도메인 사전이 없다. --background로 PR 설명을 넣으면 조금 나아진다. 요구사항 리뷰를 대체하지는 않는다.

보안 댓글은 단서이지 판결이 아니다. “여기서 SQL을 잇고 있다”는 드라이버와 권한과 데이터 등급을 직접 확인하는 일이다. 이 글은 악용 절차를 보여 주지 않는다. 표시가 달렸는지만 기록한다. 쓰기 경계도 조이려면 Agent가 파일을 안전하게 고치는 VFS를 보라. 리뷰는 읽기 전용이고 디스크를 쓰는 것은 코딩 에이전트다.

CI: GitHub Actions, 규칙, 오탐

로컬이 되면 팀이 원하는 것은 PR의 라인 댓글이다. 공식 composite Action은 신뢰할 수 있는 base를 체크아웃하고(포크 작업 트리를 펼치지 않음), head git 객체를 가져오고, merge-base를 계산하고, ocr review --format json한 뒤 Review API로 라인 댓글과 sticky 요약을 붙인다. 트리거는 PR open/synchronize 또는 /open-code-review 댓글.

권한은 최소. contents: read, 댓글을 쓸 때만 pull-requests: write. 키는 Secrets, 모델 이름은 Variables. 포크는 기본으로 저장소 Secret을 못 읽는다. 보호이지 고장이 아니다. 외부 기여를 자동 심사하려고 신뢰할 수 없는 코드 체크아웃과 pull_request_target을 묶지 마라. 비밀 유출 조합이다. GitHub 자체 강화: Security hardening for GitHub Actions.

규칙은 네 층. --rule, 프로젝트 .opencodereview/rule.json, 홈 글로벌, 내장 시스템. ocr rules check로 어떤 층이 이겼는지 본다. merge_system_rule: true로 로그 두 줄 커스텀이 Java NPE 목록을 덮어쓰지 않게 한다. 테스트·생성물·vendor 제외가 나중에 오탐으로 싸우는 것보다 싸다.

macOS에서 Xcode diff를 같은 흐름에 태우려면 runner가 ocr보다 더 손이 간다. 구축과 검수는 GitHub Actions macOS 자체 호스팅 Runner. 잠들지 않는 머신과 노트북과 다투지 않는 키가 재현성을 만든다.