WEAVE라는 대학생 미팅서비스를 개발하고 출시하기 까지 과정에 대한 회고글 입니다.
퇴사후 공백기
퇴사후 잠깐 공백기가 생기게 되었는데, 뭐라도 만들고 싶어서 미칠것 같았다. 그래서 사이드 프로젝트 개발을 계속 시도해 왔는데, 금방 흥미가 떨어져 좌절되곤 했다.
여태까지 중간에 그만두었거나, 더발전시키지 못한 사이드 프로젝트들을 되돌아 보면 다음과 같은 이유들이 있을것 같다.
- 페인포인트에 공감하지 못했다.
- 혼자하느라 금방 흥미가 떨어졌다.
이런 와중에 이전에 부트캠프에서 함께했던 도진님이 같이 사이드 프로젝트를 해보지 않겠냐고 연락 주셔서 무슨 서비스인지 듣지도 않고 바로 하겠다고 했다.
MVP 개발 1월
대학생 미팅 서비스를 개발하기로 했다. 디자이너 한분, AOS 개발자 한분, 서버 두명이 모여 개발을 진행했다. 회의는 월, 수, 금 짧게, 일요일 길게 진행했는데, 자주하는만큼 팀원들의 진행사항을 쉽게 파악할 수 있었고, 자주하는 만큼 일상속에 사이드 프로젝트가 잘 녹아들어갔다.
이전에 진행했던 사이드 프로젝트들의 경우 디자인이나 기획이 주어진대로 그대로 따라가는 형태가 대부분이었는데, 왜 이 기능이 필요하지 라는 의문이 드는 케이스가 있어서 아쉬웠었다. WEAVE에서는 기획단계부터 참여했던 만큼, MVP기능을 선정하고 디자인 하는 과정에서도 의견을 많이 낼 수 있어서 동기부여가 잘됐다.
MVP 개발 2월
기술스택과 아키텍처를 협의하고 본격적으로 개발에 들어갔다. 기존에 사이드 프로젝트를 진행하면서 만들어 두었던 코드 템플릿을 토대로 서버 개발을 진행했다. 도진님은 회사일 때문에 바쁘셔서 많이 참여는 못하셨지만 리뷰는 빠르고 꼼꼼하게 남겨주셔서 놓친부분들을 쉽게 파악할 수 있었다.
IOS개발자 두분이 중간에 합류해 주셨는데, 싱크를 맞추는 과정에서 내가 API명세에서 놓쳤던 부분들을 많이 알 수 있었다. 에러코드 관리와 명세가 아쉬웠고, 다양한 케이스들에 대한 테스트베드를 Swagger상에서 제공할 수 있다는 점을 처음 알았다.
JIRA를 사용하는데 있어서 테스크가 유스케이스 별로 관리되는것이 아니라 각자 파트 별로 단순하게 관리되는 점이 아쉬웠다. 어떤 작업들을 진행하고 있는지 회의로 한번더 파악해야 했었고, JIRA는 유명무실하게 사용되고 있었다. 사실 회의 주기가 짧고 비동기 소통이 꽤나 잘되고 있어서 크게 문제가 되진 않았는데, JIRA의 효용성에 대한 의문이 있었다.
MVP 개발 3월
본격적으로 출시를 앞두면서 MVP기능 개발은 대부분 완료가 되었다. AOS심사가 들어갔고, 개발서버와 별개로 배포서버 인프라를 구축했다. 대학생 서버 개발자 한분이 합류하셨다.
Terraform과 Terraform cloud를 통해 인프라를 배포했는데, 충분히 팀원들에게 Terraform의 활용법에 대해 공유하지 못한부분이 아쉬웠다. ELB가 unmanaged resource로 배포되었다.
AWS비용이 발생하기 시작했는데, 6~70달러를 웃돌았다. 최대한 프리티어로 맞추었지만 추가적인 EC2비용과 ELB로 인한 비용이 컸다. 해외 IP를 차단하기 위해 WAF를 사용했다.
3월 말에는 AOS 심사가 지연되었고, IOS도 심사에 들어갔다.
MVP 개발 4월
앱스토어, 플레이스토어에 모두 출시가 되었다. IOS 한분과 이전에 합류했던 서버팀원 한분이 나가셔서 친한 서버 개발자 지인을 데려왔다.
홍보를 했지만, 효과는 미미했고, 유저들을 확보하기 어려웠다.
팀원들과 몇가지 고민을 했다.
- 홍보가 미약했다. (인스타를 활용 안함)
- 유사 제품들과 차별점이 뭔지 모르겠다.
- 유저를 잘 모른다 (대학생 서비스인데 팀에 현직 대학생이 한명밖에 없음.
고민끝에 잠깐 서비스 개발을 중단하고 마침 디자이너 분도 학업때문에 이탈하게 되셔서 새로운 팀원을 모집하는겸 시간을 갖기로 했다.
Liked : 좋았던 점은 무엇인가?
짧은 회의주기
사이드 프로젝트는 동기부여가 가장 중요하다고 생각한다. 대부분 각자 학업, 현업이 있는 만큼 짬내서 작업을 해야 하는데, 동기부여 없이는 아주 힘들다.
처음에는 성대한 동기로 시작하지만 중간 중간 위기를 겪는다. 짧은 회의 주기(월,수,금,일)는 작은 성취를 팀원들과 공유하면서 지속적인 동기부여를 주기에 아주 좋은 방법이라고 생각한다.
코드 리뷰
나는 필요할때는 코드리뷰를 매우 적극적으로 하는 편이다. 몇몇 PR은 하나에 수십개가 넘는 코멘트를 주고받기도 했는데 도진님도 비슷한 성향이셔서 잘 맞았다. 주관을 개진할때는 확신을 가지고 하되, 상대방이 더 합리적이라면 누그러뜨리고 수용한다. 상대방에 대한 충분한 신뢰가 있었기에 가능했다고 생각한다.
Lacked : 아쉬웠던 점, 부족한 점은 무엇인가?
API 명세
에러코드, 다양한 케이스에 대한 테스트 베드를 Swagger상에 명세하지 못했다. Discord 서버 채널로 클라이언트 분들의 관련 문의가 들어올때마다 죄송한 마음이 들었다.
Swagger에 여러 케이스별로 테스트 베드를 만들어 내 명세할 수 있다는점을 나중에 알았다. 클라이언트 분들이 추가적인 문의 없이 개발할 수 있을 만큼 충분한 명세서를 만들자
빈약한 DDD
도메인 엔터티와 JPA 엔터티를 분리한 만큼 도메인에서 최대한 로직을 처리할 수 있게 설계할 수도 있었다. 초창기에는 그러지 못했고, Aggregate Root말고 모든 객체에 대해 Repository를 만들어 졌는데, 복잡도가 많이 높아졌고, Application 레이어로 도메인 로직들이 새어나갔다. 리팩토링을 통해 바로잡았는데, 다시 설계한다면 비슷한 우를 범하진 않을것 같다.
이외에도 기술적으로는 아쉬운점들은 많았는데, 사소하거나 방향을 조금만 바꾸면 해결할 수 있는것들이어서 생략해도 될것 같다.
도메인 명세
도메인 지식을 명세하는 문서가 있긴 했는데, 유명무실하게 관리되었다. 모두가 와이어 프레임만 보고 기능을 개발하다 보니 제때 수정사항을 문서에 반영하지 못한 부분도 있었고 와이어 프레임에 나타나지 않는 수정사항들을 파악하는데 추가적인 소요가 발생했다. 도메인 문서는 백엔드가 챙겨야할 중요한 부분중 하나라는 생각이다
Longed for : 앞으로 바라는 것은 무엇인가?
서비스 개발을 중단한 기간동안 여러 스타트업들의 아이디어 검증 방법, 성공사례, 실패사례 등을 살펴보았다. 공통적으로 아이디어 검증을 충분히 진행한 이후에야 개발을 진행한 케이스들이 많았다.
하지만 사이드 프로젝트들의 경우 자신만의 명확한 페인포인트를 해결하는데 집중한 케이스들이 많았다. 덕분에 규모가 크지 않았고, 타겟층이 확실한 만큼 유저도 수월하게 확보한 것 같았다.
위의 두가지 포인트를 잘 논의하면서 어떤 방법이 좋은 방향인지 논의해 봐야 할것 같다. 잠깐 서비스는 중단했지만, 여태 진행했던 사이드 프로젝트들 중 가장 완성도 높은 프로젝트였고, 좋은 팀원분들과 함께 했기에 괜찮은 결과물을 만들 수 있었다.
이제는 실제 유저를 확보하고 지속적으로 운영할수 있을만큼의 수익도 발생 시킬 수 있는 서비스 까지 가기 위해 고민해보고 방향을 더 논의해봐야 할 것 같다. 정말 필요한 기능만 린하게 개발할수 있게 충분히 아이디어를 검증하고, 이전에 아쉬웠던 점들을 보완해 좀더 견고하게 설계 할 수 있어야한다.