Rizzz종료 전 AI 소셜 플랫폼 품질 개선
AI 소셜/채팅 서비스 종료 전 품질 개선 작업. 채팅 백엔드, 관리자 화면, 크롤러 인프라, 권한 보안 문제를 정리했습니다.
프로젝트 소개
Rizzz는 2025년 11월 서비스가 종료된 AI 소셜/채팅 프로젝트입니다. 종료 전까지 AI 채팅 백엔드와 프론트 관리자 화면, 야구 데이터 크롤러, Terraform 인프라를 맡았고, 대화 권한 보안 취약점 개선, NPB/KBO 데이터 수집, API 응답 구조 정리, any 타입 제거, Lambda 크롤러 인프라 추가 같은 운영 품질 개선이 중심이었습니다.
- 역할
- NestJS 백엔드, React 관리자 화면, 크롤러 모듈, Terraform/Lambda 인프라 개선
- 형태
- Blynx 회사 프로젝트
- 상태
- 종료/보관
Company Work
회사 프로젝트 범위
실제 담당했던 백엔드, 프론트엔드, 배치, 결제, 인프라 영역을 중심으로 묶었습니다.
구현한 기능
- theme 기반 대화 기록을 무조건 읽을 수 있던 보안 취약점 개선
- KBO에 종속된 선수 스키마를 baseball_player로 일반화하고 NPB 데이터 수집 흐름 추가
- 크롤러 모듈을 theme 도메인에서 분리하고 타입 검증과 스케줄러 처리 로직 개선
- 프론트엔드 관리자 페이지에서 any 타입 제거, API 응답 data 래핑 제거, Redis/Admin 화면 타입 정리
- KBO/NamuWiki/NPB 크롤러를 위한 Lambda, S3, CloudWatch, IAM, EventBridge Terraform 리소스 추가
- 모바일 OAuth 로그인 DTO validation과 Google API access token 처리 로깅 보강
사용 기술
서비스 요구사항에 맞춰 사용한 기술과 선택 이유입니다.
프론트엔드
언어
TypeScript
API 응답 구조와 관리자 화면 상태를 타입으로 정리해 운영 중 오류를 줄이기 위해 사용했습니다.
프레임워크/라이브러리
React
관리자 화면에서 에이전트 설정과 Redis 상태를 다루기 위해 사용했습니다.
Vite
관리자 프론트엔드를 빠르게 개발하고 빌드하기 위해 사용했습니다.
백엔드
언어
TypeScript
API 응답 구조와 관리자 화면 상태를 타입으로 정리해 운영 중 오류를 줄이기 위해 사용했습니다.
프레임워크/라이브러리
NestJS
AI 채팅, OAuth, 크롤러, 야구 데이터 API를 도메인별 모듈로 관리하기 위해 사용했습니다.
LangChain
LLM 기반 대화 처리 흐름을 구성하기 위해 사용했습니다.
LangGraph
여러 단계의 AI 대화 흐름을 그래프 형태로 조합하기 위해 사용했습니다.
DB/검색
저장소
MongoDB
사용자, 대화, 선수 데이터처럼 문서형으로 다루기 쉬운 데이터를 저장하기 위해 사용했습니다.
Redis
채팅 세션, 큐, 캐시성 데이터를 처리하기 위해 사용했습니다.
OpenSearch
장기 메모리와 추천/검색 흐름을 위해 사용했습니다.
AI/API
모델 연동
AWS Bedrock
AWS 기반 LLM 모델 호출을 서비스 백엔드에 연결하기 위해 사용했습니다.
인프라
서버리스/리소스
AWS Lambda
KBO/NPB/NamuWiki 크롤러를 서버리스 작업으로 배포하기 위해 사용했습니다.
Terraform
크롤러 Lambda, S3, IAM, CloudWatch, EventBridge 리소스를 코드로 관리하기 위해 사용했습니다.
CI/CD
스케줄/배포
EventBridge Scheduler
크롤러와 배치성 작업을 정해진 시간에 실행하기 위해 AWS EventBridge 스케줄을 사용했습니다.
Terraform
크롤러 Lambda, S3, IAM, CloudWatch, EventBridge 리소스를 코드로 관리하기 위해 사용했습니다.
구조와 개선
NestJS API: AI 채팅, 사용자, OAuth, 크롤러, 야구 선수 데이터 API React Admin: 에이전트 설정, Redis 관리, 사용자 에이전트 관리 화면 Crawler module: KBO/NPB/NamuWiki 데이터 수집과 스케줄링 처리 Data model: baseball_player 스키마로 리그 종속성을 낮춘 선수 데이터 구조 Terraform: Lambda, S3, CloudWatch Logs, IAM, EventBridge, ECS lifecycle 관리
- NestJS API: AI 채팅, 사용자, OAuth, 크롤러, 야구 선수 데이터 API
- React Admin: 에이전트 설정, Redis 관리, 사용자 에이전트 관리 화면
- Crawler module: KBO/NPB/NamuWiki 데이터 수집과 스케줄링 처리
- Data model: baseball_player 스키마로 리그 종속성을 낮춘 선수 데이터 구조
- Terraform: Lambda, S3, CloudWatch Logs, IAM, EventBridge, ECS lifecycle 관리
성과와 회고
- 대화 기록 조회는 메시지를 단순 조회하던 흐름에서 aggregation pipeline과 페이지네이션을 붙여 개선했습니다. 필요한 범위만 가져오고 session 메타데이터의 unreadCount를 활용해, 채팅방이 늘어날수록 반복 계산이 커지는 문제를 줄였습니다.
- DM/채팅 성능은 인덱스와 조회 조건을 함께 손봤습니다. MessageSchema 인덱스 추가, presence 정확도 개선, 세션 조회 최적화를 묶어 실시간 채팅에서 자주 호출되는 경로의 부하를 낮췄습니다.
- KBO에 묶여 있던 선수 스키마를 baseball_player로 일반화하고, NPB 크롤러를 추가했습니다. 리그가 늘어날 때 모델명과 크롤러 책임을 먼저 분리해야 이후 데이터 확장 비용이 줄어든다는 점이 분명했습니다.
- 크롤러 인프라는 Lambda 코드만으로 끝나지 않았습니다. S3, CloudWatch Log Group, IAM, EventBridge를 Terraform으로 추가하고, 이후 EC2를 t4g.micro에서 t4g.small로 올리며 ECS task memory도 850MB에서 1850MB로 늘려 실행 여유를 확보했습니다.
- 종료를 앞둔 서비스에서도 권한 검증 누락은 그냥 넘길 수 없었습니다. theme kind 요청에서 대화 기록이 무조건 읽히던 보안 취약점을 막고, 프론트 관리자 화면의 any 타입과 API 응답 래핑도 함께 정리했습니다.