---
type: template
domain: product
role: Backend
status: active
last-reviewed: 2026-07-27
---

# 관측·테스트 계획

> API 계약의 정상·실패 경로를 테스트와 운영 신호로 동시에 검증한다. 여기서 만든 시나리오·증거가 QA의 테스트케이스와 납품 테스트결과서의 입력이 된다.

## 관측성

> 관측 신호는 오픈 이후 하자보수 기간의 원인 규명 근거이기도 하다 — 무상(버그)/유상(개선) 경계 판단에 로그가 쓰인다.

| 이벤트·경로 | 구조화 로그 필드 | metric·단위 | alert 조건 | 추적 ID | 마스킹 항목 |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 테스트 매핑

| 요구사항·계약 (RTM ID) | 테스트 수준 | 시나리오 | fixture·mock | 예상 결과 | 실행 명령·증거 |
|---|---|---|---|---|---|
|  | 단위 / 통합 / 계약 / E2E |  |  |  |  |

## 필수 실패 시나리오

| 시나리오 | 재현 방법 | 기대 상태코드·도메인 상태 | 로그·metric |
|---|---|---|---|
| 입력 검증 실패 |  |  |  |
| 미인증·권한 부족 |  |  |  |
| 없는 자원·충돌 |  |  |  |
| DB 실패 |  |  |  |
| 외부 timeout·rate limit |  |  |  |

## 완료 질문

- [ ] 요청·응답·상태코드 계약이 자동 테스트에 매핑됐는가?
- [ ] 권한·실패·timeout 경로를 반복 재현할 수 있는가? (검수 재검증·인수인계 후 회귀에 필요)
- [ ] 로그만으로 실패 요청을 추적하되 token·비밀번호·PII는 남기지 않는가?
- [ ] alert가 실제 사용자 영향 및 계약된 SLA 항목과 연결되는가?
- [ ] 미수행 테스트를 PASS로 계산하지 않는가?

## 판정 기준

> PASS 기준은 [[요구사항과 완료 조건]]의 기계 검증 가능 형식으로, 착수 전 발주사와 합의된 값만 유효하다.

| Gate | PASS 기준 | 차단 여부 | 판정자 |
|---|---|---|---|
| API 계약 |  |  |  |
| 단위·통합 |  |  |  |
| 보안 기본기 |  |  |  |
| 성능·관측 |  |  |  |