여기 적는 건 둘로 나뉜다. 개발 중 실제로 재현한 문제 두 건과, 운영을 가정해 일부러 실패시켜 확인한 시나리오. 겪지 않은 것을 겪은 것처럼 쓰지 않으려고 나눴다.

실제 사례 1 · 2호선 직행인데 이촌과 사당을 거쳐 왔다

홍대입구에서 삼성으로 가는 직행 질문에 이촌과 사당을 지나는 이상한 환승 경로가 나왔다. 실제 API로 검증하다가 재현한 문제다.

원인이 두 개 겹쳐 있었다. 일반 역 번호와 최단경로 API 전용 역 코드를 같은 값으로 가정했고, 이름으로 조회할 때 환승역의 다른 호선이 선택될 수 있었다. API 입장에서는 정상 응답이라 에러도 안 났다. 그래서 더 늦게 찾았다

그래서 API 응답으로 직접 확인한 역·호선별 경로 코드를 따로 관리하기로 했다. 양쪽 코드가 다 있으면 코드로 조회하고, 없으면 이름으로 조회하되 그 사실을 기록한다. 입력한 호선과 다른 후보는 아예 제외한다.

홍대입구에서 삼성이 환승 0회에 2호선으로, 이촌과 사당을 안 거치고 나오는지를 테스트로 고정했다.

남은 위험도 있다. 등록하지 않은 역은 여전히 이름으로 조회해야 하고, 공공 API의 코드가 바뀌는 건 계속 확인해야 한다.

실제 사례 2 · 상세한데 뭘 해야 할지 모르겠는 답변

내부 검토 두 차례에서 행동 가능성이 모두 5점 만점에 2점이었다.

근거와 주의사항은 많았다. 그런데 사용자가 출발 전에 무엇을 확인해야 하는지는 바로 안 보였다. 현재 판단과 첫 행동이 답변 앞부분에 없었던 게 원인이었다.

내부 점수보다 결론과 권장 확인을 먼저 보여주도록 답변 형식을 바꿨다. 판단 → 요약 → 권장 확인 순서로 개편하고, 역별 확인·미확인 근거도 사용자 조건에 맞춰 나눴다. 첫 세 줄 안에 판단과 첫 행동이 보이는지를 검토 기준에 추가했다.

다만 이건 내부 검토지 실제 사용자 검증이 아니다. 교통약자 당사자와 접근성 전문가의 평가가 남아 있다.

일부러 실패시켜서 확인한 것

아직 실제 경험으로 쓰지 않는 것

• 공개 호스팅 엔드포인트 장애와 복구