유난한 한 해였다.
올 한해는 바닥부터 제품을 만드는 경험만 여러번 한 만큼, 우리 팀이 개발한 제품들과 함께 지난 1년을 회고하려한다1.
이야기의 시작은 2022년 여름으로 거슬러 올라간다. 뤼이드에서 2년을 보내고 구글에서 인턴을 하면서, 창업을 하는 것이 너무나도 그리웠다. 첫번째 창업 프로젝트였던 Everest를 만들면서, 사람들이 사랑하는 서비스를 만드는 것이 얼마나 즐거운 일인지 깨달았었다. 대체복무도 끝났겠다, 이제는 비로소 모든 걸 쏟아부어 자랑스러운 제품을 만들고 싶었다.
시장의 크기 측면에서 한국과 비교가 안되는 기회를 가지고 있는 미국에서 창업을 하고 싶은 생각은 여전히 있었기에, 비자 문제를 해결하기 위해 우선 휴학하고 있던 UC 버클리로 돌아가기로 했다. 그 후 1년 반동안, 조기 졸업을 위해 수업을 몰아듣는 와중 20개가 넘는 아이디어의 가설검증을 진행하고 8개의 제품을 런치하였다2. 지난 1년 반동안의 희노애락을 가져다준 8개의 제품과 함께, 2023년 회고를 진행해보려고 한다.
Idea 1. 복잡한 웹 서핑시 학습한 지식을 정리해주는 툴
Period: August 2022 ~ January 2023
Background
2022년 봄, Will Smith 가 아카데미 시상식에서 Chris Rock 의 뺨을 때린 사건이 있었다. 페이스북을 보다가 이에 대한 글을 보고 사건을 알게 되었던 기억이 난다. 글을 보자마자 전체 영상이 궁금해서 유튜브에 찾아가서 검색해보고, 사람들의 의견이 궁금해서 구글에서 칼럼들을 읽어봤다. 몇일 후, 링크드인에서 동서양이 해당 사건에 대해 다르게 생각한다는 글을 읽고, 네이버에서 관련 한국 기사들을 추가로 읽어봤다.
이 일을 계기로, 각각의 도메인에서의 추천 시스템은 최적화 되어있지만 각 도메인을 넘어선 추천 시스템은 아직 존재하지 않는다는 것을 지각하게 되었다.
브라우저 레벨에서 우리가 특정 주제에 대해서 얻은 지식을 관리해주고 추천해줄 수 있다면 어떨까? 처음부터 추천을 해줄 수는 없으니, 사용자가 여러 도메인에서 습득한 지식을 브라우저 레벨에서 정리해주고 관리해주자. 이것이 첫번째 아이디어의 시작이었다.
v1 Hypothesis
유저가 특정 목적 (e.g. 새로운 주제에 대한 학습, 기사를 위한 리서치 등) 을 위해 수십개의 탭을 방문하고 지식을 수집하는 과정을 Complex Search Journey 라고 정의했다.
일반적으로 Complex Search 를 하는 과정을 조사해보니, 별도의 페이지를 Split Screen 으로 띄워서 내용을 복붙하면서 조사를 하거나, 수십개의 탭을 그냥 열어두고 조사를 하는 방식이 주된 리서치 방식이었다.
Complex Search 에서 얻은 정보들은 위계를 갖기 마련인데, 그러한 위계가 브라우저의 UI 혹은 노트 앱에서 나타나지 않는다고 생각했고 유저가 complex search journey 시에 방문하는 페이지들을 트리 형태로 가시화해서 보여줄 수 있다면 유저가 가치를 느끼고 지속적으로 사용할 것이다 - 라는 가설을 세우게 되었다.
Progress
크롬 익스텐션에 대한 개발 경험이 전무할 뿐더러, 1년이 넘는 기간동안 AI Research (뤼이드) 및 ML/Backend (구글) 을 했던 시점이라 일반적인 Web framework 도 익숙하지 않았다. CSS/JS 를 배우면서 조악하지만 동작은 하는 제품을 빠르게 만들고, 20명을 대상으로 Private beta test 를 약 10일 정도 진행하였다.
Learnings
실제 사용자의 사용 패턴을 보니, 1개 이상의 탭을 필요로 하는 웹서핑에서도 트리 구조가 필요한 만큼 복잡한 서치를 하는 일이 많이 없었다. 사실 트리의 노드 개수가 5개 이하라면, 단순히 쉬운 북마크 이상으로 트리 구조가 주는 가치는 유의미하지 않다는 결론을 내렸다. Complex Search 를 많이 하는 사람들에게는, 페이지의 내용, 해당 페이지에서 새롭게 알게 된 것, 어떤 질문이 해소되었는지가 UI 상에서 기록되지 않아서 불편했다.
또한, 우리가 타겟하는 문제의 범위가 너무 크다는 결론을 내렸다. 가장 구체적이고 복잡한 서치 케이스에서 우선 검증을 하고, 해당 케이스의 UI/UX 를 더 넓은 대중에 맞게 변화시키면서 가는 방향이 적합했을 것 같은데, 처음부터 제너럴한 케이스를 타겟하게 되니 우리가 문제를 잘 풀고 있지 못하고 있는건지, 애초에 문제가 아닌지 구별을 짓는게 힘들어졌다.
v2 Hypothesis
이러한 실험 결과를 바탕으로, 두번째 버전의 가설을 세우기 시작했다. 이번 가설부터는 Complex Search 를 도식화하고 3 유저를 명확히 정의하기 시작했다.
User Persona 1. 특정 주제에 대한 기사를 쓰기 위해 본인의 전문분야가 아닌 주제를 빠르게 학습하여 글로 표현해야하는 저널리스트들
User Persona 2. 특정 산업에 대한 깊은 리서치를 해야 하는 애널리스트들
User Persona 3. 리서치 기반 에세이를 자주 써야하는 학부생/대학원생들
v2 Progress
v2 에서 가장 크게 바뀐 부분은 질문/주제 기반 UI 였다.
첫번째 탭을 여는 이유는, 해결하고 싶은 궁금증이 있기 때문이다.
N개의 탭에서 N+1 번째 탭을 여는 이유는, 아직 해결되지 못한 질문 혹은 궁금증이 있기 때문이다.
고로, 각각의 탭을 여는 이유는 질문의 형태로 표현할 수 있다.
무분별하게 열린 탭들을 관리하지 말고, 각각의 탭들이 열린 동기인 ‘질문’ 을 관리해주면 어떨까? 위 가설이 성립하는 이상, 행위의 ‘결과’를 관리하는 것보다 행위의 ‘동기’를 관리하는 것이 더욱 직관적일 것이라고 생각했다.
질문 베이스의 흐름을 기록할 수 있는 UI 를 가진다면, 얻을 수 있는 추가적인 이점은 아래와 같다:
조금 더 의식적으로 서치할 수 있고, 무엇을 알게되었는지 명확히 인지할 수 있다.
Hyper-correction effect: 틀린 답이라도 도출해보는 것이 추후에 옳은 답을 배웠을때 더 오래 기록할 수 있다.
방문한 페이지를 이탈하지 않고 계속 읽고 싶을때, 질문을 간편히 남겨놓고 정보 습득에 남겨둘 수 있다.
추후 Copilot 이 붙는다면, 해당 질문들에 대한 대답은 글을 읽다보면 추가되어 있을 것이다.
이렇게 하여 탄생한 제품이 위 데모 영상에 나온 제품이다. 해당 제품을 가지고 무작정 저널리스트분들, 애널리스트분들, 그리고 대학생분들을 찾아다녔다.
딱 1년전 겨울이었다. 겨울방학 기간동안 한국에서 살을 에는 바람을 뚫고 신문사별로 돌아다니기 시작했는데, 다행히 얘기를 듣고 연락처라도 주시는 분들이 대부분이었다. 하지만 저널리스트분들과 더 깊게 얘기를 해볼 수록, 이 마켓은 적합한 마켓이 아니라는 생각이 들었다.
우선, 내가 저널리스트와 거리가 너무 멀었다. 친한 지인들 중에 저널리스트가 있는 것도 아니라 distribution 및 domain knowledge 를 확보하는 것이 힘들었고, 한국의 저널리스트분들 중 많은 분들은 Microsoft Word 을 아직도 쓰고 계셔서 사실상 Word extension 을 개발해야 했다. 또한 한국 신문사는 SaaS subscription 에 대한 개념이 한국의 B2B 회사보다도 익숙하지 않아서 저널리스트 당 달마다 10불을 내고 서비스를 쓴다는 개념 자체를 매우 어색해했다.
저널리스트에서 시작한 제품이 제너럴한 유스케이스로 퍼져나가면 좋겠다는 생각을 하면서 인터뷰를 하러 다녔는데, 점점 저널리스트에 특화된 제품이 아니고서는 문제를 제대로 풀지 못하겠다는 생각이 들었다. 이는 애널리스트도 마찬가지였고, 우리 팀에게 직접적으로 공감이 가고 우리가 domain knowledge 를 가지고 있는 제품을 만들자는 생각을 하면서 피봇을 하게 되었다.
Learnings
저널리스트 2분이 private beta 버전을 $10/month 로 결제하고 쓰셨는데, 제품을 많이 사용하지는 않으셨다. 결국 Vertical 하게 가기 위해서는 우리가 Distribution 채널을 가지고 있는 것이 모든 일을 100배 쉽게 만들어준다는 교훈을 얻었다.
Idea 2. 지식 노동자들이 웹에서 리서치한 내용을 바탕으로 학습 노트를 만들어주는 툴
Period: 2023 년 2월 ~ 3월
Background
v1 과 v2 를 개발하면서 얻은 또 하나의 인사이트가 있었는데, 이는 사용자의 지식을 브라우저 레벨에서 관리하고 추천해주기 위해서는 크롬 익스텐션이 아닌 new 크롬, 즉 새로운 브라우저를 만들어야 한다는 것이었다4. 크롬 위에서 우리가 원하는 메타데이터를 얻는 것이 개발적으로 너무 복잡하고 제한 사항도 많았다.
당시 미국에서 돌풍을 일으키던 Arc 브라우저를 보면서, 스타트업이 개발한 브라우저도 제품성이 뛰어나면 주류가 될 수 있겠구나를 깨닫게 되었다. 그러면서 2주 정도 사용자의 의도에 따라 탭을 정리하고 얻은 지식을 관리해주는 브라우저를 디자인하기 시작했는데, 결국 개발은 하지 않기로 결정했다. 이미 크롬에서 부족한 부분을 Arc 브라우저가 잘 충족을 해주고 있었고, 그간의 경험들은 많은 사람들을 위한 비타민을 만들기 보다는 소수의 사람들을 위한 pain killer 를 만드는 것이 훨씬 효과적이라는 가르침을 주었기에 우리가 만든 새로운 브라우저가 pain killer 가 될 수 있을지 의구심이 들었다.
따라서 v2 에서 얻은 distribution channel 에 대한 교훈을 바탕으로, 우리가 최적의 distribution 을 가지고 있는 대학생/대학원생에 집중하기로 결정을 내렸다.
Hypothesis
웹 서치를 하면서 하이라이팅만으로 노트 정리가 된다면, 학생들이 월 $10 을 지불하고 서비스를 사용할 것이다.
Progress
서비스는 아래 데모 영상에 나온 것처럼, 온라인에서 학습한 정보들을 마치 내가 직접 만든 노트처럼 노션페이지에 정리를 해주는 서비스이다.
런치를 하고, 이 제품도 20명 정도 Private beta 를 진행했다.
Learnings
사람들의 반응은 ‘신기하다‘ 가 주였다. 하지만 우리가 타겟했던 대학생/대학원생의 경우, 막상 노트 정리가 꼭 필요한 주제를 리서치를 해야할때에는 창을 옮겨가면서 노트 정리를 하는 것에 큰 pain point 를 느끼지 않았다. 반면 정리가 굳이 필요한 주제는 아니지만 정리가 되면 좋은 주제들에 대해서는 willingness to pay 가 매우 낮았다.
Vertical 하게 가더라도, willingness to pay 가 낮은 마켓이라면 커지기 어렵다. Vertical 로 가서 TAM 이 작아지게 되면 그 것을 보완할 수 있도록 willingness to pay 가 높아야 한다는 사실을 다시 한번 상기시키게 되는 계기가 되었다.
이렇게 적어놓으면 자명한 깨달음처럼 들리지만, 사실 Idea 2 까지는 우리의 목표가 Venture-scaleable startup 을 만드는 것임에도 불구하고 시장에 대한 생각을 하며 제품을 만들었다기 보다는 우리가 만들고 싶은, 우리가 풀고 싶은 문제를 푸는 제품을 만들었었다.
Idea 3. Zoom 과 integrated 된 AI 기반 회의록 생성툴
Period: 2023 년 4월 ~ 6월
Background
Idea 2 까지의 우리팀은 한국에서 일하는 팀원이 적어도 1명은 있었다. 따라서 회의때마다 줌콜을 켜야했고, 회의를 진행하면서 회의 내용을 기록하는 것은 내 몫이었다. 회의록을 작성하는 것이 너무 번거로워서 간단히 OpenAI API 로 회의록을 작성하도록 해봤더니, 성능이 놀랍도록 좋았다. 바로 다음 미팅에서부터 내가 만든 툴을 쓰기 시작했고, 한번 팔아볼까? 라는 생각을 하게 되면서 제대로 시작을 해보게 됐다.
Hypothesis
원하는 양식에 맞는 회의록을 AI가 자동생성해준다면, 회사에서 제품을 구매하여 사용할 것이다.
Progress
이전 2개의 아이디어로 배운 교훈이 있기 때문에, 이번엔 만들 생각부터 하지 않고 팔 생각부터 했다. 이미 친분이 있는 지인의 스타트업에 바로 연락을 했고, Discovery call 을 진행했다. Discovery call 을 할때만 해도 해당 스타트업의 코파운더 분은 우리 서비스에 관심이 없었다. 이미 Gong 이라는 미국 메이저 Sales 플랫폼에 엄청난 금액을 지불하고 있었고, Gong 에서도 회의록 요약을 해주고 있었기 때문이다.
콜이 끝나고 아쉬운 마음에 우리의 기술로 생성된 회의록을 보여주자, 회의록의 질에 깜짝 놀라시면서 바로 사고 싶다고 말씀을 하셨다 (회의록은 몇시간만 투자해서 만든 Python script 의 output 이었다).
이렇게 우리 팀은 Python script 하나로, 제품이 개발되면 해당 스타트업이 바로 매월 X 달러를 내겠다는 Letter of Intent 를 사인했고, 고객이 존재하는 상태에서 제품 개발을 시작했다.
제품은 위와 같이 동작한다. Zapier Integration 과 Zoom integration 을 통해, 줌콜이 끝나면 바로 해당 회사의 Knowledge Base (e.g. Notion) 에 쏴준다. 또한, 줌콜시 줌봇이 조인을 해서 실시간으로 스크립트 및 번역 서비스를 제공한다.
런치 후 3 곳의 스타트업에서 월 구독료를 지불하면서 우리의 제품을 사용하였고, 월 매출이 $500 정도 되었다.
Learnings
타 회의록 생성 제품과 비교했을때, 우리 제품의 가장 큰 차별점은 원하는 고객이 회의록 양식에 맞춰서 생성된 회의록을 받아볼 수 있다는 것이었다. 예를 들어, Sales Call 을 위한 템플렛을 고객이 제공하면 그 양식에 맞게 우리가 회의록을 생성해드리는 것이다. 하지만 아직 이 부분을 확장성있게 제공할 수 있는 방법을 찾지 못한 상태였고, 단순한 기능 기반 차별점이었기에 왜 우리가 경쟁에서 이길 수 있을지를 설득할 수 있는 명확한 이유를 찾지 못했다.
그리고 회사마다 우리의 서비스를 주로 사용하는 미팅의 종류가 달랐는데, 가장 만족도가 높은 미팅 타입은 Sales call 이었던 반면 가장 만족도가 낮았던 미팅 타입은 생각외로 사내 회의였다. 우리가 이 아이디어를 개발하기 시작했던 계기가 우리 팀의 사내 회의였음에도 말이다. 인터뷰를 해보니, Sales call, User Interview 와 다르게 내부 회의는 회의가 끝나고 회의록을 보는 일이 거의 없었다. 회의 내용에 대해서 궁금하다면 옆사람에게 바로 물어보면 되고, 컨텍스트 유실이 걱정되어 회의록을 적더라도 막상 그 회의록을 근시일내에 볼 일이 없다보니 회의록의 가치를 명확히 전달하기 힘들었다.
Sales call 은 이미 경쟁이 치열하고 우리가 열정을 가지고 있는 분야도 아니었기 때문에 내부 회의에서의 인사이트를 찾아내려고 노력했다. 내부 회의에서의 가장 큰 가치는 하지 않아도 될 회의를 없애주거나, 회의 시간을 단축하는 것이라고 생각했다. 하지만 Loom, Rewatch 등이 이미 asynchronous meeting 으로 이를 해결하고 있었다.
우리가 생각해낸 다른 솔루션은 회의 중 연관된 컨텍스트가 나왔을때 해당 컨텍스트를 resurfacing 해주는 툴이었다. 하지만 이 부분도, 이미 회의 플랫폼을 가지고 있는 incumbent 가 훨씬 잘 할 수 있는 아이디어라는 생각이 들었다.
결국 피봇을 하지 않으려면 Sales Call 에서의 사용 케이스를 더 면밀히 파고들어 JTBD (Jobs To Be Done) 에 맞는 workflow automation 에 초점을 맞췄어야 했는데, Founder Market Fit 이 높지 않다고 생각하여 피봇하게 되었다.
Summer 2023
Idea 3 까지 개발을 하고, 여름방학이 되었다. 이전까지는 학교 수업을 들으며 개발을 했지만, 드디어 모든 시간을 내 회사에 쏟을 수 있는 시간이 생긴 것이다. 2023년의 여름은 내가 창업을 처음 꿈꿨던 중학교 2학년 사춘기 이후부터 가지고 있었던, 거실에서 옹기종기 모여 하루종일 개발을 하는 로망이 실현된 시간으로 기억에 남을 것이다. 6월부터 8월까지, 계절학기를 들었던 기간을 제외하고는 Pensieve 만 생각하며 살았다.
벽에는 거대한 Scrum board 를 만들어 놓았는데, 내가 가장 좋아하는 미드 Sillicon Valley 등장인물 중 한명인 Jared 의 Scrum Board 를 최대한 비슷하게 따라했다.
방학 기간 중에는 여기 언급되지 않은, 가설 검증 과정 중 버린 아이디어들이 특히나 많이 있었다. Food Supply Chain 을 공부하러 새벽에 SF Market (샌프란시스코의 가락시장) 에 가기도 했고, 새로운 food delivery 시스템을 도입했을때의 음식 가격을 알아보기 위해 China Town 에서 가장 싼 메뉴였던 만두를 대량으로 시켜먹기도 했었다.
여름방학 기간 중에 가설 검증을 진행한 아이디어들 중, 개발을 결정하고 완료한 아이디어가 Idea 4, 5이다.
Idea 4. 대학 강의 실시간 번역툴
Period: 2023 년 7월
Background
어처피 회의록 서비스를 만들면서 실시간 번역툴을 개발했기 때문에, 날카로운 usecase 에 맞게 번역툴을 만들어보면 어떨까 생각했다. 영어로 된 대학 강의를 들을때 실시간으로 번역 및 요약이 되면 강의 내용을 이해하기 쉽고 월에 3만원은 지불할 것 같다는 유저 인터뷰 내용을 바탕으로 제품을 개발하기로 결정했다.
Hypothesis
대학 영어 강의 중 실시간으로 번역 및 요약이 된다면, 카이스트/포스텍 등 영어로 전공 수업을 듣는 학부생들이 월 $30 을 지불하고 서비스를 사용할 것이다.
Progress
일주일만에 빠르게 개발했지만, 결국 외부에 런치를 하지는 않았다.
Learnings
이 아이디어는 유일하게, 우리가 배운 점이 없다고 생각하는 아이디어이다. 개발을 했으면 런치를 했어야 하는데, mvp를 만들고보니 제품이 너무 별로였다. 실시간 통역이 꽤 빠른 속도로 되기는 했지만, 대학 강의에 초점을 맞추기 위해서는 개발 기간이 길어질 것이 눈에 보였다. 그리고 결정적으로 나와 코파운더 모두 타겟 시장과 거리가 먼 미국 대학에서 공부를 했고, 타겟 유저인 한국 대학의 공대생과 거리가 멀었기 때문에 이 프로젝트는 개발만 하고 런칭을 하지 않은채 종료가 되었다.
하지만 우리가 이 제품을 전혀 예상치 못하게 요긴하게 쓰는 계기가 있었는데, 이는 이후 섹션에서 등장한다.
Idea 5. Admin Panel 을 AI 가 대체하는 툴
Period: 2023 년 7~8월
Background
방학 기간 중에 대부분 개발을 하긴 했지만, SF/South Bay 에서 매일 같이 열리는 AI 행사들 중 몇개를 참석하기도 했다. 그 중 하나가 7월에 Stripe 본사에서 열렸던 Stripe AI Day 였다.
Stripe 에서 Agent 를 활용하여 번거로운 과정을 자동화하는 데모를 보여줬는데, 당시 코파운더가 이미 퇴사한 스타트업에서 Admin Panel 이슈를 해결해달라고 지속적인 연락을 받고 있던 상황이었다. 내가 하는 대신 이를 Agent 로 자동화시켜버리면 어떨까? 라는 아이디어를 제안해주어서 논의를 시작하게 되었다.
Hypothesis
Retool 처럼 admin panel 을 쉽게 만들어주는 툴이 아닌, AI Agent 에게 database 접근 권한과 API endpoint 를 주고 (적절한 권한에 따른 human oversight 아래) admin task 를 채팅 인터페이스로 실행하게 한다면 회사는 admin panel 을 개발할 일이 없을 것이고, 우리 서비스를 이용하기 위해 돈을 낼 것이다.
아래 데모 영상에 나온 것처럼, “7월 7일에 결제한 모든 유저에게 각 유저가 결제한 금액만큼을 store credit 으로 돌려줘“ 와 같은 admin panel task 를 agent 가 처리해주는 방식이다.
Progress
이 아이디어도, 개발하기 전에 데모 영상부터 만들고 $500/month 를 지불할 기업을 찾아서 LOI 를 싸인했다. 고객이 생긴 상태에서 개발을 시작했고, 개발이 끝나기 전까지는 우리가 수동으로 admin panel 이슈 처리를 대신 해주었다.
Learnings
실제로 테스트를 해보니, 해당 스타트업의 PM이 보내는 채팅 메세지의 90% 는 데이터 분석에 관한 쿼리지 admin panel 에 관한 쿼리가 아니었다. 우리가 생각한 것보다 admin panel 쿼리 빈도가 훨씬 적었던 것이다.
그리고, admin panel 도 80:20 법칙을 따른다는 것을 발견했다. admin panel 의 20% 의 기능들이 80% 의 빈도로 쓰이고, 나머지 80% 의 기능들은 20% 도 쓰이지 않는다는 것이다. 그리고 그 20% 의 기능들은, 사실 개발자가 1시간만 쓰면 개발이 가능한 기능들이었다. 그렇게 피봇을 하게 되었다.
Idea 6. AI Property Manager
Period: 2023 년 8~9월
Background
이 아이디어를 설명하기 위해서는 우선 한국과 미국의 부동산 관리 시장의 차이를 간단히 짚고 넘어가야 한다. 한국은 많은 사람들이 아파트에 거주하고 있고, 아파트 관리는 하나의 업체가 도맡아서 한다. 하지만 미국은 사람들이 대부분 단독 주택에 살고, 각 단독 주택은 개별 Property Manager 가 있다. Property Manager 는 부동산 중개사와는 다른 개념으로, 집을 사고 파는 것을 제외하고 집과 관련해서 생기는 거의 모든 문제를 해결하는 사람이라고 생각하면 편하다.
예를 들어, 수도관이 터지게 되면 임차인이 Property Manager 에게 연락을 하고, Property Manager 는 근시일 내에 문제를 해결할 수 있는 가장 싸면서도 신뢰도가 높은 배관공을 찾는다. 이렇게 배관공을 찾으면 견적서를 받고 임대인에게 연락하여 비용을 지불해도 되는지 컨펌을 받는다. 임대인이 동의한다면, 배관공을 보낼 시간을 임차인과 논의하여 결정하고 배관공을 보낸다.
위에서 느껴지는 것처럼, 하나의 이슈를 처리하는데 적개는 몇번에서 많게는 수십번의 연락을 돌려야 한다. 이 때문에, 일반적인 Property Manager 는 한꺼번에 30채의 주택만을 관리할 수 있고, 각 주택으로부터 월세의 3~10% 를 보수로 받는다. 보수가 꽤나 크기 때문에, Property Management (PM) 시장은 미국에서만 40조가 넘는 큰 시장이다.
Hypothesis
우리의 아이디어는 간단했다. PM 소통 과정 및 PM 이슈를 해결하는데 적합한 사람을 찾는 과정을 AI Agent 로 자동화하여 한번에 30채가 아닌 300채를 관리하게 할 수는 없을까?
우리는 이 아이디어가 단순히 Property Manager 가 더 많은 돈을 벌게 해주는 것을 넘어서 임차인에게 더 나은 주거 환경을 제공해준다고 생각했다. 이는 우리가 이전에 언급된 아이디어들과 가장 다른 이 아이디어를 생각하게 된 동기이기도 하다. UC Berkeley 학생들 대부분은 2학년때부터 기숙사를 떠나 학교 주변에서 아파트를 구해 거주를 하는데, 코파운더는 주차장 문제로, 나는 고장난 블라인드 문제로 몇주째 PM 회사와 연락을 주고 받은 적이 있다. 미국의 PM 은 속도가 느리고 불친절하기로 유명한데, 이는 한번 집 계약을 하고 나면 어처피 임차인이 긴 기간 집을 떠나지 않으니 PM 회사가 이슈를 빠르게 처리할 동기가 부족해서 그렇다.
만약 AI 로 소통과정 및 contractor 를 구하는 과정을 자동화하면 임차인과 PM 에게 모두 좋은 서비스를 만들 수 있을 것이라 생각했다.
Progress
가장 큰 문제는, 우리가 PM 시장에 대해서 잘 모른다는 것이었다. 그래서 이번 아이디어는 우리가 이제까지 진행했던 아이디어 중에 가장 빡세게 가설검증을 진행했다. 가설 시트를 따로 만들어 가장 리스크가 큰 가설부터 나열을 했고, 하나하나 직접 검증을 했다. 검증을 하는데에만 3주가 걸렸는데, 이 기간 중에는 폭풍을 뚫고 Irvine, California 로 출장을 갔던 기간도 포함이 된다.
학교가 개학하기 불과 몇 일전, 코파운더 어머니의 여러 지인분들이 Property Manager 로 근무하신다는 것을 듣고 개학하기 전에 출장을 가서 이 분들을 만나뵙기로 했다. 하지만 공교롭게도, 우리가 방문하는 시기에 맞춰 84년만에 Irvine 에 허리케인이 닥친다는 뉴스를 보게 되었다. 비행기까지 결항되어 표를 구할 수가 없었는데, 개학을 하면 가기가 힘들었기 때문에 우리는 위험을 무릅쓰고 차를 끌고 Irvine 을 가는 결정을 내렸다.
지금 생각해보면 어떻게 갔는지 모르겠다. 영상에 보이는 것처럼 점점 아래로 내려갈 수록 강한 비가 몰아쳤다.
다행히(?) 허리케인보다 더 빨리 Irvine 에 도착하여 허리케인이 지나가자마자 Property Manager 분들을 만나고 다녔다. 여기서 우리가 이전에 만든 실시간 번역기 (Idea 4) 가 요긴하게 쓰였는데, 만나는 모든 Property Manager 가 중국에서 이민을 오신 분들이라 미팅이 중국어로 진행되었다. 중국계 미국인인 코파운더가 미팅을 진행하고, 나는 옆에서 우리가 만든 실시간 번역기를 보며 대화의 흐름을 이해했다.
가설 검증의 마지막 단계로, 우리는 우리가 직접 Assistant Property Manager 가 되어 이슈들을 해결하기 시작했다.
위 이미지처럼 Property Manager 가 관리하는 주택에 문제가 생기면 우리에게 연락을 주셨고, 우리는 그 이슈를 우리가 직접 해결하면서 어떻게 AI 로 자동화를 할 수 있는지 알아보았다.
Learnings
최근에 탄생한 많은 PM 스타트업들이 우리가 해결하고자 하는 문제를 인도, 필리핀 등지의 overseas worker 로 해결하고 있다는 것을 알게 되었다. 놀랍지 않게도, AI 를 사용해서 자동화를 하는 것과, 이런 해외 노동자를 통해 자동화를 하는 것에 큰 비용 차이가 나지 않았다.
이는 통상적인 Customer Service 와 대비가 되는 지점이었는데, 한국의 배달 업체가 CS 티켓을 처리할 경우 인도/필리핀의 노동자를 고용하기가 상당히 어렵다. 한국어로 대응을 해야하고, 해당 회사의 제품에 대한 교육도 진행을 해야하기 때문이다. 하지만 PM 티켓 처리는 1) 언어가 영어이고 2) 작업을 수행하기 위해 교육을 받아야 하는 점이 크게 없다는점에서 해외 노동자를 고용하기 매우 수월했다.
마지막으로, Marble 등의 회사들이 이미 AI 를 도입하여 PM 시장을 혁신하고 있었는데, 이러한 회사들이 이미 우리가 생각하고 있는 pricing point 와 비슷한 가격을 제시함에도 성장속도가 빠르지 않다는 것을 알게 되면서 이 아이디어를 접게 되었다.
Idea 7. Google Slides for Teachers
Period: 2023년 10월
Background
나는 3Blue1Brown 채널을 매우 좋아한다. 직관적으로 이해하기 어려울 수 있는 STEM 분야 개념들을, 고퀄리티의 애니메이션과 시각화를 통해 알기 쉽게 설명해주는 채널이다. 최근 Gen AI 의 발전양상을 보면서, 문득 이제는 LLM 을 이용해 누구나 3Blue1Brown 같은 시각화를 할 수 있지 않을까? 라는 생각을 하게 되었다.
그리고 이것이 가능하게 되면, 이러한 기술을 주고 싶은 첫번째 대상은 강의자료를 준비하고 정기적으로 강의를 하는 STEM 분야 교수님들이었다. UC 버클리의 많은 이공계 교수님들은 강의를 할때 아이패드를 화면 공유하고, 아이패드에 수식을 쓰면서 강의를 하셨다. 글씨체가 Latex 수식처럼 깔끔하지 않다보니 가독성이 떨어질때도 있었고, 강의 속도에도 제한이 생겼으며, 무엇보다 시각화가 필요한 개념이 있을때 손수 그림을 그리거나 이미 만들어진 이미지를 가져와야하다보니 제한이 많이 생겼다.
Hypothesis
LLM 을 이용해 Prompting + 간단한 다이어그램을 input 으로 넣어 3Blue1Brown 같은 애니메이션을 생성할 수 있을 것이다.
이러한 Google Slides for STEM Teachers 를 만들면, 학교가 구매할 것이다.
Progress
3blue1brown 은 본인이 직접 개발한 manim 이라는 애니메이션 엔진을 사용하여 영상을 제작한다. 그래서 LLM 으로 manim 코드를 생성하도록 간단한 toy project 를 몇일 동안 진행해보았고, 꽤 높은 퀄리티의 애니메이션이 생성되는 것을 보고 가설 1을 검증했다.
가설 2에 대한 검증을 빠르게 하기 위해, 제품을 하나도 만들지 않은 상태에서 마치 이런 제품이 존재하는 것처럼 demo 영상을 만들었다.
그리고나서 버클리의 수학/물리 교수님 20분을 만나러 다녔다.
Learnings
우선 교수님들이 어떻게 강의 자료를 준비하시고 강의를 진행하고 계신지 여쭤본다음, 아래 2가지를 여쭤보았다.
1. 교수님들이 제품이 개발되기도 전에 $50 로 pre-order 하실 생각이 있으신지
2. 런치 후 $50/month/course 를 개인적으로 지불할 의향이 있으신지
하지만, 우리 제품에 가장 열정적인 교수님조차 1은 힘들었고 2도 가격이 너무 높다라는 의견이 지배적이었다.
교수님 개개인에게 과금을 하거나 교수님이 쓰시는 소프트웨어로 학교에서 비용을 지불하다보면 시장 규모가 너무 작겠다라는 생각이 들었고, 결국 학생 단위로 결제를 할 수 있는 제품을 만들어야겠다는 생각을 하게 되었다.
Idea 8. ?
Period: 2023 년 10월 ~ Present
8번째 아이디어는 현재 진행중인 아이디어이다. 현재 진행중인 아이디어는 아직 결론이 나지 않은 만큼, 이 글에서는 구체적으로는 다루지 않으려고 한다. 이전 아이디어에서 얻은 인사이트를 활용하여 교육 도메인에서 이어서 개발하고 있고, 다음학기부터 UC Berkeley 에서 가장 큰 수업인 CS 61A (프로그래밍 기초 수업이며, 학기 당 1500명이 듣는다) 가 공식적으로 우리의 제품을 사용하여 수업을 진행하기로 하였다.
아직 진행중인 아이디어인 만큼, 이 제품에 대한 소개는 다음번으로 미루겠다.
Discarding good ideas in search of great ones
올해 IPO 한 회사들 중 테크업계의 가장 큰 주목을 받은 회사를 꼽으라 한다면 많은 이들이 Instacart (미국에서 대신 식료품 장보고 배달해주는 서비스) 를 고를 것이다. Instacart 의 창업자 Apoorva Mehta 는 Instacart 를 만들기전에 20개가 넘는 제품을 만들었다. 토스는 비바리퍼블리카의 9번째 제품이었고, 그 앞 여덟 번의 시도는 실패였다. 두 회사 모두, 앞선 실패들은 우리가 알고 있는 이 회사들의 서비스인 식료품 배달 시장 (Instacart) 혹은 핀테크 시장 (토스) 과는 아예 관련없는 아이디어들이 많았다.
지난 1년을 정의하자면, 나는 “discarding good ideas in search of great ones.“ 라고 정의하고 싶다. 솔직히 말해 피봇을 하면서 넘어가기로 결정한 아이디어들이 나쁜 아이디어는 아니었다. 위 아이디어들 중 절반 이상은, 열심히 개발한다면 연 매출 10억 이상 낼 수 있는 제품으로 키워낼 자신이 있다. 하지만, 우리가 특정 아이디어를 버린 이유는 그 아이디어가 충분히 위대하지 않아서였다.
Apoorva Mehta 가 그의 20번이 넘는 피봇을 돌아봤을때, 가장 크게 느꼈던 교훈은 다음과 같다.
The reason to start a company shouldn’t be to start a company, but should be to solve a problem which you truly truly care about.
우리는 인류에게 큰 영향을 미치는 문제이면서 우리가 잘 풀 수 있는 문제를 풀기 위해 창업했다. 이 과정 중에서, 세대를 넘나드는 Generational Company 를 세우고 싶다. 그러기 위해서는 과감히 좋은 아이디어를 버리고 위대한 아이디어를 선택하는 용기가 필요하다고 생각한다.
Good ideas aren’t enough—you need great ones.
여러번의 피봇을 통해 생긴 점(dot)들을 이어가면서, 나에 대해서 더 많이 알아가게 되었고 Founder-Market Fit 의 중요성에 대해서도 느끼게 되었다.
조급함을 버리고 나를 향한 길을 걸어가려한다. 점점, -1 에서 0에 가까워지고 있다.
끝내며.
우리의 여정이 얼마나 전달이 되었을지 모르겠다. 여기까지 읽으셨다면, 당신은 우리의 여정에 관심이 많은 사람일 것이다.
자신의 길을 아는 사람에게, 모든 사건은 운명적이다. 이것이 운명처럼 느껴진다면, yoonseok@berkeley.edu 로 연락달라.
2024년은 더 유난할 것 같다.
여러분에게도 유난한 한해가 되기를.
Substack Substack 글들은 영어로만 쓰려고 생각했었는데, 앞으로는 그런 제한을 두지 않으려고 한다.
“런치“ 의 기준은, 단순히 소프트웨어 제품 런치 뿐만 아니라 어떤 종류이든 일종의 서비스 런치한 것으로 정의했다. 예를 들어 Idea 7 에 우리가 개발한 소프트웨어는 없었지만, 우리의 workflow 를 자동화하기 위해 우리의 노동력을 제공하면서 고객의 문제를 풀었기 때문에 런치를 한 것으로 정의했다.
코파운더 Jack 이 2022년 12월에 조인해서, Idea 1 을 제외하고 모든 아이디어를 같이 이끌어주었다. Jack 이 없었다면 이렇게 많은 제품들을 빠르게 개발하지 못했을 것이다. 지난 1년간 곁에 있어준 Jack 이 너무 고맙다.
그리고, 위 제품들 중 Idea 6 이전의 제품들은 우리 둘만 개발한 제품이 아니다. Dooho Lee, Sanmaru Um, Tinah Hong, Suyeong An, Kitae Hwang, Deokhaeng Lee 는 모두 적어도 1개의 프로젝트에 참여해서 기여했던 사람들이다. 나를 믿어주고 함께 제품을 만들어주어서 고맙다. 짐시나마 우리팀에서 일했던 기억이 좋은 영향을 주었다면 좋겠다.
“React를 Vanilla JS 대신 사용해볼까?” 라는 주제로 Complex Search 를 한다고 생각해보자.
Q (Question)는 목적이 되는 지식에 대한 질문이다. 위 예시에서는 “React를 Vanilla JS 대신 사용해볼까?” 가 될 것이다.
Q hat: 은 해당 질의에 대한 답을 찾기 위해 우리가 쪼개어 던지는 (유사한) 새끼 질문들이다.
예를 들어, React를 Vanilla JS 대신 사용할지 결정을 하기 위해서는 JS 가 무엇인지 (Q1 hat), React가 무엇인지 (Q2 hat), 현재 우리의 JS 기반 software를 React로 대체하는 경우 시간이 얼마나 들지 (Q3 hat) 등이 있을 것이다.
여기서 Q1, Q2, Q3 가 아닌 추정치를 의미하는 hat (^ 기호) 를 붙인 이유는 질문의 길이가 너무 길어져서 검색에 용이하지 않은 경우 및 질문을 명확하게 인지하지 못 하는 경우 우리가 가지고 있는 질문을 추정하는 질문들로 검색을 할 수 밖에 없다고 생각했기 때문이다.
P (Page): Q hat 을 검색했을때의 결과로 얻어질 수 있는 page.
하나의 Estimated Question 에 여러개의 page가 결과로 나타날 수 있다.
I (Information): P 에 존재하는 정보들 중 Q 에 대한 답이 될 수 있는 정보
S (Sub Knowledge): I 의 조합들로 얻어지는 sub knowledge
Root Question에 대해서 partially answerable 한 knowledge 들.
ex) React와 Vanilla JS의 각 장점 및 단점
K (Knowledge): Sub Knowledge 들을 구조화하여 Root Question에 대한 답을 포함하는 지식
이렇게 검색을 하는 과정에서, 하나의 Session 을 유저가 웹 서핑을 지속적으로 하는 시간으로 정의한다면 이 모든 과정이 하나의 세션에서 진행이 될수도, 여러개의 세션으로 나눠서 진행될 수도 있다. 이를 다이어그램에서 Day 1, Day 2, Day 3… 로 표현하였다.
이렇게 Complex Search Problem 을 도식화하고, 유저 그룹을 명확히 정의했다.
https://www.mirror.work 에서 비슷한 접근을 하고 있다.
너무 재미있는 글이었습니다. 올 한해도 유난한 도전을 하시기를 기원합니다!
멋지다 윤석아!! 우리가 EMNLP에서 만난게 엊그제 같은데 그간 이렇게 알차고 밀도 있는 시간을 보냈다는게 놀랍고 존경스럽다! 그간 경험을 몰입력 있는 스토리로 써줘서 고마워ㅋㅋ 읽으면서 덕분에 많은 인사이트를 배웠어! 유난한 도전이란 책도 어제 다 읽던 참이었어서 글 제목이 특히 이목을 끌었네ㅎㅎ
아무튼 나도 자극 받아서 더 빠르게 가설 검증하고 더 위대한 아이디어를 좇아야겠어 💪 Idea 8(+) 다 응원하고 배우는 점들 계속해서 공유해주길 ㅎㅎ 새해 복 많이 받고 다 잘되길🔥