[회고] 온앤오프(2.0) 개인회고

저번 해커톤에서 진행했던 온앤오프를 리뉴얼 하여 앱스토어, 플레이스토어에 런칭하게 되었다.

 

해커톤은 단기간에 결과물을 만들어야 하므로 퀄리티가 다소 떨어지고 해커톤이 끝나면 해당 아이디어는 버려지게 된다.

 

이렇게 버려지는 아이디어와 이를 구체화한 우리의 서비스가 사라지는 것이 아쉬워 기존 Express를 사용하던 해커톤 버전의 온앤오프를 NestJS로 리뉴얼하여 실제 런칭까지 해보는게 어떻겠냐고 제안했었다.

 

결국, NestJS로 리뉴얼을 완료하면서 추가적인 기능들을 구현했고 IOS 팀을 새롭게 모집해 기존 AOS에서만 사용할 수 있던 서비스를 IOS에서도 사용할 수 있도록 확장했다.

---

1. 기존과의 차이점

기존에 만들었던 서비스는 로그인 기능이 매우 빈약했다.

 

따라서, 이번 프로젝트를 진행하며 카카오 로그인, 애플로그인, 자체 로그인 등의 로그인 방식을 도입했다.

 

이번 프로젝트 목표에 앱스토어 런칭이 추가된 만큼 앱스토어 정책에 유의하며 로그인 기능을 추가했다.

 

또한, FCM을 통한 푸시 알림을 추가로 구현했다.

 

SNS 서비스인 만큼 사용자들 간의 상호작용이 서비스의 핵심 기능인데 이를 원활하게 할 수 있도록 푸시 알림 기능을 추가했다.

---

2. 새롭게 배운 점

이 프로젝트는 기존에 했던 프로젝트들 보다 기간이 길었다. (약, 6개월)

 

오랫동안 진행되는 프로젝트이므로 팀원들간의 원활한 소통이 중요했다. 이를 위해 2주에 한 번 기획자의 주도로 정기 회의를 진행하고 서로의 진행 상황을 고려하는 시간을 가졌다.

 

이 과정을 통해 서로가 서로의 작업이 얼마나 진행되었는지 인지하고 그에 맞춰 자신이 해야 할 일을 효율적이고 체계적으로 수행할 수 있었다고 생각한다.

 

Express로 만들어진 서비스를 NestJS로 바꾸는 것이 쉽고 빠르게 진행될 줄 알았지만 생각보다 오랜 시간이 걸렸다.

 

기존에 사용하던 프레임워크가 아니기 때문에 팀원 모두 유튜브를 통해 NestJS에 대해 배우는 시간이 필요했으며 이를 우리의 서비스에 적용하는 과정도 생각보다 까다로웠다.

 

NestJS의 디렉토리 구조에 Repository를 갖도록 설계하고 구현했는데 데이터베이스에 다양한 테이블들이 생기고 그들 간의 연관성이 생기게 되어 특정 역할만을 수행하도록 설계한 Module에서 많은 수의 Repository를 import 해야 했다.

 

이 과정에서 정상적으로 작동은 하지만 실수로 특정 Repository를 import하지 않는 경우 서버가 실행되지 않으며, 많은 Repository를 import하기 때문에 Module 파일이 매우 길어지고 지저분해졌다.

 

하지만 이는 NestJS에 대해 아직 익숙하지 않기 때문에 발생하는 문제라고 생각한다.

 

NestJS로 만들어진 서비스들 중에는 지금 우리가 만든 서비스보다 더 많은 기능을 지원하는 서비스도 있을 것이고 그 서비스들의 각 Module 파일이 이렇게 지저분 할 리가 없다는 생각이다.

 

Express의 단점을 극복하고자 NestJS를 도입하였으며 이를 사용하여 개발하는 과정에서 소통이 훨씬 원활하게 이루어졌다.

 

특정 기능을 만들기 위해서는 정해진 형식을 따라야 하고 특정 기능을 하는 코드를 찾고 싶다면 매우 직관적으로 해당 코드를 찾을 수 있었다.

(팀원들간의 소통 이슈는 발생하지 않았으며, 개발 중 발생하는 이슈의 대부분은 NestJS에서 발생하는 오류로 인한 것이었다.)

 

이 과정을 통해 Node.js 기반의 새로운 백엔드 프레임워크 NestJS를 사용해 협업해볼 수 있었고 Express와 비교하여 장단점에 대해 느낄 수 있었다.

 

또한, 이번 FCM을 이용해 푸시 알림 구현을 담당했었는데 진행 순서가 대략 클라이언트 -> (요청) -> FCM 서버 -> (토큰) -> 클라이언트 -> (토큰) -> 서버의 순서로 진행된다.

 

클라이언트가 FCM에서 받은 토큰을 서버에서 저장하고 있다가 푸시 알림을 보내야 하는 경우 해당 토큰을 서버에서 FCM 으로 전송해야 한다.

 

푸시 알림이 정상적으로 작동하는지 확인하기 위해 기기의 토큰이 필요하고 이는 클라이언트 코드에 FCM에서 제공하는 코드를 삽입하여 실행되도록 하면 된다.

 

이렇게 얻어진 토큰은 기기를 식별하는데 사용되며 푸시 알림을 보내고자 한다면 FCM에 기기별 토큰과 함께 푸시 알림 요청을 보내면 FCM에서 해당 기기를 식별하여 푸시 알림을 전송하게 된다.

 

이 경험을 통해 FCM을 사용해볼 수 있었으며, 그 중 푸시 알림 전송의 과정에 대해 알게 되고 실제로 구현까지 해볼 수 있었다.

---

3. 아쉬운점

여러 팀원들이 중간에 이탈하고 다시 새로운 팀원들이 여러명 합류하는 과정에서 분위기가 어수선 했던 것 같다.

 

기존 해커톤 인원들 중에서 남은 인원은 기획자, AOS 1명, 서버 4명이었다.

 

많은 인원이 참여했던 해커톤이었지만 남은 인원이 많이 없어 아쉬웠다.

 

하지만, 여러차례 모집 공고를 내고 많은 사람들이 지원해주어서 프로젝트가 잘 진행될 수 있었던 것 같다.

 

기존 서비스의 기능, 목표, 방향성 등을 알고 있던 인원들이 많이 줄어든 만큼 새로운 인원들에게 서비스를 이해시키는 과정에서 새로운 인원들이 이 서비스에 대한 애착을 가지고 열심히 개발을 해줄까 라는 의문이 들기도 하였다.

 

다행히 모든 팀원들은 목표 기간 안에 자신들의 역할을 훌륭히 수행해주었다.

---

4. 다음 목표

약 6개월 간의 프로젝트가 끝났다.

 

다음 목표는 "사람들이 실제로 사용하는 서비스 만들기" 또는 "오랫동안 운영해볼 수 있는 서비스 만들기" 이다.

 

런칭에 성공했다고는 하지만 많은 사용자를 유지하기는 어려울 것 같다.

 

또한, 지금 서비스는 수익을 얻을 수 있는 수단이 없기 때문에 AWS의 프리티어가 종료되면서 발생하는 과금에 대응할 수 없다.

 

따라서, 다음 프로젝트를 진행한다면 많은 사람들이 사용하는 서비스(대중성) 또는 오랫동안 운영하며 유지보수 해볼 수 있는 서비스(수익성)를 만들어보고 싶다는 생각이 든다.