2024.11.07 k8s

어젯밤에 첫째가 자꾸 발로 나를 차대서 거의 잠을 못잤는데 아침에 땡깡까지 부려서 컨디션이 완전히 망가졌다. 그 핑계로 일 하기 싫어서 오래 전 봤던 책을 다시 꺼내서 읽었다. [Release의 모든 것] 이라는 책(원제는 아마 Release it! 이었던듯)은 나름 이 분야에서는 고전, 혹은 정석과도 같은 책인데, 서비스를 배포하고 운영하기까지의 그 모든 과정에서 일어날 수 있는 일과 주의해야 할 일들을 모두 담아놓은 책이다. 원서는 2018년에 최신판인 2판이 나온 책이라 실제 기술 도구를 소개할 때는 약간 타임머신을 탄 기분이 들지만, 이 책에서 이야기하는 원칙들은 아직까지 모두 유효한 것들이다. 다루는 내용이 대단히 방대하면서도 압축적인 책인데, 번역의 단어선택들 중 몇 가지가 아주 야아악간 아쉽다는 느낌은 있다. 약간 단순화해서 이야기 하면, 내가 만들려는 제품의 궁극적인 목표의 형태가 이 책에 나오는 이야기와 원칙들을 전부 자동화해서 대신해주는 플랫폼이라고 해도 큰 과장은 아닐 것이다. https://www.hanbit.co.kr/store/books/look.php?p_code=B1820128661

IR자료 작성을 접고 2주만에 리포에 들어가 기억을 되살려 보는데 그간 외부 라이브러리나 패키지들이 많이 업데이트 되어 dependabot이 PR을 많이 만들어 놓은 것을 확인했다. 아직은 코드베이스가 크지 않아 모두 테스트를 통과해 있었고 딱히 깨지는 곳 없이 바로 올릴 수 있었다. 실제로 다른 회사들은 이걸 어떻게 대처하는지 궁금한데, 아예 워킹하는 버전에 고정해 놓고 올리지 않는 것을 택하는 경우가 절대다수일거라 생각한다. 내 현직장도 이런 모습에 가까운데, 괜히 올렸다가 어딘가 깨질 수도 있고 또 그런게 반복되다 보면 아예 breaking change를 몇 차례 ...

며칠 일지를 못 썼는데, 계속 사업계획서 다듬다 보니 뭔가 남길만한 별 특별한 일이 없었다. 요 며칠 육아가 고되기도 했고.. IR자료는 계속 다듬고 있는데 계속 보면 볼수록 헐거운 부분이 새롭게 발견되고 보강하고 고치고 하는 것의 연속이었던 것 같다. 하지만 2주나 썼으니 이제 이 정도에서 멈추고 다시 코딩으로 돌아가는게 맞을 것 같다. 그러면서 다음주부터 또 다시 사람들과 좀 만나는 일정들을 잡아 봐야겠다.

혼자 창업을 준비하면 어느 날은 CTO, 어느 날은 CPO, 어느 날은 CFO 이렇게 모드가 바뀌곤 하는데, 또 오늘은 CSO 역할이 되었다. 시장이나 경쟁업체 조사도 좀 더 자세히 하면서 여러가지 시나리오와 전략을 세워 보는데, 결국 고객을 어떻게 락인 시킬것인가에 대한 답을 찾아야 하는데 쉽지 않다. 오히려 '님이 이거이거 이렇게 개발해야 됨'인 상황이라면 개발한 시간이나 매몰비용이 아까워서라도 약간은 락인되는 효과가 있는데, 그런 유저에게 맡기는 요소를 최대한 없게 만드는 것이 제품의 목표라면 오히려 들어오는 것 만큼이나 나가는 것이 부담없어질 가능성이 크다. 언젠가 다른 회사가 유사한 제품을 낼텐데, 그러기까지 걸리는 시간이 어느정도일지는 잘 모르겠다. 큰 회사가 바로 따라오긴 쉽지 않겠으나, 이미 이 시장에 들어와 있는 스타트업들의 수가 적지 않고 어딘가는 꽤 빠르게 비슷한 피봇을 할 것이다. 우리 제품이 좀 더 나으리라고 생각하지만 경쟁은 언제나 불쾌한 일이다. 그러다 결국 가격경쟁으로 수렴하게 되면 박리다매나 치킨게임으로 갈 수밖에 없기 때문이다. 사업의 플랜 자체가 거의 다 온 것 같은데, 이 부분이 계속 고민이다. 폭리다매 하고 싶다..

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