왜 만들었고, 뭘 만들었나 이번 실험의 목적은 분명했다. 작게 만들고, 빠르게 오픈해서, 실제 사용자 반응을 관찰해보는 것. 작동하는 서비스를 출시해 누군가 실제로 써보게 하고, 가능하다면 바이럴을 통해 더 많은 사람들의 사용 흐름과 행동 로그를 살펴보는 것이 핵심이었다. 그런 고민 끝에 선택한 아이디어는 카카오톡 대화 기반 퀴즈 생성기였다. 사람들의 거의 모든 일상(방문 장소, 기념일, 약속 등등)은 메신저 안에 담겨 있다. LLM을 사용해 퀴즈를 만들고, 친구들과 함께 가볍게 웃으며 즐길 수 있는 재미있는 콘텐츠가 되리라 기대했다. 기획은 아래와 같았다. 사용자가 자신의 카카오톡 대화 파일(txt) 을 업로드한다. 대화를 바탕으로 LLM이 자동으로 퀴즈 5~7개를 생성한다. 결과는 공유 가능한 URL 형태로 제공된다. 링크를 받은 친구는 로그인 없이 퀴즈를 풀 수 있다. 비즈니스 모델은 단순했다. 큰 수익을 기대하진 않았고, 일정 사용자 수가 생기면 구글 애드센스를 붙여 LLM 호출 비용 정도만 충당하는 수준이면 충분했다. 핵심은, 작고 빠르게 만들어 실제 사용자 반응을 직접 관찰해보는 것. 이 실험은 그렇게 시작되었다. Lesson Learn ① 가벼운 서비스에 무거운 벽이 너무 많았다 실제 서비스를 오픈하고 가장 먼저 느낀 문제는 생각보다 많은 사용자가 시작조차 하지 않는다는 것이었다. 구조는 간단했지만, 두가지 허들이 유저를 가로막고 있었다. 1차 허들: 회원가입 카카오톡 대화 파일이라는 민감한 데이터를 다루기 때문에, 파일 업로드 기록과 결과 저장을 위해 간단한 이메일 기반 로그인을 도입했다. 인증 메일도 없고, 최소한의 절차였지만, 사용자 입장에선 충분히 귀찮았다. "왜 로그인을 해야 하지?" "귀찮다, 안 해." "이거 뭐야, 그냥 나가자." 결과적으로 회원가입 단계에서 대부분의 유저가 이탈했다. 이 서비스는 "가볍지 않다"는 인상을 남겼고, 사용자는 떠났다.

LLM 시대 2022년 말 ChatGPT를 시작으로 LLM이 세상에 알려진지 2년 반 정도가 지났다. LLM은 인터넷이나 모바일보다 더 빠르게 많은 사람들의 삶에 스며들었고 이제는 회사에서도 개인의 삶에서도 없으면 안되는 수준이 된 것 같다. ChatGPT 이후에 Claude, Gemini, Perplexity를 필두로 Cursor, Windsurf, Lovable, v0, Genspark, Skywork 등 다양한 서비스가 출시되고 경쟁하며 발전하고 있다. 이런 새로운 서비스 말고 Figma, Slack, Zoom 등 기존 서비스들에도 LLM을 이용한 기능들이 다양해지고 있다. 이 중 개발 분야가 가장 급격한 변화를 맞이하고 있고 코딩에서 더 나아가 제품 개발까지도 변곡점에 있다고 느껴진다. Cursor만해도 생산성에 큰 기여를 한다고 느꼈고 이에 대한 반증으로 Cursor는 연 반복매출이 1년만에 100배 증가했다. 연 매출이 $1M에서 $100M으로 증가하는 기염을 토하고 현재도 빠르게 증가하고 있다고 한다. 하지만 Cursor의 약진도 25년 6월, 지난달에 Claude Code가 출시되면서 상황이 한풀 꺾일걸로 보인다. Cursor까지는 개발자의 생산성을 위한 도구였다면 Claude Code는 코드를 작성할줄 모르는 사람도 개발할 수 있게 해주는 서비스라 생각한다. 이 생각에 아니라고 반대하는 사람도 있을거고 지금은 실제로 어려운 점이 있을 수 있지만 25년 하반기, 늦어도 26년 상반기에는 비개발자가 작성한 PRD(Product Requirements Document)만으로도 MVP가 나올거라 생각한다. 그리고 이 과정에서 비개발자가 개발을 시작하는 경우도 많아질거라 생각한다. (그러면 Cursor가 계속 승승장구할거 같기도하고..) Viable? Marketable? LLM으로 인해 전통적으로 이야기하던 MVP(Minimum Viable Product)보다 이제는 MMP(Minimum Marketable Product)라는 이야기가 나오고 있다. 이전에는 개발이 오래걸리고 어렵게 만든 제품이 시장에서 반응을 얻지 못하는걸 대비하기 위해 최소한으로 고객에게 가치를 전달할 수 있는 제품을 만드는걸 강조했다. 그래서 창업자들은 개발자를 고용해서 제품을 만들기전에 스프레드시트와 오픈채팅으로 검증을 하는 등 다양한 시도를 통해 PMF를 찾고 투자를 받고 제품을 개발하는게 일반적이였다.

실패한 가설: Chainlit UI만으로 MVP는 충분할까? 실험 결과, 이 가설은 실패로 결론 내렸다. 처음엔 Chainlit이 꽤 매력적으로 보였다. 별도 프론트 없이도 대화형 UI가 바로 뜨고, LangChain과의 연동이나 세션 관리, 히스토리 기록도 잘 되어 있었다. 우리는 이를 FastAPI와 docker-compose로 구성해, 서비스 UI와 Chainlit을 따로 분리하고 필요할 때만 연결하는 구조를 시도했다. 하지만 곧 한계에 부딪혔다. Chainlit은 독립적인 프레임워크로 동작하는 것을 전제로 설계되어 있다. 외부 컨테이너나 프론트엔드에서 값을 넘겨주거나, 세션을 유기적으로 연결하는 방식은 구조적으로 어려웠다. 작은 커스터마이징(로고, 말풍선, 색상 변경)은 가능했지만, 브랜드 UI에 맞춰 유연하게 바꾸기에는 제한이 많았다. 결국, "Chainlit만으로 서비스 UI를 커버한다"는 전략은 현실적으로 어렵다는 판단을 내렸다. 빠르게 실험하긴 좋지만, 실제 제품에 통합해 쓰기엔 애매했다. 한때 주목한 대안: Lovable + Supabase 다음으로 주목한 건 Lovable이었다. Lovable은 ChatGPT 스타일의 프론트를 빠르게 생성해주는 서비스로, Supabase와도 연동이 쉬웠다. 로그인, DB 저장, 프롬프트 관리 같은 기능이 자동으로 세팅되고, 빠른 프로토타이핑에 최적화되어 있었다. 최근 빠르게 MVP를 만들어야 하는 스타트업에서 자주 언급되는 조합이기도 하다. 하지만 이 역시 제한적이었다. 생성된 프론트는 커스터마이징이 어렵고, 백엔드 로직은 자동 생성되지만 재사용 가능한 구조로 짜여 있지 않으며, 결국 직접 수정하거나, 처음부터 다시 짜야 하는 부분이 많았다. v0.dev도 함께 살펴봤지만, 생성된 프론트의 구조가 복잡했고, 기존 API와 붙이기엔 오히려 리소스가 더 많이 들었다. 디자인은 깔끔했지만, 실제 서비스 구조에 통합하려면 너무 많은 수작업이 필요했다. 그럼에도 살아남은 실용 스택: Supabase Lovable과 v0.dev는 결국 버릴 수밖에 없었지만, Supabase는 명확하게 효과가 있었다. 일정 사용량까지는 무료이고, 외부 API 키만 연동하면 쉽게 호출할 수 있으며, GUI로 DB를 손쉽게 관리할 수 있다는 점에서 초기 개발에 매우 유리했다. 비슷한 기능을 AWS에서 구성하려면 비용도 훨씬 많이 들고, 세팅도 복잡하다. 초기 실험과 MVP 구조를 구성하는 단계에서 Supabase를 선택하지 않을 이유가 없었다.