2024.10.28 폭리다매

IR자료에 다른 내용은 거의 완결성 있게 갖췄고 재무적 로드맵만 남았는데, 제품 고민에 집중하느라 지금까지 각잡고 생각을 안해봤던 것 같다. 그렇게 재무적 로드맵을 생각하려고 보니 자연스럽게 과금 모델을 고민하게 되었다. 원래는 막연하게 같은 워크로드로 따져서 AWS 비용의 몇퍼센트 정도를 이윤으로 남기자 이런 정도의 생각이었는데, 실제 시나리오를 몇 가지 넣어서 계산 해봤더니 규모의 경제가 잘 작동하지 않고 좀 더 나은 방법이 있지 않을까 생각을 해 보았다. SaaS(우리가 하려는건 그 중 PaaS지만) 과금모델 중 이제 흔하게 쓰이는 모델은 역시 유저 수에 비례하게 월 얼마 이렇게 돈을 받는 식인데, 보통 회사의 지출 여력이 사람 수에 비례할테니 무난한 방식으로 취급되는 편이다. 그런데 이 제품에는 그렇게 어울리지는 않는다는 생각이 들었다. 이 제품을 사용하게 될 사람은 주로 백엔드 개발자나 데브옵스/클라우드 엔지니어일 것 같은데, 또 이 제품이 잘 작동한다면 회사 입장에서 ...

IR자료와 실제 제품에 쓰일 컴포넌트의 디자인 외주를 맡기려고 간단하게 숨고에 올려보았는데 여러 사람들이 연락을 주셨다. 처음에는 대강 회사와 제품이 무엇을 하려는 것인지를 공유해 주고 디자인의 톤과 방향성을 잡아달라고 하면 될 줄 알았는데, 그렇게 요청하려고 문서를 쓰다 보니 처음에는 내가 진짜 원하는 것이 뭔지 직시하는 순간으로 느껴지고, 이윽고 내가 진짜 원하는 것을 나도 정확히 모른다는 결론을 내렸다. 그래도 내가 내 마음을 모른다는 사실을 안다는 것만으로 한발짝 전진한 것 같다. 레퍼런스 삼을만한 좋은 디자인들을 좀 더 보면서 생각을 해봐야겠음..

요 며칠 정신적으로도 신체적으로도 컨디션이 영 좋지 않았다. 둘째 태어나고 70일 좀 넘었는데 너무 전력으로 달린게 독이 된 것 같다. 사업이 구체화되면 될수록 빨리 가는 것보다는 스테디하게 오래 가는게 중요한 것 같아서, 당분간 페이스를 좀 내려봐야겠다는 생각이 든다. IR자료를 만든다고 하지만 그 대상이 시드투자자일수도 있고 코파운더일 수도 있고 초기멤버일 수도 있을텐데, 어차피 투자자가 아니라 조인할 팀원이더라도 본인의 인생과 기회비용 일부를 투자하는 것이라면 본질적으로 다를 것은 없다고 생각한다. 그런데 자료를 만들면서 드는 생각이 'IR에서 이 얘기를 하려면 가설이 어느 정도 실제 데이터로 실증이 되어야 하는데' -> '실제 데이터가 있으려면 이 부분까지를 만들어야지' -> '이 부분까지 만들려면 돈이나 사람이 필요한데?' -> '돈이나 사람을 끌어오려면 IR자료를 완성해야지' -> 'IR에서 이 얘기를 하려면 가설이 어느 정도 실제 데이터로 실증이 되어야 하는데' -> ... 이런 무한 도돌이표가 생기게 된다. 사실 닭와 달걀의 문제인데.. 전 회사 엑싯한 이후로 엔젤투자 제안이 들어오면 그래도 다 업계 후배들이라고 생각하고 시간을 내서 피칭은 들어보는 편이라서(아쉽게도 실제 투자까지 간 적은 없음) 제법 많은 다른 회사들의 IR자료들을 봤는데 보통은 저 루프의 어떤 부분이 헐거운 것을 기세로 돌파하려고 하거나, 아니면 악질적인 경우에는 아예 사기에 가깝게 치거나 하는 경우가 많았는데 이제 어느 정도 이해가 되기는 한다. 그래도 나는 그렇게 젊은 창업자들처럼 기세로 밀고가긴 싫고 내 입장이라도 투자하고 싶은 시나리오를 짜는게 결국 중요한 것 같다.

고교 동문들이 모여서 테크 컨퍼런스를 열어서 오전에 다녀왔다. 하루 종일 하는 행사였지만 70일 아기를 두고 하루 종일 갔다오는 것은 무리라 빨리 가서 오랜만에 보는 얼굴들 인사도 하고 명함도 돌리고 일부 세션만 듣고 나왔다. 근데 진짜 오랜만에 모교 가니 환골탈태했네.. 창업 준비중이라고 이야기 하고 어떤거 할거냐는 질문을 계속 받는데 아직은 한줄로 설명하기가 만만치 않다고 느껴서 오늘부터 다음주까지는 코딩보다는 IR을 고민하기로 했다. 슬슬 공동창업자 후보들도 찾아봐야 할텐데 그럴때도 자료는 필요하니 한번 빨리 제대로 만들어 볼 필요가 있는데, 확실히 10년 전에는 사업계획서나 IR자료가 뭔가 막연하고 이해가 안됐는데 이제는 확실히 뭐가 필요한지, 어떤 내러티브로 끌고가야 하는지, 킥을 어떻게 줘야 하는지 이런 것들이 느낌이 오는 것 같다. 이제 이렇게 짬바를 믿고 자만하다가 리얼월드에서는 털리게 될텐데.. 디자인 작업들이 재미는 있는데 내가 직접 하니 시간효율이 확실히 좋지 않아서, 이제 슬슬 외주로든 어떤 형태로든 좀 오래 같이 할 사람을 찾아봐야겠다.

여러가지 기술적 대상이나 방법론들에 관한 관점은 시간이 지나면서 많이 바뀌고 또 상황도 바뀌고 하기 마련인데, 시간이 지나도 별로 안 바뀐 것중 하나는 테스트에 관한 관점이다. 나는 과감히 TDD의 원칙 중 '테스트를 먼저 작성하라'는 안티패턴이라고 생각하는 편인데, 먼저 작성하라는 테스트가 유닛테스트인 경우 코드도 없이 설계가 결정되어버리는 문제점이 있고, e2e나 integration과 같은 더 거대한 단위의 테스트를 먼저 작성하는건 보통 쉽지 않다. 그래서 내가 작업하는 방식은 보통 다음과 같다: 1) 손가는 대로 일단 한 100~200줄 정도의 모듈 - 몇 개의...