계획 강도 테스트

초안을 무조건 비판하는 대신, 실제 실행을 막을 수 있는 약한 가정과 빠진 대응을 찾는다. 검토만 요청받았다면 원본은 수정하지 않고, 수정까지 요청받았을 때만 개선안을 만든다.

초보자를 위한 용어

• 가정: 확인하지 않았지만 맞다고 보고 계획에 사용한 생각이다. 지도를 보지 않고 “이 길이 열려 있을 것”이라고 믿는 것과 같다.
• 실패 경로: 계획대로 되지 않을 때 문제가 이어지는 과정이다.
• 복구: 문제가 생긴 뒤 정상 상태로 돌아가는 방법이다.
• 되돌리기: 변경 전 상태로 돌아가는 것이다. 컴퓨터의 실행 취소와 비슷하다.
• 잔여 위험: 고친 뒤에도 남아 있어 계속 지켜봐야 하는 위험이다.

먼저 지킬 원칙

• 사용자가 확정한 목표와 범위를 이유 없이 바꾸지 않는다.
• 사실, 근거 있는 판단, 아직 확인하지 않은 가설을 구분한다.
• “그럴 수 있다”는 가능성만으로 확정 결함이라고 말하지 않는다.
• 중요하지 않은 흠을 채우기 위해 억지 비판을 만들지 않는다.
• 해결책이 원래 계획보다 더 복잡하고 위험하다면 단순한 대안을 먼저 검토한다.
• 외부 파일은 검토 요청만으로 덮어쓰지 않는다.
• 발송, 배포, 결제, 삭제, 운영 환경 변경은 강도 테스트의 범위에 포함되지 않는다.

사용할 때

• 실행 전 계획에서 빠진 전제와 실패 대응을 찾을 때
• 상품·운영·콘텐츠 제안이 실제 고객 상황과 맞는지 점검할 때
• 마이그레이션이나 변경 계획의 중단·복구 기준을 확인할 때
• 초안에 대한 반대 의견을 우선순위별로 받고 싶을 때

맞춤법 교정, 단순 요약, 이미 구현된 코드의 상세 버그 리뷰에는 사용하지 않는다.

입력 확인

대상과 성공 기준이 현재 대화에 분명하면 바로 진행한다. 여러 문서 중 무엇을 검토할지 모호하거나 성공 기준에 따라 판단이 크게 달라질 때만 짧게 확인한다.

검토 대상:
달성하려는 결과:
반드시 지킬 조건:
이미 확인된 근거:
이번 요청: 검토만 / 수정안까지

세 번의 검토

검토 대상의 크기에 맞춰 관련 항목만 다룬다. 각 단계에서 발견한 것이 없으면 없다고 말하고 숫자를 채우지 않는다.

1. 가정 점검

계획이 성립하려면 맞아야 하는 생각을 찾는다.

• 고객이나 사용자가 실제로 이렇게 행동하는가
• 필요한 자료, 권한, 예산, 시간이 있는가
• 외부 도구나 담당자가 제때 작동하는가
• 숫자와 사례의 출처가 현재 상황에도 적용되는가
• 앞 단계의 결과가 다음 단계의 입력으로 충분한가

각 가정을 다음 중 하나로 표시한다.

확인됨: 근거가 있다
부분 확인: 일부 상황에서만 확인됐다
미확인: 아직 확인하지 않았다
반박됨: 현재 자료와 맞지 않는다

미확인이라는 이유만으로 계획을 폐기하지 않는다. 영향이 큰 가정부터 확인 방법이나 의존하지 않는 대안을 제시한다.

2. 실패 경로 점검

실제로 일어날 가능성과 영향이 있는 경로만 본다.

무슨 일이 생기는가
어떻게 알아차리는가
누가 어떤 행동을 하는가
어디까지 되돌릴 수 있는가
복구하지 못하면 무엇이 남는가

상황에 따라 다음 관점을 선택한다.

• 고객: 이해하지 못함, 중도 이탈, 잘못된 결과
• 운영: 담당자 부재, 인수인계 누락, 수작업 부담
• 외부 의존성: 도구 장애, 정책·가격 변경, 자료 지연
• 비용과 일정: 예상보다 큰 비용, 작업 지연, 반복 수정
• 데이터와 권한: 잘못된 입력, 개인정보 노출, 권한 부족
• 변경 안전성: 부분 완료, 중복 실행, 되돌리기 실패

보안이나 법률처럼 전문 확인이 필요한 항목은 확정 판단을 꾸며내지 말고 별도 검토 필요성을 표시한다.

3. 현실성·단순성 점검

• 이 계획이 현재 문제를 직접 해결하는가
• 더 적은 비용과 단계로 같은 결과를 낼 수 있는가
• 실행할 사람에게 필요한 정보와 권한이 있는가
• 성공과 실패를 무엇으로 판단할지 보이는가
• 중단하거나 사용자에게 다시 물어야 할 시점이 있는가
• 검증되지 않은 미래 요구를 위해 복잡성을 추가하지 않았는가

목표에 영향이 없는 개선은 최종안에 억지로 넣지 않는다.

우선순위 정하기

발견 사항을 세 등급으로만 나눈다.

• 지금 수정: 실행 실패나 중요한 손실로 이어질 근거가 있고, 현재 계획에서 다룰 수 있다.
• 실행 전 확인: 영향은 크지만 사실관계나 선택이 더 필요하다.
• 관찰: 가능성은 있으나 근거가 약하거나 지금 고칠 비용이 더 크다.

심각도 점수를 정밀하게 계산한 것처럼 꾸미지 않는다. 왜 해당 등급인지 한 문장으로 설명한다.

수정안 만들기

사용자가 수정안까지 요청했을 때만 만든다.

1. 지금 수정 항목을 먼저 반영한다.
2. 실행 전 확인 항목에는 질문, 테스트, 중단 기준을 넣는다.
3. 관찰 항목은 잔여 위험으로 남긴다.
4. 원래 목표, 범위, 승인 조건이 유지되는지 비교한다.
5. 수정으로 새 복잡성이나 위험이 생기지 않았는지 한 번 더 확인한다.

출력 형식

## 판정
- 한 줄 결론:
- 가장 중요한 이유:

## 지금 수정
1. [발견 사항]
   - 근거:
   - 실패 시 영향:
   - 수정 방향:

## 실행 전 확인
- [확인할 가정]: [확인 방법 또는 필요한 질문]

## 관찰할 위험
- [구체적인 상황]: [어떤 신호를 볼지]

## 수정안
[수정까지 요청받았을 때만 작성]

## 남은 한계
- 이번 검토에서 확인하지 못한 범위

문제가 없다면 “문제 없음”만 쓰지 말고, 무엇을 확인했고 어떤 근거로 통과했는지 알린다.

초보자가 바로 쓸 요청 예시

이 출시 계획이 실제로 가능한지 강도 테스트해줘.
확인된 문제와 아직 가설인 걱정을 구분하고,
지금 꼭 고칠 것만 우선순위로 알려줘. 원문은 아직 수정하지 말아줘.

이 운영 절차에서 담당자가 실수하거나 외부 도구가 멈췄을 때
어디서 문제가 생기는지 찾아줘. 감지 방법과 복구 방법이 빠진 곳도 봐줘.

이 전자책 목차가 초보자에게도 이어지는지 검토해줘.
전문지식이 있다고 가정한 부분, 예시 없이 넘어간 부분,
독자가 다음 행동을 못 정하는 부분만 찾아줘.