기능을 넓히는 순서가 아니라 불확실성을 줄이는 순서로 진행했다. 단계마다 완료 기준을 먼저 정하고 그걸 넘어야 다음으로 갔다.
1. 모의 기준선 — 외부 키 없이 도구와 판단 흐름부터 만들었다. 고정된 예시 데이터로 전체 경로를 반복 실행할 수 있으면 통과로 봤다.
2. 실제 소스 연결 — 공공 API 4종을 내부 5개 소스로 붙이고 원본 응답을 내부 형식으로 정리했다.
3. 근거와 판단 — 시설이 있는지, 지금 도는지, 동선이 이어지는지를 각각 다른 근거로 나눴다. 부족하면 낮은 위험으로 내려가지 않게 했다.
4. 경로 정확도 — 최단경로 API 전용 역 코드와 호선 확인을 넣어 비정상 환승 후보를 걸러내고 회귀 테스트로 고정했다.
5. 사용자 답변 — 결론과 미확인 정보, 출발 전 행동이 빠지지 않는지를 통과 기준으로 삼았다.
6. 운영 경계 — 타임아웃과 캐시, 인증, 상태 점검을 붙이고 일부러 실패시켜서 확인했다.
7. 품질 검증 — 실제 API 품질과 성능 비교, 사용성 검토를 돌리면서 자동 테스트와 사람 평가의 범위를 나눴다.
새 기능보다 정확성과 사용성, 재현성을 높이는 안정화 단계다. 다음은 실제 교통약자 사용자와 접근성 전문가의 피드백, 그리고 공개 호스팅 환경의 운영 검증이다.
동작을 바꾸는 작업과 구조를 고치는 작업은 섞지 않았다. 모의 데이터와 회귀 테스트를 먼저 만들고 실제 API는 별도 점검으로 확인했다.
새 API나 인프라는 실제로 필요해질 때만 추가했고, 구현한 것과 로컬에서 검증한 것과 실제 운영해본 것을 같은 표현으로 묶지 않았다.
단계별 결과물은 테스트·성능·사용성 검증에서 확인할 수 있다.