사이드 프로젝트 런칭 후기

들어가며

얼마 전, 친구들과 사이드 프로젝트로 진행한 ShortBoost란 서비스를 런칭했다.

 

 

지금 터지는 인스타그램 릴스 찾기, 숏부스트 short boost

 

 대학교에서 친하게 지냈던 친구가 릴스 마케팅 교육 사업을 하고 있다. 단순히 교육에서 멈추는 게 아니라, 교육을 진행하며 얻은 인사이트로, 이를 IT 서비스화 하면 더 많은 사람들의 문제를 해결해 줄 수 있을 것이란 생각을 하더라.

 

 나는 2년 넘게 IT 회사에서 서버 개발자로 일하고 있다. 회사에서의 업무 대부분은 기존 프로젝트 유지 보수 및 신규 기능 추가 등이다. 그리고 DB 작업은 DBA가, 네트워크 및 인프라 세팅은 담당 팀이, 프론트는 또 다른 담당 팀이 하고 있다.

WAS밖에 안보여!

 그래서 항상 A-Z로 하나의 완결된 서비스를 내는 경험에 대한 갈망이 있었다. 친구와 뜻이 잘 맞아, 릴스 크리에이터를 위한 서비스를 만들어보자고 의기투합 해 작년부터 프로젝트를 진행했다. 전반적인 기획, 디자인은 친구들과 같이 했지만, 개발과 관련된 부분은 전부 내가 담당했다. 거의 6개월 동안, 기획도 많이 엎어지고, 화면도 두 번이나 전면 수정했지만, 결국 1차 런칭을 성공적으로 마무리했다.

잘은 모르겠고, 일단 굴러는 갑니다.

 

기술 스택 및 아키텍쳐

 전형적인 SPA + REST API 형식의 웹 서비스이다. 다만, 추후 엄청나질 ShortBoost의 초기 모습(…!)을 기록하기 위해서 현재의 기술 스택과 아키텍쳐에 대해서 간단하게 기록해둔다.

 

 대부분의 인프라는 AWS에 의존하고 있다. REST API + SPA로 동작하고 있으며, 서버는 Spring boot3를 사용 중이다. SPA는 Vue3를 사용하고 있고, 애플리케이션 서버와 동일한 인스턴스의 nginx로 서빙 중이다. DB는 MySQL을, 캐시는 서버와 같은 인스턴스의 로컬 Redis를 사용 중이다. 이미지는 S3 버킷을 Read 퍼블릭 설정해 사용 중이다.

 

 Batch 작업들은 API 서버와 같은 애플리케이션에서 Spring Schedule를 활용해서 관리하고 있으며, 인공지능 모델은 GPT4를 사용하다가 Anthropic의 Claude 3 Opus로 변경했다.

 

 CI/CD는 Github Actions + AWS Code deploy를 통해서 Dev / Main 브랜치에 푸쉬하면 자동으로 배포되도록 되어있으며, 모니터링은 AWS Cloud Watch를 활용하고 있다.

 

작고 귀여운 ShortBoost 아키텍쳐

 

사이드 프로젝트를 하며 배운 것

일단 출시하라

 아무래도 "엄청난 아이디어가 있어, 이걸 만들자!"가 아니라, "릴스 마케팅을 하는 사람들의 문제는 뭐지?" "어떤 서비스로 어떻게 하면 릴스로 마케팅하려는 사람들을 제일 잘 도와줄 수 있지?"를 고민하다보니, 기획이 계속 바뀌었다. 화면 구성, 세부 스펙은 커녕, "이런게 좋을 것 같은데?"로 기획이 자꾸만 바뀌었다. 기획도 세부 스펙 레벨에서 있는게 아니라, “그냥 이런 기능이 있으면 좋겠다.” 수준이었음에도, 계속해서만 바뀌었다.

 

 그렇다보니, 일이 제대로 진척이 되지 않았다. 나도 사이드 프로젝트로 진행하는지라 하루에 3~4시간밖에 시간을 낼 수 없었고, 함께하는 친구들도 본업인 교육과 콘텐츠에 집중하느라 많은 리소스를 투여할 수 없는 상황에 계속해서 바뀌는 기획에 대응할 수가 없었다.

 

 표류하던 중 3월 말 회의를 통해 오픈 스펙을 픽스하고, 이를 빠르게 구현해서 출시 먼저 해보자는 결론에 이르렀다. 그 후 빠르게 출시하고 현재는 사용자 지표와 반응을 보고 있는 중이다.

 

 프로젝트라는게, 어쩔 수 없이 요구 사항에 맞춘 변화는 있을 수 밖에 없다. 하지만, 출시도 하지 않고 이리저리 흔들리는 것은 최악이다. 일단 어떤 모습으로라도 내야한다. 인스타그램의 처음 모습, 노션의 처음 모습을 기억하는 사람이 있는가? 일단은 내고, 사용자들의 목소리를 들어가며 좀 더 나은 제품으로 계속해서 튜닝해가야 함을 절실히 느꼈다. 완벽한 초기 제품은 있을 수 없다. 완벽한 초기 제품이라고 생각한 것도, 결국 그냥 “생각”일 뿐이다. 생각랜드에서 빠져나와 현실을 느끼기 위해서, 일단 내라.

출시를 해야 뭐라도 하지!

과한 건 필요 없다.

 회사에서는 서비스의 안정성, 손쉬운 운영을 위해서 많은 사람들이 노력해서 엄청나게 좋은 환경이 깔려있다. 서비스는 당연히 24시간 돌아가야 하며, 배포 시스템도 잘 갖추어져 있고, 누군가의 실수로 대형 사고가 나지 않도록 권한 분리도 확실하게 되어있다. DB, 캐시, 쿠버네티스 클러스터, CDN, 프록시 서버 등를 각 분야의 전문가가 다 담당해주고 있다. 모니터링도 APM / 로그 모니터링 / 시스템 모니터링까지, 모든게 완벽하게 잘 갖추어져 있다.

황량한 사이드 프로젝트.. 아무것도 없다!

 보고 배운게 이렇다보니, 사이드 프로젝트를 하면서도 조금이라도 따라하려고 로그 모니터링, 캐시 서버 분리 뭐 이런 것들에 대해 고민하는데 처음에 시간을 쏟앗다. AZ 이중화, 카나리 배포와 같은 완벽한 플랜, 좋은 모니터링 시스템을 갖추고 시작해야하나? 싶었다. 돌아보니, 이런 건 지금은 필요가 전혀 없더라. 서비스가 중단되어도 화낼 고객이 없다. 실수로 DB를 날려도 없어질 데이터가 없다. 일단 EC2 1대, RDS 1대, S3로 정적파일 서빙, 이 정도로도 충분하다. 문제를 찾고, 이를 해결해주기 위한 솔루션을 찾기 위해 시간을 쓰자.

 

그래도 준비는 해야지?

 같이 하는 친구가 인스타 팔로우 4만명 정도 되는 인플루언서이다. 이를 통해 홍보하면 처음부터 엄청난 트래픽이 처음부터 몰려올 거라고 생각..했지만, 글을 쓰는 현재 DAU 200명 정도되는 귀여운 서비스이다. 이런 서비스에서 Scaclable한 아키텍쳐. EDA, Reactive(요새는 좀 안쓰는 듯하기 ㄴ하다), MSA가 필요 있을까? 그저, 심플한 3 Tier 모놀로식 아키텍쳐로도 충분할 것이다.

 다만, 언제든 확장에 대비할 수 있도록, API 서버는 Stateless하게, 각 애플리케이션(어드민, 배치, API 등) 및 도메인 분리에 대비한 프로젝트 아키텍쳐를 미리 설계해두는게 미래를 위해 좋을 것이다.

 

 현재 ShortBoost 서버 프로젝트는 각 도메인을 분리해두고, 언제든 도메인 간 분리가 가능하게 해두었다. 이와 비슷하게, 어드민 / 배치 / API 등 애플리케이션도 언제든 분리할 수 있도록 소스코드를 구성해두었다.

언제든... 헤어져야지?

 

마치며

 앞으로 이 프로젝트가 어떻게 될 진 모른다. 진짜 릴스로 마케팅을 하려고 하는 사람들의 문제를 해결해서 서비스가 엄청나게 커질 수도 있고, 조용히 사라져버릴 수도 있다. 하지만, 새로운 걸 만들고 사람들의 문제를 해결할 수 있는 서비스를 만드는 건 굉장히 재밌기 때문에, 열심히 퇴근하고 뚝딱 거릴 예정이다.

 

약간 급마무리긴 한데, 숏부스트 화이팅!

 

읽을 거리

혼자서 모든 개발을 진행하며 도움이 많이 되었던 자료를 누군가를 위해 남겨두도록 한다.

 

1) 스프링부트로 웹 서비스 출시하기 - 1. SpringBoot & Gradle & Github 프로젝트 생성하기

 

web:신규서비스 [권남]