open-code-review 딥다이브
— 알리바바가 사내에서 2년 굴린 AI 코드리뷰를 통째로 공개하다

1프로젝트 한줄 요약

이 레포가 무엇을 하는 물건인가.

터미널에서 ocr review 한 줄을 치면, 지금 작업 중인 변경사항(스테이징·미스테이징·새 파일 전부)을 모아 LLM에게 보내고, 결과를 "몇 번째 줄의 이 코드가 왜 문제이고 어떻게 고치면 되는지" 형태로 돌려받습니다. Anthropic(Claude)·OpenAI 호환 API 어느 쪽이든 모델 주소와 키만 설정하면 바로 동작합니다.

출신이 특이합니다. 처음부터 오픈소스로 만든 프로젝트가 아니라, 알리바바 그룹의 공식 사내 AI 코드리뷰 비서로 2년간 운영되며 수만 명의 개발자에게 쓰이고 수백만 건의 결함을 찾아낸 뒤, 그 운영 데이터를 바탕으로 다듬어 2026년 5월에 공개된 물건입니다. 공개 3주 만에 ★4.6k를 모으며 TrendShift 상위권에 올랐습니다.

2왜 주목받는가

트렌딩 이유 · 범용 에이전트 대비 무엇이 다른가.

Claude Code 같은 범용 코딩 에이전트에 "리뷰해줘"라고 시켜본 사람이라면 누구나 겪는 세 가지 고질병이 있습니다. README가 첫머리에서 정면으로 지적하는 내용입니다.

여기에 에이전트의 도구 세트 자체를 대규모 운영 데이터로 설계했다는 점이 흥미롭습니다. 도구 호출 빈도 분포, 도구별 반복률, 새 도구가 전체 호출 체인에 주는 영향을 분석해서 — 범용 에이전트의 만능 도구함 대신 코드리뷰 전용으로 깎아낸 6개 도구만 남겼습니다. 도구가 적을수록 LLM이 헤맬 공간도 줄어듭니다.

3기술 스택 전체 지도

Go 단일 바이너리 + 외부 의존성 최소 구성.

프론트엔드 프레임워크도, 데이터베이스도 없습니다. Go 1.25로 빌드한 단일 실행 파일이 전부이고, 결과 열람용 웹 뷰어조차 Go 표준 라이브러리의 HTML 템플릿으로 만들었습니다. "CLI 도구는 이렇게 만든다"의 교과서 같은 구성입니다.

4아키텍처 심화 분석

diff 한 덩어리가 줄 단위 코멘트가 되기까지.

전체 그림부터 봅시다. ocr review를 치면 데이터가 아래 라인을 따라 흐릅니다. 회색 글씨로 표시한 왼쪽 단계들은 전부 일반 Go 코드가 결정하고, LLM은 가운데 "에이전트 루프" 안에서만 일합니다.

흐름 한 줄기를 끝까지 따라가 보기

"내가 자바 파일 3개를 고치고 ocr review를 쳤다"는 상황 하나를 입구부터 출구까지 추적해 봅니다. 이 한 줄기만 이해하면 나머지는 변주입니다.

① 수집 — internal/diff가 git을 호출해 스테이징·미스테이징·새 파일의 변경분을 Unified Diff (유니파이드 디프, +/- 줄로 표현한 변경 기록) 형태로 모읍니다. ② 필터 — 바이너리, 테스트 파일(*Test.java 등), 지원하지 않는 확장자를 코드 레벨에서 걸러냅니다. LLM에게 "이건 보지 마"라고 부탁하는 게 아니라 아예 보내지 않습니다. ③ 규칙 매칭 — **/*.java 패턴이 걸리므로 내장 점검표 java.md(NPE·스레드 안전성·N+1 쿼리 등)가 이 파일의 리뷰 기준으로 붙습니다. ④ 번들링 — 서로 관련된 파일(예: message_en.properties와 message_zh.properties)은 한 묶음으로 묶고, 묶음마다 서브에이전트를 배정해 기본 8개까지 동시에 돌립니다.

⑤ 에이전트 루프 — 변경이 50줄을 넘으면 본 리뷰 전에 PLAN_TASK라는 별도 LLM 호출로 "위험 지점과 조사 계획"을 JSON으로 먼저 뽑습니다. 그다음 MAIN_TASK 에이전트가 diff와 점검표를 받아, 필요하면 file_read(주변 코드 읽기)·code_search(저장소 검색)·file_read_diff(다른 변경 파일 보기)로 컨텍스트를 모으고, 문제를 확신하면 code_comment 도구를 호출합니다. 도구 호출은 최대 30회로 제한되고, 대화가 길어지면 MEMORY_COMPRESSION_TASK가 지금까지의 발견을 요약해 컨텍스트를 비웁니다.

⑥ 위치 결정 — 이 레포의 백미. LLM은 줄 번호를 자주 틀리기 때문에, OCR은 줄 번호를 아예 신뢰하지 않습니다. 대신 code_comment가 "문제가 된 코드 조각 원문(existing_code)"을 받아 슬라이딩 윈도우 알고리즘으로 diff 텍스트에서 그 조각과 일치하는 연속 줄을 찾아 코멘트를 박습니다. 텍스트 매칭이 실패하면? RE_LOCATION_TASK라는 작은 LLM 호출이 "diff에서 코멘트가 가리키는 최소 범위를 글자 그대로 다시 뽑아라"를 수행해 한 번 더 시도합니다. ⑦ 출력 — 결과는 터미널(text) 또는 CI용 json으로 나가고, LLM과 주고받은 전 과정이 JSONL로 남아 ocr viewer에서 복기할 수 있습니다. (에러 처리·토큰 한도 분기 같은 곁가지는 여기선 생략합니다.)

5디렉토리 구조 해부

어떤 폴더가 무슨 일을 하나 — 표준적인 Go CLI 레이아웃.

눈여겨볼 관례 하나 — 이 프로젝트에서 "정상"은 설정이 코드가 아니라 JSON·md 데이터로 존재하는 것입니다. 규칙도, 프롬프트도, 도구 스키마도, 제외 패턴도 전부 파일입니다. Go 코드는 그 데이터를 해석하는 엔진 역할만 합니다.

6학습 포인트 (기술별)

이 레포에서 배울 만한 것 + 어디를 보면 되는지.

// 프로젝트 규칙 예시 — .opencodereview/rule.json
{
  "rules": [
    { "path": "**/*mapper*.xml",   ← 글롭 패턴: 이 경로에 매칭되면
      "rule": "SQL 인젝션·파라미터 오류·닫는 태그 누락을 확인" }
  ],
  "exclude": ["**/generated/**"]   ← 자동 생성 코드는 리뷰 제외
}

7시스템 요구사항

돌리려면 무엇이 필요한가 — 진입 장벽이 매우 낮다.

로컬에서 모델을 돌리는 게 아니라 API를 호출하는 구조라, 비용은 하드웨어가 아니라 API 토큰 요금으로 나갑니다. 큰 diff일수록 토큰을 많이 쓰므로 --preview로 리뷰 대상을 먼저 확인하는 습관이 유용합니다.

8직접 해볼 수 있는 실습 과제

난이도별로 손에 익히는 단계.

9관련 기술 심화 학습 로드맵

한 주씩 따라가는 계획.

10핵심 키워드 사전

본문에 나온 용어 빠른 참조.

11참고 링크

• GitHub: alibaba/open-code-review
• 공식 사이트: alibaba.github.io/open-code-review
• npm 패키지: @alibaba-group/open-code-review
• 한국어 README: README.ko-KR.md
• 코딩 에이전트용 스킬: skills/open-code-review/SKILL.md
• CI 연동 예시: examples/