📋 [SoundView]

청각장애인을 위한 AI 기반 영상 자막 생성 및 햅틱 변환 서비스. 소리의 감각을 시각과 촉각으로 변환해서 청각장애인이 영상을 실감나게 시청할 수 있도록 도와줍니다.

👤 내 역할

역할	백엔드(FastAPI), 팀장, 발표
담당 파트	FastAPI를 활용한 GPU 서버 구축, 학습된 AI 모델 서빙

🛠️ 기술 스택

Backend	Java 17, Spring Boot 3.5.9, Spring Data JPA, Spring Security (OAuth2), JWT (0.12.3), WebSocket
Frontend	React 19.2.0, TypeScript, Node.js v24.12.0
AI	Python 3.9.23, FastAPI
Database & Messaging	MySQL 8.0.43, Redis (Alpine), RabbitMQ 3 (Management)
Infrastructure	AWS (EC2, S3, CloudFront), Docker / Docker Compose v3.8, Jenkins LTS, Nginx

⚠️ 트러블 슈팅

🚨 메세지 큐를 활용한 시스템 무결성 확보 및 종속성 개선

구분	상세 내용
🛑 문제 :	장애 발생 시 데이터 유실 리스크
	AI 서버(SoundView 오디오 처리)에 일시적인 장애나 지연이 발생할 경우, 백엔드에서 전송한 핵심 데이터가 그대로 유실될 수 있는 위험 존재
🔍 원인 :	서버 간의 강한 종속성
	백엔드 서버와 AI 서버가 직접적으로 연결되어 있어 한쪽의 장애가 다른 쪽의 정상적인 비즈니스 로직 수행까지 방해하는 구조적 한계
🛠️ 해결 :	RabbitMQ 기반의 비동기 메시지 큐 아키텍처 도입
	대규모 인프라에 적합하지만 오버헤드가 큰 Kafka 대신, 작업 할당 패턴에 최적화되고 처리 상태(ACK/Nack) 관리가 직관적인 RabbitMQ를 선택하여 각 서버의 기능을 독립적으로 분리
✨ 결과 :	결합도 완화 및 무결점 아키텍처 달성
	1. AI 서버에 장애가 발생해도 요청 데이터가 큐에 보존되어 복구 시 안전하게 재처리 가능 2. 백엔드는 MQ에 요청을 던지기만 하도록 역할을 분리하여, 시스템 확장성과 개발 편의성 대폭 향상

🚨 비동기 처리 지연 시 데이터 접근성 유지 및 Queue 안정성 확보

구분	상세 내용
🛑 문제 :	비동기 작업 적체 시 데이터 접근 권한 만료 위험
	대규모 영상 데이터가 RabbitMQ에 쌓여 처리가 지연될 경우 기존의 Pre-signed URL 방식은 유효 기간 만료로 인해 AI 서버에서 데이터에 접근하지 못할 가능성이 있음.
🔍 원인 :	Pre-signed URL의 유효 기간 제약
	보안을 위해 생성하는 Pre-signed URL은 일정 시간이 지나면 폐기됨. 비동기 환경에서 Consumer(FastAPI)의 처리 속도가 Producer(Spring Boot)의 발행 속도를 따라가지 못할 경우, 실제 처리 시점에 링크가 만료되는 구조적 결함 확인
🛠️ 해결 :	S3 Object Key 전달 및 도메인 기반 접근 방식 채택
	1. 큐에는 만료 시간이 없는 S3 고유 Key 값만 전달하여 데이터 식별 2. FastAPI 서버에서 .env로 관리되는 도메인 정보와 Key를 조합하여 영상에 접근하도록 설계하여 시간 제약 제거
✨ 결과 :	대규모 비동기 처리 가용성 극대화
	1. 영상 처리 대기 시간이 길어져도 데이터 접근 실패가 발생하지 않아 큐 적체 대응력 확보 2. 불필요한 URL 재생성 로직이 사라짐. 서버 리소스 최적화 및 시스템 간 통신 효율성 증대 3. 안정적인 비동기 파이프라인 구축으로 대량의 영상 분석 작업 시에도 높은 처리 성공률 유지

📚 배운 점

Trade-Off를 고려한 기술 선택

•

단순 최신 기술 도입이 아닌, 기술별 한계(Thread Pool의 데이터 휘발 등)를 분석하여 시스템 환경에 최적화된 도구(RabbitMQ)를 선택하는 의사결정 역량 향상.

•

보안(Pre-signed URL)과 대규모 비동기 가용성(S3 Object Key) 사이의 트레이드오프를 고민하며 내부망 아키텍처에 맞는 가장 효율적인 데이터 접근 방식을 설계하는 시야 확장.

느슨한 결합의 중요성

•

Spring Boot와 FastAPI 간의 직접적인 상태 의존성 제거, 컴포넌트 간 독립적 동작 보장.

•

특정 서버의 장애가 전체 시스템 마비로 이어지지 않는 가용성의 중요성을 체감했습니다

사용자 중심의 설계 사고

•

무거운 AI 처리 로직을 비동기로 분리하여 사용자 경험(UX)을 개선

•

큐 병목 현상으로 인해 발생할 수 있는 “데이터 만료”라는 엣지 케이스까지 선제적으로 해결하며 확장성 있는 백엔드 시스템 구축 철학 확립

📊 성과

✅

💡 측정 아이디어 1: 카오스 테스트 (장애 복구율 측정)
금융권이나 공공 인프라에서 가장 좋아하는 수치인 **'장애 시 데이터 유실률 0%'**를 증명하는 방법입니다.

Spring Boot 서버를 켜고 영상을 연속으로 50개~100개 업로드 요청을 보냅니다. (메시지 큐에 쌓이게 됨)

이때 의도적으로 FastAPI 서버를 강제 종료(Kill)합니다.

5분 정도 뒤에 FastAPI 서버를 다시 켭니다.

FastAPI 서버가 큐에 쌓여있던 50~100개의 데이터를 하나도 빠짐없이 처리하는지 확인합니다.

•

👉 포트폴리오 적용: ✅ 장애 시뮬레이션(Chaos Test) 결과: AI 서버 강제 다운 및 재기동 상황에서 대기 중인 요청 100건에 대해 데이터 유실률 0% 및 100% 자동 재처리 달성

💡 측정 아이디어 2: 로직 간소화 (코드 라인 수 감소)
개발 편의성이 좋아졌다는 것을 '코드의 복잡도 감소'로 수치화하는 방법입니다.

기존에 동기식(HTTP API)으로 호출할 때 짰어야 했던 코드(타임아웃 처리, 재시도 로직, 에러 핸들링 등)의 줄 수(Lines of Code)를 대략 계산해 봅니다.

RabbitMQ에 publish만 하는 현재 코드의 줄 수와 비교합니다.

•

👉 포트폴리오 적용: ✅ 통신 모듈 코드 복잡도 감소: 복잡한 동기식 예외 처리 및 재시도 로직을 MQ 발행 로직으로 대체하여 통신 관련 코드 라인 수(LOC) 약 00% 감소

📸 스크린샷

SoundView

Tech Stack