유저 0명에서 구글 마케팅 라이브까지

Pomelli가 2025년 10월 말 유저 수 0->1으로 시작하여 반년 만에 Google Marketing Live Keynote에서 소개되는 자리까지 올라섰습니다. 현재에는 전 세계 수만 명의 사람들이 자신의 비즈니스를 성장시키기 위해 Pomelli를 사용하고 있습니다.

첫 출시 이후 Photoshoot, Product Catalog, Agent 등 여러 기능들을 빠르게 출시했습니다. 팀의 모멘텀이 정말 엄청났습니다. 어떤 출시일에는 아침에 중요한 기능을 배포하고 오후에 바로 다음 기능 출시 계획을 세웠던 기억이 납니다.

이 모든 일들이 제가 Google Labs에 합류한 지 채 1년도 되지 않아 일어났습니다. 팀 규모도 커졌습니다. 처음 합류했을 때는 엔지니어 수를 한 손으로 꼽을 수 있을 정도였는데, 이제는 팀이 너무 빠르게 확장되어 일하는 방식이나 조직 문화에 대해 끊임없이 이야기하곤 합니다.

Google 같은 빅테크 기업에서 이런 스타트업 같은 경험을 할 수 있을 것이라곤 상상도 못 했습니다. 아마도 0에서 1을 만드는 제품들이 태어나고, 사라지고, 성장하는 Google Labs 같은 몇몇 조직에서만 가능한 독특한 경험일 것입니다.

2026년 상반기는 Pomelli를 궤도에 올려놓는 데 온전히 집중했습니다. 아직 가야 할 길이 멀지만, 사내외에서 상당한 관심을 끄는 데 성공했고 여러 중소기업(SMB)들이 실제로 저희 제품을 사용하게 되었습니다.

그동안 실험적인 AI 제품을 만들며 배운 점들을 기록하고 공유하고자 합니다. 이는 지식을 나누는 목적도 있지만, 미래의 저를 위한 참고 자료이기도 합니다. 비슷한 프로젝트를 진행하고 계신 분들께도 조금이나마 도움이 되었으면 좋겠습니다.

시스템 디자인과 라스트 마일

바이브 코딩(vibe coding)의 시대가 도래하면서 코드 작성 비용이 급격히 낮아졌다고들 합니다. 이 말은 어느 정도는 사실일 수 있지만, 그렇다고 좋은 제품을 만드는 것이 쉬워졌다는 뜻은 아니라고 생각합니다.

바이브 코딩은 개념 증명(PoC)이나 최소 기능 제품(MVP)을 처음 빠르게 만들어내는 데는 훌륭하지만, 딱 70-80% 까지만 데려다줄 수 있습니다. 이정도만 해도 굉장히 놀라운 발전이지만, 실제 유저들이 들어오기 시작하면 바이브 코딩으로 만든 앱을 안정적으로 확장(scale)하는 것은 다른 차원의 어려운 문제입니다.

실제 유저들이 제품을 쓰기 시작하면 마치 멈출 수 없는 열차를 운영하는 것과 같습니다. 승객들이 타고 있는 상황에서 안전하게 코드를 변경하고 버그를 수정하는 것은, 달리는 기차의 엔진을 교체하고 바로 앞의 선로를 깔아 나가는 것과 마찬가지입니다. 이제 본인만 쓰는 제품이 아니기에, 문제가 생겼다고 단순히 "재생성(re-generate)" 버튼을 누를 수는 없습니다.

그렇기 때문에 제품의 확장성과 유지보수성을 확보하는 데 있어 좋은 시스템 디자인(System Design)은 여전히 매우 중요합니다. AI 에이전트가 이를 위한 지식을 가지고 있을지라도, 엔지니어가 그 작업을 제대로 조율(orchestrate)하지 못하면 코드를 짤 때 근시안적인 결정을 내리기 쉽습니다. 이전에도 말했듯이, 소프트웨어 엔지니어링은 단순히 코딩을 하는 것보다 훨씬 큰 개념입니다.

제품을 70-80% 완성도에서 90-100% 수준으로 끌어올리는 '라스트 마일(last mile)' 엔지니어링이야말로 훌륭한 제품을 만드는 핵심입니다. 이는 예외적인 에지 케이스(edge case) 버그를 고치거나, 평가(eval)와 반복 개선을 통해 생성형 AI 아웃풋의 품질을 높이거나, 유저 피드백에 기반해 전체적인 워크플로우를 다시 회고하고 고치는 작업을 의미합니다.

저희 팀은 Pomelli의 성공 요인이 기능을 출시하기 전에 이러한 '라스트 마일' 작업에 집중했기 때문이라고 믿고 있습니다. 많은 기능들이 팀 전체의 피드백 세션, 유저 리서치, 그리고 퀄리티에 대한 개별 팀원들의 집요함 덕분에 완성될 수 있었습니다.

물론 이는 냉혹한 우선순위 지정을 통해 덜 중요한 부분은 과감히 타협하는 유연함도 필요로 합니다. 완벽주의가 팀의 개발 속도를 늦추어서는 안 되니까요.

GTM(Go-to-market) is King

매일 수백 개의 AI 기능과 제품들이 쏟아져 나오는 상황에서, 이 수많은 소음을 뚫고 사람들의 이목을 끌기 위해서는 시장 진입 전략(GTM)이 극도로 중요합니다.

저희 제품 개발 논의에는 마케팅 팀이 매우 밀접하게 참여하여 제품 개발과 GTM 전략이 유기적으로 진행하고 있습니다. 엔지니어들 역시 본인이 담당하는 기능의 마케팅 런칭 계획에 의문을 제기하고 보완을 요구할 수 있습니다. 이는 팀원들의 주인 의식이 얼마나 강한지 보여준다고 생각합니다.

Google Labs의 GTM 팀은 저희 제품 성공의 일등 공신입니다. Photoshoot 기능을 런칭할 당시 인플루언서 파트너십, 언론 보도, 그리고 Google 리더십 레벨(Demis Hassabis, Josh Woodword 등)의 증폭 지원까지 모든 마케팅 실탄이 정확한 타이밍에 맞아떨어졌습니다.

이토록 시끄럽고 빠르게 변하는 세상에서는 제품이 아무리 훌륭하더라도 결국 GTM 전략이 핵심("GTM is King")이라고 생각합니다.

무엇을 만들지 조율하고 통일하는 것은 어렵다

빠르게 움직이기 위해서는 팀원 간의 조율, 특히 엔지니어링, PM, 디자인 등 서로 다른 직군 간의 통일(alignment)이 매우 중요하지만 동시에 무척 어렵습니다.

어떤 기능을 개발할 때 우리가 정말로 만들고자 하는 것이 무엇인지 명확하게 합의하지 못해 시간과 리소스를 낭비한 경험이 꽤 있습니다. 결국 해당 기능이 유저에게 주고자 하는 본질적인 가치가 무엇인지 처음부터 다시 고민하고, 불필요하거나 구현 난이도가 너무 높은 부분들을 쳐내야만 했습니다.

또한 팀이 기민하게 움직이고 범위(Scope)가 계속해서 바뀌는 환경에서는 효율적인 의사소통과 의사결정이 어렵습니다. 이는 많은 혼란과 중복 작업을 야기하고, 계속되는 논의와 잦은 수정 작업으로 인해 팀이 번아웃될 위험성을 키우기도 합니다.

스타트업처럼 빠르게 달리는 팀에서는 이러한 진통이 어느 정도 불가피할 수도 있습니다. 팀의 규모가 커질수록 이러한 고통은 더 커질 거구요. 하지만 그렇다고 더더더욱 잘해낼 수 없다는 뜻은 아닙니다.

불편한 대화나 긴장감이 생기더라도 저희 팀은 소통과 일하는 방식을 개선하기 위해 꾸준히 노력하고 있습니다. 끊임없는 피드백과 반복(iteration)만이 좋은 제품을 만드는 건강한 팀을 유지하는 유일한 길이기 때문입니다.

Buzzwords가 아닌 실제 문제에 집중하기

마지막으로, 아마 가장 실천하기 어려운 부분일 것입니다. 많은 사람들이 제품의 가치를 포장하기 위해 "에이전트(agent)", "하네스(harness)" 같은 최신 유행어(buzzwords)들을 남발하는 모습을 봅니다. 기술에 관심이 많은 소수에게는 통할지 몰라도, 현실적으로 대부분의 사람들은 복잡한 AI 개념들을 잘 이해하지 못하며, 이해하고 싶어 하지도 않습니다.

유저들은 그저 자신들의 문제가 해결되기를 바랄 뿐입니다. 저희의 핵심 철학은 복잡한 백엔드 기술은 뒤로 숨겨두고, 중소기업(SMB)들이 겪는 실질적인 문제 해결에 초점을 맞추어 누구나 일상적인 문제를 Pomelli로 쉽고 편리하게 해결할 수 있도록 만드는 것입니다.

새로운 제품을 만드는 일은 무척 설레지만, 제품이 궤도에 오르기 시작하면 모멘텀을 유지하며 제품과 팀이 나아갈 올바른 방향을 정하는 것이 훨씬 더 큰 도전 과제라는 것을 경험하고 있습니다.

매일 이 여정에서 치열하게 배우고 느끼는 중이지만, Pomelli의 초기 성장 단계를 함께하며 얻은 이 소중한 생각들을 먼저 기록해두고 싶었습니다.

이 글이 흥미로우셨다면 편하게 의견을 남겨주세요! 함께 이야기를 더 나누어보았으면 좋겠습니다!