잔소리 프로젝트 마무리

잔소리 프로젝트란?

쟌소리 프로젝트는 구글 애드센스 API 를 기반으로 애드센스에서는 제공하지 않는 보고서 알림에 대한 불편함을 개선하기 위해 시도한 메일링 서비스를 만들어보고자 시도했던 프로젝트 입니다. 순전히 개인화된 프로젝트 였기에 실제 사용자를 받아볼 생각은 없는 방향으로 진행되었습니다(퀄리티 자체도 실제 서비스하기에는 부족했구요).

 

데스크톱

 

 

모바일

 

사용된 기술스택

전반적으로 사용한 스택 부분에서는 NextJS14, PostgreSQL+ Prisma + GCP Cloud SQL 으로 개발하고, GCP Cloud Run  을 통해 도커 컨테이너 방식으로 배포하는 방향으로 갔습니다. 

 

이번 프로젝트에서 시도해 보고자 했던 것

해당 프로젝트는 순전히 스케줄링을 통해서 사용자가 등록한 보고서 옵션과 일정에 맞춰 주기적으로 사용자의 이메일로 보고서를 취합 후 제공하는 것이 목적이었고, 그로 인한 도전도 자동화 서비스를 구축해보는 것이 이번 프로젝트에서 기대했던 목표였습니다.

 

아래는 주요 서비스(사실상 이게 전부!) 사용 과정 일부입니다.

보고서 등록

여기서 사용자가 애드센스 내에서 어떤 목록을 조회할 지 설정합니다.

 

등록된 보고서 목록

사용자가 등록한 보고서의 옵션이 표시됩니다. 여기서 주단위, 월단위, 년단위로 알림 설정이 가능하고, 원한다면 즉시 받기를 통해 지정한 기간과 옵션에 대한 보고서를 받아볼 수 있습니다.

 

알림 설정 시 목록

사용자가 알림을 받기로 원하는 날짜를 지정하면, 다음 알림과 다다음 알림 일정을 표시하여 사용자가 언제 해당 보고서를 받아볼 수 있는지 알려줍니다.

보고서 메일 전송 

정해진 알림 일정 혹은 즉시 받기를 클릭한다면, 사용자가 등록한 이메일로 알림 메시지와 csv 파일을 첨부하여 발송합니다.

 

 

이 과정에서 직면했던 문제와 해결 방법

전체적으로 기능은 정상적으로 동작하였으나, Cloud Run의 경우 인스턴스를 최소 0개 이상으로 축소와 확장이 되기 때문에, 아무런 사용자가 접속하지 않은 경우에는 인스턴스가 중지된 상태(즉, 컴퓨터가 꺼진 상태)에 있습니다.

 

이로 인해 로컬 환경에서 node-cron 을 통해 등록한 스케줄이 정상적으로 동작하지 않고, 데이터베이스 상의 기록으로만 남게 되는데, 이를 동기화하여 언제든지 동작할 수 있도록 하기 위해, 별도의 백엔드 API 를 만들어 두었습니다.

 

그 후, 사용자가 접속하지 않은 상태에서도 데이터베이스에 저장된 알림 스케줄을 동기화하여 실행할 수 있도록 GCP 의 Cloud 스케줄러를 등록했고, 사용자가 등록한 알림 일정의 10분 전에 4분 간격으로 2번의 크론 작업 동기화 요청을 보내도록 하여 정상적으로 사용자의 알림으로 보고서를 전송하도록 설정했었습니다.

다만, 해당 기능의 치명적인 제한점이 있었습니다. 바로 동기화를 위해서 필요한 정보는 구글 애드센스 API 를 통해서 가져오기 때문에,  해당 API 를 사용하기 위해서는 매번 Oauth2 인증을 통해 구글 api 에 접근해야 한다는 점입니다. 다행히 사용자가 가입 처리를 하면 refresh 토큰을 발급받게 되고, 이를 데이터베이스에 안전하게 저장해두기 때문에, 이를 사용하여 동기화할 수 있었습니다.

 

프로젝트를 통해 배운 것들

프로젝트를 통해서 배운 것은 간단하게 나마 메일링 서비스를 시도해보며 크론이 어떻게 동작하는지, 이를 어떻게 자동화 프로세스에 적용하는지에 대해서 알게된 것이라 볼 수 있습니다.

 

또한, 구글 클라우드를 통해 도커 컨테이너 배포를 시도해보면서, 로컬에서의 환경을 이미지로 빌드 하고, 이를 컨테이너로 실행하면서, 도커의 여러 이점에 대해서 많은 것을 느끼고 배울 수 있었던 시간이었습니다.

 

Cloud SQL 과 Cloud Run  연동하는 과정을 통해서 유닉스 소켓 통신에 대해서도 얕은 정도이지만, 기존의 몰랐던 배경 지식을 넓히는 기회가 되었습니다.

 

이번에 Cloud Run 을 사용하면서 느꼈던 점은 콜드 스타트 문제를 떠나서 서버가 매우 느렸다는 점입니다. 그래서 하나의 페이지에서 다음 페이지로 넘어가기 까지 매우 느렸고, 이는 사용자 경험에도 엄청 엄청 부정적일 수 밖에 없다는 생각이 들었습니다. 이는 배포 리전이 일본 도쿄인 점이 한 몫했고, 여기서 CDN 서비스가 필요한 이유에 대해서 몸소 느꼈던 기회가 되었습니다.

 

프로젝트에서 아쉬었던 점, 곤란했던 점

배운 것들 부분의 중복이 되는 것 같은데, 일단 개인 회고를 위해 작성해둘 것이 있으면, 모두 기록해두는게 목적이므로 마저 작성해봅니다.

 

해당 프로젝트를 하면서 아쉬었던 점 혹은 곤란했던 점은 배포 이후 서비스가 불안정하게 운영되었다는 점입니다. 이는 네트워크나 백엔드, 인프라 전반에 대한 부족한 배경 지식이 큰 한 몫 했다고 생각합니다. 

 

Cloud Run의 경우 인스턴스를 최소 0 개 이상으로 확장과 축소가 유연하기 때문에, 사용자가 접속하지 않는 경우에는 최대 15분 정도 지나서 자동으로 인스턴스가 중지됩니다. 이 때 새로운 사용자가 사이트에 접속하게 되면, 인스턴스가 1개 이상 활성화 되는데, 이 때 활성화 되는 동안 발생하는 콜드 스타트 문제로 인해 웹 사이트 접속 시 로딩이 오래걸리는 문제가 직면 했습니다.

 

또한, 사이트를 배포한 리전의 경우 커스텀 도메인을 적용하기 위해 일본 도쿄를 선택했고, 이로 인해 국내에서 서비스를 이용하는 경우에도 사이트 전체가 매우 느린 인상을 많이 받았습니다.  데이터베이스의 경우에도 PostgreSQL 의 포트에 여러 인스턴스가 동시에 접근하는 경우 열린 포트 문제가 발생하여 서버가 다운되는 등 여러가지로 문제가 많이 존재하였습니다.

 

이러한 문제들을 경험하면서, 전반적으로 부족한 부분을 인지할 수 있었다는 점에서 아쉽기도 했지만, 그만큼 채워나가야 할 점들을 알게되었다는 것은 분명 좋은 경험이라 생각합니다.

 

그래서 다음에는 어떻게?

이번 프로젝트는 나름 배운 것도 많았지만, 부족한 것도 너무 많았던 프로젝트였습니다. 또한 NextJS 를 사용하면서 백엔드와 프론트엔드의 구분이 애매모호 했고, 마냥 NextJS 를 고집해서 해당 프로젝트를 해야 했는가에 대해서도 스스로 자문을 하게 되었던 회의감이 드는 프로젝트 였기도 했습니다.

 

현재로서는 글로 자세하게 표현하기는 어려우나, 지나온 과정을 돌이켜 보면서 부족한 부분에 어떤 것들이 있었는지 분석하고, 이번 경험을 기회로 삼아서 더 성장할 수 있도록 해야 겠습니다.