서비스 아키텍처 V3 설계 - 100-hours-a-week/6-nemo-wiki GitHub Wiki
V3 아키텍처 설계 문서: 모듈화 관점
개요
버전 3은 네모 서비스의 AI 기능을 운영 안정성과 성능 최적화 중심으로 재구성한 구조입니다.
모든 AI 관련 모듈을 완전히 분리된 구조로 설계하고, 반복 요청 처리 속도를 개선하기 위해 캐싱 계층을 도입하였습니다.
또한 사용자 이력 등 개인화 데이터를 AI 처리 흐름에 반영함으로써, 기능 정밀도와 응답 품질을 동시에 향상시킬 수 있도록 설계되었습니다.
아키텍처 다이어그램
모듈 구성 및 책임 정의
1. UI/UX + FE 서버
- 사용자의 모든 요청은 BE 서버를 기본 경유
- 일부 경우 FE → BE → AI 서버 → 응답 흐름 적용
2. BE 서버 & 일반 DB
- 서비스 전반의 사용자 정보, 모임 데이터, 일정 정보를 정형 형태로 저장
- AI 서버와의 데이터 연동은 읽기 위주
3. AI 서버 (FastAPI 기반)
- LangChain Gateway
- 텍스트 생성 / 챗봇 모델 분기
- 응답 캐시 여부 확인 → 캐시 hit 시 캐시 반환, miss 시 추론 진행
- Guardrail
- 입력/출력 안전성 필터링 (예: 유해 표현, 비정형 입력)
- PyDynamic 또는 유사한 모듈로 대체 가능
- 추론 이전 단계에서 필수 처리
- Context Reconstruction
- 요청 목적에 따라 필요한 데이터 구성 및 프롬프트 가공
- 이전 발화, 사용자 정보, 관심사 등 다층 context 구성
- 캐싱 모듈
- Gateway에 연동되어 자주 요청되는 질의/응답을 사전 캐싱
- 반복 요청에 대한 모델 호출 제거
- 주요 캐싱 항목: 일정 요약, 소개글, 추천 결과 등
- AI DB (정형)
- 프롬프트, 요청 로그, 사용자 태그, 생성 결과 등 AI 전용 데이터 저장
- 일반 서비스 DB와 완전히 분리되어 AI 서버만 접근 가능
- 벡터 DB (RAG용)
- 사용자 히스토리, 태그, 모임 참여 기록 등을 벡터로 저장
- Context Reconstruction 또는 Gateway에서 참조
인터페이스 설계
- 모든 클라이언트 요청은 BE를 경유
- AI 서버의 처리 흐름: Gateway → 캐싱 → Context → Guardrail → 모델 → Guardrail → 결과 저장 및 반환
모듈화 목적 및 설계 관점
설계 이유
- 반복 요청 최적화 및 처리 속도 개선이 주요 목적
- RAG, 챗봇, 텍스트 생성 등 다양한 기능 간 처리를 독립화
- 운영 중 모듈 단위 배포 및 관리가 가능하도록 파일 수준 분리
구조적 고려 사항
- 캐시 hit 시 즉시 응답 반환 가능하도록 Gateway에 로직 통합
- 모든 기능은 독립된 Python 모듈 또는 서비스 단위로 관리 가능
- Context 구성 로직은 다양한 모델에 재사용되도록 추상화 설계
기대 효과
- 성능 최적화: 반복 요청에 대한 모델 호출 제거
- 모듈 단위 스케일링 가능: 챗봇/생성 모듈 개별 확장 가능
- 개인화 대응: 사용자 이력 기반 RAG, Context 구성으로 정밀도 향상
- 관리 효율성 증대: 각 기능의 책임이 명확히 분리되어 운영 중 유지보수 용이
팀 시나리오와의 정합성
버전 3 구조는 “모임 자동 생성”, “일정 요약”, “추천 기능”, “커리큘럼 작성” 등
고성능 기반의 AI 응답이 필요한 고도화된 기능을 안정적으로 운영하기 위한 설계입니다.
캐싱 도입으로 응답 지연 문제를 개선하고, RAG 및 사용자 이력 반영 구조를 통해
정확성과 개인화 수준이 모두 향상되며, 이후 기능 확장 또는 고성능 모델 도입 시에도 유연하게 대응 가능한 구조입니다.