관광 앱 상세 화면 만들 때 놓치는 데이터 검증과 정보 구조 설계 기준
제주에서 이런저런 가이드 앱이나 유틸리티 서비스를 만들고 운영하다 보면, 결국 가장 손이 많이 가고 컴플레인이 자주 들어오는 곳이 바로 상세 화면(Detail View)입니다. 처음에는 공공데이터 API 땡겨와서 응답 나오는 대로 대충 뿌려주면 끝날 줄 알았는데, 실제 운영해보면 데이터가 대화면에 찍히는 것과 사용자가 그걸 믿고 실제 방문 결정을 내리는 것은 완전히 다른 문제더군요. 공공데이터는 설명문, 이미지, 운영 시간의 출처가 제각각이거나 갱신 주기가 달라서 관리를 까먹으면 바로 버그성 화면이 되기 십상입니다. 나중에 제가 다시 개발할 때 참고하려고 상세 화면의 정보 구조 설계, 데이터 기준일 처리, HTML 정제, 보안 체크리스트까지 실무 기준으로 짧고 명확하게 정리해 둡니다. 1. 내가 겪은 문제: API 응답을 그대로 나열할 때의 한계 공공데이터나 외부 API 응답 필드를 아무 생각 없이 데이터 바인딩해서 UI에 그대로 때려 넣으면 아래와 같은 문제가 무조건 터집니다. 사용자가 진짜 지금 보고 싶어 하는 정보(운영 여부, 주소, 전화번호)가 긴 소개글에 묻힘. 데이터가 비어 있을 때(Null) 화면이 툭 끊기거나 뜬금없는 공백이 생김. 공공데이터의 기괴한 HTML 태그( <br> , > 등)가 화면을 깨뜨리거나 웹뷰 보안 취약점을 만듦. 공개하면 안 되는 내부 API URL, 지도 API Key, 사용자 좌표가 로그나 소스코드에 섞여 들어감. 결국 상세 화면은 단순한 '데이터 표시 창'이 아니라, 사용자가 방문 판단을 내리는 신뢰 화면 으로 접근해야 구조가 안정적으로 잡힙니다. 2. 해결 방법 1: 화면 전용 UI 모델(UiModel) 분리 API 응답 모델(DTO)을 Activity나 Fragment, 또는 Compose 스크린에 그대로 던지지 마세요. 무조건 화면 표시용 독립 모델 을 따로 파서 파싱하는 게 유지보수에 정신 건강을 이롭게 합니다. Kotlin data class TourDetailUiMo...