서비스 아키텍처 V2 설계 - 100-hours-a-week/6-nemo-wiki GitHub Wiki

V2 아키텍처 설계 문서: 모듈화 관점

개요

버전 2는 네모 서비스에서 AI 기능을 확장성 있고 안전하게 통합하기 위한 구조로,
로컬 모델을 도입하고 모델 호출 흐름을 Gateway 기반 모듈로 분리하였습니다.
또한, 입력/출력 데이터에 대한 안전성 검증(Guardrail) 및 RAG(Retrieval-Augmented Generation) 구조를 통해
모델 응답 품질과 개인화 수준을 동시에 개선하고자 설계되었습니다.

아키텍처 다이어그램

image

모듈 구성 및 책임 정의

1. UI/UX + FE 서버

  • 사용자 입력 수신 및 결과 시각화
  • 대부분의 요청은 BE를 경유하나, 일부 경우 직접 AI 서버로도 연결

2. BE 서버 & DB

  • 사용자 인증 및 비즈니스 로직 처리
  • 모임 정보, 사용자 활동 기록 등 정형 데이터를 저장
  • AI 서버 요청을 위임 및 결과 반환

3. AI 서버 (FastAPI 기반)

- LangChain Gateway

  • 모델 라우팅 기능 수행
    • 텍스트 생성 모델: 목표/마일스톤, 모임 소개글 생성
    • 챗봇 모델: 질문 응답, 자연어 처리, 유저 대화 대응
  • 로컬 모델 기반으로 직접 호출되며, 모델 종류 및 용도에 따라 분기 처리

- Guardrail (PyDynamic 기반 예정)

  • 모델이 처리하기 어려운 입력을 사전에 걸러내는 입력 필터링 계층
  • 예시: 너무 긴 텍스트, 유해 표현, 금칙어, 구조상 비정형 입력 등
  • 출력 필터링도 가능하며, 향후 강화 예정

- Context Reconstruction

  • 사용자 요청 및 관련 데이터를 종합하여 모델에 전달할 context를 구성
  • 모임 정보, 사용자 입력, 이전 발화 등을 통합하여 더 적절한 프롬프트 생성

- AI DB

  • AI 기능 전용 메타데이터 저장소 (프롬프트, 키워드, 요청 로그 등)
  • RAG를 위한 검색 대상 포함
  • 추후 구조 결정 예정이나, AI 서버에서만 접근 가능하도록 설계

- 벡터 DB (RAG용)

  • 사용자 참여 이력, 관심사, 태그 등을 벡터화하여 검색
  • LangChain Gateway와 연결되어, 검색 결과를 기반으로 모델 입력 구성

인터페이스 설계

  • 모든 클라이언트 요청은 BE 서버를 기본 경유
  • AI 서버는 REST API 기반으로 내부 모듈을 호출
  • Gateway → Context → Guardrail → 모델 추론 → Guardrail → 결과 반환 흐름

모듈화 목적 및 설계 관점

설계 이유

  • 기능별 책임을 명확히 하여 AI 기능 추가/수정 시 영향 최소화
  • 로컬 모델을 도입하며 성능 제어 및 비용 관리 가능
  • Guardrail 계층과 Gateway 라우팅 구조 도입으로, 기능별 안정성 확보

구조적 고려 사항

  • 모든 주요 기능은 별도 모듈(파일 단위)로 분리되어 유지보수 용이
  • Gateway, Context, Guardrail 간 인터페이스 정의가 명확하여 테스트/교체 용이
  • RAG 기반 검색이 별도 계층으로 분리되어 재활용성 확보

기대 효과

  • 모델 선택 자유도 확보: 각 기능별로 최적화된 로컬 모델 할당 가능
  • 성능 최적화: 불필요한 요청 차단 및 context 구성 품질 향상
  • 기능 확장 기반 확보: 챗봇, 자동 요약, 추천 기능 등 다양한 도메인에 대응 가능
  • 비용 효율성: 외부 API 비용 제거, 모델 서빙 제어 가능

팀 시나리오와의 정합성

V2 구조는 "모임 자동 생성", "개인화 기반 커리큘럼 추천", "질문 응답 챗봇" 등
서비스 고도화를 위한 주요 기능 확장에 적합한 기반을 제공합니다.

RAG 기반 구조와 로컬 모델 라우팅은 향후 다양한 도메인으로의 확장성과 모델 대체 용이성을 고려한 구조이며,
모든 모듈이 독립적으로 구성되어 있어 이후 버전(V3)에서의 캐싱/고성능 최적화 적용에도 유연하게 대응할 수 있습니다.