여기 적는 건 둘로 나뉜다. 개발 중 실제로 발견한 문제 두 건과, 운영을 가정해 일부러 실패시켜 확인한 시나리오다. 개발 환경 쪽에서 겪은 CI 실패는 개발 하네스와 검증 게이트에 따로 적었다.

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

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

원인은 두 가지였다. 최단경로 API 전용 역 코드를 일반 역 번호와 같은 값으로 가정했고, 역 이름으로 조회하면 환승역에서 요청과 다른 호선이 잡힐 수 있었다. 둘 다 API 쪽에서는 정상 응답이라 에러가 나지 않았다.

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

홍대입구에서 삼성까지 환승 없는 2호선 경로가 이촌과 사당을 거치지 않고 나오는지를 테스트로 고정했다.

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

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

사람이 읽고 1~5점으로 매기는 사용성 검토를 내부에서 두 차례 돌렸는데, 행동 가능성(출발 여부나 다시 확인할 행동을 정할 수 있는가)이 두 번 다 2점이었다.

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

답변을 판단 → 요약 → 권장 확인 순서로 바꾸고, 역별 확인·미확인 근거도 사용자 조건에 맞춰 나눴다. 첫 세 줄 안에 판단과 첫 행동이 보이는지를 검토 기준에 추가했다.

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

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

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

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