1. 아키텍처 개요

• 온기는 AI 기반 사진 정리 및 공유 플랫폼으로, 사용자가 업로드한 여행/일상 사진을 자동으로 분류, 정리, 변환하는 기능을 제공

• 카테고리별 사진 분류, 중복 제거, 품질 평가 등은 내부에 탑재된 AI 모델들을 통해 처리

• 아키텍처 버전 흐름

  버전	구조	주요 특징
  v1	모놀리식	모든 태스크를 controller → service 흐름 내에서 동기 처리
  v2	모놀리식 + 비동기 확장	CLIP 임베딩 후 duplicate/score/category/quality는 비동기 처리, 큐 + 워커 구조 도입
  v3 (예정)	마이크로서비스 분리	CLIP 및 face_recognition 모델 로딩/임베딩 기능을 독립 서비스로 분리 예정

---

2. 외부 연계 시스템과의 상호작용

• 현재 시스템은 LLM을 포함하지 않지만, 다음과 같은 외부 시스템 혹은 서브 시스템과의 상호작용이 존재

  항목	설명	외부 연계 여부
  S3 이미지 로딩	사용자 이미지 URL은 pre-signed S3 URL로 전달되어 외부에서 로드	✅
  Gemini 프롬프트 생성	스타일 변환을 위한 텍스트 프롬프트를 생성하기 위해 Gemini API를 호출하여 텍스트 생성	✅
  Stable Diffusion 스타일 변환	Stable Diffusion 모델은 별도 GPU 서버에서 호출해 처리	✅
  People (face clustering)	face_recognition 모델을 활용해 내부적으로 얼굴 분류	❌
  CLIP 임베딩	현재 내부 서비스에서 수행 중 (v3에서는 분리 예정)	❌

---

3. 현재의 외부 연계 처리 방식과 그 한계

a. 현재 외부 연계 처리 방식

기능	연계 방식
S3 이미지 로딩	requests.get() 기반 HTTPS 요청
Gemini 프롬프트 생성	내부에서 Gemini API에 HTTPS 요청
Stable Diffusion 스타일 변환	내부에서 GPU 서버에 HTTPS 요청

b. 한계

• 각 외부 시스템은 직접 명시적 호출 방식으로 tightly coupled
• 프롬프트 생성(Gemini)이나 스타일 변환(GPU 서버)과 같은 기능은 별도 추상화 없이 서비스 내부에 결합
• 도구 abstraction이 부재하여 유사 도구 교체(Gemini → GPT, 스타일 모델 교체 등)에 대한 구조적 유연성이 부족

---

4. MCP 도입 적정성 판단

a. MCP?

• **MCP (Model Context Protocol)**은 LLM 기반 애플리케이션이 외부 도구(API, DB, 파일 등)와 안전하고 유연하게 상호작용할 수 있도록 설계된 표준 프로토콜

b. MCP 핵심 사용 조건(전제)

1. LLM이 클라이언트 역할을 수행하며 도구를 호출할 수 있어야 한다.
2. 도구에 대한 선언적 abstraction이 존재하고, 이를 동적으로 선택할 수 있어야 한다.
3. 컨텍스트(사용자 입력, 프롬프트, 이전 대화 등)를 기반으로 도구 호출이 조정되어야 한다.
4. 보안, 권한 제어, 호출 기록 관리 등을 위한 통일된 인터페이스가 필요하다.
5. LLM ↔ 도구 간 통신은 JSON-RPC 기반으로 표준화되어야 한다.

c. 우리 서비스가 해당 조건을 충족하지 않는 이유

MCP 조건	현재 서비스 상태	충족 여부
LLM이 클라이언트	❌ LLM 미사용. 모든 요청은 사용자 → REST API로 전달	❌
도구를 선언하고 선택	❌ Gemini, S3, GPU 서버는 controller/service에서 명시적 호출	❌
Context-aware 도구 호출	❌ 프롬프트나 입력 조건에 따라 도구가 바뀌지 않음	❌
권한 및 호출 관리 계층 필요	⚠️ 각 도구마다 인증 방식이 개별적으로 처리됨	부분적
표준 통신 프로토콜(JSON-RPC)	❌ HTTPS + REST 기반 API로 충분	❌

---

5. MCP를 사용하지 않고도 충분한 이유

a. 요약

• MCP를 도입하지 않음으로 인해 일부 구조적 한계는 존재하지만, 현재 서비스의 특성과 운영 환경을 고려할 때 이러한 한계는 시스템 안정성과 유연성에 실질적인 영향을 주지 않는다고 판단

b. 한계 1. 외부 시스템 호출이 명시적이고 tightly coupled?

→ 예: 직접 Gemini API, Stable Diffusion GPU 서버에 요청

→ 충분한 이유

• 현재 호출 대상(Gemini, 스타일 서버, S3)은 구조가 단순하고 호출 방식이 고정
• 복잡한 컨텍스트 분기나 동적 선택이 필요하지 않아, 명시적 호출 방식으로도 충분히 안정적
• 호출 책임을 services/나 core/ 계층에 적절히 분산함으로써, 로직 재사용성과 테스트 가능성을 유지하고 있음
• 결국 tightly coupled 하더라도 도메인 경계를 침범하지 않는 수준으로 제어되고 있기 때문에 문제되지 않음

c. 한계 2. 별도 추상화 없이 서비스 내부에 결합?

→ 예: prompt_generator.py나 style_transformer.py가 특정 도구에 직접 의존

→ 충분한 이유

• 프롬프트 생성과 스타일 변환은 서비스 내부에서 기능 단위로 명확히 모듈화되어 있으며, 이를 통해 이미 내부 추상화 수준은 확보되어 있음
• LLM이 컨텍스트에 따라 도구를 선택하는 구조가 아니라서, 도구 선택의 동적 추론이 필요하지 않음
• 향후 필요 시 interface 패턴 또는 tool abstraction 구조로 확장 가능하므로, 현재 시점에서는 간단하고 직관적인 결합이 오히려 유지보수에 유리

d. 한계 3. 유사 도구 교체에 대한 구조적 유연성 부족?

→ 예: Gemini → GPT, 스타일 모델 교체 등이 어렵다.

→ 충분한 이유

• 현재 프롬프트 생성, 스타일 변환 기능은 모두 단일 모듈로 분리되어 있어, 실제 교체가 필요할 때는 해당 모듈만 수정하면 됨
  • 예를 들어, prompt_generator.py에서 Gemini API 호출을 GPT 호출로 바꾸는 건 비즈니스 로직에 영향 없이 가능
• 도구 교체 시 직접 호출 방식이 일관된 덕분에, 오히려 복잡한 추상화 없이 간결하게 교체 가능 (MCP 도입 대비 오버엔지니어링 방지)

---

6. 향후 MCP 적용이 필요한 가능성

시나리오	설명	MCP 도입 타당성
LLM 기반 사용자 인터페이스 도입	“흐릿한 사진만 골라줘” 같은 자연어 요청 분석	✅ 높음
다양한 도구 연결 (달력, 메시징, 앨범 추천 등)	LLM이 상황별로 API 선택	✅ 높음
외부 시스템 자동화 요청 (Slack 공유, 카카오 메시지 등)	사용자 명령 기반 실행	✅ 가능

---

7. 결론

• 현재 MCP의 핵심 적용 조건(LLM 기반 도구 호출, context-aware 추론 등)을 충족하지 않음
• 지금의 서비스 구조로도 외부 연계 처리에 충분한 안정성과 유연성을 확보하고 있음

→ 따라서 MCP는 현 시점에서 도입하지 않으며, 추후 확장에 대비한 기반만 유지