Published on

사이드 프로젝트 회고

프로젝트 소개

프론트엔드 개발자 2명과 함께 롤링 페이퍼 서비스를 만들었습니다.

간단한 소개는 프로젝트 README.md에서 가져와봤습니다.

💌 QuokkaLetter

쿼카레터로 전해보는, 따뜻한 진심

익명의 편지를 주고 받을 수 있는 따뜻한 소통의 공간, QuokkaLetter입니다.

그동안 전하지 못한 마음을 쿼카레터로 담아 보내보세요. 함께 시작하는 새해에 상대방에게 닿을 때까지의 설레임과 기대가 담긴 쿼카레터로 더욱 특별한 순간을 만들어보아요!

조금 더 개발 관점에서 설명하자면 아래와 같습니다.

  • 카카오 로그인을 통해 회원가입 및 로그인
  • 유저들은 각자의 대시보드를 가지고 있습니다.
  • 유저는 다른 유저의 대시보드 링크에 가서 편지를 작성할(보낼) 수 있습니다. 이 때 편지마다 직접 설정하는 익명의 발송자 이름을 사용합니다.
  • 편지를 받으면 받은 유저의 대시보드에 발송자 이름만 보이고 내용은 비공개입니다.
  • 편지의 내용은 특정 날짜(2024년 2월 10일)에 공개됩니다.

백엔드 서버는 Next.js의 API Routes를 활용한 Vercel Severless Function을 사용했고, DB는 Firestore DB를 선택했습니다.

내가 한 것들

DB 관리

Firestore를 사용해서 유저와 편지 데이터를 관리했습니다. 비즈니스 로직이 간단하여 테이블(Firestor에서는 컬렉션이기 때문에 앞으로는 컬렉션으로 부르겠습니다.)이 적고 RDB 기준 많은 Join이 필요하지 않은 케이스이기 때문에 NoSQL을 사용하는 것이 적절하다고 판단했습니다.

규모가 크지 않은 서비스이기 때문에 관리의 용이성에 집중하여 Serverless + RealTime DB인 Firestore를 사용했습니다. 실무에서도 사용하고 있기 때문에 저에게 익숙한 것도 장점이었습니다.

API 개발

서비스 플로우에서 필요한 API들을 예측하여 개발하고 프론트엔드에서 추가적으로 필요한 API가 있다고 하면 개발하는 방식으로 진행했습니다.

최근에 실무에서 요구사항을 보고 어떤 API가 필요한 지 파악하여 직접 태스크를 생성하는 작업이 어렵고 연습해야겠다는 생각을 했었는데 이번 프로젝트로 조금이라도 도움이 됐을 것이라고 생각합니다.

아래는 개발한 API 목록입니다.

  • 최초 가입한 유저의 닉네임 설정 API
  • 유저 닉네임 조회 API
  • 편지 작성 API
  • 받은 편지 조회 API
  • 보낸 편지 조회 API

Next-auth Firebase Adapter

Next-auth를 사용해서 카카오 로그인을 구현했습니다. 이 때 유저 데이터를 Firestore에 저장하는 방식을 Next-auth에서 Adapter라는 개념으로 지원하고 있어서 패키지를 설치해서 유저 데이터 관리를 쉽게 할 수 있었습니다.

Adapter만 설정해두면 유저가 가입했을 때 유저 정보, 세션 정보, 토큰 정보까지 DB에 저장되어 간단한 서비스 구현에서는 이만한 대체제가 없다고 생각합니다.

마이그레이션 스크립트

이벤트성 서비스이다보니 한 번만 작업하면 되는 마이그레이션 작업이 필요했고, 유용했습니다.

편지 공개 마이그레이션

특정 날짜가 되면 비공개이던 편지들이 공개되어야 하는 서비스입니다. 이를 위해서는 공개/비공개를 구분하는 필드값의 변화가 필요했습니다. 설정한 시간이 되면 자동으로 변경되는 것이 정석적인 방법이지만 이 또한 규모가 작기 때문에 미리 스크립트를 작성해두고 공개되는 시간에 스크립트를 실행시켜 편지를 공개하도록 했습니다.

공지사항 전송

추가적인 이벤트 설명과 감사 인사를 모든 유저에게 보내면 좋겠다는 아이디어가 서비스 공개 이후에 떠올랐습니다. 보통 팝업으로 처리하는 것이 좋지만 운영 중에 빠르게 구현할 수 있는 아이디어로 모든 유저에게 운영진의 편지를 전송하는 방법을 선택했습니다. 모든 유저에게 편지를 보내는 스크립트를 작성해서 공지사항을 알릴 수 있었습니다.

추가로 마이그레이션은 아니지만 이벤트 상품 수령자 선정을 위한 통계도 스크립트 작성을 통해 낼 수 있었습니다.

배운 것들

내 상황에 필요한 기술을 선택하기

처음에는 기술적인 학습을 위해 학습해보고 싶던 기술들로 프로젝트를 진행하려고 했습니다. 하지만 일정과 회사 업무가 바빠짐에 따라 최대한 간결하고 빠르게 개발할 수 있는 기술적 선택이 필요했고 이 과정에서 내 상황에 필요한 기술을 선택하는 고민을 많이 해보는 경험을 했습니다. Serverless의 장점에 대해 더욱 이해하게 되는 경험이었습니다.

기획의 중요성

기획자가 없이 비슷한 서비스를 레퍼런스로 개발했습니다. 하지만 기획이 전혀 필요없는 클론코딩이 아니었기 때문에 기획적이니 부분을 신경썼어야 했다는 점을 느꼈습니다.

QA를 더 길게 꼼꼼하게 진행하고 유저 플로우를 모든 프로젝트 개발자가 동일 선상에서 인지하고 있었으면 더욱 수월한 프로젝트가 됐을 것이라고 느꼈습니다.