코딩부터 배포까지 쉬워진 시대, 제품의 승부는 여전히 코딩 전에 갈린다

저녁 자리에서 들은 이야기

오랜만에 지인과 저녁을 먹었다. 몇 년째 인공지능 이론과 실제 활용 사례를 유튜브로 나누고 있는 분이다. 이야기 중에 내가 쓴 《AI로 만들기: 비개발자를 위한 실전 가이드》가 화제에 올랐고, 그러다 자신이 멘토링한 한 사람의 이야기를 들려줬다.

처음에는 VS Code를 설치하는 것부터 막혀서 옆에서 붙잡고 도와줘야 했다고 한다. 그런데 그 고비를 넘기자 며칠 만에 자기가 생각한 아이디어를 서비스 형태로 만들어 냈다. 문제는 그다음이었다. 만들기는 했는데 남들이 쓸 수 있게 내보내는 방법을 모르겠다는 것이었다.

나는 배포는 이제 쉬워졌다고 답했다. 요즘 도구 중에는 배포까지 대신해 주는 것도 있고, 어떤 도구를 쓰든 배포 명세를 정리해 AI에게 맡기면 직접 처리해 주거나 환경에 맞는 자세한 안내를 내놓는다.

돌아오는 길에 그 대화가 계속 남았다. 그가 막혀 있다고 느낀 지점은 사실 곧 풀릴 문제였다. 며칠이면 아이디어가 서비스가 되고, 배포까지 도구가 대신해 주는 시대에 진짜 병목은 그보다 훨씬 앞에 있다. 이 글은 그 앞 단계에 대한 이야기다.

출시는 쉬워졌다

AI 코딩 어시스턴트의 발전으로 웹사이트나 모바일 앱을 만드는 일은 놀랄 만큼 쉬워졌다. 만들고 싶은 서비스를 자연어로 설명하면 AI가 화면을 설계하고, 코드를 작성하고, 데이터베이스를 연결하고, 오류를 수정한다. 이제는 코딩뿐 아니라 빌드와 배포까지 하나의 흐름 안에서 처리할 수 있다.

예전에는 서비스를 배포하려면 먼저 VS Code에 Claude Code나 Codex 같은 도구를 설치하거나, Cursor를 쓰기 위해 Docker 컨테이너를 구성해야 했다. 이후 프로젝트 환경을 설정하고, 배포 스크립트를 작성하고, AWS나 GCP 같은 클라우드에 직접 올려야 했다. 개발자에게는 익숙한 과정이지만, 개발 경험이 많지 않은 사람에게는 아이디어를 실제 URL이나 앱으로 공개하기까지 넘어야 할 문턱이 많았다.

지금은 상황이 크게 달라졌다. 많은 AI 개발 서비스가 코딩부터 빌드, 배포까지 한 번에 처리한다. Kimi나 Manus 같은 도구를 쓰면 웹 서비스의 URL을 바로 만들거나 모바일 앱 패키지를 빌드하는 일까지 한 흐름으로 끝난다. 앞으로 이런 방향은 더 강해질 것이다. 개발 환경을 직접 구성하고 배포 인프라를 관리하는 일은 점점 눈에 보이지 않게 되고, 사용자는 자연어로 원하는 결과를 설명하는 데 집중하게 될 가능성이 크다.

그렇다면 이제 아이디어만 있으면 되는가. 최근 화제가 된 사례를 하나 살펴보자.

2024년 5월에 출시된 'Cal AI'는 음식 사진을 찍으면 칼로리와 영양 정보를 추정해 주는 앱이다. 만든 사람은 당시 열일곱 살 고등학생이던 잭 야데가리(Zach Yadegari)였다. 이 앱은 앱 스토어 건강·피트니스 분야 상위권에 올랐고, 2025년 한 해 약 3천만 달러의 매출을 올린 것으로 보도됐다. 이후 오랜 경쟁자였던 MyFitnessPal에 인수됐다. CNBC 보도

여기서 주의해서 볼 대목이 있다. 야데가리는 흔히 소개되는 것처럼 'AI에게 시켜서 앱을 만든 비개발자'가 아니었다. 그는 일곱 살부터 코딩을 했고, 중학생 때 파이썬과 C#을 익혔고, 고등학교 1학년 때 만든 게임 사이트를 약 10만 달러에 팔았다. 기술적으로는 또래에서 최상위에 가까운 사람이었다.

그런데도 그의 성공 요인으로 꼽히는 것은 코딩 실력이 아니다. 그는 자기 문제에서 출발했다. 몸을 만들려고 칼로리를 기록하기 시작했지만 기존 앱에 음식을 일일이 입력하는 일이 번거로워 사흘 만에 그만뒀다. 그 불편이 제품의 출발점이 됐다. 그리고 출시 후에는 건강·피트니스 분야의 작은 인플루언서들과 협업하는 방식으로 사용자를 모았다. 코딩을 가장 잘하는 사람의 승부도 결국 코딩 밖에서 났다는 뜻이다.

이런 사례를 "AI에게 아이디어만 말하면 된다"는 뜻으로 읽어서는 안 된다. 앱 마켓에 등록되는 앱의 수는 계속 늘고 있지만, 등록 자체는 성공의 증거가 아니다. 새로 올라오는 앱 가운데 상당수는 의미 있는 다운로드나 리뷰를 얻지 못한 채 사라진다. 경쟁에서 이긴 사례의 공통점은 코드를 빨리 작성했다는 데 있지 않다. 특정 사용자의 절실한 문제를 발견하고, 짧은 시간 안에 첫 가치를 전달하며, 반응을 보고 제품을 고쳐 나갔다는 데 있다.

숙련된 개발자도 마찬가지다. GitHub의 2022년 연구에서는 HTTP 서버를 작성하는 특정 과제에서 GitHub Copilot을 쓴 개발자들이 그렇지 않은 개발자보다 작업을 55% 빠르게 끝냈다고 보고했다. 다만 이것은 잘 정의된 하나의 과제에 대한 결과이지, 제품 개발 전체가 그만큼 빨라진다는 뜻은 아니다. 약 5천 명의 기술 종사자를 조사한 2025년 DORA 연구도 비슷한 결론에 가깝다. AI는 좋은 조직과 개발 관행을 대체하기보다, 이미 있는 역량을 증폭하는 도구에 가깝다는 것이다. GitHub 2022 연구, 2025 DORA 보고서

문제는 만들기 쉬워진 만큼 비슷한 서비스도 빠르게 늘어난다는 점이다. 새로운 아이디어라고 생각해 검색해 보면 이미 유사한 앱이 여러 개 나와 있다. 여기에 챗봇을 붙이고, 대시보드를 추가하고, 디자인을 조금 바꾸는 것만으로는 선택받기 어렵다.

그래서 지금 더 중요한 질문은 이것이다.

무엇을 만들 수 있는가가 아니라, 누구의 어떤 문제를 왜 이 방식으로 풀어야 하는가?

AI는 명세가 주어지면 빠르게 코드를 작성하고, 환경을 구성하고, 서비스를 배포한다. 그러나 그 명세가 실제 사용자의 문제를 반영하는지, 사람들이 그 문제를 풀기 위해 시간이나 돈을 쓸 의향이 있는지, 이미 있는 서비스보다 나은 이유가 무엇인지는 대신 정해 주지 못한다.

"일단 만들어서 던져보면 되지 않나"

여기까지 읽고 이런 반론이 떠오를 수 있다. 어차피 만드는 비용이 싸졌으니 오래 고민하기보다 빨리 만들어 시장에 던지고 반응을 보는 편이 더 정확한 검증 아닌가. 실리콘밸리의 오랜 조언이기도 하다. 완벽한 계획보다 형편없는 첫 버전이 낫다는 말은 지금도 유효하다.

절반은 맞는 말이다. 다만 두 가지 조건이 붙는다.

첫째, 던져서 얻는 신호가 읽을 수 있는 신호여야 한다. 만드는 비용이 싸진 만큼 던져지는 제품의 수도 늘었다. 아무도 쓰지 않는 결과가 나왔을 때 그것이 문제를 잘못 골랐다는 뜻인지, 문제는 맞는데 발견되지 못했다는 뜻인지, 발견은 됐는데 첫 경험이 나빴다는 뜻인지 구분할 수 없다면 그 실험은 아무것도 알려 주지 않는다. 무엇을 확인하려고 던지는지 정하지 않으면 빠른 출시는 검증이 아니라 추측의 반복이 된다.

둘째, 되돌릴 수 있는 실수인지 따져야 한다. 도구성 앱은 첫 버전이 엉성해도 다음 버전에서 만회할 수 있다. 그러나 감정 기록처럼 민감한 데이터를 다루는 제품은 다르다. 한 번 불쾌하거나 부적절한 응답을 받은 사용자는 대체로 돌아오지 않는다. 개인정보를 잘못 처리한 설계는 나중에 고쳐도 이미 나간 데이터를 되돌리지 못한다.

그래서 이 글은 오래 기획하자는 이야기가 아니다. 무엇을 확인하려는지 정하고 던지자는 이야기에 가깝다. 뒤에서 제안하는 검증 방법도 대부분 며칠이면 끝나는 것들이다.

기능 명세보다 먼저 필요한 '사용자 문제 명세'

서비스를 기획할 때는 흔히 기능부터 적는다.

• 이메일과 소셜 계정으로 로그인한다.
• 음성으로 내용을 입력한다.
• AI가 입력 내용을 분석한다.
• 결과를 차트로 보여준다.
• 매일 알림을 보낸다.
• 웹 서비스 URL을 만들고 모바일 앱 패키지를 빌드한다.

그러나 이것은 사용자가 원하는 결과가 아니라 제품이 제공할 기능 목록이다. 기능을 자세히 적었다고 좋은 제품 명세가 되지는 않는다. 게다가 AI가 코딩부터 배포까지 처리하는 시대에는 기능 목록을 구현하는 일 자체가 쉬워졌으므로, 기능 명세만으로 차별화하기는 더 어려워졌다.

코딩 전에 먼저 써야 하는 것은 기능 명세가 아니라 문제 명세다. 이 글에서는 이를 '사용자 문제 명세'라고 부르겠다. 여기에는 다음 질문이 들어가야 한다.

예를 들어 "감정 일기 앱을 만들겠다"는 것은 아이디어일 뿐이다. 사용자 문제 명세는 이보다 구체적이어야 한다.

감정이 크게 흔들리는 순간에는 긴 글을 쓸 여유가 없지만, 나중이 되면 무슨 일이 있었고 왜 그렇게 반응했는지 기억하기 어렵다. 기존 감정 기록 앱은 감정을 선택하고 저장하는 데서 끝나는 경우가 많다. 사용자는 그 순간을 빠르게 붙잡고, 감정 이면의 생각과 욕구와 행동 충동을 차분히 살펴본 뒤, 후회할 행동 대신 지금 할 수 있는 한 가지 행동을 고르고 싶어 한다.

이렇게 문제를 정의하면 필요한 기능도 달라진다. 감정 선택 화면보다 빠른 순간 기록, 음성 입력, 단계적인 질문, 성급한 해석을 피하는 대화 방식, 행동 선택 가이드가 더 중요해진다.

1. 아이디어를 기능이 아닌 '변화'로 설명한다

좋은 기획은 "무엇을 제공할 것인가"보다 "사용자에게 어떤 변화가 일어날 것인가"에서 출발한다.

감정 일기 앱의 목적은 이렇게 쓸 수 있다.

사용자가 일상의 감정을 부담 없이 기록하고, 처음 떠오른 감정만으로 성급하게 결론 내리지 않도록 돕는다. 감정과 함께 나타난 생각, 신체 반응, 행동 충동, 욕구와 가치를 살펴보고, 자신과 타인에게 해가 적은 다음 행동을 고르도록 안내한다.

여기에는 중요한 관점의 변화가 있다.

앱의 목적은 부정적인 감정을 없애고 긍정적인 감정으로 바꾸는 것이 아니다. 분노, 불안, 슬픔, 죄책감 같은 감정도 상황과 필요를 알려 주는 신호일 수 있다. 중요한 것은 감정을 억누르는 일이 아니라, 감정이 곧바로 행동을 지배하지 않도록 돕는 일이다.

감정은 신호이지 명령이 아니다. 감정은 존중하되, 행동의 방향은 사용자가 고른다.

이 한 문장이 제품의 기능, AI의 말투, 추천 방식, 안전 원칙을 결정하는 제품 철학이 될 수 있다.

2. 서비스가 다루는 분야의 이론과 방법론을 조사한다

LLM을 붙였다고 서비스가 전문성을 갖는 것은 아니다. 범용 LLM은 그럴듯한 말을 만들어 내지만, 서비스가 따라야 할 일관된 관점과 절차를 대신 세워 주지는 않는다.

감정 앱을 만든다면 먼저 감정에 관한 이론을 조사해야 한다. 감정은 하나의 원인으로 생기지 않는다. 상황에 대한 해석, 과거 경험, 신체 상태, 관계, 문화, 학습된 반응, 충족되지 않은 욕구가 함께 작용할 수 있다.

그러니 사용자의 짧은 기록만 보고 AI가 "이 감정은 어린 시절의 경험 때문입니다"라고 원인을 단정해서는 안 된다. 앱이 할 일은 진단이 아니라 탐색을 돕는 것이다.

감정 일기 앱에는 다음 접근을 구분해 적용할 수 있다.

• 인지행동치료(CBT) 는 사건 자체와 그 사건에 대한 해석을 구분하도록 돕는다. "그 사람이 답하지 않은 것은 사실이지만, 나를 싫어한다는 것은 지금 내가 한 해석일 수 있다"는 식으로 생각을 검토한다.
• 마음챙김 기반 접근은 감정을 즉시 고치려 하기보다 지금 나타나는 생각, 감정, 신체 반응을 판단하지 않고 알아차리도록 돕는다.
• 수용전념치료(ACT) 는 불편한 감정이 남아 있더라도 자신이 중요하게 여기는 가치에 맞는 행동을 고르도록 돕는다.
• 감정 세분화(Emotional Granularity) 는 "기분이 나쁘다" 대신 실망, 서운함, 불안, 수치심, 억울함처럼 경험을 더 구체적으로 구분하는 능력이다. 연구에서는 높은 감정 세분화가 여러 긍정적 심리 결과와 관련된 것으로 보고되지만, 이를 인과관계로 단정할 수는 없다. 관련 연구

이 이론들을 한꺼번에 적용할 필요는 없다. 사용자의 상태와 목적에 따라 다른 탐색 경로를 제공하는 편이 낫다.

예를 들어 앱은 이렇게 물을 수 있다.

지금은 이 생각이 사실인지 함께 살펴보고 싶은가요? 결론을 내리기 전에 몸과 감정을 잠시 진정시키고 싶은가요? 불편한 감정이 남아 있더라도 지금 할 수 있는 행동을 찾고 싶은가요?

첫 번째는 CBT에, 두 번째는 마음챙김에, 세 번째는 ACT에 가깝다. 사용자를 진단해 치료법을 배정하는 방식이 아니라, 지금 필요한 도움을 사용자가 직접 고르게 하는 방식이다.

이론 조사는 기능을 어렵게 만들려는 과정이 아니다. 잘못된 가정을 제품에 넣지 않으려는 과정이다.

3. 사용자가 지금 어떻게 버티고 있는지 조사한다

진짜 경쟁 상대는 다른 앱만이 아니다. 메모장, 종이 일기, 친구와의 대화, 음성 메모, 상담사에게 받은 기록지, 그리고 아무것도 하지 않고 참는 행동까지 모두 기존 대안이다.

감정 기록과 관련된 온라인 커뮤니티를 살펴보면 반복되는 요구가 보인다.

• 감정이 변할 때마다 기록하고 싶지만 매번 긴 글을 쓰기 어렵다.
• 기록을 시작해도 며칠 후에는 잊거나 귀찮아서 중단한다.
• 단순한 차트보다 왜 그런 감정이 생겼는지 이해하고 싶다.
• 명상이나 긍정 문구만 반복 추천하는 앱은 부담스럽다.
• 민감한 감정 기록이 어떻게 저장되고 쓰이는지 불안하다.

한 사용자는 상담을 위해 시간대별 감정과 활동을 기록할 간단한 도구를 찾고 있었고, 다른 사용자는 지나치게 치료적이거나 동기부여 문구 중심이 아니면서 실제로 내면에서 무슨 일이 일어나는지 이해하게 해 주는 앱을 원한다고 적었다. 감정 기록 앱이 실패하는 이유는 기능 부족보다 기록 습관이 오래가지 않기 때문이라는 의견도 눈에 띈다. 시간대별 감정 기록 사례, 사용자 요구 사례

다만 커뮤니티 글 몇 개는 시장 수요를 입증하는 자료가 아니다. 어디까지나 문제 가설을 발견하는 질적 신호다. 실제 수요는 인터뷰와 행동 관찰, 프로토타입 사용, 결제로 다시 확인해야 한다.

4. 경쟁사의 기능이 아니라 '성공 방식'을 분석한다

경쟁사 조사는 기능 목록 비교로 끝나서는 안 된다. 어떤 사용자를 대상으로 하고, 어떤 순간에 쓰게 만들며, 첫 사용에서 어떤 가치를 경험하게 하고, 다시 돌아오게 만드는 이유가 무엇인지를 봐야 한다.

대표적인 감정 기록 앱인 How We Feel은 색상으로 구성된 감정 매트릭스를 통해 사용자가 더 구체적인 감정 단어를 고르게 한다. 감정과 함께 수면, 운동, 건강 정보를 기록해 시간에 따른 패턴도 볼 수 있다. 2026년 9월 1일 기준 미국 Apple App Store에는 4.9점, 약 2만 9천 개의 평가가 표시된다. How We Feel App Store

여기서 배울 점은 디자인이 예쁘다는 것이 아니다.

• 긴 문장을 쓰지 않아도 감정을 고를 수 있다.
• 색상과 감정 단어를 연결해 감정 탐색의 부담을 낮춘다.
• 기록에서 끝나지 않고 대처 방법을 배울 수 있게 한다.
• 예일대 감성지능센터와의 협업으로 이론적 신뢰를 전달한다.

그런데 경쟁 구도를 볼 때 더 중요한 사실이 하나 있다. How We Feel은 영리 기업이 아니라 기부로 운영되는 비영리 프로젝트다. 데이터도 기본적으로 사용자 기기에 저장하고, 연구 목적의 익명 전송은 사용자가 직접 동의한 경우에만 이뤄진다고 밝히고 있다. 다시 말해 이 경쟁자는 애초에 이 앱으로 돈을 벌 필요가 없다. 앞으로도 무료일 가능성이 높고, 프라이버시를 마케팅이 아니라 구조로 지킬 수 있다.

이 사실을 모르고 "무료 감정 기록 앱과 기능으로 경쟁하겠다"는 계획을 세우면 출발부터 어긋난다.

Reflectly는 AI 기반 질문, 감정 인사이트, 홈 화면 위젯, 습관 유지 장치를 강조한다. 같은 시점 미국 Apple App Store에는 4.6점과 약 8만 2천 개의 평가가 표시된다. Reflectly App Store

다만 평점은 만족의 신호일 뿐 유지의 증거가 아니다. 다운로드 수, 평점, 리뷰 수는 공개적으로 확인할 수 있지만 코호트별 7일·30일 유지율은 회사가 공개하지 않는 한 알 수 없다. 확인할 수 없는 수치를 사실처럼 쓰면 안 된다.

대신 직접 앱을 써 보면서 다음 질문에 답해야 한다.

• 첫 기록을 끝내기까지 얼마나 걸리는가?
• 짧은 기록과 깊은 기록 중 무엇에 강한가?
• AI는 사용자의 말을 되풀이하는가, 새로운 시각을 주는가?
• 기록한 데이터가 다음 행동으로 이어지는가?
• 무료와 유료의 경계는 어디이고, 민감한 데이터 처리 방식을 얼마나 분명히 설명하는가?

경쟁사의 장점은 배워야 한다. 차별화를 위해 무조건 다르게 만들 필요는 없다. 사용자가 이미 익숙하게 받아들이는 좋은 방식은 그대로 쓰고, 아직 풀리지 않은 문제에 집중하는 편이 낫다.

5. 이것이 정말 'Painkiller'인지 검증한다

창업 분야에서는 제품을 비타민과 진통제에 비유한다. 비타민은 있으면 좋지만 당장 필요하지 않을 수 있고, 진통제는 지금 겪는 고통을 없애 주기 때문에 적극적으로 찾게 된다는 뜻이다.

그러나 제품 전체를 둘 중 하나로 나누기는 어렵다. 감정 기록 앱도 평소에는 자기 이해를 돕는 비타민처럼 쓰이지만, 갈등이나 불안이 크게 올라온 순간에는 후회할 행동을 막아 주는 진통제가 될 수 있다.

중요한 것은 가장 절박한 사용 순간과 초기 사용자를 찾는 일이다. 예를 들면 이런 사람들이다.

• 일기를 여러 번 시작했지만 기록 부담 때문에 오래 유지하지 못한 사람
• 감정이 크게 흔들린 뒤 충동적으로 말하거나 행동하고 후회하는 사람
• 상담사에게 감정과 상황을 기록해 오라는 요청을 받은 사람
• 화가 났다는 것은 알지만 그 이면의 감정을 설명하기 어려운 사람
• 감정 기록은 원하지만 지나치게 임상적이거나 교훈적인 앱은 부담스러운 사람

이 가설은 제품을 만들기 전에 작은 실험으로 확인할 수 있다.

1. 목표 사용자 10~15명을 인터뷰한다. 원하는 기능보다 최근 감정 때문에 실제로 어려웠던 구체적인 순간을 묻는다.
2. 7일 동안 감정이 변할 때 지금 어떤 방식으로 기록하는지 관찰한다.
3. 앱을 개발하는 대신 노코드 도구나 화면 시안, 단체 대화방만으로 음성 입력과 간단한 대화 흐름을 흉내 낸다.
4. AI가 자동으로 분석하기 전에, 기획자가 직접 기록을 읽고 정리해 돌려주는 컨시어지 방식으로 사용자가 어떤 결과를 가치 있게 느끼는지 확인한다.
5. 무료 사용 의향이 아니라 사전 결제, 유료 베타 참여 같은 실제 행동을 측정한다.

이 단계에서 확인해야 할 것은 "사람들이 좋은 아이디어라고 말하는가"가 아니다.

• 감정이 생긴 순간에 실제로 기록하는가?
• 30초 안에 첫 기록을 끝낼 수 있는가?
• 며칠 뒤에도 다시 쓰는가?
• 기록이 충동적인 행동을 미루는 데 도움이 되는가?
• 어떤 결과를 위해 돈을 낼 의향이 있는가?

좋다는 말보다 반복되는 행동이 더 강한 증거다.

6. 차별화는 기능의 수가 아니라 하나의 약속에서 나온다

경쟁사 조사와 사용자 검증이 끝나면 제품의 핵심 약속을 한 문장으로 정리해야 한다.

감정 일기 앱의 약속은 이렇게 쓸 수 있다.

말로 설명하기 어려운 감정의 순간을 10초 안에 붙잡고, 3분 동안 감정의 층위를 차분히 살핀 뒤, 후회할 행동 대신 지금 가능한 한 가지 행동을 고르도록 돕는다.

이 약속을 중심으로 핵심 경험을 설계하면 다음 흐름이 나온다.

1단계, 순간을 빠르게 붙잡는다. 앱을 완전히 열지 않고도 위젯, 잠금 화면 바로가기, 음성 입력으로 짧게 기록한다.

"팀 회의가 끝났는데 기분이 너무 나쁘다."

2단계, AI가 성급하게 해석하지 않고 상황을 묻는다.

"회의에서 어떤 일이 있었나요?" "그 순간 가장 먼저 떠오른 생각은 무엇이었나요?"

3단계, 처음 표현한 감정을 세분화한다.

"화가 난 느낌에 가까운가요, 무시당한 느낌에 가까운가요? 실망이나 불안도 함께 있나요?"

AI는 답을 정해 주지 않고 몇 가지 가능성을 제시한다. 최종 선택은 사용자가 한다.

4단계, 경험의 요소를 구분한다. 실제로 일어난 사건, 그에 대한 해석, 감정, 신체 반응, 행동 충동, 충족되지 않은 욕구, 중요하게 여기는 가치를 나눠서 본다.

5단계, 지금 필요한 접근을 고른다. 생각을 검토할지, 몸과 감정을 먼저 가라앉힐지, 불편함이 남아도 가치에 맞는 행동을 찾을지, 아니면 지금은 기록만 남길지 사용자가 정한다.

6단계, 작고 안전한 다음 행동을 제안한다.

"지금 바로 메시지를 보내기보다 초안을 써 두고 30분 뒤 다시 읽어 보는 것은 어떨까요?"

이 구조의 차별점은 LLM 자체가 아니다. 범용 모델은 경쟁사도 쓴다. 차별점은 감정 탐색의 원칙, 질문의 순서, 성급한 판단을 막는 장치, 오래 쌓인 기록에서 패턴을 찾는 방식, 그리고 기록을 실제 행동으로 잇는 경험에 있다.

7. 수익 모델은 사용자가 돈을 내는 '결과'에서 찾는다

기본적인 감정 기록만으로는 강한 수익 모델을 만들기 어렵다. 앞에서 봤듯이 품질 높은 무료 서비스가 이미 있고, 그중에는 애초에 수익을 낼 필요가 없는 비영리 조직도 있다. 사용자가 감정을 고르고 저장하는 기능에 돈을 낼 이유는 거의 없다.

따라서 유료 가치는 기록 기능이 아니라 기록 이후의 결과에서 찾아야 한다.

무료 기능은 기본 감정 기록, 제한적인 음성 입력, 감정 단어 탐색, 기본 주간 요약, 간단한 마음챙김과 행동 가이드 정도가 될 수 있다.

개인용 프리미엄은 긴 음성 기록과 자동 정리, 장기간의 감정·상황·관계 패턴 분석, 개인화된 탐색 흐름, 반복 패턴을 보여 주는 월간 보고서, 사용자가 직접 설정하는 질문, 암호화된 백업과 데이터 내보내기, 상담 전 공유할 수 있는 사용자 승인형 요약으로 구성할 수 있다.

전문가 연계 모델도 생각할 수 있다. 상담사나 코치가 고객의 동의를 받아 요약 보고서를 확인하는 보조 도구다. 다만 개인정보 보호와 보안, 전문적 책임의 문제가 커지므로 개인용 제품이 검증된 뒤에 접근하는 편이 적절하다.

여기서 흔히 빠뜨리는 계산이 하나 있다. 감정 기록은 하루에 여러 번 쓰는 앱이라 무료 사용자 한 명이 발생시키는 AI 호출 비용이 생각보다 크다. 음성을 문자로 바꾸고, 되묻고, 주간 요약을 만드는 과정을 모두 외부 모델로 처리하면 사용자가 늘수록 적자가 커진다. 어떤 처리를 기기 안에서 하고 어떤 처리를 서버로 보낼지, 무료 사용자에게 하루 몇 번까지 허용할지는 기능 결정이 아니라 사업 결정이다. 이것도 코딩 전에 정해야 한다.

감정 기록처럼 민감한 데이터를 다루는 서비스에서는 프라이버시가 부가 기능이 아니라 제품 가치의 일부다. 감정 데이터를 광고에 활용하면서 동시에 신뢰를 내세우는 사업 모델은 서로 충돌한다.

8. 어떻게 발견되게 할 것인가

코딩 전에 정해야 할 목록에서 가장 자주 빠지는 것이 유통이다. 문제를 정의하고 경험을 설계하는 데까지는 공을 들이면서, "이 앱을 사람들이 어떻게 알게 되는가"는 출시 후에 생각하려 한다. 그러나 앞서 본 Cal AI의 성공에서 제품만큼 큰 비중을 차지한 것이 인플루언서를 통한 유통이었다.

유통을 미리 정해야 하는 이유는 마케팅 때문이 아니다. 유통 경로가 제품의 형태를 바꾸기 때문이다.

• 상담사의 추천으로 퍼진다면, 상담 전에 공유할 수 있는 요약 보고서가 부가 기능이 아니라 핵심 기능이 된다.
• 소셜 미디어에서 퍼진다면, 개인의 감정 기록을 노출하지 않으면서도 공유할 만한 결과물이 필요하다. 감정 기록 앱에서 이것은 상당히 어려운 설계 과제다.
• 앱 스토어 검색으로 들어온다면, 사용자가 실제로 검색하는 말이 무엇인지가 제품 이름과 첫 화면 문구를 결정한다.
• 특정 커뮤니티에서 시작한다면, 그 커뮤니티가 이미 쓰는 용어와 기록 방식에 제품이 맞춰야 한다.

그러니 코딩 전에 이 질문에 답해 두는 편이 좋다. 이 문제를 겪는 사람들이 지금 어디에 모여 있는가. 그들은 이 문제를 어떤 말로 검색하는가. 처음 백 명은 어디에서 데려올 것이며, 그 경로가 제품에 무엇을 요구하는가.

9. '진단'과 '치료'라는 말은 조심해서 쓴다

감정 앱을 기획할 때 "감정의 원인을 진단하고 적절한 치료를 제공한다"는 표현은 매력적으로 들린다. 그러나 AI가 사용자의 기록만으로 감정의 원인이나 정신건강 상태를 진단하는 것은 과학적으로도 위험하고, 규제 문제로 이어질 수 있다.

미국 FDA는 일반적인 건강과 웰니스 관리를 돕는 저위험 서비스와 질병의 진단·치료를 목적으로 하는 소프트웨어를 구분한다. FDA 모바일 의료 앱 안내, 일반 웰니스 가이드 한국에서도 식품의약품안전처가 개인용 건강관리(웰니스) 제품과 의료기기를 구분하는 판단 기준을 두고 있다. 어느 쪽이든 경계를 가르는 것은 기술이 아니라 제품이 내세우는 목적과 표시·광고 문구인 경우가 많다.

따라서 초기 제품은 경계를 분명히 하는 편이 좋다.

이 앱은 감정을 진단하거나 정신질환을 치료하는 도구가 아니다. 사용자가 자신의 경험을 기록하고 성찰하며, 안전한 다음 행동을 고르도록 돕는 웰니스 도구다.

AI도 "당신이 이렇게 느끼는 이유는 이것입니다"라고 결론 내리기보다 이렇게 말해야 한다.

"몇 가지 가능성을 함께 살펴볼 수 있습니다. 이 가운데 지금의 경험과 가장 가까운 것은 무엇인가요?"

좋은 AI는 모든 답을 대신 내리는 AI가 아니다. 사용자가 자신의 답을 더 잘 찾도록 돕는 AI다.

위험 신호를 만났을 때의 행동을 미리 정한다

감정을 다루는 제품은 언젠가 반드시 무거운 기록을 만난다. 스스로를 해치고 싶다는 마음이 담긴 문장이 들어올 수 있다. 이때 AI가 평소처럼 "그 감정 이면에 어떤 욕구가 있을까요"라고 탐색을 이어 가는 것은 적절하지 않다. 반대로 기록만 저장하고 아무 안내도 하지 않는 것도 위험하다.

그러니 코딩 전에 정해 둬야 한다. 어떤 표현을 신호로 볼 것인가. 그때 화면은 무엇을 보여 줄 것인가. 어느 지역의 어떤 공식 상담 창구를 안내할 것인가. 그 문구는 누가 검토했는가. 오탐이 났을 때 사용자 경험을 해치지 않으려면 어떤 어조여야 하는가.

이 부분은 기능 명세의 마지막 줄에 한 문장으로 적고 넘어갈 항목이 아니다. 제품 철학이 실제로 시험받는 자리다.

코딩 전에 만들어야 할 진짜 결과물

코딩 전 기획의 결과물은 기능이 가득한 두꺼운 문서가 아니다. 아이디어와 시장, 사용자와 제품을 잇는 근거의 사슬이다.

이 과정이 끝난 뒤에야 AI가 일할 수 있는 제품 요구사항 문서(PRD)와 기술 명세서를 쓴다. 그다음에 AI 도구로 코딩하고, 빌드하고, 웹이나 모바일에 배포하면 된다.

배포 자체는 과거보다 훨씬 쉬워졌다. 개발 환경을 자동으로 구성하고, 패키지를 설치하고, 오류를 고치고, URL까지 만들어 주는 서비스가 많다. 그러나 배포가 쉬워졌다는 것이 제품 검증이 끝났다는 뜻은 아니다. 과거에는 개발 비용이 높아서 잘못된 제품을 만드는 데 많은 시간과 돈이 들었다. 지금은 잘못된 제품도 아주 빠르게 만들고 배포할 수 있다.

그래서 지금 필요한 능력은 코딩을 빨리 시작하는 능력이 아니라, 아직 코딩하지 않아도 되는 질문을 충분히 던지는 능력이다.

• 이 문제는 누구에게 얼마나 절실한가?
• 사람들은 지금 어떤 방법으로 버티고 있고, 기존 서비스가 이미 잘 해결하는 것은 무엇인가?
• 우리가 줄 수 있는 고유한 변화는 무엇이고, 사용자는 거기에 시간이나 돈을 낼 것인가?
• 우리 AI가 해서는 안 되는 판단은 무엇인가?
• 배포할 수 있는가가 아니라, 배포한 뒤에도 사용자가 돌아올 이유가 있는가?

덧붙이자면 이 글에 나온 감정 기록 앱은 설명을 위해 지어낸 예시가 아니다. 나 역시 같은 문제를 붙들고 지금 기획 단계를 지나고 있고, 이 글은 그 과정에서 정리한 메모에 가깝다.

AI는 빠른 개발자이자 배포 담당자가 될 수 있다. 그러나 사용자의 고통이 어디에 있는지, 어떤 가치를 지켜야 하는지, 무엇을 만들지 말아야 하는지는 사람이 정해야 한다. 출시는 쉬워졌지만 선택받고, 신뢰받고, 반복해서 쓰이는 제품을 만드는 일은 여전히 어렵다. 그리고 그 승부는 대부분 첫 번째 코드가 작성되기 전에 이미 시작된다.