AI 에이전트 개발 리뷰, 어디까지 해야 할까? — 기능별 리뷰 Tier 표

「AI가 작성한 코드는 전 행을 리뷰해야 한다」는 사실일까?

AI 에이전트 개발에 있어서, "AI가 생성한 코드는 전 행을 훑어보고 인간이 책임을 담보해야 한다"라는 의견이 있다.

일반론적으로는 옳다. 하지만 실무에서 이를 무턱대고 수행하면 낭비가 많다.

결함이 발생했을 때 예상되는 손실——금전적 손해뿐만 아니라, 신용 실추나 사용자 이탈 등 금액으로 환산하기 어려운 것을 포함하여——보다 더 큰 비용을 리뷰에 투입하고 있다면, 그것은 과잉 투자다.

예를 들어, 단순한 HTML의 전 행을 훑어보는 것은 시간 낭비다. 반면, 주식 거래에서 순식간에 수억 엔이 움직이는 것과 같은 처리는 인간이 전 행을 확인하여 안전을 담보해야 한다.

즉 **「무엇을 볼 것인가」가 아니라 「어디에 집중할 것인가」**가 중요해진다.

이 기사에서는 기능의 성질에 따라 리뷰와 테스트의 깊이를 5단계로 정리한 리뷰 Tier 표를 제안한다.

Tier 표의 두 가지 판단 축

Tier를 결정하는 축은 두 가지가 있다.

영향도— 망가졌을 때 어떤 일이 일어나는가 (금전적 손실, 데이터 소실, 법적 문제…)
복잡도— 망가지기 쉬운가 (조건 분기의 많음, 상태 관리의 복잡함…)

이 두 축의 조합으로 리뷰에 투입해야 할 시간이 결정된다.

Tier S: 전 행 리뷰 + 수동 테스트

돈·개인정보·인증 — 단 한 줄의 실수가 소송이나 수천만 엔의 손실로 직결되는 영역

인명, 거액의 돈, 법적 책임과 직결된다. AI의 출력을 신뢰하지 않는다는 전제하에 전 행을 확인한다.

리뷰 방침

전 행을 인간이 읽고, 로직을 이해한 후 승인한다.

테스트 방침

유닛 테스트 (Unit Test) + 통합 테스트 (Integration Test) + 수동 경계값·이상계 테스트.

구체적인 예

• 결제·송금 처리 (Stripe, 은행 API 연동)
• 인증·인가 로직 (JWT 발행, RBAC, OAuth)
• 개인정보의 암호화·저장·삭제 처리
• 의료·헬스케어 관련 판정 로직
• 주식 거래·금융 상품의 주문 처리
• 법적 문서의 자동 생성 로직

Tier A: 중점 리뷰 + 자동 테스트 필수

데이터 조작·외부 연동 — 처리 전체는 정형적이라도, 에러 핸들링(Error Handling)이나 순서를 틀리면 데이터가 사라짐

버그가 있으면 업무 중단이나 데이터 손실로 이어진다. 주요 로직을 중점적으로 확인한다.

리뷰 방침

비즈니스 로직 부분을 중점 리뷰하고, 정형적인 부분은 가볍게 읽는다.

테스트 방침

유닛 테스트 (Unit Test) 필수 + 주요 플로우의 통합 테스트 (Integration Test).

구체적인 예

• 데이터베이스 마이그레이션(Migration)·스키마 변경
• 배치 처리·비동기 작업 (Celery, 큐)
• 외부 API 연동 (데이터 변환·에러 핸들링)
• 파일 업로드·S3 조작
• 메일 전송 로직 (템플릿 포함)
• 검색·필터링 쿼리 구축

Tier B: 차분(Diff) 리뷰 + 자동 테스트 권장

정형적인 비즈니스 로직 — 패턴이 확립되어 있어 AI의 특기 영역이지만, 의도대로인지 차분(Diff)으로 확인

망가져도 영향 범위가 한정적이다. 변경 차분 확인과 기본 테스트로 충분하다.

리뷰 방침

차분 (Diff) 기반의 리뷰, 의도대로인지 확인.

테스트 방침

주요 경로의 유닛 테스트 (Unit Test), 스냅샷 테스트 (Snapshot Test).

구체적인 예

• CRUD의 API 구현 (표준적인 REST)
• 폼(Form)의 유효성 검사(Validation) 로직
• 관리 화면의 목록·상세·편집
• 로그 출력·모니터링 설정
• Docker / docker-compose 설정
• CI/CD 파이프라인 설정

Tier C: 대략적인 확인 + 동작 확인만 수행

표시·외관 계열 — 망가져도 화면을 보면 알 수 있으며, 치명적인 영향 없음

외관·표시 계열의 기능. 망가져도 치명적이지 않으며, 육안으로 확인할 수 있다.

리뷰 방침

브라우저/실기기에서 동작 확인, 코드는 대략적으로 육안 확인.

테스트 방침

비주얼 회귀 테스트 (Visual Regression) 또는 수동으로 화면 확인.

구체적인 예

• UI 컴포넌트 (버튼, 카드, 모달)
• 반응형 대응·CSS 조정
• 정적 페이지 (LP, About, 이용약관 표시)
• i18n 대응 (번역 파일 추가)
• README나 문서 업데이트
• 테스트 데이터·시드 데이터

Tier D: AI에게 맡겨도 OK (신뢰하고 위임)

설정·보일러플레이트 (Boilerplate) — 망가져도 재생성하면 그만이며, 패턴이 완전히 정해져 있음

보일러플레이트나 자동 생성 코드. 망가져도 즉시 재생성할 수 있다.

리뷰 방침

생성 결과가 빌드/기동되는지만 확인.

테스트 방침

빌드 통과 + lint 에러 없음.

구체적인 예시

• scaffold 코드 (rails generate 등)
• ESLint / Prettier / editorconfig 설정
• 타입 정의 파일 (Type definition file) 자동 생성
• .gitignore / .env.example
• 패키지 설치 및 의존성 (Dependency) 업데이트
• 단순한 HTML/CSS 정적 페이지

Tier 판정에 고민될 때의 6가지 축

자신이 구현하고 있는 기능이 어느 Tier에 해당하는지 고민된다면, 다음 6가지 축으로 판단한다.

판정 축	높음 → Tier를 올림	낮음 → Tier를 내림
금전적 손실	수백만 엔~
...

리뷰 공수(Man-hour) 절감은 태만이 아니다

전제로, AI가 생성한 것이라 할지라도 결과물에 대한 모든 책임은 개발자에게 있다. 이는 변하지 않는다.

그럼에도 불구하고, "그러니까 모든 행을 본다"는 방식은 합리적으로 보일 수 있으나 최적은 아니다. 책임을 진다는 것은 어디에 리스크가 있는지를 스스로 판단하고, 한정된 리소스를 가장 효과적으로 배분하는 것이다. 전수 리뷰(Full-line review)는 언뜻 책임감 있는 행동처럼 보이지만, "어디를 보지 않을 것인가"에 대한 판단을 피하고 있다는 점에서는 사고를 생략하고 있는 것이다.

구체적으로 생각해 보길 바란다. 시니어 엔지니어의 시급이 5,000엔이라고 가정했을 때, AI가 생성한 정적 HTML을 30분 동안 전수 리뷰하는 비용은 2,500엔이다. 그 HTML에 버그가 있다고 했을 때, 예상되는 손실은 얼마인가? 레이아웃 깨짐을 발견하고 즉시 수정하는 정도라면 손실은 거의 제로에 가깝다. 반면, 동일한 30분을 Stripe 결제 처리 리뷰에 할애한다면 수백만 엔 규모의 사고를 방지할 수 있을지도 모른다.

"HTML을 전수 리뷰하는 사람은 없다, 너무 극단적인 예다"라고 생각할지도 모른다. 그렇다면 어디서부터 봐야 하는가? 그 경계선을 긋는 기준을 가지고 있지 않다면, 결국 매번 감(Intuition)으로 판단하거나 전부 보고 있거나 둘 중 하나다.

리뷰 공수의 절감은 투자의 적정화다. 결함 발생 시의 예상 손실보다 더 큰 공수를 리뷰에 소비하고 있다면, 그것은 안전성에 과도하게 키를 꺾은 비합리적인 투자가 된다.

용기를 가지고 "여기는 보지 않겠다"라고 결정하는 것. 그것은 손을 빼는 것이 아니라, 한정된 시간을 리스크가 높은 곳에 집중시키는 투자 판단이다. AI 에이전트가 당연하게 코드를 작성하는 시대에, 이러한 판단을 할 수 있느냐가 개발자의 가치를 가른다고 생각한다.

운용의 팁

동일한 기능이라도 프로젝트의 페이즈(Phase)에 따라 Tier는 변한다. MVP 단계의 랜딩 페이지(LP)는 Tier D로 충분하지만, 정식 출시 후 SEO나 법적 표기(특정 상거래법 표시 등)가 포함되면 Tier C로 올라간다.

프로젝트 초기 단계에서 팀과 Tier 표를 합의해 두면, 리뷰를 할 때마다 "여기는 어디까지 봐야 하는가?"를 논의할 필요가 없다.

Discussion