AI 드리븐

지도 위치 : 3일차 · 신뢰와 운영 · 자동화의 경계선 긋기 | 이전: 19차시 자동화 파이프라인 ① | 다음: 21차시 배포 ① 서버 공개 키워드 : 자동 코드 리뷰 연동, 자동화의 범위와 사람의 몫

이 차시를 다 읽으면

1. AI 코드 리뷰 를 유와 종차로 정의하고, CI와 각각 무엇을 잘 잡는지 가를 수 있다.
2. 리뷰 기준을 저장소에 두는 이유와 좋은 AI 리뷰의 세 조건 을 말할 수 있다.
3. "자동화할 것 ↔ 사람이 할 것"을 두 개의 축 (되돌릴 수 있는가, 기계로 판정 가능한가)으로 가를 수 있다.
4. CODEOWNERS 를 정의하고, 이것만으로는 강제가 되지 않는 이유와 함께 무엇을 더 켜야 하는지 말할 수 있다.
5. 코드를 읽지 않고 PR을 승인할 때 쓸 병합 전 체크리스트 를 댈 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 두 개입니다. 테스트로 적을 수 없는 문제는 누가 잡는가 (축 3), 그리고 다 자동화하면 책임은 누가 지는가 (축 1). 앞에서 배운 검증 역할의 분리 (7, 13차시)를 PR마다 자동으로 돌게 하는 것이 전반부이고, 앞 차시의 관문(19차시)에 사람의 승인 이라는 칸을 강제로 끼워 넣는 것이 후반부입니다.

---

1. AI 코드 리뷰 — 무엇에 속하는가

1.1 정의

코드 리뷰 — [검증 활동]인데, [ 코드를 실행하지 않고 읽어서 문제를 찾는다 ]는 점에서 실행해서 확인하는 테스트와 구별된다(앞에서 배운 정적 검증, 13차시).

AI 코드 리뷰 — [코드 리뷰]인데, [ PR마다 AI가 변경 내용을 읽고 판단이 필요한 문제를 PR에 코멘트로 짚는다 ]는 점에서 정해 둔 규칙을 기계적으로 판정하는 CI와 구별된다.

1.2 경계 — CI ↔ AI 리뷰

⭐ 둘은 0절 축 3의 양쪽입니다. 테스트는 "정해 둔 것"만 확인합니다. AI 리뷰는 아직 정하지 못한 것까지 짚을 수 있지만, 그만큼 틀릴 수도 있습니다. 그래서 CI는 관문으로 걸고, AI 리뷰는 사람이 판단할 재료로 씁니다.

1.3 반례 — 이건 AI 코드 리뷰가 아닙니다

---

2. 리뷰 연동과 리뷰 기준

2.1 PR 하나에 두 줄기

PR 생성
  ├─▶ CI (19차시): 린트, 타입, 테스트, 빌드, 스캔 → 통과 / 실패  (관문)
  └─▶ AI 리뷰: 변경 내용 검토 → PR에 코멘트                    (의견)
                    │
                    ▼
            사람: 코멘트 확인, 최종 판단, 병합

🔍 읽는 포인트 : 두 줄기가 마지막에 사람에게 모인다 는 것만 보면 됩니다.

구현 방법 예:

• Claude Code의 GitHub 연동 — GitHub Actions에서 도는 공식 액션으로 PR마다 리뷰를 실행. Claude Code 안에서 /install-github-app으로 설정을 시작할 수 있습니다(세부 절차와 권한은 공식 문서 확인).
• 이 밖에도 여러 AI 리뷰 서비스가 있습니다.

2.2 리뷰 기준을 저장소에 둔다

앞에서 배운 검증 역할 정의 (7, 13, 14차시)를 그대로 재사용합니다. 기준이 대화에만 있으면 세션마다 사라지므로(① 디스크 ↔ 메모리), 파일로 둡니다.

# 리뷰 기준 (지침 파일 또는 리뷰 프롬프트에)
우선순위 순으로 본다:
1. 보안: 인가 누락, 비밀값, 주입, 개인정보 로그
2. 정합성: docs/api.md 명세와 다른 응답 · 상태 코드
3. 데이터: 트랜잭션 범위, 동시성, 파괴적 마이그레이션
4. 테스트: 새 동작에 테스트가 있는가, 테스트를 약하게 바꾸지 않았는가
5. 그 외 가독성은 중요한 것만. 취향 지적은 하지 않는다.
보고: 심각도(높음/중간/낮음), 파일:줄, 근거. 확실하지 않으면 "확인 필요"로 표시.

🔍 읽는 포인트 : 1~4번이 무엇을 먼저 볼지 , 마지막 줄이 어떻게 보고할지 입니다. 4번이 17 · 19차시의 "테스트 · 관문을 고쳐서 통과"를 리뷰 단계에서 한 번 더 잡는 자리입니다.

2.3 좋은 AI 리뷰의 세 조건

2.4 위험한 PR에는 두 겹으로

코드를 읽을 수 있는 사람은 리뷰어가 놓친 것을 직접 잡을 수 있습니다. 읽지 못한다면 그럴 수 없습니다. 그래서 결제 · 인증 · 마이그레이션처럼 위험한 PR에는 관점이 다른 리뷰를 하나 더 붙입니다(README 9.1의 ④ 교차 검증).

---

3. ⭐ 자동화의 범위와 사람의 몫

3.1 두 축으로 긋는 경계선

판단 기준 : 되돌릴 수 있고 기계적으로 판정 가능하면 자동화, 되돌리기 어렵거나 가치 판단이 필요하면 사람. 이 한 문장은 사실 두 개의 축 을 겹친 것입니다.

⚠️ 그리고 표 밖에 하나가 더 있습니다. AI 리뷰 결과에 대한 최종 판단과 책임 은 언제나 사람입니다. AI 리뷰가 통과시켰다고 결제 버그의 책임이 AI에게 가지 않습니다. 모든 걸 자동화하면 일은 빨라지지만 책임질 사람이 사라집니다.

3.2 사람의 몫은 코드 실력과 무관하다

위 표의 오른쪽 아래 칸을 다시 보세요. 무엇을 만들지, 트레이드오프, 돈 · 데이터 · 배포 승인은 거의 전부 코드를 읽는 능력과 무관합니다. README 9.2의 "내가 직접 (위임 불가)" 열과 같은 목록입니다. AI에게 맡기는 사람의 역할은 줄어든 게 아니라 이쪽으로 옮겨 간 것 입니다.

앞으로 다시 만납니다 — 22차시의 자동 배포 흐름에서 이 표의 "자동 + 사람 승인" 칸이 실제 버튼(운영 배포 승인)이 됩니다.

---

4. 사람의 확인을 강제하는 장치

4.1 CODEOWNERS

"사람이 볼 것"도 다짐(0절 축 4의 왼쪽)이 아니라 장치로 걸 수 있습니다.

CODEOWNERS — [저장소 설정 파일]인데, [ 경로별로 승인해야 할 사람을 지정해, 그 경로가 바뀐 PR은 지정된 사람의 승인을 받게 한다 ]는 점에서 누구의 승인이든 개수만 채우면 되는 "필수 승인 수"와 구별된다.

# .github/CODEOWNERS
/apps/api/src/payments/   @내아이디
/apps/api/migrations/     @내아이디
/.github/                 @내아이디
/.claude/                 @내아이디

🔍 읽는 포인트 : 왼쪽이 경로 , 오른쪽이 승인할 사람 입니다. 결제 · 마이그레이션에 더해 .github/(CI 설정과 이 파일 자신)와 .claude/(에이전트 설정)가 들어 있다는 것이 핵심입니다.

⭐ 마지막 두 줄이 중요한 이유: 이 두 경로는 관문 자체를 바꾸는 변경 이기 때문입니다. 에이전트가 CI 검사를 지우거나(19차시) 자기 권한을 넓히는 변경을 내 승인 없이 넣을 수 없게 됩니다. 관문을 지키는 관문 입니다.

4.2 ⚠️ CODEOWNERS만으로는 강제가 아니다

19차시와 같은 구조입니다. 워크플로 파일만으로는 관문이 아니었듯, CODEOWNERS 파일만으로도 관문이 아닙니다. 브랜치 보호에서 켜야 강제가 됩니다.

⚠️ 혼자 쓰는 저장소의 함정 : GitHub는 PR 작성자 본인의 승인을 인정하지 않습니다. 에이전트가 내 계정으로 PR을 만들면 내가 승인할 수 없어서 병합이 막히거나, 결국 보호를 끄게 됩니다. 에이전트가 별도 계정(봇 · 앱)으로 PR을 만들게 하는 것이 깔끔합니다(공식 액션은 보통 앱 계정으로 동작합니다 — 설정은 공식 문서 확인).

💡 모든 PR에 사람 승인을 걸면 병목이 생깁니다. 위험한 경로만 CODEOWNERS로 거는 것으로 충분합니다. 3.1절 표의 "사람" 칸에 해당하는 경로만 고르면 됩니다.

---

5. ⭐ 코드를 읽지 않고 승인하는 법

"AI 리뷰 결과에 대한 최종 판단은 사람"이라고 했습니다. 코드를 못 읽는다면 무엇을 근거로 판단할까요? 코드 대신 체크리스트로 판단합니다.

5.1 병합 전 체크리스트

5.2 PR 설명을 비개발자 언어로

에이전트가 PR을 만들 때 설명에 세 칸 을 반드시 채우도록 지침 파일에 넣어 둡니다. 체크리스트의 1 · 2 · 6번이 자동으로 채워집니다.

PR 설명에는 반드시 아래 세 칸을 채운다.
1. 사용자에게 달라지는 점 (화면 · 동작 기준, 코드 용어 없이)
2. 위험 영역 (돈, 개인정보, 데이터 삭제, 권한, 인증, 외부 연결, 관문 설정 중 해당하는 것. 없으면 "없음")
3. 확인 방법 (미리보기 주소에서 무엇을 눌러 보면 되는지)

🔍 읽는 포인트 : 2번의 "없으면 '없음'"이 중요합니다. 빈칸이면 안 본 건지 없는 건지 알 수 없습니다.

설명이 부족하면 위치를 묻습니다. 코드를 못 읽어도 "어디서"와 "어떤 경로로"는 물을 수 있습니다.

결제 금액은 코드의 어디에서 결정돼? 파일 이름과 줄 번호, 그 줄이 하는 일을 한 문장으로.
화면에서 보낸 금액이 그 계산에 쓰이는 경로가 하나라도 있으면 알려줘.

답이 모호하거나 위치가 여러 군데라면 그 자체가 위험 신호 입니다.

---

6. 클래스온에 적용하면 — PR 하나의 일생

에이전트가 feature 브랜치에서 작업, 커밋 검사 통과            (18차시)
→ PR 생성 (설명 세 칸 채움)                                  (5.2)
→ CI 통과 (필수)                                            (19차시)
→ AI 리뷰 코멘트 → 에이전트가 반영                            (2)
→ 결제 · 마이그레이션 · .github · .claude가 바뀌었다면 내 승인 필요 (4)
→ 체크리스트 7항목 확인 후 내가 병합                           (5.1)
→ 자동 배포                                                  (22차시)

🔍 읽는 포인트 : 오른쪽 괄호의 차시 번호를 따라가면 3일차 전반부가 한 줄의 흐름 이라는 것이 보입니다.

---

7. 실습 — 맡기고 검수하기

지시

[1단계 — 리뷰 연동]
클래스온 저장소에 PR마다 AI 리뷰가 돌도록 설정해줘.
- 리뷰 기준은 docs/review-criteria.md에 두고(우선순위: 보안 > 명세 정합성 > 데이터 > 테스트), 취향 지적은 금지.
- 보고 형식: | 심각도 | 파일:줄 | 지적 | 근거(어느 기준, 어느 문서) |
- .github/CODEOWNERS를 만들어 결제, 마이그레이션, .github/, .claude/ 경로를 내 계정으로 지정해줘.
- PR 설명 세 칸(사용자에게 달라지는 점 / 위험 영역 / 확인 방법)을 지침 파일에 규칙으로 추가해줘.

[2단계 — 시험]
결제 금액 계산 파일에 일부러 "화면이 보낸 금액을 그대로 쓰는" 변경을 넣은 시험용 PR을 만들어줘. 병합하지 마.
그 PR에 달린 AI 리뷰 코멘트 원문과, PR 화면에서 내 리뷰가 요청됐는지 보이는 부분을 보고해.
브랜치 보호의 "코드 소유자 리뷰 필수" 설정은 내가 직접 켤 테니 켜는 위치만 알려줘.

받을 증거

• 리뷰 기준 파일 경로와 CODEOWNERS 내용
• 시험용 PR 주소, AI 리뷰 코멘트 원문 (심각도 "높음"으로 금액 문제를 짚었는가)
• PR 화면에 "코드 소유자 리뷰 필요" 같은 표시가 보이는 부분

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 20차시 노트만 근거로 5문제를 내줘. 비전공자 기준으로.
"CI와 AI 리뷰가 잡는 것의 차이", "자동화와 사람의 몫을 가르는 두 축", "CODEOWNERS만으로 강제가 되지 않는 이유"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.