관광데이터 활용 공모전 지원기 1편, 과제 선택과 기획 단계의 고충

친구네 강아지랑 같이 여행을 간 적이 있어요. 식당에 들어가기 전에도, 카페에 들어가기 전에도 매번 “여기 강아지 같이 들어가도 되나” 확인부터 해야 하더라고요. 저는 반려견을 키우지 않아서 그 과정이 있다는 걸 그때 처음 알았습니다. 이 경험이 2026 관광데이터 활용 공모전에서 반려동물 과제를 고르게 된 출발점이에요.

이 글은 그 공모전을 준비한 과정을 세 편으로 나눈 기록 중 첫 번째입니다. 지원하게 된 이유, 10개 과제 중 하나를 고른 이유, 그리고 코드를 쓰기 전 기획 단계에서 부딪힌 문제들을 담았어요. 2편에서는 기존 서비스와 어떻게 달라야 하는지 고민한 과정과 개발 최적화를, 3편에서는 테스트와 배포, 제출 서류 작업과 느낀 점을 정리할 예정입니다. 지금은 1차 심사 자료를 내고 결과를 기다리는 중이에요.

인스타에서 우연히 본 관광데이터 활용 공모전

계기는 별거 없었어요. 인스타그램을 넘기다가 한국관광공사가 올린 공모전 게시물이 우연히 떴습니다. 신청서의 지원 경로 칸에도 그래서 “SNS(인스타그램 등)“라고 적었어요.

타이밍이 묘했어요. 그때 저는 실업급여가 끝나가고 있었고, 끝나면 사업자를 내고 본격적으로 1인 사업을 준비해야 하는 상황이었습니다. 외주로만 먹고사는 것보다 제 서비스로 수익을 만들고 싶다는 생각은 오래전부터 있었는데, 막상 뭘 만들지는 정해진 게 없었어요. 그래서 그냥 “뭐든 해보자”였습니다. 상금이 걸려 있고, 마감 일정이 정해져 있고, 심사라는 외부 기준이 있으니 혼자 일할 때 제일 부족한 강제성이 생기는 셈이었어요.

저처럼 혼자 일하시는 분이라면 공감하실 거예요. 내 서비스를 만들겠다고 마음만 먹으면 기획서만 몇 달 고치다 끝나기 쉽습니다. 공모전은 그 핑계를 없애줘요. 9월까지 완성 서비스를 내야 한다는 조건이 붙으니까요.

공고문에서 먼저 확인한 것들

지원 전에 공고문 원문부터 읽었어요. 공모전 공고는 포스터만 보고 넘기면 꼭 하나씩 놓치는 게 있거든요. 저도 이 글을 정리하면서 시상 내역을 다시 보다가 대상 줄을 빼먹고 읽어서 혼자 헷갈린 적이 있습니다.

한국관광공사 구현 부문 공고문을 보면, 올해 관광데이터 활용 공모전은 세 부문으로 운영됐어요. 웹·앱 개발, 생성형 AI 활용 관광 프롬프톤, 그리고 제가 지원한 웹·앱 구현 부문입니다. 원래 예정됐던 웹·앱 고도화 부문은 운영 계획이 조정되면서 열리지 않았다고 적혀 있어요.

구현 부문의 성격은 이래요. 프롬프톤 수상작을 바탕으로 뽑은 지정과제 10개 중 하나를 골라서, 한국관광공사 OpenAPI를 반드시 활용해 실제로 돌아가는 서비스를 만드는 겁니다. 접수는 7월 6일부터 7월 21일 16시까지였고, 7월 말 예비심사와 온라인 OT, 7월 말부터 9월까지 서비스 개발, 10월 중 1차 심사와 최종심사, 11월 시상식 순서예요. 참가 자격은 국내 거주자면 제한이 없고 팀당 최대 5명까지라서, 1인 지원도 가능했습니다.

시상은 구현 부문만 놓고 보면 최우수상 1팀 300만 원, 우수상 10팀 각 100만 원, 장려상 10팀 각 50만 원이에요. 여기에 대상(문화체육관광부 장관상, 1,000만 원) 1팀이 별도로 있는데, 이건 웹·앱 개발 부문 1차 상위 5팀과 구현 부문 1차 상위 3팀을 모아 통합 최종심사로 뽑습니다. 구현 부문 기준 총 22팀, 상금 총액 2,800만 원이에요.

제일 오래 들여다본 건 배점표였어요. 1차 심사는 서비스 구현성 30점, 서비스 기획력 30점, 데이터 활용 적절성 20점, 서비스 발전성 20점입니다. 최종 PT 심사는 서비스 적정성 30점, 완성도 30점, 실용성 25점, 발표 15점이고요. 이걸 보고 판단한 게 하나 있어요. 제대로 돌아가는 완성품은 기본 입장권이고, 상위권은 기획력의 독창성과 발전성에서 갈린다는 것. 이 판단이 이후 기획 방향을 거의 다 정했습니다.

10개 지정과제 중 6번을 고른 이유

지정과제는 실시간 여행 변수 대응, 오버투어리즘, K-콘텐츠 지방 관광, 인구 감소 지역 생활인구, 만성질환자 외식, 반려동물 출입, 여행 상품 기획 자동화, 홍보물 다채널 배포, 축제 수요 예측, 지역 관광 전략까지 10개였어요. 이 중 제가 고른 건 6번, “모호한 반려동물 출입 조건 및 규정 인지 오류로 현장 입장 거부 및 헛걸음 유발 문제”입니다.

이유는 맨 앞에 쓴 그 여행이에요. 지원 직전에 친구네 강아지와 같이 여행을 갔는데, 어딜 들어가든 동반이 되는지 먼저 확인해야 했습니다. 반려견이 없는 저한테는 낯선 풍경이었어요. 그리고 이게 한 번의 불편이 아니라, 반려견이 있는 집은 외출할 때마다 매번 겪는 일이라는 게 보였습니다. 아, 이건 진짜 있는 문제구나 싶었어요.

그래서 이쪽 서비스 시장을 먼저 조사해봤고, 해볼 만하다고 판단해서 지원했습니다. 다른 과제들도 흥미로운 게 많았는데, 여행사나 지자체 실무자를 타깃으로 하는 과제는 제가 그 업무를 겪어본 적이 없어서 문제를 체감하기 어려웠어요. 반면 6번은 제가 직접 옆에서 본 장면이 있었습니다. 혼자 기획부터 개발까지 하는 입장에서는 문제를 내 눈으로 본 적이 있느냐가 생각보다 크게 작용하더라고요.

데이터 쪽에서도 6번은 출발이 명확했어요. 관광데이터 활용 공모전은 한국관광공사 OpenAPI를 반드시 써야 하는데, 공사가 운영하는 한국관광 콘텐츠랩에는 반려동물 동반여행 API가 따로 있습니다. 반려동물과 함께 갈 수 있는 전국의 관광지, 숙소, 음식점, 쇼핑시설 정보를 제공하는 API예요. 과제와 데이터가 일대일로 맞물려 있으니, 어떤 API를 써야 하나 고민할 시간을 아낄 수 있었습니다. 대신 이 말은 같은 과제를 고른 모든 팀이 같은 데이터를 쓴다는 뜻이기도 했어요. 이 부분은 나중에 꽤 큰 고민거리가 됩니다.

참고로 공고문 뒤에는 과제별 예시 서비스가 붙어 있어요. 6번 예시는 견종·무게 같은 반려동물 특성과 목적지를 설정하면, 장소별 출입 규정을 분석해서 동반 가능 여부와 준비물을 안내하는 서비스였습니다. 해시태그 예시는 반려동물 여행, 헛걸음 방지, 조건 해석, 여행 가이드였고요. 공고문에는 1차 심사 때 해시태그와 연관된 기능으로 기능설명서를 요청할 예정이니 처음부터 고려하라는 안내도 있었어요. 이 문장은 기획 초반부터 메모해 뒀습니다.

지인 대상 구글폼 설문, 5명의 답

지원하고 본격적으로 만들기 전에 지인들 위주로 구글폼 설문을 돌렸어요. 반려동물을 키우는지, 얼마나 자주 같이 외출하는지, 동반 장소를 찾을 때 언제가 제일 힘든지, 정보는 어디서 찾는지, “동반 가능”이라더니 아니었던 경험이 있는지, 이런 서비스를 쓸 의향이 있는지를 물었습니다.

응답은 5명이었어요. 표본으로는 솔직히 약합니다. AI한테 결과를 보여줬더니 이 정도면 심사 근거로는 부족하고 최소 50명에서 100명은 모아야 한다는 답이 돌아왔어요. 맞는 말이긴 한데, 혼자 개발까지 해야 하는 일정에서 설문만 붙잡고 있을 수는 없었습니다. 그래서 숫자로 증명하는 용도가 아니라 방향을 확인하는 용도로만 썼어요.

그 5명 안에서도 신호는 꽤 뚜렷했어요. 5명 중 3명이 제일 힘든 순간으로 “정확한 정보 확인(크기 제한, 실내 가능 여부 등)“을 골랐습니다. 동반 가능이라더니 아니었던 경험으로는 “테라스만 가능한 경우”, “테라스가 많았음”, “추가적인 요구사항이나 제한이 있었다”가 나왔어요. 정보는 대부분 네이버·구글 검색과 인스타, 커뮤니티에서 찾고 있었고요. 사용 의향은 5점 만점에 3, 2, 5, 5, 4였습니다.

제일 오래 남은 답은 따로 있어요. 한 분이 “거부당할까봐 애초에 시도도 안 해본 것 같다”고 적었습니다. 헛걸음 자체도 문제지만, 헛걸음이 무서워서 아예 안 나가는 사람도 있다는 거죠. 이 답을 보고 서비스가 해야 할 일이 “갈 수 있는 곳 목록”이 아니라 “가도 되는지 확신을 주는 것”이라고 정리했어요.

공모전 기획 단계에서 부딪힌 문제들

기획을 시작하면서 제일 먼저 정한 원칙은 “기획서부터 쓰지 않는다”였어요. 공공 API는 막상 열어보면 생각과 다른 경우가 많아서, 데이터가 기획을 배신할 가능성이 높았거든요. 채움률이 30%면 기획을 통째로 바꿔야 하고, 80%면 그대로 가면 되니까 그것부터 확인하기로 했습니다.

그래서 한국관광공사 반려동물 동반여행 API(KorPetTourService2)를 전부 긁어서 필드별로 실제로 얼마나 채워져 있는지 세는 감사 스크립트를 만들었어요. 이게 한 번에 안 끝났습니다. v1부터 v4까지 네 번을 고쳐 돌렸어요.

항목	실측 결과
전체 레코드	9,695건 (이 중 쇼핑 8,647건)
여행 관점에서 의미 있는 레코드	1,048건
’일부구역 동반가능’ 중 구역 정보가 없는 비율	62.6% (506건 중 317건)
음식점 레코드	전국 72곳
규칙 기반 파서 커버리지	약 95% (LLM 없이)

첫 번째 고충은 제 실수였어요. v1부터 v3까지 지역별 집계가 이상하게 적게 나왔는데, 원인을 찾아보니 지역 파라미터를 예전 방식인 areaCode로 넣고 있었습니다. 지금은 lDongRegnCd를 써야 했어요. 그 상태로는 전체 레코드의 6% 정도만 잡히고 있었습니다. 세 번을 틀린 숫자로 분석한 셈이라 꽤 허탈했어요. 공공 API 문서는 버전이 바뀌면서 파라미터가 달라지는 경우가 있으니, 처음 붙이시는 분들은 지역 코드 파라미터부터 확인하시는 게 좋아요.

두 번째는 생각보다 데이터가 적다는 거였어요. 9,695건이라는 숫자만 보면 넉넉해 보이는데, 그중 8,647건이 쇼핑 시설이었습니다. 여행 맥락에서 쓸 만한 건 1,048건이었어요. 음식점은 전국을 통틀어 72곳이었는데, 같은 시기 네이버 지도에서는 광주 한 곳에서만 반려동물 동반 카페가 98곳 검색됐습니다. 친구네 강아지와 여행하면서 제일 많이 확인했던 게 식당과 카페였는데, 공공 데이터는 바로 그 구간이 제일 비어 있었던 거죠.

세 번째가 가장 결정적이었어요. “일부구역 동반가능”으로 분류된 506건 중 317건, 62.6%가 어느 구역에서 되는지 적혀 있지 않았습니다. 설문에서 나온 “가보니 테라스만 되더라”가 데이터에서 그대로 재현되고 있었어요. 데이터에 “가능”이라고 적혀 있어도 사용자 입장에서는 답이 안 되는 상태였던 겁니다.

이걸 보고 판정 구조를 정했어요. 갈 수 있음, 조건부, 확인 필요, 갈 수 없음의 네 단계입니다. 그리고 원칙을 하나 박았어요. 데이터가 비어 있는 것과 허용은 절대 같은 값이 아니다. 코드로 쓰면 null과 'allowed'를 섞지 않는다는 뜻이에요. 정보가 없으면 “가능”으로 뭉개지 않고 “확인 필요”라고 정직하게 띄우기로 했습니다. 다행히 조건 문장 대부분은 규칙 기반 파서로 95% 정도 해석이 돼서, 판정에 AI를 실시간으로 붙이지 않아도 됐어요.

네 번째 고충은 행정이었어요. 지도 서비스는 화면을 움직일 때마다 주변 장소를 불러와야 하는데, 사용자 요청마다 공공 API를 직접 부르면 일일 호출 한도 1,000건으로는 버틸 수가 없습니다. 그래서 데이터를 제 서버 DB에 저장해서 쓰겠다는 로컬 저장 신청서를 8월 5일에 tourapi@knto.or.kr로 보냈어요. 왜 실시간 호출 구조가 불가능한지 기술적인 이유까지 적어서요. 한 달 가까이 답이 없어서 후속 문의 메일까지 준비했는데, 결국 승인을 받았습니다. 매뉴얼 확인 과정에서 데이터 동기화 기준 시각이 새벽 4시 30분이라는 것, 출처는 “ⓒ한국관광공사”로 표기해야 한다는 것도 같이 챙겼어요.

지정과제 예시 서비스에 대한 오해

공모전을 처음 준비하시는 분들이 헷갈리기 쉬운 게 하나 있어요. 지정과제에 붙어 있는 예시 서비스를 “이대로 만들라는 가이드”로 받아들이는 겁니다. 공고문에는 이 자료가 과제 이해를 돕기 위한 참고용 예시이고, 그 내용으로 개발할 의무도 없고 그에 따른 이익이나 불이익도 없다고 분명히 적혀 있어요.

이게 중요한 이유는 예시가 프롬프톤 수상작을 기반으로 정리된 자료라는 점 때문이에요. 이미 한 번 상을 받은 답안이 문제지에 같이 실려 있는 셈이고, 같은 과제를 고른 지원자 전원이 그걸 보고 출발합니다. 예시를 충실하게 구현하면 완성도는 챙길 수 있지만, 배점표의 독창성 항목에서는 남들과 같은 출발선에 서게 돼요. 저도 처음 짠 기획이 이 예시와 거의 겹쳤고, 그 문제를 어떻게 풀었는지가 2편의 주제입니다.

또 하나는 “혼자서는 불리하다”는 생각이에요. 공고문 기준으로 팀은 1인부터 최대 5인까지 가능하고, 심사 항목에 인원수와 관련된 기준은 없습니다. 혼자라서 생기는 진짜 문제는 점수가 아니라 시간이에요. 기획, 데이터 조사, 개발, 문서를 혼자 다 하려면 버릴 걸 빨리 버려야 합니다. 이건 3편에서 더 자세히 쓸게요.

1편을 정리하면

이번 관광데이터 활용 공모전 지원은 거창한 계획에서 시작하지 않았어요. 인스타에 우연히 뜬 게시물, 끝나가는 실업급여, 뭐든 해보자는 마음, 그리고 친구네 강아지와 간 여행에서 본 장면 하나가 전부였습니다. 반려견을 키우지 않는 사람이 반려동물 과제를 고른 게 이상해 보일 수도 있는데, 오히려 처음 보는 사람이라 그 불편이 더 선명하게 보였던 것 같아요.

기획 단계에서 얻은 제일 큰 교훈은 “데이터부터 까보고 기획하라”였습니다. 감사 스크립트를 네 번 고쳐 돌리는 동안 서비스가 해야 할 일이 오히려 분명해졌어요. 장소를 더 많이 보여주는 게 아니라, 비어 있는 62.6%를 정직하게 다루는 서비스. 그렇게 PetOK의 뼈대가 잡혔습니다.

다음 편에서는 이 기획이 지정과제 예시와 너무 비슷하다는 걸 깨닫고 어디서 차별화를 만들었는지, 실제 사용자가 불편해하는 지점을 어떻게 찾았는지, 그리고 서버 응답을 어떻게 줄였는지를 정리할게요.