프로젝트 한눈에 보기
별도의 감정 분석 모델로 텍스트·음성의 감정을 분석하고, 그 결과와 사용자 맥락을 RAG 기반 LLM에 전달해 상담 답변을 생성하는 서비스입니다. 6인 팀의 백엔드 담당자로서 Spring Boot와 FastAPI 기반 모델 API를 연동하고, 실시간 상담과 기록 저장·리포트를 연결했습니다.
- 개발 기간
- 2025.04.14 — 2025.05.22
- 프로젝트 형태
- 6인 팀 · BE 1 / FE 2 / AI 2 / 인프라·빅데이터 1
- 기술 스택
- Java · Spring Boot · PostgreSQL · Redis
- 제공 상태
- 팀 프로젝트 개발 완료 · GitHub에 코드 공개
내가 맡은 일
Spring Boot 백엔드 개발과 PL을 맡았습니다. 데이터베이스·API 설계부터 인증, 실시간 상담, FastAPI로 제공되는 감정 분석·LLM API 및 Spark·S3 연동, 상담 기록과 리포트의 저장·조회까지 구현하고 API 문서와 협업 규칙을 정리했습니다. 감정 분석 모델·LLM과 해당 FastAPI 서버, Spark 처리 서버, 프런트엔드와 인프라는 각 담당 팀원과 역할을 나눴습니다.
대표 기록
상담에서 기록으로
담담은 감정 분석 모델과 RAG 기반 LLM을 함께 활용한 AI 상담 서비스입니다. 감정 분석 모델이 텍스트·음성에서 감정 점수를 산출하면, LLM이 그 결과와 사용자 맥락을 반영해 상담 답변을 생성합니다. 사용자는 상담 후 대화 내용과 감정 변화를 살펴보고, 상담별·기간별 리포트를 확인할 수 있습니다.
- 로그인·프로필
소셜 계정으로 로그인하고 프로필과 선택적 사전 설문을 입력합니다.
- 텍스트·음성 상담
감정 분석 모델이 입력을 분석하고, LLM이 그 결과와 사용자 맥락을 반영한 상담 답변을 생성합니다.
- 상담별 리포트
리포트를 발행하면 상담 전문과 요약·분석 결과를 저장하고 상담을 종료합니다.
- 기록·기간 분석
지난 대화를 다시 읽거나 날짜 범위를 선택해 여러 상담을 묶은 리포트를 생성합니다.
백엔드는 상담 메시지를 전달하는 것과 함께 상담 상태, 메시지 순서, 외부 AI 요청, 기록 저장과 이후 조회를 관리합니다. 저는 이 단계들이 사용자·상담·리포트의 데이터 관계 안에서 이어지도록 설계하고 구현했습니다.
담당 범위와 기술
6인 팀에서 백엔드를 단독으로 담당하며 PL 역할도 맡았습니다. 계정·상담·리포트·문의·공지의 데이터 구조와 API를 구현하고, 프런트엔드와 AI 서버가 사용할 요청·응답 형식을 정리했습니다. 모델 개발은 AI 담당 팀원이, Spark 처리 서버와 배포 환경은 인프라·빅데이터 담당 팀원이 맡았습니다.
| 영역 | 기술 | 담당한 구현 |
|---|---|---|
| 서버 | Java 21 · Spring Boot | 계정·상담·리포트 등 도메인 API와 서비스 로직 |
| 인증 | Spring Security · OAuth2 · JWT | 소셜 로그인과 API·STOMP 인증 처리 |
| 데이터 | JPA · QueryDSL · PostgreSQL | 데이터 모델링과 저장·조회, 날짜·키워드 조건 검색 |
| 실시간 상담 | WebSocket · STOMP · Redis | 상담 메시지 전달, 진행 중인 상담 상태와 대화 기록 관리 |
| 외부 연동 | WebClient · Amazon S3 | FastAPI로 제공하는 감정 분석·LLM·Spark HTTP API 호출과 상담 전문·파일 저장 |
감정 분석 모델과 LLM은 각각 FastAPI로 API를 제공하고, Spring Boot에서는 WebClient로 호출했습니다. 감정 분석 결과를 백엔드 DTO로 변환해 사용자 발화·맥락과 함께 LLM 요청에 전달했습니다. 기간별 리포트에서는 Spark의 처리 결과를 LLM 요청에 연결했습니다.
시스템과 저장소 구성
- Next.js 웹
일반 HTTP API와 WebSocket·STOMP로 계정·상담·리포트 기능 사용
공통 API 요청
인증 · 상담 상태 관리 · AI 요청 조합 · 기록 저장과 리포트 조회
데이터 저장 · 외부 서비스 연동
- 감정 분석 모델 API · FastAPI
텍스트·음성 감정 분석 모델을 API로 제공 · 분석한 감정 점수를 Spring Boot에 반환
- RAG 기반 LLM API · FastAPI
감정 점수와 사용자 맥락을 받아 LLM 상담 답변 생성 · 상담 요약과 리포트 생성
- Spark API
선택한 기간의 상담 데이터를 처리해 기간 분석에 필요한 결과 제공
- Redis
진행 중인 상담 상태 · 남은 상담 횟수 · 순서가 있는 메시지 목록
- PostgreSQL
사용자·상담의 관계 · 상담별·기간별 리포트 · 서비스 데이터
- Amazon S3
리포트 발행 시 저장하는 상담 전문 · 업로드 파일
진행 중인 상담에는 상태와 메시지를 계속 갱신해야 하고, 종료된 상담에는 다시 읽을 수 있는 전문과 분석 결과가 필요했습니다. Redis에는 상담 중의 상태와 대화를, S3에는 리포트 발행 시의 상담 전문을, PostgreSQL에는 상담의 관계와 리포트를 저장하도록 역할을 나눴습니다.
조회 경로도 상담 상태에 따라 구분했습니다. 진행 중인 상담은 Redis의 메시지 목록을 사용하고, 리포트를 발행해 종료된 상담은 상담 엔티티에 연결된 S3 전문을 읽어 화면에 전달합니다.
감정 분석 모델과 LLM 연동
- 사용자 입력
텍스트 메시지 또는 음성 파일을 받습니다.
- 감정 분석 모델 · FastAPI
Spring Boot가 텍스트·음성 분석 API를 호출해 모델이 산출한 기쁨·분노·중립·슬픔·기타 감정 점수를 받습니다.
- Spring Boot에서 요청 조합
분석 결과를 사용자 발화·프로필·설문과 함께 LLM API 요청에 담습니다.
- RAG 기반 LLM · FastAPI
전달받은 정보로 상담 답변을 생성해 반환하면, Spring Boot가 WebSocket으로 화면에 전달합니다.
문제: AI 채팅에 필요한 정보가 전달되지 않았습니다.
LLM에 상담 응답을 요청할 때는 사용자 발화·배경과 별도 감정 분석 모델이 산출한 결과가 함께 필요했습니다. 모델별 API를 연결하는 과정에서 백엔드 DTO의 필드와 전달 값이 맞지 않아 AI 채팅 요청에 필요한 정보가 전달되지 않는 문제가 발생했습니다.
| 요청 필드 | 전달하는 정보 |
|---|---|
| messageInput | 현재 사용자 발화 |
| userContext | 사용자 프로필 · 선택적 사전 설문 · AI 설정 |
| emotion | 별도 감정 분석 모델이 산출한 해당 발화의 감정 점수 |
수정: 요청 DTO와 실제 데이터 전달 경로를 함께 정리
- DTO·빌더 일치messageInput 필드명과 요청 빌더를 맞추고, 감정 결과가 서비스 메서드에서 최종 LLM 요청까지 전달되도록 수정했습니다.
- 선택 정보 처리사전 설문을 작성하지 않은 사용자도 요청을 만들 수 있도록 처리하고, 미입력·미지정 정보를 구분했습니다.
- 음성과 발화 연결별도로 업로드한 음성 파일과 채팅 메시지를 messageOrder로 연결해 해당 발화의 감정 분석 결과를 사용했습니다.
수정 후 사용자 발화·사용자 맥락·감정 분석 결과를 하나의 LLM 요청으로 조합하는 경로를 연결했습니다. 백엔드에서 만든 값이 최종 요청에 포함되는지까지 살피며 서버 사이의 데이터 전달 문제를 다뤘습니다.
상담 기록과 리포트
실시간으로 주고받은 대화를 상담이 끝난 후에도 다시 읽고 분석할 수 있어야 했습니다. 한 번의 상담을 정리하는 경로와 여러 날의 상담을 분석하는 경로를 나누고, 각각에 필요한 저장 데이터와 외부 API를 연결했습니다.
상담별 리포트: 대화를 저장하고 상담을 마무리
- 대화 조회·분석
Redis에서 메시지와 감정 결과를 읽고 LLM에 상담 요약·분석을 요청합니다.
- 전문 저장
상담 전문을 S3에 저장하고 상담 엔티티에 저장 위치를 연결합니다.
- 리포트 저장
요약·분석 결과를 PostgreSQL의 상담별 리포트로 저장합니다.
- 상담 종료·정리
리포트 생성 이후 상담을 닫고 Redis의 대화 기록을 정리합니다.
상담별 리포트를 조회할 때는 메시지 순서로 사용자 발화와 감정 결과를 연결합니다. 사용자가 상담의 요약뿐 아니라 대화 중 감정 정보의 변화도 함께 살펴볼 수 있도록 응답을 구성했습니다.
기간별 리포트: Spark 결과와 사용자 맥락을 결합
사용자와 날짜 범위로 조회한 상담 중 전문이 저장된 상담이 최소 2건인지 확인한 뒤 Spark 처리 결과를 요청합니다. 반환된 감정 정보와 타임스탬프를 백엔드 DTO로 변환하고, 사용자 맥락을 더해 LLM에 기간 분석을 요청했습니다.
생성한 리포트에는 관련 상담 목록을 함께 저장합니다. 사용자가 기간 분석을 읽다가 그 바탕이 된 상담 기록으로 돌아갈 수 있도록 리포트와 상담의 관계를 유지했습니다.
LLM 오류와 상담 횟수
문제: 답변을 받지 못한 요청도 사용자에게 설명해야 했습니다.
LLM 호출이 실패하면 사용자는 정상적인 상담 답변을 받지 못합니다. 실패 상황을 채팅 화면에 알리고, 이 요청으로 남은 상담 횟수가 줄어들지 않도록 처리할 필요가 있었습니다.
| 상황 | 화면에 전달하는 내용 | 상담 상태 처리 |
|---|---|---|
| 정상 응답 수신 | AI의 상담 답변 | 정상 응답 이후 상담 횟수와 세션 상태 갱신 |
| LLM 호출 실패 | 백엔드에서 생성한 오류 안내 | 횟수 차감 단계로 진행하지 않으며 안내를 정상 AI 응답 저장 흐름에서 제외 |
정상 LLM 응답을 받은 뒤 상담 횟수를 갱신하도록 순서를 두고, 호출 예외에서는 오류 안내 메시지를 만들어 WebSocket으로 전달했습니다. 서버에서 만든 안내와 정상 상담 답변을 구분해 처리했습니다.
응답 시간과 저장 보완
Virtual Thread를 적용한 외부 I/O 처리
Java 21의 Virtual Thread executor를 감정 분석 API 호출과 음성 파일 업로드 작업에 적용했습니다. 감정 분석 결과가 있어야 다음 LLM 요청을 만들 수 있으므로, 상담 흐름에서는 해당 결과를 기다린 뒤 다음 단계로 진행합니다.
| 측정 구간 | 변경 전 | 변경 후 |
|---|---|---|
| 메시지 전송 → 답변이 화면에 표시 | 약 20초 | 약 10초 · 약 50% 단축 |
프로젝트 종료 후 상담 전문·리포트 저장 시 암호화 추가
2025년 5월 26일, 주요 개발 기간이 끝난 뒤 상담 전문과 리포트 문자열의 저장 처리를 보완했습니다. 상담 전문은 S3에 올리기 전에 암호화하고, 상담별·기간별 리포트의 요약·분석·조언 등 지정한 문자열 필드는 JPA 변환기를 통해 DB 저장 시 암호화하도록 했습니다.
조회할 때는 S3 전문 다운로드 또는 JPA 엔티티 변환 과정에서 복호화해 서비스에 필요한 형태로 사용합니다. 적용 대상은 S3의 상담 전문과 변환기를 지정한 DB 리포트 필드입니다.
협업과 구현 결과
프런트엔드·AI·인프라·빅데이터 담당자가 같은 요청과 응답 형식을 이해할 수 있도록 API 문서를 작성하고, Git·코드 컨벤션을 정리했습니다. 백엔드를 단독으로 맡은 만큼 각 시스템의 결과가 다음 단계에서 어떤 형태로 필요한지 연결하는 역할을 수행했습니다.
- API 문서계정·상담·리포트 등 도메인별 요청과 응답을 문서화해 연동 기준으로 사용했습니다.
- 이슈·MR 템플릿저장소에는 작업 유형별 이슈 템플릿과 관련 이슈·변경 설명·기능·리뷰 수정 내용을 정리하는 MR 템플릿이 있습니다.
- 역할별 연동AI 모델과 Spark 처리 서버의 결과를 백엔드 DTO로 변환하고, 프런트엔드에서 사용할 상담 응답과 리포트 조회 API로 제공했습니다.
담담에서는 로그인부터 상담 채팅, AI 분석, 기록 저장, 리포트 조회까지 백엔드의 기능과 데이터 관계를 설계하고 구현했습니다. 여러 서버와 저장소가 각자의 역할을 수행하면서도 사용자에게는 하나의 상담 경험으로 이어지도록 연결한 프로젝트입니다.