제주 삼춘이 관광객을 가르치는 플랫폼, 삼춘한수를 만든 이야기
2025 구름톤 16기에서 대상을 받은 프로젝트 '삼춘한수'의 기획부터 개발까지를 정리한 회고입니다. 주제였던 '문화다양성 증진과 지역경제 활성화'를 '세대 간 단절을 어떻게 연결할까'로 좁히면서, 기획의 주인공이 청년에서 시니어로 바뀐 4일간의 이야기이기도 해요.
프로젝트 기획
출발점은 '워킹 홀리데이를 제주로?' 였어요
구름톤 16기의 주제는 '문화다양성 증진과 지역경제 활성화' 였어요. 여기서 저희는 '문화다양성'을 젊은 세대와 고령 세대를 연결하는 문제로 재해석했어요. 외국인·이주민만 다양성이 아니라, 한국 안에서도 가장 말이 안 통하는 게 세대 사이잖아요. 그리고 그 격차가 가장 극적으로 드러나는 곳이 제주였고요.
첫 방향은 '워킹 홀리데이를 제주로?' 였어요.
"해외 워킹 홀리데이처럼, 청년이 제주에서 잠깐 일하고 돈 벌면서 로컬 문화를 배우면 어떨까?"
제주도는 이미 워케이션·청년 정착 지원금이 활발했고, 관광업 성수기에는 단기 일손이 부족하다는 점도 맞물렸어요. 그런데 저희가 이 가설을 리서치로 검증하면서, 다음 세 단계에서 차례로 벽에 부딪혔어요.
1단계. "청년이 근데 왜 그냥 일하러 오겠어요?"
멘토링 때 나온 질문이에요. 저희가 가정한 건 '돈 + 제주'면 청년이 올 거라는 거였는데, 현실은 달랐어요.
•
제주는 전국에서 연봉 평균이 가장 낮은 지역이에요
•
반면 집값·물가는 서울 다음 수준이고요
•
관광업 단기 알바는 계절성·비정기성이 강해서 커리어로 안 쌓여요
•
그리고 결정적으로, 집 근처에서 해도 되는 단기 알바를 굳이 제주까지 와서 할 이유가 없어요
즉 '청년이 제주에서 일한다'는 전제가 애초에 수요 쪽에서 검증이 안 됐어요. 워킹 홀리데이 프레임은 여기서 접었어요.
2단계. "그럼 누가 일할까?"
질문을 뒤집었어요. "제주에서 일하고 싶어 하는 사람은 누구지?" 그리고 저희가 발견한 주체가 제주에 거주하는 액티브 시니어였어요.
•
은퇴했지만 여전히 사회적 역할과 소득을 원하는 세대
•
이미 제주에 살고 있어서 이주 리스크가 0
•
무엇보다, 귤 농사·해녀·전통 요리·돌담·목공 같은 제주 고유의 기술을 가진 사람들이에요
•
이 기술은 몸으로 배워야 해서 인강으로 전수가 안 되는 종류예요
노인일자리 사업에서도 '경륜전수형'이 정책적으로 강화되고 있었고, '마처 세대'(부모를 부양하는 마지막 세대이자 자식에게 부양받지 못하는 첫 세대)라는 사회적 맥락도 이 방향에 힘을 실어줬어요. 일하는 주체를 청년에서 시니어로 바꾸자, 기획이 풀리기 시작했어요.
3단계. "그럼 누가 배우러 오지?"
주체가 시니어로 바뀌면서 학습자/소비자 자리는 자연스럽게 비었어요. 여기서 다시 후보를 놓고 비교했어요.
후보 | 왜 어려운가 |
제주 청년 | 장기 정착의 현실적 장벽(연봉·물가·커뮤니티) 때문에 서비스 이용자로 전환이 어려움 |
외부에서 유입될 청년 | '제주까지 와야 할 이유'가 약함. 농사·전통 기술에 대한 청년 니즈가 검증되지 않음 |
| 관광객 | 이미 제주에 오는 동기가 있고, 단기 체험에 비용을 지불할 의사가 높음 (리서치로 확인) |
관광객은 이미 제주에 오고 있어요. 대신 카페 사진·게하 파티·서핑처럼 '제주다움'과 크게 관련 없는 소비 루틴에 시간을 쓰고 있었죠. 저희는 여기에 '제주 삼춘에게 직접 배우는 원데이클래스'라는 새로운 선택지를 꽂기로 했어요.
최종 정의: 두 정책 흐름의 교차점
이 지점에서 삼춘한수를 '로컬관광 체험형 정책 × 경륜전수형 노인일자리 정책이 만나는 실행 인프라'로 재정의했어요. 둘 다 정부가 이미 밀고 있는 방향이라 단기 성장은 정책에 올라타고, 정책이 바뀌더라도 '로컬 시니어의 기술을 단기 체험으로 전환' 이라는 핵심 가치는 다른 지역으로 확장할 수 있게 설계했고요.
그래서 삼춘한수가 뭔가요?
한 줄로 정리하면 이래요.
제주 시니어('삼춘')가 보유한 기술을 입력하면, AI가 관광객용 원데이클래스 커리큘럼을 자동으로 생성해주는 매칭 플랫폼.
시니어는 복잡한 클래스 기획을 하지 않아도 새로운 수입을 얻고, 관광객은 카페 사진·게하 파티 대신 제주만의 체험(감귤·해녀·돌담·전통 요리·목공)을 하게 되는 구조예요. 그 과정에서 서로 말이 안 통하던 두 세대가 원데이클래스 안에서 만나게 되고요. 이게 저희가 정의한 '문화다양성 증진'이에요.
UX 기획, 기술적인 결정
4일 동안 저희가 내린 핵심 기획 결정 3가지
시니어 UX는 '양식 채우기'가 아니라 'AI가 채워주기'
초반에 가장 큰 고민은 "60~70대 시니어가 직접 클래스를 등록할 수 있을까?" 였어요. 음성 인식까지 고민했지만 4일 안에 구현할 수 없다고 판단했고, 대신 두 가지 원칙을 세웠어요.
원칙 1. 입력은 최소화, 생성은 AI가
시니어는 본인이 할 줄 아는 기술과 단편적인 정보 몇 가지만 입력해요. 커리큘럼 문장·준비물·단계별 진행법 같은 긴 텍스트는 AI가 초안을 써주고, 시니어는 textarea에 미리 채워진 값을 그대로 쓰거나 다듬기만 하면 돼요.
원칙 2. 한 화면엔 질문 한 개, 글자는 크게
스마트폰에 익숙하지 않은 시니어가 한 화면에서 여러 질문을 동시에 마주하면 바로 이탈해요. 그래서 한 화면에 질문 하나, 입력 하나만 두고 나머지 정보는 모두 뺐어요. 실제 구현에서도 Vapor TextInput의 size="xl", 제목 텍스트는 fontSize: 24px, 카테고리 아이콘은 48px 이모지처럼 기본보다 1~2단계 큰 사이즈를 디폴트로 잡았고요. 버튼도 큼직한 CTA 하나만 하단 고정했어요.
주황색이 시니어의 영역, 파란색이 AI의 영역이에요. 시니어는 처음과 마지막 구간만 담당하고, 중간의 '긴 문장 생성'은 AI가 대신 해줘요. 덕분에 입력 부담은 낮추면서도 AI가 기획의 주도권을 갖지 않는 구조가 만들어졌어요.
양방향 플랫폼이 아니라 '같은 인터페이스'로
당근마켓이 판매자·구매자 같은 앱 안에서 모드만 다르게 쓰는 것처럼, 삼춘한수도 등록 화면과 탐색 화면을 하나의 폼 구조 위에 얹었어요. 해커톤 4일 안에 양방향 플랫폼의 모든 화면을 만드는 건 현실적이지 않았거든요.
퍼널은 10단계, 그리고 AI는 3번 끊어서 호출
최종 등록 플로우는 이렇게 나왔어요.
AI 호출을 한 번에 몰아서 하지 않고 퍼널 중간중간 3번 끼워넣은 게 핵심이에요. 앞 단계에서 시니어가 입력한 답을 바탕으로 뒷 단계 초안을 그때그때 받아보는 구조라서, 10단계가 길게 느껴지지 않았어요.
기술적 접근: 어떤 문제를 어떻게 풀었나
기술 스택 한눈에
•
Frontend: React · Vite · TypeScript · 구름 디자인 시스템 Vapor · 퍼널(다단계 폼) 라이브러리
•
Backend: Python · FastAPI · OpenAI(gpt-4o · 임베딩) · FAISS(벡터 검색 엔진)
•
배포: Jenkins → ArgoCD → 쿠버네티스(EKS) · Nginx 정적 호스팅
Frontend에서 가장 고민한 것: 시니어의 진입 마찰 최소화
프런트에서 저희가 가장 많은 시간을 쏟은 주제는 단 하나였어요.
"10단계짜리 등록 과정을 시니어가 끝까지 완주하게 만들려면 어떻게 해야 할까?"
시니어 UX의 성패는 중간 이탈에서 갈려요. 60~70대 시니어는 한 화면에 정보가 조금만 많아져도 "뭘 해야 할지 모르겠다"며 앱을 닫아요. 그래서 저희는 이탈을 만드는 요소를 하나씩 제거하는 방향으로 붙었어요.
1. 한 화면엔 질문 한 개만
10단계 전체를 한 번에 보여주지 않고, 화면을 10장으로 잘게 쪼갰어요. 한 장에는 질문 한 줄 + 입력 칸 하나 + 다음 버튼만 남겼고, 나머지 보조 정보·도움말·링크는 전부 뺐어요. 시선이 한 곳으로만 모이게요.
2. 글자는 크게, 버튼은 큼직하게
일반 앱보다 한 단계 큰 크기를 기본값으로 썼어요. 제목 글자를 더 키우고, 입력 칸도 한 단계 큰 사이즈로 통일, 카테고리 아이콘은 한눈에 들어올 만큼 큼직하게. 여기에 "돌담 쌓기 복원" 같은 예시를 입력 칸 안에 아예 굵은 글씨로 박아둬서, 시니어가 입력 칸을 눌러도 예시가 사라지지 않고 그대로 남아있게 했어요. 예시를 '힌트'가 아니라 '기본 답변'처럼 보이게 한 거죠. 그리고 '다음' 버튼은 화면 맨 아래에 화면 너비로 크게 고정해서, 다음으로 가는 길을 헷갈릴 수 없게 했어요.
3. 입력 자체를 최소화
긴 문장을 써야 하는 칸(준비물·진행 단계)은 비워두지 않았어요. AI가 앞 단계의 답을 보고 문장을 미리 채워넣은 상태로 열고, 시니어는 읽어보고 수정만 하면 되는 구조였어요. 빈칸을 채우는 부담과 "뭐라고 써야 하지?"라는 막막함을 없앤 것만으로 입력 체감이 완전히 달라졌어요.
4. 디자인 시스템 덕을 많이 봤어요
구름이 제공한 Vapor 디자인 시스템을 쓴 덕분에 버튼을 눌렀을 때 반응이라든가, 입력 칸의 기본 품질 같은 건 신경 쓰지 않고 저희는 '시니어 친화' 부분에만 시간을 쏟을 수 있었어요. 디자이너가 피그마에서 정한 크기·색이 코드에 거의 그대로 반영돼서, 디자이너와 개발자 사이의 커뮤니케이션 비용도 거의 0에 가까웠고요.
Backend에서 가장 고민한 것: 제주 특화 커리큘럼을 어떻게 만들까
백엔드의 핵심 질문은 이거였어요.
"AI에게 그냥 '제주 돌담 쌓기 원데이클래스 만들어줘'라고 하면 될까?"
처음엔 그렇게 해봤어요. 그런데 AI가 만들어주는 커리큘럼은 제주스럽지 않았어요. '돌담'이라고 물으면 그냥 일반적인 돌담 이야기만 나올 뿐, 제주 화산암 특유의 구멍·바람·현무암 지형 같은 이야기는 안 나왔어요. 감귤도 '귤 수확 체험' 수준의 일반론에 그쳤고요. AI가 학습한 일반 지식만으로는 '제주만 가진 디테일'을 채우지 못한다는 걸 확인했어요.
그래서 저희가 택한 방법은 "AI에게 제주 현지 자료를 같이 보여주면서 답하게 하는 것" 이었어요. 쉽게 말해 AI를 참고서를 손에 든 학생처럼 만든 거예요. 이 방식을 업계에서는 RAG(검색 증강 생성)이라고 불러요.
1단계. 제주 현지 자료를 모으기
제주관광공사가 운영하는 공식 사이트 비짓제주(visitjeju.net) 에서 제공하는 API를 통해, 제주도 내 체험·공방·공예·도예·목공·염색·핸드메이드·전통공예 같은 워크샵 정보를 수집했어요. 공식 데이터라 저작권·신뢰성 문제에서 자유로웠고, 콘텐츠마다 제목·소개·태그·주소가 잘 정리되어 있어서 AI가 참고하기 좋은 형태였어요.
2단계. 자료를 '검색 가능한 상태'로 만들기
수집한 워크샵 정보를 그대로 쓸 수는 없어요. 수백 개 자료 중 이번 질문과 관련 있는 것만 빠르게 골라낼 수 있도록 색인(목차)을 만드는 작업이 필요해요. 도서관에서 책 제목·키워드로 원하는 책을 빠르게 찾는 카드 목록을 만드는 것과 비슷해요. 저희는 이 색인을 서버에 저장해뒀고, 같은 질문이 반복되면 중복 계산 없이 바로 꺼낼 수 있게 캐시도 같이 뒀어요.
3단계. 질문이 들어오면 관련 자료를 찾아서 AI에게 같이 건네기
시니어가 "돌담 복원 장인으로 20년"이라고 입력하면, 서버는 이 문장과 가장 관련성이 높은 제주 워크샵 자료 몇 개를 색인에서 꺼내요. 그리고 이 자료를 AI에게 보내는 요청에 "이걸 참고해서 커리큘럼을 만들어줘" 라는 형태로 함께 전달해요. AI는 제주 현지 자료를 손에 든 상태로 답하니까, 일반론이 아니라 제주 디테일이 들어간 커리큘럼을 내놓게 돼요.
실패해도 멈추지 않도록: 자동 폴백
RAG 인덱스 로딩에 실패하거나 OpenAI 임베딩 API에서 예외가 나면, 컨텍스트 없이 기본 프롬프트로 그대로 생성하도록 폴백을 넣었어요. 해커톤 시연에서 RAG가 죽어도 서비스 자체는 계속 돌아가야 했거든요. 이 결정 덕분에 데모 당일 외부 API 지연이 있었는데도 끊김 없이 시연할 수 있었어요.
RAG는 "LLM이 모르는 도메인 지식을 붙이는 장치"가 아니라, "LLM의 기본 응답이 왜 나쁜지"를 먼저 관찰한 뒤에 쓰는 것이에요. 저희가 처음부터 RAG를 염두에 뒀다면 비짓제주 데이터가 꼭 필요한지도 검증 못 했을 거예요. "LLM 직접 호출 → 결과 부족함 확인 → RAG 도입" 순서로 가서 더 의미가 있었던 것 같습니다.
정리하면서 배운 것
4일 해커톤이 저희 팀에 남긴 건 기획에 대한 감각이었어요. 특히 세 가지가 오래 남을 것 같아요.
"막힌 가설은, 해결책을 비틀지 말고 주어를 바꿔야 풀린다."
'워킹 홀리데이를 제주로?'가 막혔을 때 저희는 처음엔 "어떻게 하면 청년이 올까"만 고쳐 쓰고 있었어요. 하지만 답을 아무리 다듬어도 "청년이 왜 제주에 일하러 오지?"라는 근본 질문 앞에서 매번 무너졌죠. 해결책을 비틀기를 멈추고 "그럼 누가 일할까?"로 질문의 주어 자체를 옮기자, 시니어라는 답이 자연스럽게 나왔어요. 기획이 막힐 때 가장 빠른 돌파구는 답을 개선하는 게 아니라 질문의 주어를 바꾸는 것이라는 걸 배웠어요.
"사용자의 역할을 어떻게 정의하느냐가, BM이 어느 시장과 연결될지를 결정한다."
"기획은 '무엇을 할지'가 아니라 '무엇을 안 할지'에서 갈린다."
4일 안에 음성 인식·양방향 플랫폼·관광객 탐색 화면을 다 만드는 건 불가능했어요. 대신 저희는 "음성 대신 AI 초안", "양방향 대신 폼 하나로 통합", "시연은 등록 플로우에만 집중" 으로 각 기능을 포기하거나 좁혔어요. 스코프를 넓히는 결정은 거의 항상 틀렸고, 좁히는 결정은 거의 항상 옳았어요. 기획에서 무엇을 뺄지를 먼저 정하는 습관이 단기 프로젝트의 생존 공식이라는 걸 체감했어요.
기존 로컬 정책들이 대부분 실패한 이유는 시니어를 '도움받는 대상'으로만 고정해둔 것이었어요. 저희가 시니어를 기술을 전수하는 주체로 재정의하자, 서비스가 경륜전수형 노인일자리 정책(B2G) 이라는 수조 단위의 수익 구조와 자연스럽게 맞물렸어요. B2G가 메인 엔진, B2C(관광객 결제)는 그 위에 얹는 단기 검증·보조 수익이고요. 사용자의 역할을 어떻게 정의하느냐에 따라 같은 서비스가 '민간 앱'으로도, '정책 인프라'로도 포지셔닝될 수 있다는 걸 체감했어요. 기획에서 타겟 유저를 정할 때는 그 정의가 어떤 시장 · 어떤 예산 풀과 연결되는지까지 같이 봐야 해요.
삼춘한수 서비스 영상
팀명 만들 때 추웠어요.. 와들와들 히어로즈가 됐어요
