서비스 아키텍처 모듈화 - 100-hours-a-week/6-nemo-wiki GitHub Wiki
AI 서비스 아키텍처 설계 개요
이 문서는 네모 서비스의 AI 기능 도입 및 통합 과정에서의 아키텍처 구조 변화 과정을 정리한 것입니다.
단계별로 요구사항과 운영 환경에 따라 점진적인 모듈화와 기술 고도화가 적용되었으며,
각 버전은 설계 의도, 기술적 구성, 기대 효과가 명확히 구분됩니다.
해당 내용은 내부 구조 이해, 기술적 의사결정 근거 확보, 팀 간 협업 기반 마련을 목적으로 작성되었습니다.
1. 아키텍처 버전별 변화 개요
| 버전 | 주요 특징 | 핵심 구성 요소 | 설계 목적 |
|---|---|---|---|
| V1 (MVP) | 단일 FastAPI 기반 구조 | Context Reconstruction, Gemini API | 빠른 구축 및 시연 |
| V2 | RAG 구조, Guardrail 도입 | LangChain Gateway, 모델 분기 처리 | 안정성 및 응답 품질 확보 |
| V3 | 캐싱 계층 포함한 최적화 구조 | 사용자 이력 반영, 완전한 모듈화 | 확장성, 성능 최적화 |
2. 설계 흐름 요약
V1 (MVP)
- 모든 기능을 하나의 서버 내에 배치해 빠르게 MVP를 구현.
- Gemini 모델을 API로 호출하며, 모델 기능과 BE가 혼재된 구조.
- Context Reconstruction과 DB 조회 기능이 주요 AI 서버 로직.
- 장점: 빠른 개발, 단순 구조
- 제한점: 유지보수 어려움, 기능 확장에 비효율적
V2
- 모델 호출 및 출력 필터링 기능을 별도 모듈화.
- LangChain 기반 Gateway 구성, 텍스트 생성과 챗봇 응답 모델 분기 처리.
- Guardrail 계층 도입으로 입력/출력 제어, 비속어 및 금칙어 필터링 수행.
- AI DB 구조 정립: 프롬프트, 키워드 등 메타데이터 분리 저장
- 장점: 구조적 분리 시작, 품질/안전성 확보
- 제한점: 일부 처리 흐름은 여전히 결합되어 있음
V3
- BE 요청 흐름에 캐싱 계층을 도입, 반복 요청에 대한 성능 최적화.
- Guardrail, Context Reconstruction, 모델 라우팅 기능을 완전히 독립된 모듈로 운영.
- AI DB에 사용자 히스토리까지 저장, 개인화 기능 대응 기반 확보.
- 장점: 완전한 모듈화, 확장성 및 독립 배포 가능
- 제한점: 초기 설정 복잡도 및 모듈 간 인터페이스 관리 필요
3. 기술 스택 및 아키텍처 구성 변화
| 항목 | V1 | V2 | V3 |
|---|---|---|---|
| 모델 서빙 방식 | 외부 API 직접 호출 | Gateway 통한 내부 분기 | Gateway + 캐싱 |
| 주요 도입 기술 | FastAPI, Gemini | FastAPI, RAG, LangChain, Guardrail | FastAPI, RAG, LangChain, 캐싱 |
| 보안 및 필터링 | 없음 | 입력/출력 검열 (Pydynamic) | 입력/출력 검열 (Pydynamic 강화) |
| DB 처리 구조 | 단일 DB | AI DB 분리 | AI DB + 사용자 이력 저장 |
| 확장성 | 제한적 | 중간 수준 | 완전한 분산 및 독립 운영 가능 |
4. 모듈화 전략의 목적과 기대 효과
- 유지보수성 향상: 기능별 책임이 분리되어 디버깅 및 배포 리스크 감소
- 스케일링 유연성: 특정 AI 기능만 독립적으로 스케일 조정 가능
- 기능 고도화 기반: Guardrail, 개인화, 캐싱 등 고급 기능 도입의 사전 준비 완료
- 팀 간 병렬 작업 지원: 프론트/백엔드/AI 기능 간 작업 간섭 최소화