Over-simplification

저도 새롭게 스타트업 v1 출시를 위해 달려가고 있지만 아직도 가끔 멘토링 부탁을 받게되면 시간이 되는 한에는 창업자 분들을 만나보고 있습니다. 저도 다시 창업자가 되어서 보니 요새가 GOAT의 엔지니어링 리더로서 멘토링을 할때 보다 더 창업자분들 고민에 공감을 하고 조금더 현실적인 이야기를 해드릴수 있는거 같아서 보람을 느끼면서도 자주 비슷한 질문을 받는거 같아 제 생각이 혹시나 같은 고민을 하고 계신 예비 창업자분들께 조금이나마 도움이 될까 해서 글을 써보네요.

새롭게 아이디어를 가지고 Product Development을 준비하는 팀들은 거의 대부분 제게 Tech Architecture 문제를 가지고 오시는 경우가 종종 있습니다 (그 팀 투자자 분들께 창업자분들이 부탁을 하고 그 투자자 분들중 제 지인이나 아는 회사가 있으면 제게 부탁이 오곤 합니다).

Native vs. Flutter / React

Postgress vs DynamoDB

GraphQL vs gRPC

Golang vs Java Spring

Redshift vs Snowflake

Etc.

주로 이런식으로 밸런스 게임을 하듯이 질문을 하시고 제가 둘중 하나를 골라주길 긴장하며 기다리시는 팀이 많습니다. 물론 GOAT나 Tinder가 성장하면서 시스템적으로 스케일을 해야만 하는 상황이 있었고 그 과정에서 이것 저것 시도/실패/성공을 많이 해봤기 때문에 제 나름대로의 의견이 있지만 저는 하나를 집어 선택해 드리지는 않습니다.

가장 궁금해하시는 한가지 질문에 주로 제가 선택을 했던 배경 설명과 선택을 하게 되었던 과정과 팀 구성 그리고 그 당시 나왔던 의견들과 제가 결정을 내린 이유과 결과 그리고 결과를 리뷰하는 프로세스 정도를 설명을 해드리는 편입니다.

예를 들면 제가 Native를 사용하여 GOAT / Tinder를 만들었기 때문에 왜 Native가 다른 솔루션들 보다 뛰어난지를 설명 드리고 그 결정을 내려주길 기대해주시는 분들이 생각보다 많은데 제가 중요하게 강조하는 부분은 problem-solving 과정 그리고 방법입니다. 쉬운 답은 없다고 생각합니다. 어짜피 native로 쓰던 dart로 쓰던 코드를 제대로 쓰지 않으면 좋은 프로덕트는 나오지 않으니까요. 

얼마나 성실하게 준비/공부하고 빠른 결정을 내리고 본인의 결정을 믿고 결과를 내느냐가 전부라고 생각합니다. 결과가 제대로 나오지 않는 다면 나오지 않은 이유에서 부터 다시 수정하고 다음 결정에 배운것을 적용하면 됩니다. 많은 분들이 걱정하시는것 보다 지금 Tech 자체가 너무나 많은 발전이 되어 있어서 어떤 선택을 하던 막다른길이 나오는 일은 적다고 생각합니다.

저도 이번 프로젝트에선 GOAT/Tinder에서 한번도 사용해보지 않은 tech solution들을 써보며 준비하고 있습니다 ㅎㅎ 충분히 가능할고 재밌을거 같았는데 리스크가 크다고 판단을 내려 못써본 기술들 위주로 친구들과 재밌게 풀어 나가는 중입니다. 저희는 저희가 만들때 재밌어야 뭐든 진행이 되더라고요.

그럼 메이커분들 모두 파이팅하시고 그럼 좋은 한주 보내시길 바랍니다! :)