댄버 서버시간 프로젝트 개발 과정 및 후기

프로젝트 소개

이 프로젝트는 서버의 시간을 최대한 정확하게 알려주는 서비스입니다. 인기가 많은 티켓과 수강신청은 보통 열리자마자 수초내에 마감됩니다. 그래서 시간이 되자마자 빠르게 신청을 해야 합니다. 하지만 문제는 모든 서버의 시간이 미묘하게 다릅니다. 어떤 곳은 2초가 빠르고, 어떤 곳은 1초가 느립니다. 그 이상 차이가 나는 경우도 많이 있습니다. 미리 서버의 시간을 체크하고, 수강신청을 하는 것은 이제 필수입니다.

시작 이유

어떤 프로젝트를 진행할까 고민하다 깨달은 것이 있습니다. 1인 개발자의 제품은 리소스가 많은 기업과는 달라야 합니다. 1인 개발자는 자금도 부족하고, 개발에 사용할 수 있는 리소스도 부족합니다. 그러니 상품성을 조금 포기하더라도 더 적은 리소스를 사용하는 제품을 만들어야 합니다. 그래야 지속할 수 있습니다.

수강신청이나 티켓팅에 많이 사용되는 서버시간 조회 사이트는 백엔드의 부담이 거의 없습니다. Verecl을 통해 배포하면 추가적인 배포 비용도 들지 않기 때문에 광고를 통한 작은 수익화라도 이루어진다면 내가 자는 순간에도 조금씩 돈을 벌어줄 수 있습니다. 한번 만들어두면 특별한 문제 없이 계속 굴러가는 웹사이트는 1인 개발을 하는 제게 좋은 주제였습니다.

제작 과정

처음 진행하는 프로젝트라서 미리 계획을 짜고 시작했습니다
- 타겟 : 연령대 10 ~ 30, 공연 예매 또는 수강 신청하는 사람들.
- 개발 기간 : 2주로 잡았습니다.
- 1주차에는 핵심 기능만 작동하는 MVP 버전을 만들고, 2주차에 채팅 추가 및 아래처럼 부족한 부분을 채웠습니다. 한번에 완성하지 않고 단계를 나누는 이유는 MVP 버전이 미리 배포하고, 개선할 때 저는 가장 능률이 좋기 때문입니다.

프로젝트의 규모에 비해 일정을 길게 잡은 이유는 앞으로 이 정도 사이즈의 작은 프로젝트를 여러개 배포할 예정이기 때문입니다. 매번 바닥부터 만들기보다는 템플릿과 필요한 라이브러리를 미리 만들어두고, 다음 프로젝트에 활용할 수 있게 하는 것을 목표를 두었습니다.
- Next.js 템플릿을 만들었습니다. (i18n, svgr, react-query, tailwindcss 등을 미리 셋팅했습니다.)
- 디자인 시스템 프로토타입을 제작했습니다. 버튼이나 Input과 같은 자주 사용하는 컴포넌트를 미리 만들어서 Github packges에 배포해서 사용할 수 있도록 했습니다.
도메인은 구입하지 않고 서브도메인에 연결했습니다. 광고 수익이 들어올지도 불투명한 프로젝트에 매달 도메인 비용을 낼 수는 없었습니다. (https://servertime.danver.io 를 사용했습니다.)
Route53을 이용해서 Vercel serverless의 cold start 문제를 Warm-up 한 것.
어떤 일을 할지 세세하게 나눠놓는 것이 일하기에 편해서 미리 카드를 만들었습니다. 하나의 카드를 끝낼 때마다 클리어 표시를 하고 통에 담으면서 하루동안 얼마나 많은 일을 처리했는지 매일 체크하면서 관리했습니다.
책상 앞에 구글홈을 두고, 25분씩 일하고 5분 쉬는 것을 반복했습니다. 같은 자세로 오랫동안 일하면 몸에 무리가 옵니다. 조금씩 자주 스트레칭을 해주면 그런 문제 없이 오랜 시간 집중할 수 있기 때문에 구글홈의 도움을 받습니다. 포모도로 타이머도 써보고, 여러가지 방법을 써봤지만 가장 편합니다. 일을 시작할 때 "헤이 구글, 25분 타이머" 라고 이야기해주면 정확히 25분 뒤에 알려주기 때문에 편히 시간 관리를 할 수 있습니다.
번역 텍스트는 구글 스프레드시트에서 관리했습니다. 한눈에 보기 편하고, 추후에 친구들에게 번역 요청을 할 때 편하기 때문입니다. 스프레드 시트에 작성하고, 명령어를 통해 다운로드 받아 i18n에 맞게 변환합니다.

디자인 시스템은 Github Packages를 통해 배포해서 사용하고 있습니다. NPM과 달리 Github Packages는 Private packages를 일정 범위까지는 무료로 사용할 수 있습니다.

Vercel을 통해 웹을 배포했는데, 서버리스 특성상 몇분 사용을 멈추면, Cold start가 발생합니다. Route 53 Health Check를 활용해서 30초마다 리퀘스트를 때려서 항상 빠르게 접속할 수 있도록 설정했습니다. 이 부분은 아래 블로그 글을 참고했습니다.
https://medium.com/aws-tip/speeding-up-aws-amplify-nextjs-first-render-cold-start-and-images-an-unexpected-result-36a416d69615

사용한 기술

웹 : Next.js, Typescript, TailwindCSS
다국어화 : next-i18next (번역), Google sheet를 이용한 번역 텍스트 관리
채팅 : Firebase Realtime Database
소리 재생 : use-sound 라이브러리 (https://github.com/joshwcomeau/use-sound)
배포 : Vercel을 통한 자동 배포
백엔드 : Next.js API route Backend

좋았던 것들

Github Packges를 통해 라이브러리를 처음 배포하고 사용한 것
프론트와 백엔드 모두에 자동배포를 적용해서 코드에만 집중할 수 있도록 한 것. (1인 개발의 문제인 리소스 부족을 조금이나마 도울 수 있다)
Firebase Realtime database를 이용해서 채팅 서비스를 무료로 쉽게 만들어낸 것 (하루 다운로드 360MB 까지는 무료)
앞으로 내가 사용할 기술의 방향을 정한 것. 돈을 버는 것에 새롭고 더 좋은 기술은 의외로 필요하지 않다. 기술보다는 비즈니스가 더욱 중요하므로. 기술을 배우고 시행착오를 해결하는 시간에 하나의 프로젝트를 더 만드는 것을 선택했다. 퇴사 후 내가 주어진 시간은 6개월. 그 안에 결과를 내고 싶다.

진행하면서 겪었던 실패

1. 정확한 시간 추측이 불가능

이 서비스의 핵심은 서버의 정확한 시간을 알아내는 것인데 여기에는 한계가 있습니다. 웹에서는 언제나 딜레이가 있는데, 네트웍 상황에 따라서 그 시간이 매번 다르기 때문입니다. CORS 문제로 인해 사용자의 디바이스가 아닌 Vercel 서버에서 티켓팅 사이트로 신호를 보내는 것에도 문제가 있습니다. 더 나은 방법을 찾기 까지는 지금 방법 그대로 사용하기로 했습니다.

2. Amplify로 Next.js 배포

Vercel에 광고를 달면 유료 플랜 (월 $20)을 구매해야 합니다. 이런 문제가 없는 AWS Amplify를 통해 배포를 시도했지만, locale detection에 어려움이 있어서 포기했습니다. middleware로 도전했지만, 순조롭지 않았습니다. 정해진 일정이 있으므로, 추후에 해결되면 다시 시도해볼 예정.

3. Ad sense 승인실패

컨텐츠 부족으로 실패했습니다. 더 많은 컨텐츠를 추가해야 합니다. 이 부분은 차라리 블로그를 통해 광고 승인을 받는 방법으로 변경합니다. 루트 url에 대해 승인을 받으면 서브도메인은 승인 없이 사용할 수 있기 때문에 블로그를 통해 승인 받고 앞으로 만들어지는 프로젝트에는 처음부터 광고를 삽입 할 예정입니다.

맺으며

간단한 사이트이지만 계획했던 대로 결과물을 만들어낸 것에 만족합니다. 또 다음 프로젝트를 빠르게 만들 수 있도록 여러 기반을 만들어둔 것이 뿌듯합니다. 앞으로는 생각이 조금 달라질 것 같습니다. 이제 새로운 서비스의 MVP버전은 작은 규모라면 하루만에 만들어서 배포할 수도 있기 때문에 출근하면서 길을 걷다가도 아이디어가 떠오르면 바로 시도해볼 수 있을 것 같습니다.

언젠가 완성하고 싶은 목록

언어 번역을 다른 사용자로부터 도움 받을 수 있는 환경 구축. 하나의 언어를 추가하면 그 언어를 사용하는 사람만큼 검색에 노출될 확률이 증가합니다. 이를 위해 언어 번역 도움을 받을 수 있는 방법을 고민해보고 싶습니다. 앞으로 제가 만들 어떤 서비스든 활용할 수 있기 때문입니다.