


실패하는 테스트로 먼저 재현한 뒤 최소한으로 버그 고치기
버그 보고를 받았을 때 쓴다. AI가 버그가 어느 부분의 문제인지 나누고, 사용자에게 보이는 실패를 실패하는 테스트로 재현하고, 진짜 원인을 찾아 최소한으로 고친다. 테스트는 재발 방지용으로 남기고, 사용자와 같은 순서로 다시 해 보며 고쳐졌는지 확인한다.
이 AI 규칙을 사용하려면
## 코드를 고치기 전에 버그가 어느 부분의 문제인지 나누기
증상이 나타난 파일이 아니라 관찰 가능한 영향에서 시작한다. 유용한 초기 분류 결과는 다음 조사자에게 무엇이 실패했는지, 누구 또는 무엇이 영향을 받는지, 어느 구성 요소가 해당 동작을 책임지는지 알려 준다.
### 조치 전에 분류한다
- 결함을 핵심 동작, 시스템 또는 통합 동작, 호스트 환경 동작 중 하나로 분류한다.
- 증상을 표시하는 구성 요소와 실패한 동작을 제어하는 구성 요소를 구분한다.
- 증거가 현재 구성 요소 밖을 가리키면 해당 동작을 책임지는 경계로 작업을 전달한다.
### 증거의 경계를 정의한다
문제를 일으키는 입력, 초기 상태, 사용자의 정확한 행동, 예상 결과, 실제 결과, 관련 환경을 기록한다. 사실과 가설은 따로 나열한다. 초기 분류 단계에서는 구현 코드를 수정하지 않는다. 다음 단계에서 먼저 재현 가능한 실패를 확립해야 한다.
이 분류는 잠정적이다. 이후의 증거가 분류와 모순되면 이 단계로 돌아와 경계를 수정하고, 실제로 해당 동작을 책임지는 계층으로 테스트를 옮긴다.
## 사용자에게 보이는 실패를 실패하는 테스트로 재현하기
보고 내용을 사용자가 경험하는 현상과 일치하는 가장 짧고 반복 가능한 시나리오로 바꾼다. 의미 있는 입력, 상태, 순서, 눈에 보이는 결과는 유지하고, 실패에 영향을 주지 않는 부수적인 준비 과정은 제거한다.
### 가장 가깝고 신뢰할 수 있는 테스트 계층을 선택한다
- 분리된 로직에는 범위를 좁힌 단위 테스트나 구성 요소 테스트를 사용한다.
- 저장, 화면 표시, 전송 또는 여러 구성 요소가 관여하면 통합 테스트나 시스템 테스트를 사용한다.
- 실패가 실제 상호작용, 초점, 시점, 화면 이동 또는 시각적 상태에 의존하면 브라우저 테스트나 종단 간 테스트를 사용한다.
소스 코드를 변경하기 전에 회귀 테스트를 작성한다. 테스트를 실행하여 준비 과정의 오류, 오래된 자원, 누락된 데이터 또는 무관한 검증문 때문이 아니라 보고된 원인으로 실패하는지 확인한다. 실제로 실패하는 모습을 한 번도 확인하지 않은 테스트는 결함의 증거가 아니다.
동작을 자동화할 수 없다면 그 이유를 문서화하고, 결정적인 수동 절차, 화면 캡처 순서, 추적 기록 또는 측정 결과처럼 가장 강력하고 반복 가능한 대안을 확보한다. 실패 증거를 신뢰할 수 있을 때까지 구현 코드를 변경하지 않는다.
## 동작이 처음 어긋나는 지점을 찾아 근본 원인 밝히기
실패 재현이 안정된 후에만 조사한다. 여러 개의 타당한 가설을 만들고, 한 번에 여러 항목을 변경하는 대신 범위를 좁힌 관찰로 각 가설을 검증한다.
### 최초의 차이를 추적한다
실패하는 입력이 상태 변화, 경계, 제어 흐름을 지나는 과정을 따라간다. 성공 사례와 실패 사례를 비교하고, 실제 동작이 예상 동작에서 처음 벗어나는 지점을 찾는다. 재현 결과가 관련성을 나타내는 경우에만 생성된 결과물, 저장된 값, 통합 응답 또는 시점을 조사한다.
각 가설에 대해 어떤 증거가 가설을 확인하거나 기각할지 예측하고, 이를 판별할 수 있는 최소한의 점검을 실행한 뒤 결과를 기록한다. 근본 원인을 그로 인한 후속 손상 및 버그를 더 쉽게 관찰하게 할 뿐인 조건과 구분한다.
원인을 분리하는 동안 실제 서비스 로직을 수정하지 않는다. 모든 가설이 맞지 않으면 재현 단계로 돌아가 전제를 확인하고, 분류를 다듬고, 새로운 증거 기반 가설을 세운다.
## 최소한으로 고치고 테스트를 회귀 방지용으로 남기기
근본 원인이 분리되면 의도한 동작을 복원하는 가장 작은 범위만 변경한다. 외부에 공개된 규약과 무관한 동작을 보존하고, 실패 사례에 필요하지 않은 정리, 재설계 또는 구조 개선은 피한다.
원래 실패했던 테스트를 먼저 실행한다. 검증문을 약화하거나, 시나리오를 건너뛰거나, 테스트 준비물이 버그를 더 이상 실행하지 않게 해서가 아니라 원인이 제거되었기 때문에 테스트가 통과해야 한다. 이 테스트는 영구적인 회귀 방지 수단으로 유지한다.
그다음 직접 영향을 받는 테스트 그룹과 관련 정적 검사, 코드 규칙 검사 또는 형식 검사를 실행한다. 변경이 공유 경계를 넘거나 더 좁은 범위의 증거가 광범위한 위험을 나타낼 때만 검사 범위를 더 넓은 모음으로 확장한다. 새로 발생한 모든 실패를 증거로 취급한다. 실제 회귀라면 수정하고, 제안된 수정이 불완전했다면 근본 원인 분리 단계로 돌아간다.
최종 변경 내역에서 의도하지 않은 수정, 중복 로직, 약화된 검증, 누락된 경계 사례를 검토한다. 이 단계에서 수정이 완료되려면 대상 동작과 직접 영향을 받는 인접 동작이 모두 검사를 통과해야 한다.
## 실제 환경에서 사용자와 같은 순서로 다시 해 보고 고쳐졌는지 확인하기
자동화된 테스트는 필요하지만 실제 사용자 경로의 확인을 대신하지는 못한다. 결함을 드러냈던 것과 동일한 의미 있는 입력과 상태를 사용하여 대표 실행 환경에서 원래의 사용자 대상 절차를 반복한다.
눈에 보이는 경계에서 변경 전후의 결과를 비교한다. 해당하는 경우, 사용자가 최종적으로 의존하는 저장 결과, 표시 결과, 발행된 이벤트, 통합 전달 또는 다시 생성된 결과물도 확인한다. 다른 사람이 결론을 검증할 수 있도록 환경, 절차, 관찰한 결과를 기록한다.
수동으로 확인한 동작이 여전히 실패하거나, 자동화 결과와 다르거나, 문서화되지 않은 우회 방법을 요구한다면 결함이 해결되었다고 선언하지 않는다. 분류 또는 재현 단계로 돌아가 놓친 조건을 테스트에 반영하고, 원인 분리, 수정, 회귀 확인, 검증의 순환을 반복한다.
간결한 증거 보고서로 마무리한다. 보고서에는 결함 분류, 확인된 재현, 근본 원인, 최소 변경, 회귀 방지 범위, 직접 영향을 받는 검사, 실제 흐름의 결과를 담는다. 결함이 반복되는 아키텍처 유형을 드러낸 경우에만 재사용 가능한 예방 규칙을 추가하고, 일회성 세부 사항은 테스트와 변경 기록에 남긴다.
