이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- AI 기능 코드 리뷰에서 무엇을 확인해야 하는가?
- 프롬프트, context, 모델 호출, RAG, tool, 로그, eval을 어떻게 점검하는가?
- 개인 프로젝트와 기업 운영 수준의 체크리스트는 어떻게 다르게 적용하는가?
- 출시 전에 반드시 막아야 할 위험 신호는 무엇인가?
개요
AI 기능 리뷰는 프롬프트 문장 리뷰가 아니다. 백엔드 코드 리뷰처럼 경계, 실패 처리, 보안, 테스트, 운영 지표를 봐야 한다.
이 체크리스트는 AI 기능 PR이나 출시 전 리뷰에서 사용할 수 있는 기준이다.
기능 정의
- AI 기능의 업무 유형이 명확한가?
- 사용자에게 보이는 결과와 내부 후속 작업이 분리되어 있는가?
- 실패했을 때 사용자 경험이 정의되어 있는가?
- 사람이 검토해야 하는 고위험 결과가 있는가?
데이터와 권한
- 모델 provider로 보내는 데이터가 문서화되어 있는가?
- 개인정보와 민감정보가 포함되는가?
- tenant와 사용자 권한 필터가 서버에서 강제되는가?
- RAG 검색 결과가 DB 권한 모델과 일치하는가?
- 삭제된 문서가 index에서 제거되는가?
Prompt와 Context
- prompt version이 있는가?
- prompt 변수가 검증되는가?
- context source id가 trace에 남는가?
- token budget이 있는가?
- tool result와 외부 문서는 지시가 아니라 데이터로 감싸지는가?
모델 호출
- SDK 호출이 adapter/client로 감싸져 있는가?
- timeout이 있는가?
- retry 대상과 금지 대상이 구분되는가?
- rate limit과 quota가 있는가?
- circuit breaker 또는 fallback이 필요한 기능인가?
Output Validation
- structured output schema가 있는가?
- validation failure를 처리하는가?
- refusal과 partial output을 구분하는가?
- fallback model도 같은 schema를 지키는가?
- 모델 응답을 그대로 DB 변경에 사용하지 않는가?
RAG
- chunking 기준이 문서화되어 있는가?
- embedding model version이 저장되는가?
- source id, document version, updated_at이 있는가?
- metadata filter가 권한 모델과 일치하는가?
- retrieval eval이 있는가?
Tool Calling과 MCP
- read-only tool과 write tool이 분리되어 있는가?
- write tool에 idempotency key가 있는가?
- tool 호출 audit log가 있는가?
- tool timeout과 retry policy가 있는가?
- agent loop max step이 있는가?
- tool 권한이 서버에서 강제되는가?
Observability
- prompt version, model, token usage, latency가 기록되는가?
- validation failure rate와 fallback rate를 볼 수 있는가?
- source id와 trace id가 연결되는가?
- prompt/context 원문 로그는 제한되는가?
- 고카디널리티 tag가 없는가?
Eval과 테스트
- 대표 eval case가 있는가?
- 권한 경계 테스트가 있는가?
- schema validation 테스트가 있는가?
- prompt 변경 시 regression을 돌리는가?
- 장애 사례가 eval set에 추가되는가?
비용과 운영
- 사용자별 또는 tenant별 quota가 있는가?
- max output token이 있는가?
- batch/eval과 production quota가 분리되는가?
- 비용 폭증 알림이 있는가?
- 기능을 끄거나 degrade할 수 있는가?
코드로 이해하기
PR 템플릿에 AI 섹션을 추가할 수 있다.
## AI Review
- [ ] Prompt version이 변경되었음
- [ ] Eval 결과를 첨부했음
- [ ] Token 사용량 변화가 확인되었음
- [ ] Timeout/retry 정책이 확인되었음
- [ ] 민감정보 로그가 없음
- [ ] Tool calling side effect가 검토되었음
- [ ] Rollback 또는 feature flag가 있음작은 체크리스트라도 리뷰 대화의 질을 크게 높인다.
개인 프로젝트 적용
개인 프로젝트에서는 모든 항목을 만족할 필요는 없다. 다만 다음은 꼭 본다.
- API key 노출 없음
- timeout 있음
- prompt version 있음
- schema validation 있음
- usage log 있음
- eval case 몇 개 있음
기업 운영 적용
기업 운영에서는 거의 모든 항목을 출시 기준으로 본다. 특히 보안, 권한, audit, quota, eval, runbook은 빠지면 안 된다.
위험 신호!
- 모델 호출이 Controller에 직접 있다.
- 권한 없는 문서를 prompt에 넣고 모델에게 무시하라고 한다.
- write tool이 idempotency 없이 retry된다.
- prompt/context 전문이 일반 로그에 남는다.
- 기능을 끄는 방법이 없다.
확인 질문
확인 질문
- AI 기능 리뷰에서 가장 중요한 경계는 무엇인가?
- 데이터/권한 경계, 모델 호출 경계, output validation 경계, tool 실행 경계, 로그 경계다.
- 개인 프로젝트에서도 반드시 확인할 항목은 무엇인가?
- API key 노출 방지, timeout, prompt version, schema validation, usage log, 작은 eval set이다.
- 기업 운영에서 출시 전 반드시 있어야 하는 것은 무엇인가?
- 권한 강제, audit log, quota, eval regression, 장애 런북, degrade 또는 feature flag다.
Spring AI 적용 연결
- Spring AI 기능 리뷰에서는
ChatClient호출 경계, structured output 검증, tool side effect, RAG source, observability가 모두 체크 대상이다. 종합 예시는 13. 고객지원 RAG Capstone에서 이어진다. - 운영 준비 항목은 12. Production Readiness와 인프라 협업을 함께 본다.