얼마집 제품 로그 1 (입사 - MVP 시절)
안녕하세요, 한국프롭테크의 코파운더이자 프로그래머로 일하고 있는 서대원이라고합니다. (저에 대한 자세한 정보는 여기) 2022년 7월, 드디어 한국프롭테크가 시드 투자를 마무리할 수 있었는데요🎉
기념으로! 제가 입사 후 지금까지의 제품 개발 로그를 남겨볼까 합니다. 저도 다양한 회사에서 이런저런 일을 해왔지만, 이렇게 아예 바닥부터(첫번째 커밋부터) 제품을 개발했던 경험은 이번이 처음이라… 약 1년에 걸친 고민들, 내렸던 의사결정들을 공유할 수 있다면 저에게도 정리가 되고 누군가에게는 도움이 되지 않을까 해서요!
아 참, 현재 한국프롭테크는 채용을 진행하고 있습니다! 많은 관심 부탁드려요!
https://career.koreanproptech.com
첫번째 MVP
저는 2021년 7월 12일, 대표님이 회사를 설립한지 채 3개월이 안 되었을 무렵에 한국프롭테크의 두번째 구성원으로 입사했습니다.
당시의 제품은 MVP의 형태로, 집주인이 본인의 집을 직접 등록하면 중개사가 집의 가격을 역제안하는 기능을 가지고 있었습니다. 이는 집주인이 본인 자산의 가격을 최대한 투명하게 알 수 있게 하기 위한 의도였습니다.
이 MVP는 대표님이 디자인/개발 에이전시와 계약해 제작했고, React와 Nest를 이용해 작성되어 있었습니다. 입사하자마자 에이전시로부터 이 프로젝트를 인수하고 이런 저런 유지보수를 진행하긴 했지만, 이전까지 저의 주요 경력은 Python 서버 애플리케이션 개발이었기 때문에, 웹 개발이나 Node 같은 Javascript 생태계에 대해서 거의 알지 못했고, 시작부터 많은 걱정을 할 수 밖에 없었습니다…😵💫
두번째 MVP
첫번째 MVP를 통해 중요한 가설을 증명할 수 있었습니다. ‘집주인이 온라인에 직접 자기 집 정보를 상세하게 올리는데 거부감이 없을 것이다’는 가설이었습니다. 갓 태어난 MVP는 유저 입장에서 매우 낮은 완성도나 신뢰도를 가질 수 밖에 없었음에도 불구하고, 우리가 타겟한 소수의 유저는 직접 본인의 집의 정보를 공개했습니다.
그러나 중개사가 역제안을 해 거래를 성사시킨다고 하더라도, 또 다른 집주인이 이 플랫폼에 계속 남아있지 않는다면 중개사 역시 떠날 것이고, 플랫폼 내에서 거래도 이루어지지 않을 것이라는 생각도 하게 되었습니다. 그래서 거래와 관련 없는 시점에도 집주인이 계속 머무를 수 있는 무언가를 만들어 보기 위해 두번째 MVP를 기획했습니다. 이때가 약 7월 말 경이었습니다.
여러 부동산 커뮤니티를 돌아다니며 모니터링한 결과, 집주인이 가장 흥미를 느끼는 정보는 역시나 본인 집의 가격이라는 결론을 내렸습니다. 그래서 두번째 MVP는 거래 당사자들이 매수/매도 호가를 직접 입력, 확인하는 집 가격 발견 서비스로 기획했습니다(주식 거래 앱의 호가창을 생각해보면 익숙하실 것 같습니다).
개발 시작
물론 저는 기획을 하면서 동시에 두번째 MVP를 어떤 시스템 위에 구현해야 할지도 같이 고민해야 했고, 이 고민은 자연스럽게 ‘기존 MVP의 처분을 어떻게 할까’에 대한 고민으로 이어졌습니다. 그동안의 경험 때문에 동적 언어의 단점을 자주 생각하다보니, Typescript를 포함한 강타입 언어에 대한 관심도 있었던 것은 사실이었습니다. 그래서 잠시간 기존 Typescript 환경의 프로젝트를 그대로 가져갈까 생각하기도 했습니다만, 다음 문제가 있었습니다.
- 기존 MVP는 에이전시의 커스텀 프레임워크로 만들어졌음(React, Nest를 감싸서 인증 등의 주요 기능을 프레임워크 안에 구현한 상태)
- 나는 Node 서버를 개발-운영해본적이 한 번도 없음(…)
오픈소스 프레임워크가 아닌, 특정 회사에서 만든 커스텀 프레임워크 위에서 프로젝트를 유지보수하는 것은 (내가 모르는 부분이 너무 많을테니)좋은 결정이 아니라는 생각과, 무엇보다 두번째 이유가… 장애 대응을 못해서 새벽 3시에 컴퓨터 앞에서 끙끙대고 있을 스스로를 상상하다가… 결국… 고민 끝에 서버 플랫폼은 저에게 가장 익숙한 Python을 선택했고, 대신 타입 힌트를 적극적으로 사용하자고 마음 먹었습니다. 웹 프레임워크는 FastAPI를 선택했고, 웹 애플리케이션 도구로는 그나마 깔짝거려본 경험이 있는 TypeScript/React를 선택했습니다.
클라우드 벤더는 제가 주로 사용하던 AWS로 선택했고, 기존 MVP가 배포되어 있던 다른 AWS 계정(에이전시가 생성한)으로부터 도메인, 애플리케이션, 데이터베이스 마이그레이션을 진행했습니다.
Python 애플리케이션은 가장 단순하게 Fabric을 이용해 EC2(systemd)에 배포했습니다. 처음에는 Docker등의 컨테이너 혹은 Serverless 플랫폼도 잠시 생각했었지만, 당시 상황에서(현재까지도) ALB + EC2 + AMI 이외의 기술을 도입해야 할 필요성(문제 의식)을 느끼지 못했습니다. 제가 컨테이너/서버리스 기술에 경험이 엄청 많은 것도 아니었고, 현재 상황에서 기술 스택의 복잡도를 지나치게 늘린다는 느낌도 받았습니다.
데이터베이스는 PostgreSQL-RDS를 이용했습니다. PostgreSQL-Aurora 클러스터와 고민을 했었는데요, Aurora에는 프리티어를 적용할 수 없을 뿐더러, DB를 클러스터로 운용하면 단일 인스턴스를 운용하는 것에 비해 비용 차이도 클 것이라는 생각도 들었습니다. 시스템이 일정 규모 이상일 때는 이 차이가 전체 비용에 큰 영향을 주지 못할 수도 있겠지만, 저희 처럼 전체 인스턴스가 5개도 되지 않는 신규 서비스에게는 이 차이가 꽤나 크게 다가왔습니다. 게다가 가용성을 위해 Aurora 클러스터를 선택하면 커넥션 풀 관리를 더 신경써서 해야했고(여기를 참고), MVP 수준의 앱을 개발해야하는 당시 상황에서 이는 오버엔지니어링처럼 느껴졌습니다.
런칭
물론 회사에는 여전히 대표님과 저 둘 뿐 디자이너는 없었기 때문에, 지인 분과 외주 계약을 맺고 함께 제품을 만들기 시작했습니다. 개발 기간을 최대한 단축하기 위해, 디자이너의 완성되지 않은 중간 작업부터 같이 보면서 코드로 빠르게 옮겼습니다(나중에 여러번 수정하는 것을 감수하더라도 이 편이 훨씬 빨랐습니다). 도메인 이전 과정에서 3–4시간의 다운 타임이 있었지만🥲 어찌어찌 두번째 MVP를 런칭했습니다. 기획을 시작한지 약 한 달 뒤인, 2021년 8월 말이었습니다.
다음
엄청 길게 썼다고 생각했는데 아직도 겨우 입사 후 2달 시점이라니… 다음 글에서는 채팅방을 붙이게 된 계기와, 웹으로된 MVP를 버리고 앱을 런칭하게된 이야기를 적어보려고 합니다!
