라벨이 데이터설계인 게시물 표시

공공데이터 기반 관광 앱 개발 시 데이터 저장 위치 선정 및 설계 방법 (공공누리 라이선스 주의점 포함)

공공데이터를 활용해서 관광 앱을 만들 때 가장 먼저 부딪히는 문제가 바로 "이 수많은 데이터를 어디에 두고 관리할 것인가"입니다. 모든 데이터를 서버 API로만 가져오자니 서버 비용이 걱정되고, 그렇다고 앱 안에 JSON 파일로 다 밀어 넣자니 나중에 데이터가 바뀌었을 때 대책이 안 섭니다. 저의 경우도 관광 데이터를 다루면서 처음에는 개발하기 편한 방식으로만 접근했다가, 나중에 운영 중에 데이터가 바뀌거나 라이선스 문제로 고생한 적이 있습니다. 이래저래 운영하면서 정립한 데이터 위치 선정 기준과 설계 방법을 자꾸 까먹어서 실무 메모용으로 정리해 둡니다. 운영하다 보면 꼭 터지는 데이터 구조 문제 처음에 구조를 잘못 잡고 배포하면 운영 단계에서 아래와 같은 골치 아픈 상황들을 마주하게 됩니다. 앱 업데이트 지연: 운영 시간 오타 하나 고치거나 폐업 확인되어 데이터 지우려는데, 데이터가 앱 내부 asset에 묶여 있어서 매번 마켓 앱 업데이트 심사를 받아야 합니다. 앱 용량 비대화: API 호출 비용 좀 아끼겠다고 관광지 수천 개의 이미지 URL과 정보를 전부 앱에 내장했다가 초기 다운로드 용량이 수백 MB로 커집니다. 이미지 엑박(Broken Link): 공공데이터 원본에서 이미지 URL 경로를 바꿨는데, 앱에 반영할 방법이 없어 사용자들이 엑박만 보게 됩니다. 라이선스 위반 위험: 공공데이터 출처표시나 이용 조건을 앱 안에서 제대로 안내하지 않았다가 법적 문제가 생길 수 있습니다. 불필요한 서버 비용: 굳이 서버가 없어도 되는 고정된 코드나 카테고리 데이터까지 매번 서버 API를 호출하게 만들어 서버 유지비만 늘어납니다. 보안 취약점: 급하게 개발하느라 앱 내부에 실제 공공데이터 API 키나 서버 관리자 경로를 하드코딩해서 노출하는 실수를 하기도 합니다. 데이터의 저장 위치는 개발이 편한 곳이 아니라 "얼마나 자주 바뀌는지, 용량이 얼마나 큰지, 오프라인 환경이 필요한지, 라이선스 조건이 무엇인지"를 기준으로 철...