서비스 아키텍처 모듈화 - 100-hours-a-week/20-real-wiki GitHub Wiki
📐 1.아키텍처 구조
app/
├── main.py # FastAPI 앱 진입점, 전체 라우터 및 설정 로딩
├── api/
│ ├── router.py # API 전체 엔드포인트 등록용 모듈
│ └── v1/ # v1 버전: 초기 기능군 (챗봇, 공지요약, Discord 뉴스 요약)
│ │ ├── endpoints/
│ │ │ ├── chat_router.py # [챗봇 응답] → /api/v1/chatbots
│ │ │ ├── notice_router.py # [공지 요약] → /api/v1/notices/summarization
│ │ │ └── discordnews_router.py # [Discord 뉴스 헤드라인/요약] → /api/v1/news
│ │ └── controllers/
│ │ ├── chat_controller.py
│ │ ├── notice_controller.py
│ │ └── discordnews_controller.py
│ └── v2/ # v2 버전: 위키 기반 뉴스 기능
│ ├── endpoints/
│ │ └── wikinews_router.py # [위키 기반 뉴스 생성] → /api/v2/news
│ └── controllers/
│ └── wikinews_controller.py
│ └── v3/ # v3 버전: 퀴즈 생성 기능
│ ├── endpoints/
│ │ └── wikiquiz_router.py # [위키 기반 퀴즈 생성] → /api/v1/quizzes
│ └── controllers/
│ └── wikiquiz_controller.py
├── core/ # 공통 유틸리티 및 시스템 설정
│ ├── llm_client.py # LLM 호출 인터페이스
│ ├── vector_store.py # FAISS 벡터 스토어 로딩 및 검색
│ ├── config.py # 환경 변수, 설정값 관리
│ ├── embedding_model.py # RAG용 임베딩 모델 로딩
│ ├── logging_config.py # 요청/응답 로깅 설정 (운영 대비)
│ └── error_handler.py # 예외 처리 핸들러
├── services/ # 비즈니스 로직 계층
│ ├── chat_service.py # 챗봇 응답 생성 처리
│ ├── notice_service.py # 공지 요약 생성 처리
│ ├── discordnews_service.py # Discord 기반 뉴스 헤드라인/요약 처리
│ ├── wikinews_service.py # 위키 문서 기반 뉴스 생성 처리
│ └── wikiquiz_service.py # 위키 기반 퀴즈 생성 처리
├── schemas/ # 요청/응답 구조 정의 (Pydantic 모델)
│ ├── chat_schema.py
│ ├── notice_schema.py
│ ├── discordnews_schema.py
│ ├── wikinews_schema.py
│ └── wikiquiz_schema.py
├── model/ # LLM 추론 모듈
│ ├── qwen2_5_loader.py # Qwen2.5 모델 로딩 스크립트
│ └── prompt_template.py # 각 기능별 프롬프트 템플릿
├── scripts/
│ ├── create_vectorstore.py # docs/ 기반 벡터스토어 생성
│ ├── upload_to_gcs.py # 생성된 인덱스를 gcs로 업로드
└── docs/ # RAG용 내부 공지 문서
├── 공지사항1.md
└── 공지사항2.md
🚀 2. 각 모듈의 책임(domain)과 기능에 대한 설명
모듈 |
책임 (Domain) |
주요 기능 |
main.py |
앱 진입점 |
FastAPI 앱 실행, 전체 라우터 등록, 공통 설정 적용 |
api/*/endpoints |
라우터 정의 |
각 기능(API 버전별)의 HTTP 라우팅 경로 정의 |
api/*/controllers |
요청 핸들러 |
실제 API 호출 시 요청 검증, 서비스 호출, 응답 반환 |
core |
공통 유틸리티/핵심 설정 |
모델 클라이언트, 프롬프트 생성기, 캐시, 에러 처리, 설정 관리 |
services |
비즈니스 로직 처리 계층 |
각 기능별 서비스 로직, LLM 추론 호출, 응답 포맷 처리 |
schemas |
데이터 구조 정의 |
요청/응답에 사용하는 Pydantic 기반 데이터 클래스 |
model |
모델 서빙 로직 |
Qwen2.5 모델 로딩, 텍스트 생성 함수, 프롬프트 템플릿 정의 |
📦 3. 모듈 간 인터페이스 설계
flowchart TD
A[Client Request] --> B["Router: endpoints"]
B --> C["Controller: controllers"]
C --> D["Service: services"]
D --> E["Model: generate.py"]
D --> F["Core: Prompt Builder & LLM Client"]
D --> G["Core: Cache, Config"]
C --> H["Schemas: Pydantic"]
- Router ↔ Controller: FastAPI 라우터 경로를 통해 컨트롤러 호출 (APIRouter)
- Controller ↔ Service: 요청 데이터를 Pydantic으로 파싱 후, service 로직 호출
- Service ↔ Model/Core: 추론이 필요한 경우 core/model 함수 호출 (llm_client.generate_text(...))
- Service ↔ Cache: 응답 캐싱이 필요한 경우 core/cache 연동
- Service ↔ Prompt Template: 도메인별 템플릿 포맷을 가져와 prompt 구성
- 모든 계층 ↔ Schemas: 데이터 유효성 검증 및 응답 포맷 통일
💡 4. 모듈화 후 기대 효과 및 장점
- ✅ 확장성 확보: 각 기능은 독립적 모듈로 구성되어, 새로운 기능 추가 시 손쉽게 확장 가능
- ✅ 유지보수 용이: 각 계층이 분리되어 있어 디버깅, 리팩토링, 테스트가 간편
- ✅ 재사용성 증가: core, model, schemas 등은 여러 서비스에서 재사용 가능
- ✅ 병렬 개발 최적화: 팀 단위로 기능을 나눠 동시 개발 가능
- ✅ 마이크로서비스화 유리: 서비스 경계가 명확하여, 추후 모델 서빙 등을 별도 서비스로 분리하기 용이
☁️ 5. 모듈화된 설계가 팀의 서비스 시나리오에 부합함을 설명하는 근거
- 현재 팀의 서비스는 다기능 AI 응답 API로, 챗봇·헤드라인·위키뉴스·요약·퀴즈 등 기능별 처리가 명확히 요구됨
- 각 기능마다 입력 구조, 모델 프롬프트, 응답 포맷이 다르므로 기능 단위의 모듈 분리가 필요
- LLM 모델은 고비용 리소스를 사용하는 특수 모듈이므로, 별도 로직(model/, core/)으로 분리하여 재사용 및 효율적 자원 관리를 달성
- 추후 기능이 늘어나거나 모델 종류가 추가될 경우에도 서비스 단위 확장과 분산 배포(MSA)가 가능하도록 설계되어 있음