실험기록

왜 만들었고, 뭘 만들었나 이번 실험의 목적은 분명했다. 작게 만들고, 빠르게 오픈해서, 실제 사용자 반응을 관찰해보는 것. 작동하는 서비스를 출시해 누군가 실제로 써보게 하고, 가능하다면 바이럴을 통해 더 많은 사람들의 사용 흐름과 행동 로그를 살펴보는 것이 핵심이었다. 그런 고민 끝에 선택한 아이디어는 카카오톡 대화 기반 퀴즈 생성기였다. 사람들의 거의 모든 일상(방문 장소, 기념일, 약속 등등)은 메신저 안에 담겨 있다. 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를 찾고 투자를 받고 제품을 개발하는게 일반적이였다. 하지만 LLM으로 인해 더 빠른 개발이 가능하고 이제는 개발자 없이도 개발이 가능한 시대가 왔기 때문에 MVP를 넘어서 MMP가 필요하다고 한다. 이러한 시장에서 결국 더 필요한건 목표에 집중하는 가설 설정과 이 가설을 검증하는 빠른 실행아닐까? 그래서 월간 실험실은 매달 실험을 통해 가설을 검증하고 이를 기반으로 MVP를 넘어 MMP를 찾아보려고 한다. 실험 가설은 기술 측면과 비지니스 측면으로 나눠서 진행하고 실험 결과를 기록하다보면 우리가 세운 가설이 틀리더라도 심리적 타격 없이 금방 다시 다른 아이디어를 실행에 옮길 수 있을 것 같다. 실패에서 교훈을 얻고 다음 실험을 설계해서 나아가다보면 어떤 지점에서 깨달음이 있을 것 같다. 그리고 이 과정을 반복하다보면 깨달음과 함께 아이디어-MMP까지 이어지는 과정에 노하우가 쌓이고 자동화하여 AI Factory가 만들어 질 것 같다. 첫번째 실험 첫번째 검증해보려는 가설은 다음과 같다. LLM은 대화 내역에서 사람이 생각하는 중요한 이벤트를 뽑아 낼 수 있을까? 사람들은 재미를 위해 자신들의 대화내역을 서비스에 제공할까? 위 가설을 세운 이유와 어떤 아이디어가 제품으로 나올지 궁금하시다면 Monthly Lab 페이지 Subscribe 부탁드립니다. 😃

실패한 가설: 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를 선택하지 않을 이유가 없었다. 물론, 이후에 서비스가 확장되면서 다른 DB로 이전할 가능성은 있다. 하지만 처음부터 DB를 하나의 드라이버 혹은 인터페이스 레이어를 통해 추상화해두면, 추후 전환 시에도 큰 문제가 없다. Supabase를 "초기용 DB"로 두고, 확장을 고려한 구조로 설계해두는 것이 오히려 더 합리적인 접근이었다. 새로운 전략: Claude Code + Cursor로 CSS 개발 결론은 의외로 단순했다. AI 코딩 툴을 적극적으로 활용하자. Claude Code를 활용해 초벌 CSS 코드를 생성하고, Cursor에서 바꾸고 싶은 일부분만 수정하는 방식이 훨씬 더 효율적이었다. 로직과 UI를 분리한 구조로 설계할 수 있어 유지보수가 쉬웠고, 반복적으로 재사용 가능한 컴포넌트 개발도 가능했다. 무엇보다 직접 통제 가능한 코드 기반이라 디버깅이 훨씬 수월했다. 특히 예상보다 훨씬 인상적이었던 것은 Claude Code의 코드 생성 능력이었다. 처음에는 GPT-4 수준의 자동 완성을 기대했지만, 실제로는 전체 코드 구조를 파악하고, 파일 단위의 흐름을 일관성 있게 유지하며 구현해주는 모습이 눈에 띄었다. 함수와 컴포넌트 간의 연결, context의 흐름, 로직에 필요한 세부 변수 구성까지도 매우 정교하게 계획하고 작성하는 능력은 기대 이상이었다. TDD(Test-Driven Development) 방식과 결합하면 그 진가가 더욱 빛난다. 테스트 케이스가 명확히 정의되어 있기 때문에, 이후 UI를 수정하더라도 기존 로직이 깨지지 않았는지 빠르게 확인할 수 있다. 이 말은 곧 비개발자도 안정적인 구조 안에서 실험에 참여할 수 있다는 뜻이다. 예를 들어, 디자이너나 기획자가 Cursor의 미리보기 환경에서 버튼 위치를 바꾸거나 색상, 구성 요소를 수정해도, 기능 자체가 깨질 가능성은 낮다. 테스트가 모든 주요 흐름을 보장하고 있기 때문이다. 실제로는 Claude가 만든 초안을 기반으로 내가 전체 구조를 정리하고, 다시 Claude에게 일부를 개선시키는 흐름이 가장 자연스럽고 생산적이었다. 빠르게 만들고, 쉽게 고치고, 안심하고 실험할 수 있는 개발 흐름이 만들어졌다.

우리가 세운 3가지 가설 LLM 서비스를 처음 만들기로 했을 때, 우리가 가장 먼저 고민한 건 이거였다. "빠르게 만들 수 있을까? 그리고 그게 실제로 쓰일까?" 복잡한 아키텍처, 거대한 클라우드 인프라, 멋진 MLOps 도구. 처음부터 그런 걸 겨냥한 건 아니었다. 우리에겐 작지만 명확한 구조가 필요했고, 몇 주 안에 움직이는 서비스를 직접 보고 싶었다. 그렇게 우리는 하나의 실험실을 꾸리기로 했다. 매달 새로운 가설을 세우고, 빠르게 실험하고, 그 결과를 기록하는 “월간 실험실” 시리즈다. 가설-1: Chainlit UI만으로 MVP는 충분할까? LLM 기반 앱에서 가장 중요한 건 프론트엔드가 아니다라는 전제가 있었다. 대부분의 사용자 경험은 결국 대화 인터페이스에 머물고, 우리가 만든 게 실제로 쓰이는지 확인하려면 UI보다는 로직과 성능, 그리고 "대화 품질"이 더 중요하다고 생각했다. 그렇다면 정말 별도 프론트엔드 없이도 괜찮을까? React/Vue 없이 Chainlit만으로 충분할까? 사용자에게 신뢰를 줄 만큼 깔끔한 UI는 가능한가? 간단한 커스터마이징(로고, 색상, 말풍선)만으로도 브랜드 인식에 도움이 될까? 이 질문들을 담아, 첫 MVP는 FastAPI + Chainlit + Bootstrap 조합으로 구성했다. 클론 수준이 아닌, 실제 서비스를 최소한으로 동작시킬 수 있는 구조였다. Chainlit은 LLM 기반 애플리케이션을 빠르게 구축하고 배포할 수 있도록 설계된 오픈소스 프레임워크다. 특히 챗봇 UI에 최적화되어 있어, 복잡한 프론트엔드 코딩 없이도 Python 코드 몇 줄만으로 대화형 앱을 구현할 수 있다는 점이 강점이다. LangChain, LlamaIndex 등 주요 LLM 툴들과도 쉽게 통합되며, 세션 관리나 대화 흐름 추적, 사용자 인터랙션 구현 등도 기본적으로 지원한다. 처음 이 스택을 고를 때 가장 크게 고려한 점은 개발 속도였다. 실제 사용자 피드백을 빠르게 확인하기 위해선, 번거로운 프론트 작업 없이 MVP를 완성할 수 있어야 했고, Chainlit은 그 목적에 잘 들어맞았다. 대화형 인터페이스만으로도 초기 실험엔 충분하다는 가설 아래, React나 Vue 없이도 빠르게 결과를 보여줄 수 있는 최적의 도구였다. 가설-2: LangFuse와 Supabase만으로 운영 가능한가? LLM을 써보면 바로 느낀다. "왜 이 답이 나왔는지 알 수가 없다." LLM의 불확실성은 처음엔 재밌지만, 서비스 입장에선 굉장히 불편한 요소다. 그래서 LangFuse를 도입했다. 프롬프트 변경 추적, 토큰 사용량, 히스토리 관리, 심지어 A/B 테스트 까지 모든 것이 다 들어있다. 특히 LangChain과 연동이 부드러운 것도 장점이다.