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

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

개요

버전 1은 네모 서비스의 MVP 단계로, 빠른 개발과 배포를 목표로 단일 AI 서버 구조를 채택하였습니다.
외부 모델 API를 활용하여 실시간 AI 응답을 생성하며, 모델 서빙을 직접 운영하지 않고도 서비스 기능을 검증할 수 있도록 설계되었습니다.

모델 기능은 FastAPI를 통해 제공되며, 주요 기능으로는 모임 요약을 위한 Context Reconstruction과
데이터 조회용 Read-Only SQL 액션이 포함됩니다.

아키텍처 다이어그램

image

모듈 구성 및 책임 정의

1. UI/UX + FE 서버

  • 클라이언트의 입력을 수신하고 AI 요청을 서버로 전달
  • 응답 결과를 사용자에게 시각화하여 제공

2. BE 서버 & DB

  • 사용자 요청을 처리하고 내부 데이터베이스와 연동
  • 참가자 목록, 모임 정보 등 AI 추론에 필요한 데이터를 읽기 전용으로 제공

3. AI 서버 (FastAPI 기반)

- Context Reconstruction

  • 기능: 모임 정보 및 관련 데이터를 종합하여, 모임 소개글 또는 요약 문단을 구성하는 전처리 로직
  • 설계 의도: 모델 입력에 필요한 컨텍스트를 명확히 구성함으로써 응답 품질 향상

- Read-Only Actions (SQL)

  • 기능: 모임 관련 DB 데이터를 조회 (예: 참가자 목록, 시간 정보 등)
  • 목적: AI 입력에 필요한 필수 데이터를 실시간으로 확보

- 모델 API 연동 (Gemini 2.0-flash)

  • 연동 방식: 외부 API 호출 (Rate limit: 15 req/min 기준)
  • 선택 이유:
    • 로컬 모델 준비/파인튜닝 없이도 사용 가능
    • 성능 대비 비용이 없고 관리 부담이 없음
    • 별도 AI 서버를 항상 띄우지 않아도 되어 초기 단계에 적합

- AI DB (정형 데이터 저장소)

  • 구조: 정형 DB
  • 목적: 프롬프트, 요약 요청, 컨텍스트 메타데이터 등 AI 서버만 사용하는 전용 저장소
  • FE/BE DB와 분리하여 AI 중심 기능의 독립성과 확장성 확보

인터페이스 설계

  • BE 서버와 AI 서버 간: FastAPI 기반 REST 호출 (POST /generate-group-intro등)
  • FE 서버와 AI 서버 간: BE를 경유하여 API 통신
  • 외부 모델 API 호출: FastAPI 서버 내에서 비동기 방식으로 Gemini API 호출
  • 데이터 포맷:
    • 입력: JSON
      • 예시:
      {
  {
  "short_intro": "GPT 실습 중심의 AI 스터디입니다.",
  "detailed_intro": "이 모임은 생성형 AI(GPT)를 실제로 활용해보며, 실습 위주의 커리큘럼을 통해 실력을 키우는 것을 목표로 합니다. AI 초보자도 쉽게 따라올 수 있도록 구성됩니다.",
  "curriculum": [
  "1주차: 생성형 AI 개요 및 GPT 사용법",
  "2주차: 프롬프트 엔지니어링 실습",
  "3주차: LangChain 도구 실습",
  "4주차: GPT 기반 미니 프로젝트"
  ]
}
}
    • 출력: JSON
      • 예시:
      {
  "group_name": "GPT 실습 스터디",
  "category": "AI",
  "goal": "생성형 AI 도구를 학습하고 활용한다",
  "duration_weeks": 4,
  "is_public": true,
  "auto_accept": false,
  "use_ai_curriculum": true
}

모듈화 목적 및 설계 관점

설계 이유

  • MVP 단계에서는 빠른 구조 검증이 중요했기 때문에, 모델을 직접 호스팅하지 않고 외부 API를 사용하는 구조를 채택
  • 기능 중심으로 Context Reconstruction, 데이터 조회, 모델 호출을 명확히 구분
  • 추후 모듈별 분리를 고려하여 최소한의 단위로 기능을 정리

구조적 고려 사항

  • Read-only 방식으로 데이터를 활용하여 BE 로직과의 충돌을 최소화
  • 모델 호출을 단일 API 모듈로 캡슐화하여, 후속 단계(V2, V3)에서 LangChain Gateway 또는 Guardrail 등 기능 추가를 용이하게 하기 위한 기반

기대 효과

  • 빠른 배포 가능: 별도 모델 구축 없이도 실시간 AI 응답 서비스 구현
  • 비용 최소화: 무상 API 사용 및 운영 비용 절감
  • 유지보수 단순화: 단일 서버 내 구조로 디버깅과 검증 용이
  • 확장 기반 확보: 모듈 단위 분리가 가능하도록 설계되어 이후 구조 개편(V2/V3)으로의 전환이 자연스러움

팀 시나리오와의 정합성

본 구조는 "모임 소개 자동화", "간단한 정보 요약", "사용자 참여 기반 데이터 가공" 등의 초기 서비스 시나리오를 빠르게 구현하는 데 적합하며,
V2에서 Guardrail, Gateway 등이 추가되기 전 단계로서 역할을 수행합니다.
모델 호출 구조와 전처리 로직이 명확히 분리되어 있어, 향후 로컬 모델 교체 또는 캐싱 기능 추가 시에도 기존 흐름의 영향을 최소화할 수 있는 유연한 구조입니다.