48시간 개발 후 한 달간 운영한 결과와 회고. 사용자 행동 패턴 발견, 데이터 분석, 그리고 개선 방향.

핵심 요약: 402명이 유입되어 67명이 완료했다. 광고와 Direct 유입 사용자의 전환율 차이는 시작률에서 발생했고, 시작 후 완료율은 유사했다. 랜딩 페이지가 최대 병목이었으며, 진입 장벽은 타겟을 필터링하는 역할을 했다. 완료자들은 극단적 만족도를 보였다(하트 평균 20.9회). 가장 아쉬운 점은 질문별 이탈률을 측정하지 못한 것이다.

가을에 혼자 iOS, Android 앱을 출시한 뒤 어느덧 겨울이 되었다. Year Log는 연말 배포를 목표로 혼자 만들어 본 두 번째 서비스이다. 이번 프로젝트를 통해 결국 '무엇을 만들 것인가', '어떻게 운영하고 유지할 것인가'가 핵심이라는 것을 깨달았다. 누구나 빠르게 만들 수 있는 시대가 되었기에 오히려 초기 아이템 단계에서의 기획과 배포 후 운영이 더 중요하게 느껴진다. 그래서 이번 회고에서는 데이터 분석, 사용자 반응 관찰, 개선 방향 고민에 집중하게 되었다.

광고의 경우 해당 서비스가 무료로 운영되었기에 사용자 반응 확인 목적으로 소액만 집행했다. 적은 비용과 한 달 운영이라는 제약 속에서 광고 소재 A/B 테스트나 랜딩 페이지 최적화 같은 반복 실험은 진행하지 않았다. 이번 분석의 목적은 광고 효율 최적화가 아닌 "깊이 있는 회고 서비스가 통하는가?"라는 핵심 질문에 답하는 것이었기에 완료자들의 피드백과 행동 패턴 파악을 우선했다.

앞선 1편에서는 Year Log의 기획 배경과 48시간 개발 과정을 다뤘다. 연말 회고를 AI가 도와주는 서비스, 20개 주관식 질문으로 깊이 있는 경험을 제공하는 컨셉, 그리고 빠르게 MVP를 만들어낸 과정까지 다뤘다. 이번 편에서는 12월 8일 배포 후 한 달간의 실제 운영 데이터와 인사이트를 정리했다.

데이터 분석

전체 전환 퍼널

초기 오가닉 홍보 후 인스타그램 릴스 광고로 실제 사용자 반응을 확인했다. 모든 데이터는 GA4로 중복 집계를 피하고자 활성 사용자 수 기준으로 측정했다.

전체 웹사이트 유입 402명 → 완료 67명

전체 웹사이트 유입 402명
(광고 영향 189명 + 사용자 공유 174명 + 기타 39명)
   ↓
테스트 진입 149명 (37.1%) ← 랜딩 페이지 이탈 253명 (62.9%)
   ↓
테스트 완료 67명 (45.0%) ← 진입 후 이탈 82명 (55.0%)

먼저 전체 유입부터 테스트 완료까지의 전환 퍼널을 살펴봤다. 가장 큰 유입 채널은 paid 광고(47.0%)였고, direct가(43.3%)로 뒤를 이었다. 병목 지점은 랜딩 페이지 메인홈이었다.

2단계 장벽

1차 장벽: 랜딩 페이지

웹사이트에 유입된 402명 중 62.9%가 랜딩에서 나갔다. 추측되는 이탈 요인은 아래와 같다.

• 이름 입력 필수 (버튼이 비활성화, "일단 둘러보기" 불가능)
• 호기심만으로는 부족한 동기
• 가치 제안 부족 (뭘 얻을 수 있는지 불명확)

2차 장벽: 진입 후 이탈

테스트에 진입한 149명 중 55.0%가 완료하지 못했다. 아래의 허들이 작용한 결과로 보인다.

• 질문 미리보기 단계 (소요시간 10분, 질문의 무게감)
• 진행 중 타이핑 부담 (20개 주관식)
• 중간 이탈 (다른 방해 요소)

채널별 비교: 광고 vs Direct

채널별 유입 402명

• Paid (광고): 189명 (47.0%) *총 지출 ₩48,123
• Direct (사용자 공유): 174명 (43.3%)
• 기타 39명 (9.7%)

완료자 67명 분포

• Paid (광고): 39명 (58.2%)
• Direct (사용자 공유): 23명 (34.3%)
• 기타: 5명 (7.5%)

유입과 전환은 달랐다. 채널별 퍼널을 비교해보았다.

광고 (189명)

• 유입 → 시작: 82명 (43.4%)
• 시작 → 완료: 39명 (47.6%)
• 전체 전환율: 20.6% (189명 → 39명)

Direct (174명)

• 유입 → 시작: 52명 (29.9%)
• 시작 → 완료: 23명 (44.2%)
• 전체 전환율: 13.2% (174명 → 23명)

세그먼트는 25-34세 집중

초기 타겟 세팅은 "연말 회고에 관심 있을 연령대"라는 가정으로 범위를 넓게 잡았다. 25-39를 설정했고 실제 데이터 결과는 25-34세가 74.8%를 차지했다. 35-39세는 아주 적은 비율이었다.

25-34세는 커리어 전환기로 자기 성찰 니즈가 높고, 디지털 네이티브로 AI 기반 서비스에 대한 거부감이 덜했던 것으로 보인다.

다음 실험에서는 타겟을 25-34세로 좁히고 광고 메시징도 "커리어 고민", "20대 마지막/30대 초입" 같은 구체적 맥락을 담아 전환율을 높여볼 계획이다.

핵심 인사이트

유입 경로보다 회고 동기

광고로 유입된 사용자는 Direct 유입 사용자보다 약 13%p 높은 수치로 '테스트를 시작' 했다. 릴스 소재에서 서비스 맥락을 보고 유입된 페이드 유저의 시작율이 높았다. 반면 Direct 유입은 대부분 친구의 결과 또는 메인홈 링크를 받아 들어왔다. 이들에게는 랜딩 페이지에서의 메시지 전달이 약했던 듯하다. 메인홈에서는 이름 입력 필드와 "시작하기" 버튼만 보이고 행동 유도나 명확한 베네핏 제시가 없었으니 시작 동기가 부족했을 것이다.

이외에 광고 소재, 랜딩 페이지, 질문 미리보기 어디에서도 "주관식 타이핑"이라는 행동 비용을 명확히 알려주지 않았다. 테스트를 시작한 사용자 중 절반 이상은 막상 타이핑을 시작하는 순간 예상치 못한 부담을 느끼고 이탈했다.

흥미로운 결과도 있었다. 일단 테스트를 시작한 사람들의 완료율은 채널별로 보면 큰 차이가 거의 없었다. 광고 47.6%, Direct 44.2%로 유입 경로와 무관하게 시작 후 완료율은 약 3%p의 차이로 비슷했다. 어떻게 들어왔는지보다 얼마나 회고하고 싶은가, 즉 개인의 내적 동기가 완료 여부를 결정했던 것으로 보인다.

시작점이 전환율 차이의 핵심

이는 "유입 숫자"보다 "첫 접점에서의 동기 부여"가 중요함 보여준다. 랜딩 페이지가 첫 번째 병목이기 때문에 여기를 먼저 개선해야 다음 단계도 의미있다. 랜딩 페이지를 통과하지 못하면 아무리 질문 구성을 개선하고 중간 이탈을 줄여도 그 효과가 영향을 미칠 모수 자체가 적기 때문이다. 현재 62.9%가 랜딩에서 이탈하는 상황에서 랜딩 페이지 전환율을 10%p만 높여도 테스트 진입자가 40명 늘어난다. (현재: 402명 × 37.1% = 149명 → 개선 시: 402명 × 47.1% = 189명)

• 구체적인 베네핏 제시: "10분 투자하면 AI가 올해 패턴을 분석해 리포트로 정리해줍니다" 같은 명확한 혜택 제시
• 닉네임 입력 뒤로 보내기: 질문을 먼저 보여주고 관심이 생긴 후에 닉네임 입력 유도
• 샘플 결과 노출: 어떤 결과를 받을 수 있는지 미리 보여주기

극단적 만족도

한편 테스트를 완료한 사용자들의 반응은 예상 밖이었다. 완료자 중 31.3%가 하트(결과 페이지에 배치된 좋아요 버튼)를 눌렀고 하트를 한 번이라도 누른 사람은 평균 20.9회씩 눌렀다. 그 외에 "울었다", "감동했다", "한 해를 잘 돌아볼 수 있었다"는 후기를 전해오기도 했다.

20개 주관식이라는 장벽을 넘은 사용자들은 극단적으로 높은 만족도를 보였다. 사용자의 45%만이 완료했지만, 완료한 이들에게는 깊은 인상을 남겼다는 것을 확인했다.

제품 방향성

깊이와 밸런스

처음 기획 시 주관식 포맷을 고민하던 때였다. 평소 나와 다른 시각을 가져 종종 의견을 참고하는 지인이 이런 말을 해주었다.

"선택형에 재미 위주로 다 바꾸면 기존 심리테스트랑 차별점이 없잖아?"

그 말을 듣고 Year Log는 나를 돌아보는 수고로움을 회피하지 않고 정면으로 마주하는 서비스로 만들기로 했다. 20개 주관식, 긴 AI 분석, 개인적인 질문으로 가벼운 심리테스트와는 다른 방향으로. 의도적으로 "깊이"를 택했다. 만약 10개 객관식, 짧은 결과, 재미 위주로 구성했다면 더 많은 사람이 완료했을지 모르지만 '진짜 내 이야기'라는 인상을 주기는 어려웠을 테다.

하지만 사용자의 45%만이 완료했다는 건 개선이 필요하다는 신호이기도 했다. 테스트를 포기한 사람들은 크게 두 가지 반응으로 나뉘었다.

• "회고? 어렵고 관심 없어": 회고라는 단어 자체에 거부감 표시한 사람들.
• "타이핑이 귀찮다": 회고에 관심은 있는데 20개 주관식이 부담스러웠던 사람들.

"회고? 어렵고 관심 없어" 반응을 보인 이들은 이 서비스의 타겟이 아니었다는 생각이 든다. 이들은 자기성찰 니즈가 없고 지난일을 돌아보는 행위에 회의적이었다. 고민이 됐던 건 "타이핑이 귀찮다" 그룹이었다. 완료율을 높이기 위해 서비스의 어디까지 바꿔야 할지 우선 스펙트럼을 생각해봤다.

• 20개 주관식 (현재): 깊이 최대, 완료율 45%
• 15개 주관식 + 일부 객관식 (절충안): 타이핑 부담 감소, 깊이는 유지
• 전체 객관식 + 재미 위주 (극단): 완료율 상승, 하지만 본질 훼손

극단적인 방향(전체 객관식)으로 바꾸면 "울었다"는 피드백을 주었던 이들이 느낀 깊이 있는 경험을 끌어내기 어려울 것이다. Year Log의 제품 특성상 모두를 만족시키려다 핵심 타겟을 잃는 것보다 명확한 타겟에게 강렬한 경험을 주는 게 낫다고 생각했다. 다만 절충안은 다음 버전에서 적용할 가치가 있다. 질문 수를 20개에서 15개로 줄이고 일부를 객관식이나 단답식으로 바꿔도 주관식으로 직접 "쓴다"는 핵심은 유지할 수 있기 때문이다.

수익화와 시즌성 탈피

한 달간의 운영을 통해 "이런 서비스가 통하는가?"를 알아봤다. 다음 단계는 프리미엄 구독 모델로 전환하면서 12월에 집중된 시즌성 탈피하기.

연말 회고는 시즌 상품이다. 이번에는 타이밍을 맞추기 위해 빠르게 런칭했지만 연중 지속 가능한 모델이 필요하다. 연말 회고가 통했다면 정기적인 성찰을 원하는 사람들도 있지 않을까.

구독 모델 (안)

• 주간 회고: 매주 일요일 저녁, 주간 요약 질문
• 월간 회고: 매달 말일, 한 달을 돌아보는 질문
• 분기 회고: 4분기 끝, 시즌별 목표 점검 질문
• 연간 회고: 연말 1회, 기존 Year Log 개선 질문

테마 확장
연말 외에 다른 맥락의 회고 테마를 추가할 수 있다. 특히 25-34세 타겟은 자기 계발에 대한 투자 의향이 높고 "나만의 이야기"에 대한 니즈도 있다고 판단했다.

• 커리어 회고: "이직을 고민 중이신가요?" "올해 가장 성장한 순간은?" 등
• 관계 회고: "이번 달 함께 방문한 곳 중 가장 좋았던 곳" "다음 달엔 뭘 함께 하고 싶나요?" 등
• 여행 회고: "이번 여행에서 가장 기억에 남는 순간은?" "다시 오고 싶은 장소는?" 등
• 투자/재무 회고: "이번 분기 가장 잘한 재무 결정은?" "다음 분기 재무 목표는 무엇인가요?" 등
• 라이프스타일 회고: "건강, 취미, 일상에서 어떤 변화가 있었나요?" 등

핵심은 깊이 있는 성찰이라는 본질을 유지하면서 주기와 주제를 다양화하는 것이다. 질문 수를 줄여 부담을 낮추되 주관식 타이핑이라는 핵심은 유지한다.

마무리하며

측정하지 못한 것들

질문별 이탈률을 측정하지 못했다. 테스트에 진입한 149명 중 55.0%(82명)가 완료하지 못했는데 만약 질문별 이탈 데이터가 있었다면 어땠을까. 20개 질문 중 어떤 질문이 부담스러웠는지, 초반 질문이 문제인지 후반 피로도가 문제인지 정확히 파악할 수 있었을 것이다. "올해 가장 힘들었던 순간은?"과 "올해 가장 행복했던 순간은?" 중 어느 쪽이 완료율을 높이는지 A/B 테스트로 검증 가능했을 텐데. 다음 프로젝트에서는 기능 개발과 동시에 세부 지표 측정 인프라를 함께 구축해야겠다고 생각했다.

사용자들과 후속 소통할 방법이 없다. 후기 남기기 CTA를 넣어두긴 했으나 운영자가 직접 어프로치할 채널이 부재한다. 이메일 수집을 고려했으나 빠른 검증을 위해 MVP로 만들다 보니 명시적 마케팅 동의, 수신거부 시스템 등 신경 쓸 게 여럿이어서 빠른 배포를 우선했다. 앞서 언급한 구독 모델이나 새로운 테마로 서비스를 확장하더라도 기존 사용자들에게 알릴 방법이 없어 아쉽다. 연중 지속 가능한 모델로 확장 시에는 사용자와의 커뮤니케이션 채널을 필수로 챙길 예정이다.

바이럴 계수(사용자 1명당 데려온 신규 사용자 수)도 측정이 불가했다. referrer tracking 시스템(DB 스키마 설계, UTM 파라미터, 공유 링크별 추적)의 구현 복잡도가 높아 우선순위에서 제외했다. 추적할 수 있었다면 바이럴 메커니즘을 더 정확히 이해하고 사용자 공유를 최적화할 수 있었을 것이다. 다음 버전에서는 바이럴 지수 측정 방법을 잘 마련해보고 싶다.

운영하며 배운 것들

자동저장을 구현해 20개 주관식 질문을 답하다 중간에 나가도 다시 돌아오면 이어서 진행 가능하게 만들었다. 긴 폼에서는 진행 상태 보존이 필수라는 걸 다시 한번 느낀다. 무료 AI 서비스를 운영하면서는 리스크 관리에도 신경을 썼다. OpenAI API 월 한도 설정을 재점검하고 비정상 이용패턴 발생 시 메일, 슬랙 등의 채널로 알림이 오도록 설정해 문제 상황에 빠르게 대처하고자 했다. 혼자서 프로젝트를 운영할 때는 기능 구현뿐만 아니라 사용자 경험 보존, 비용 관리, 모니터링까지 모든 운영 요소를 직접 챙겨야 함을 다시금 체감했다.

마케팅 활동은 계획대로 이루어지지 않았다. META의 AI봇 감지 시스템이 계정을 오인해 제한했고, 필요한 조치를 취했으나 여전히 해결되지 않고 있다. 같은 문제로 수천 명이 모여 있는 오픈채팅방을 발견하면서 플랫폼 리스크의 심각성을 실감했다. 시스템이 오작동할 때의 불편함을 몸소 경험하며 오류나 잘못된 판단으로 사용자에게 피해를 주지 않도록 더욱 신중해야겠다고 다짐했다.

프로젝트의 의미

이 프로젝트는 처음부터 수익화를 목표로 한 게 아니었다. 아이디어가 실제로 통할지, 사람들이 20개 주관식 질문에 끝까지 답할지 알아보고 싶었다. 일단 무료로 배포했고 400개 이상의 하트 클릭과 "눈물이 났다"는 피드백을 받으며 깊이 있게 다가가는 방향도 '통한다'는 걸 확인했다. 이번 프로젝트의 목적은 달성한 셈이다.

하지만 프로젝트의 진짜 의미는 검증 지표를 넘어서 있었다. 무엇보다, 긴 주관식 질문에 진심으로 답해주시고 피드백을 남겨주신 분들이 있었기에 이 프로젝트가 의미있었다고 생각한다.

핵심 요약: Year Log는 20개 주관식 질문에 대한 답변을 AI가 분석해 개인화된 연말 회고 리포트를 생성해주는 무료 서비스다. 이번 글에는 이 서비스를 만들게 된 계기부터 구현 과정까지의 세세한 과정을 담았다.

이 글의 구성

• 1편: 기획 배경, 질문 설계, 기술 스택 선택, 프롬프트 최적화, UI/UX 디자인
• 2편: 전환 퍼널 데이터 분석, 사용자 반응, 제품 방향성, 운영 회고

연말 회고 서비스를 만든 이유

12월이면 데이터 기반 연말 결산 콘텐츠가 쏟아진다. 유튜브 리캡이나 애플 뮤직의 리플레이처럼 "올해 가장 많이 들은 노래" 같은 것들.

콘텐츠 마케터로 업무할 당시 서비스 전체 데이터를 활용하는 연말결산 콘텐츠를 기획했었고, 심리 테스트 포맷도 작업해봤다. 이 두 가지 경험과 최근 잘 활용하고 있는 AI를 더해 처음부터 끝까지 하나의 서비스를 혼자 만들어보기로 했다. 가을에 맨땅에 헤딩하며 혼자 앱을 출시해본 경험 덕분에 새로운 시도에 대한 허들이 사라진 것 같다!

내가 올해 만들어보고 싶었던 것은 숫자로 표현되는 회고랑은 조금 달랐다. 올해 뭘 배웠는지, 어떻게 달라졌는지, 데이터만으로는 다 담아내지 못하는 경험을 정리하고 싶었다. 질문을 던지고, 직접 답하게 하고, 그걸 AI가 분석해주는 연말결산. 5분 만에 끝나는 심리테스트가 아니라 좀 더 딥하게 한 해를 돌아보는 경험을 만들고 싶었다.

바이럴을 노린다면 선택형 옵션으로만 구성하고 결과도 심플한 게 좋겠지만, 나는 '회고'라는 특성에 집중하기로 했다. 주관식으로 직접 적게 하고 AI 분석 결과도 충분히 길게 보여주는 쪽으로. 이번에 만든 연말결산 회고 서비스 'Year Log'는 이렇게 출발했다.

48시간 개발: 빠른 MVP 출시 전략

방향성을 정하고 나니 빠르게 실행에 옮기는 게 중요했다. 연말결산은 시즌성이 짙은 서비스이다. 12월을 벗어나면 해야 할 이유가 사라진다. 그래서 우선순위를 바로 올리고 일정을 이틀로 픽스했다. 이틀 동안 기획부터 배포까지 모두 마쳤다. 혼자서 이 속도가 나온 건 AI 도구 덕분이다.

사업자 없이 무료 서비스 운영하기

유료로 할까 잠깐 생각은 해봤다. 2티어 모델도 고민해봤다.

무료 (20개 질문, 라이트 AI)  →  프리미엄 (50개 질문, 풀 AI, 1,900원)

하지만 역시 PG 연동에는 현실적인 벽이 있었다. 토스페이먼츠 등 국내 PG사는 사업자 등록이 필수다. 다른 한편 Stripe/PayPal 같은 해외 결제는 내 타깃인 사용자에게는 낯설다.(실제로 UI보여줬을 때 어려워함) 비용 이슈를 따져봤다. OpenAI 연동의 경우 사용량 대비 토큰 비용을 계산해보았을 때 크게 부담되지 않았다. 그래서 무료 모델로 빠르게 결정했다.

질문 설계: 50개에서 20개로, AI 분석에 최적화된 주관식 질문

Year Log의 핵심은 질문이다. 질문에 따라 결과가 달라진다.

처음엔 프리미엄 모델을 생각하며 50개 질문을 리스트업했었다. 하지만 무료 모델로 결정하면서 질문 수를 현실적으로 줄이기로 했다. 주변에 테스트 돌려봤을 때 30문항도 많다는 피드백이 있어서 20문항으로 줄였다.

50개 → 20개로 줄일 때의 기준

• 중복 제거: "올해 가장 큰 변화" vs "올해 나를 성장시킨 경험" → 하나로 통합
• 분석 가치: AI가 분석하기에 의미 있는 답변이 나올 질문만
• 뎁스 조절: 부정적이거나 무거운 질문은 최소화

최종 카테고리 구성

취향과 라이프 스타일 카테고리가 질문의 절반을 차지하도록 배치했다. 요즘은 "나는 누구인가"를 설명하는 방식이 바뀌었다. 이제 사람들은 "Taste"로 자신의 정체성을 드러낸다. 플레이리스트, 즐겨 찾는 카페, 좋아하는 브랜드. 이런 것들이 '나'를 설명한다.

반면 무겁거나 부정적인 질문은 최소화했다. "가장 힘들었던 순간" 정도만 넣고, 나머지는 가볍고 구체적인 질문으로 채웠다. 회고가 무겁기만 하면 끝까지 가기 힘들다.

몇 가지 특별한 질문도 넣었다. "올해 나를 가장 잘 아는 사람은 누구? 그 사람은 나를 뭐라고 표현할까?"처럼 타인의 시선으로 나를 객관화하게 만드는 질문. 그리고 "버리기를 미루고 있던 지금 당장 버려야 할 물건은?", "내년 1월에 바로 실행할 것 한 가지는?" 같은 질문으로 단순 회고에서 끝나지 않고 실제 행동으로 이어지게 했다. 회고를 하는 이유는 결국 나를 돌아보고 다음은 더 나아지기 위해서니까.

왜 주관식인가

대부분 주관식(텍스트 입력)으로 갔다.

객관식이 편하긴 하다. 클릭 몇 번이면 끝나니까. 근데 그러면 기존 심리테스트랑 다를 바가 없다. 회고는 본질적으로 불편한 행위이다. 지난 나를 되짚어보고, 외면했던 순간들을 다시 꺼내보고, 솔직하게 마주하는 과정은 쉽지 않다. 그래서 많은 사람들이 빈 페이지 앞에서 멈춘다.

주관식으로 직접 적게 한 건 바로 이 지점 때문이었다. 구체적인 질문으로 시작점을 마련해주되, 스스로 생각을 정리하며 문장을 완성하는 시간을 주고 싶었다. 빈 페이지는 부담스럽지만, "1년 전의 나라면 절대 안 했을 것을 올해 했다면?"이라는 질문은 한 걸음 내딛게 해준다. AI가 분석하기에도 주관식은 텍스트가 훨씬 풍부하다.

빈칸 채우기 형식도 몇 개 넣었다. "요즘 나는 ____가 제일 무섭다" 같은 형식. 문장을 완성하는 정도라서 진입장벽이 조금 낮다. 민감한 질문에는 구체적인 예시도 제공했다. "올해 숨겨둔 작은 비밀은?"이라는 질문에 "전 연인 SNS 몰래보기, 숨겨둔 비상금, 아픈 척 약속 취소" 같은 예시를 보여주면 가볍게 접근할 수 있다.

책, 여행, 취미, 향수처럼 모든 사람이 경험하지 않을 수 있는 질문 5개는 선택 항목으로 만들어 건너뛸 수 있게 했다.

기술 스택 선택: Next.js, Supabase, GPT-4o-mini를 고른 이유

Next.js + Tailwind CSS

프론트엔드는 Next.js로 갔다. LLM에 구현하려는 기능(짧은 공유 URL, OG 메타데이터 동적 생성 등)을 설명했더니 가장 적합한 스택으로 추천해줬다. Vercel 배포도 단순하다.

Next.js가 적합했던 이유: 동적 라우팅(/result/[id])으로 짧은 URL 구현이 쉽고, 서버 컴포넌트로 사용자별 OG 메타데이터를 동적 생성할 수 있다. API Routes로 프론트/백엔드를 한 프로젝트에서 처리할 수 있어 빠른 개발에 유리하다는 특성도 있다.

Tailwind는 디자인 시스템 없이도 빠르게 스타일링하기 좋다. 48시간짜리 프로젝트에서 컴포넌트를 직접 꾸미기에 적합했다.

GPT-4o-mini

AI는 GPT-4o-mini를 썼다. 다른 모델 대비 합리적으로 연말결산 분석에 필요한 성능을 충분히 커버한다. input/output 토큰 수와 예상 리퀘스트 수를 계산해보니 무료 운영이 가능한 비용 수준이었다.

Supabase

DB는 Supabase. 결과를 저장해야 /result/abc123 같은 짧은 URL을 줄 수 있는데 Supabase가 바로 쓸 수 있는 대안이었다. 무료 티어가 넉넉하고 셋업도 빠르다. 이제 수파베이스에 조금 익숙해진 상태이기도 해서 더 편했다.

결과 생성 → Supabase 저장 → short_code 발급 → 공유 URL 생성

Vercel

배포는 Vercel. Next.js 기반이라 호환성이 좋고 무료 티어 안에서 충분히 운영할 수 있다. 커스텀 도메인 연결도 간단하다.

GPT-4o-mini 프롬프트 최적화: 연말결산 분석 성능 높이기

JSON 구조 설계

AI에게 7개 섹션을 JSON으로 달라고했다. 구조화를 해서 해당 포맷으로 입출력하면 프론트엔드에서 렌더링할 때도 깔끔하다.

{
  "title": "~한 한 해",
  "summary": "2025년 총평",
  "emotion": "감정 분석",
  "growth": "성장 포인트",
  "taste": "취향/나다움 분석",
  "advice": "2026년 맞춤 조언",
  "keywords": ["키워드1", ..., "키워드10"]
}

정해진 형식으로 결과 페이지가 구성되어 나오기 때문에 일관성이 생겼다.

톤 지정

톤앤매너도 명시했다. 내가 그려둔 Year Log 컨셉에 맞춰 원하는 온도를 구체적으로 적어주었다.

- 따뜻하고 친근한 어조로 작성
- 판단하지 말고 공감하기
- 부정적인 답변에도 긍정적 관점 제시
- "~네요", "~했군요" 같은 부드러운 종결어미 사용

"당신은 이런 사람입니다"보다는 "이런 한 해를 보내셨군요"가 덜 위압적이다. 같은 말도 다르게 느껴진다. 사용자 답변을 존중하는 어조를 직접 명시했다.

AI 도구로 48시간 만에 디자인하기

한 해를 회고하며 사용자들은 주관식으로 직접 타이핑을 하고, 깊이 있는 질문도 마주한다. 쉽지 않은 여정이다. 그렇기에 디자인만큼은 최대한 따뜻하고 포근하게 만들어야 한다고 생각했다.

딱딱한 UI 대신 손으로 만든 것 같은 질감을 목표로 했다. 친구가 직접 바느질해서 건네주는 연말 카드 같은 느낌. 가볍지 않은 질문을 던지더라도 그걸 감싸는 분위기만큼은 따뜻해야 한다.

Midjourney로 에셋 제작

• 집: 메인 화면 이미지로 따뜻한 보금자리
• 편지지/우체통: 결과를 주고 받는 메세지함
• 하트: 만족도를 표현하는 좋아요 버튼
• 눈송이: 연말 눈 내리는 겨울날 분위기

프롬프트에 "felt texture", "embroidery style", "handmade" 같은 키워드를 넣어서 일관된 펠트 질감으로 뽑았다. react-snowfall로 눈 내리는 효과를 추가해 연말 분위기와 차별점을 만들었다.

사용자 플로우: 이름 입력부터 AI 결과까지 5단계

사용자가 어떤 순서로 이 여정을 밟게 될지 그려봤다.

1. 이름 입력

처음에 이름이나 닉네임부터 받는다. "{이름}님의 2025 연말결산"이라고 뜨면 심리적으로 내 이야기라는 느낌이 강해진다. OG 메타데이터에도 반영되니까 공유했을 때 존재감이 다르다.

2. 질문 미리보기

바로 질문으로 가지 않고 어떤 질문들이 있는지 예시를 먼저 보여준다.

"올해 가장 행복했던 순간은?"
"요즘 나는 ____가 제일 무섭다"
"올해 가장 잘한 소비는?"
"올해 숨겨둔 작은 비밀은?"
"2026년엔 어떤 사람이 되고 싶나?"

어떤 질문이 나올지 미리 보여주면 예상도 가능하고 마음의 준비도 할 수 있다.

3. 20개 질문

질문은 한 번에 하나씩, 차분하게 답변하는 구조다.

• 자동 저장: 답변할 때마다 localStorage에 저장
• 24시간 유효: 나갔다 와도 이어서 가능
• 중간에 나가도 OK

4. AI 분석 로딩

결과 생성에 5-10초 가량이 걸린다. 스피너만 보여주면 진행 상황을 알 수 없어서 메시지를 넣었다.

"당신의 2025년을 정리하고 있어요..."
"답변에서 패턴을 찾고 있어요..."
"올해의 이야기를 엮고 있어요..."
"거의 다 됐어요, 조금만요..."

초마다 바뀌면서 AI 결과 생성이 진행 중임을 보여준다. 대기 시간에도 이탈하지 않도록 하는 장치다.

5. 결과 확인

AI가 분석한 결과를 보여준다. 구체적인 페이지 구성은 아래와 같다.

AI 결과 페이지: GPT가 분석한 7개 섹션과 바이럴 CTA

AI 분석 섹션

AI는 7개 섹션으로 분석 결과를 제공한다. 과거(총평) → 현재(감정/성장) → 미래(조언) 순서로 자연스럽게 한 해를 정리하고 내년을 바라보게 만드는 구조다.

CTA 버튼

결과 페이지 하단에는 액션 버튼을 배치했다. 사용자가 AI 분석을 확인한 직후 어떤 행동을 하게 만들지에 집중했다.

• 이미지로 저장하기: 결과를 기록으로 남겨두게 했다.
• 결과 공유하기: 카카오톡 등 링크로 공유할 수 있게 했다.
• 하트 버튼: 마음에 들면 하트를 중복으로 누를 수 있게 했다. 만족도 표현과 더불어 "N개의 마음이 쌓였다"를 메인과 결과 페이지에 보여줘서 다른 사람들도 참여하고 반응했다는 걸 보여준다.
• 나도 해보기: 친구 결과 보고 온 사람한테 중요한 버튼. 바이럴 루프의 핵심이다.

공유 링크

바이럴의 핵심은 공유 링크다.

• 결과를 Supabase에 저장
• 6자리 짧은 코드 발급 (예: x7k2m9)
• /result/x7k2m9 형태의 깔끔한 URL

카톡에 링크를 보내면 "{이름}님의 2025 연말결산"이라고 뜬다. OG 메타데이터를 동적으로 생성했기 때문이다.

Buy me a coffee 섹션

최하단에는 "이 프로젝트가 마음에 닿았다면, 작은 응원은 계속 이어갈 수 있는 힘이 됩니다"라는 메시지와 함께 "응원하기" 버튼을 넣었다. 펠트 질감 컨셉과 문구가 자연스럽게 이어지도록 했다.

브랜딩: 도메인과 서비스 정체성

서비스 이름은 Year Log로 정했다. 한 땀 한 땀 바느질하듯 한 해를 기록한다는 의미를 담았다. 펠트/자수 디자인 컨셉과도 자연스럽게 이어진다.

도메인은 stitch-planet.com으로 했다. "한 땀 한 땀 삶의 순간을 기록하고 엮어간다"는 의미를 담고 있다. 향후 서비스 확장을 고려한 선택이기도 하다.

푸터에 개인정보처리방침을 넣고 Stitch Planet 로고를 박았다. 이런 기본 요소가 있어야 서비스가 진짜로 존재하는 것처럼 느껴진다.

다음 편에서는

2편에서는 운영 결과와 회고를 다룬다. 인스타그램 광고 결과, 전환율과 바이럴 지표 분석, 사용자 피드백, 그리고 한 달간 운영하며 배운 것들을 담았다.

요약

• SSL 인증서 만료 오류가 났는데 인증서 파일은 유효했음
• 원인: Certbot이 갱신은 했는데 Nginx가 재시작 안 돼서 메모리에 캐시된 이전 인증서를 계속 사용
• 해결: docker compose restart nginxproxy 실행 + 갱신 스크립트에 Nginx 재시작 명령 추가

어느 날 갑자기 블로그가 안 열렸다

평소처럼 블로그에 글을 쓰려고 접속했는데, 브라우저에서 경고 화면이 떴다. "연결이 비공개로 설정되어 있지 않습니다. NET::ERR_CERT_DATE_INVALID." SSL 인증서 만료 오류였다.

예전 같았으면 가슴이 철렁했을 것이다. 이번엔 그렇게까지 당황하지 않았다. 서버 운영하다 보면 이런 일도 있지. 일단 원인부터 찾아보자. 그런 마음이었다.

그런데 분명 Let's Encrypt 자동 갱신을 설정해뒀는데? certbot 컨테이너가 자동으로 인증서를 갱신하도록 cron 설정을 해놨었다. 그런데 왜 갑자기 이런 오류가 났을까?

내 블로그 구성: Docker Compose로 Nginx와 Certbot을 별도 컨테이너로 운영하고, certbot 갱신 스크립트를 cron으로 자동 실행하는 환경이다.

서버 상태 확인

SSH로 EC2 인스턴스에 접속했다. 일단 서버 자체가 살아있는지부터 확인해야겠다고 생각했다. AWS 콘솔에서 인스턴스 상태를 확인해보니 정상 실행 중이었다. 서버 문제는 아니었다.

터미널에서 sudo certbot certificates 명령어를 입력해봤다. 그런데 "command not found"가 떴다. 아, 맞다. certbot이 시스템에 직접 설치된 게 아니라 Docker 컨테이너로 돌아가고 있으니까 당연히 시스템 명령어로는 안 되지.

docker ps를 실행해서 컨테이너 상태를 확인해봤다. Ghost와 Nginx 프록시 모두 정상적으로 실행 중이었다. 컨테이너가 죽은 것도 아니었다.

인증서 만료일 확인

그래서 실제 인증서 파일의 만료일을 직접 확인해보기로 했다. openssl 명령어로 인증서 정보를 조회했다.

sudo openssl x509 -dates -noout -in certbot-etc/live/your-domain.com/fullchain.pem

결과가 나왔는데 예상과 달랐다.

notBefore=Nov 15 23:07:29 2025 GMT
notAfter=Feb 13 23:07:28 2026 GMT

인증서가 2026년 2월까지 유효하다고? 만료된 게 아니라 오히려 최근에 갱신까지 됐네. 하긴 크론탭 설정해놨으니 당연하다. 그러면 왜 브라우저에서 인증서 만료 오류가 나는 거지?

갱신 로그도 확인해봤다. renew_cert.log 파일을 열어보니 11월에 갱신이 성공했다는 기록이 있었다. 분명히 갱신은 제대로 된 것이다.

뭔가 이상했다. 인증서 파일은 새 것인데, 브라우저는 왜 만료됐다고 할까?

원인: Nginx가 새 인증서를 로드하지 않음

갱신 스크립트를 열어봤다. renew_cert.sh 파일 내용은 단순했다. Docker로 certbot을 실행해서 인증서를 갱신하는 스크립트였다.

그런데 뭔가 빠진 게 있었다. 스크립트는 인증서 갱신만 하고 끝났다. Nginx를 재시작하는 코드가 없었다.

잠깐, Nginx가 뭔지부터 정리하자.

Nginx는 웹 서버이자 리버스 프록시다. 쉽게 말하면 "문지기" 역할이다.

사용자 요청 → [Nginx] → Ghost 블로그
                ↓
           SSL 인증서 처리
           요청 분배
           정적 파일 서빙

HTTPS 처리(SSL 인증서로 암호화), 요청을 뒤에 있는 앱(Ghost)으로 전달, 여러 서버로 트래픽 분산, 정적 파일(이미지, CSS) 빠르게 서빙하는 일을 한다.

왜 Docker Compose에서 Nginx와 Ghost를 따로 띄울까? 이유가 있다. 이 부분은 피상적으로만 알고 있던지라 이번 기회에 좀 더 자세히 알아봤다.

첫째, 각자 잘하는 일만 하게 하는 거다. Ghost는 블로그 글 쓰고 보여주는 것만 집중하고, Nginx는 네트워크 처리, SSL, 트래픽 관리만 집중한다.

둘째, Ghost는 SSL 처리를 제대로 못 한다. Ghost 자체는 HTTP만 지원하기 때문에 HTTPS를 쓰려면 앞에 뭔가를 붙여야 한다. 그게 Nginx다.

인터넷 → [Nginx :443 HTTPS] → [Ghost :2368 HTTP]
                ↓
           암호화 벗기고
           Ghost한테 전달

셋째, 하나의 컨테이너에서 통으로 관리하지 않는다. Docker의 철학이 "1 컨테이너 = 1 프로세스"이기 때문이다. 분리하면 Ghost 업데이트할 때 Nginx 안 건드려도 되고, 반대로 Nginx 설정 바꿀 때 Ghost 안 건드려도 된다. 문제 생기면 뭐가 문제인지 찾기도 쉽다. 그간 블로그 운영 시 여러 오류를 마주했는데 체감상 이게 찐장점 같다.

한편 이번 케이스는 각 컨테이너가 따로 있어서 생긴 이슈이기도 했다. Nginx는 시작할 때 인증서를 메모리에 로드한다. 그 이후로는 파일 시스템에서 인증서를 다시 읽지 않는다. 즉, 인증서 파일이 새로 갱신되어도 Nginx가 재시작되지 않으면 메모리에 캐시된 이전 인증서를 계속 사용하는 것이다.

타임라인을 정리해보면 이랬다.

11월에 인증서가 성공적으로 갱신됐다. 새 인증서는 2026년 2월까지 유효하다. 하지만 Nginx는 재시작되지 않았기 때문에 여전히 이전 인증서(12월에 만료되는)를 메모리에서 사용하고 있었다. 그리고 12월 13일, 이전 인증서가 만료되며 사이트 접속이 불가해졌다.

원인을 알게되니 해결은 쉬웠다. 근데.. 처음에 이걸 왜 빠뜨리게 되었을까?

처음 이 스크립트를 만들 때 certbot 튜토리얼을 따라했고 이후 인증서 갱신이 성공했다고 뜨니까 다 된 줄 알았다. 당시에 Nginx가 뭐하는 역할인지 문서를 보긴 했는데, 솔직히 깊게 제대로 이해를 못 했던 것 같다. 처음 공부시작했던 때여서 읽어도 잘 안 와닿았달까..? Nginx가 인증서를 메모리에 캐시하고 있다는 건 당연히 생각도 못 했다. 그래서 Nginx 재시작 명령어가 빠진 채로 몇 달을 돌렸던 거다.

해결: Nginx 재시작

원인을 알고 나니 해결책은 단순했다. Nginx만 재시작하면 된다.

cd /path/to/project
docker compose restart nginxproxy

시크릿 모드로 브라우저를 열고 블로그에 접속해봤다. 깔끔하게 열렸다. 문제 해결.

하지만 여기서 끝이 아니다. 재발을 방지하려면 갱신 스크립트에 Nginx 재시작 명령을 추가해야 했다.

기존 스크립트 밑에 아래 내용을 넣어주었다.

# 인증서 갱신 후 Nginx 재시작
cd /home/ubuntu/my_folder
docker compose restart nginxproxy

이제 cron이 갱신 스크립트를 실행하면 인증서 갱신 후 자동으로 Nginx도 재시작된다.

마무리하며

기술적으로 배운 것도 있지만 이번에 더 크게 느낀 건 '나 자신의 변화'였다.

문제를 해결하고 나니 처음 블로그 만들었을 때가 떠올랐다. 불과 몇 개월 전만 해도 AWS 계정조차 없었는데 직접 만들어보고 운영하니 작고 다양한 이슈를 경험하게 된다. 처음 블로그가 다운되었을 땐 화들짝 놀라서 일단 뭐라도 해보려고 이것저것 만지작거렸다. 로그? 그런 거 볼 겨를이 없었다. 지금 생각해보면 딱히 방문자가 많은 것도 아니었는데 "일단 고쳐야 해"라는 조급함이 앞섰다.

이번에는 달랐다. 블로그에 접속이 안 된다는 걸 발견했을 때, 놀라기는 했지만 예전 같은 당황스러움이 없었다. 그냥 "아, 뭔가 터졌네. 빨리 봐야겠다" 싶었다. 고작 개인 블로그 하나 운영해본 것뿐이지만, 이런 경험들이 쌓이면서 서버 운영이라는 게 어떤 건지 조금씩 배우게 된다.

더 중요한 건 대응 방식이 바뀌었다는 점이다. 예전 같았으면 바로 docker ps 찍어보고 뭔가 이상해 보이면 docker compose down으로 다 내린 다음 docker compose up -d --build로 다시 올리고. 어떤 날은 다른 이슈로 AWS 콘솔에서 재부팅 버튼으로 급하게 해결했었다. 하지만 이번에는 차분하게 로그부터 뜯어봤다. 서버 상태 확인하고, 컨테이너 상태 확인하고, 인증서 파일 확인하고, 갱신 로그 확인하고. 하나씩 문제의 범위를 좁혀가고 상황을 파악하려 했다.

그랬더니 진짜 원인이 보였다. 인증서는 갱신됐는데 Nginx가 새 인증서를 안 읽고 있었구나. 이걸 알았으니까 재발 방지도 할 수 있었다. 갱신 스크립트에 certbot 작업과 함께 Nginx 재시작 명령어를 추가하는 것. 예전처럼 무작위로 고쳤으면 "일단 돌아가니까 됐다" 하고 끝났을 거다. 그리고 3개월 뒤에 또 같은 일을 겪었겠지.

로그를 읽는다는 건 결국 문제를 이해하겠다는 태도인 것 같다. 이해 없이 해결만 하면 같은 문제가 반복된다. 반대로 원인을 제대로 파악하면 그 문제는 두 번 다시 안 생긴다. 귀찮아도 로그부터 보는 습관, 이게 진짜 중요한듯하다.

추가 스터디

이번 오류를 계기로 내가 쓰고 있는 구성, 다른 선택지들은 뭐가 있는지 더 스터디해봤다.

SSL 인증서 관리 방법 비교

왜 EC2를 쓰는가, Vercel 쓰면 안 돼?

요즘 프론트엔드 개발하면 Vercel을 많이 쓴다. 코드 푸시하면 알아서 빌드하고 배포해주고, SSL 인증서도 자동으로 관리해준다. 편하다. 나도 이번 하반기 동안 배포한 앱이랑 웹서비스를 vercel로 연결했다.

근데 Ghost 블로그는 Vercel에서 안 돌아간다. 이유는 둘의 구조가 다르기 때문이다.

Vercel (서버리스)
요청 올 때 → 함수 실행 → 응답 → 함수 종료
(계속 켜져 있는 서버가 없음)

EC2 (서버)
서버 항상 실행 중 → 요청 오면 처리 → 계속 대기
(24시간 돌아가는 컴퓨터)

Ghost가 필요한 것

• 항상 켜져 있는 Node.js 서버
• 데이터베이스 (MySQL 또는 SQLite)
• 파일 시스템 (이미지 업로드 저장)
• 메모리에 상태 유지

Vercel이 제공하는 것

• 서버리스 함수 (요청당 제한된 시간만 실행)
• 정적 파일 호스팅
• Edge Functions

Ghost는 "계속 실행되는 서버"가 필요한데 Vercel은 서버리스로 "요청 올 때만 잠깐 실행"하는 구조다.

이걸 처음엔 몰랐다. Vercel이 "서버리스"라는 건 알았는데 그게 구체적으로 뭘 의미하는지, 다른 것과 어떤 차이가 있는지는 이번에 더 공부해보고 나서야 이해됐다. 서버리스는 "서버가 없다"가 아니라 "서버 관리를 안 해도 된다"는 뜻이고 대신 제약이 있다. Ghost 같은 전통적인 서버 애플리케이션은 그 제약 안에서 돌아가지 않는다.

Ghost를 호스팅하려면

이외에 중간 정도를 원하면 Railway나 Render 같은 컨테이너 PaaS, EC2랑 비슷한데 UI가 더 친절하다는 DigitalOcean Droplet도 있다고 함. AWS가 어렵게 느껴지면 이쪽이 나을 수도 있겠다. 월 $4부터 시작.

결국 Ghost를 쓰려면 "서버"가 필요하고 서버를 쓰면 SSL 인증서도 관리해야 한다. 덕분에 다양한 케이스도 경험할 수 있었다.

SSL 인증서 관리하는 방법 3가지

하나씩 알아보자.

1. 내가 쓰는 방식: Certbot + cron

사용자 → EC2 (Nginx + Certbot) → Ghost

Nginx + Certbot + cron 조합. 개인 프로젝트나 사이드 프로젝트에서 많이 보이는 구성이다.

Nginx는 Netflix, Airbnb 같은 기업도 쓸 정도로 검증된 기술이다. 근데 Certbot을 이런 기업들에서 사용하지 않는다. Certbot(Let's Encrypt)은 무료지만 직접 갱신을 관리해야 하고 보증이 없어서 기업에서 쓰기엔 귀찮고 리스크도 있다.

기업 구조
사용자 → CDN/ELB (여기서 SSL 처리) → Nginx → 앱 서버들
         ↑ 유료 인증서 or ACM 사용

개인 블로그 구조
사용자 → Nginx (여기서 SSL 처리) → Ghost
         ↑ Certbot으로 무료 인증서

기업은 서버가 수백~수천 대라서 앞단에 로드밸런서나 CDN을 두고 거기서 SSL을 처리한다. 인증서도 보증이 있는 인증서를 쓴다. Certbot으로 서버마다 일일이 갱신하는 건 현실적으로 불가능하다.

CDN(Content Delivery Network): 전 세계 여러 곳에 서버를 두고 콘텐츠를 복사해두는 시스템이다.

개인 블로그는 서버 1대니까 Nginx에서 직접 SSL 처리해도 된다. 이게 내 개인 블로그에 Certbot을 설정해둔 이유이다.

Certbot 말고 다른 도구는?

찾아보니까 Let's Encrypt 인증서 발급하는 도구가 Certbot만 있는 게 아니었다.

Certbot이 Let's Encrypt 공식 추천이고 2015년에 제일 먼저 나왔다. 그래서 튜토리얼이 제일 많고 문제 생기면 검색하면 답이 나온다. 근데 Traefik이나 Caddy 쓰면 이번 같은 삽질을 안 해도 된다고 한다. 인증서 발급/갱신/적용을 알아서 해줘서 "재시작 안 해서 적용 안 됨" 같은 문제가 애초에 안 생긴다. 둘 다 오픈소스라 무료고. 나중에 갈아타야하나 고민 된다.

2. AWS ACM은 왜 안 되나?

내 Ghost 블로그는 AWS EC2에서 돌아간다. AWS에는 ACM이라는 게 있는데 SSL 인증서를 웹에서 클릭 몇 번으로 발급받을 수 있다. 무료고 자동 갱신도 된다. 좋아 보여서 찾아봤는데 이건 ELB나 CloudFront에서만 쓸 수 있었다.

ACM(AWS Certificate Manager): AWS에서 SSL 인증서를 발급해주는 서비스다.
ELB(Elastic Load Balancer): AWS에서 제공하는 로드 밸런서 서비스다. 트래픽을 여러 서버에 분산시켜주는 역할.

ELB는 월마다 비용도 나가고 나처럼 개인 블로그 세팅 시에는 서버가 여러 대 있는 것도 아니니 불필요. CloudFront는 CDN인데 없어도 된다.

내 구조
사용자 → EC2 (Nginx) → Ghost  ← ACM 못 씀

ACM 쓰려면
사용자 → ELB → EC2 → Ghost  ← ACM 쓸 수 있음

ACM은 인증서 파일을 안 준다. AWS가 내부적으로 보관하고 ELB/CloudFront에 알아서 연결해주는 방식이라 파일 다운로드가 안 된다.

근데 Nginx는 인증서 파일 경로를 직접 설정해줘야 한다.

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

ACM은 이 파일을 안 주니까 Nginx에서 못 쓴다. 그래서 EC2 + Nginx 조합에서는 Certbot 쓰는 거다.

3. Cloudflare는?

원래: 사용자 → 내 서버
Cloudflare: 사용자 → Cloudflare → 내 서버

DNS를 Cloudflare로 연결하면 SSL 자동 발급/갱신, DDoS 방어, CDN까지 해준다. 무료 플랜도 있다. 기업에서 좋아하는 이유는 "설정 한 번 하면 신경 안 써도 되기 때문"이다.

단 Cloudflare는 SSL 문제가 생기면 대시보드에서 로그 보거나 서포트 문의해야 한다. 위 글에서 내가 직접 로그를 확인했듯 서버에 들어가서 인증서 파일을 열어보는 건 어렵다.

Certbot/Nginx 직접 관리랑 비교하면

• Cloudflare 엣지 서버에 SSH 접속 불가
• 인증서 파일 직접 열어보기 불가
• 내부 처리 과정 직접 확인 불가
• Cloudflare ↔ 내 서버 사이 문제 생기면 원인 파악이 애매할 때 있음

왜 Certbot을 선택했나

처음에는 "Ghost 블로그 만들기" 강의 튜토리얼을 따라해 만든 거였다. 돌이켜보면 나쁜 선택이 아니었다.

Cloudflare 쓰면 편하긴 한데 서버에 직접 들어가서 로그 보거나 인증서 파일 확인하는 식의 디버깅은 안 된다. 대시보드에서 제공하는 정보에 의존해야 해서, 이번처럼 "인증서 파일은 갱신됐는데 왜 적용이 안 되지?" 같은 문제는 직접 파악하기 어렵다.

Certbot + cron으로 직접 하면 SSL, Nginx, Docker에 대해 알게 된다. 이번처럼 터져도 직접 디버깅 가능하고 이 경험이 블로그 글의 주제가 되었다.

SSL 트러블슈팅 명령어

나중에 비슷한 상황이 생겼을 때 쓸 수 있도록 명령어들을 정리해둔다.

인증서 만료일 확인

sudo openssl x509 -dates -noout -in certbot-etc/live/{your-domain}/fullchain.pem

갱신 로그 확인

tail -20 renew_cert.log

인증서 수동 갱신

docker compose run --rm certbot renew

Nginx 재시작

docker compose restart nginxproxy

참고로 docker compose up -d --build와 헷갈릴 수 있는데, restart는 컨테이너만 재시작하는 거고 up --build는 이미지까지 새로 빌드하는 거다. 비유하자면 restart는 재부팅, up --build는 재설치. 난 주로 --build까지 쓰는 편이다. 작은 개인 블로그라 무거운 서비스도 아니고 이왕 하는 김에 클린하게 하려고. 하지만 SSL 인증서 문제는 Nginx가 메모리에 캐시된 인증서를 다시 읽기만 하면 되니까 restart로 충분하다.

앱을 Flutter로 만들었는데 iOS만 출시하기 아쉬워서 Android 출시를 알아봤다. Mac으로도 안드로이드 스튜디오 설치, 에뮬레이터 테스트 모두 가능했기에 11월부터 딱 안드로이드 중고 기기(실기기 테스트 목적)만 구해서 바로 진행했다. 기존에 App Store 출시 때 잡아두었던 보안·심사 체크리스트 덕분에 11월 안드로이드 심사 제출은 보다 빠르게 할 수 있었다.

다만 구글에는 개인 개발자에게는 가혹한(?) 출시 전 요구사항이 있었다. 2023년 11월 이후 만들어진 Google Play 신규 개발자 계정의 경우 "14일간 12명 이상"의 비공개 테스트가 필수였다.

14일? 12명? 혼자 개발인데 난관이다. 1인 개발자에게는 테스터 모집도 일이었고, 2주라는 기간 동안의 테스터 관리는 어려운 일이었다. 구글에 연관 검색어에도 "안드로이드 비공개 테스트 12명", "안드로이드 비공개 테스트 품앗이"가 최상단에 있고 "테스트 품앗이 먹튀" 등의 고통받은(?) 후기도 검색결과에 나오고 있다. 나는 약간의 비용을 써서 리소스와 스트레스를 줄이는 방향으로 '안드로이드 비공개 테스트 솔루션 도플리(Doply)'를 선택했다. 이번 글에는 이 서비스를 이용하여 안드로이드 출시 전 요구사항을 채운 과정, 검증 루틴, 실제 서비스가 어떻게 작동했는지를 남겨둔다.

Play Console 테스트 트랙 및 요구사항

내부 테스트 (Internal Testing) *선택(안해도됨)
- 앱 설정 완료 전, 신속하게 배포하여 초기 문제 파악 및 의견 수렴

비공개 테스트 (Closed Testing) *필수
- 출시 전 문제 해결 및 Google Play 정책 준수 확인
- 앱 설정을 완료한 후 시작, 프로덕션 신청을 위해 필수
- 12명 이상의 테스터, 최근 14일 동안 지속적인 테스트 참여

공개 테스트 (Open Testing) *선택(안해도됨)
- 앱의 테스트 버전을 Google Play에 공개해, 누구나 참여 가능
- 프로덕션 액세스 권한이 있으면 사용

프로덕션 (Production) *필수
- Google Play에서 사용자가 앱 다운로드 가능
- 비공개 테스트 선행 및 완료 이후 진행
- 신청 시 비공개 테스트에 관한 설문 항목들에 답변 필요

Phase 1 — 안드로이드 비공개 테스트 요구사항

Google Play Console 비공개 테스트의 "14일 연속"과 "12명 이상 모집" 조건은 단순히 테스터를 초대만해서 충족되는 것이 아니다. 위의 스크린샷에도 표시해두었지만 해당 기간 동안 "앱 테스트를 일관되게 실행"해야 해서 더 어려운 일이었다.

구글 플레이 비공개 테스트 요구사항

• 최소 14일간 비공개 테스트 진행
• 12명 이상의 테스터 참여
• 테스터가 실제로 앱을 설치하고 사용해야 함
• 매일 앱이 실행되어야 함

현실적 어려움

• 주변에 12명의 안드로이드 사용자를 구할 수 있을까?
• 14일 동안 계속 앱을 실행해달라고 부탁할 수 있을까?

아이고. 정책 의도는 이해하지만 1인 앱 출시의 경우 허들이 높다. 다른 방법을 찾아야했고, 도플리(Doply)가 효율적인 대안이 되어주었다.

이럴 땐, 도플리(Doply) 추천
- 혼자 안드로이드 앱을 개발해 테스터 12명을 구하기 어려운 경우
- 지인에게 14일 동안 매일 실행해달라고 부탁하기 난감한 경우
- 테스트 관리보다 기능·콘텐츠 개발에 시간을 쓰고 싶은 경우
- 빠르게 프로덕션 빌드를 올려야 하는 경우

이럴 땐, 직접 테스터 모집 추천
- 협조 가능한 팀이나 안드로이드 사용자가 12명 이상 있는 경우
- 2주간 지속 커뮤니케이션할 여유가 있는 경우
- 비용이 부담스럽고 시간을 투자할 수 있는 경우

Phase 2 — 한 줄기 빛이 되어준 '도플리(Doply)'

서비스 이용 신청 전에 도플리가 지금 내 상황에 구체적으로 어떤 도움이 될지 알아봤다.

도플리를 선택한 이유

• 100% 자동화 서비스
• 테스터 관리 불필요
• 12개 이상의 원격 실기기에서 자동으로 앱 실행·업데이트
• 대시보드로 실시간 진행 상황 확인
• 20일 테스트 기간 (Google에서 요구하는 14일보다 여유)
• 가격: 앱당 19,000원
• 조건 충족 시, 서비스 연장 제공

"2만원도 안되는 비용으로 리소스 아끼고 스트레스도 없는데, 안 할 이유가 없잖아..?" 라는 결론이 나서 바로 신청했다.

Phase 3 — 도플리(Doply) 서비스 신청, 테스트 준비

도플리(Doply) 가입을 한 뒤 가이드에 따라 프로세스를 진행했다. 안내 사항은 온보딩 페이지에 다 적혀있다. 그냥 보고 따라하면 된다.

1. 구글 플레이 콘솔에서 비공개 트랙 활성화, 앱 출시 최소 지원 버전 설정 등을 도플리 안내에 따라 세팅
2. 도플리(Doply)에서 제공하는 테스터 목록 CSV 파일을 Google Play Console > 비공개 테스트 > 테스터에 추가
3. 콘솔에서 발급되는 "테스터 참여 링크"를 도플리(Doply)에 등록

이 과정을 거치면 대시보드에서 테스터 디바이스 수, OS 버전, 설치 상태가 실시간으로 업데이트된다. 여기까지 너무 쉬워서 해놓고도 "뭐야, 다 된건가..?"하는 생각이 들 정도였다.

Phase 4 — 14일 자동화 테스트

안드로이드 비공개 테스트 시작

도플리(Doply)에서 "테스트 시작"되면 실제 활동 로그와 촬영된 스크린샷까지 대시보드 한곳에서 확인 가능하다. 직접 해야 했다면 상상만으로도 피로한데, 덕분에 비공개 테스트 과정을 쉽게 진행했다. 실제 서비스 환경은 데모 체험 페이지에서 미리 확인할 수 있다.

도플리(Doply) 자동화 테스트 방식

- 자동 앱 실행 매일 실제 테스터 기기에서 앱이 자동 실행된다.
- 업데이트 확인 이용자가 새 빌드를 올리면 자동으로 확인해 테스트한다.
- 변동 사항 파악 매일 설치 여부·버전을 체크하고 문제가 생기면 자동 감지한다.

만약 진행 중 문의사항이 생기면 카카오톡, 이메일, 왓츠앱 등으로 물어보면 된다. 답변 매우 빠르고 명쾌해서 더 믿음이 갔다.

안드로이드 비공개 테스트 중간 점검

진행 상황

• 테스트 기간: 4/20일(최소 14일)
• 일일 활성 테스트 기기: 18개 (최소 12개 기준 150%)
• 앱 충돌: 0건

대시보드에서 모든 지표가 안정적으로 유지되고 있음을 확인했다. 원래 12명이 최소 기준 인원인데 넉넉하게 18개의 기기에서 테스트가 진행되었다. "정말 자동으로 잘 돌아가는구나" 체감한 순간이다.

도플리(Doply)에서는 '비공개 테스트 기간 내 3-4일 간격으로 앱을 2회 이상 신규 버전 출시'하면 무료로 테스팅 기간을 20일 연장해준다. 이는 승인 거절 리스크를 줄이기 위함으로, '운영 노하우'가 '서비스 제공'의 형태로 녹아있었다. 앱 2회 업데이트는 어려운 일이 아니기에 무료 연장 서비스가 오히려 안전망처럼 느껴져 좋았다.

나는 리젝이 무서워서 비공개 테스트 기간 동안 (착실하게ㅎㅎ) 총 3회 업데이트했다. 버전 번호는 원래대로라면 안드로이드에서의 첫 출시니까 1.0.0이 되어야 하지만 iOS랑 맞추느라 1.0.4로 적어서 올렸다. 구글 플레이 콘솔에서의 신규 버전 출시 여부도 도플리에서 자동으로 감지하기 때문에 번들만 새로 올렸다.

참고로 비공개 테스트 기간 동안 코드 수정 없이 빌드 번호만 올려 앱 번들을 업로드했는데, 이렇게 해도 출시는 무리 없이 잘 됐다.

Phase 5 — 프로덕션 액세스 획득

마침내 조건 충족

2025년 11월 19일, 드디어 도플리 대시보드에 표시된 "프로덕션 신청일"이 되었다. 이제 도플리에서 프로덕션 신청할 때 유용한 설문 예시를 활용할 차례. 무료로 제공되는 답변인데 유용하게 사용했다. 숫자랑 일부 워딩만 한두개 바꿔서 그대로 냈고 프로덕션 승인까지 무난하게 통과했다.

최종 결과

• 비공개 테스트 기간: 11/4-18
• 안드로이드 정식 출시일: 11/20
• 소요 기간: 총 16일 (비공개 테스트 14일, 프로덕션 승인 2일)

비공개 테스트 신청부터 프로덕션 승인 후 출시까지 거의 2주만에 완료했다. 만약 혼자 하다가 한 번이라도 실패했다면 14일 테스트를 다시 반복해야 하니 출시 일정이 순식간에 한 달 가까이 밀릴 뻔했다. 커뮤니티 같은 곳을 보면 지인 테스트에 의존하다가 요건을 채우지 못해 시간만 날리고 결국 도플리 같은 솔루션을 찾는 사례도 종종 보인다. 처음부터 자동화를 선택해 한 번에 통과하는 길을 추천하고 싶다. 시간·돈·스트레스 비용까지 아끼게 될 것이다.

실제 투입 시간

1. 도플리 신청 및 콘솔 테스터 등록, 5-10분
2. 앱 번들 세 번 업데이트, 5분

실제로 비공개 테스트를 위해 직접 투자한 시간은 15분 남짓이었다. 도플리를 이용해 불필요한 반복 업무를 통째로 덜어낼 수 있었다. 커피 몇 잔 값, 치킨 한 마리보다도 저렴한 19,000원으로 출시 일정과 마음의 평화를 동시에 산 셈이다.

마무리하며

앱을 한 번 만들어본 뒤부터 새로운 서비스를 접하게 되면 '어떤 문제를, 어떻게 해결'하는지 들여다보게 된다. 도플리는 명확한 문제점을 날카롭게 파고들어 자동화로 풀어낸 인상적인 솔루션이었다. 공부할 겸 살짝 분석을 해봤다.

• 문제: Google Play 출시를 준비하는 1인·소규모 팀이 겪는 '14일·12명' 비공개 테스트 요구사항 충족의 어려움. 안드로이드 테스터 섭외, 지속적인 관리, 결과 증빙 등 개발 외 리소스 소모가 크고 실패 리스크가 높은 상황이다.
• 솔루션: '테스터 모집'부터 '프로덕션 설문 작성 가이드'까지, 비공개 테스트 전 과정을 End-to-End로 해결하는 서비스. 개발자는 단 몇 번의 클릭으로 가장 번거로운 출시 허들을 넘을 수 있다.
• 주요 특징
  • 자동화: 사람의 개입 없이 앱 등록부터 설치, 실행, 업데이트까지 자동으로 수행된다.
  • 신뢰성: 에뮬레이터가 아닌 실제 안드로이드 기기를 사용하여 테스트 신뢰도를 높였다.
  • 투명성: 대시보드를 통해 테스트 진행 현황을 실시간으로 확인하고 설치이력과 로그, 스크린샷도 제공된다.
  • 올인원 패키지: 단순 테스터 제공을 넘어, 프로덕션 설문 템플릿 제공, 조건부 무료 기간 연장 등 사후 관리까지. 실패 리스크를 줄여주는 역할을 한다.

내가 만약 시장 가격을 모른다고 가정했을 때, 이 서비스 이용료를 최대 얼마까지 지불할지도 생각해봤다.

일단 도플리(Doply)는 ROI가 압도적이다. 10시간 가량 소요될 수 있는 수작업을 단 15분의 설정으로 대체하고 19,000원으로 '출시 지연 +14일'이라는 리스크를 제거했다. 개인적으로 이 서비스의 가치를 고려했을 때 10만원도 기꺼이 지불할 의사가 있을 만큼 가성비도, 가심비도 뛰어났다.

이번 경험을 계기로 '문제를 정확히 좁히고 자동화로 풀어내는 서비스'가 사용자에게 얼마나 큰 편의성과 만족감을 주는지 다시 체감했다. 앞으로 이런 제품을 만날 때마다 공부해본 내용을 담아 시리즈를 연재해봐야겠다.

이번 글에는 비개발자로서 약 한달간 1인 개발로 감정 기반 레시피 앱을 만들고 출시하기까지의 여정을 한 편에 모았다. 각 에피소드의 교훈과 실제로 부딪힌 문제, 숫자로 남긴 결과를 중심으로 정리했다. 매일 쌓인 작업 로그와 시행착오 기록이 문제 해결 과정과 변화의 흐름을 따라가는 데 도움이 됐다.

• iOS: App Store
• Android: Play Store

1. 프로젝트 한눈에 ㅡ 숫자로 보는 여정

• 기간: 40일 중 실작업 32일(약 192시간)
• 콘텐츠 자산: 견습생 토끼가 요리사로 거듭나며 열리는 32단계 토끼굴 (+16개 특별 공간), 다양한 테마의 51개 요리 챌린지
• 주요 기능: URL 추출·사진 분석 등 5가지 레시피 입력 방식, 홈|토끼굴|통계|보관함|설정 5개 바텀탭
• 스택: Flutter, Hive(로컬 우선), Supabase Realtime(공지/메시지), OpenAI API(요약/분석), Vercel 프록시(API 키 보호)
• 배포:
  • ios — 심사 2일 승인, 10/9 출시, Apple Developer $99
  • android — 심사 2일 승인, 11/20 출시, Play Console Developer $25, 비공개 테스트 솔루션 '도플리(Doply)' 19,000원
• 회고: Prolog, Episode.1-9, 번외편까지 총 12편 퍼블리시(이 글의 최하단에 앱 출시 회고 시리즈 맵 URL 정리)

2. 시작과 설계 — 왜, 무엇을, 어떻게

• 동기: 콘텐츠·마케팅 출신으로 "아이디어를 직접 끝까지 구현"해보기 위해 도전. 레시피를 AI로 쉽고 편하게 쓰고 요리하는 마음을 함께 기록하는 것이 핵심 가치
• 경험 설계: 레시피 축적에 따라 요리 실력이 성장하며 토끼굴이 깊어지는 32단계 마일스톤, 16개 특별 공간과 51개 챌린지로 동기 부여
• 디자인: 앱의 컨셉 키워드 추출, ASCII 목업, 빈티지 팔레트로 일관성 확보, 빈티지 아이콘, 스플래시, 토끼굴 이미지 제작

3. 개발부터 출시까지의 과정

개발 과정 — 1인 개발자의 학습과 문제 해결

• 일정: 설계→구현→회고 루틴을 반복하며 MVP를 완성했다.
• 스택 선택: Flutter로 iOS/Android를 동시에 대비하고, 로컬 우선 구조가 필요해 Hive를 채택했다. AI 요약·분석 기능은 OpenAI API를 연동했다.
• 학습 방식: 바이브 코딩 강의, Claude와 Codex, 서브 레딧, 구글링으로 찾은 기술 블로그 사례, 개발자 지인의 조언까지. 막히는 순간마다 이렇게 다양하게 배우고 탐색하며 해결책을 찾았다.
• 기술적 난관: 강제 종료 후 데이터 사라짐 이슈, API 키 노출, 로컬 앱 특성상 커뮤니케이션 채널 부재 등의 어려움이 있었다.
• 해결 방안: Hive 데이터 저장 로직 및 타입 재설계, 프록시 토큰 관리와 키 교체, 메시지함 Supabase 연동, 점검 체크리스트 마련 등으로 해결했다.
• QA: 릴리즈 빌드에서 빌드 속도와 전체 용량을 기록하고, 실기기로 노치·홈 인디케이터·AI 레시피 작성·앨범 권한 등 심사 허들이 될 플로우를 집중 검증했다.

출시 과정 — iOS·Android 동시 배포

• 준비: iOS 생태계만 익숙한 데다 Android는 기기가 없어 출시를 미뤄오다 중고 기기를 구했다. 결과적으로 목표 기간 내 iOS와 Android 프로덕션까지 통과했다.
• 스토어: App Store, Google Play Console 모두 개인정보 처리, 스토어 설명, 스크린샷, 연령/권한, 프라이버시 설정 등을 챙겼다.
• 심사 과정:
  • iOS의 경우 첫 심사는 약 2일 만에 통과했고 이후 빌드는 하루 단위로 승인됐다. 리뷰어 혼선을 막기 위해 앱 내 필수 입력, 오프라인 동작 범위, 감정 태그 설명을 심사 노트에 명시했다.
  • Android는 심사 메모 대신 설문과 '비공개 테스트' 절차로 이루어졌다. 비공개 테스트 필수 기간이 14일이나 되어서 체감상 iOS보다 더 까다롭게 느껴졌다. 다행히도 좋은 솔루션을 통해 잘 넘겼다. 이건 다음 번외글에서 풀 예정이다.
• 승인 반려: 정책·프라이버시·권한 설정 등을 챙겼다고 생각했지만 Privacy Manifest 설정에 빠진 항목이 있어 보완했다.
• 빌드: iOS와 Android 출시 일자 간격이 1달 넘게 차이가 나는데 지금 생각해보면 오히려 다행(?)이었다. ios 첫 출시 이후 여러 차례 빌드를 올리며 업데이트했기 때문. 이렇게 한 쪽에서 안정화를 한 뒤에 나머지 스토어에 올렸기에 리소스를 아낀 셈이다. 만약 실시간으로 2개 스토어를 번갈아가며 여러 차례 빌드했다면 비효율적이었을 것이다.

남은 과제 — 출시 후 운영과 성장

• 마케팅: 다채널 테스트와 크리에이티브 실험 병행
• 제품: 영상 레시피 분석 기능 추가, 공유/커뮤니티 확장 검토, Dead Code 정리
• 학습: Dart/Flutter 강의 수강, Clean Architecture 스터디 등

이번에는 처음인지라 혼자 앱을 만들고 출시하는 일만으로도 벅찼는데, 다시 한다면 개발 초반부터 마케팅 활동 병행을 시도할 것 같다. 또한 지금 시점에서 보니 앱의 핵심 기능에 집중하는 방향으로 가지치기를 해보려 한다. 범위를 고민 중이다.

4. 배운 점

기술·프로세스·운영

• TDD: 핵심 로직에라도 작은 단위 테스트를 붙이면 QA 시간이 줄었다.
• DB 영속성: Hive 데이터는 저장 타이밍과 타입 일관성을 보장해야 한다.
• 데이터 백업: MVP 단계에서 수동으로 데이터 보존 이중 장치를 제공할 수 있다.
• API 보안: Vercel 프록시를 활용해 OpenAI 키를 노출하지 않을 수 있다.
• UI 폴리싱: 앱 컨셉과 컬러 시스템을 정의해두면 일관성 부여 작업이 빨라진다.
• QA: 시뮬레이터·디버그 모드로 속도를 높이되 실기기 테스트는 필수이다.
• 문서화: 프로세스, 체크리스트 등을 문서화해두면 오히려 효율적이다.

실행 루틴부터 마인드셋까지

• 실행 루틴: 하루/주 단위로 쪼개고 AI와 페어로 작업하니 초보자인 나도 흐름을 놓치지 않았다.
• 질문 습관: 작업마다 "왜 하려는가, 더 나은 방법은 없는가"를 스스로에게 묻고 고민하는 게 버릇이었다.
• 마인드셋: 포기하고 싶은 순간마다 "하루만 더, 한 번만 더"하며 재현하고 수정했더니 결국 문제가 풀렸다. 포기하지 않는 끈기가 출시까지 길을 이끌어주었다.

마무리하며

마침내 상상만 하던 것이 실제로 구현되고 누군가에게 쓰이는 순간, 새로운 세계가 열리는 느낌을 받았다. 이렇게 한 번 끝까지 만들어 본 경험이 동력이 되어 요즘은 새로운 아이템을 탐색하고 아이디에이션하는 중이다.(2가지 정도 추가로 만들어보고 싶은데..!) 만약 현업에 돌아간다면 이제는 프로덕트와 밀접한 관련이 있는 직무로 커리어를 전환해보고 싶다는 생각도 든다.

이번 '마무리하며' 파트는 링크드인 올릴 게시물 내용으로 대신한다.

<'무식'해서 용감했던 비개발자, 그 덕분에 iOS·Android 앱 출시까지>

앱 출시 도전 프로젝트 회고를 마무리하며 실감합니다. 이 과정은 단순히 앱을 만드는 것이 아니라, 콘텐츠·마케팅을 해오던 제가 '만드는 사람'으로 거듭나는 여정이었다는 것을요.

Recipesoup는 어떤 '성공담'이 아니라 '실행의 결과물'입니다. 시간과 포기하지 않는 마음(중꺾마!)만 있으면 누구나 할 수 있다는 걸 믿게 되었습니다.

처음부터 끝까지 혼자 하면서 실수도 많았는데요. 앱 종료 시 사용자 데이터가 사라지는 문제는 데이터 저장 방식을 재설계하며 해결했고, OpenAI API 키 노출 사고는 노출 지점을 즉시 찾아 키를 교체하고 복구했습니다. 스토어 정책과 권한 설정도 다 챙겼다 생각했지만 승인이 반려되어 놓친 항목을 빠르게 보완했습니다. 매번 시행착오는 문서화하고 체크리스트를 만들며 배워갔습니다.

초기 기술 스택은 바이브 코딩 강의를 참고해 잡았어요. 막힐 때면 Claude와 Codex에 질문하거나 서브레딧과 기술 블로그를 뒤졌고, 개발자 지인의 조언을 구하며 실마리를 찾았습니다.

언젠가 읽었던 고레에다 히로카즈 감독의 에세이 '걷는 듯 천천히'가 떠오릅니다. 책 내용은 거의 잊혀졌지만 "그럼에도"라는 네 글자는 여전히 선명합니다. 앱을 만들었다는 사실보다, 멈추고 싶었던 순간마다 '그럼에도' 계속 걸었다는 점에서 더 큰 의미가 있었습니다.

10여 편의 회고글을 쓰며 "왜 이런 선택을 했나" 스스로에게 다시 질문하며 배움이 깊어졌어요. 이 기록들이 첫 발을 떼기 주저하는 누군가에게 닿을 수 있다면 좋겠습니다.

Recipesoup 앱 출시 회고 시리즈 맵

• Prolog — 프로젝트 동기·기획, MVP 범위
• Ep1 — 기술 스택 선정·초기 설계
• Ep2 — 하루 만에 AI 레시피 앱 MVP
• Ep3 — 토끼굴 32단계 성장 UX
• Ep4 — 레시피 앱 UX 리프레시
• 번외 — UTM 제너레이터 제작기
• 번외 — 감사 메일로 뉴스레터 소개된 이야기
• Ep5 — 챌린지·콘텐츠 큐레이션
• Ep6 — 데이터 안전·백업·프라이버시
• Ep7 — TestFlight QA·스토어 심사 준비
• Ep8 — 출시 후 운영·Supabase·수익화 실험
• Ep9 — iOS·Android 출시·1인 개발 통합 회고
• 번외 — 안드로이드 비공개 테스트 솔루션 '도플리' 후기

지난 이야기

이전 글에 적었던 TestFlight 개선과 심사 준비를 마친 뒤 승인이 되었다. 출시 자체보다 앱스토어에서 앱 다운로드가 가능해지는, 마켓에 나온 이 단계부터 진짜인 느낌이다.(다른 차원의 어려움이 많다..) 이번 편에는 푸시 없는 로컬 앱 운영 방안 찾기, 업데이트 프로덕션 설정, Supabase 연동, 파트너스 배너 삽입 등 출시 직후부터 이어진 고민과 해결 방법을 모색했던 과정을 담아보았다.

출시 직후 — 푸시 없는 로컬 앱, 말 걸 창구가 없다

스토어 승인 알림을 받고 얼마 되지 않아 "업데이트 사항이 생길 때마다 빌드를 할 순 없는데, 사용자들에게 어떻게 알리지?"라는 질문이 떠올랐다. 개인 아카이빙 앱이기에 푸시 알림은 필수적인 기능으로 보지 않아 MVP 단계에서는 제외하고 출시를 진행했다. 로그인도 서버도 구현하지 않아 사용자가 앱을 켜야만 커뮤니케이션할 수 있고, 중요한 업데이트 소식을 바로 알릴 수 없었다. 이전에 업무할 때는 공지사항이나 배너 등 수정 시 CMS 툴에서 실시간으로 반영했었기에, 로컬 앱에서는 빌드 없이 즉각적인 변경이 어렵다는 점을 늦게 자각했다...

'그렇다면 현 구조에서 빠르게 활용할만한 채널은 무엇이 있을까?' 생각해봤다. 두 가지가 있었다. 앱 실행 시 자동으로 뜨는 업데이트 다이얼로그. 그리고 홈의 인앱 메시지 시스템. 이를 어떻게 써먹을지가 숙제였다.

푸시 없이 업데이트 알리기

upgrader 패키지 프로덕션 설정 확정

곧바로 프로덕션 설정을 조정하고 MessageProvider를 병행하는 운영 루틴을 잡기 시작했다. upgrader 패키지를 통해 앱이 실행될 때마다 애플 앱스토어 API에 자동으로 접속해서 최신 버전 정보를 가져오게 했다. 현재 버전과 앱스토어에 등록된 최신 버전을 비교해서 새로운 버전이 있으면 업데이트 안내 팝업을 띄운다. 예를 들어 내 폰에 설치된 버전이 1.0.0이고 앱스토어 최신 버전이 1.0.1이라면 사용자에게 이를 안내해준다.

앱을 알아서 최신 버전으로 설치해 주는 것은 아니다. 사용자가 팝업에서 "업데이트"를 눌러 App Store로 이동해야 실제 진행된다. iOS의 백그라운드 자동 업데이트 설정이 꺼져 있으면 이 팝업이 사실상 유일한 안내 창구다. 팝업 알림 빈도는 1일로 제한했다. 앱을 켤 때마다 팝업이 뜨게 할까도 고민했지만 사용자 입장에서는 너무 피로할 것 같았다.

안내 화면은 간결하게 구성했다. 자동으로 붙는 릴리즈 노트는 길이가 길어 핵심 메시지를 가려, 보이지 않게 처리했다. 버튼은 두 개의 선택지만 명확하게 보여주는 것이 혼란을 줄이는 방법이라고 판단했다. "업데이트" 버튼을 누르면 즉시 App Store로 이동하여 최신 버전을 설치할 수 있고, "나중에" 버튼을 누르면 다이얼로그가 닫히며 1일 후에 다시 안내받게 된다. 메시지는 빈티지 아이보리 테마의 따뜻한 톤앤매너를 유지하면서도 업데이트 필요성을 명확히 전달하도록 했다.

구버전 지원 한계: upgrader 패키지 부재 문제

업데이트 다이얼로그에도 구조적 한계는 있었다. 이전 버전에 upgrader 패키지가 없으면 자동 팝업을 띄울 수 없다는 점이다. 만약 버전 1.0.0에 upgrader가 없고, 1.0.1에 추가했다면 이전에 앱을 받은 사용자는 새 버전 출시 사실을 알 수 없다. 이 문제는 코드로 직접 해결할 수 없는 아키텍처 레벨의 제약이었다. 이후에는 공지 시스템으로 구버전 사용자도 놓치지 않게 해두었지만, 이 또한 Supabase 연동 이전 버전을 설치한 사람은 푸시가 없어 앱을 켜야만 알림을 받게 된다.

모두 새 버전부터라도 빈틈을 최소화하려는 대응 작업이었다. 로컬 앱의 경우 운영 채널이 제한적이니, 가능한 사용자의 개인 콘텐츠와 내부 루틴만으로도 돌아가는 구조가 유지 부담을 덜어준다는 교훈을 얻었다.

공지함으로 보완하는 업데이트 안내

앱 내 공지사항 시스템의 역할을 하는 '메시지함'은 홈화면의 🔔 아이콘으로, 기존에도 있었다. 실제 메시지함에는 개선 사항, 온보딩 가이드 같은 운영 메시지가 올라가 있었다. 읽지 않은 메시지가 있다면 레드닷으로 표시한다. 로컬 기반이던 메시지함은 이 시점에 Supabase를 연동해 원격 테이블에서 공지를 불러오도록 세팅했고, 실패 시 로컬 콘텐츠를 폴백으로 표시하게 했다.

중요한 건, 단순히 새 빌드 안내용으로 연동한 건 아니라는 점이다. 원격 DB인 Supabase로 메시지함을 관리하기 때문에 빌드 없이 언제든 공지를 추가할 수 있다. 푸시 알림 없이도 신규 기능 가이드, 이벤트 공지, 서비스 점검 안내 등 사용자와 소통할 최소한의 채널이 생긴 것이다.

빌드 없이 홈 콘텐츠 교체

로컬 앱에 Supabase를 도입한 이유

App Store 출시 직후 가장 답답했던 부분은 콘텐츠 수정이었다. 홈 화면에 보이는 요리 지식이나 추천 콘텐츠 섹션을 변경하려면 다음 과정을 거쳐야 했다.

로컬 JSON 파일 수정 → Flutter 프로젝트 다시 빌드 → App Store에 재제출 → 심사 대기 (1~2일) → 승인 후 배포 → 사용자 업데이트 필요

최소 이틀이 걸리는 구조였다. 그래서 메시지함에서 구현한 구조를 그대로 적용했다. 이제 홈화면에서도 빌드·심사 없이 콘텐츠를 즉시 수정 가능하다.

Supabase 연동 과정: 테이블 설계와 타입 맞춤

Supabase를 붙이면서 로컬 JSON 구조와 Supabase 테이블 스키마를 일치시키는 데에 가장 주의를 기울였다. 로컬 JSON 스키마와 Supabase 테이블 스키마를 1:1로 맞춰야 동기화가 안전하게 수행되기 때문이다.

• 컬럼명: 키값인 id, title, description, category 등
• 타입 매핑: JSON의 String → TEXT, 날짜 문자열 → DATE 등
• Nullable 처리: 로컬에서 Optional인 필드는 Supabase에서도 Nullable

Supabase에서 가져온 List<Map<String, dynamic>> 결과를 앱 코드에서 변환 없이 그대로 사용할 수 있었다. 원격/로컬 전환 시 추가 매핑 로직이 필요 없어 코드가 단순해졌다.

문제: 도입 직후 릴리즈 빌드에서 썸네일 전부 깨짐

Supabase를 처음 연동하고 빌드했을 때 "콘텐츠 큐레이션" 섹션 이미지가 전부 깨져 있었다. Storage 버킷 구조가 원인이었다. 처음 이미지를 업로드할 때 movies/, books/ 같은 카테고리 폴더를 만들어 정리했는데, 이 경로 부분이 URL에서 빠지며 해당 이미지를 찾지 못한 것이다.

해결: 버킷 루트로 이미지 이동 + 테이블 필드 일괄 업데이트

Supabase Storage에 접속해 해당 테이블 내 image 필드를 각기 매핑되는 스토리지 URL로 일괄 수정하니 문제가 해결되었다.

이 과정에서 Supabase 도입의 가치를 실감했다. 경로를 정리하고 테이블 필드만 변경해 몇 분 만에 복구됐다. 코드 수정이나 재빌드 없이 운영 단에서 바로 고칠 수 있었다.

캐시 TTL 문제와 운영 가이드

다만 주의사항으로, Supabase 데이터는 앱에서 1시간 동안 캐싱되기 때문에 수정 시 즉시 반영은 어렵다. 앱을 완전히 종료했다가 재실행해야 업데이트되며 이외에는 지연이 불가피함을 참고차 문서에 남겨두었다.

쿠팡 파트너스 배너: UX를 지키며 수익화 실험 기반 확보

왜 AdMob/전면 팝업/네이티브 광고 대신 쿠팡 파트너스 배너인가

• 강제 노출형 광고(전면, 팝업, 네이티브 피드 삽입 등)는 감정 기반 레시피 앱의 따뜻한 UX를 해친다.
• 빈티지 아이보리 톤에 맞춰 90×120px 미니 배너만 노출해 디자인 일관성을 유지했다.
• 홈 화면에서 "재료 필요 시 바로 구매"라는 맥락을 주며, 무작위 팝업처럼 사용자 흐름을 끊지 않는다.
• Apple App Store 심사에서 핵심 기능을 방해하는 광고는 리젝 사유가 될 수 있어 정책 리스크를 피했다.
• "UX를 지키며 수익화 실험 기반 확보"라는 전략 아래 성장에 집중하고 조용히 클릭 가능한 실험만 남겼다.

로켓 프레시를 선택한 이유

작은 수익화 실험을 고민했을 때 앞서 언급한 전면/팝업/네이티브 광고들은 모두 앱 톤과 충돌한다고 생각했다. 그래서 레시피 앱이라는 맥락을 살리면서도 UX를 지킬 수 있는 쿠팡 파트너스 로켓프레시(신선식품 배송 서비스) 다이내믹 배너를 넣어보기로 했다.

1. 맥락 적합성: 레시피 앱 사용자이기에 식재료 구매로 자연스러운 랜딩 유도
2. UX 침해 최소화: 광고처럼 튀지 않고 콘텐츠로 녹아들 수 있음

일반 광고 네트워크(AdMob, 애드핏, 카울리 등)는 노출·클릭 단위로 즉시 수익이 잡히지만 UX 침해 강도가 높은 전면·팝업·네이티브 광고 비중이 높다. 대신 쿠팡 파트너스는 구매 성사 시 약 3% 수수료만 지급된다. 단기 수익성은 낮지만 감정 기반 앱의 톤을 지키면서도 "재료 구매"라는 명확한 액션과 연결되어 실제 가치 있는 클릭만 남길 수 있다고 판단했다.

컬리는 SNS 인플루언서 전용
식료품 플랫폼인 '컬리'도 레시피 앱과 맥락이 맞아 어필리에이트 연동을 고려했다. 하지만 쿠팡 파트너스는 가입만으로 누구나 시작 가능한 반면, 컬리 큐레이터(컬리 제휴 마케팅)는 SNS 채널 기반 인플루언서 제휴 프로그램으로 앱 내 배너 연동은 대상이 아니었다. 게다가 유튜브 구독자 1천 명, 인스타그램/스레드/틱톡 팔로워 1천 명, 블로그 월 순방문자 1만 명 같은 최소 팔로워 요구사항도 있어 선택지가 될 수 없었다.

배너 디자인: 가이드 준수 + 배치 실험

쿠팡 파트너스는 지정된 배너 디자인을 그대로 써야 하고 색상·문구를 바꾸면 안 된다. 배너 자체는 공식 디자인을 사용하되, 앱 톤앤매너를 해치지 않으면서 정책을 지키도록 배치·사이즈를 바꿔가며 여러 번 테스트했다. 최종적으로 왼쪽에는 아이콘과 CTA 카피("새벽배송 장보기")를 두고, 오른쪽 90×120px 영역에 WebView로 다이내믹 태그를 삽입하는 구성이 가장 덜 튀었다. 배경색만 투명한 당근 컬러를 깔아 다른 섹션과 구분하면서도 앱 테마와 어울리게 했다.

WebView 네비게이션: 쿠팡 추적 유지하기

쿠팡 가이드에 맞춰 공식 다이내믹 배너를 넣었다. 클릭하면 WebView가 먼저 짧게 뜨고 이후 네비게이션 핸들러가 매 요청의 URL 스킴을 보고 분기하는 로직이다. 시작은 대부분 http(s)://로 들어오고, 리디렉션 응답에서 쿠팡 서버가 내려주는 링크가 coupang://(쿠팡 앱 딥링크)나 market://(앱스토어, 플레이스토어 링크)로 바뀔 수 있다. 설치 여부를 서버가 판단하는 건 아니고, 응답에 담긴 스킴을 그대로 OS에 넘긴다. OS는 설치된 앱이 있으면 열고, 없으면 마켓이나 웹으로 자연스럽게 넘긴다.

딥링크(Deep Link): 앱의 특정 화면으로 바로 이동시키는 URL. 앱이 설치되어 있으면 해당 화면으로 직접 랜딩하고, 없으면 웹이나 앱스토어로 폴백된다.

디퍼드 딥링크(Deferred Deep Link): 앱 미설치 상태에서 링크를 클릭했을 때, 설치 후 첫 실행 시 원래 의도한 화면으로 이동시키는 기술. 설치 전 캠페인 파라미터를 보존했다가 설치 후 복원한다. 마케팅 유입 채널 트래킹에 활용되며 Firebase/Branch/AppsFlyer 같은 SDK가 필요하다. (이건 기존에 실무하면서 "앱 설치 트래킹" 목적으로 익숙했던 용어인데, 이번 WebView 로직을 회고하면 디퍼드 딥링크의 내부 동작 방식까지 구체적으로 찾아보게 됐다.)

쿠팡 파트너스 배너는 일반 딥링크만 사용한다.

1. 쿠팡 앱 전용 주소(coupang://, market://)

• 이런 스킴은 "쿠팡 앱 또는 앱 설치 유도하는 마켓을 바로 열라"는 신호라 추가 작업 없이 바로 외부 앱으로 보낸다.

1. 일반 웹 주소(http/https)

• 1단계: 앱 안의 WebView에서 배너 HTML을 한 번 연다.
• 2단계: 리디렉션으로 완성된 최종 주소를 읽어 외부 브라우저·앱으로 넘긴다.

배너 스크립트가 쿠팡 서버로 요청을 보내면 서버가 리디렉션을 처리해 trackingCode=AB1234567 같은 파라미터를 주소에 덧붙인 뒤 최종 주소를 외부로 보내는 흐름이다.

사용자가 쿠팡 앱/브라우저를 다녀온 뒤에 Recipesoup 앱 배너가 깨지는 문제도 있었다. 이는 외부로 넘길 때 WebView를 닫아두고, 돌아올 때 초기 배너 HTML을 다시 로드한 뒤에야 화면에 보이게 순서를 조정했더니 안정화됐다. 제공된 배너 디자인을 유지하면서 정책을 지키고, 앱 톤앤매너를 살리기 위해 배치·사이즈만 조정해 최종 상태를 완성했다.

Disclosure 문구: 쿠팡 파트너스 정책 준수

쿠팡 파트너스 정책에 따라 제휴 문구를 명확히 표시해야 했다. 이 문구는 배너 카드 하단 중앙에 항상 노출되도록 했다. 다른 곳에 표기하거나 숨기면 정책 위반이다.

ⓘ 쿠팡 파트너스 활동으로 일정 수수료를 제공받습니다.

배너를 활성 사용 지표로 활용

로켓프레시 배너를 추가한 뒤 매일 배너 노출 수 패턴이 일정하게 유지되는 것을 데이터로 확인했다. 노출 수 외에도 클릭·구매까지 제대로 트래킹되는지도 직접 테스트해봤다. 참고로 쿠팡 파트너스 수수료는 보통 3%이고 구매 품목은 알 수 있지만, 구매자 정보는 넘어오지 않는다.

로컬 앱이라 사용자 데이터를 수집하지 않기에 데이터 측정이 어려웠는데, 매일 비슷하게 찍히는 배너 노출 수를 통해 간접적인 DAU 파악도 가능했다. (아직은 미미한 수치..ㅎㅎ)

마무리하며

이번에 배운 것은 "승인 이후부터 진짜 운영이"시작된다는 사실이다. 각 작업을 한 이유는 명확했다.

첫째, 버전 업데이트 팝업을 설정해 푸시 없이도 사용자에게 메시지를 보내도록 했다. 로컬 앱의 약점은 서버가 없어 사용자에게 직접 말을 걸 방법이 제한적이라는 점이었다. upgrader 패키지로 앱 실행 시 자동 버전 체크와 업데이트 안내를 구현해 최소한의 소통 채널을 확보했다.

둘째, Supabase 연동으로 공지·콘텐츠를 빌드 없이도 실시간 업데이트하도록 설정했다. 빌드-심사-배포로 이틀이 걸리는 구조는 운영 속도를 심각하게 저하시켰다. 필요한 섹션만 원격 우선, 로컬 폴백 구조로 전환하면서 효율적으로 변경사항을 반영하게 되었다.

셋째, 쿠팡 파트너스로 작은 수익화 실험이 시작됐다. 레시피 앱 특성에 맞는 로켓프레시 배너를 통해 UX를 최대한 해치지 않으면서도 수익 가능성을 테스트할 수 있었다. 배너 노출 수로 간접적인 DAU 지표를 추측해보는 것도 좋은 포인트였다.

출시 이후 작업들을 통해 결국 기본을 다시 떠올렸다. 앱의 가치는 제품 그 자체보다 사용자에게 달려있다. "앱 사용자 수를 늘리고 유지하기" 위해 더 노력해야겠다.

다음 에피소드 예고

이 회고 시리즈의 최종편, 마지막 Episode 09에서는 전체 앱 출시 여정을 회고하고, 운영 루틴까지 포함해 어떤 교훈과 v2.0 계획을 세웠는지 정리한다.

지난 이야기

지난 에피소드에서의 과정을 거쳐 ZIP 백업과 Hive 디버깅으로 데이터가 사라지지 않도록 작업했다. 이제 출시를 앞두고 Episode 07에는 TestFlight 기간 동안 발견한 이슈를 수정하고 앱스토어 심사 제출 전 체크리스트와 보안 전략을 정비한 기록을 적었다.

기능 개발도, App Store 행정·정책 절차도 모두 처음이라 뭐 하나 쉽게 굴러가는 게 없었다. 특히 썸네일·설명·키워드·프라이버시·연령 등급 같은 서류성 정보를 채우는 과정이 의외로 까다로웠다. (출시 소식 전해드렸더니 아는 개발자분도 "개발도 개발이지만 앱스토어 등록·출시가 더 어려웠을 텐데"라며 공감해주셨었다..ㅎㅎ) 그래도 이번에 한 번 해봐서 다음은 '아는 매운맛(?)'이라 처음보다 낫겠지, 생각한다. 이번 글은 그 과정에서 부딪힌 허들과 배운 점을 함께 적어두려 한다.

이 글에서 다루는 내용

• TestFlight 베타 기간 동안 발견한 이슈와 개선 작업
• Vercel 프록시로 OpenAI 키를 보호한 구조와 체크포인트
• 개인정보 문서와 App Store 메타 데이터 정리, 심사 제출부터 출시까지

Phase 0 — TestFlight 베타와 심사 체크리스트 정비

데이터 안전망을 갖추고 TestFlight 베타 테스트 기간 동안 "심사 제출 전 챙겨야 할 항목"을 정리했다. 앱 아이콘, 개인정보 처리방침 링크처럼 놓치면 심사에서 바로 거절되는 항목을 정리했고 Info.plist에서는 카메라·사진 접근 사유를 명확히 적고 앱 표시 이름 등을 다시 확인했다. .env.production을 추가해 릴리즈 빌드 시 자동으로 프로덕션 설정을 로드하도록 했다. 이를 통해 OpenAI 모델, 프록시 토큰, 로깅 레벨을 릴리즈용으로 분리해 환경 설정이 섞이지 않도록 했다.

앱 스토어 커넥트 개발자 계정은 미리 만들어 두면 편하다. Apple Developer Program의 멤버십 비용은 연간 $99 (약 12만원)로 해마다 갱신해야 한다. 등록 시 일회성으로 $25(약 3만원)만 지불하면 되는 안드로이드에 비해 많이 비싸다..

Phase 1 — 릴리즈 빌드와 실측 지표 확보

체크리스트 정리 후 릴리즈 빌드를 만들어 바이너리 크기를 기록하고, 서로 다른 실기기에 설치해 실제 응답 시간, 앱 용량 등을 측정했다. 토끼굴 언락, 레시피 작성, 챌린지 전환 등 핵심 플로우를 릴리즈 모드로 반복 실행하며 응답 속도와 성공 여부를 확인해 두니, 심사 대응에 필요한 수치를 객관적으로 확보할 수 있었다. Debug 모드에서는 데이터 persistence가 왜곡되는 경험을 이미 했기에 QA 문서에도 "Release 모드 실행 필수"를 명시했다.

Phase 2A — Vercel 프록시 구현과 보안 검증

프록시의 경우 TestFlight에 올리기 전에 구축을 마친 상태였다. 앱은 Vercel URL로만 요청을 보내면서 x-app-token 헤더를 붙이고 프록시가 검증한 뒤 OpenAI를 대신 호출한다. 실제 OpenAI 키는 Vercel 환경변수에서 관리되는 구조이다.

Vercel을 선택한 결정적인 이유

1인 개발 워크플로우에 최적화된 구조라고 판단했기 때문이다. 프로토타입 단계부터 비용 부담 없이 테스트할 수 있다는 점이 매력적이었다. 또한 "Node/TypeScript 파일 + 환경변수 몇 개"만으로 API 엔드포인트를 만들 수 있어 서버나 CI를 따로 세팅할 필요가 없었다. 또한 GitHub에 푸시하면 자동 배포되는 구조도 효율적이었다. 대시보드에서 환경변수를 직관적으로 관리할 수 있어 토큰 노출 사고 같은 긴급 상황에서도 빠른 대응이 가능해 보였다. 여러 모로 장점이 많다고 생각했다.

여기에 Rate Limit 시스템을 추가했다. 레이트 리밋은 일정 시간 내 API 호출 횟수를 제한하는 메커니즘이다. 만약 프록시 토큰이 노출되고 악의적인 사용자가 무한 호출을 시도하는 경우 방어막이 있으면 피해를 최소화할 수 있다. 나는 이 기준을 동일 IP & 시간당 50회로 잡았다.(로그인 인증 기능을 붙이지 않았기에, IP 기준으로) Recipesoup 앱 사용자 패턴을 가정해 만든 RATE_LIMITING.md 문서를 기반으로 정했다. 보통의 사용자는 많아도 하루에 3~5개 레시피를 만들 것이고, 각 레시피당 AI 분석 1회씩이면 하루 평균 5회 정도다. 분 단위당 제한을 고려해봤으나 사용자는 "한 번에 여러 레시피를 입력하는 행동"을 취할 수도 있다. 몰아 작업하더라도 시간당 20회 정도가 피크일 것으로 예상하여 50회는 여유로운 수준으로 보았다.

레이트 리밋 카운트는 Vercel KV에 저장하고 TTL(Time To Live)을 3600초(1시간)로 설정해 시간이 지나면 자동으로 초기화되도록 했다. 시간당 50회를 넘기면 HTTP 429(Too Many Requests)를 반환하며, 앱에서는 요청 한도를 초과했다는 안내 메시지를 띄운다.

Phase 2B — TestFlight 중 토큰 노출 사고와 복구

이처럼 Vercel 프록시는 이미 구현되어 작동 중이었지만 TestFlight 기간에 예상치 못한 문제가 발생했다. 앱스토어 심사를 위해 개인정보처리방침과 앱 지원 페이지를 작성해 GitHub Pages로 올리는 과정에서 OpenAI API 키가 담긴 txt 파일이 커밋되어 버렸다. 이 과정을 처음부터 복기해보면 이러하다. 파일을 수동 선택해 올리면 안전할 것이라 생각하며 GitHub Desktop을 사용 중이었는데, 막상 Claude Code 연동(MCP) 시 현재의 폴더 전체가 통째로 올라갈 수 있다는 사실을 모르고 있었다. .env는 .gitignore로 막아두었지만 문서 작업용 텍스트 파일은 관리 대상에 포함하지 못했다. 저녁 무렵 OpenAI로부터 "OpenAI API - API key Disabled"라는 제목의 키 노출 안내 메일을 받았다. GitHub를 확인한 결과 해당 파일이 public 레포에 있었다.

처음에는 빌드를 새로 올려야 하나? 싶었는데, 구조를 다시 짚어보니 그럴 필요가 없었다. 클라이언트는 x-app-token만 갖고 있고 실제 OpenAI 키는 Vercel 환경변수에서만 사용하고 있었다. 이제 해야 할 일은 노출된 OpenAI 키를 폐기하고 OpenAI/Vercel 환경변수를 새 키로 교체한 뒤 프록시를 재배포하는 것이었다. TestFlight 빌드를 새로 올리지 않아도 5분 만에 AI 기능이 정상화됐다.

이 사건으로 API 키가 노출되면 어떤 준비와 대응이 필요한지, 내가 놓쳤던 게 무엇이었는지 분명해졌다. key 보안에 늘 주의해야 함은 당연하고, .gitignore 범위와 GitHub 사용 시 업로드 범위를 미리 점검해두어야 한다는 사실을 다시 확인했다. Claude Code로 GitHub MCP를 쓸 때는 폴더 전체를 한 번에 업로드하지 않도록 필요한 파일만 지정하거나, 상황에 따라 수동 커밋을 선택하는 것이 더 안전할 때도 있다는 점을 깨달았다. 노출 사실을 인지하면 즉시 어느 작업·어느 파일에서 문제가 생겼는지 파악하고 원인을 제거한 뒤에 교체·재배포 루틴을 따라야 한다. 나중을 위해 키/토큰 교체 절차를 문서화해 두는 것도 방법일 것이다.

Phase 3 — 문서·심사 자료 업데이트

이후에는 App Store Connect에 사용자에게 제공할 개인정보처리방침, 앱 지원/FAQ 문서 url을 넣었다. 지원 페이지에는 기능 지원 범위·문의 채널·데이터 삭제 절차 등을 명시했고, 개인정보처리방침에는 로컬 저장 우선 원칙과 OpenAI API를 통한 선택적 데이터 활용 범위를 설명했다. 심사관 가이드에는 감정 메모 필수 입력, 토끼굴/챌린지 구조, 오프라인 동작 범위를 정리해 리뷰어가 헤매지 않도록 했다. 문서와 코드가 같은 모습을 바라보는지 마지막으로 교차 검토한 단계다.

Phase 4 — TestFlight QA와 앱스토어 제출 패키지 정리

보안 구조를 정리한 뒤에는 이 기간 활용하기 위해 만든 TESTFLIGHT_BUILD_GUIDE.md문서에 환경변수 설정부터 flutter build ios --release, Xcode Archive, App Store Connect 업로드까지 간단한 단계로 기록했다.

이어서 App Store 커뮤니티 체크리스트를 전수 확인했다. Recipesoup 앱의 경우 로컬 기반으로 로그인이나 서버 동기화도 없어 상대적으로 단순한 구조였기에 주로 "미완성으로 보일 만한 흔적"을 없애는 데 집중했다. 12~15개의 앱스토어 출시 전 체크리스트 중에서 나는 스플래시·비활성 기능 라벨을 다시 훑었다.

앱스토어 심사 거절되는 주요 포인트: 개인정보·권한 설정 불일치, SDK 프라이버시 매니페스트 누락, 로그인·결제·외부 링크 처리 오류, 기능 불안정, 설명 부족 등은 심사 거절의 원인이되니 꼭 챙겨야 한다.

Apple은 "Coming soon/준비중" 문구를 '덜 완성된 기능'으로 판단하는 사례가 많기에 이는 필수로 수정해야 하는 요소였다. 스플래시에 나타나는 당신의 이야기를 "준비중...” 텍스트를 "불러오는 중...”으로 바꾸고, 영상 링크 레시피 추출 요청 시 "기능 준비중" 문구를 "지원되지 않습니다"로 수정했다. '설정'에 더미로 넣어두었던 링크와 이메일 등도 최신 구현에 맞춰 다시 연결했다.

스토어 자산도 정리했다. App Store 스크린샷은 Figma에서 디바이스 목업을 직접 세팅하고, 감정 아카이빙·토끼굴·AI 분석·로컬 백업을 강조하는 카피까지 새로 작성했다. 앱 설명에는 AI 활용 등 5가지 레시피 입력 방식, 성장 시스템이나 분석 등 핵심 기능을 포함했다. 부제목·프로모션 텍스트·100자 키워드·검색 태그·카테고리·연령 등급도 다시 적어 누락을 방지했다.

Phase 5 — App Store 정식 심사 제출

App Store 앱 설명·부제목·프로모션 텍스트·100자 키워드·검색 태그·카테고리·연령 등급도 모두 챙겨 필수 항목을 최신 구현에 맞춰 수정했다. 그리고 정식 심사를 제출했다. 2일 뒤에 앱스토어에 정식 배포를 할 수 있었다. 드디어 출시!

심사 제출이 완료되면 메일이 발송된다. 보통 앱 심사 제출 후 50%는 하루 안에, 90%는 이틀만에 리뷰가 완료된다고 적혀있었다. 실제로 첫 심사 제출에는 이틀이 소요되고 이후 빌드부터는 하루만에 승인이 났다. '심사중-심사완료'가 주로 새벽에 이루어졌는데, 궁금해서 찾아보니 내 리뷰어는 미국 샌프란시스코 본사에 있는 것 같았다. 심사자마다 스타일이 달라서 꼼꼼한 리뷰어를 만나면 세세한 부분까지 체크하고, 느슨한 리뷰어를 만나면 최소 요건만 보고 통과시키는 경우도 있다고 한다. 하지만 전체적인 기준은 동일하므로, 기본 요건인 '정책 위반·크래시·개인정보·부정확한 메타데이터' 같은 문제가 있으면 통과할 수 없다.

앱스토어 심사 준비 항목 요약

• 형식 요건 충족: 스크린샷, 설명, 카테고리 입력
• 규정 준수 체크: 개인정보 처리, 타사 SDK 선언
• 심사 통과를 위한 문항 작성: 앱 사용 방식, 계정 필요 여부 등 설명
• 정책 문서 제출: 프라이버시 정책 URL 등

앱 자체 기능 개발도 쉽지 않았지만 App Store Connect에 썸네일·설명·키워드·프라이버시·연령 등급 같은 서류성 정보를 채우는 과정이 꽤나 까다로웠다. 처음인데다 행정 절차 + 정책 준수 작업까지 혼자 다 하려다보니 어려움이 있었다. 그래도 한 번 사이클을 돌았더니 이제 덜 복잡하게 느껴진다. 이번에 잘 해냈으니 다음 앱 제출은 좀 더 빠르게 해낼 수 있을 것 같다!

Recipesoup 앱스토어 바로가기

마무리하며

이번 작업의 목표는 "심사 전에 필요한 것(문서·기능·보안·스토어 자산)을 챙겨서 되돌아올 일을 막자"였다. 특히 아래 네 가지를 체크하는 식으로 진행했다.

첫째, 문서화이다. 첫 정식 심사 제출이라 체크리스트, 빌드/배포 가이드, 심사 대응 메모를 문서로 만들어 기록해두었다. 덕분에 "이번 빌드에 무엇이 들어 있는지" 적는 게 수월했다.

둘째, 심사 통과 요건 충족이다. Info.plist 권한 이유를 적고, "Coming soon" 같은 문구를 빼고, 개인정보 처리방침/지원 페이지를 최신으로 맞췄다. 스토어에 적은 내용이랑 실제 앱이 다르지 않게 신경 썼다.

셋째, 보안 실수 대비이다. GitHub MCP 주의사항을 정리하고 API 키 노출 시 교체 절차와 로그 확인 순서를 프로세스화했다. API 키 노출 사고는 "문서도 배포 대상"이라는 교훈을 남겼다.

넷째, 프록시와 Rate Limit. OpenAI 호출을 프록시로 감싸고 요청 수를 제한해서, 앱·서버·로그가 한 흐름으로 움직이도록 기본 틀을 잡았다.

결국 제출 준비는 코드·문서·스토어 자산을 맞춰주는 일이라는 걸 알았다. 이 흐름을 만든 덕분에 첫 심사 후 이틀 만에 통과할 수 있었다.

다음 에피소드 예고

Episode 08에서는 출시 이후 운영 핫픽스 작업을 다룬다. Update 공지 정비, Supabase 연동, 어필리에이트 배너 삽입 등을 하며 느낀 점을 풀어볼 예정이다.

지난 이야기

지난 에피소드까지는 깡총 챌린지와 추천 콘텐츠로 기록 리듬을 만드는 데 집중했다. 이후에는 전체적인 검수를 거쳐 TestFlight 단계로 갔다. 이번 편과 다음편에서는 이 단계에서 앱스토어 심사 제출 전 진행했던 QA 및 추가 작업들에 대해 다룰 것이다. 먼저 에피소드 6에는 데이터가 사라진 이유를 디버깅한 과정, 백업과 저장·복원 안전장치 구축기를 담았다.

이번 글에서 다루는 내용

• 실기기에서 Hive 데이터 손실을 재현하고 해결한 과정
• Box<dynamic> 통일·flush/compact 재시도 안전장치
• 사용자가 직접 지킬 수 있는 ZIP 백업 UX 설계
• 비개발자로서 시도한 문제 범위 좁히기, 회고하는 이유

데이터 안전 과제 재정의

TestFlight 테스트 때 "앱 강제 종료 후 다시 켜면 저장한 레시피가 전부 사라진다"는 리포트를 받았다. (테스트 초기에 개발자인 제부, 파워 J 성향의 동생이 각자의 시각으로 QA를 해주어서 강제 종료 후 데이터 손실 이슈, UX/UI 개선 의견까지 바로바로 피드백을 받을 수 있었다. 고마워요!) 사실 처음에 QA 템플릿을 만들었었는데 작은 앱이다보니 캐주얼하고 빠르게 피드백을 주고 받는 게 리소스상 이득임을 깨닫고 이 절차는 바로 스킵했다.

아카이빙 앱 특성상 기록 데이터를 지키는 것이 최우선이었기에 목표를 세 갈래로 정리했다. ① 실기기에서 발생하는 Hive 데이터 손실을 재현하고 원인을 찾는다. ② 저장·복원 안전장치를 정비한다. ③ 사용자가 원할 때 수동 백업이 가능하도록 기능을 마련한다.

Phase 1 — Hive 데이터 손실 재현 타임라인

기존에 갖고 있던 2개의 iOS 실기기에서 직접 테스트해보니 저장 → 강제 종료 → 재실행 시 보관함에 있던 레시피가 사라지는 현상이 동일하게 발생했다. 평소에는 홈 버튼으로 나가거나 백그라운드에 두는 정도만 반복해서 미처 문제를 발견하지 못했다. 디버깅하다보니 보관함 레시피가 사라지는 반면, 알림함에 있는 메시지는 그대로라는 점을 알게 되었다. 알림함은 SharedPreferences로 저장하고 있어서 읽음/안읽음 상태값과 콘텐츠가 그대로 유지되고 있었다. 박스 단위로 비동기 flush되는 Hive와 달리 SharedPreferences는 즉시 처리되기에 Write Timing이 문제라는 결론에 도달했다.

비동기 flush: Hive는 데이터를 박스 단위로 모아서 메모리에 쌓아 두었다가 flush()를 호출하거나 내부 타이머가 돌 때 디스크에 내려쓰는데, 이것이 비동기 쓰기 작업이다.

Hive가 모든 디버그 모드에서 데이터를 지우는 것은 아니지만, Debug 빌드 특유의 Hot Reload·DevTools 결합 때문에 박스가 다시 열리거나 OS 캐시에만 쓰고 끝나는 케이스가 발생했다. 한 번이라도 Hot Reload를 누르면 방금 넣은 값이 flush 되기 전에 재초기화되어 결과를 믿을 수 없었던 것. 한편 Debug 모드뿐만아니라 Release 모드에서도 동일한 증상이 발생했기에 이건 명백히 고쳐야 할 "문제" 상황이었다. 이후부터 모든 데이터 영속성 테스트는 최종 배포 환경과 동일한 Release 모드에서 돌리기로 했다. 릴리즈 빌드는 box.flush() 호출이 바로 디스크까지 내려가며, 수정이 제대로 작동하는지 확인할 유일한 근거가 됐다.

뱅뱅 돌았던 삽질 과정

처음에는 알림함처럼 맞추면 되겠지, 라고 생각해 같은 방식으로 보관함을 구현하려 했다. 그러나 레시피 데이터가 담기는 박스는 키 수와 데이터 크기가 훨씬 커서 비교 대상이 아니었다. 클로드 코드, 코덱스를 써도 안되어서 비슷한 사례를 찾아 구글링을 해보았다. 강제 종료 직전에 sleep으로 시간을 벌고 WidgetsBindingObserver/MethodChannel로 이벤트를 받는 케이스를 발견해 await Future.delayed를 심거나 다시 한 번 box.flush()를 호출해도 증상이 그대로였다. box.flush() 뒤에 await box.compact()를 붙여 디스크에 확실히 쓰이게 저장·백업·복원 시퀀스마다 배치도 해봤지만 허사였다. iOS 네이티브와 신호를 주고받아 포그라운드/백그라운드 전환마다 flush()를 강제해보기도 했지만 이 또한 해결방법은 아니었다.

차라리 외부 DB로 옮길까, 싶어 기존에 만들어뒀던 Supabase 프로젝트를 열어 연동도 시도해봤다. 하지만 구조상 로컬에서 관리하던 사용자별 상태값을 옮기려면 복잡도가 높아지는 데다 인증·마이그레이션 준비도 덜 되어 있어 당장 전환하기엔 리스크가 컸다. 결국 레시피 보관도 개인별 저장 시스템이기 때문에 수퍼베이스 연동은 Hive를 안정화한 뒤, 해야 할 이유가 생긴다면 별도 로드맵으로 빼기로 결정했다. (나중에 알았지만 이건 진짜 안해도 되는 시도였다...ㅎㅎ)

Release 모드 강제 테스트 로그

테스트를 하며 시뮬레이터는 Debug 모드만 지원해 릴리즈 빌드를 검증할 수 없다는 사실을 깨닫게 되어 실기기로 Release 테스트를 진행했다. 약 20차례 시나리오를 돌리면서 차수가 높아짐에 따라 중복 시도를 피할 방법을 찾게 되었다. 내가 생각한 방법은 문서화. APP_CRASH_DEBUG.md파일을 만들었고 Test 19 프로토콜이 QA 기준이 됐다.

레시피 작성 → 보관함 저장 → 강제 종료 후 앱 실행 직후에도 레시피가 그대로 남아 있는지 확인해 테스트마다 수정 사항, 재현 조건과 결과를 전부 남겼다.

강제 종료 이슈 핵심 정리

• 홈을 눌러 백그라운드로 두는(paused) 상황에서는 문제가 없었다. 강제 종료(detached)로 완전히 앱을 지울 때만 레시피 박스가 비워졌다.
• Debug 모드에서 Hot Reload·DevTools가 결합되면 박스를 다시 열고 닫느라 로그가 뒤섞이거나 데이터가 비어 결과를 믿기 어려웠다. 그래서 _hiveInitialized 플래그가 있는 HiveService 싱글톤(앱 전체에 하나만 두는 관리자)을 두어 "한 번만 열기, 열려 있으면 그대로 재사용" 원칙을 적용시켰다. 중복 초기화(열어둔 박스를 또 여는 상황)도 막았다.
• Release 빌드에서도 동일하게 레시피가 사라졌기 때문에 실제 사용자가 겪는 플로우를 기준으로 오류를 잡아야 했다.
• 따라서 '강제 종료 후 재실행' QA는 릴리즈 빌드에서만, Debug 모드 결과는 참고용으로 남겼다.

Phase 2 — 저장·복원 안전장치 개선

문제를 파고들자 OS 버퍼에 쓰기가 남아 있는 사이 앱을 종료하면 Hive에 값이 남지 않는다는 사실이 드러났다. 동시에 백업 복원 시 ID가 중복되거나 Hive key 타입(int/String)이 섞이면 박스가 손상된다는 것도 확인했다. 원인을 파헤치고 해결하기까지 꼬박 나흘을 썼는데, 해결책은 두 가지였다. 첫째, 저장 직후 다시 읽어 값이 남아 있는지 검증하고 실패 시 재시도 루틴을 추가했다. 둘째, 병합 복원 시 ID 충돌을 감지해 새 타임스탬프 ID를 발급하고 모든 키를 String으로 통일했다. 이전에 크롤링 데이터를 빅쿼리에 적재할 당시, 테이블 스키마 정의 시 "key type은 전부 string으로 맞추는 게 정신건강에 좋을 것"이라 했던 데이터 파트 팀장님 조언이 떠올랐다.(또르륵..) '데이터'로 이 경험들이 연결되면서, 어떤 종류의 작업이라도 언젠가는 도움이 되고 의미가 있다는 것도 다시 한 번 느꼈다.

싱글톤 초기화 역시 이 시점에서 확정됐다. "저장은 되는데 박스를 닫지 못한 채 앱이 종료되는 것 같다. 다음 실행에서 크래시가 나며 아예 켜지지 않는다"고 개발자인 제부에게 상황을 설명했더니 "굳이 박스를 닫아서 크래시가 난다면 열어둔 채 관리하라"고 조언해줬다. (열었으면 잘 닫는 게 기본인 줄 알았는데.. 안 닫는 방법도 있었구나..!) 그 말을 따라 HiveService를 앱 전체에서 한 번만 초기화하도록 묶고 _hiveInitialized 플래그로 중복 초기화를 막았다.

문제를 좁히는 3단계
재현 기록: 무슨 순서로 무엇을 했는지 글로 정리한다. 환경 비교: 디버그/릴리즈, 기기/시뮬레이터, 데이터 양을 바꿔 '어디에서만 터지는가'를 찾는다. 요약 공유: 이미 해본 것과 못 해본 것을 적어 지인·AI·커뮤니티에 묻는다.그래도 모르겠으면 해당 현상만 남긴 작은 테스트 프로젝트를 만들어 파고들어본다.

실제 구현에서는 복원 대상을 순회하면서 현재 박스의 ID 집합과 비교해 충돌을 감지하고, 충돌 시에는 새로운 타임스탬프 ID를 발급해 복제본을 저장한 뒤 로그로 변환 과정을 남기도록 했다.

recipes, settings, stats, burrowMilestones, burrowProgress 5개 Box 모두를 dynamic 타입으로 통일한 뒤, challenge_progress 박스에도 flush()를 강제 호출해 챌린지 진행률이 즉시 디스크에 남도록 했다. 이 작업을 거친 뒤에야 "앱을 껐다 켜도 데이터가 남는다"고 말할 수 있었다.

데이터 다루기 Q&A

타입 정책

• Hive는 박스 키 타입이 뒤섞이면 다시 열지 못한다. 기존에는 int와 String이 섞여 있었기에 어느 타입으로 열지 정해지지 않아 실패했다.
• 지금은 recipes, settings, stats, burrowMilestones, burrowProgress 박스를 모두 Box<dynamic>으로 열고 JSON(Map)만 넣어 타입 혼선을 없앴다.

JSON vs Map & 키·값 구조

• JSON은 디스크에 { "title": "수박" }처럼 문자열로 저장된 형태고, Map<String, dynamic>은 그 문자열을 Dart에서 다루기 좋게 펼친 버전이다.
• Recipesoup 앱은 객체 → toJson() → Map<String, dynamic> → Hive 순서로 저장하므로, 박스 안에는 실제로 "recipe_1759029682515": { "title": "클램 차우더", "emotionalStory": "오늘의 기록" ... } 같은 구조가 통째로 들어간다.
• 여기서 바깥 키("recipe_1759029682515")가 레시피 전체를 가리키는 이름표고, 안쪽 JSON의 "title", "calorie", "ingredients" 등이 내부 key, 텍스트·숫자는 내부 value이다.
• 이제 받아주는 박스는 Box<dynamic)이지만 실제 값은 항상 JSON(Map) 하나라 '서랍은 자유형, 내용물은 JSON' 구성이 되었다. Hive가 박스를 열 때 타입 혼동을 일으킬 위험이 줄었다.

이제 '문은 한 번만 열고, 안에 넣는 물건 종류도 통일' 하는 두 축이 결합돼 데이터 무결성이 깨지던 루프가 멈췄다.

Phase 3 — ZIP 백업 플로우 설계

데이터 손실 이슈를 재현하고 저장 로직을 손본 뒤에는 최소한의 안전 장치를 마련하기 위해 ZIP 백업 플로우를 설계했다. Hive 박스를 JSON으로 직렬화해 ZIP 파일로 묶고, 이메일·AirDrop 등으로 내보내는 수동 백업 흐름을 기본으로 삼았다. 백업 파일명 규칙을 정해 복원 시 충돌 여부를 체크하고, 오류가 나면 어떤 메시지를 띄울지까지 세분화했다. 이 과정에서 토끼굴 데이터를 여러 번 초기화·복원하며 진행 상태값이 정상적으로 돌아오는지 테스트도 반복했다.

작업 범위 확정

클라우드 백업이나 자동화 기능까지 욕심내면 일정에 차질이 생길듯해 수동 ZIP 백업을 확실하게 제공하는 데 집중했다. 버튼 위치, 저장 직후 안내 문구, 오류 대응 흐름을 다듬으면서 '지금 바로 제공 가능한 가치'와 '향후 확장 옵션'을 구분했다.

마무리하며

이번 작업을 통해 배운 것은 "문제 상황을 끝까지 정리하기"이다. 재현 기록을 꼼꼼히 남기고 디버그·릴리즈 환경을 번갈아 비교하고, 정리된 상태로 조언을 구했기에 뾰족한 힌트를 얻게 되었다.

두 번째 다짐은 "끝까지 포기하지 않을 것"이었다. 이번 문제를 만나기 전까지 어떤 이슈든 하루 안에 해결 못한 적이 없었지만, 이번엔 달랐다. 나흘째가 되자 '혼자선 못 푼다, 그냥 포기해야 하나? 앱 출시가 무모했던 걸까?'라는 생각까지 밀려왔다. 그래도 하는 데까지 원인을 좁혀가며 노트에 정리했다. 그러다 결국 노트북을 들고 동생 부부를 찾아갈 채비까지 했던 날, 기적처럼 길이 열렸다. 아마 이때 포기했더라면 앱 출시도 하지 못했을 것이다.

세 번째로 기억해두어야 할 건 "AI 시대라도 기본기는 중요하다"는 사실이다. 그게 내가 회고글을 쓰며 다시 복기하고 공부해보는 이유이기도 하다.
기본기 쌓는 정석 루트는 'CS 공부 → 이론 학습 → 실무 적용'일 것이다. 나는 실전에서 부딪힘 → 문제 해결 → 회고하며 원리 이해하는 방식으로 배워가고 있다. 아주 깊게는 못해도 '왜 그런 건지' 이해하게 되면 그것도 나름의 기본기가 되지 않을까? 이번 경험을 통해 내가 배우고 얻은 것들을 나열해보면 이러하다. Hive의 작동 원리(flush, compact, 타입 시스템), Debug와 Release 환경의 차이, 데이터 영속성 테스트 방법, 문제 재현부터 디버깅까지의 QA 프로세스 및 체크리스트.
그냥 문제를 해결하고 끝내면 '어떻게든 되긴 했네'로 남지만, 회고를 통해 복기하다보면 '왜 그렇게 됐는지를 어렴풋이 이해하게 된다. 이렇게 몸소 익힌 경험을 글로 정리하다 보면, 조금씩 내 것이 되어가는 것 같다.

다음 에피소드 예고

다음 글에서는 iOS 제출 체크리스트를 다시 정리한 과정을 다룬다. Info.plist 권한, 앱 아이콘, 실기 테스트, 심사 문서, 프록시 아키텍처까지 TestFlight 전 마지막 준비를 이어서 공유한다.

지난 이야기

이전 에피소드 작업을 통해 UI/UX를 개선하며 화면은 어느정도 안정됐다. 그러나 지속적인 기록 리듬을 만드는 게 필요해보였고 이번 글에는 그 장치를 만든 과정을 담았다.

기록 리듬 문제 재정의

이 에피소드에서의 작업은 "어떻게 하면 사용자의 일상에 자연스러운 기록 리듬을 만들까?"라는 질문에 답을 찾아보는 과정이었다.

UI 톤을 맞추고 나니 "수행할 미션이 있으면 좋겠다”는 생각이 들었다. 토끼굴 성장 여정만으로는 일일 기록 리듬을 만들기 어렵다고 판단했고, 감정 기반 허브와 추천 데이터를 만들어보기로 했다. 목표는 ① 감정을 고르면 바로 맞춤 챌린지를 제안하는 허브를 만든다. ② 진행 과정에서 매끄러운 흐름을 위해 UX·카피를 정리한다. ③ 챌린지 완료 후 레시피 화면으로 넘어갈 때 데이터가 누락되지 않도록 안정화한다. 이렇게 세 가지를 잡았다.

챌린지 허브 설계

"깡총 챌린지"라는 이름으로 홈화면에서만 진입할 수 있는 게이트를 만들었다. 바텀 탭에 넣어야할까 잠시 고민했는데, 이미 바텀 탭에 마일스톤 기능인 토끼굴이 있었다. 토끼굴이 더 "레시피 기록"이라는 앱의 본질에 가깝다고 여겼기 때문에 바텀 탭에 그대로 두었다. 그리고 홈화면에서 진입 가능한 챌린지 메인 상단에 8가지 감정(기쁨·평온·활력·그리움·피로·모험·아늑함·건강)으로 레시피 추천 장치를 넣었다.

감정 기반 추천 로직

사용자가 선택한 감정의 태그와 challenge_recipes.json 안의 레시피 태그가 하나라도 겹치면 추천 목록에 올리고, 난이도와 미완료 여부로 정렬해 보여준다. 이를 위해 감정 옵션마다 해시태그 세트를 붙여 두었다. 초기 기획 시에는 매칭률이 낮았지만 지금은 전체 태그가 매칭된다. '기쁘고 행복해요'는 바비큐 립 같은 파티 메뉴에 #축하, #특별한날 을 붙이고 '평온하고 차분해요'는 허브차·힐링 레시피에 #명상, #차분함을 달았다. '활기차고 신나요'는 세계 요리·고난이도 메뉴로 #도전, #활력 태그를 부여했고, '피곤하고 지쳐요'는 회복식에 #든든함, #회복을 매칭해 에너지 식단이 즉시 노출된다. 이를 관리하기 위해 감정 태그 ↔ 레시피 태그 매핑 표를 별도로 관리하는 mood-tag-mapping.md 파일을 만들었다. Flutter 단에서는 진입 → 감정 선택 → 태그 매칭 → 추천 카드 → 완료 카드 흐름을 유지한다.

3가지 메인 챌린지 카테고리

챌린지 허브는 사용자의 기분과 상황에 맞는 레시피를 제안하기 위해 3가지 큰 축으로 구성했다. 현재 총 51개 챌린지가 세부 카테고리로 나뉘어 있다.(여기는 앞으로 더 늘리거나, 아예 다른 방향을 고민중이다.)

• 감정별 챌린지: 감정 상태에 맞춘 레시피 큐레이션. 감정을 선택하면 해당 무드 태그와 매칭되는 요리들을 추천한다.
• 세계 맛 여행: 한식부터 이탈리아·멕시코·인도까지 다양한 나라와 지역의 요리를 탐험하는 카테고리. 아시아·유럽·아메리카·퓨전 테마로 구성해 이국적인 맛과 문화를 담았다.
• 건강 라이프: 다이어트·면역강화·식물성 식단 등 건강 목표에 맞춘 레시피. 자연식·케어 등 웰빙을 위한 요리를 제안한다.

진행 UX와 카피 폴리싱

챌린지의 뼈대를 세운 뒤에는 사용자 집중도 높이기 작업을 진행했다. 완료 카드가 터치되지 않던 문제를 해결하고, 카테고리 색상을 앱 팔레트에 맞춰 파스텔 톤으로 통일했다. 진행 화면은 '단계별 진행'과 '완료 & 기록' 두 스탭으로 나눠 최소한의 정보만 보여주고, 다음 동작이 명확히 보이도록 했다. 챌린지 완료 후에는 원할 경우 레시피로 기록할 수 있도록 했다.

챌린지→레시피 파이프라인 안정화

기능을 붙이며 가장 크게 막혔던 문제는 챌린지를 끝내고 레시피 작성 화면으로 넘어갈 때 '소스·양념'과 '만드는 법' 필드가 텅 비는 이슈였다. 원인을 추적해 보니 챌린지 JSON을 만들 때 조리 단계를 포함하지 못했고, 소스·양념 리스트도 그대로는 레시피 입력 폼에 들어가지 않아서였다. 전환 로직을 다시 짜서 조리 단계를 별도 JSON에서 가져오게 했다. 소스·양념 리스트는 문자열로 합쳐 레시피의 '소스 비율' 필드에 매핑하도록 재설계했다. try-catch로 실패 상황을 잡고 전환이 꼬이면 허브로 되돌리는 예외 처리도 붙였다.

추천 데이터 JSON 구조 정리

홈 화면 추천 영역도 손을 봤다. 챌린지 카드와 별개로 "오늘은 뭘 해볼까?"를 꾸준히 던지려면 데이터 구조를 정리할 필요가 있었다.

세 가지 콘텐츠 블록 기획

기획 단계에서 세 가지 축을 정했다. 첫째는 계절 재료로 만드는 제철 레시피. 가을 전어구이, 김장철 보쌈, 겨울 호떡처럼 시의성 있는 요리를 제안해 "지금 이 계절에 챙겨야 할 맛"을 상기시킨다. 둘째는 가볍게 참고할 수 있는 요리 상식 카드. 향신료 보관법, 마이야르 반응, 수비드 조리법처럼 1분 안에 읽을 수 있는 팁으로 요리를 부담스럽지 않은 학습 경험으로 바꾼다. 셋째는 책·영화 추천 카드. '줄리 & 줄리아', '리틀 포레스트: 겨울과 봄', '소금, 지방, 산, 열'처럼 요리를 콘텐츠로 확장해 주는 작품으로 주방 밖에서도 영감과 감상 기록을 이어 갈 거리를 제공한다.

콘텐츠 운영 전략과 업데이트 주기

제철 레시피 블록은 "금요일마다 변경"되도록 업데이트 주기를 설정했다. 이를 위해 미리 리스트를 만들어 두고 금요일에 해당 시즌 레시피가 교체되면 일주일 동안 같은 카드가 유지된다. 더 자주 변경되면 좋겠지만 1인 운영 시 현실적인 주기로 세팅했다. 요리 상식 카드와 책·영화 카드는 시즌을 타지 않는 영역이어서 수십 개의 콘텐츠를 미리 만들어두고 캐러셀 형태로 좌우 스와이프 시 랜덤 노출되도록 만들었다. 앱에 진입할 때마다 새로운 조합이 등장하여 '업데이트되고 있다'는 인상을 줄 수 있고, 운영하는 입장에서도 실제로 잦은 수정 없이 데이터 풀만 가끔 보강하면 된다. 랜덤 캐러셀 구조 덕분에 홈 화면이 정적인 목록으로 굳어 있지 않고, 사용자마다 다른 큐레이션을 체감하게 된다.

JSON 구조 설계와 데이터 아키텍처

세 블록을 lib/data/content/*.json 파일로 체계화하면서 각 콘텐츠 블록마다 제목, 설명, 태그, 이미지 경로 같은 키 구조를 동일하게 맞췄다. 제철 레시피는 조리법을 접어두기-펼쳐두기로 구현해 필요한 사람만 볼 수 있게 했다. JSON 안에 instructions 배열로 조리 순서를 담아 두면 화면에서는 이를 확장 가능한 위젯으로 표현한다.

AI 이미지 생성 프롬프트 전략

제철 레시피와 요리 상식 카드 이미지는 AI 이미지 생성 도구로 직접 만들었다. 프롬프트 작성 시 각 콘텐츠의 핵심 키워드를 조합했다. 예를 들어 "가을 전어구이"라면 "grilled fish, Korean traditional dish, realistic"처럼 사실적인 표현으로 요리 이미지를 담으려했고, "마이야르 반응"이라면 "browning reaction, detailed description, educational illustration"처럼 설명 자료의 성격을 강조했다. 큐레이션 섹션(책·영화)은 실제 작품 표지 이미지를 가져왔다. 모든 이미지는 assets/images/content/ 경로 아래에서 관리하고, JSON에는 상대 경로만 기록해 나중에 이미지를 교체하거나 추가할 때도 구조를 유지할 수 있게 했다.

사용자 경험과 기록 유도 흐름

홈 화면을 스크롤하며 사용자는 계절 콘텐츠나 요리 지식, 문화 콘텐츠를 훑어본 뒤 자연스럽게 기록을 시작할 수 있다. 제철 레시피는 계절감을 환기하고, 토막 상식 카드는 새로운 배움을 제공하며, 책·영화 추천은 요리 너머의 영감을 준다. 이 세 가지 요소가 시너지를 내어 사용자가 '무언가를 기록하고 싶다'는 영감을 얻도록 하고자 했다.

사실 기능적으로는 이미 기록 플로우가 돌아간다. 그럼에도 홈 콘텐츠 섹션을 만든 건 레시피가 재료·조리법·문화권·라이프스타일을 조합해 끝없이 변주되는, 그 자체로 콘텐츠가 풍부한 카테고리라고 생각했기 때문이다. 또한 사용자가 홈을 처음 마주했을 때 "여긴 레시피를 다루는 공간이구나"라고 자연스럽게 인지하기를 바랐다. 그걸 가장 쉽게 보여줄 수 있는 장치가 콘텐츠 블록이라고 판단했다. 그래서 계절·지식·문화 섹션을 홈에 배치하고, 그다음 아카이빙이나 챌린지 실행으로 이어지게 흐름을 묶었다.

마무리하며

깡총 챌린지의 허브는 현재 감정에 맞는 미션을 즉시 제안하고, 폴리싱된 진행 화면은 집중을 돕는다. 전환 파이프라인을 안정화하면서 챌린지와 레시피가 끊기지 않게 연결됐고, 로컬 JSON 기반 홈 추천 데이터가 다시 챌린지로 이어지는 순환을 만든다.

이 과정을 통해 몇 가지 중요한 점을 배울 수 있었다. 첫째, 추천 기능은 데이터 정비와 UX 설계가 정교하게 맞물려야만 비로소 제 역할을 할 수 있다는 사실이다. 둘째, 챌린지와 레시피처럼 여러 기능이 연결된 플로우에서는 중간 단계의 데이터 유실을 막는 방어 로직이 필수적이라는 점을 다시 한 번 확인했다. 마지막으로, 추천 콘텐츠는 1인 개발 환경에서도 데이터 구조만 잘 설계해두면 충분히 유지보수할 수 있겠다는 작은 가능성을 엿볼 수 있었다.

다음 에피소드 예고

Episode 06에서는 TestFlight 직전 데이터 안전망을 다듬는다. 레시피 데이터 백업 전략, Hive 디버깅, Native Storage 전환 검토까지 "데이터가 사라지지 않는 앱"을 만들기까지의 험난했던(?) 과정을 공유한다.

Recipesoup 앱은 "AI를 활용해 요리를 쉽게 기록하는 감정 레시피 아카이빙"을 목표로 만들었다. Flutter를 처음 다루며 바이브 코딩 강의 커리큘럼을 따라 완성한 앱이다.

앱의 뼈대는 바이브 코딩 강의에서 배운 구조를 그대로 적용했었다. 수업에서 익힌 요소를 프로젝트에 붙여 본 과정은 이전 에피소드에 정리해두었다.

강의를 통해 비개발자도 약 한 달 만에 출시까지 갈 수 있다는 가능성을 확인했고, 그걸 가능하게 해주신 강사 선생님께 감사한 마음이 들어 메일을 보냈다. 그 메일 한 통이 Recipesoup 앱뉴스레터 메인 소개로 이어졌는데...!!

Recipesoup 앱
ios 다운로드 가능, android는 11월 내 출시 예정

그 전에 잠깐, 내가 수강했던 바이브 코딩 강의랑 뉴스레터 소개를 살짝 해보려 한다. (이번에 PPT 자동 제작 기능 후기가 담겨있어서 더 좋았음)

바이브 코딩 강의 소개

아이디어를 직접 구현해 보고 싶거나, 1인 개발을 준비하는 분이라면 잔재미코딩 선생님의 꼭 익혀야할 최신 AI: 풀스택 바이브 코딩 강의에서 많은 팁을 얻게 될 것이다. 나는 앱 만든 이후에도 필요한 부분들 다시 보는 중이다. 게다가 수시로 AI 트렌드 소개, 기술 변화에 맞춘 업데이트 영상이 무료 추가되어서 계속 보게된다. 아래에 강의 커리큘럼을 요약해두었으니 참고하자.(선생님 소개는 여기)

풀스택 바이브 코딩 커리큘럼

잔재미코딩 뉴스레터 최신호에서 클로드 코드 업데이트 소식을 보고 적용해서 PPT 슬라이드를 만들어봤다.

최신 AI, 개발, 데이터 관련 트렌드가 담긴 뉴스레터

IT 최신 소식을 빠르게 접할 수 있는 채널이어서 구독 추천. 몇 달 동안 받아보면서 다음과 같은 점 때문에 더욱 유용했다. (난 뉴스레터 보다가 강의 결제함ㅎㅎ)

• 가장 빠르게 IT 업계 소식 확인 가능
• 직접 써본 툴 후기(장단점), 활용 포인트 예시 포함

실제로 GPT-5 출시 당일, 업데이트 사항과 직접 써본 후기가 메일로 바로 날아왔을 때 놀랐다. 클로드 코드 2.0 때도 마찬가지였다.

가장 최근 발행된 11월 뉴스레터에는 클로드 코드 플러그인의 Skills를 짚어주셨다. 관련 내용은 내 경우 바이브 코딩 강의에 무료로 업데이트되어서 바로 볼 수 있었다. 잔재미코딩 유튜브에서도 확인 가능!

이건 내가 작성한 블로그 내용을 넣어 만들어본 PPT. 클로드 코드에 던져주니 초단위로 뚝딱 생성됐다. 뉴스레터 안봤으면 이런 꿀팁 늦게 알았겠지.. 핵심 내용 알아서 뽑고 톤앤매너 맞춰서 디자인까지 싹 해준다. 요즘 클로드 코드 성능이 좀 떨어져서 멀어지고 있었는데 다시 가까워짐...

감사 메일 작성 계기

10월 앱 출시 이후, 해냈다는 생각과 함께 감사한 분들이 떠올랐다. 그중에는 내가 들었던 바이브 코딩 강의를 만들어주신 선생님도 있었다. 더듬더듬 강의를 보며 혼자 진행한 프로젝트였지만 강사님의 안내와 자료에서 많은 배움을 얻었다. 그래서 감사 메일을 보내기로 했다.

다만 온라인 수강생이라 강사님과 직접 이야기를 나눈 적도 없거니와.. 출시 직후라 앱 성과도 없었기에 메일을 보내는 것이 조심스러웠다. 그래도 강의가 아니었다면 프로젝트를 시작하기 어려웠을 거라는 생각이 들어서 마음을 전달하기로 했다.

메일 제목은 "감사 인사 드립니다 - 수강생 앱 출시 소식 공유"로 적었다. 강의에서 얻은 팁 덕분에 앱을 출시할 수 있었다는 사실, 앱 설명 한 줄, 앱스토어와 회고 블로그 링크를 넣었다. 부담 되시지 않도록 마지막에 "답장 주시지 않아도 괜찮습니다"라고 덧붙였다.

그런데 얼마 후 선생님이 답장을 주셨다! 따뜻한 격려 말씀과 함께 몇 가지 물어봐주셔서 뉴스레터 소개 여부, 좀 더 상세한 앱 설명 등을 정리해 다시 전달드렸다. 이어서 "추후에 잘 정리해서 뉴스레터에 포함하겠다"는 메일이 도착했다. 강의 덕분에 앱도 만들었는데 뉴스레터까지 실리게 되다니, 더욱 감사했다.

AI·개발 뉴스레터 메인 소개

얼마 뒤 11월 3일자 뉴스레터에 내가 만​든 앱이 소개되었다.

뉴스레터 인트로에 이렇게 많은 지면을 할애해주시다니..! 비록 온라인이지만 몇 차례 강의를 수강하며 팬심(?)을 가지게 된 선생님이 뉴스레터에 내 앱을 다뤄 주셨다는 사실에 감격.. 블로그 링크도 걸어주셨다. 감사합니다!

돌아보면 온라인으로 강의를 진행하시는 선생님 입장에서도 반가운 소식이셨을 것 같다. 실제로 메일로 "힘이 된다고" 말씀주셔서 용기내길 잘했구나 싶었다. 혹시 수강생 중에 이런 소식을 전할까 말까 망설이는 분이 있다면, 작은 감사 메일이 새로운 연결로 이어질 수 있기에 한 번쯤 용기를 내보는 게 어떨지! 나에게는 성장의 동력이 되고 선생님께는 보람이 되는 멋진 순환을 경험하게 될 테다.

감사하는 마음, 긍정적 영향

작은 인사가 어떤 효과를 냈는지 정리해 보면 다음과 같다.

• 긍정 루프: 감사 메일을 계기로 격려와 뉴스레터 게재 기회를 얻게 되었다.
• 동력 회복: 구현 과정을 되짚어보며 후속 업데이트 계획도 같이 정리되었다.
• 관점 확장: 메일을 적으며 주변의 도움을 다시 떠올릴 수 있었다.
• 트래픽 증가: 뉴스레터 발행 이후 블로그 세션수가 크게 늘어났다.

이번 일로 감사 인사가 실제 연결로 이어질 수 있다는 점을 다시 확인했다. 거의 다 와가는 구글 플레이 스토어 출시 과정도 같은 마음으로 잘 마무리해야겠다.

그간 앱을 출시하기까지의 과정을 회고해 왔는데, 잠시 쉬어가는(?) 차원에서 요즘 잘 쓰고 있는 Recipesoup 전용 UTM 생성기와 관리 시트 구축 과정을 정리해 본다.

왜 UTM 생성기를 따로 만들었나

최근 Recipesoup 앱 출시 회고 블로그 글을 여러 채널에 공유하고 있다. 콘텐츠와 마케팅을 하면서 '숫자는 제대로 봐야 한다'는 감각이 몸에 배었었다. 큰 볼륨이 아니더라도 GA에서 정확한 지표를 보고 싶어 UTM을 붙였다. 그런데 링크드인, 앱스토어, 유튜브, 향후 예정된 SNS까지 채널이 늘어나면서 매번 스프레드시트를 열어 파라미터를 입력하고 GA4에서 값이 제대로 들어왔는지 확인하는 일이 점점 번거로워졌다. 단순 반복 작업을 좋아하지도 않고, 실무에서 알파벳 하나가 틀린 탓에 지표가 엉뚱하게 쌓인 사례도 직접 봤기에 자동화가 필요하다고 판단했다. 그래서 자동으로 UTM을 생성해주는 도구를 만들어보기로 했다.

"이 정도 작업을 자동화하는 것은 과한 투자인가?"라는 의문은 있었다. 하지만 한 번 틀을 만들어 두면 이후에는 입력 → 생성 → 기록이 자연스레 이어진다. 규칙을 매번 확인하지 않아도 되고 휴먼 에러를 시스템이 대신 막아준다. 요즘에는 AI와 다양한 기술 덕분에 간단한 툴 정도는 반나절이면 만들 수 있는 환경이 갖춰져 자유로움과 확장성을 자주 체감한다.

다섯 가지 UTM 파라미터 다시 정렬하기

UTM 필드를 혼동 없이 쓰기 위해 다섯 가지 파라미터의 역할을 다시 정리했다. 오랜만에 보면 헷갈릴 때가 있어 기준을 명확히 해 두었다.

• utm_source: 사용자가 들어온 출처. linkedin, newsletter, naver처럼 플랫폼 이름을 적는다.
• utm_medium: 전달 방식. social, organic , cpc등 매체 유형을 기록한다.
• utm_campaign: 상위 캠페인 그룹. 보통 paid 광고 진행하면 autumn_discount_2025 등을 사용. 내 경우 앱 콘텐츠 시리즈로 묶었다.
• utm_content: 동일 캠페인 안의 세부 콘텐츠 구분. focus_price vs focus_benefit 같은 A/B 테스트값. 나는 에피소드 구분용으로 사용했다.
• utm_term: 검색 광고나 키워드 실험 값. 필요한 경우에만 입력한다.

역할을 명확히 나눠 두니 채널별로 어떤 값을 써야 할지 덜 고민하게 되었다. 그리고 이 내용을 각 필드 타이틀과 디스크립션에도 녹였다.

정책을 문서로 확정하기

혼자 쓰는 툴이라도 규칙이 없으면 자꾸 길을 잃는다. 그래서 utm-policy.md 문서를 만들어 필수·선택사항 파라미터를 표로 정리하고, 플랫폼별 UTM 추적 가능 여부와 GA4 실시간 확인 항목을 함께 적어 두었다. 이 문서가 UI 설계의 기준점이 되었다.

Recipesoup 톤을 살린 UI와 배포 방식

UTM 생성기 UI는 HTML/CSS/JavaScript로 구현했다. 디디자인은 모노톤으로도 충분하지만, Recipesoup 전용 툴이라는 느낌을 주고 싶어 앱의 토끼 로고와 크림색 팔레트를 그대로 사용했다. 기능 면에서는 아래와 같은 편의 요소를 넣었다.

• https://를 생략해도 자동으로 보정한다.
• 드롭다운에 자주 쓸 옵션을 미리 넣고 "직접 입력"을 선택하면 커스텀 필드가 열린다.
• 생성된 링크는 버튼 한 번 클릭으로 복사, 토스트 메시지로 피드백을 준다.
• 파비콘을 추가해 에러 페이지처럼 보이지 않게 했다.
• 각 필드에 짧은 힌트를 붙여 입력 목적을 바로 이해할 수 있게 했다.

프론트엔드는 GitHub Pages로 배포했다. 저장소에 푸시하면 바로 반영되고 브랜치 기반으로 실험 버전을 따로 운영하기도 쉽다. 어디서든 동일한 URL을 열면 바로 작업을 시작할 수 있다.

여기서 자바스크립트는 HTML만으로 처리하기 어려운 입력 수집, UTM 조합, Apps Script와의 통신을 담당한다.

Apps Script와 Google Sheets로 자동화 완성

UTM 생성기에서 입력을 마치면 Google Apps Script 웹앱(WEB_APP_URL)에 JSON으로 아래 정보를 전달한다.

• 원본 URL과 최종 UTM URL
• 선택한 source/medium/campaign/content/term 값

Apps Script는 Google Sheets에 같은 데이터를 기록한다. 언제 어떤 링크를 만들었는지, 칼럼별 값까지 자동으로 쌓이고 분류되니 히스토리를 수기로 관리할 필요가 없어졌다.

"이미 Vercel 프록시를 쓰고 있다면, 모든 로직을 Vercel Serverless Function으로 옮겨서 한 번의 fetch 요청으로 처리하면 되지 않을까?"하는 생각도 들어 검토를 해봤다. 하지만 Google Sheets API를 직접 호출하려면 서비스 계정과 OAuth 인증을 세팅해야 하고 토큰 갱신과 권한 관리를 추가로 챙겨야 한다. 반면 Apps Script는 시트와 같은 계정 안에서 실행되기 때문에 인증을 손대지 않고도 빠르게 읽고 쓸 수 있다.

Supabase와 Edge Function 조합도 고려했다. 데이터가 늘어났을 때 SQL로 대시보드를 만들거나 다른 앱과 연동하기 좋은 선택지다. 다만 지금은 데이터가 적어서 스프레드시트가 합리적이다. 별도 DB를 운영하면 초기 마이그레이션과 백업까지 챙겨야 해서 우선순위를 낮췄다. Make·n8n·Zapier 같은 자동화 툴은 구축 속도와 확장성이 뛰어나지만 속도와 쿼터 제한을 살펴봐야 한다.

결론적으로 Apps Script는 무료로 간단하게 시작할 수 있는 데다, 나중에 다른 스택으로 옮겨가기에도 쉬워 가장 가벼운 출발점이었다.

기술을 조금씩 더 익힐수록 선택지는 계속 늘어난다. "이 조합 대신 다른 서비스를 쓰면?" 같은 질문이 매번 떠오르는데, 결국 지금 상황에서 적절한 균형점과 대안이 베스트인 것 같다. 자유도가 높아진 만큼 어떤 옵션을 선택할지에 대한 고민이 늘 따라다니는 요즘이다.

단축 URL 파이프라인 설계

UTM 구조가 그대로 노출되면 링크가 길어지고 캠페인 전략이 드러나기도 한다. 내 경우 너무 긴 UTM 처리가 목적이었다. 처음에는 Apps Script에서 바로 단축하려고 했지만 오히려 URL이 길어지는 문제가 생겼다. 그래서 Vercel 프록시를 사이에 두고 다음 순서로 처리하게 작업했다.

1. 생성기 → Apps Script: 캠페인 데이터를 전달

2. Apps Script → Vercel 프록시: 단축 URL 생성 요청

3. Vercel 프록시: 난수 코드 생성, 기존 코드와 중복 여부 확인

4. 중복이 없으면 링크 저장, 원본 URL과 매핑해 Apps Script로 응답

5. Apps Script는 단축 URL까지 포함해 시트에 기록

짧고 간단한 UTM 링크가 만들어졌다. 개인용이라 메인 도메인은 커스텀하지 않았고, Apps Script가 실패하면 에러 메시지를 띄우고 기본 UTM 링크를 먼저 보여주도록 예외 처리를 넣었다.

다만 처음에는 단축 링크를 눌러도 실제 캠페인 페이지가 아니라 Google Apps Script의 HTML 화면이 뜨면서 GA가 데이터를 못 받는 문제가 있었다. 단축 주소 → Apps Script → 캠페인 페이지 순서가 꼬여 있었던 것. 그래서 역할을 단순화했다. Apps Script는 시트에 기록만 남기고 '최종으로 보내야 하는 주소'만 돌려주도록 바꾸고, Vercel은 그 주소로 바로 넘겨주는 중간다리 역할만 하도록 정리했다. 이제는 단축 링크를 클릭하는 즉시 캠페인 페이지가 열리며 GA4에서도 의도한 소스·매체 값이 빠짐없이 쌓인다.

[최종 흐름] UTM 생성기 → Apps Script → Vercel → 블로그 페이지 → GA4 UTM 이벤트 수집

GA4 검증과 재사용 흐름 다듬기

툴을 만든 뒤에는 GA4 실시간 보고서로 파라미터가 정확히 기록되는지 확인했다. 테스트 결과 GA4 대시보드에 입력값이 정확히 들어왔다. 실시간 개요에서 direct로 표시되더라도 이벤트 매개변수를 열어 source, medium, campaign 값을 확인하면 의도한 대로 들어왔는지 바로 검증할 수 있다. utm-policy.md에 정리해둔 체크리스트와 나란히 비교해 QA 속도도 빨라졌다.

마무리하며

작은 도구지만 마케팅 자동화 사이클을 처음부터 끝까지 세팅했다. Recipesoup 회고 시리즈에서 자주 쓰는 옵션을 기본값으로 넣어두니 클릭 몇 번이면 링크가 만들어지고 입력값이 알아서 쌓인다. GA4에서는 소스·매체가 일관된 이름으로 묶여 채널별 비교가 간단해졌고, 시트 덕분에 히스토리를 따로 정리할 필요도 없다.

반복 작업을 줄이고 다시 체크하는 과정의 리소스를 덜 수 있다는 점이 특히 만족스러웠다. 짧은 시간 안에 필요한 것을 직접 구현한 경험도 의미있었다. 다음에는 협업자를 초대할 수 있는 접근 제어, 생성된 링크를 캠페인 요약 카드로 변환하는 기능처럼 주변 흐름을 확장해 볼 생각이다.

기술과 AI 덕분에 필요한 도구를 쉽게 만들어 실험할 수 있는 시대가 왔음을 다시 실감했다. 불편함과 문제를 빠르게 개선할 환경이 갖춰져 있으니 앞으로도 주저하지 않고 계속 테스트하고 만들어봐야겠다.

지난 이야기

이전 에피소드에 토끼굴 마일스톤을 붙이며 "한 층씩 파 내려가는 재미"를 만들었던 이야기를 담았다. 다만 기능은 만들어졌어도 화면은 여전히 거칠고 버튼 배치가 제멋대로였다. 이번 글에는 직접 쓰며 불편했던 UI/UX를 집중적으로 다듬은 한 주의 작업에 대해 담았다.

이 글에서 다루는 내용

• 토끼굴 마일스톤 작업 이후 UI 개선이 필요하다고 판단한 배경
• 빈티지 톤 컬러 시스템과 Material 3 컴포넌트 적용 과정
• Bottom Navigation·AppBar 구조 개편과 SafeArea 오류 수정
• 진행 메시지·감정 메모 UI 재작성 예시 케이스
• 직접 테스트하며 발견한 개선 포인트들

사용자 동선을 줄이는 정보 구조 재정비

토끼굴 작업을 마무리한 뒤에 앱을 써 보았는데 전체적으로 화면이 정돈되어 있지 않다는 느낌이 들었다. 가장 큰 문제는 상단 AppBar와 하단 Bottom Navigation이 동시에 존재한다는 점이었다. 실제 사용자는 하단 탭으로만 이동하게 만들었는데 AppBar가 제목과 설정 버튼 영역을 차지해 크기가 작은 화면에서는 콘텐츠 영역을 잠식하고 있었다. 그래서 AppBar를 걷어내고 이동 탭은 하단 5가지(홈·토끼굴·통계·보관함·설정)로 통일했다. 각 화면 상단에는 텍스트 헤더(토끼굴, 보관함 등)만 남겨 사용자가 '지금 어디에 있는지' 알 수 있도록 했다.

Before: 상단 AppBar + 하단 4탭
┌──────────────────────────────┐
│ AppBar (Recipesoup 제목)      │ ← 중복된 헤더
├──────────────────────────────┤
│ 탭: 전체 | 즐겨찾기 | 최근        │ ← 필요한 정보가 묻힘
├──────────────────────────────┤
│         화면 콘텐츠             │
├──────────────────────────────┤
│ Bottom Navigation (5탭)       │
└──────────────────────────────┘

After: 텍스트 헤더 + 탭 + 하단 5탭
┌──────────────────────────────┐
│ 보관함                   🔍    │ ← 텍스트 헤더 + 검색 아이콘
├──────────────────────────────┤
│ 탭: 전체 | 즐겨찾기 | 최근        │ ← 필요한 정보만 남긴 탭바
├──────────────────────────────┤
│         화면 콘텐츠             │ ← SafeArea로 여백 정리
├──────────────────────────────┤
│ Bottom Navigation (5탭)       │
└──────────────────────────────┘

검색 기능도 별도 탭에서 보관함 내부로 옮겼다. 사용자가 미리 저장해 둔 레시피를 찾고 싶을 때 떠올릴만한 가장 자연스러운 공간은 '보관함'이라고 가정했기 때문이다. 또한 이전에는 Search 탭으로 이동한 뒤 다시 돌아오면 즐겨찾기·정렬 정보가 끊겼다. 이제는 보관함 헤더의 검색 아이콘을 누르면 바텀시트가 열리고 필터·검색·즐겨찾기를 한 화면에서 만날 수 있다.

바텀시트에는 최근 레시피에서 추려낸 '추천 태그'를 항상 노출하게 했다. 태그를 탭하면 곧바로 검색어가 채워지고 다시 누르면 해제되는 구조라 긴 문장을 입력하지 않아도 원하는 레시피를 빠르게 찾을 수 있다. 검색 결과 리스트도 바텀시트 바로 아래에 붙여 "검색 → 레시피 카드 → 상세 보기" 흐름이 끊기지 않게 했다.

감정 기반 앱다운 언어로 다시 말하기

UI 구조 못지않게 화면을 채우는 문장도 중요했다. 사용자가 입력을 시작하기 전부터 '어떻게 쓰면 될지'를 안내하기 위해 레시피 작성·챌린지 후기·재료 추천 같은 주요 폼에 예시 키워드를 심었다. 레시피 작성 화면에는 제목 예시(예: 직장인 힐링 히야시츄카), 감정 스토리 샘플 문장, 재료와 조리 단계의 기본 포맷을 넣었다. 냉장고 재료 추천 화면은 "양상추, 무화과, 썬드라이 토마토"처럼 조합 사례를 보여 주고 "쉼표로 구분하거나 + 버튼으로 추가하세요"라는 힌트를 덧붙여 흐름을 이어 갈 수 있도록 했다.

URL 가져오기 화면도 "블로그나 웹사이트의 레시피 URL을 입력하면…"이라는 설명과 함께 플레이스홀더를 넣어 처음 보는 사용자도 구조를 이해하도록 했다. 특히 링크로 가져오기의 경우 영상 링크를 필드에 넣자마자 '지원 불가' 메시지를 띄웠다. 해당 기능을 지원하기 전까지는 사용자가 링크를 넣은 뒤 불필요하게 버튼을 누르고 결과값이 나오기를 기다리는 상황이 생기지 않도록 하고 싶었다.

경고 메시지는 빨간 박스 대신 빈티지 팔레트로 정돈했다. 치명적인 문제가 발생한 게 아닌 이상 상태 메시지만 잘 보여주면 될 것이었다. 안내 박스와 다이얼로그는 공통 컴포넌트를 사용해 제목·문구·아이콘 배치를 맞춰주었다. 사진 분석 실패, 비디오 URL 경고 등 상황이 달라도 같은 톤으로 들리도록 맞춘 과정이다.

빈티지 톤 전 화면에 입히기

감정 기반 앱이라는 메시지를 시각적으로도 전달하고 싶어 Material 3 팔레트를 다시 정리했다. 베이스(#F8F3EC)와 포인트(#D4A574, #8C7A6B)를 전체 테마에 적용하고 카드 그림자와 라운드 형태를 토끼굴 카드와 동일하게 맞췄다. 감정 태그 뱃지 색상도 카테고리별로 다시 지정했다. + 버튼을 누르면 나타나는 스피드 다이얼 메뉴도 각 아이콘마다 다른 컬러를 주어 구분이 더 잘 되도록 수정했다. 또한 가장 많이 쓰일 기능이기에 텍스트를 눌러도 이동하도록 했다. 가족들 대상으로 진행했던 베타 테스트 때 버튼을 눌러야만 랜딩이 되어서 에러처럼 느껴진다는 의견을 반영한 작업이었다.

실사용 환경에서 반복 검증하기

디자인을 수정했다고 끝이 아니었다. 가장 작은 화면 사이즈인 iPhone 12 mini 기기와 기타 시뮬레이터를 통해 Bottom Navigation 정렬, SafeArea 침범 여부, 토끼굴 탭 레벨 배지가 제대로 보이는지 반복 확인했다. 홈화면 콘텐츠 영역에는 50% 너비의 레시피 이미지를 추가하고 이미지가 없으면 기본 팔레트 색상이 보이도록 에셋 구조를 정리했다. 이미지가 깨져도 톤이 흐트러지지 않는 장치다.

마무리하며

한 주 내내 화면을 들여다보며 UI 네비게이션과 UX 카피, 플로우, 디자인 톤 등을 정리했다. 그 결과 진행 메시지는 단계가 명확해졌고 Bottom Navigation은 심플해졌다. 홈 카드·감정 메모·스플래시가 같은 팔레트로 묶이면서 토끼굴에서 시작한 감정 여정이 앱 전체로 이어져 통일감이 생겼다. SafeArea, 검색, 레시피 전환 루틴까지 직접 손보고 나니 실기기에서도 삐걱거리던 부분이 거의 사라졌다. 이제 다음은 감정 기반 챌린지를 붙여 이 UI 리듬 위에 기록 동기를 더할 차례다.

핵심 요약

• 빈티지 아이보리 팔레트로 주요 화면의 색감을 묶고, Material 3 요소를 정돈했다.
• Bottom Navigation과 탭 구조를 재정비해 이동 경로를 단순화했다.
• 감정 메모·진행 메시지·종료 카피를 학습자 톤으로 다듬어 다음 행동을 유도했다.
• SafeArea, 그림자, 타이포그래피를 조정해 화면에 자연스럽게 표시되도록 했다.
• 실기기 테스트는 시뮬레이터에서 못보았던 노치·SafeArea 이슈를 발견하게했다.
• 마이크로카피는 기능만큼이나 사용자의 인지와 행동에 영향을 준다.

다음 에피소드 예고

이제 UI가 정리됐으니 '기록을 계속하고 싶은 장치'를 붙일 차례다. 이어지는 이야기에서는 감정 기반 챌린지와 홈화면 추천 콘텐츠를 통해 토끼굴 성장과 일상 기록을 어떻게 연결했는지 다룬다.

다음 편에 계속...

지난 이야기

지난 에피소드에는 하루 만에 MVP를 완성한 이야기를 담았다. 사진을 찍으면 AI가 분석해 초안을 채워주고, 감정 메모를 붙이면 바로 저장되는 흐름을 확보했다. 에피소드 1에서 잡아둔 빈티지 톤과 감정 구조, 블로그 URL 스크래퍼, 단계별 프로그레스 메시지가 실제 화면에서 자연스럽게 동작하는 걸 확인한 날이었다. 다음 과제는 사용자가 계속 요리를 기록하고 싶어지도록 동기를 설계하는 일이었다.

이 글에서 다루는 내용

• 기록을 계속하게 만드는 장치를 찾게 된 배경
• 토끼굴 마일스톤 아이디어, 최종 UI로 이어지는 과정
• 32단계 성장 여정 + 16개 특별한 공간 설계, 이름 붙이기
• 언락 로직 이슈와 QA를 통한 재정비

문제 정의: 지속 기록을 위한 Gamification 설계 목표

MVP 작업을 마무리하고 나니 이제 "사용자가 왜 계속 기록해야 할까?"라는 질문이 떠올랐다. 감정 기반 아카이빙이라는 컨셉은 분명했지만 동기부여가 약하다는 생각이 들었다. 물론 실질적인 보상을 제공하면 베스트겠지만 지금 시점에서는 복잡하지 않으며 비용과 리소스가 덜 들고, 앱 톤앤매너에 어울리는 방향을 찾아야했다. 고민 끝에 "레시피가 쌓일 때마다 새로운 방이 열리는 토끼굴"이라는 컨셉으로 정하고 아이디에이션 작업과 마일스톤 시스템 설계를 본격적으로 시작했다.

  토끼굴 구조 초기 구조

  지상 (0개)
      │
      ├─── 아늑한 토끼굴
      │     "첫 레시피와 함께 아늑한 토끼굴을 만들었어요"
      │
      ├─── 작은 토끼굴
      │     "조금씩 넓어지는 나만의 공간"
      │
      ├─── 따스한 토끼굴
      │     "이제 제법 요리 공간이 갖춰졌어요!"
      │
      ├─── 서재 토끼굴
      │     "지식과 추억이 쌓인 서재 토끼굴이 완성되었어요"
      │
      ├─── 오순도순 토끼굴
      │     "모든 감정이 어우러진 오순도순 토끼굴의 완성"
      │
      └─── ...
            "점점 더 깊어지는 요리 여정"

기획 스케치 단계에서는 동물의 숲이나 심즈처럼 공간을 확장해 나가는 게임 메커닉을 고민했다. 레시피 저장이 단순한 '완료'로 끝나지 않고 "레시피가 쌓이며 토끼굴을 한 층 더 깊이 파 내려가는 경험"으로 남게 하고 싶었다. 사용자가 레시피를 작성하면 잠겨 있던 새로운 이미지를 볼 수 있게 아트워크의 unlock을 보상으로 하여 이야기 자체가 다음 마일스톤으로 안내하는 지도가 된다면 어떨까.

프로토타입: 토끼굴 UI/UX

클로드에 토끼굴 컨셉으로 UI를 그려달라고 요청하고, 레퍼런스 이미지도 제공하며 여러 버전을 만들어봤지만 정확히 내가 원하는 화면 구현은 잘 되지 않았다. UI 홈화면을 아래 레퍼런스처럼 그려서 하나씩 오픈되게 하고 싶었으나.. 현재 수준으로는 어렵겠다 싶어서 더이상 시간을 쓰지 않고 심플하게 가기로 결정했다.

토끼굴 화면의 카드 내용도 정의했다. “다음 방까지: 3개”처럼 숫자로 진행률을 보여주고, 세로 스크롤로 깊이감을 표현해 실제 구현 시에는 레이아웃 갈등이 거의 없었다. 머릿속에서만 그리던 감자줄기 형태의 지도 대신 한 줄로 내려가는 구조를 선택하면서 반응형 처리와 애니메이션 부담도 크게 줄였다.

성장 여정 전략: 32단계 레벨링과 네이밍 시스템

처음에는 100개 레시피를 목표로 잡았다가 최소한의 보람과 달성 가능성 사이에서 타협점을 찾았다. 최종적으로 70개 레시피(32단계)로 축소했다.

레벨 간 간격을 세 구간으로 나눴다. 1~5단계는 +1씩만 늘려서 '기록 시작이 어렵지 않게' 설계했고 6~21단계는 +2로 설정했다. 22~32단계는 +3씩 올렸다. 초반에는 빠르게 보상이 주어져서 몰입을 돕고, 후반으로 갈수록 '나 꽤 오래 해왔네'라는 성취감을 느끼게 하고 싶었다. 성장 구간을 다섯 단계(입문→발전→숙련→마스터→완성)로 나누고, 각 레벨에 이름을 붙였다.

예를 들어 Leve 1 <아늑한 토끼굴>에서 시작해 '견습 요리사'가 되고 시간이 지남에 따라 직접 식재료를 재배하고 수확하기도 한다. Level 24에서는 요리경연 대회를 나가고, 견문을 넓히기 위해 여행을 떠날 때도 있다. 마지막으로 자기만의 시그니처 메뉴를 만들고 Level 32에서 <꿈의 레스토랑>을 여는 여정으로 완성되는 이야기. 토끼굴마다 이름을 붙여 숫자 대신 서사로 기억하게 했다.

이 흐름을 코드로 옮길 땐 레벨 번호만 넣으면 이미지·설명·필요 레시피 수가 한꺼번에 채워지는 함수를 만들어 뒀다. 토끼굴 일러스트는 Assets에 미리 저장해 둔 파일을 불러오고 색감은 앱 전체의 빈티지 팔레트를 그대로 따라가게 했다. 이미지는 기존에 모아둔 레퍼런스 이미지들을 넣어서 프롬프트화해서 AI로 생성했다. 무료로 사용하다보니 가끔 에러도 발생했고 요청수 리밋에 걸릴 때도 있었지만 대량 생산을 하는 것이 아니었기에 짜투리 시간을 활용해 제작했다.

특별 공간 설계: 감정 데이터 기반 Unlock 조건

32단계 성장 트랙을 구성하면서 '감정 기반 아카이빙'이라는 기획 의도도 담겨야 한다고 느꼈기에 특별한 공간을 추가로 만들었다. SpecialRoom enum 16개를 만들고 Ballroom, Hot Spring, Orchestra처럼 컨셉이 뚜렷한 방을 만들고 각 방마다 고유한 언락 조건을 부여했다. 이 단계에서는 각 공간마다 언락 조건의 조합 패턴이 모두 달랐기에 로직이 제대로 작동하게 하는데까지 꽤 걸렸다. 많은 테스트와 단순화 및 타협을 거쳐 결국 완료했지만.

언락 조건은 레시피 데이터를 기반으로 한다. 성장 여정은 단순히 레시피 수량을 기준으로 했지만 특별 공간은 다르다. 예를 들어 Ballroom은 감정 스토리에서 3명 이상 사람을 언급한 레시피 3개를 모으면 열리고, Hot Spring은 슬픔·피로·그리움 같은 감정을 각각 한 번씩 기록해야 한다. 이외에 재료 및 계절 키워드, 평점 등을 조합해 다양하게 unlock 정책을 만들었다. 이 조건들은 의도적으로 화면에 명시하지 않았는데, 레시피를 작성하다 보면 우연히 공간이 열리게 하고 싶었기 때문. 감정·태그·키워드 등을 조합해 '내가 어떤 요리를 어떻게 해왔는지'를 느슨하게 확인할 수 있게 유도했다.

키워드는 리스트는 여행, 계절, 휴식 등 테마를 다양화했다. 조건을 만족하면 UnlockProgress 객체에 카운트를 저장한다. 중복을 막기 위해 processedRecipeIds를 따로 관리하고 재료 기반 조건은 ingredient 리스트를 순회하며 찾게 했다. 덕분에 다양한 표현으로 공간을 열어주는 프로세스가 구현되었다.

Unlock 로직 재작성과 디버깅 기록

토끼굴 UI를 다듬고 테스트하다가 특별 공간 카운트가 0/0으로 멈춰 있는 걸 발견했다. 언락 로직을 처음부터 다시 살펴보니 마일스톤을 두 단계만 만들고 멈춰 버리는 코드가 원인이었다. 이대로 두면 사용자가 아무리 레시피를 쌓아도 새로운 방을 만날 수 없었다. 그래서 앱이 켜질 때 32개 성장 단계와 16개 특별 공간을 한 번에 모두 만들어 저장하는 초기화 방식으로 바꿨다. 시작 목록 리셋 이후 '몇 단계가 열렸는지' 계산할 때 오류가 더는 발생하지 않았다.

기본 구조를 잡은 뒤 '언제든 조건이 추가되거나 실패하더라도 흐름이 멈추지 않아야 한다'는 원칙을 세웠다. 성장 트랙과 특별 공간을 각각 검사할 수 있게 로직을 분리하고, 한쪽이 실패해도 다른 쪽이 계속 실행되도록 예외 처리를 나눴다. 새로 열린 마일스톤은 큐에 순서대로 넣어 팝업이 겹치지 않게 했고, 이미 처리한 레시피 ID는 따로 저장해 중복 unlock이나 데이터 꼬임을 피했다. Provider에 재검사 루틴을 넣어 앱을 다시 열 때마다 기존 레시피를 훑고, 조건을 충족하면 바로 반영하게 했다.

마지막으로 초기화 타이밍을 놓치는 이슈가 있었다. 레시피를 저장했음에도 팝업이 뜨지 않는 케이스가 발견되었는데 이는 Provider 사이 콜백을 '조금 뒤에 실행'하는 것으로 예약해 둔 탓이었다. 준비가 끝나기 전에 레시피가 추가되면 언락 검사가 스킵되고 있었다. 콜백을 즉시 연결하고 초기화가 끝났는지 짧게 확인한 뒤 실행하게 바꾸자 같은 문제가 재현되지 않았다.

실시간 피드백: 달성 다이얼로그와 감정 힌트 UX

토끼굴이 열렸다는 사실도 사용자에게 알려야 하니 레시피 저장 직후 BurrowUnlockCoordinator가 조건을 만족하면 즉시 다이얼로그를 띄우도록 했다. 팝업에는 토끼굴 이미지를 크게 보여주며 메시지를 띄웠다.

잠긴 공간에 힌트는 주어야겠다 싶어서 SpecialRoom 카드의 디스크립션 카피를 다듬었다. "누군가를 위한 요리를 만들어보세요..."처럼 테마를 은근히 암시하는 방향으로 바꿨다.

브랜드 일관성은 스플래시·타이포그래피로 부여

토끼굴 테마는 스플래시 화면에도 그대로 녹였다. 앱이 켜지는 동안 백그라운드에서는 필수 리소스 로딩 및 초기 데이터 동기화 등의 준비 작업이 이루어진다. 그 사이 빈 화면 대신 스플래시 이미지를 노출하면 아이덴티티를 효과적으로 전달할 수 있어서 조금 공을 들였다.

앱 테마에 어울리는 느낌의 폰트를 직접 찾아 <Recipesoup> 타이틀과 "감정을 담은 레시피 아카이빙" 각기 다른 폰트를 적용했다. 이미지의 중심에는 요리하는 토끼를 배치하고, 토끼의 성장 여정을 담은 주요 장면들을 냄비에서 피어나는 꿈처럼 구성하여 연결했다. 토끼 일러스트가 흐릿해지지 않게 오버레이를 투명하게 바꿨다. 이제 앱의 시작부터 전체 경험이 하나의 톤으로 연결된 느낌이 들었다.

마무리하며

성장 마일스톤을 32단계로 쪼개 두니 토끼굴을 "한 층씩 파 내려가는" 감각이 살아났다. 레벨마다 이름을 붙여 둔 것도 스토리텔링에 도움이 되는듯하다. 특별 공간을 감정·키워드 조건과 연결해 두니 자연스럽게 감정 스토리를 되돌아보게 되었고, 초기화·재검사 로직을 다시 짜서 언락 로직이 더 견고해졌다. Achievement Dialog와 진행 위젯이 방금 달성한 마일스톤을 바로 안내해 주는 덕분에 사용자가 이를 놓치지 않는 흐름도 유지할 수 있다. 스플래시 화면까지 같은 톤으로 맞추니 앱을 켜는 순간부터 토끼굴 경험이 이어진다. 홈 화면에 토끼굴로 이동하는 CTA 카드를 하나 넣으려다가 뺐는데 레시피 작성을 유도하는 용도로 추후 추가를 고민해야 할 것 같다.

핵심 요약

토끼굴 핵심 성과

• 32단계 성장 여정을 정의해 레벨·이미지·설명을 한 번에 관리
• 감정·태그·키워드 기반으로 언락되는 16개 공간을 설계해 감정 기록 흐름 확보
• 초기화 및 재검사 로직으로 누락·중복·타이밍 오류 정비

UX 강화 포인트

• 마일스톤 달성 시 실시간 팝업과 진행 위젯으로 게이미피케이션 보상 경험 전달
• 특별 공간 언락 조건 힌트, 홈 화면 진행률 위젯으로 다음 목표 느슨하게 제안
• 스플래시·타이포그래피 통해 앱 진입부터 브랜드 톤을 일관되게 유지

다음 이야기, Episode 4 예고

토끼굴 정비도 마무리되었고, 이제 앱 사용 경험이 자연스레 이어지도록 숨을 고를 차례. UI 개선 주간이 다가왔다.

• 빈티지 아이보리 팔레트를 기반으로 화면 톤을 재정리한 과정
• Bottom Navigation과 SafeArea 구조를 손보며 이동 흐름을 매만진 기록
• 감정 메모와 진행 메시지 마이크로카피를 학습자 톤으로 다듬은 방법

다음 편에 계속...

지난 이야기

프롤로그, 에피소드 1편에서는 레시피 앱을 어떤 계기로 만들게 되었는지 그리고 기술 스택과 디자인 테마는 어떻게 정했는지 회고했다.

이번 편에는 실제로 작동하는 첫 버전을 만들었던 과정을 담았다.

MVP 구현의 시작

아침, 커피 한 잔과 함께 노트북을 열었다. 목표는 오늘 안에 '작동하는' 첫 버전 만들기. 먼저 "작동한다"는 게 무엇을 의미하는지 정의하는 것부터가 숙제였다. 내가 정한 기준은 단순했다. 사용자가 감정 메모를 필수 입력값으로 하여 레시피를 저장할 수 있는가? URL이든 사진이든 어떤 입력을 넣어도 AI가 초안을 채워 주고, 필요하면 수동으로 고친 뒤 바로 보관함에 기록되는가? 오류가 나더라도 안내 메시지와 삭제·수정 같은 안전장치가 잘 작동 하는가? 세 가지 최소한의 기준을 충족할 때 이 앱은 '작동한다'고 볼 수 있었다.

프로젝트 셋업

Episode 1에서 정리한 구조를 실제 프로젝트에 옮기는 작업부터 시작했다.

1. Flutter 프로젝트 기반 세팅: 필수 패키지(provider, dio, hive, image_picker) 설치와 iOS 권한 정리, 폴더 구조 점검

lib/
├── config/        # API 설정, 테마 색상
├── models/        # Recipe, Ingredient, Mood
├── services/      # OpenAI, Hive
├── screens/       # 화면들
├── widgets/       # 버튼 같은 공통 요소
├── providers/     # 상태 관리
└── utils/         # 도구들

2. 작업 문서화: CLAUDE.md, ARCHITECTURE.md, PROGRESS.md, TESTPLAN.md 등에 상태 업데이트

• CLAUDE.md: 프로젝트 전체 개요
• ARCHITECTURE.md: 시스템 구조 설명
• DESIGN.md: 디자인 가이드
• PROGRESS.md: 진행 상황 기록
• TESTPLAN.md: 플로우별 테스트 시나리오와 체크리스트
• TESTDATA.md: 감정·태그 조합 샘플 데이터 모음

프로젝트 중후반부터 특히 위 문서들이 큰 힘이 되었다. '왜 이 결정을 했는지'를 남겨 둔 기록 덕분에 다음 단계로 넘어갈 때 흔들리지 않았고, 각 프로세스를 트래킹하기 수월했다. 과거의 나와 대화하는 기분이랄까.

사전 준비, OpenAI API 키와 환경 변수

그 다음으로 한 일은 OpenAI에서 새 API 키를 발급받는 것이었다. 키를 그대로 코드에 넣지 않도록 프로젝트 루트에 .env 파일을 만들고 OPENAI_API_KEY=sk-... 형태로 저장했다. Flutter 쪽에서는 flutter_dotenv로 이 값을 읽어오고, 터미널에서 https://api.openai.com/v1/models 엔드포인트를 호출해 "200 OK"가 떨어지는지 확인했다. 덕분에 이후 앱 코드에서 오류가 나면 내 코드 문제인지, 키나 서버 문제인지 구분할 수 있었다.

데이터 모델 설계와 첫 번째 위기

미리 정한 Recipe 모델 구조(감정 메모 필수, Hive 저장)는 그대로 가져왔다. 이번에는 실제 데이터를 넣어 보며 필수 입력 필드인 emotionalStory가 비어 있으면 저장 단계에서 어떻게 막히는지, 감정 Enum은 잘 연결되는지 검증하는 데 집중했다. 그리고 모델 적용과 동시에 블로그에서 레시피를 끌어오는 스크래퍼를 붙여 첫 실사용 데이터를 만들었다.

OpenAI Service 구현

1) 링크로 가져오기 플로우

• 소스 확보: 여러 차례 테스트를 거쳐 모바일 네이버 블로그를 스크래핑 대상으로 설정했다. PC에 비해 DOM이 단순하고 광고 노이즈가 적어 제목·재료·조리 단계를 안정적으로 추출할 수 있었기 때문이다.
• AI 매핑: 추출한 텍스트를 템플릿에 넣어 chat.completions으로 보내면 title, ingredients, instructions 값이 채워진다.

진행 안내: 레시피 재료 준비중 → 레시피 추출 완료 → AI로 레시피 굽는중 → 작성 완료 메시지를 단계별로 표시해 URL 입력부터 저장까지 흐름이 끊기지 않는지 확인했다.

2) 이미지 분석 플로우

• 전처리: 촬영/앨범 이미지는 1024px·2MB 이하로 압축 후 Base64로 변환해 네트워크 전송 비용과 타임아웃을 줄였다.
• 타입 감지 & 분석: OpenAI 모델이 이미지를 감지해 레시피가 적힌 스크린샷이면 한글 OCR 분석 프롬프트를, 일반 사진이면 음식 분석 프롬프트를 사용하도록 적용했다. 음식 사진이 아니라면 메시지를 띄워 다른 이미지를 넣도록 요청한다.
• 로딩 UX: 분석이 길어질 수 있어 이미지 타입 감지중, AI로 레시피 분석중 같은 메시지를 띄워 사용자가 현재 진행 상태를 알 수 있게 했다.

3) 키워드·재료 기반 빠른 입력

• 퀵레시피 작성하기: 요리 이름 한 줄만 입력하면 텍스트 전용 프롬프트를 활용해 10초 안에 초안을 채워 준다. 최소 입력으로 감정 메모만 보강하면 바로 저장까지 이어지는 흐름이 유지된다.
• 냉장고 재료 입력하기: 사용자가 집에 가지고 있는 재료 리스트를 선택하면 바로 만들 수 있는 요리를 제안하도록 구성했다. 마음에 들지 않으면 다른 메뉴 추천받기도 가능하다. 재료가 부족할 땐 대체 재료까지 AI가 함께 추천해 기록 습관이 끊기지 않게 했다.

4) 에러 핸들링 전략

• 이미지 흐름의 경우 Base64 검증이나 스크린샷 감지가 실패하면 즉시 일반 분석 루틴으로 내려 안전하게 마무리한다. (Base64는 이미지를 텍스트 형식으로 포장하여 안정적으로 전송되도록 돕는 역할)
• 응답이 비거나 네트워크가 불안정하면 최대 3회까지만 재시도하고, 실패 시 안내 메시지를 띄워 수동 입력으로 전환을 유도한다.
• 토큰 오류, 429 Too Many Requests, 500과 같은 에러는 원인별 메시지를 나눠 프록시 작업 시 로그를 볼 때도 바로 식별할 수 있도록 준비했다.

CORS 에러의 등장

AI를 붙여 테스트를 돌리니 콘솔에 아래와 같은 경고가 뜨기도 했다.

Access to XMLHttpRequest at 'https://api.openai.com/v1/chat/completions'
from origin 'http://localhost' has been blocked by CORS policy

웹 빌드에서는 브라우저가 "너 지금 다른 서버에 바로 가려고 하잖아?"라며 보안을 이유로 막아 버린다. Flutter 앱이라도 웹에서 돌리면 이 규칙을 피할 수 없고 API 키를 그대로 노출하는 것도 보안상 위험했다.

당시에는 flutter run -d chrome으로 실행해 두고 Playwright MCP로 자동 테스트 시나리오를 돌리는 중이었다. 크롬 브라우저 안에서 Recipesoup 웹앱을 띄워 놓은 상태였기 때문에 브라우저 보안 정책(CORS)이 적용된 것이다.

당장은 앱 흐름을 완성하는 데 집중하느라 프록시를 손댈 여유가 없었다. 대신 터미널에서 직접 curl을 날려 'API는 정상'인지 확인하고 iOS 시뮬레이터에서 프록시 없이 텍스트 요약과 이미지 분석 플로우가 잘 돌아가는지 다시 체크했다. 프록시 구현은 별도 TODO로 묶어 이후 배포 시점에 적용했다.

참고로 네이티브(iOS·Android)는 CORS에 걸리지 않는다. 그래도 API 키와 호출 흐름을 한 곳에서 관리하고자 추후 브라우저와 앱 모두 프록시를 통하도록 설계했다.

에러 케이스와 대응 요약

• 401 Unauthorized: 프록시를 거치지 않고 호출하다가 Authorization: Bearer <토큰> 헤더를 누락해 로그를 통해 이를 확인하고 다시 넣었다.
• 429 Too Many Requests: OpenAI가 잦은 요청을 막아서 요청 사이에 딜레이를 넣어 2초 쉬게 하고 사용자에게는 "조금 뒤에 다시 시도해 주세요" 토스트를 보여주도록 했다.
• 500 Internal Server Error: OpenAI 쪽이 잠깐 불안정해지면 최대 세 번까지만 다시 호출, 내부 테스트에서는 로그로 남겨 사용자에게는 "잠시 후 다시 시도해 주세요" 정도만 보이게 했다.
• SocketException (오프라인): 인터넷을 끊으면 요청이 아예 나가지 않아서 콘솔 로그로 오프라인 상황을 남기고, 사용자가 AI 대신 직접 입력으로 흐름을 이어가도록 했다.
• CORS (웹 빌드): 크롬에서만 막히는 문제로 프록시 구축(우리 서버 → OpenAI)은 별도 TODO로 넘겼다.

AI 응답을 어떻게 보여줄까

디자인 테마는 미리 정해두었기에 UI/UX는 빈티지 톤과 폰트, 카드 스타일을 실제 화면에 입히는 과정이었다. 목표는 자동으로 채워진 데이터와 사용자가 직접 적은 메모가 자연스럽게 어우러지게 하는 것. 두 가지가 섞여도 '기록하는 공간'이라는 느낌이 깨지지 않도록 하고자 했다.

AI 기능을 통해 분석된 레시피는 재료, 소스, 조리 방법이 자동으로 분류되어 레시피 작성 화면으로 넘어오게 했다. 조리 단계를 보여줄 때에는 1. … 형식으로 넘버링해 가독성을 높였다. <레시피 작성> 버튼을 누르면 매핑된 값이 필드 입력란에 그대로 채워진다. 사용자는 감정 메모나 디테일만 다듬고 바로 저장할 수 있다.

분석이 실패하면 안내 메시지를 띄워 수동 입력으로의 전환을 유도했다. '자동과 수동 사이를 어떻게 매끄럽게 오가게 할 것인가'가 이 단계의 핵심이었다.

CRUD 구현과 Hive 재확인

기술 스택을 정할 때 로컬 우선을 기준으로 해서 Hive를 골랐고 그 선택은 이 단계에서 빛을 발했다. put 한 줄로 박스에 저장한 뒤 곧바로 리스트가 갱신되는 걸 보고 로컬 DB 구현은 적절한 선택이었음을 실감했다. 테이블 스키마를 짜고 생성할 필요도 없었고 마이그레이션 걱정도 덜었다. 덕분에 CRUD 테스트를 하는 동안 작업이 늘어지지 않고 스무스하게 진행되었다.

삭제 기능은 한 번 더 고민했다. 개인적인 기록을 아카이빙하는 앱에서 사용자가 실수로 데이터를 삭제하도록 방치하면 부정적인 경험만 남을 것이다. 이러한 이유로 MVP에 꼭 넣어야 하는 기능이 아님에도 "정말 삭제할까요?" 다이얼로그를 추가했다. 실수 방지 장치는 앱의 특성상 꼭 필요한 장치였다.

하루 타임라인 정리

• 아침 | OpenAI 키 발급, .env 정리 및 간단한 API 호출로 응답 확인
• 오전 | Flutter 프로젝트 생성과 폴더 구조 정리, 필수 패키지 설치, 작업 문서 업데이트
• 이른 오후 | 블로그 스크래핑 및 AI 요약 흐름 점검, 첫 이미지 분석 성공, JSON 파싱 로직 정리
• 늦은 오후 | 401/429/500/오프라인/CORS 테스트, 사용자 메시지 다듬기, 프록시 TODO 분리
• 저녁 | 빈티지 톤 UI 적용, 자동 채워진 필드와 수동 입력 Fallback 동작 확인
• 밤 | CRUD 동작 최종 점검, 삭제 다이얼로그 추가, QA 체크리스트 작성

중간중간 다른 작업을 먼저 할까, 하는 유혹이 들었지만 '오늘의 목표는 작동하는 흐름 만들기'라는 걸 계속 되새겼다.

밤 11시, 마지막 테스트를 마쳤다.

• 블로그 URL 스크래퍼와 요약 기능도 기대대로 잘 돌아갔다.
• 사진을 찍으면 AI가 분석해주고, 필요하면 금방 고쳐 저장할 수 있었다.
• AI 사용 시 단계별 프로그레스 메시지도 끊김 없이 이어졌다.
• 레시피가 저장된 보관함에서 내용을 볼 수 있고, 수정하고, 삭제할 수 있다.
• 레시피 기록 구조와 빈티지 테마 디자인이 기능에 잘 입혀졌다.

이렇게 최소한의 기능을 붙인 첫 MVP 버전이 완성되었다.

마무리하며

이번 에피소드까지의 작업을 통해 네 가지를 확인했다.

첫째, '최소한'은 검증에 꼭 필요한 것만 남기는 일. 이번 과제는 "사용자가 감정을 담은 레시피를 저장할 수 있는가?"였기에 당장 필요하지 않은 기능은 뒤로 미뤘다. 잘라내는 것도 연습이 필요하다.

둘째, 초보라면 기술 선택은 쉽고 빠른 길로. Flutter·Hive·Provider는 내 수준에서 최대한 빠르게 구현할 수 있는 조합임을 다시금 깨달았다. 개발에 대해 잘 알지 못하는 상태로 1인 작업 시 '최고'의 아키텍처를 욕심내는 건 사치.

셋째, 에러 케이스를 통한 배움. CORS 덕분에 '클라이언트에서 바로 키를 쓰면 안 된다'는 사실을 다시 한 번 확인했다. MVP는 기능을 만드는 것 못지않게 문제를 빠르게 찾아서 대응하는 과정에 가깝다는 생각도 든다.

마지막으로, 결정했던 기준은 크리티컬한 오류가 있는 게 아니라면 유지. emotionalStory를 필수 필드로 묶어 둔 선택은 번거롭지만 앱의 방향을 지키는 역할을 하므로 계속 이어 가기로 했다.

이번 에피소드 핵심 요약

• 작업 사항: 블로그 요약과 이미지 분석 AI 연동, 자동 채움·수동 편집이 가능한 레시피 작성 화면 구현, CRUD 전 흐름에 삭제 확인·에러 메시지 같은 안전장치 마련
• 기술/운영: OpenAI 연동 전 .env·curl로 통신을 확인하고, 401·429·500·오프라인·CORS 등 에러 대응, 프록시 구축은 다음 단계로 이관

단거리 달리기가 끝났으니 이제 이 앱이 계속 쓰이도록 동기부여를 할 차례다.

다음 이야기, Episode 3 예고편

• 감정 기록을 꾸준히 이어가게 하는 '토끼굴' 마일스톤 설계를 어떻게 시작했는지
• Claude와 ASCII 시안으로 토끼굴 UI를 잡고 32단계 성장 여정을 만든 과정
• burrow_unlock_service.dart 재작성과 QA에서 터진 보상/레벨 버그를 해결한 기록

다음 편에 계속..

프롤로그 이야기

이전 글에서는 퇴사 후 머릿속에만 있던 아이디어를 실제로 구현하기로 결심한 배경을 다뤘다. 문예창작을 전공하고 콘텐츠 마케팅을 해온 내가 왜 앱을 만들기로 했는지, MVP 범위를 어떻게 좁혔는지, 그리고 "요리의 감정과 맥락을 기록하는 공간"이라는 컨셉이 어떻게 정리됐는지 이야기했다.

이번 Episode 1에서는 본격적으로 기술 스택을 선정하고 초기 설계를 진행한 과정을 다룬다.

최소한, 필수적인

기획 문서를 쓰면서 이 앱에 꼭 필요한 기능 4가지가 자연스럽게 정리됐다.

1. 레시피 작성 및 감정 메모 기록

"요리 방법뿐만 아니라 왜 만들었는지, 누구를 위해 만들었는지 함께 기록하기."

• 작성 화면에 emotionalStory 필드 추가
• 감정 상태를 Enum 타입으로 정의
• #파티 #혼밥 #기념일 등 감성 중심 태그 입력

2. AI 분석 및 자동 기록

"필요에 따라 AI로 분석하거나 레시피 추천받기."

• 기능과 토큰 비용을 고려해 AI 모델 선정
• 클라이언트는 프록시 토큰만 사용
• 재료, 소스, 조리법 분기 프롬프트와 모델 작업

3. 마일스톤과 게이미케이션

"요리 견습생 토끼 캐릭터가 성장하는 감성 게임적 요소로 동기부여하기"

• 레시피 저장 진행률 계산 → 레벨업·언락 팝업
• 감정 메모·태그 활용한 마일스톤 조건 정의
• 진행 상태 로컬 저장, 오프라인에서 여정 지속

기술 스택 선정 이유

왜 Flutter를 선택했을까?

비개발자가 기술 스택을 선택하는 과정은 쉽지 않다. 나는 바이브 코딩 강의에서 추천받은 플러터+하이브 구조를 택했다.(툴 후기는 여기) 그리고 다른 옵션들과 어떤 차이점이 있는지 궁금해져서 더 알아봤다. 우선 Flutter부터.

1. Hot Reload로 1초 내 변경사항 확인
2. 크로스 플랫폼으로 iOS/Android 동시 개발
3. Dart 단일 언어로 학습 부담 최소화
4. 풍부한 위젯과 패키지

기술 스택 비교

비교해보니 더 적합했던 Flutter

• 1인 개발에 최적화: iOS/Android 동시 개발
• 빠른 MVP: 핫 리로드로 시행착오 시간 단축
• 풍부한 생태계: pub.dev에 5만+ 패키지 활용

왜 Hive일까?

하이브는 로컬에 데이터를 JSON으로 저장하는 NoSQL 구조라 직관적이고 오프라인 우선 설계에 최적화되어있다. 한 마디로 초보자가 DB 구축하기에 진입장벽이 낮음!

1. Flutter 공식 추천 로컬 DB 중 하나
2. iOS/Android에서 모두 작동
3. 데이터가 JSON으로 저장돼 구조 이해 쉬움
4. 복잡한 테이블 설계, 마이그레이션 고민 불필요

데이터 베이스 비교

비교해보니 더 적합했던 Hive

Firebase는 사용자 계정이 없는 로컬 기반 MVP에 어울리지 않고 플러터 연동하기에 SQLite보다 Hive가 적합했다. 설치 5분 만에 끝나고 NoSQL 구조라 스키마 변경도 자유로웠다.

결론, 초보자에게 추천하는 Flutter + Hive 조합

• 빠른 프로토타이핑 가능
• 로컬 우선 앱 만들기 최적화
• 초보자도 비교적 쉽게 접근 가능한 스택

실제로 개발하면서 이 조합의 장점을 체감했다. 특히 중간에 데이터를 클라우드화하는 시도를 했을 때 Hive Box에 데이터를 저장하는 코드 구현이 비교적 간단한 편이었음을 깨달았다. 디버깅하느라 예상보다 시간을 많이 썼지만 그 시행착오 덕분에 구조를 더 잘 이해하게 됐다.

그리고 앱 심사 제출 시 꼭 챙겨야 할 것! 지원 및 개인정보처리방침 같은 정책 문서 작업 시 와닿았던 장점도 적어본다.

로컬 데이터베이스 채택 시 운영과 정책상 메리트

• 운영 비용 및 유지보수 리소스 축소
• API 보안 강화 및 상태 처리 간소화
• 앱스토어 심사 정책 관련 작업 용이

이후 클라우드 백업이나 알림을 붙일 때는 필요한 정책·보안 체크리스트를 준비해야한다.

AI 기능은 필수

AI 기능은 요즘 서비스들의 핵심 경쟁력 중 하나다. 나는 특히 블로그 레시피를 요약해서 나만의 킥을 정리해두고 싶은 니즈가 있었다. 그 외에 사진 분석이나 키워드로 레시피 생성 등도 필요했다. 직접 API 호출당 예상 비용과 AI 모델 성능을 비교해봤을 때 비전 기능까지 있으면서도 토큰 비용이 합리적인 모델은 4o-mini여서 이걸로 결정했다.

1. GPT-4o-mini: 텍스트, 이미지 분석 가능
2. 한국어 지원: OCR도 되고 레시피 분석도 무난
3. 빠른 응답: 대기 시간 3-5초 정도로 길지 않음

API key 보안

설계 및 개발 단계에서는 로컬 env로 기능 구현 위주로 테스트했고, API 기능 완료 후 프록시 설정으로 전환했다.

사용자 앱 → 프록시 서버 (API 키 보관) → OpenAI API

• 앱에는 임시 토큰만 저장, API 키는 서버에만
• 릴리즈 빌드 전 .env 파일 제거 필수 체크

처음에 다른 방법도 시도해보았는데 그건 더 돌아서 가는 길이었다. 새로운 교훈을 얻으며 보안상 필수였던 과정도 마무리되었다.(에피소드 5정도에서 다룰 예정)

프록시가 필수인 이유
- 앱에 직접 OpenAI API Key를 넣으면 리버스 엔지니어링으로 키가 노출됨
- 악의적 사용자가 APK/IPA 파일을 디컴파일해서 키를 추출할 수 있음
- 추출된 키로 무제한 API 호출 시 예상치 못한 과금 폭탄 가능

초기 설계 과정

기획 방향에 맞춘 Recipe 모델

단순한 메모장이 아닌 아카이빙 앱을 만들고자 했던 방향에 맞춰 레시피 작성 화면을 구성했다.

class Recipe {
  String id;
  String title;                  // 요리 이름
  String emotionalStory;         // 이게 핵심! 왜 만들었는지의 이야기
  List<Ingredient> ingredients;  // 재료들
  List<String> instructions;     // 만드는 방법
  String? localImagePath;        // 사진 (있으면)
  List<String> tags;             // #태그들
  DateTime createdAt;            // 언제 만들었는지
  Mood mood;                     // 그때의 감정
  int? rating;                   // 맛있었는지 (별점)
}

• emotionalStory 레시피 메타데이터로 감정 메모 저장
• Mood 감정 상태를 8가지 Enum으로 구조화 (기쁨, 슬픔, 평온...)

감정의 포맷화

텍스트로 "기쁨", "슬픔" 저장하면 오타가 날 수 있어서 나중에 통계 낼 때 불편할 것 같았다. 감정은 Mood enum으로 고정하고 아이콘 키·국문·영문 이름을 함께 저장하도록 설계해 UI와 검색에서 동일한 값을 재사용했다.

• 감정 아이콘 키도 저장돼 UI에서 바로 사용
• 이후 특정 감정의 레시피만 모아볼 때 편리
• 오타 걱정 없음!

컨셉 덕분에 빠르게 정한 디자인

아이보리 & 올리브 그린 테마 선택

내가 만들고 싶었던 건 조용히 기록하는 공간이었기에 강렬한 색보다 차분한 톤이 어울리겠다는 생각이 들었다. 최종적으로 아이보리와 올리브의 조합을 선택했다.
그리고 아이템 초기부터 잡아두었던 컨셉 키워드로 '아날로그, 동화적인, 빈티지 레시피북, 햇살이 내리쬐는 정원의 채소와 야채' 등으로 있었고, 레퍼런스 이미지들까지 수집해 폴더링해두었던 상태여서 빠르게 정리됐다.

primaryColor: #8B9A6B      // 연한 올리브 그린
backgroundColor: #FAF8F3   // 아이보리 백그라운드
cardColor: #F8F6F1         // 따뜻한 아이보리
accentOrange: #D2A45B      // 빈티지 오렌지 (포인트)
textPrimary: #2E3D1F       // 다크 올리브 (텍스트)

화면 구조, 고민될 땐 레퍼런스를

바텀 네비게이션을 4개로 할지, 5개로 할지 고민했다. 프로토타입으로 5개 탭을 구현해놓고 "모바일 특성상 탭이 너무 많은가?"싶어서 다른 분야의 평소 자주 쓰는 앱들을 리서치해보았다. 평균 3-5개 정도의 탭을 사용하고 있어서 나는 아래처럼 정했다.

5개 탭 Bottom Navigation

├── 홈 (최근 레시피)
├── 검색 (감정/태그로 찾기) *추후 토끼굴로 대체
├── 통계 (요리 패턴 분석)
├── 보관함 (폴더별 정리)
└── 설정 (백업/설정)

스켈레톤 수준으로 아직 뼈대만 잡아둔 상태. 이후 검색 탭은 보관함에 통합시키고 '토끼굴'이라는 마일스톤 기능으로 대체했다.

FAB 버튼, 스피드 다이얼 메뉴

빈티지 오렌지 색으로 눈에 띄게 만들었다. 제일 많이 쓸 "레시피 작성" 버튼이니까 확 보이게 해뒀다. 그리고 어느 화면에서든 FAB 버튼이 최상위 레이어에 자리하도록 설정했다. 초기에는 아래처럼 4가지 스피드 다이얼 메뉴가 있었고 이후 냉장고 재료 입력 기능 등을 붙여서 최종 5개가 되었다.

• 퀵레시피 작성하기
• 링크로 가져오기
• 사진으로 가져오기
• 나만의 레시피 작성하​기

마무리하며

아이디어 단계부터 컨셉을 분명하게 정해두니 기술 스택 선정이든 디자인이든 빠르게 결정할 수 있었다. 범위를 제한하고 필요한 만큼만 작업했기에 포기하지 않고 앱을 완성할 수 있었다. 기획 단계는 기존에 머릿속에 구상해둔 게 있다 보니 나름 스무스하게 흘러갔다.

하지만 다음 에피소드에 나올 개발 단계부터는 막히는 부분이 많았다. 그래도 모든 시행착오 끝에 앱이 실제로 작동하고, 앱스토어에 등록된 화면을 봤을 때의 뿌듯함은 이루 말할 수 없었다.

이번 프로젝트는 '일단 출시'가 목표였지만, 향후에는 이 앱이든 다른 서비스든 실제 사용자 반응을 기반으로 수익화 방향도 천천히 탐색할 계획이다.

이번 에피소드 핵심 요약

MVP 핵심 기능

1. 감정 메모와 함께 레시피 기록
2. AI 요약 및 분석
3. 자유로운 재료·방법 입력 + 태그

기술 스택

• Flutter: 크로스 플랫폼, 빠른 개발
• OpenAI API: GPT-4o-mini
• Hive: 심플한 NoSQL 로컬 저장
• Provider: 최대한 심플한 상태 관리
• 로컬 DB: 사용자 데이터는 기기에만

디자인

• 빈티지 아이보리 테마: 따뜻하고 감성적
• Bottom Navigation: 5탭 구조
• 감정 중심 UI: 이모지, 색상 팔레트

그렇게 며칠만에 앱의 첫 버전을 완성했다.

다음 이야기, Episode 2 예고편

"앱이 작동하네..? 이게 진짜 내가 만든 거 맞아...?"

• 24시간 개발 타임라인: 새벽부터 밤까지
• OpenAI API 연동: 요리 사진도 분석!
• 레시피 CRUD: 작성/저장/목록/삭제까지
• 문서 작성의 힘: 과거의 나와 대화하는 기분

가장 중요한 부분은 AI 연동 과정이었다.

다음 편에서 계속...