Google 코드 리뷰 표준 eng-practices를 AI 에이전트에 붙이는 4가지 실전 방법

목차 (Table of Contents)

1. Google이 GitHub에 공개한 코드 리뷰 표준
2. 12 검토 축: AI 에이전트 프롬프트의 척추
3. 단일 senior principle: Code health 개선이면 perfect 아니어도 승인
4. AI 에이전트에 적용하는 4단계 워크플로우
5. CC-By 3.0 라이선스가 왜 중요한가
6. 자주 묻는 질문 (FAQ)

요약: Google이 2019-09-05 GitHub에 공개한 eng-practices 저장소(Star 20,400개, 라이선스 CC-By 3.0)는 코드 리뷰의 12 검토 축과 단일 senior principle(code health 개선이면 perfect 아니어도 승인)을 정리한 표준 문서입니다. CC-By 3.0이라 출처 표기만 하면 AI 시스템 프롬프트에 그대로 주입 가능합니다.

AI한테 PR 리뷰를 시켜봤는데, 마음에 안 드신 적 있으세요?

"이거 잘 짠 거 같아요"라고만 답하거나, 반대로 별것 아닌 변수명까지 P1으로 잡아내거나. 결국 사람이 다시 검수해야 하니까 시간 절약이 안 되는 거예요.

해법은 의외로 단순합니다. Google이 2019-09-05에 GitHub에 공개한 코드 리뷰 표준을 그대로 AI 에이전트에 주입하면 돼요. 라이선스는 CC-By 3.0, 출처 표기만 하면 상업적 재가공도 합법이에요. 오늘 기준 약 6.7년 검증된 산업 표준이고요.

이 글은 그 표준 문서를 Claude Skill, Cursor 룰, 시스템 프롬프트, PR 자동화 도구 네 가지로 변환하는 워크플로우를 정리한 글입니다.

Google이 GitHub에 공개한 코드 리뷰 표준

저장소 이름은 google/eng-practices입니다. URL은 https://github.com/google/eng-practices, GitHub Pages 버전은 https://google.github.io/eng-practices/ 에서 볼 수 있어요.

문서가 두 축으로 나뉘는 게 특징이에요. 한쪽은 리뷰어 입장, 다른 한쪽은 PR(Google에선 CL이라 부릅니다) 작성자 입장. AI 에이전트로 변환할 때 이 구분이 그대로 살아납니다. "리뷰어 봇"과 "PR 자체 점검 봇"을 분리해서 만들 수 있어요.

용어 정리부터 짚고 갈게요. eng-practices를 그대로 LLM에 던지면 LLM이 용어를 못 알아듣는 경우가 많거든요.

• CL (Changelist): Google 내부 용어. 다른 곳에선 change, patch, pull request라고 부릅니다.
• LGTM (Looks Good To Me): 리뷰어가 승인할 때 쓰는 표현.
• Readability: Google 내부 인증 제도. 특정 언어의 코딩 스타일을 이해함을 증명. 약 20%의 Google 엔지니어가 항상 이 프로세스에 참여 중이에요 (출처: abseil.io/resources/swe-book Ch.3).
• Code Health: 시스템의 유지보수성·복잡도·테스트 가능성 종합 품질. 승인의 단일 기준입니다.

12 검토 축: AI 에이전트 프롬프트의 척추

review/reviewer/looking-for.html 챕터에 정리된 12 검토 축은 AI 에이전트 프롬프트의 핵심이 됩니다. 이 표만 그대로 시스템 프롬프트에 붙여도 일반 LLM 대비 리뷰 품질이 확 달라져요.

특히 Complexity의 over-engineering 경계가 핵심입니다. 대부분의 LLM은 "더 견고하게", "더 확장 가능하게" 같은 일반화를 좋아하는데, eng-practices는 정반대로 "지금 필요한 것만"이라고 명확히 못 박아요. 이 한 줄이 AI 리뷰어의 false positive를 절반 가까이 줄여줍니다.

단일 senior principle: Code health 개선이면 perfect 아니어도 승인

eng-practices의 모든 룰을 관통하는 한 줄이 있어요. review/reviewer/standard.html에 명시된 표준입니다.

"Reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect."

번역하면, "리뷰어는 CL이 시스템 전체의 code health를 명확히 개선하는 상태가 되면, 완벽하지 않더라도 승인해야 한다"입니다.

그리고 한 줄 더.

"There is no such thing as 'perfect' code — there is only better code."

이 원칙이 AI 코드 리뷰어 운영에서 결정적으로 중요한 이유가 있어요. LLM은 본능적으로 완벽주의로 흐릅니다. "여기도 개선 가능", "이 부분도 리팩토링하면 좋겠다"고 끝없이 코멘트하는 거죠. 결과적으로 개발자는 리뷰 반영에 시간을 다 쓰고, 실제 출시는 지연됩니다.

eng-practices는 이걸 정면으로 반박해요. 점진적 개선(continuous improvement)이 완벽함보다 우선이라고요. 시스템 프롬프트에 이 한 줄만 추가해도 LLM 리뷰어의 톤이 달라집니다.

속도 SLA도 명시되어 있어요. review/reviewer/speed.html에 따르면 리뷰 요청 응답은 1 business day 안에 끝내야 합니다. 다회차 리뷰도 단일 영업일 내에 가능하도록 설계되어 있어요. AI 에이전트는 어차피 즉시 응답하니까 사람보다 빠른데, 핵심은 "응답 시간 최우선" 철학을 prompt에도 반영해서 짧고 명확한 리뷰를 강제하는 거예요.

AI 에이전트에 적용하는 4단계 워크플로우

자, 이제 본론입니다. eng-practices 원문을 어떻게 AI 에이전트에 주입하느냐.

방법 1: Claude Skill로 패키징

Claude Code를 쓰신다면 가장 깔끔한 방법이에요. SKILL.md 형식으로 변환해서 .claude/skills/code-review/ 하위에 저장합니다.

---
name: code-review
description: Google eng-practices 표준 기반 코드 리뷰. CL Design/Functionality/Complexity 12축 검토.
tools: ["Read", "Bash", "Grep"]
---

# Code Review Skill

## Standard
The single senior principle: approve a CL once it improves overall code health,
even if not perfect. Continuous improvement, not perfection.

## What to look for
1. Design — 가장 중요
2. Functionality — edge case 포함
... (12축 그대로)

이미 Skills Playground에 "Code Review Pro", "Spring Boot Reviewer", "Rust Reviewer" 같은 사례가 올라와 있어요 (skillsplayground.com).

방법 2: Cursor .cursorrules 변환

Cursor IDE를 쓰신다면 .cursorrules 파일에 발췌를 넣습니다.

# Code Review Rules (Google eng-practices, CC-By 3.0)

Single principle: Approve once code health improves, even if not perfect.

Review dimensions (in priority order):
1. Design (most important)
2. Functionality
3. Complexity (avoid over-engineering)
4. Tests (must be in same CL, except emergencies)
... (12축)

Comment style:
- Comment about code, never about the developer
- Use labels: Nit / Optional / Required
- Always comment on Good Things too

방법 3: 시스템 프롬프트 직접 주입

자체 LLM 시스템을 운영하시면 system prompt에 통째로 넣어도 됩니다. 영어 prompt가 LLM 반응이 더 안정적이긴 한데, 한국어 출력을 원하시면 마지막에 "Output in Korean" 한 줄 추가하면 돼요.

You are a code reviewer following Google's eng-practices standard
(github.com/google/eng-practices, CC-By 3.0).

SINGLE PRINCIPLE: Approve the CL once it improves the overall
code health of the system, even if the CL isn't perfect.
There is no "perfect" code — only better code.

REVIEW DIMENSIONS:
[12 축 나열]

COMMENT STYLE:
- Comment on code, never on the developer
- Use Nit:/Optional:/Required: labels
- Comment on Good Things too
- Respond within 1 business day

Output review in Korean.

방법 4: 기존 PR 자동화 도구와 통합

GitHub Actions, Graphite, CodeRabbit 같은 도구를 이미 쓰고 계시다면, 그 도구의 prompt 설정에 eng-practices 발췌를 넣으면 됩니다. Graphite Agent는 이미 eng-practices 정신을 SaaS로 구현한 사례예요 (graphite.com/blog/how-google-does-code-review).

CC-By 3.0 라이선스가 왜 중요한가

이 부분이 사실 가장 중요해요. AI 시스템 프롬프트에 외부 문서를 넣을 때 라이선스 문제로 막히는 경우가 많거든요.

eng-practices는 **Creative Commons Attribution 3.0 (CC-By 3.0)**을 채택했습니다. 의무 사항은 단 하나, 출처 표기. 그 외엔 다음이 모두 허용됩니다.

• 상업적 재가공 (예: AI 코드 리뷰 SaaS 제품에 활용)
• 번안 (한국어 번역, 도메인 특화 발췌)
• 시스템 프롬프트 활용 (LLM에 그대로 주입)
• 재배포 (사내 위키, 팀 가이드로 사본 보관)

저장소 README에 라이선스가 명시되어 있고, 출처는 "Google, eng-practices, github.com/google/eng-practices, CC-By 3.0" 정도로 끝내면 됩니다. Anthropic Claude Skills, Cursor, OpenAI Custom GPT 어디에 넣어도 법적 안전성이 보장돼요.

마무리

정리하면 이렇습니다.

1. Google이 2019-09-05 GitHub에 공개한 eng-practices는 약 6.7년간 검증된 코드 리뷰 표준입니다.
2. 핵심은 단일 원칙(code health 개선이면 perfect 아니어도 승인) + 12 검토 축 + 1 business day SLA입니다.
3. CC-By 3.0 라이선스로 AI 시스템 프롬프트 활용이 완전 합법입니다.
4. Claude Skill, Cursor 룰, 시스템 프롬프트, PR 자동화 도구 네 가지 경로 중 본인 환경에 맞는 걸 고르세요.

직접 룰을 새로 짜는 것보다, Google이 6년간 다듬은 표준을 가져다 쓰는 게 훨씬 빠르고 정확합니다. Star 20,400개가 그 검증의 증거예요.

오늘 바로 git clone https://github.com/google/eng-practices 한 줄로 시작해 보세요.

자주 묻는 질문 (FAQ)

Q1. eng-practices가 6년 전 문서인데 지금도 유효한가요?

코드 리뷰의 본질(설계·기능·복잡도·테스트·일관성)은 언어나 도구에 거의 영향을 받지 않습니다. eng-practices는 그 본질만 다루기 때문에 AI 시대에도 그대로 적용됩니다. 오히려 6년간 큰 변경 없이 유지된다는 게 표준의 안정성을 증명해요.

Q2. 한국어로 출력받으려면 한국어 시스템 프롬프트가 좋나요, 영어가 좋나요?

영어 시스템 프롬프트 + 마지막에 "Output in Korean" 한 줄 추가가 가장 안정적입니다. LLM은 영어 instruction에 더 정확하게 반응하고, 한국어 출력 요청은 마지막 한 줄로 충분합니다.

Q3. CC-By 3.0 라이선스 출처 표기는 어디에 넣어야 하나요?

AI 응답 마지막 줄 또는 시스템 프롬프트 끝에 한 줄로 충분합니다. 예: "Source: Google eng-practices (github.com/google/eng-practices), CC-By 3.0". SaaS 제품화 시에는 사용자 약관·라이선스 페이지에도 명시하세요.

Q4. 12 검토 축을 한 번에 다 적용하면 코멘트가 너무 많지 않을까요?

시스템 프롬프트에 "Limit to top 10 highest-impact comments per PR" + Nit/Optional/Required 라벨을 강제하면 됩니다. eng-practices의 senior principle도 "perfect 아니어도 code health 개선이면 승인"이므로, AI도 그 톤을 따르면 자연스럽게 코멘트가 절제됩니다.

관련 글

• Claude Code Skills로 AI 에이전트 만들기 (/skills 가이드)
• Cursor .cursorrules 패턴 모음
• 코드 리뷰 자동화 도구 비교 (Graphite vs CodeRabbit)

참고 자료

• Google eng-practices GitHub 저장소
• eng-practices GitHub Pages
• The Standard of Code Review (단일 senior principle)
• What to look for in a code review (12 검토 축)
• Speed of Code Reviews (1 business day SLA)
• How to write code review comments (톤 가이드)
• The CL author's guide
• Software Engineering at Google — Ch.9 Code Review
• Software Engineering at Google — Ch.3 Readability
• How Google does code review (Graphite 분석)
• Google Code Review Readability Certification 해설 (PullRequest)