GUBU(구독부자)

Specialty

Node.js

FE Github

BE GitHub

Specialty

날짜

프로젝트 소개

Logo / mascot

서비스 시연 영상

GuBuThe most powerful no-code platform Logo / Mascot

서비스 시연 영상

GuBuThe most powerful no-code platform Logo / Mascot

서비스 시연 영상

GuBuThe most powerful no-code platform < GUBU서비스 로 가려면.. >

서비스 시연 영상

**< GUBU서비스 로 가려면.. >**

GuBuThe most powerful no-code platform < GUBU서비스 로 가려면.. >

The most powerful no-code platform

Bubble introduces a new way to build a web application. It’s a no-code point-and-click programming tool. Bubble hosts all applications on its cloud platform.

https://gubu.bubbleapps.io/

서비스 시연 영상

GuBuThe most powerful no-code platform < GUBU서비스 로 가려면.. >

서비스 시연 영상

GuBuThe most powerful no-code platform < GUBU서비스 로 가려면.. >

서비스 시연 영상

GuBuThe most powerful no-code platform < GUBU서비스 로 가려면.. >

서비스 시연 영상

GuBuThe most powerful no-code platform < GUBU서비스 로 가려면.. >

서비스 시연 영상

GuBuThe most powerful no-code platform < GUBU서비스 로 가려면.. >

서비스 시연 영상

GuBuThe most powerful no-code platform

GitHub Link

• Service Github

GitHub - GUBU-8JO/gubu_service: 파이널 프로젝트[구독 서비스 관리 : 구독부자]

파이널 프로젝트[구독 서비스 관리 : 구독부자]. Contribute to GUBU-8JO/gubu_service development by creating an account on GitHub.

https://github.com/GUBU-8JO/gubu_service

• Batch Github

GitHub - GUBU-8JO/gubu_batch

Contribute to GUBU-8JO/gubu_batch development by creating an account on GitHub.

https://github.com/GUBU-8JO/gubu_batch

발표 영상

“대 구독 시대”에 필요한 구독 관리 사이트

프로젝트 목표 : 사용자 구독 플랫폼 관리 서비스

프로젝트 설명 : 저희 구부(구독 부자)는 사용자들이 이용하고 있는 다양한 구독 서비스(유튜브, 웨이브, 왓챠 등)를 편리하고 간단하게 관리할 수 있고, 언제 어떤 서비스를 얼마나 이용하고 있는지 쉽게 파악할 수 있습니다. 특히, 구독 결제일 하루 전에 알림을 제공하여 중요한 결제를 놓치지 않고, 구독 정보를 체계적으로 관리할 수 있는 서비스를 제공합니다.

서비스 기획 의도

내가 구독하는 플랫폼을 한 번에 볼 수 있는 ”구독 서비스 현황 확인”

결제 날을 미리 알려주는 “구독 서비스 결제일 알림”

구독 플랫폼의 계정 정보를 안전하게 저장하는 ”구독 계정 정보 보안”

인기 플랫폼을 한 눈에 볼 수 있는 ”구독 서비스 랭킹 제공”

Gallery view

서비스 핵심 기능 (1)

구부의 메인 페이지에서 구독 추가, 자신이 추가한 구독 목록을 간단히 살펴볼 수 있습니다. 또한 검색, 알림, 로그아웃 등의 기능도 사용할 수 있습니다.

#1 메인페이지

사용자는 자신이 구독 중인 플랫폼을 등록하여 구독 정보를 빠르게 확인할 수 있습니다.

•

사용자는 구독 플랫폼, 결제 주기, 결제일, 결제 수단 등을 한눈에 파악할 수 있습니다. 

•

구독 시작일, 계정 ID/PW 등 추가적인 정보는 상세 보기 옵션을 통해 확인할 수 있습니다.

Redis를 활용하여 빠른 조회가 가능합니다.

•

Database에서 직접 조회하는 것보다 빠른 Redis 캐시를 활용했습니다.

•

Look-Aside 캐시 전략을 통해 캐시에서 먼저 조회 후 캐시에 데이터가 없을 시, Database에서 가져오도록 설정했습니다.

•

응답속도 300ms로 목표를 달성하기 위해 성능 테스트를 진행했습니다.

#2 구독 추가 페이지

메인페이지

사용자가 구독하고 있는 플랫폼에 대해, 결제일 하루 전 알림을 보내서 결제일을 놓치지 않고 관리할 수 있습니다.

#1 알림

배치를 통한 알림의 일괄 생성 및 Lambda 활용

•

구독 등록 시 결제일 하루 전 알림을 발송하여 플랫폼 결제 관리에 도움을 줍니다.

•

하루 한 번 발송하는 알림은 배치(일괄작업)를 통해 API Service와 분리하여 구현했습니다.

•

이후, AWS Lambda를 활용하여 서버리스 환경을 구축했습니다.

•

API Service와 배치를 나누어, 정해진 시간에 알림을 자동으로 생성하는 서비스는 Cron을 활용하여 구현 하였습니다.

•

이후, AWS의 Lambda를 활용하여 서버리스 시스템을 구축했습니다.

(알림 오는 영상으로 대체)

#2 알림 - 코드

Cron 활용하여 함수 자동 실행

결제일 전 알림

사용자가 자신의 구독 중지를 해도 작성한 리뷰는 삭제되지 않습니다.

#1 구독 중지

외래키 삭제

•

설계 초기에는 외래 키를 사용하여 구독 정보 중지 시 작성한 리뷰도 함께 삭제되도록 구현했습니다.

•

서비스의 특성상, 리뷰는 플랫폼에 대한 사용자의 의견과 경험을 나타내는 중요한 자료이므로 삭제되지 않아야 한다고 판단했습니다.

•

외래키 제약을 제거하고, 대신 인덱스를 추가하여 사용자가 구독 중지 시 리뷰가 삭제되지 않지만, 데이터 검색 시 참조할 수 있도록 구현했습니다.

리뷰 작성 - 구독 중지 - 리뷰 존재 이미지

구독 중지 후 등록된 리뷰 유지

사용자가 구독 등록 중 입력한 해당 플랫폼의 계정 정보를 저희 서비스인 GUBU의 패스워드를 통해 찾을 수 있습니다. 입력한 ID와 PW는 crypto(AES) 양방향 암호화하여 저장되며, 만약 사용자가 정보를 잊어버린 경우 복호화를 통해 안전하게 정보를 제공해 드립니다.

#2 구독 상세 보기 시 플랫폼 계정 정보 확인

구독 상세 보기 페이지 에서 구독 정보 확인 및 수정

•

구독 정보의 변경 항목이 있을 때, 구독 상세보기 페이지를 통해 구독 정보 수정이 가능합니다.

플랫폼 계정 정보 양방향 암호화

•

구부 서비스의 비밀번호를 입력하면, DB에 암호화하여 저장된 플랫폼 계정 정보를 복호화하여 해당 확인할 수 있습니다.

#2 플랫폼 계정 정보 양방향 암호화

구독 플랫폼 계정 정보 암호화 , 복호화

구독계정의 양방향 암호화

리뷰 작성 시 평점을 함께 등록하여 해당 평점으로 플랫폼의 랭킹을 산정 후 Top 10 플랫폼을 제공합니다.

#1 플랫폼 정보 제공 및 평점 & 리뷰 등록

구독한 플랫폼에 평점 및 리뷰 등록

•

플랫폼 상세 정보 페이지에서 해당 플랫폼에 대한 세부 정보를 확인할 수 있습니다.

•

구독한 플랫폼에만 평점과 리뷰 작성이 가능합니다.

•

플랫폼 평점을 통해  플랫폼 별점을 업데이트 해줍니다.

#2. 평점 계산 코드

주기적 평점 계산

•

Cron을 활용하여 1시간 간격으로 평점을 계산 후 업데이트합니다.

•

계산된 평점은 Redis캐시에 저장됩니다.

<캐시에 저장된 Top10 플랫폼 데이터>

랭킹 서비스

플랫폼 조회 시 전체 플랫폼에 대해 제목 및 평점 순 조회가 가능합니다.

#1 전체 플랫폼 조회(제목 순, 평점 순)

전체 플랫폼 조회 시 조회 조건을 설정할 수 있습니다.

•

전체 플랫폼에 대해 제목 및 평점 순으로 조회가 가능합니다.

크롤링을 통한 가격 정보 갱신

•

각 플랫폼의 결제 페이지를 크롤링하여 가격 정보를 주기적으로 갱신하여 최신 정보를 제공합니다.

플랫폼 정보 제공

메인 페이지에 이번 달 총 결제금액이 표시됩니다.

#1 이번 달 총 결제금액 확인

사용자는 자신의 월 구독료 총액을 쉽게 확인할 수 있습니다.

•

한 달 총구독료를 확인하여 재정 관리에 도움을 줄 수 있습니다.

•

해당 서비스를 통해 플랫폼의 중요도를 파악하여 구독 낭비를 예방할 수 있습니다.

이번 달 총 금액

서비스 아키텍처

기술 스택 및 기술적 의사결정

BACKEND

Tech Stack	도입 이유
Redis	백엔드 API 구현 시 평균 응답 속도를 300ms로 목표를 잡았습니다. Redis Cache를 활용하면 데이터베이스에서 직접 조회하는 것보다 처리 속도가 훨씬 빠르다는 것을 알게 되었고, 실제로 Redis Cache를 적용하여 테스트를 진행한 결과 Index Key 추가만으로 얻었던 성능 개선보다 60.82% 더 빠른 응답 속도를 달성할 수 있었습니다. 이를 바탕으로, 데이터 변동이 적고 자주 호출되는 데이터에 Redis Cache를 활용하여 더욱 빠른 응답 속도를 확보했습니다.
Batch	저희 서비스는 웹 사용자가 머무는 시간이 짧아, 실시간 알림이 반드시 필요하지 않다는 점을 고려했습니다. 따라서 실시간 알림 방식(소켓, SSE) 대신 배치 방식을 채택하여 특정 시간에 알림을 일괄적으로 생성하도록 구현했습니다. 이 방식은 리소스 사용을 최적화할 뿐만 아니라 서버 부하를 줄여, 전체 시스템의 안정성과 효율성을 크게 향상하는데 기여했습니다.
Scheduler	이번 프로젝트에서 직접 API를 호출하지 않고 원하는 시간에 함수가 자동으로 실행되도록 하기 위해, Nest.js에서 제공하는 스케줄링 패키지를 활용하기로 결정했습니다. 결제일 알림 전송 및 플랫폼 랭킹 산정 기능에 사용해 본 결과, Cron 표현식을 통해 정확한 시간에 함수가 실행되는 것을 확인할 수 있었습니다.
Lambda	저희는 배치 작업에 있던 알림 기능을 AWS Lambda로 변경했습니다. 그 이유는, 해당 배치 작업이 하루에 한 번만 실행되기 때문에 지속적으로 서버를 유지하는 것보다 서버리스 환경에서 필요 시간에만 실행하는 것이 더 효율적이고 경제적이라고 판단했기 때문입니다. Lambda는 일정 주기에 맞춰 자동으로 실행되며, 필요할 때만 리소스를 사용하기 때문에 비용 절감 효과도 큽니다. 그 결과 효율성을 극대화하고, 유지보수의 편의성을 높이는 데 큰 기여를 했습니다.

FRONTEND

Tech Stack

도입 이유

Bubble.io

BE 개발에 더 집중하기 위해 FE 페이지를 빠르게 구현할 수 있는 노코드 툴을 조사하던 중 API 호출이 용이하고 저희 서비스에 맞는 페이지 개발에 적합한 Bubble.io를 찾았습니다. 설계단계에서 테스트 후 실제 서비스에 적용하여 프론트엔드 페이지 제작에 시간 효율성을 높이고 배포를 원활하게 진행했습니다.

Database

Tech Stack

도입이유

TypeORM

프로젝트에서 타입 안정성을 높이기 위해 TypeORM과 Prisma를 비교한 결과, TypeORM이 관계형 데이터베이스의 복잡한 관계 설정을 잘 관리하고 TypeScript와의 호환성도 뛰어나 우리 프로젝트에 적합하다고 판단했습니다. TypeORM의 Entity 기능을 통해 데이터베이스 구조를 명확히 정의하고, 타입 오류를 사전에 감지할 수 있어 개발 효율성을 높일 수 있었습니다. 따라서, TypeORM을 사용하여 복잡한 쿼리와 관계 설정을 효과적으로 처리하고 타입 안정성을 유지했습니다.

Test

Tech Stack	도입이유
Artillery	개발한 API의 성능 개선을 위해 성능 테스트를 진행했습니다. 여러 성능테스트 도구 중 다양한 시나리오를 적용하여 대규모 트래픽에 대한 부하 테스트를 진행할 수 있는 Artillery를 선택했고, HTML과 JSON 형식으로 가독성 좋은 통계 자료로 분석이 용이하다는 것도 확인했습니다. 실제 Artillery를 사용하여 테스트 후 결과를 바탕으로 성능 개선을 달성할 수 있었습니다.
Bulk test	API 구현 후 최적화하기 위해 가장 많은 데이터를 처리하는 결제 알림 생성 로직을 리팩토링했습니다. TypeORM의 SAVE메서드와 BULK INSERT 쿼리문을 비교 결과 SELECT를 진행하는 SAVE보다 BULK INSERT 쿼리문을 사용하는 경우 속도가 훨씬 빠르다는 것을, 테스트를 통해 확인했고 해당 로직에 적용하여 소요시간 86%를 감소하는 최적화를 진행했습니다.

DevOps / Infra

Tech Stack	도입이유
GitHub Action	초기 개발 환경에서는 코드가 자주 변경되고 업데이트되기 때문에 배포 작업의 자동화를 목표했습니다. EC2 인스턴스와 배치 작업, 배포 과정에서 문제가 없음을 확인하고 서비스에 GitHub Actions 기반의 CI/CD 파이프라인을 적용하여 배포 작업을 자동화하고 속도와 안정성을 크게 개선했습니다.
AWS EC2	서버를 운영하면서 유지보수와 관리의 어려움을 해결하기 위해 AWS EC2를 도입했습니다. EC2는 신속한 배포와 자동화 지원, CI/CD 통합으로 인프라 관리 효율성을 크게 향상, EC2를 통해 빠른 배포와 오토스케일링을 검증하였습니다. RDS, S3, Lambda 등 다양한 AWS 서비스와의 통합으로 고가용성과 장애 복구를 자동화할 수 있었습니다. 이를 통해 개발 및 운영 속도와 비용 효율성을 크게 향상했습니다.
AWS CloudWatch	결제 알림 생성 로직을 Lambda로 이동 후 AWS의 서비스를 활용하여 모니터링 하기 위해 조사하였고 통합 관리가 가능한 CloudWatch 서비스가 있는 것을 알았습니다. Lambda 함수 실행 시 모든 로그를 기록하여 에러의 원인을 파악할 수 있고, SNS 서비스과 연결하여 에러 발생 시 slack으로 알림을 받을 수 있다는 것을 확인 후 적용했습니다.
AWS IAM	팀원 모두가 AWS에 접근하며 안전하게 관리하기 위해 root 계정 대신 IAM(Identity and Access Management)을 사용했습니다. 세분화된 접근 권한 관리가 가능하다는 것을 확인하고 현업에서 사용 중인 사례를 바탕으로 IAM 계정을 생성하여 팀원과 공유하여 AWS의 기능 중 람다를 함께 구현했습니다.
Slack API	서버 및 데이터베이스 오류에 신속하게 대응하기 위해, 에러 발생 시 알림을 받는 시스템을 구축하고자 했습니다. 저희는 Slack API를 통해 배치 작업에서 캐시 데이터 생성이 실패했을 때와 AWS Lambda에서 결제 알림 생성이 실패했을 때 Slack으로 알림을 받을 수 있도록 구현했습니다.

GitHub Action

AWS

Slack API

트러블 슈팅

갤러리 보기

문제

•

백엔드 API 기능 구현을 하면서 파트를 나눠서 API를 구현했습니다.

•

각자의 방식으로 작업 하다 보니 응답 값이 제각각인 상황이 발생했습니다.

해결 방법

•

프론트엔드 작업 시 응답값을 명확히 확인하기 위해 공통된 응답 값을 만들 필요가 있다고 판단했습니다.

•

ResponseDto를 사용하여 공통된 응답 값을 만들었습니다.

•

안티패턴인 any타입의 사용을 제한하기 위해 제네릭을 사용했습니다.

응답값 오류

문제

•

알림을 생성하기 위해 다음 결제일을 조회 후, 내일 날짜와 비교하는 로직에서 문제가 발생했습니다.

•

날짜가 동일한 상황에서 알림 목록이 모두 빈 배열로 반환이 되는 현상이 발생했습니다.

•

문제의 원인은 다음 결제일을 계산하기 위해 new Date()를 사용하여 내일 날짜를 생성하면, 날짜와 시간이 함께 저장되는 상황이었습니다.

•

이에 따라, 날짜가 동일해도 시간이 일치하지 않아 비교문에서 불일치가 발생하였습니다.

해결 방법

•

문제를 해결하기 위해, setHours 메서드를 사용하여 시간을 맞추는 방법을 적용했습니다.

•

setHours(0, 0, 0, 0)를 통해 시간을 초기화함으로써, 다음 결제일과 비교가 정확하게 이루어질 수 있도록 했습니다.

•

이를 통해 날짜만 정확하게 비교할 수 있게 되었고, 문제가 해결되어 알림이 정상적으로 생성되었습니다.

알림 빈배열 발생

문제

•

초기 알림 생성 로직에서는 반복문을 통해 모든 데이터를 가져온 후 필요한 데이터를 필터링하여 사용했습니다.

•

그러나 이 방식은 데이터가 많아질수록 처리속도가 크게 저하되었습니다.

•

불필요하게 전체 데이터를 가져오는 방식은 메모리와 처리 시간을 낭비하게 만들며, 규모가 커질수록 이러한 문제는 더욱 심각해지는 것을 확인했습니다.

해결 방법

•

이러한 비효율성을 개선하기 위해 where 조건절을 사용하여 필요한 데이터만 직접 조회하도록 코드를 수정하였습니다.

•

수정 후, 약 6만 개의 구독 중 1만 개의 알림을 보내야 하는 상황을 테스트했습니다.

•

반복문의 경우에는 5분 30초가 소요되었고, where 조건절을 사용한 경우에는 2분 53초가 소요되었습니다.

•

테스트를 통해 데이터 조회 시 where 조건절을 사용하여 필요한 정보만 검색하는 방식이 데이터 검색의 효율성을 크게 높일 수 있음을 알게 되었습니다.

반복문 처리속도

문제

•

플랫폼의 랭킹 정보를 Redis 캐시에 저장하는 전략 중 Look-aside설정 후 부하 테스트를 진행했습니다.

•

TTL(Time To Live)을 15초로 짧게 설정하여 테스트 한 결과, TTL이 끝나고 Redis 캐시에 데이터가 없을 때 응답 시간이 많이 늘어났습니다.

•

Look-aside 전략 설정으로, TTL이 만료될 때마다 DB에서 데이터를 재조회하고, 캐시를 갱신하는 과정에서 응답 속도가 느려지게 됩니다.

해결 방법

•

Scheduler를 통해 1시간마다 Redis 캐시에 데이터를 저장했습니다.

•

TTL을 2시간으로 설정하여 Redis 캐시에 데이터가 비어있는 시간을 없앴고, 일정한 처리 속도를 유지할 수 있었습니다.

Redis캐시 전략

문제

•

TypeORM에서 save 메서드를 사용할 때 발생하는 비효율적인 데이터 처리 방식입니다.

•

save 메서드가 실행되면 데이터를 저장할 때마다  INSERT 후 해당 데이터를 SELECT하는 과정이 발생하는 것을 확인했습니다.

•

한 번에 1,000개의 데이터를 저장해야 하는 경우, 1000번의 SELECT가 추가로 실행되어, 전체 응답 시간에 큰 영향을 미칠 수 있다고 판단했습니다.

해결 방법

•

대량의 데이터를 삽입하는 상황에서는 INSERT만 처리하는 것이 효율적이라고 생각했고, 로직을 수정하여, 한 번에 가능한 많은 데이터를 삽입할 수 있는 Bulk Insert 방식을 사용했습니다.

•

save 메서드 대신, 직접 INSERT 쿼리를 작성하여 데이터를 한 번에 DB에 저장하는 방법으로 변경하였고, 각 데이터 삽입 후에 발생하는 불필요한 SELECT 쿼리의 실행을 피할 수 있었습니다.

•

해당 코드 수정을 통해 결제 알림 데이터를 일괄 삽입함으로써, 불필요한 쿼리 실행을 줄이고 성능을 개선할 수 있었습니다.

•

이 변경 사항의 성능을 확인하기 위해 console.time() 메서드를 사용하여 각 방법의 응답 시간을 기록했습니다.

•

아래 표는 알림 개수에 따른 save 메서드와 INSERT 쿼리문 사용의 응답 시간을 비교한 것입니다.

•

평균을 나타내는 그래프에서 볼 수 있듯이, INSERT 쿼리문을 사용하는 방법이 save 메서드를 사용하는 것보다 훨씬 더 효율적임을 확인할 수 있습니다.

SAVE / INSERT 비교

추후 기술적인 도전 계획

유저 테스트 결과 정리

유저 테스트 원본 결과 및 분석(총 42명 응답) (1)

유저 테스트 결과 분석 및 피드백 자체 평가

긍정 평가

•

각각의 플랫폼 평점 및 후기

•

플랫폼 랭킹 TOP10

•

결제 전 하루 전 알림

•

많은 서비스를 한 번에 볼 수 있다.

부정 평가

•

이용 속도가 너무 느리다

•

사이트 내용 안내가 너무 부족하다.

•

편의성 개편 

새로운 의견

•

구독 가격 자동 갱신 시스템

•

자동 해지 시스템

•

결제 대행 (연동 시스템)

•

구독 검색 기능

•

모바일 어플화

유저 피드백 개선 방향 및 계획

앱 서비스 구현 과제

구독 검색 기능

자동 결제 및 구독 해지

성능 개선 과제

속도 개선

편의성 및 안내 개편