어제 스타 3,290개 붙은 alibaba/open-code-review, 진짜 코드 리뷰어를 대체할까?

① 어제 스타 3,290개, 이건 대체 뭘 해주나

저는 어제 저장소 첫 화면을 캡처했습니다. 눈에 먼저 들어온 숫자는 어제 스타 +3,290개, 전체 스타 33,981개였습니다. 포크는 2,417개이고, Go로 작성된 Apache-2.0 라이선스 프로젝트입니다. 이렇게 관심이 몰린 alibaba/open-code-review는 한 문장으로 말하면, Git 변경 사항이나 파일 전체를 LLM 에이전트와 규칙 기반 파이프라인으로 검토해 주는 단말기(CLI) 도구입니다. CLI는 터미널에 명령어를 입력해 사용하는 프로그램을 뜻합니다.

기존에는 개발자가 Pull Request의 diff, 즉 변경된 코드 조각을 직접 읽으며 문제를 찾거나, Claude Code 같은 범용 AI 코딩 에이전트에 리뷰를 맡기는 흐름이 일반적이었습니다. 이 프로젝트는 변경 파일을 설정한 LLM에 전달하고, 에이전트가 전체 파일을 읽거나 코드베이스를 검색하면서 맥락을 확인하도록 구성돼 있습니다. `ocr review`는 스테이징·언스테이징·미추적 변경, 브랜치 범위, 단일 커밋을 대상으로 하고, `ocr scan`은 Git diff가 없어도 저장소 전체나 특정 디렉터리·파일을 살펴봅니다. 결과는 특정 파일의 특정 줄을 가리키는 구조화된 댓글로 만들고, NPE·스레드 안전성·XSS·SQL 인젝션 같은 규칙 기반 점검도 포함합니다. README의 주요 기능 8건을 코드와 대조한 결과도 8건 모두 확인됐습니다.

README에 따르면 알리바바 내부에서 2년 동안 수만 명의 개발자가 사용했고 수백만 건의 결함을 찾았다고 합니다. 다만 이는 저장소가 제시하는 설명입니다. 벤치마크 역시 README의 주장으로, 50개 오픈소스 저장소와 200개 Pull Request, 10개 언어를 대상으로 범용 에이전트보다 정밀도와 F1이 높고 토큰 사용량은 약 1/9이었다고 소개합니다. 대신 재현율은 낮은 선택이었다고 밝힙니다. 첫인상 평점은 총점 4.8점입니다.

📌 먼저 보는 핵심 답변

• 총점 4.8/5점, A등급입니다.
• README가 말한 Git diff·전체 파일 스캔·LLM 에이전트·줄 단위 댓글·내장 규칙 등 8가지를 코드 근거에서 모두 확인했습니다.
• 다만 소스 코드를 외부 LLM에 보낼 수 있는 구조인 만큼 API 비용과 코드 보안 정책을 먼저 확인해야 합니다.

② 받아서 뜯어보니: Go CLI부터 웹 화면까지

저는 어제 저장소를 클론한 뒤 파일 405개를 폴더 단위로 열어봤습니다. 출발점은 `cmd/opencodereview`였습니다. Go CLI의 진입점으로 보이고, 실제 기능은 `internal/agent`·`llm`·`scan`·`session`·`viewer`로 나뉘어 있습니다. 에이전트는 리뷰 작업을 조정하고, `llm`은 모델 연결, `scan`은 전체 파일 검사, `session`은 중단·재개 흐름, `viewer`는 결과 화면을 맡는 구조로 읽힙니다. 코드에서 README가 말한 `review`, `scan`, 파일 읽기·검색 도구, 줄 단위 댓글, NPE·XSS·SQL 인젝션 규칙, JSON 저장, 세션 재개, 위임 모드 관련 흔적도 대조했습니다.

연동 예제도 눈에 띄었습니다. `examples` 아래에 GitHub Actions, GitLab CI, Gerrit을 비롯해 Bitbucket Pipelines, Codeup CI, Gitflic CI가 각각 들어 있습니다. 에디터 쪽에는 `extensions/vscode`, 웹 화면 쪽에는 `pages`가 있고, `pages` 안에 `package.json`, TypeScript·Webpack·Tailwind 설정과 Vitest 설정이 함께 있습니다. 즉 하나의 Go CLI만 있는 저장소라기보다 CI 연동, VS Code 확장, 웹 뷰어까지 나뉜 구성입니다.

다만 제가 확인한 README 앞부분 원문에는 설치 명령 3줄이 포함되어 있지 않았습니다. 확인하지 못한 명령을 설치 절차처럼 만들어 적지는 않겠습니다.

text

Simply configure a model endpoint to get started.

It reads Git diffs, sends changed files to a configurable LLM via an agent with tool-use capabilities,

Beyond diff review, `ocr scan` reviews entire files for auditing unfamiliar codebases or directories that have no meaningful diff.

사전 준비는 Go 런타임이 기본이고, LLM을 연결하려면 설정 가능한 API 엔드포인트와 API 키가 필요해 보입니다. 웹 화면을 다루는 `pages`와 `package.json`, `npm` 디렉터리에는 Node/npm 영역이 있습니다. 반면 README와 폴더 구조에서 GPU나 Docker가 필수라는 내용은 확인하지 못했습니다. 저는 설치·실행 결과를 쓰지 않고, `go.mod`, `Makefile`, 테스트 파일과 CI가 있다는 저장소 근거까지만 정리했습니다.

③ README 말대로 되나: 코드에서 확인한 8가지

README의 주장만 믿지 않고, 저장소를 받아 관련 파일과 검증표를 하나씩 대조했습니다. 결론부터 말하면 8가지 주장이 모두 코드에서 확인됐습니다.

• **① Git diff 리뷰 — 코드 어디에 있더라:** `LICENSE`에서 `review` 관련 구현 근거를 확인했습니다. `ocr review`가 스테이징·언스테이징·미추적 변경, 브랜치 범위, 단일 커밋 같은 Git diff를 대상으로 한다는 설명과 맞닿아 있습니다.
• **② 전체 파일 스캔 — 코드 어디에 있더라:** `cmd/opencodereview/cli_reference_compare_docs_test.go`에 `scan`이 등장합니다. diff가 없는 저장소나 디렉터리, 지정 파일의 전체 내용을 검토하는 `ocr scan` 경로가 확인됩니다.
• **③ LLM 에이전트 — 코드 어디에 있더라:** `cmd/opencodereview/budget_output_test.go`에서 `Agent` 근거를 확인했습니다. 변경 파일을 설정 가능한 LLM에 전달하고, 파일 읽기·코드 검색·다른 변경 파일 확인을 도구로 처리하는 구조입니다.
• **④ 줄 단위 댓글 — 코드 어디에 있더라:** `bin/ocr.js`에서 `line` 처리를 찾았습니다. 파일과 특정 줄을 가리키는 구조화된 리뷰 댓글을 만든다는 README 설명을 뒷받침합니다.
• **⑤ 내장 규칙 — 코드 어디에 있더라:** `cmd/opencodereview/emit_run_result_test.go`에 `NPE`가 확인됩니다. 검증표 기준으로 스레드 안전성, XSS, SQL 인젝션을 포함한 다언어 규칙 묶음도 함께 확인됐습니다.
• **⑥ 결과 저장 — 코드 어디에 있더라:** `cmd/opencodereview/flag_suggest_test.go`의 `--format` 근거가 있습니다. JSON 같은 형식으로 결과를 지정한 파일에 저장하는 기능입니다.
• **⑦ 세션 재개 — 코드 어디에 있더라:** `cmd/opencodereview/arg_errors_test.go`에서 `session` 처리를 확인했습니다. 중단된 세션을 목록에서 보고 ID로 이어가는 흐름입니다.
• **⑧ 위임 모드 — 코드 어디에 있더라:** 같은 `arg_errors_test.go`에서 `delegate`를 찾았습니다. LLM 설정 없이 파일 선택과 규칙 해석을 맡기고, AI 코딩 에이전트가 리뷰하도록 하는 방식입니다.

따라서 이번 검증 범위에서는 README 주장 8건 모두 코드 근거가 확인됐습니다.

④ 별점: 가장 아쉬운 축부터 4.8점

설치 난이도 ★★★★☆

가장 아쉬운 축입니다. 저장소를 클론해 폴더를 열어보니 파일이 405개이고, Go 프로젝트를 위한 `go.mod`, 빌드 작업을 정의하는 `Makefile`, npm 구성을 담은 `package.json`이 함께 있습니다. 테스트와 CI 구성까지 갖춘 만큼 구조는 탄탄하지만, 처음 보는 분에게는 Go·Make·npm을 모두 살펴볼 준비가 필요합니다. 간단한 단일 CLI 도구를 기대했다면 접근 난도가 조금 높게 느껴질 수 있습니다.

설명 일치도 ★★★★★

README가 말한 핵심 기능 8건 중 8건을 검증표의 코드 근거와 대조해 확인했습니다. `ocr review`의 Git diff 리뷰, `ocr scan`의 전체 파일 리뷰, LLM 에이전트 도구 사용, 줄 단위 댓글, 내장 규칙, JSON 등 형식 저장, 세션 재개, 위임 모드까지 설명과 코드의 방향이 맞습니다. README만 그럴듯한 프로젝트는 아니라는 점이 좋았습니다.

완성도 ★★★★★

최신 릴리즈가 v1.12.5이고, 저장소에 테스트와 CI가 함께 있습니다. 기여자 30명, 열린 이슈 186개도 확인되어 지속적으로 손질되는 프로젝트로 보입니다. 다만 이 숫자만으로 모든 기능의 품질을 단정하기보다는, 실제 도입 전에는 우리 팀의 언어와 CI 흐름에 맞는지 코드를 더 살펴보는 편이 좋겠습니다.

문서·커뮤니티 ★★★★★

README가 기능과 사용 맥락을 설명하고, GitHub Actions·GitLab CI·Gerrit CI·Bitbucket Pipelines·Codeup CI·Gitflic CI 등 CI 예제 6종을 제공합니다. DeepWiki 링크도 있고, 현재 스타는 33,981개라 참고 자료를 찾기 좋은 편입니다.

라이선스·지속성 ★★★★★

라이선스는 Apache-2.0이고, 마지막 커밋은 2026-09-17, 기여자는 30명입니다. 기업 환경에서 검토할 기본 조건과 최근 활동 모두 확인됩니다. 종합하면 5축 평균 4.8/5점, 실무 검토용으로 추천하는 A등급입니다.

⑤ 나라면 이렇게 쓴다: PR·레거시·CI를 나눠서

저라면 이 도구를 한 번에 모든 리뷰에 쓰기보다, PR·레거시·자동화 파이프라인을 나눠서 붙이겠습니다. 코드를 받아 관련 구현과 검증 근거를 대조해보니, 세 장면이 가장 현실적으로 그려졌습니다.

① 소규모 팀의 PR 사전 검토

개발자 두세 명이 운영하는 팀에서 Pull Request를 올리기 전, 담당자가 `ocr review`에 스테이징된 변경, 언스테이징 변경, 미추적 파일을 넘길 수 있습니다. 또는 `main..feature` 같은 브랜치 범위나 단일 커밋을 지정해도 됩니다. 그러면 변경 파일을 읽은 LLM 에이전트가 관련 코드까지 살펴보고, “이 조건에서 널 포인터가 발생할 수 있다”처럼 특정 파일의 특정 줄을 가리키는 댓글을 구조화해 반환합니다. 결과를 JSON 파일로 저장하면 CI(코드가 올라올 때 자동으로 검사하는 파이프라인)의 리뷰 단계에서 파싱해 실패 조건이나 담당자 알림에 연결하기 좋습니다. 다만 댓글이 곧 승인 판정은 아니므로, 팀 규칙에 맞춰 사람이 최종 확인하는 구조로 두겠습니다.

② 인수받은 레거시 저장소 점검

문서가 부족한 오래된 저장소를 인수한 기획자나 개발팀이라면, 특정 디렉터리 또는 파일을 `ocr scan` 대상으로 넣겠습니다. 이 명령은 Git diff가 없어도 전체 내용을 검토하는 흐름이라, 최근에 수정된 적 없는 코드도 대상이 됩니다. 결과로 SQL 인젝션, XSS, NPE, 스레드 안전성 같은 보안·품질 관점의 검토 의견과 해당 줄을 받아, 먼저 위험 목록과 리팩터링 우선순위를 정리할 수 있습니다. 저장소 전체를 무작정 보는 대신 결제 모듈이나 인증 디렉터리부터 좁혀 시작하겠습니다.

③ LLM 설정이 부담스러운 팀의 위임 모드

모델 엔드포인트와 규칙 파일을 직접 관리하기 어려운 팀이라면 위임 모드를 선택하겠습니다. 담당자가 리뷰할 파일이나 폴더만 고르면, 파일 선택과 규칙 해석을 맡긴 뒤 Claude Code·Codex·Cursor 같은 AI 코딩 에이전트가 실제 리뷰를 진행하는 방식입니다. 팀은 복잡한 LLM 설정 대신 대상 범위와 검토 목적을 전달하고, 에이전트가 만든 리뷰 결과를 받아 수정 작업으로 넘길 수 있습니다.

⑥ 안 맞는 사람과 대안: 작은 프로젝트엔 과할 수 있다

작은 프로젝트라면 OpenCodeReview의 에이전트와 여러 연동 구성이 오히려 과할 수 있습니다. 변경 파일이 몇 개 안 되고 제가 직접 diff를 확인하면 충분한 개인 프로젝트라면, 설치와 설정에 들이는 시간이 리뷰 시간보다 길어질 수 있습니다. 특히 LLM 비용을 아직 산정하지 않은 팀이나, 외부 서비스로 소스 코드를 보내도 되는지 보안 정책을 정하지 않은 조직이라면 바로 CI에 붙이기보다 내부 검토부터 해야 합니다.

코드를 받아서 뜯어보니 변경 파일과 관련 코드를 에이전트가 읽고 검색하는 구조라서, 어떤 파일과 변경 사항이 LLM으로 전달되는지 확인할 필요가 있습니다. 사내 비공개 코드, 고객 정보, 비밀 키가 섞일 가능성이 있다면 마스킹, 전송 범위, 보관 여부, 사용 모델의 데이터 처리 정책을 먼저 정해야 합니다. Apache-2.0 라이선스라 상업적 활용을 검토하기에는 유리하지만, 라이선스가 외부 LLM 전송에 대한 회사 보안 승인을 대신해주지는 않습니다.

유지보수도 숫자 하나만 보고 판단하면 곤란합니다. 마지막 커밋은 2026-09-17이고 최근 릴리즈는 v1.12.5까지 나왔지만, 현재 기여자는 30명, 열린 이슈는 186개입니다. 업데이트가 활발한 만큼 릴리즈 변경점과 이슈 대응이 우리 환경에 맞는지 계속 확인하는 편이 안전합니다. 저는 도입 전에 사용하는 LLM의 비용과 데이터 정책, 업데이트 주기, 장애 때 수동 리뷰로 돌아가는 절차를 문서화하겠습니다.

비슷한 선택지로 README에서 직접 언급하는 Claude Code가 있습니다. 다만 이 저장소의 비교 내용은 README에 제시된 기준이므로, 실제 팀의 언어·비용·보안 조건으로 다시 비교해야 합니다. 2026-09-18 기준.

첨부 이미지

• 이미지 1: 01_repo.png (alibaba/open-code-review 저장소 첫 화면 (2026-09-18))
• 이미지 2: 02_demo.png (README에 실린 데모 화면 (출처: alibaba/open-code-review))
• 이미지 3: 03_tree.png (받아서 열어본 폴더 구조)
• 이미지 4: 04_score.png (별점 4.8 / 5 — 지금 써라)

❓ 자주 묻는 질문

Q. alibaba/open-code-review는 어떤 도구인가요?

A. Git diff나 저장소 전체 파일을 검토하고, 설정 가능한 LLM 에이전트와 규칙 기반 파이프라인으로 줄 단위 리뷰 댓글을 만드는 Go 기반 AI 코드 리뷰 CLI 도구입니다.

Q. open-code-review는 Git diff가 없어도 사용할 수 있나요?

A. 검증표에서 ocr scan이 Git diff 없이 저장소 전체·디렉터리·지정 파일의 내용을 검토하는 코드 근거를 확인했습니다.

Q. open-code-review는 어떤 보안 규칙을 지원하나요?

A. 검증표 기준으로 NPE, 스레드 안전성, XSS, SQL 인젝션 등의 내장 다언어 리뷰 규칙을 코드에서 확인했습니다.

Q. open-code-review를 도입할 때 주의할 점은 무엇인가요?

A. 변경 파일과 코드가 설정한 LLM 엔드포인트로 전달될 수 있으므로, 외부 LLM 사용 정책과 API 비용을 먼저 검토해야 합니다. Apache-2.0 라이선스와 최근 커밋·릴리즈도 함께 확인하는 것이 좋습니다.

이 글은 2026-09-18 기준으로 저장소를 내려받아 README와 코드를 대조한 결과이며, 프로그램을 직접 실행한 결과는 아닙니다. 오픈소스는 빠르게 바뀌므로 최신 상태는 저장소에서 확인해 주세요. 참고·인용 시 이 글의 URL을 출처로 남겨주시고, 써보신 경험은 댓글로 나눠주세요.