---
title: "적대적 리뷰"
description: “괜찮아 보이네”라는 식의 대충 넘어가는 검토를 방지하는 논리적 추론 기법
sidebar:
  order: 5
---

문제를 반드시 찾게 만들어 더 깊은 분석을 강제합니다.

## 적대적 리뷰란?

리뷰어가 *반드시* 이슈를 찾아야 하는 리뷰 기법입니다. "좋아 보입니다"는 허용되지 않습니다. 리뷰어는 문제가 존재한다고 가정하고, 냉정한 태도로 그것을 찾아냅니다.

부정적이 되자는 뜻이 아닙니다. 제출물을 도장 찍듯 승인하는 대충 훑기가 아니라 실제 분석을 강제하기 위한 것입니다.

**핵심 규칙:** 이슈를 찾아야 합니다. 발견 항목이 0개면 중단하고 다시 분석하거나 이유를 설명합니다.

## 왜 효과적인가

일반 리뷰는 확증 편향에 취약합니다. 작업을 훑고, 눈에 띄는 것이 없으면 승인합니다. "문제를 찾아라"라는 요구는 이 패턴을 끊습니다.

- **철저함을 강제** - 충분히 열심히 살펴 이슈를 찾기 전까지 승인할 수 없습니다
- **빠진 것을 잡아냄** - "여기에 없는 것은 무엇인가?"가 자연스러운 질문이 됩니다
- **신호 품질 향상** - 발견 사항이 막연한 우려가 아니라 구체적이고 실행 가능해집니다
- **정보 비대칭** - 원래 의사결정 과정을 보지 않은 새 컨텍스트에서 검토해 의도가 아니라 산출물을 평가합니다

## 사용 위치

적대적 리뷰는 코드 리뷰, 구현 준비 상태 점검, 사양 검증 등 BMad 워크플로 전반에 나타납니다. 어떤 때는 필수 단계이고, 어떤 때는 고급 도출이나 파티 모드처럼 선택 사항입니다. 검토가 필요한 산출물에 맞춰 패턴이 적응합니다.

## 사람의 필터링 필요

AI는 문제를 찾도록 *지시*받았으므로 문제를 찾습니다. 실제로는 존재하지 않을 때도 그렇습니다. 사소한 지적을 이슈처럼 포장하거나, 의도를 오해하거나, 아예 환각성 발견 사항을 낼 수 있습니다.

**무엇이 실제인지 사용자가 결정합니다.** 각 발견 사항을 검토하고 노이즈를 버리고 중요한 것을 고치세요.

## 예시

다음 대신:

> "인증 구현은 괜찮아 보입니다. 승인합니다."

적대적 리뷰는 다음처럼 나옵니다.

> 1. **HIGH** - `login.ts:47` - 실패한 로그인 시도에 속도 제한 없음
> 2. **HIGH** - 세션 토큰이 localStorage에 저장됨(XSS 취약)
> 3. **MEDIUM** - 비밀번호 검증이 클라이언트 측에서만 수행됨
> 4. **MEDIUM** - 실패한 로그인 시도에 대한 감사 로깅 없음
> 5. **LOW** - 매직 넘버 `3600`은 `SESSION_TIMEOUT_SECONDS`가 되어야 함

첫 번째 리뷰는 보안 취약점을 놓칠 수 있습니다. 두 번째는 네 가지를 잡았습니다.

## 반복과 수확 체감

발견 사항을 처리한 뒤 다시 실행하는 것도 고려하세요. 두 번째 실행은 대개 더 많은 것을 잡아냅니다. 세 번째도 항상 쓸모없지는 않습니다. 하지만 각 실행에는 시간이 들고, 언젠가는 사소한 지적과 거짓 발견 사항만 남는 수확 체감 구간에 들어갑니다.

:::tip[더 나은 리뷰]
문제가 존재한다고 가정하세요. 잘못된 것뿐 아니라 빠진 것을 찾으세요.
:::