LOVETRIP에서 외부 응답을 그대로 화면에 보내지 않은 이유

LOVETRIP은 흩어진 여행 정보를 한 화면의 계획 흐름으로 모으려는 제품이었다. 사용자에게는 장소와 코스로 보이지만, 내부에서는 여러 출처의 데이터를 다뤄야 했다. 같은 장소를 설명하는 필드도 출처마다 다르고 갱신 시점도 같지 않았다.

외부 형식이 내부 규칙이 되는 순간

외부 API 응답을 그대로 컴포넌트에 전달하면 처음에는 빠르다. 하지만 화면마다 누락값과 다른 필드 이름을 처리하기 시작하면 외부 형식이 코드 곳곳에 퍼진다. 출처 하나가 바뀌었을 때 추천 로직과 지도, 상세 화면을 함께 수정해야 할 수 있다.

LOVETRIP에서는 외부 데이터를 변환 경계를 거쳐 내부 모델로 다루는 방향을 택했다. 수집 작업과 사용자 요청을 처리하는 서비스도 실행 단위로 구분했다. 수집 실패가 사용자 요청의 실패로 곧바로 연결되지 않도록 하려는 판단이었다.

변환은 이름 바꾸기 이상이었다

주소 문자열을 옮기는 것과 위치가 유효한지 확인하는 것은 다르다. 값이 없을 때 기본값을 넣을 것인지, 추천 후보에서 제외할 것인지도 제품의 결정이다. 지금 다시 만든다면 출처, 갱신 시각, 변환 실패 이유를 모델과 운영 기록에서 추적할 수 있게 하겠다.

특히 정보가 없다는 것과 비용이 무료라는 것은 같은 값으로 표현하면 안 된다. 가격을 모른다고 0을 넣으면 예산 추천이 실제보다 낙관적으로 보일 수 있다. 변환 계층이 이런 불확실성을 지워 버리면 화면은 깔끔하지만 판단은 부정확해진다.

데이터 출처를 보이게 한 이유

기존 회고에는 데이터 출처를 명시하게 된 배경도 남겼다. 여러 정보가 섞여 있을 때 사용자는 최신 정보인지 궁금해한다. 추천 결과만 보여 주기보다 원문을 확인할 수 있게 하는 것이 신뢰를 유지하는 데 필요했다. 다만 출처 링크가 있다는 사실만으로 현재 운영 시간이나 가격이 보장되는 것은 아니다.

이 경험으로 외부 데이터를 받아오는 일과 제품에서 사용할 수 있게 만드는 일을 나눠 보게 됐다. API 연결은 시작이었다. 데이터의 의미를 정하고, 모르는 부분을 모른다고 남기고, 변경을 한 경계에서 다루는 작업이 실제 유지보수의 중심이었다.

관련 기록: LOVETRIP 설계와 트레이드오프