2024.10.26 과금모델

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

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

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

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

시스템으로 권한 관리를 할 때의 원칙은 모두가 알고 있다. 리소스(그것이 사람이든 기계든)에게 1) 가능한한 최소의 권한을 2) 역할보다는 속성이나 관계 기반으로 완전히 세세하게 부여하고, 3) 필요 없는 권한은 최대한 빨리 자동으로 회수한다 등등의 원칙을 이야기 하는데, 대체 지구상에 이걸 진짜 원칙대로 지키는 회사가 있기는 한지 궁금하다. 빅테크들도 제대로 못지킬 것 같은데.. 한 펜타곤이나 CIA 이 정도나 되면 시스템이 저런 원칙을 지키고 있을지 궁금하다. 현실적으로는 귀찮아서 많은 권한을 꽤 넉넉하게 열어두고 권한회수도 제대로 안되고, 더이상 해당 업무를 맡지 않는 담당자가 그대로 다시 시스템 들어올 수도 있고 이런 식으로 개판인데, 뭔가 종합적으로 이런 부분을 자동으로 진단/실행 해 줄 수 있다면 그것도 가치있는 서비스일 것 같다. (나는 안할거임) 그래도 새로운 마음으로 새로운 회사에서는 모든 것을 원칙에 맞춰서 최소권한으로 운영해야지 하다가 오늘 하루 종일 IAM 지옥에 빠졌다. 예전같았으면 그냥 나이브하게 키/시크릿페어 환경변수에 박아놓고 GitHub Actions에서 돌리고 이랬을텐데, 좀 더 근본있는 방법으로 OIDC로 통신하고 하는 방식으로 열심히 구현에 성공했다. 오늘의 결론: 어쩌다 그렇게 되었는지는 대충 알겠지만 IAM을 어떻게 좀 대혁신하지 않으면 AWS에게도 언젠가 큰 업보로 돌아올 것 같다..