<aside> 🛠️
개발 중 실제로 재현한 문제와 운영을 가정해 실패 주입으로 검증한 시나리오를 분리해서 기록한다.
</aside>
| 항목 | 내용 |
|---|---|
| 상태 | Live 개발 검증에서 재현 · 회귀 테스트 반영 완료 |
| 증상 | 2호선 홍대입구→삼성 직행 질문이 이촌·사당을 거치는 비정상 환승 경로로 반환됨 |
| 원인 | 일반 역 ID와 최단경로 API 전용 역 코드를 같은 값으로 가정했고, 이름 조회가 환승역의 다른 호선을 선택할 수 있었음 |
| 의사결정 | API 응답으로 검증한 역·호선별 Route Code를 별도 Registry로 관리 |
| 대응 | 양쪽 Code가 있을 때 Code 조회, 없으면 이름 Fallback과 Limitation 기록, 입력 호선과 다른 후보 제외 |
| 검증 | 홍대입구→삼성의 환승 0회·2호선·금지 경유역 미포함을 Fixture로 고정 |
| 남은 위험 | 등록하지 않은 역은 이름 Fallback이 필요하며 공공 API Code 변경을 계속 검증해야 함 |
| 항목 | 내용 |
|---|---|
| 상태 | 내부 Live Review에서 발견 · 개선 반영 · 사람 재평가 대기 |
| 증상 | 두 차례 Review에서 행동 가능성이 모두 2/5였고, 사용자가 출발 전에 무엇을 해야 하는지 바로 알기 어려웠음 |
| 원인 | 근거와 주의사항은 많았지만 현재 판단과 첫 행동이 답변 앞부분에 정렬되지 않았음 |
| 의사결정 | 내부 Score보다 현재 결론과 권장 확인을 먼저 보여주는 canonical user_message를 기준으로 삼음 |
| 대응 | 판단 → Headline → 권장 확인 순서로 개편하고 역별 확인·미확인 근거를 사용자 조건에 맞춰 분리 |
| 검증 | 첫 세 줄에서 판단과 첫 행동이 보이는지 Fixture와 Review 기준에 추가 |
| 남은 위험 | 새 Packet은 생성했지만 실제 교통약자 사용자와 전문가의 재평가는 아직 필요 |
엘리베이터 위치와 실시간 상태의 이름·ID가 항상 일치하지 않았다. 시설 ID가 같거나 정확한 이름이 유일하게 일치하는 경우에만 같은 시설로 결합하고, 애매하면 상태를 붙이지 않은 채 미확인으로 남겼다. 잘못 합치는 것보다 답을 보류하는 쪽을 선택했다.
| 시나리오 | 기대 동작 | 분류 |
|---|---|---|
| 일부 공공 API 실패 | 확인 가능한 근거와 실패 Source를 함께 반환 | 실패 주입 검증 |
| 최신 조회 실패 + Stale 존재 | 허용 기간 안에서 경고와 기준 시각을 포함해 사용 | 실패 주입 검증 |
| Redis 사용 불가 | Cache Miss로 계속 처리하고 Health를 Degraded로 표시 | 구현·테스트 완료, 실제 운영 장애 아님 |
| 지원 범위 밖 | 시설 없음이나 API 장애로 오해시키지 않음 | Fixture·Live 범위 검증 |
| 인증·입력 제한 | 기본 Token 거부, 크기 제한, Secret 비노출 | 자동 테스트 |
<aside> ⚠️
위 항목은 운영을 고려해 준비했거나 Backlog로 남긴 내용이며, 실제 Production 트러블슈팅 경험으로 표현하지 않는다.
</aside>