현대인들은 매일 같은 경로를 걸으며 플레이리스트에 저장된 익숙한 노래만 반복해서 듣는 경향이 있습니다. 새로운 음악을 발견하고 싶지만, 추천 알고리즘은 비슷한 장르만 제안하고, 커뮤니티는 음악보다 팬덤 중심으로 흘러갑니다.

우리는 "음악과 장소의 결합"이라는 새로운 시각으로 이 문제를 접근했습니다. 같은 장소를 걷는 사람들은 비슷한 감정을 느끼고, 그 순간에 어울리는 음악을 공유할 수 있다는 가설에서 출발했습니다. 단순한 음악 공유를 넘어, 장소에 담긴 추억과 서사를 나누는 경험을 제공하고자 했습니다.

기술적으로는 위치 기반 실시간 데이터 처리, 대용량 음악 파일 스트리밍, 그리고 음악+위치 결합 데이터를 분석하는 AI 시스템이라는 세 가지 핵심 과제가 있었습니다. 특히 초기 단계 스타트업으로서 제한된 예산 내에서 안정적인 서비스를 운영해야 하는 비용 최적화 문제도 중요한 도전이었습니다.

본 프로젝트는 MSA 아키텍처 기반으로 확장 가능한 시스템을 설계하고, AI 데이터 분석을 통해 음악 공유 경험을 극대화하며, 하이브리드 인프라로 비용을 최적화하는 것을 목표로 했습니다.

기술적 도전과제

1. RAG 기반 데이터 분석의 높은 비용 문제

문제 상황

비즈니스 요구사항: 음악+위치 결합 데이터를 분석하여 인사이트 제공
PostgreSQL, MongoDB, ElasticSearch 3개 DB 데이터를 임베딩하여 RAG 구현
월 80달러의 AI 컨텍스트 비용 발생
긴 컨텍스트로 인한 할루시네이션 발생 (데이터 신뢰성 문제)
매 요청마다 임베딩 과정으로 서버 부하 및 응답 속도 저하

해결 과정 (1단계: RAG → Text-to-SQL)

AI가 데이터를 직접 읽는 대신 SQL 질의문 생성 방식으로 전환
응답만 반환받아 컨텍스트 크기 대폭 감소
SQL Injection 방지를 위해 읽기 전용 권한 DB 계정 사용
DML 제어 차단으로 보안성 확보

문제 상황 (2단계)

DB마다 개별 질의문 작성 필요 (PostgreSQL, MongoDB, ElasticSearch)
서로 다른 DB 간 데이터 결합을 AI가 직접 계산
다시 할루시네이션 및 데이터 신뢰성 문제 발생

해결 과정 (2단계: Trino 도입)

Trino 쿼리 엔진 도입으로 이기종 DB 통합 조회
모든 DB 메타데이터를 AI에게 제공하여 정확한 쿼리 생성 유도
이전 요청을 Vector DB(Qdrant)에 저장하여 Few-shot Learning 적용
AI 정확도 향상 및 쿼리 생성 속도 개선

기술적 의사결정 근거

RAG는 비정형 문서 검색에 적합하지만, 구조화된 DB 조회에는 비효율적
Text-to-SQL은 SQL 스키마라는 명확한 구조로 할루시네이션 감소
Trino는 ANSI SQL 지원으로 AI가 표준 쿼리만 학습하면 됨
Few-shot은 Zero-shot 대비 쿼리 정확도 40% 향상
읽기 전용 권한으로 보안 리스크 최소화

결과

월 80달러 → 월 15달러로 비용 81% 절감
응답 속도 평균 8초 → 2초로 개선
데이터 신뢰성 확보 (할루시네이션 감소)

2. 스트리밍 서버 비용 최적화

문제 상황

AWS S3 + CloudFront로 음악 파일 서빙
일 평균 I/O 비용 2달러 발생 (월 60달러)
트래픽 증가 시 비용 선형 증가 우려

해결 과정

On-Premise 환경에 스트리밍 전용 서버 구축
Nginx의 sendfile 시스템콜로 커널 레벨 파일 전송
Zero-copy 기법으로 유저 스페이스 버퍼 생략
AWS와 VPN 터널링으로 안정성 확보

기술적 의사결정 근거

Nginx sendfile은 커널에서 직접 네트워크로 전송 (애플리케이션 레벨 대비 3배 빠름)
학교 서버 인프라 활용 가능 (고정 비용 0)
On-Premise 장애 시 AWS 자동 Failover 구성
음악 파일은 변경 빈도 낮아 캐싱 효율 극대화

결과

일 2달러 절감 (연간 730달러 절감)
평균 응답 속도 200ms → 80ms로 개선
동시 접속자 100명 → 500명 처리 가능

3. 어드민 서버 비용 최적화

문제 상황

AWS EC2 인스턴스 일 1.2달러 비용
실시간 모니터링 불필요 (관리자만 사용)
트래픽 낮음 (일 평균 50건)

해결 과정

On-Premise 서버로 이전
AWS와 VPN으로 메인 DB 접근
Prometheus + Grafana로 통합 모니터링

결과

일 1.2달러 절감 (연간 438달러 절감)
스트리밍 + 어드민 서버 통합 관리로 운영 효율 향상


4. 확장 가능한 MSA 아키텍처 설계

문제 상황

초기에는 모노리식 구조로 개발 시작
스트리밍과 비즈니스 로직이 혼재하여 성능 병목 발생
관리 기능이 메인 서버에 있어 보안 리스크 존재

해결 과정

메인 서버, 스트리밍 서버, 어드민 서버로 분리
각 서버의 책임 명확화 (단일 책임 원칙)
독립적인 기술 스택 선정 및 배포 파이프라인 구축

기술적 의사결정 근거

도메인이 아닌 성능 요구사항 기준으로 서버 분리
스트리밍은 I/O 중심, 메인은 비즈니스 로직 중심
각 서버의 기술 스택을 독립적으로 선택 가능

결과

스트리밍 성능 3배 향상
배포 독립성 확보 (메인 서버 배포 시 스트리밍 영향 없음)
향후 Kubernetes 기반 Auto-scaling 준비 완료

RE:MEDY는 지도 기반 음악 공유 커뮤니케이션 서비스입니다. 사용자가 매일 같은 거리를 걸으며 듣던 노래에서 벗어나 새로운 음악을 발견하고, 같은 장소에서 음악을 듣는 사람들과 공감대를 형성할 수 있는 플랫폼입니다. 단순한 음악 공유를 넘어 위치와 결합된 추억과 서사를 나누는 경험을 제공합니다.