DEV.DY

오픈소스 릴리즈 요약 (26.01.18~26.01.25)

pfldy2850 — Sun, 25 Jan 2026 13:26:16 +0900

기간: 2026년 1월 18일 ~ 2026년 1월 25일
작성일: 2026년 1월 25일
대상 독자: ML/AI 개발자

개요

이 리포트는 추적 중인 주요 오픈소스 프로젝트들의 2026년 1월 18일부터 1월 25일까지의 릴리즈 변경사항을 기술적 관점에서 요약합니다. 총 62개의 릴리즈가 이 기간 동안 발행되었으며, 각 저장소 그룹별로 주요 업데이트와 기술적 개선사항을 정리했습니다.

주요 하이라이트:

ollama/ollama v0.15.0: 새로운 ollama launch 명령어 추가로 Claude Code, Codex, OpenCode, Droid 통합 지원
huggingface/trl v0.27.1: v0.27.0의 버그 수정 및 vLLM 호환성 개선
llama.cpp: 매우 활발한 개발 (48개 릴리즈), 지속적인 성능 최적화 및 버그 수정
vllm-project/vllm v0.14.1: 보안 및 메모리 누수 수정 패치 릴리즈
LangChain 1.2.7: 동적 도구 등록 및 미들웨어 개선
LlamaIndex v0.14.13: Ray 기반 분산 데이터 수집 파이프라인 추가
MTEB 2.7.3~2.7.9: 지속적인 버그 수정 및 개선
Milvus v2.5.26: 새로운 패치 릴리즈

저장소 그룹별 요약

1. LLM Frameworks

langchain-ai/langchain

릴리즈 수: 1개
주요 버전: langchain==1.2.7 (2026-01-23)
핵심 변경사항:
- 동적 도구 등록을 위한 미들웨어 지원 추가
- 요약 프롬프트 개선 (trailing whitespace 제거, 문법 개선)
- 버전 일관성 검사 pre-commit 훅 추가
- 의존성 업데이트 (uv 그룹)
기술적 세부사항:
- 동적 도구 등록: 미들웨어를 통한 런타임 도구 등록 기능
- SummarizationMiddleware 개선: 시스템 프롬프트 문법 개선 및 trailing whitespace 제거
- 버전 관리: langchain-core와 langchain 간 버전 일관성 검사 자동화
- 의존성 관리: uv를 사용한 의존성 그룹 업데이트

run-llama/llama_index

릴리즈 수: 1개
주요 버전: v0.14.13 (2026-01-21)
핵심 변경사항:
- Ray 기반 분산 데이터 수집 파이프라인 통합
- Agent 워크플로우에 early_stopping_method 파라미터 추가
- CodeSplitter에 토큰 기반 코드 분할 지원 추가
- 다중 모달 Condensed Conversation & Context 추가
- ChatMemoryBuffer를 Memory로 교체
- 다양한 벡터 스토어 통합 개선 (Milvus, Qdrant, Vertex AI 등)
- 새로운 LLM 통합 추가 (Apertis)
기술적 세부사항:
- RayIngestionPipeline: 분산 데이터 수집을 위한 Ray 통합
- Early Stopping: Agent 워크플로우에서 조기 종료 메서드 설정 가능
- 토큰 기반 코드 분할: CodeSplitter에서 토큰 단위 분할 지원
- 다중 모달 지원: Condensed Conversation & Context의 다중 모달 버전
- 메모리 관리: ChatMemoryBuffer를 더 범용적인 Memory 인터페이스로 교체
- 벡터 스토어 개선:
  - Milvus: 파티션 이름 지원
  - Qdrant: 검색 파라미터 지원
  - Vertex AI: 하이브리드 검색 지원
- 새로운 통합: Apertis LLM, HuggingFace datasets reader, Parallel Web System tools

2. Models & Training

huggingface/trl

릴리즈 수: 1개
주요 버전: v0.27.1 (2026-01-24)
핵심 변경사항:
- v0.27.0의 버그 수정 및 안정성 개선
- vLLM 서빙 모드에서 logprob drift 문제 수정
- DeepSeek OPSM에서 vLLM logprobs 전달 수정
- SFT 학습에서 prompt-completion 타입 및 Transformers v5 호환성 수정
- RewardTrainer의 재현성 문제 수정
기술적 세부사항:
- Logprob 정확도: vLLM 서빙 모드와 colocate 모드 간 logprob drift 문제 해결
- DeepSeek 지원: DeepSeek OPSM에서 vLLM logprobs 올바르게 전달
- Transformers v5 호환성: SFT 학습에서 Transformers v5와의 호환성 개선
- 재현성: RewardTrainer에서 결과 재현성 보장
- Gradient Accumulation: undefined current_gradient_accumulation_steps 문제 수정

3. Inference & Serving

ollama/ollama

릴리즈 수: 2개
주요 버전:
- v0.15.0 (2026-01-21) - 메이저 업그레이드
- v0.15.1 (2026-01-24) - 패치 릴리즈
핵심 변경사항:
- 새로운 ollama launch 명령어: Claude Code, Codex, OpenCode, Droid와의 통합 지원
- ollama run에서 다중 라인 문자열 (""") 지원 개선
- 키보드 단축키 개선: Ctrl+J 및 Shift+Enter로 새 줄 입력 지원
- GLM-4.7-Flash 모델의 메모리 사용량 감소
- CGO 플래그에 -O3 최적화 추가 (v0.15.1)
기술적 세부사항:
- ollama launch: 외부 도구와의 통합을 위한 새로운 명령어
  - Claude Code, Codex, OpenCode, Droid와 별도 설정 없이 사용 가능
- 다중 라인 입력: """를 사용한 다중 라인 문자열 생성 지원
- 키보드 단축키:
  - Ctrl+J: 새 줄 삽입
  - Shift+Enter: 새 줄 삽입
- 메모리 최적화: GLM-4.7-Flash 모델의 메모리 사용량 감소
- 컴파일 최적화: CGO 플래그에 -O3 최적화 레벨 추가로 성능 향상

ggerganov/llama.cpp

릴리즈 수: 48개 (매우 활발한 개발)
주요 버전: b7765 ~ b7825 (2026-01-18 ~ 2026-01-24)
핵심 변경사항:
- 지속적인 성능 최적화 및 버그 수정
- Jinja 템플릿 엔진 개선 (none|string 지원)
- 파일 I/O 개선 (fallback 확장, fileno 수정, mmap dio 파일 처리)
- llama-fit-params 개선 (--ctx-size 0 명시적 유지)
- 다양한 플랫폼 바이너리 제공 지속
기술적 세부사항:
- Jinja 템플릿: none|string 타입 지원 추가, as_string() 메서드 추가
- 파일 I/O:
  - Fallback 메커니즘 확장
  - fileno 처리 개선
  - mmap에서 dio 파일 사용 케이스 제외
- 파라미터 피팅: llama-fit-params에서 --ctx-size 0 명시적 유지
- 플랫폼 지원:
  - macOS (Apple Silicon, Intel), iOS
  - Linux (Ubuntu x64, s390x)
  - Windows (x64, arm64, CUDA 12/13, Vulkan, SYCL, HIP)
  - openEuler (x86, aarch64, 310p, 910b, ACL Graph)

vllm-project/vllm

릴리즈 수: 1개
주요 버전: v0.14.1 (2026-01-24)
핵심 변경사항:
- 보안 및 메모리 누수 수정 패치 릴리즈
- v0.14.0 기반 안정성 개선
기술적 세부사항:
- 보안 패치: 보안 취약점 수정
- 메모리 누수: 메모리 누수 문제 해결
- 안정성: v0.14.0의 안정성 개선

4. Distributed Training

이 기간 동안 새로운 릴리즈가 없었습니다.

5. Vector Search & Embeddings

embeddings-benchmark/mteb

릴리즈 수: 7개
주요 버전:
- 2.7.3 (2026-01-19)
- 2.7.4 (2026-01-19)
- 2.7.5 (2026-01-19)
- 2.7.6 (2026-01-20)
- 2.7.7 (2026-01-20)
- 2.7.8 (2026-01-20)
- 2.7.9 (2026-01-24)
핵심 변경사항:
- 지속적인 버그 수정 및 개선
- 집계 작업 저장 문제 수정 (2.7.6)
- PubChem 데이터 로드에 kwargs 추가 (2.7.9)
기술적 세부사항:
- 데이터 저장: 집계 작업 저장 로직 수정
- 데이터 로딩: PubChem 데이터 로드 함수에 kwargs 파라미터 추가
- 안정성: 지속적인 버그 수정 및 안정성 개선

milvus-io/milvus

릴리즈 수: 1개
주요 버전: v2.5.26 (2026-01-23)
핵심 변경사항:
- 새로운 패치 릴리즈 (릴리즈 노트 준비 중)
기술적 세부사항:
- 릴리즈 노트가 곧 제공될 예정

상세 릴리즈 목록

LLM Frameworks

langchain-ai/langchain

langchain==1.2.7 (2026-01-23)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain%3D%3D1.2.7
작성자: github-actions[bot]
주요 변경사항:
- 동적 도구 등록을 위한 미들웨어 지원
- 요약 프롬프트 개선 (trailing whitespace 제거, 문법 개선)
- 버전 일관성 검사 pre-commit 훅 추가
- 의존성 업데이트

run-llama/llama_index

v0.14.13 (2026-01-21)

URL: https://github.com/run-llama/llama_index/releases/tag/v0.14.13
작성자: github-actions[bot]
주요 변경사항:
- Ray 기반 분산 데이터 수집 파이프라인 통합
- Agent 워크플로우 개선
- 다양한 벡터 스토어 통합 개선
- 새로운 LLM 통합 추가

Models & Training

huggingface/trl

v0.27.1 (2026-01-24)

URL: https://github.com/huggingface/trl/releases/tag/v0.27.1
작성자: qgallouedec
주요 변경사항:
- vLLM 서빙 모드에서 logprob drift 문제 수정
- DeepSeek OPSM에서 vLLM logprobs 전달 수정
- SFT 학습에서 Transformers v5 호환성 수정
- RewardTrainer의 재현성 문제 수정

Inference & Serving

ollama/ollama

v0.15.0 (2026-01-21)

URL: https://github.com/ollama/ollama/releases/tag/v0.15.0
작성자: github-actions[bot]
주요 변경사항:
- 새로운 ollama launch 명령어 추가
- 다중 라인 문자열 지원 개선
- 키보드 단축키 개선
- GLM-4.7-Flash 모델 메모리 사용량 감소

v0.15.1 (2026-01-24)

URL: https://github.com/ollama/ollama/releases/tag/v0.15.1
작성자: github-actions[bot]
주요 변경사항:
- CGO 플래그에 -O3 최적화 추가
- README 업데이트 (Ruby gem 정보)
- 문서화 개선

ggerganov/llama.cpp

주요 릴리즈 (2026-01-18 ~ 2026-01-24, 총 48개)

b7765 (2026-01-18 01:30 UTC) - 기간 시작

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7765
지속적인 성능 최적화 및 버그 수정

b7772 (2026-01-18 17:28 UTC)

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7772
주요 변경사항: Fallback 확장, fileno 수정, mmap dio 파일 처리 개선

b7798 (2026-01-22 01:40 UTC)

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7798
주요 변경사항: Jinja 템플릿 엔진에 none|string 지원 추가

b7825 (2026-01-24 22:03 UTC) - 기간 종료

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7825
주요 변경사항: llama-fit-params에서 --ctx-size 0 명시적 유지

vllm-project/vllm

v0.14.1 (2026-01-24)

URL: https://github.com/vllm-project/vllm/releases/tag/v0.14.1
작성자: khluu
주요 변경사항:
- 보안 및 메모리 누수 수정 패치 릴리즈
- v0.14.0 기반 안정성 개선

Vector Search & Embeddings

embeddings-benchmark/mteb

2.7.3 ~ 2.7.9 (2026-01-19 ~ 2026-01-24)

지속적인 버그 수정 및 개선
집계 작업 저장 문제 수정 (2.7.6)
PubChem 데이터 로드 개선 (2.7.9)

milvus-io/milvus

v2.5.26 (2026-01-23)

URL: https://github.com/milvus-io/milvus/releases/tag/v2.5.26
작성자: yanliang567
주요 변경사항: 릴리즈 노트 준비 중

주요 기술 트렌드

이번 기간 동안 관찰된 주요 기술 트렌드:

도구 통합 및 확장성: Ollama의 ollama launch 명령어로 외부 도구와의 통합 용이성 향상
분산 처리 강화: LlamaIndex의 Ray 기반 분산 데이터 수집 파이프라인 추가
동적 기능 확장: LangChain의 미들웨어를 통한 동적 도구 등록 지원
성능 최적화 지속: llama.cpp의 지속적인 성능 최적화 및 버그 수정 (48개 릴리즈)
메모리 효율성: Ollama의 GLM-4.7-Flash 모델 메모리 사용량 감소
템플릿 엔진 개선: llama.cpp의 Jinja 템플릿 엔진에 타입 지원 확대
보안 및 안정성: vLLM의 보안 패치 및 메모리 누수 수정
재현성 보장: TRL의 RewardTrainer 재현성 문제 수정
벡터 스토어 통합 확대: LlamaIndex의 다양한 벡터 스토어 통합 개선
vLLM 호환성 개선: TRL의 vLLM 서빙 모드 logprob 정확도 개선

API 변경사항

ollama/ollama v0.15.0

새로운 API: ollama launch 명령어 추가
- Claude Code, Codex, OpenCode, Droid와의 통합 지원
개선된 API:
- ollama run에서 다중 라인 문자열 (""") 지원 개선
- 키보드 단축키: Ctrl+J 및 Shift+Enter로 새 줄 입력
마이그레이션 가이드: 기존 코드는 대부분 호환되며, 새로운 ollama launch 기능 활용 가능

langchain-ai/langchain v1.2.7

새로운 기능: 미들웨어를 통한 동적 도구 등록
개선된 기능: SummarizationMiddleware의 프롬프트 개선
마이그레이션 가이드: 기존 코드는 호환되며, 새로운 미들웨어 기능은 선택적 사용

run-llama/llama_index v0.14.13

새로운 통합:
- RayIngestionPipeline: 분산 데이터 수집
- Apertis LLM 통합
- HuggingFace datasets reader
- Parallel Web System tools
개선된 기능:
- Agent 워크플로우에 early_stopping_method 파라미터 추가
- CodeSplitter에 토큰 기반 분할 지원
- ChatMemoryBuffer를 Memory로 교체
마이그레이션 가이드: ChatMemoryBuffer 사용자는 Memory 인터페이스로 마이그레이션 권장

huggingface/trl v0.27.1

버그 수정:
- vLLM 서빙 모드에서 logprob drift 문제 해결
- DeepSeek OPSM에서 logprobs 전달 수정
- SFT 학습에서 Transformers v5 호환성 개선
마이그레이션 가이드: v0.27.0 사용자는 업그레이드 권장 (버그 수정 포함)

성능 개선

ollama/ollama v0.15.0

개선 영역: 메모리 사용량, 컴파일 최적화
성능 향상:
- GLM-4.7-Flash 모델의 메모리 사용량 감소
- CGO 플래그에 -O3 최적화 추가 (v0.15.1)

ggerganov/llama.cpp

개선 영역: 파일 I/O, 템플릿 엔진, 파라미터 피팅
성능 향상:
- Fallback 메커니즘 확장으로 I/O 안정성 향상
- Jinja 템플릿 엔진 개선으로 템플릿 처리 효율성 향상
- 지속적인 성능 최적화 (48개 릴리즈)

huggingface/trl v0.27.1

개선 영역: Logprob 정확도, 재현성
성능 향상:
- vLLM 서빙 모드에서 logprob drift 문제 해결로 정확도 향상
- RewardTrainer의 재현성 보장

새로운 모델/알고리즘

ollama/ollama v0.15.0

새로운 기능: ollama launch 명령어
- Claude Code, Codex, OpenCode, Droid와의 통합 지원
- 별도 설정 없이 외부 도구와 함께 사용 가능

run-llama/llama_index v0.14.13

새로운 통합:
- Apertis LLM: 새로운 LLM 통합 추가
- RayIngestionPipeline: 분산 데이터 수집 파이프라인
- HuggingFace datasets reader: HuggingFace 데이터셋 읽기 지원
- Parallel Web System tools: 병렬 웹 시스템 도구

보안 업데이트

vllm-project/vllm v0.14.1

보안 패치: 보안 취약점 수정
영향도: 보안 패치이므로 즉시 업그레이드 권장

통계 요약

총 릴리즈 수: 62개
저장소 그룹 수: 5개
활발한 저장소:
- ggerganov/llama.cpp: 48개 (가장 활발, 일일 다중 릴리즈)
- embeddings-benchmark/mteb: 7개
- ollama/ollama: 2개 (v0.15.0 메이저 업그레이드 포함)
- langchain-ai/langchain: 1개
- run-llama/llama_index: 1개
- huggingface/trl: 1개
- vllm-project/vllm: 1개
- milvus-io/milvus: 1개
주요 버전 업그레이드:
- ollama/ollama: v0.14.3 → v0.15.0 (메이저)
- embeddings-benchmark/mteb: 2.7.2 → 2.7.9
- langchain-ai/langchain: 1.2.6 → 1.2.7
- huggingface/trl: v0.27.0 → v0.27.1
- vllm-project/vllm: v0.14.0 → v0.14.1
- milvus-io/milvus: v2.5.25 → v2.5.26

다음 단계

이번 기간의 변경사항을 바탕으로 권장되는 다음 단계:

Ollama v0.15.0 업그레이드: 새로운 ollama launch 기능으로 외부 도구 통합 활용
vLLM v0.14.1 업데이트: 보안 패치 및 메모리 누수 수정 적용 (즉시 권장)
TRL v0.27.1 업데이트: vLLM 호환성 개선 및 재현성 문제 수정 적용
LangChain 1.2.7 업데이트: 동적 도구 등록 기능 및 요약 프롬프트 개선 활용
LlamaIndex v0.14.13 업데이트: Ray 기반 분산 데이터 수집 파이프라인 활용
llama.cpp 최신 버전 모니터링: 매우 활발한 개발이므로 정기적 업데이트 권장
MTEB 2.7.9 업데이트: 최신 버그 수정 및 개선사항 적용
Ollama launch 기능 실험: Claude Code, Codex 등 외부 도구와의 통합 테스트

참고 자료

OSS 릴리즈 요약

pfldy2850 — Sun, 18 Jan 2026 18:13:37 +0900

기간: 2026년 1월 1일 ~ 2026년 1월 18일
작성일: 2026년 1월 18일
대상 독자: ML/AI 개발자

개요

이 리포트는 추적 중인 주요 오픈소스 프로젝트들의 2026년 1월 1일부터 1월 18일까지의 릴리즈 변경사항을 기술적 관점에서 요약합니다. 총 169개의 릴리즈가 이 기간 동안 발행되었으며, 각 저장소 그룹별로 주요 업데이트와 기술적 개선사항을 정리했습니다.

주요 하이라이트:

huggingface/transformers v5.0.0rc2: 메이저 버전 5.0의 첫 번째 릴리즈 후보
huggingface/trl v0.27.0: 메이저 업그레이드로 VRAM 최적화 및 비동기 처리 지원
ollama/ollama v0.14.0~v0.14.2: 이미지 생성 모델 실험적 지원 및 TranslateGemma 추가
llama.cpp: 매우 활발한 개발 (139개 릴리즈), AMD GPU 최적화 및 Flash Attention 개선
Chroma 1.4.1: 다중 리전 지원 및 인덱싱 상태 추적 기능 추가
LangChain 1.2.x 시리즈: 지속적인 개선 및 타입 안정성 강화

저장소 그룹별 요약

1. LLM Frameworks

langchain-ai/langchain

릴리즈 수: 10개
주요 버전:
- langchain-core 1.2.6, 1.2.7, 0.3.82, 0.3.83
- langchain 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
핵심 변경사항:
- LangChain 1.2.x 시리즈 지속적인 개선
- Agent 프레임워크 개선 및 타입 안정성 향상
- SummarizationMiddleware 시그니처 불일치 수정
- Agent 이름 메타데이터 추가
- 모델 ID 사용법 명확화
- UUID7 기반 run ID 사용
기술적 세부사항:
- UUID7 도입: run ID에 UUID7 사용으로 시간 기반 정렬 및 고유성 보장
- 타입 안정성: Mypy 규칙 강화 (warn_return_any, warn-unreachable 활성화)
- 메시지 태깅: 요약에서 생성된 메시지 자동 태깅 시스템
- 메타데이터 관리: Agent 이름 메타데이터 자동 추가 및 스트리밍 지원
- Ruff 업그레이드: 버전 0.14.11로 업그레이드
- 요약 프롬프트: 요약 프롬프트 업데이트 및 메타데이터 구성 추가

2. Models & Training

huggingface/transformers

릴리즈 수: 3개
주요 버전:
- v5.0.0rc2 (2026-01-08) - 메이저 버전 5.0 첫 릴리즈 후보
- v4.57.4, v4.57.5, v4.57.6 (패치 릴리즈)
핵심 변경사항:
- Transformers 5.0.0rc2: 메이저 버전 5.0의 첫 번째 릴리즈 후보
- v4 시리즈의 마지막 패치 릴리즈 (v4.57.4~v4.57.6)
- Qwen2VL 및 Qwen2.5VL 모델 타입 로딩 문제 수정
- Grouped beam search 개선
기술적 세부사항:
- v5.0.0rc2: 메이저 버전 업그레이드의 첫 번째 릴리즈 후보 (프로덕션 사용 전 테스트 권장)
- Qwen VL 모델 수정: config 저장 후 재로딩 시 model_type이 올바르게 유지되도록 수정
- Grouped beam search: config 파라미터에서 grouped beam search 지원
- 오프라인 모드: Mistral base 체크를 조건부로 변경하여 오프라인 로딩 개선
- vLLM 호환성: vLLM 관련 버그 수정

huggingface/peft

릴리즈 수: 1개
주요 버전: v0.18.1 (2026-01-09)
핵심 변경사항:
- Transformers v5 릴리즈를 위한 호환성 개선
- AMD ROCm 지원 수정
- Transformers 버전 요구사항 회귀 버그 수정
기술적 세부사항:
- Transformers v5와의 호환성을 위한 특수 케이스 수정
- AMD ROCm 환경에서 PEFT 실행 가능하도록 수정
- Transformers >= 4.52 요구사항 회귀 버그 수정

huggingface/trl

릴리즈 수: 1개 (메이저 업그레이드)
주요 버전: v0.27.0 (2026-01-16)
핵심 변경사항:
- 성능 최적화: Forward pass 중 VRAM 사용량 최대 50% 감소
- 비동기 처리: 보상 함수의 비동기 지원 및 병렬화
- vLLM 통합: vLLM 0.12.0 지원 및 vllm_group_port 인자 추가
- 새로운 알고리즘: GDPO (Group reward-Decoupled Normalization Policy Optimization) 추가
- DeepSeek 지원: DeepSeek V3.2 Off-policy 시퀀스 마스킹 지원
기술적 세부사항:
- VRAM 최적화: forward_masked_logits 함수로 forward pass 중 VRAM 사용량 대폭 감소
- 비동기 보상 함수: RLOO 및 일반 보상 함수에서 비동기 지원 및 병렬 호출
- BFD Packing: 잘린 토큰 보존 기능 추가
- Gradient Checkpointing: 기본값을 use_reentrant=False로 변경 (PyTorch 권장사항)
- 다중 보상 최적화: GDPO를 통한 다중 보상 함수 동시 최적화
- GRPO 개선: 도구 호출 반복 횟수 제한 설정 추가
- 실험적 기능 정리: 여러 유틸리티를 experimental.utils로 이동하여 API 구조화
- 다중 GPU 지원: 다중 GPU 사용 시 데이터셋 스트리밍 및 dtype 초기화 문제 해결
- Transformers 5.0 호환성: Transformers 5.0.0+ 호환성 개선 및 버그 수정

3. Inference & Serving

ollama/ollama

릴리즈 수: 4개
주요 버전:
- v0.14.0 (2026-01-10)
- v0.14.1 (2026-01-14)
- v0.14.2 (2026-01-16)
- v0.14.3-rc1 (2026-01-16)
핵심 변경사항:
- 실험적 이미지 생성 모델 지원 (macOS, Linux CUDA)
- TranslateGemma 모델 추가 (55개 언어 번역 지원)
- macOS 자동 업데이트 서명 검증 문제 수정
- CLI 개선 (Shift+Enter로 새 줄 입력)
- OpenResponses 스펙 준수 개선
- Anthropic API 호환성 (/v1/messages API 지원)
기술적 세부사항:
- 이미지 생성 모델: Z-Image-Turbo 실험적 지원 (macOS, Linux CUDA), MLX 기반
- 번역 모델: Gemma 3 기반 TranslateGemma로 55개 언어 간 번역 지원
- 실험적 CLI: ollama run --experimental로 agent loop 및 bash 도구 포함 CLI 제공
- API 개선: /v1/responses 엔드포인트가 OpenResponses 스펙에 더 잘 부합
- Anthropic 호환성: /v1/messages API 지원으로 Anthropic API와 호환
- VRAM 측정: AMD iGPU에서 더 정확한 VRAM 측정
- Modelfile: REQUIRES 명령으로 필요한 Ollama 버전 선언 가능

ggerganov/llama.cpp

릴리즈 수: 139개 (매우 활발한 개발)
주요 버전: b7598 ~ b7770 (2026-01-01 ~ 2026-01-18)
핵심 변경사항:
- AMD GPU 최적화: Vulkan Matmul 파라미터 최적화, RDNA4용 fattn-mma-f16 추가
- Flash Attention 최적화 및 CPU 지원
- Jinja 템플릿 엔진 개선 (attribute 지원)
- 다양한 플랫폼 바이너리 제공 확대
- 지속적인 성능 개선 및 버그 수정
기술적 세부사항:
- AMD GPU 최적화:
  - Vulkan에서 AMD GPU (Coopmat 지원)를 위한 큰 matmul 파라미터 조합 최적화
  - RDNA4 아키텍처를 위한 fattn-mma-f16 커널 추가
  - HIP 백엔드 개선
- Flash Attention:
  - VQ mma, flash_attn_ext_f16_iter, KQ_rowsum 최적화
  - CPU 사이드 지원 활성화
  - 커널 선택 로직 개선
- Jinja 템플릿:
  - join, map, sort에 attribute 지원 추가
  - 음수 배열 인덱스 및 기본값 지원
- 플랫폼 지원:
  - macOS (Apple Silicon, Intel), iOS
  - Linux (Ubuntu x64, s390x)
  - Windows (x64, arm64)
  - openEuler (x86, aarch64, 310p, 910b, ACL Graph)
- 백엔드 지원: CUDA 12/13, Vulkan, SYCL, HIP
- DeepSeek 모델: DeepSeek-R1-Distill-Qwen-1.5B 기본 튜닝

4. Distributed Training

이 기간 동안 새로운 릴리즈가 없었습니다.

5. Vector Search & Embeddings

chroma-core/chroma

릴리즈 수: 2개
주요 버전:
- CLI 1.3.1 (2026-01-13)
- Chroma 1.4.1 (2026-01-14)
핵심 변경사항:
- Google Cloud Spanner 통합 강화
- 인덱싱 상태 추적 기능 추가 (Python, TypeScript, Rust 클라이언트)
- 다중 리전/다중 클라우드 구성 지원
- Eventual consistency 지원 (Query 노드 및 프론트엔드)
- WAL3 (Write-Ahead Log) 복제 인터페이스 추가
- Rust 클라이언트 0.12 업그레이드
기술적 세부사항:
- Spanner 통합:
  - SysDB 및 마이그레이션 서비스가 실제 Spanner에 연결
  - Spanner 마이그레이션을 Rust로 재구현
  - Rolling hash를 사용한 마이그레이션 관리
  - Rust SysDB에서 e2e tenant 및 데이터베이스 작업 지원
  - Spanner collection 및 segments 스키마 추가
- 인덱싱 상태:
  - Python, TypeScript, Rust 클라이언트에 인덱싱 상태 API 추가
  - 프론트엔드 로직 및 메터링 지원
  - 인덱싱 상태 추적을 위한 스키마 및 로직 추가
- 다중 리전 지원: Multi-region, multi-cloud 구성 지원
- Eventual consistency:
  - Query 노드에 eventual consistency 구현
  - 프론트엔드에 eventual consistency 지원 추가
  - Read-level 테스트 추가
- WAL3:
  - 복제된 인터페이스 추가
  - quorum_writer를 통한 병렬 future 조정
  - FragmentConsumer trait로 fragment 읽기 캡슐화
- 성능 개선:
  - Ordered blockfile writer에서 eager commit
  - Block ref drop 최적화 (copy to end 시 drop)
  - Cursor 정리 로직 개선 (재삽입 횟수 기반 purge)
- Rust 클라이언트: 버전 0.11.x → 0.12 업그레이드
- Collection affinity: Collection affinity 버그 수정
- 기타:
  - Tonic 버전 0.14로 업그레이드
  - Rust Log Service 스키마 추가
  - Globalize dead letter queue in SysDB

embeddings-benchmark/mteb

릴리즈 수: 10개
주요 버전:
- 2.6.2 ~ 2.6.9 (2026-01-02 ~ 2026-01-12)
- 2.7.0, 2.7.1, 2.7.2 (2026-01-13 ~ 2026-01-15)
핵심 변경사항:
- vLLM 지원 추가 (2.7.0): vLLM을 사용한 임베딩 모델 벤치마킹 지원
- CI 시스템을 uv로 마이그레이션 (2.6.2)
- ResultCache 직접 노출 (2.7.2)
- 누락된 점수 계산 문제 수정 (2.7.2)
- 새로운 모델 추가 (llama-embed-nemotron-8b, pixie_models, mixedbread-ai 모델, voyage-4 시리즈, nemotron rerank)
- 새로운 데이터셋 추가 (EuroPIRQRetrieval, ChemRxivRetrieval)
기술적 세부사항:
- vLLM 통합:
  - vLLM wrapper를 통한 고성능 임베딩 모델 벤치마킹 지원
  - Rerank 모델 지원 포함
  - Prompt 지원 추가
  - 벤치마크 예제 및 문서 추가
- CI 개선:
  - uv를 사용한 의존성 관리로 마이그레이션
  - GitHub Actions에서 uv sync 사용
  - Makefile 업데이트
- API 개선:
  - ResultCache를 mteb.ResultCache로 직접 노출하여 접근성 향상
  - 누락된 점수가 있는 결과 계산 로직 수정 (0 → NaN 처리)
- 새로운 모델 지원:
  - llama-embed-nemotron-8b
  - pixie_models
  - mixedbread-ai/mxbai-edge-colbert-v0-32m
  - mixedbread-ai/mxbai-edge-colbert-v0-17m
  - voyage-4, voyage-4-large, voyage-4-lite
  - nemotron rerank
- 새로운 데이터셋:
  - EuroPIRQRetrieval
  - ChemRxivRetrieval (ChemTEB v1.1)
- 버그 수정:
  - Git LFS 콘텐츠 처리 개선
  - Nemo retriever 버전 업데이트로 크래시 문제 해결
- 문서화: vLLM 링크 수정 및 문서 개선

상세 릴리즈 목록

LLM Frameworks

langchain-ai/langchain

langchain-core==1.2.6 (2026-01-02)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain-core%3D%3D1.2.6
작성자: github-actions[bot]

langchain==1.2.1 (2026-01-07)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain%3D%3D1.2.1
작성자: github-actions[bot]

langchain==1.2.2 (2026-01-07)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain%3D%3D1.2.2
작성자: github-actions[bot]

langchain==1.2.3 (2026-01-08)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain%3D%3D1.2.3
작성자: github-actions[bot]

langchain-core==1.2.7 (2026-01-09)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain-core%3D%3D1.2.7
작성자: github-actions[bot]

langchain-core==0.3.82 (2026-01-09)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain-core%3D%3D0.3.82
작성자: github-actions[bot]

langchain-core==0.3.83 (2026-01-13)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain-core%3D%3D0.3.83
작성자: github-actions[bot]
주요 변경사항: UUID7 기반 run ID 사용

langchain==1.2.4 (2026-01-14)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain%3D%3D1.2.4
작성자: github-actions[bot]
주요 변경사항: Agent 이름 메타데이터 추가, 타입 안정성 개선

langchain==1.2.5 (2026-01-16)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain%3D%3D1.2.5
작성자: github-actions[bot]
주요 변경사항: 요약 프롬프트 업데이트, 메타데이터 구성 추가

langchain==1.2.6 (2026-01-16)

URL: https://github.com/langchain-ai/langchain/releases/tag/langchain%3D%3D1.2.6
작성자: github-actions[bot]
주요 변경사항: SummarizationMiddleware 시그니처 불일치 수정

Models & Training

huggingface/transformers

v5.0.0rc2 (2026-01-08)

URL: https://github.com/huggingface/transformers/releases/tag/v5.0.0rc2
작성자: (확인 필요)
주요 변경사항:
- 메이저 버전 5.0의 첫 번째 릴리즈 후보
- 프로덕션 사용 전 테스트 권장

v4.57.4 (2026-01-13)

URL: https://github.com/huggingface/transformers/releases/tag/v4.57.4
작성자: vasqu
주요 변경사항: v4 시리즈의 마지막 패치 릴리즈

v4.57.5 (2026-01-13)

URL: https://github.com/huggingface/transformers/releases/tag/v4.57.5
작성자: vasqu
주요 변경사항: QwenVL 모델 타입 로딩 문제 수정 시작

v4.57.6 (2026-01-16)

URL: https://github.com/huggingface/transformers/releases/tag/v4.57.6
작성자: vasqu
주요 변경사항: Qwen2VL 및 Qwen2.5VL 모델의 config 저장/로드 시 model_type 불일치 문제 완전 해결

huggingface/peft

v0.18.1 (2026-01-09)

URL: https://github.com/huggingface/peft/releases/tag/v0.18.1
작성자: (확인 필요)
주요 변경사항: PEFT 라이브러리 업데이트

huggingface/trl

v0.27.0 (2026-01-16)

URL: https://github.com/huggingface/trl/releases/tag/v0.27.0
작성자: qgallouedec
주요 변경사항: 메이저 업그레이드 - VRAM 최적화, 비동기 처리, GDPO 추가 등

Inference & Serving

ollama/ollama

v0.14.0 (2026-01-10)

URL: https://github.com/ollama/ollama/releases/tag/v0.14.0
작성자: github-actions[bot]
주요 변경사항: 실험적 이미지 생성 모델 지원, Anthropic API 호환성

v0.14.1 (2026-01-14)

URL: https://github.com/ollama/ollama/releases/tag/v0.14.1
작성자: github-actions[bot]
주요 변경사항: Z-Image-Turbo 모델 사용 가능, macOS 자동 업데이트 수정

v0.14.2 (2026-01-16)

URL: https://github.com/ollama/ollama/releases/tag/v0.14.2
작성자: github-actions[bot]
주요 변경사항: TranslateGemma 모델 추가, CLI 개선

v0.14.3-rc1 (2026-01-16)

URL: https://github.com/ollama/ollama/releases/tag/v0.14.3-rc1
작성자: github-actions[bot]
주요 변경사항: macOS 시스템 종료 중 앱 종료 허용

ggerganov/llama.cpp

주요 릴리즈 (2026-01-01 ~ 2026-01-18, 총 139개)

b7598 (2026-01-01 00:30 UTC) - 기간 시작

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7598
주요 변경사항: (상세 정보 확인 필요)

b7707 (2026-01-11 20:03 UTC)

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7707
주요 변경사항: Vulkan에서 AMD GPU 최적화

b7723 (2026-01-13 19:31 UTC)

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7723
주요 변경사항: RDNA4용 fattn-mma-f16 추가, Flash Attention 최적화

b7768 (2026-01-18 04:10 UTC)

URL: https://github.com/ggml-org/llama.cpp/releases/tag/b7768
주요 변경사항: Jinja 템플릿 개선, openEuler ACL Graph 바이너리 추가

b7770 (2026-01-18 07:56 UTC) - 기간 종료

최신 릴리즈로 지속적인 성능 최적화 및 버그 수정

Vector Search & Embeddings

chroma-core/chroma

v2.5.25 (2026-01-08)

URL: https://github.com/chroma-core/chroma/releases/tag/v2.5.25
작성자: (확인 필요)

CLI 1.3.1 (2026-01-13)

URL: https://github.com/chroma-core/chroma/releases/tag/cli-1.3.1
작성자: github-actions[bot]

1.4.1 (2026-01-14)

URL: https://github.com/chroma-core/chroma/releases/tag/1.4.1
작성자: github-actions[bot]
주요 변경사항: Spanner 통합, 인덱싱 상태 추적, 다중 리전 지원

embeddings-benchmark/mteb

2.6.2 ~ 2.6.9 (2026-01-02 ~ 2026-01-12)

지속적인 버그 수정 및 모델 추가

2.7.0 (2026-01-13)

URL: https://github.com/embeddings-benchmark/mteb/releases/tag/2.7.0
작성자: KennethEnevoldsen
주요 변경사항:
- vLLM 지원 추가: vLLM을 사용한 임베딩 모델 벤치마킹 지원
- voyage-4-large, voyage-4-lite 모델 추가
- 문서 링크 문제 해결

2.7.1 (2026-01-14)

URL: https://github.com/embeddings-benchmark/mteb/releases/tag/2.7.1
작성자: KennethEnevoldsen
주요 변경사항:
- voyage-4 모델 추가
- nemotron rerank 추가
- EuroPIRQRetrieval 데이터셋 추가
- ChemRxivRetrieval 데이터셋 추가 (ChemTEB v1.1)
- 로깅 개선

2.7.2 (2026-01-15)

URL: https://github.com/embeddings-benchmark/mteb/releases/tag/2.7.2
작성자: KennethEnevoldsen
주요 변경사항:
- ResultCache 직접 노출
- 누락된 점수 계산 문제 수정
- pixie_models, mixedbread-ai 모델 추가

주요 기술 트렌드

이번 기간 동안 관찰된 주요 기술 트렌드:

비동기 처리 및 병렬화: TRL에서 보상 함수의 비동기 지원 및 병렬화로 학습 속도 향상
VRAM 최적화: TRL의 forward_masked_logits로 최대 50% VRAM 사용량 감소
다중 보상 최적화: GDPO를 통한 다중 보상 함수 동시 최적화 지원
AMD GPU 지원 강화: llama.cpp에서 RDNA4 아키텍처 최적화 및 HIP 백엔드 개선
이미지 생성 모델 확산: Ollama에서 실험적 이미지 생성 모델 지원 시작
타입 안정성 강화: LangChain에서 mypy 규칙 강화 및 타입 체크 개선
다중 리전/클라우드 지원: Chroma에서 다중 리전 및 다중 클라우드 구성 지원
Eventual Consistency: Chroma에서 eventual consistency 지원으로 확장성 향상
메이저 버전 업그레이드: Transformers 5.0.0rc2 릴리즈로 메이저 버전 전환 시작
vLLM 통합 확대: MTEB에서 vLLM 지원 추가로 고성능 임베딩 벤치마킹 가능

API 변경사항

huggingface/transformers v5.0.0rc2

변경된 API: 메이저 버전 업그레이드로 인한 API 변경 가능성
마이그레이션 가이드:
- 릴리즈 후보 단계이므로 프로덕션 사용 전 충분한 테스트 권장
- v4에서 v5로의 마이그레이션 가이드 확인 필요

huggingface/trl v0.27.0

변경된 API:
- AutoModelForCausalLMWithValueHead 및 AutoModelForSeq2SeqLMWithValueHead가 experimental로 이동
- 여러 유틸리티 함수가 experimental.utils로 이동
- DbrxForCausalLM 지원 제거
마이그레이션 가이드:
- 실험적 기능 사용 시 import 경로 변경 필요
- Deprecated 함수 및 파라미터 제거됨 (코드 업데이트 필요)

ollama/ollama

변경된 API: /v1/responses 엔드포인트가 OpenResponses 스펙에 더 잘 부합하도록 개선
새로운 API: /v1/messages API 추가 (Anthropic API 호환)
마이그레이션 가이드: 기존 코드는 대부분 호환되지만, OpenResponses 스펙 준수도 향상

chroma-core/chroma

새로운 API: 인덱싱 상태 추적 API 추가 (Python, TypeScript, Rust 클라이언트)
마이그레이션 가이드: 인덱싱 상태를 확인하려면 최신 클라이언트 버전 필요

embeddings-benchmark/mteb

새로운 API: vLLM wrapper를 통한 임베딩 모델 벤치마킹 지원
마이그레이션 가이드: vLLM을 사용한 벤치마킹을 위해 vLLM wrapper 사용법 확인 필요

성능 개선

huggingface/trl v0.27.0

개선 영역: Forward pass 중 VRAM 사용량
성능 향상: 최대 50% VRAM 사용량 감소 (forward_masked_logits 함수 사용 시)
추가 개선: 비동기 보상 함수로 학습 속도 향상

ggerganov/llama.cpp

개선 영역: Flash Attention 성능, AMD GPU 최적화
성능 향상:
- RDNA4 아키텍처에서 fattn-mma-f16 커널로 성능 향상
- Vulkan에서 AMD GPU (Coopmat 지원)를 위한 matmul 최적화

chroma-core/chroma

개선 영역: 쓰기 성능, 다중 리전 지원
성능 향상:
- Ordered blockfile writer에서 eager commit
- WAL3 복제 인터페이스로 쓰기 성능 향상

새로운 모델/알고리즘

ollama/ollama

새로운 모델:
- Z-Image-Turbo: 실험적 이미지 생성 모델 (macOS, Linux CUDA)
- TranslateGemma: Gemma 3 기반 번역 모델 (55개 언어 지원)
특징:
- 이미지 생성은 실험적 단계 (macOS, Linux CUDA만 지원)
- 번역 모델은 프로덕션 사용 가능

huggingface/trl

새로운 알고리즘:
- GDPO: Group reward-Decoupled Normalization Policy Optimization (다중 보상 RL 최적화)
- DeepSeek V3.2 Off-policy 시퀀스 마스킹: DeepSeek 모델을 위한 특화된 마스킹 전략
실험적 기능 정리:
- AutoModelForCausalLMWithValueHead, AutoModelForSeq2SeqLMWithValueHead를 experimental로 이동
- 여러 유틸리티 함수를 experimental.utils로 이동하여 API 구조화
제거된 기능: DbrxForCausalLM 지원 제거
다중 GPU 지원: 다중 GPU 사용 시 데이터셋 스트리밍 및 dtype 초기화 문제 해결
Transformers 5.0 호환성: Transformers 5.0.0+ 호환성 개선 및 버그 수정

embeddings-benchmark/mteb

새로운 모델 지원:
- llama-embed-nemotron-8b
- pixie_models
- mixedbread-ai/mxbai-edge-colbert-v0-32m
- mixedbread-ai/mxbai-edge-colbert-v0-17m
- voyage-4, voyage-4-large, voyage-4-lite
- nemotron rerank
새로운 데이터셋:
- EuroPIRQRetrieval
- ChemRxivRetrieval (ChemTEB v1.1)

보안 업데이트

이 기간 동안 특별한 보안 패치 릴리즈는 없었습니다.

통계 요약

총 릴리즈 수: 169개
저장소 그룹 수: 5개
활발한 저장소:
- ggerganov/llama.cpp: 139개 (가장 활발, 일일 다중 릴리즈)
- embeddings-benchmark/mteb: 10개
- langchain-ai/langchain: 10개
- chroma-core/chroma: 2개
- ollama/ollama: 4개
- huggingface/transformers: 3개 (v5.0.0rc2 포함)
- huggingface/peft: 1개
- huggingface/trl: 1개 (메이저 업그레이드)
주요 버전 업그레이드:
- huggingface/transformers: v4.57.x → v5.0.0rc2 (메이저)
- huggingface/trl: v0.26.0 → v0.27.0 (메이저)
- ollama/ollama: v0.13.x → v0.14.2
- embeddings-benchmark/mteb: 2.6.x → 2.7.2
- chroma-core/chroma: 2.5.x → 1.4.1
- langchain-ai/langchain: 1.2.0 → 1.2.6

다음 단계

이번 기간의 변경사항을 바탕으로 권장되는 다음 단계:

Transformers 5.0.0rc2 테스트: 메이저 버전 업그레이드이므로 프로덕션 사용 전 충분한 테스트 권장
TRL v0.27.0 업그레이드 고려: VRAM 최적화 및 비동기 처리로 학습 효율성 향상 가능
Ollama 이미지 생성 모델 실험: 실험적 단계이지만 이미지 생성 기능 테스트 가능
LangChain 1.2.6 업데이트: 타입 안정성 개선 및 버그 수정 적용
Transformers 4.57.6 업데이트: Qwen VL 모델 사용 시 필수 업데이트
llama.cpp 최신 버전 모니터링: 매우 활발한 개발이므로 정기적 업데이트 권장
Chroma 1.4.1 업데이트: 다중 리전 지원 및 인덱싱 상태 추적 기능 활용
MTEB 2.7.2 업데이트: vLLM 지원 및 새로운 임베딩 모델 평가 기능 활용

참고 자료

A2A 프로토콜이란?

pfldy2850 — Sun, 30 Nov 2025 18:35:33 +0900

인공지능(AI) 기술이 발전하면서, 각기 다른 역할을 수행하는 AI 에이전트들이 하나의 복잡한 목표를 달성하기 위해 협력하는 멀티 에이전트 시스템의 중요성이 커지고 있습니다. 하지만 서로 다른 플랫폼, 프레임워크, 개발사에서 만들어진 이질적인 에이전트들이 원활하게 "대화"하고 협력하는 것은 큰 도전이었습니다.

이러한 문제를 해결하기 위해 등장한 것이 바로 A2A(Agent-to-Agent) 프로토콜입니다.

A2A 프로토콜이란 무엇인가?

A2A 프로토콜은 AI 에이전트 간의 원활한 통신 및 협업을 가능하게 하는 오픈 표준(Open Standard) 프로토콜입니다.

이 프로토콜은 서로 다른 프레임워크로 구축되고, 다른 조직에 의해 소유 및 배포된 에이전트들이 사일로(Silos)를 허물고 하나의 연합된 시스템처럼 함께 작동하도록 공통 언어와 표준화된 데이터 구조를 제공합니다.

A2A가 해결하는 문제: '도구'가 아닌 '에이전트'로 소통하기

기존의 에이전트 협업 환경에서는 다음과 같은 핵심적인 문제들이 있었습니다.

에이전트 노출의 한계 (Agent Exposure): 개발자들은 종종 에이전트의 기능을 다른 에이전트에게 노출하기 위해 에이전트를 단순한 도구(Tool)로 래핑(Wrapping)하는 방식을 사용했습니다. 이는 모델 컨텍스트 프로토콜(MCP, Model Context Protocol)과 같은 도구 노출 방식과 유사하지만, 에이전트가 본질적으로 가진 협상, 추론, 계획, 위임과 같은 자율적인 능력을 제한합니다. A2A는 에이전트를 있는 그대로 노출하여 그들의 전체 기능을 활용할 수 있도록 합니다.
커스텀 통합의 비효율성 (Custom Integrations): 표준이 없는 환경에서는 에이전트 간의 모든 상호작용에 대해 맞춤형(Point-to-Point) 통합 솔루션이 필요해집니다. 이는 막대한 엔지니어링 오버헤드를 발생시키고, 시스템의 확장성과 유지보수를 어렵게 하며 혁신 속도를 늦춥니다.
상호 운용성 부족 (Interoperability Challenge): 다양하게 개발된 에이전트들은 서로의 기능을 쉽게 발견하거나, 안정적이고 안전하게 협업할 수 있는 표준화된 방법을 찾을 수 없어 개별적으로 고립됩니다.

A2A는 이 모든 문제를 해결하고, 에이전트가 단순한 '도구'가 아닌, 복잡한 다자간 상호작용(Multi-turn interaction)을 수행할 수 있는 자율적인 '개체(Autonomous Entity)'로서 소통할 수 있도록 지원합니다.

A2A 프로토콜 예시 시나리오: 복잡한 여행 계획

1. 사용자 요청과 협업의 필요성

사용자가 AI 어시스턴트에게 "국제 여행을 계획해 줘."와 같은 복잡한 요청을 보냅니다. AI 어시스턴트는 이 요청을 처리하기 위해 혼자서 모든 것을 할 수 없다는 것을 인지하고, 다음의 여러 전문 에이전트들과의 협업이 필요함을 판단합니다:

✈️ 항공편 예약 에이전트
호텔 예약 에이전트
환전 에이전트
현지 투어 추천 에이전트

2. A2A가 없을 때의 문제: 상호 운용성 문제

A2A 프로토콜이 표준화되어 있지 않다면, 위에서 언급된 각 에이전트는 서로 다른 개발사, 프레임워크, 배포 환경에서 구축되었기 때문에 다음과 같은 문제가 발생합니다.

고립된 에이전트: 각 에이전트는 서로의 기능을 발견하거나 직접적인 소통을 할 수 있는 표준화된 방법이 없습니다.
커스텀 통합: AI 어시스턴트(오케스트레이터)가 이들을 연결하려면 에이전트마다 별도의 맞춤형(Custom) 연결 코드를 작성해야 하며, 이는 확장성을 저해합니다.
제한된 상호작용: 에이전트를 단순한 '도구'로만 사용하게 되어, 에이전트 본연의 자율적인 추론, 협상, 다자간 소통(Multi-turn) 능력이 제한됩니다.

3. A2A를 통한 해결책: 상호 연결된 시스템

A2A 프로토콜을 사용하면 이 모든 문제가 해결되고, 에이전트들은 마치 하나의 상호 연결된 팀처럼 작동합니다.

에이전트 검색 및 위임: AI 어시스턴트(클라이언트 에이전트)는 표준화된 A2A 프로토콜을 사용하여 주변 환경의 모든 전문 에이전트들의 기능(Agent Card)을 검색하고 적절한 에이전트를 식별합니다. 이후 항공편 예약 에이전트에게 항공편 탐색 작업을 위임(Delegate)합니다.
원활한 통신: 항공편 에이전트가 최적의 항공편을 찾은 후, 그 정보를 다시 A2A를 통해 AI 어시스턴트에게 표준화된 데이터 구조로 전달합니다. AI 어시스턴트는 이 정보를 기반으로 호텔 예약 에이전트에게 필요한 날짜와 목적지를 전달하는 등 다음 단계로 작업을 연속적으로 위임합니다.
결과 통합 및 응답: 최종적으로 AI 어시스턴트는 모든 전문 에이전트(항공편, 호텔, 환전, 투어)로부터 받은 정보를 통합하고, 이를 사용자에게 하나의 완성된 매끄러운 여행 계획으로 제시합니다.

핵심 설계 원칙 및 기능

A2A 프로토콜은 넓은 채택과 엔터프라이즈급 기능을 위해 다음과 같은 주요 원칙을 기반으로 설계되었습니다.

원칙	설명
단순성 (Simplicity)	기존 표준(HTTP, JSON-RPC 2.0, SSE)을 활용하여 개발자 채택을 가속화합니다.
엔터프라이즈 준비 완료 (Enterprise Readiness)	강력한 인증(Authentication), 권한 부여(Authorization), 보안, 추적, 모니터링 등 엔터프라이즈 환경에 필수적인 요구 사항을 충족합니다.
비동기 지원 (Asynchronous)	장기 실행 작업(LRO)을 기본적으로 지원하며, 서버 발신 이벤트(SSE) 및 푸시 알림 메커니즘을 통해 에이전트나 사용자가 지속적으로 연결되어 있지 않은 시나리오도 효과적으로 처리합니다.
모달리티 독립성 (Modality Independent)	일반 텍스트를 넘어 파일, 구조화된 데이터, 오디오, 비디오 스트리밍 등 다양한 유형의 콘텐츠를 통한 소통을 지원합니다.
불투명한 실행 (Opaque Execution)	에이전트들은 자신의 내부 로직, 메모리, 또는 독점적인 도구를 노출하지 않고도 협력할 수 있습니다. 이는 지적 재산권을 보호하고 보안을 강화합니다.

AI 에이전트 스택 이해하기: A2A, MCP, 프레임워크 및 모델

A2A 프로토콜은 AI 에이전트 생태계 전체를 아우르는 더 넓은 에이전트 스택(Agent Stack) 내에서 매우 중요한 위치를 차지합니다. 에이전트 스택은 에이전트의 기초가 되는 모델부터, 개발 도구, 그리고 외부 자원 및 다른 에이전트와의 소통 표준까지 모든 계층을 포함합니다.

A2A의 위치와 역할

에이전트 스택은 일반적으로 다음과 같은 네 가지 계층으로 구성됩니다.

모델 (Models): 에이전트의 추론(Reasoning) 및 의사 결정의 근간이 되는 기초 엔진입니다. 일반적으로 대규모 언어 모델(LLM) 등이 여기에 해당하며, 에이전트의 '뇌' 역할을 합니다.
프레임워크 (Frameworks) 및 ADK: 에이전트를 실제로 구축하고 배포하기 위한 도구 키트입니다. LangChain, LangGraph, Crew AI, 그리고 Google의 ADK(Agent Development Kit) 등이 여기에 속합니다. A2A는 에이전트를 어떤 프레임워크로 만들었는지에 관계없이 통신을 가능하게 합니다.
MCP (Model Context Protocol): 에이전트가 자신의 추론을 수행하는 과정에서 외부 도구, API, 데이터 소스와 연결하여 필요한 정보를 얻고 행동을 실행할 수 있도록 돕는 표준입니다. MCP는 모델과 외부 자원 간의 연결을 담당합니다.
A2A (Agent-to-Agent Protocol): 서로 다른 조직에서, 다른 프레임워크로 구축되고 배포된 AI 에이전트 '개체'들이 서로를 호출하고, 복잡한 작업을 위임하며, 다자간 소통을 할 수 있도록 표준화합니다. A2A는 에이전트 간의 수평적 협력을 가능하게 합니다.

A2A와 MCP: 보완적인 관계의 이해

A2A와 MCP는 서로 경쟁하는 관계가 아니라, AI 에이전트의 역량을 극대화하기 위해 상호 보완적으로 작동합니다.

MCP의 역할: 에이전트가 계산기, 데이터베이스 쿼리 등 정의된 기능을 수행하는 정적인 외부 도구를 활용하여 데이터와 연결될 때의 복잡성을 줄이는 데 초점을 맞춥니다.
A2A의 역할: 에이전트가 단순히 도구를 사용하는 것을 넘어, 다른 에이전트에게 복잡한 작업을 위임하고, 추론을 바탕으로 협상 및 다중 턴(Multi-turn) 상호작용을 수행할 수 있도록 표준화합니다.

즉, A2A는 에이전트가 다른 에이전트를 '도구'가 아닌 '협력적인 동료'로 대우할 수 있도록 하여, AI 에이전트 생태계의 복잡성과 깊이를 한층 더 높여줍니다.

A2A 상호작용의 핵심 주체 (Core Actors in A2A Interactions)

A2A 프로토콜 기반의 상호작용은 크게 세 가지 핵심 주체(Actor)를 중심으로 이루어지며, 이들이 정의된 역할을 수행함으로써 복잡한 멀티 에이전트 워크플로우를 완성합니다.

1. 사용자 (User)

역할: 최종 사용자(End User)로서, 사람이 될 수도 있고 자동화된 서비스가 될 수도 있습니다.
기능: 작업을 시작하고, 하나 이상의 AI 에이전트의 도움이 필요한 목표(Goal)를 정의합니다. 사용자의 요청은 A2A 생태계 전체를 움직이는 출발점이 됩니다.

2. A2A 클라이언트 (Client Agent)

역할: 사용자(인간 또는 서비스)를 대리하여 행동하는 애플리케이션, 서비스, 또는 또 다른 AI 에이전트입니다.
기능: A2A 프로토콜을 사용하여 통신을 개시하는 주체입니다. 원격 에이전트의 기능을 검색하고, 인증을 거쳐, sendMessage 또는 sendMessageStream API를 호출하여 작업을 위임합니다. 여행 계획 시나리오에서는 최종 사용자에게 응답을 전달하는 오케스트레이터(Orchestrator) 역할을 수행합니다.

3. A2A 서버 (Remote Agent)

역할: AI 에이전트 또는 에이전트 시스템으로서, A2A 프로토콜을 구현한 HTTP 엔드포인트를 외부에 노출합니다.
기능: 클라이언트 에이전트로부터 요청을 수신하고, 실제 작업(Task)을 처리하며, 그 결과나 상태 업데이트를 클라이언트에게 반환합니다. 클라이언트의 관점에서 원격 에이전트는 내부 작동 방식, 메모리, 또는 독점적인 도구가 노출되지 않는 불투명한(Opaque, 블랙박스) 시스템으로 작동합니다.

A2A의 기본 통신 요소 (Fundamental Communication Elements)

A2A 프로토콜은 에이전트 간의 통신과 협업을 구조화하고 표준화하기 위해 다섯 가지 핵심 기본 요소를 사용합니다. 이 요소들은 에이전트가 안전하고 효율적으로 정보를 교환하고 작업을 추적할 수 있도록 돕습니다.

요소	설명	핵심 목적
에이전트 카드 (Agent Card)	에이전트의 신원, 기능(Capabilities), 서비스 엔드포인트(URL), 필요 인증 정보를 JSON 형태로 기술한 메타데이터 문서입니다.	클라이언트가 에이전트를 발견하고, 안전하고 효과적으로 상호작용하는 방법을 이해하도록 돕습니다.
작업 (Task)	에이전트에 의해 시작되며, 고유한 ID와 정의된 수명 주기(Lifecycle)를 가진 상태 유지(Stateful) 작업 단위입니다.	장기 실행 작업(LRO)을 추적하고, 여러 턴에 걸친 상호작용(Multi-turn interaction) 및 협업을 가능하게 합니다.
메시지 (Message)	클라이언트와 에이전트 간의 단일 턴(Single turn) 커뮤니케이션입니다. 내용(Part)과 역할("user" 또는 "agent")을 포함합니다.	지침, 문맥, 질문, 답변, 상태 업데이트 등 공식적인 결과물(Artifact)이 아닌 일반적인 소통을 전달합니다.
파트 (Part)	메시지나 결과물(Artifact) 내에서 사용되는 가장 기본적인 콘텐츠 컨테이너입니다. TextPart, FilePart, DataPart 등이 있습니다.	에이전트가 일반 텍스트를 넘어 파일, 구조화된 JSON 데이터 등 다양한 콘텐츠 유형을 유연하게 교환하도록 지원합니다.
결과물 (Artifact)	작업(Task)을 수행하는 동안 에이전트가 생성하는 실제 산출물 또는 구체적인 결과입니다(예: 문서, 이미지, 구조화된 데이터).	에이전트 작업의 구조화되고 검색 가능한 최종 결과를 전달합니다.

A2A 요청 라이프사이클 (A2A Request Lifecycle)

A2A 프로토콜에서 클라이언트 에이전트와 원격 에이전트 간의 상호작용은 복잡한 작업을 안전하고 신뢰할 수 있게 처리하기 위해 표준화된 라이프사이클을 따릅니다. 이 과정은 크게 에이전트 검색, 인증, 메시지 전송의 네 가지 주요 단계로 구성됩니다.

1. 에이전트 검색 (Agent Discovery)

가장 먼저 클라이언트 에이전트는 협력하고자 하는 원격 에이전트의 존재와 기능을 파악해야 합니다.

에이전트 카드(Agent Card) 요청: 클라이언트 에이전트는 원격 에이전트의 공개된 엔드포인트(예: /.well-known/agent-card)로 GET 요청을 보냅니다.
기능 확인: 원격 에이전트는 자신의 신원, 통신 엔드포인트, 제공하는 기능, 그리고 필요한 보안 메커니즘을 JSON 형식으로 정의한 에이전트 카드를 반환합니다. 클라이언트 에이전트는 이 카드를 분석하여 작업을 위임할 적절한 에이전트인지 판단합니다.

2. 인증 (Authentication)

에이전트 카드를 통해 보안 요구 사항을 파악한 후, 두 에이전트 간의 통신 보안을 확립합니다.

토큰 요청: 에이전트 카드에 명시된 securitySchemes(예: OpenID Connect)를 기반으로 인증 서버(Auth Server)에 접근하여 JWT(JSON Web Token)와 같은 보안 토큰을 요청합니다.
JWT 획득: 인증 서버는 유효성 검사를 거쳐 보안 토큰을 발급하고, 클라이언트 에이전트는 이를 후속 요청에 사용합니다.

3. 메시지 전송 (sendMessage API)

실제 작업 요청 및 처리가 시작되는 단계입니다.

요청 전송: 클라이언트 에이전트는 에이전트 카드에서 파악한 원격 에이전트의 URL로 보안 토큰(JWT)을 포함하여 POST /sendMessage API를 호출합니다. 이 요청에는 수행해야 할 작업의 상세 내용이 포함됩니다.
작업 및 응답: 원격 에이전트는 메시지를 처리하고, 이 요청을 기반으로 작업(Task)을 생성합니다. 이후 클라이언트에게 Task Response를 즉시 반환하여 요청이 성공적으로 접수되었음을 알립니다. 이 응답에는 작업 상태를 추적할 수 있는 정보가 포함됩니다.

4. 스트리밍 및 비동기 처리 (sendMessageStream API)

작업이 즉시 완료되지 않는 장기 실행 작업(LRO)이나 지속적인 업데이트가 필요한 경우에 사용되는 메커니즘입니다.

스트리밍 요청: 클라이언트 에이전트는 POST /sendMessageStream API를 호출합니다.
실시간 업데이트: 원격 에이전트는 Server-Sent Events (SSE) 메커니즘을 사용하여 다음의 이벤트를 클라이언트에게 실시간으로 스트리밍합니다.
- Task (Submitted): 작업이 접수되었음을 알립니다.
- TaskStatusUpdateEvent (Working/Completed): 작업의 현재 진행 상태(처리 중, 완료됨 등)를 알려줍니다.
- TaskArtifactUpdateEvent: 작업 과정 중 생성된 중간 결과물이나 최종 결과물(예: 이미지, 보고서 등)을 전달합니다.

이러한 라이프사이클은 A2A 프로토콜이 에이전트 간의 신뢰할 수 있고 비동기적인 협업을 가능하게 하는 핵심 기반입니다.

A2A Protocol

Agent2Agent (A2A) Protocol What is A2A Protocol? Welcome to the official documentation for the Agent2Agent (A2A) Protocol, an open standard designed to enable seamless communication and collaboration between AI agents. Originally developed by Google and no

a2a-protocol.org

K8S 개발 환경 세팅

pfldy2850 — Thu, 23 Oct 2025 11:19:11 +0900

kubectl 세팅

https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/

Install and Set Up kubectl on macOS

Before you begin You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.34 client can communicate with v1.33, v1.34, and v1.35 control planes. Using the latest compatible version of kubectl helps avoid

kubernetes.io

1. kubectl 바이너리 다운로드

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"

2. kubectl 바이너리에 실행권한 부여

chmod +x ./kubectl

3. 바이너리를 시스템 PATH 하위에 이동

sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl

podman 설치

https://podman.io/

Podman

Have fun coloring and learn about Podman! A decentralized team of open source container tool superheroes comes to the rescue when an asteroid storm threatens the planet. Learn about each tool—Podman, CRI-O, Buildah, Skopeo, and OpenShift—as they redesi

podman.io

minikube 설치

https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fhomebrew

minikube start

minikube is local Kubernetes, focusing on making it easy to learn and develop for Kubernetes. All you need is Docker (or similarly compatible) container or a Virtual Machine environment, and Kubernetes is a single command away: minikube start What you’ll

minikube.sigs.k8s.io

1. homebrew 이용해서 설치

brew install minikube

2. minikube 실행

minikube start

@lru_cache

pfldy2850 — Thu, 15 May 2025 20:42:02 +0900

일반적인 케이스에서는 당연하게 동작

max_size개 이상 mapping key가 들어오면 값을 갱신

객체의 메소드에서도 잘 동작

Milvus #1 - 아키텍처

pfldy2850 — Tue, 22 Apr 2025 11:32:05 +0900

개요

Milvus는 컴퓨팅 노드에 대한 스토리지 및 컴퓨팅 분리와 수평적 확장성을 특징으로 하는 공유 스토리지 아키텍처를 채택합니다. Data Plane과 Control plane 분리 원칙에 따라 Milvus는 access layer, coordinator service, worker node, storage의 네 가지 계층으로 구성됩니다. 이러한 계층은 확장 또는 재해 복구와 관련하여 상호 독립적입니다.

figure에 따라서 인터페이스는 다음과 같은 카테고리로 분류할 수 있습니다.

DDL / DCL: createCollection / createPartition / dropCollection / dropPartition / hasCollection / hasPartition
DML / Produce: insert / delete / upsert
DQL: search / query

Access Layer

Stateless Proxy의 그룹으로 구성된 access layer는 시스템의 최전방 계층이자 사용자 엔드포인트입니다. 클라이언트 요청의 유효성을 검사하고 반환되는 결과를 줄입니다. 프록시는 그 자체로 상태 비저장(Stateless)입니다. Nginx, Kubernetes Ingress, NodePort, LVS와 같은 부하 분산 구성 요소를 사용하여 통합 서비스 주소를 제공합니다. Milvus는 대규모 병렬 처리(MPP) 아키텍처를 사용하므로 프록시는 최종 결과를 클라이언트로 반환하기 전에 중간 결과를 집계하고 사후 처리합니다.

Coordinator service

Coordinator Service는 Worker nodes에 작업을 할당하고 시스템의 핵심 역할을 합니다. Coordinator Service가 수행하는 작업에는 클러스터 토폴로지 관리, 로드 밸런싱, 타임스탬프 생성, 데이터 선언 및 데이터 관리가 포함됩니다.

코디네이터 유형에는 루트 코디네이터(루트 좌표), 데이터 코디네이터(데이터 좌표), 쿼리 코디네이터(쿼리 좌표)의 세 가지가 있습니다.

Root coordinator (root coord)

Root coordinator는 컬렉션, 파티션 또는 인덱스를 생성하거나 삭제하는 것과 같은 DDL 및 DCL 요청을 처리하고 TSO(타임스탬프 Oracle) 및 타임 티커 발급을 관리합니다.

Query coordinator (query coord)

Query coordinator는 쿼리 노드의 토폴로지와 부하 분산을 관리하고, growing 세그먼트에서 sealed 세그먼트로 핸드오프를 처리합니다.

Data coordinator (data coord)

Data coordinator는 데이터 노드와 인덱스 노드의 토폴로지를 관리하고, 메타데이터를 유지 관리하며, flush, compact, 인덱스 구축 및 기타 백그라운드 데이터 작업을 트리거합니다.

Worker nodes

Worker nodes는 Coordinator service의 지시를 따르고 프록시에서 DML 명령을 실행하는 단순 실행자입니다. Worker nodes는 스토리지와 컴퓨팅이 분리되어 있어 상태 비저장(stateless)이 가능하며, 쿠버네티스에 배포하면 시스템 확장 및 재해 복구를 용이하게 할 수 있습니다. 워커 노드에는 세 가지 유형이 있습니다.

Query node

Query node는 증분 로그 데이터를 검색하고 로그 브로커를 구독하여 이를 growing 세그먼트로 전환하고, Object Storage에서 과거 데이터를 로드하고, 벡터와 스칼라 데이터 간에 하이브리드 검색을 실행합니다.

Data node

Data node는 로그 브로커를 구독하여 증분 로그 데이터를 검색하고, 변형 요청을 처리하고, 로그 데이터를 로그 스냅샷으로 패킹하여 Object Storage에 저장합니다.

Index node

Index node는 인덱스를 생성합니다. 인덱스 노드는 메모리에 상주할 필요가 없으며, 서버리스 프레임워크를 사용하여 구현할 수 있습니다.

Storage

스토리지는 시스템의 핵심으로, 데이터 지속성을 담당합니다. 메타 스토리지, 로그 브로커, 객체 스토리지로 구성됩니다.

Meta storage

Meta storage는 컬렉션 스키마, 메시지 소비 체크포인트와 같은 메타데이터의 스냅샷을 저장합니다. 메타데이터 저장에는 매우 높은 가용성, 강력한 일관성, 그리고 트랜잭션 지원이 요구되므로 Milvus는 메타 저장소로 etcd를 선택했습니다. Milvus는 서비스 등록 및 상태 점검에도 etcd를 사용합니다.

Object storage

Object storage는 로그의 스냅샷 파일, 스칼라 및 벡터 데이터의 인덱스 파일, 중간 쿼리 결과를 저장합니다. Milvus는 MinIO를 Object storage로 사용 합니다. 하지만 객체 스토리지는 액세스 지연 시간이 길고 쿼리 수에 따라 요금이 부과되기 때문에 Milvus는 성능 향상 및 비용 절감을 위해 메모리 또는 SSD 기반 캐시 풀에 콜드-핫 데이터 분리를 구현할 계획입니다.

Log broker

Log broker는 playback을 지원하는 Pub-Sub 시스템입니다. 또한 Worker nodes가 시스템 장애에서 복구될 때 증분 데이터의 무결성을 보장합니다. Milvus 클러스터는 Pulsar를 로그 브로커로 사용하고, Milvus 단독형은 RocksDB를 Log broker로 사용합니다. 또한, Log broker는 Kafka와 같은 스트리밍 데이터 스토리지 플랫폼으로 쉽게 대체될 수 있습니다.

Milvus는 Log broker를 중심으로 구축되었으며 "log as data" 원칙을 따릅니다. 즉, Milvus는 물리적 테이블을 유지하지 않고 로깅 지속성 및 스냅샷 로그를 통해 데이터 안정성을 보장합니다.

Log broker는 Milvus의 핵심입니다. 고유한 Pub-Sub 메커니즘을 통해 데이터 지속성과 읽기-쓰기 분리를 담당합니다. 위의 그림은 메커니즘을 단순화하여 나타낸 것으로, 시스템은 로그 시퀀스를 유지 관리하는 Log broker와 Log subscriber의 두 가지 역할로 나뉩니다. 전자는 컬렉션 상태를 변경하는 모든 작업을 기록하고, 후자는 로그 시퀀스를 구독하여 로컬 데이터를 업데이트하고 읽기 전용 복사본 형태로 서비스를 제공합니다. Pub-Sub 메커니즘은 변경 데이터 캡처(CDC) 및 글로벌 분산 배포 측면에서 시스템 확장성을 위한 여지도 제공합니다.

Data Processing

Data Insertion

Milvus에서는 각 컬렉션에 대해 여러 개의 샤드를 지정할 수 있으며, 각 샤드는 가상 채널(vchannel)에 해당합니다. 다음 그림에서 볼 수 있듯이 Milvus는 로그 브로커의 각 vchannel에 물리적 채널(pchannel)을 할당합니다. 들어오는 모든 삽입/삭제 요청은 기본 키의 해시 값을 기반으로 샤드로 라우팅됩니다.

Milvus에는 복잡한 transaction이 없기 때문에 DML 요청의 검증은 프록시로 진행됩니다. 프록시는 루트 코디네이터와 함께 배치되는 타이밍 모듈인 TSO(타임스탬프 오라클)에서 각 삽입/삭제 요청에 대한 타임스탬프를 요청합니다. 이전 타임스탬프가 새 타임스탬프로 덮어쓰여지면서 타임스탬프는 처리되는 데이터 요청의 순서를 결정하는 데 사용됩니다. 프록시는 Data coord에서 일괄적으로 entity 세그먼트와 primary key를 포함한 정보를 검색하여 전반적인 처리량을 높이고 중앙 노드에 과도한 부담을 주지 않습니다.

DML(데이터 조작 언어) 작업과 DDL(데이터 정의 언어) 작업 모두 로그 시퀀스에 기록되지만, DDL 작업은 발생 빈도가 낮기 때문에 하나의 채널만 할당됩니다.

vchannel은 기본 로그 브로커 노드에서 유지됩니다. 각 채널은 물리적으로 나눌 수 없으며, 어떤 노드에서든 접근 가능하지만 동시에 오직 하나의 노드에서만 사용할 수 있습니다. 데이터 ingestion 속도가 병목에 도달하면 두 가지 사항을 고려하세요. 로그 브로커 노드가 과부하되어 확장이 필요한지 여부와 각 노드의 부하 균형을 보장할 만큼 충분한 샤드가 있는지 여부입니다.

위의 다이어그램은 로그 시퀀스를 작성하는 프로세스에 관련된 네 가지 구성 요소, 즉 프록시, 로그 브로커, 데이터 노드, 개체 스토리지를 요약한 것입니다. 이 프로세스에는 DML 요청 검증, 로그 시퀀스의 Pub-Sub, 스트리밍 로그에서 로그 스냅샷으로의 변환, 로그 스냅샷의 persistence의 4가지 작업이 포함됩니다. 4가지 작업은 서로 분리되어 각 작업이 해당 노드 유형에서 처리되도록 합니다. 동일한 유형의 노드는 동일하게 만들어지고 다양한 데이터 부하, 특히 대규모이고 변동성이 큰 스트리밍 데이터를 수용하기 위해 탄력적이고 독립적으로 확장될 수 있습니다.

Index building

인덱스 구축은 인덱스 노드를 통해 수행됩니다. 데이터 업데이트를 위한 빈번한 인덱스 구축을 피하기 위해 Milvus에서는 컬렉션을 세그먼트로 세분화하고 각 세그먼트에 고유한 인덱스를 부여합니다.

Milvus는 각 벡터 필드, 스칼라 필드, 그리고 프라이머리 필드에 대해 인덱스를 생성하는 것을 지원합니다. 인덱스를 생성하는 과정에서 입력과 출력 모두 오브젝트 스토리지를 사용합니다: 인덱스 노드는 세그먼트(오브젝트 스토리지에 있음)로부터 인덱싱할 로그 스냅샷을 메모리로 로드하고, 관련된 데이터와 메타데이터를 역직렬화하여 인덱스를 생성한 후, 인덱스 생성이 완료되면 이를 직렬화하여 다시 오브젝트 스토리지에 저장합니다.

인덱스 구축은 주로 벡터 및 행렬 연산을 포함하므로 연산량과 메모리 사용량이 많은 작업입니다. 벡터는 고차원 특성 때문에 전통적인 트리 기반 인덱스로는 효율적으로 인덱싱할 수 없지만, 클러스터 기반 또는 그래프 기반 인덱스와 같은 이 분야에서 보다 성숙한 기술을 통해 인덱싱할 수 있습니다. 인덱스의 유형과 관계없이, 인덱스 구축은 K-means나 그래프 탐색과 같은 대규모 벡터에 대한 반복적인 계산을 대량으로 수행해야 합니다.

스칼라 데이터의 인덱싱과는 달리, 벡터 인덱스를 구축할 때는 SIMD(single instruction, multiple data) 가속을 최대한 활용해야 합니다. Milvus는 SSE, AVX2, AVX512와 같은 SIMD 명령어 세트를 기본적으로 지원합니다. 벡터 인덱스 구축은 "중단(hiccup)" 현상과 자원 집약적인 특성을 가지기 때문에, Milvus에서는 경제적인 관점에서 탄력성(elasticity)이 매우 중요합니다. 향후 Milvus 릴리스에서는 관련 비용을 줄이기 위해 이기종 컴퓨팅(heterogeneous computing) 및 서버리스 컴퓨팅(serverless computation)에 대한 탐구가 계속될 예정입니다.

또한 Milvus는 스칼라 필터링(scalar filtering)과 기본 필드(primary field) 질의도 지원합니다. Milvus에는 Bloom 필터 인덱스, 해시 인덱스, 트리 기반 인덱스, 역색인(inverted index) 등 쿼리 효율을 향상시키기 위한 내장 인덱스가 있으며, 향후에는 비트맵 인덱스(bitmap indexes)나 러프 인덱스(rough indexes)와 같은 외부 인덱스도 도입할 계획입니다.

Data query

데이터 쿼리란, 지정된 컬렉션에서 대상 벡터와 가장 가까운 k개의 벡터를 검색하거나, 대상 벡터로부터 지정된 거리 범위 내에 있는 모든 벡터를 검색하는 과정을 말합니다. 벡터는 해당하는 기본 키(primary key) 및 필드 정보와 함께 반환됩니다.

Milvus에서 하나의 컬렉션은 여러 개의 세그먼트(segment)로 분할되며, 쿼리 노드(query node)는 세그먼트 단위로 인덱스를 로드합니다. 검색 요청이 도착하면, 해당 요청은 모든 쿼리 노드에 브로드캐스트되어 병렬 검색이 수행됩니다. 각 노드는 로컬 세그먼트를 필터링하고, 조건에 부합하는 벡터를 검색한 후, 결과를 취합하여 반환합니다.

데이터 쿼리 과정에서 쿼리 노드들은 서로 독립적으로 작동합니다. 각 노드는 오직 두 가지 작업만 담당합니다: 쿼리 코디네이터(query coord)의 명령에 따라 세그먼트를 로드하거나 해제하는 일, 그리고 로컬 세그먼트 내에서 검색을 수행하는 일입니다. 프록시(proxy)는 각 쿼리 노드로부터 반환된 검색 결과를 취합하여 최종 결과를 클라이언트에게 전달합니다.

세그먼트는 두 가지 유형이 있습니다: 증분 데이터(incremental data)를 위한 growing 세그먼트와, 이력을 보존하는 sealed 세그먼트입니다. 쿼리 노드는 vchannel을 구독하여 최근 업데이트된 증분 데이터를 growing 세그먼트로 수신합니다. growing 세그먼트가 사전 정의된 임계값에 도달하면, data coord가 이를 sealed 상태로 전환하고 인덱스 구축이 시작됩니다. 이후, query coord가 주도하는 handoff 작업을 통해 증분 데이터가 이력 데이터로 전환됩니다. query coord는 메모리 사용량, CPU 부하, 세그먼트 수 등을 기준으로 sealed 세그먼트를 모든 쿼리 노드에 균등하게 분산시킵니다.

Cursor에서 MCP (Model Context Protocol) 사용하기

pfldy2850 — Thu, 3 Apr 2025 01:17:06 +0900

Cursor는 개발자들이 생산적으로 코드를 작성하고 협업할 수 있도록 돕는 강력한 AI 기반 코드 편집기입니다. 최근 Cursor가 MCP(Model Context Protocol)를 지원하면서, 사용자는 더욱 향상된 코드 작성 환경을 경험할 수 있게 되었습니다. 이번 글에서는 Cursor에서 MCP를 어떻게 설정하고 활용하는지 살펴보겠습니다.

MCP와 관련된 내용은 지난 블로그 글에서 다루었으니, 참고하시기 바랍니다!

MCP(Model Context Protocol)이 뭐길래?

인공지능(AI) 기술의 발전과 함께, AI 시스템이 외부 데이터와 효과적으로 연동되는 것이 점점 더 중요한 이슈로 떠오르고 있습니다. 기존에는 AI 모델이 내부적으로 훈련된 데이터만을 기반으로

dytis.tistory.com

MCP(Model Context Protocol)이 뭐길래? 실습편

지난 포스트에서는 MCP(Model Context Protocol)이 무엇인지, 그리고 MCP가 최근 화제가 되는 이유에 대해서 다뤘습니다.해당 내용에 대해서 관심 있으신 분들은 지난 포스트 글을 참고해주시기 바랍니

dytis.tistory.com

Cursor에서 MCP 설정하기

MCP를 사용하면 Cursor를 외부 시스템 및 데이터 소스에 연결할 수 있습니다. 즉, Cursor에게 여러분들의 프로젝트에서 코드 외의 프로젝트 구조를 알려줄 필요 없이 기존 도구 및 인프라와 통합할 수 있습니다.

MCP Server 설정

Claude Desktop과 마찬가지로 Cursor도 mcpServers에 대한 configuration을 작성합니다. 이에 대한 인터페이스는 MCP에 의해 규격화되어서 모든 호스트 어플리케이션에서 동일한 내용으로 사용할 수 있습니다. 실행할 수 있는 MCP 서버도 Node.js나 python 스크립트를 실행하거나, SSE 서버에 연동하는 등의 다양한 기능을 제공합니다.

CLI Server - Node.js

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

CLI Server - Python

{
  "mcpServers": {
    "server-name": {
      "command": "python",
      "args": ["mcp-server.py"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

SSE Server

{
  "mcpServers": {
    "server-name": {
      "url": "http://localhost:3000/sse",
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Cursor에서는 이러한 설정파일을 프로젝트별 / 전역의 두가지로 설정할 수 있도록 제공합니다. 프로젝트별 configuration은 프로젝트 폴더 내의 .cursor/mcp.json에 작성할 수 있습니다. 전역 설정은 \~/.cursor/mcp.json 파일에 작성합니다.

실습: MCP 서버 적용하기

Naver OpenAPI

지난 실습에 이어서 Cursor에도 Naver OpenAPI MCP를 적용해보겠습니다.

https://github.com/pfldy2850/py-mcp-naver

GitHub - pfldy2850/py-mcp-naver: python MCP NAVER

python MCP NAVER. Contribute to pfldy2850/py-mcp-naver development by creating an account on GitHub.

github.com

API 발급을 위한 사전작업은 지난 블로그글을 참고해주세요.

MCP(Model Context Protocol)이 뭐길래? 실습편

dytis.tistory.com

시작하기에 앞서, Cursor에 들어가 Cursor Settings를 열어봅니다.

현재는 MCP Servers에 아무것도 등록이 되지 않은 것을 확인할 수 있습니다.

설치

해당 프로젝트에 작업이 많이 되어, PyPi로 쉽게 설치하여 사용할 수 있게 되었습니다. 먼저 mcp-naver를 설치합니다.

uv pip install mcp-naver

패키지가 정상적으로 설치되었다면, mcp-naver 에서 제공하는 스크립트를 활용하여 cursor에 해당 mcp 서버를 등록합니다.

uv run python -m mcp-naver.hosts.claude_desktop \
  -e NAVER_CLIENT_ID=<YOUR NAVER CLIENT ID> \
  -e NAVER_CLIENT_SECRET=<YOUR NAVER CLIENT SECRET>

정상적으로 설치되었다면, 아래처럼 Cursor Settings에 Naver OpenAPI MCP 서버가 등록된 것을 확인할 수 있습니다.

MCP Server에서 개별 MCP 서버에서 사용할 수 있는 Tools나 서버를 실행하기 위한 command를 확인할 수 있습니다. 우측 상단에서는 해당 MCP 서버를 사용하지 않도록 설정할 수 있고, 내용을 편집 할 수 있습니다.

\~/.cursor/mcp.json 파일을 들어가보면, 위에서 소개해드린 mcpServers에 Naver OpenAPI라는 MCP 서버가 설정된 것을 확인할 수 있습니다.

실행하기

그럼 이제 Agent를 통해서 MCP를 실행해보겠습니다. 간단하게 오늘 날씨가 어떤지 물어보겠습니다.

Agent는 스크린샷처럼 오늘 날씨 어때? 라는 질문에 맞는 MCP 서버를 탐색하고, 직접 입력을 생성하여 전달하기 위한 준비를 합니다. Cursor에서는 command + enter를 눌러 Tool을 실행하도록 할 수 있습니다.

이번 질문에서는 Agent 스스로 네이버 블로그와 네이버 뉴스에 오늘 날씨와 관련된 내용을 검색해서 정보를 찾아왔습니다.

찾은 정보를 토대로 질문에 맞는 답변을 잘 생성한 것을 확인할 수 있습니다.

Yolo Mode

Yolo 모드를 활성화하면 Agent가 승인 없이도 MCP 도구를 자동으로 실행할 수 있습니다.

공식 문서에서는 Yolo Mode라고 되어 있는데, 제 Cursor 앱에서는 Enable auto-run mode로 설정되어 있습니다. 도구 호출에 대한 승인 없이 자동으로 호출하게 하려면 해당 설정을 On 하면 됩니다. 설정을 활성화하고 실행하면 아래처럼 도구가 바로 수행됩니다.

Cursor MCP의 한계

Tool Quantity

일부 MCP 서버 또는 여러 MCP 서버를 활성화한 사용자는 Cursor가 사용할 수 있는 도구가 많을 수 있습니다. 현재는 Cursor가 첫 40개의 도구 목록만 Agent에 전달합니다.

Remote Development

Cursor는 stdio를 통해 직접 또는 sse를 사용한 네트워크를 통해 로컬 머신에서 MCP 서버와 직접 통신합니다. 따라서 MCP 서버는 SSH 또는 다른 개발 환경을 통해 Cursor에 액세스할 때 제대로 작동하지 않을 수 있습니다.

MCP Resources

MCP 서버는 도구와 리소스라는 두 가지 주요 기능을 제공합니다. Tools는 현재 Cursor에서 사용할 수 있지만 Cursor에서는 아직 Resources가 지원되지 않습니다. 향후 릴리스에서 리소스 지원을 추가하기를 바라고 있습니다.

맺음 말

이번 글에서는 인기있는 AI 기반 코드 편집기인 Cursor에 MCP 서버를 설치하여 사용하는 법에 대해서 정리하였습니다.

MCP 자체가 규격을 말하는 것이기 때문에 mcpServers와 같은 공통 설정에 대한 약속이 있어서, Claude Desktop이나 Cursor와 같은 여러 호스트 어플리케이션에 MCP를 손쉽게 적용해볼 수 있는 것이 개인적으로 굉장히 좋았습니다.

최근 MCP에 대한 관심과 함께 관련 생태계가 점점 커지고 있습니다. 뿐만 아니라 PulseMCP 등의 여러 MCP를 탐색하여 활용하고자 하는 관심사도 많아지고 있는 것 같습니다. 앞으로 더 다양한 MCP 서버들이 개발되어 보다 풍부하고 강력한 에이전트 경험을 할 수 있는 시대가 오기를 기대합니다.

MCP(Model Context Protocol)이 뭐길래? 실습편

pfldy2850 — Fri, 21 Mar 2025 00:22:14 +0900

지난 포스트에서는 MCP(Model Context Protocol)이 무엇인지, 그리고 MCP가 최근 화제가 되는 이유에 대해서 다뤘습니다.

해당 내용에 대해서 관심 있으신 분들은 지난 포스트 글을 참고해주시기 바랍니다.

MCP(Model Context Protocol)이 뭐길래?

dytis.tistory.com

이번 포스트에서는 그럼 MCP는 어떻게 활용할 수 있는건데?를 위하여, 간단한 실습을 하고자 합니다.

Claude desktop에 Naver 검색 능력 입히기를 주제로 실습해보겠습니다.

Claude desktop 설치

Claude 데스크톱은 Claude AI 챗봇의 기능을 사용자의 컴퓨터로 직접 제공하는 Windows 및 macOS 전용 애플리케이션으로, 워크플로와의 원활한 통합과 보다 빠르고 집중적인 상호작용을 가능하게 해줍니다. (아직은 베타로 제공중입니다.)

Claude 데스크톱은 아래 링크에서 다운받을 수 있습니다.

https://claude.ai/download

Download Claude

Download Claude for your desktop or mobile device.

claude.ai

앱을 다운받은 후, 구글 계정 또는 본인의 계정을 사용해서 로그인을 하면, 아래처럼 Chat 인터페이스를 기본으로 하는 간단한 claude app을 확인할 수 있습니다.

먼저, 여기서 기본적인 claude app의 성능을 테스트해보기 위하여, Naver OpenAPI를 사용해서 영등포구청 맛집을 찾아줘라는 질문을 던져보면 다음과 같은 답변을 합니다.

죄송합니다만, 저는 Naver OpenAPI에 직접 접근하거나 실시간으로 맛집 정보를 검색할 수 있는 기능이 없습니다. 제 지식은 2024년 10월까지의 정보로 제한되어 있으며, 현재 외부 API나 인터넷에 연결할 수 없습니다.

영등포구청 주변 맛집을 찾으시려면 다음과 같은 방법을 이용해보시길 권장드립니다:

1. 네이버 지도 앱이나 웹사이트에서 직접 "영등포구청 맛집" 검색
2. 카카오맵, 구글맵 등의 지도 서비스 이용
3. 망고플레이트, 다이닝코드와 같은 맛집 추천 앱 사용
4. 네이버 블로그나 카페에서 최근 영등포구청 맛집 리뷰 검색

혹시 Naver OpenAPI를 직접 활용하는 방법에 대해 알고 싶으시다면, 제가 API 연동 방법이나 코드 예시를 안내해드릴 수 있습니다. 원하시는 정보가 있으면 말씀해주세요.

그러면 여기서 이제 우리의 claude app에게 Naver 검색 기능을 주입해봅니다.

Develop MCP Server (FastMCP)

지난 포스트에서도 공유드렸듯이 python에서는 fastmcp라는 라이브러리를 통해서 MCP Server를 쉽게 구축할 수 있습니다.

https://github.com/jlowin/fastmcp

GitHub - jlowin/fastmcp: The fast, Pythonic way to build Model Context Protocol servers

The fast, Pythonic way to build Model Context Protocol servers - GitHub - jlowin/fastmcp: The fast, Pythonic way to build Model Context Protocol servers

github.com

아래와 같이 FastMCP 서버를 초기화하고, 그 다음에는 필요한 엔티티에 데코레이터를 달아주는 방식으로 구현되어 있습니다.

# demo.py

from fastmcp import FastMCP


mcp = FastMCP("Demo  ")

특히, 구현상에서의 MCP는 3가지의 주요한 구성요소가 있습니다:

리소스 (Resource)

리소스는 AI 모델에게 필요한 정보와 컨텍스트를 제공합니다. REST API의 GET 엔드포인트와 유사합니다. 데이터를 제공하지만 상당한 계산을 수행하거나 부작용이 있어서는 안 됩니다.

ex) File contents, Database schemas, API responses, System information

@mcp.resource("config://app")
def get_config() -> str:
    """Static configuration data"""
    return "App configuration here"

동적으로 인자 전달:

@mcp.resource("users://{user_id}/profile")
def get_user_profile(user_id: str) -> str:
    """Dynamic user data"""
    return f"Profile data for user {user_id}"

도구 (Tool)

도구는 AI 모델이 외부 시스템에서 작업을 수행할 수 있게 합니다. 리소스와 달리 도구는 계산을 수행하고 side effect가 있을 것으로 예상됩니다. REST API의 POST 엔드포인트와 유사합니다.

@mcp.tool()
def calculate_bmi(weight_kg: float, height_m: float) -> float:
    """Calculate BMI given weight in kg and height in meters"""
    return weight_kg / (height_m ** 2)

http 요청 예시)

import httpx

@mcp.tool()
async def fetch_weather(city: str) -> str:
    """Fetch current weather for a city"""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.weather.com/{city}"
        )
        return response.text

복잡한 입력 처리 예시)

from pydantic import BaseModel, Field
from typing import Annotated

class ShrimpTank(BaseModel):
    class Shrimp(BaseModel):
        name: Annotated[str, Field(max_length=10)]

    shrimp: list[Shrimp]

@mcp.tool()
def name_shrimp(
    tank: ShrimpTank,
    # You can use pydantic Field in function signatures for validation.
    extra_names: Annotated[list[str], Field(max_length=10)],
) -> list[str]:
    """List all shrimp names in the tank"""
    return [shrimp.name for shrimp in tank.shrimp] + extra_names

프롬프트 (Prompt)

프롬프트는 AI 모델이 리소스와 도구를 활용하여 일관되고 유용한 응답을 생성하도록 안내합니다. 프롬프트는 재사용 가능한 템플릿이며, 이는 서버에 인코딩된 "모범 사례"와 같습니다. 프롬프트는 문자열만큼 간단할 수 있습니다.

@mcp.prompt()
def review_code(code: str) -> str:
    return f"Please review this code:\n\n{code}"

from fastmcp.prompts.base import UserMessage, AssistantMessage

@mcp.prompt()
def debug_error(error: str) -> list[Message]:
    return [
        UserMessage("I'm seeing this error:"),
        UserMessage(error),
        AssistantMessage("I'll help debug that. What have you tried so far?")
    ]

FastMCP에서는 이미지나 Context에 대한 처리도 가능합니다.

Image

from fastmcp import FastMCP, Image
from PIL import Image as PILImage

@mcp.tool()
def create_thumbnail(image_path: str) -> Image:
    """Create a thumbnail from an image"""
    img = PILImage.open(image_path)
    img.thumbnail((100, 100))
    
    # FastMCP automatically handles conversion and MIME types
    return Image(data=img.tobytes(), format="png")

@mcp.tool()
def load_image(path: str) -> Image:
    """Load an image from disk"""
    # FastMCP handles reading and format detection
    return Image(path=path)

Context

Context 객체는 도구와 리소스에 MCP 기능에 대한 액세스를 제공합니다. 이를 사용하려면 fastmcp.Context로 주석이 달린 매개변수를 추가합니다.

from fastmcp import FastMCP, Context

@mcp.tool()
async def long_task(files: list[str], ctx: Context) -> str:
    """Process multiple files with progress tracking"""
    for i, file in enumerate(files):
        ctx.info(f"Processing {file}")
        await ctx.report_progress(i, len(files))
        
        # Read another resource if needed
        data = await ctx.read_resource(f"file://{file}")
        
    return "Processing complete"

SQLite Explorer 예시

from fastmcp import FastMCP
import sqlite3

mcp = FastMCP("SQLite Explorer")

@mcp.resource("schema://main")
def get_schema() -> str:
    """Provide the database schema as a resource"""
    conn = sqlite3.connect("database.db")
    schema = conn.execute(
        "SELECT sql FROM sqlite_master WHERE type='table'"
    ).fetchall()
    return "\n".join(sql[0] for sql in schema if sql[0])

@mcp.tool()
def query_data(sql: str) -> str:
    """Execute SQL queries safely"""
    conn = sqlite3.connect("database.db")
    try:
        result = conn.execute(sql).fetchall()
        return "\n".join(str(row) for row in result)
    except Exception as e:
        return f"Error: {str(e)}"

@mcp.prompt()
def analyze_table(table: str) -> str:
    """Create a prompt template for analyzing tables"""
    return f"""Please analyze this database table:
Table: {table}
Schema: 
{get_schema()}

What insights can you provide about the structure and relationships?"""

날씨 도구 예시

from mcp.server.fastmcp import FastMCP

# MCP 서버 초기화
mcp = FastMCP("weather-service")

@mcp.resource()
async def get_locations(self) -> list:
    """사용자가 자주 검색하는 위치 목록을 반환합니다"""
    return ["Seoul", "New York", "London", "Tokyo"]

@mcp.tool()
async def get_weather(self, location: str) -> dict:
    """특정 위치의 날씨 정보를 가져옵니다"""
    api_key = "your_api_key"
    url = f"https://api.weather.com/v1/location/{location}?apiKey={api_key}"
    async with httpx.AsyncClient()  as client:
        response = await client.get(url)
        return response.json()

@mcp.tool()
async def save_favorite_location(self, location: str) -> bool:
    """사용자의 즐겨찾는 위치를 저장합니다"""
    # 데이터베이스에 저장하는 로직
    return True

@mcp.prompt("weather_forecast")
def weather_forecast_prompt(location: str, forecast: dict) -> str:
    return f"""
    {location}의 날씨 예보:
    
    현재 온도: {forecast['current']['temperature']}°C
    날씨 상태: {forecast['current']['condition']}
    
    오늘의 예상 최고/최저 기온: {forecast['today']['high']}°C / {forecast['today']['low']}°C
    
    내일 예보: {forecast['tomorrow']['condition']}, {forecast['tomorrow']['high']}°C / {forecast['tomorrow']['low']}°C
    """

# MCP 서버 실행 - 지속적인 연결 유지
if __name__ == "__main__":
    mcp.run(transport='stdio')

Naver OpenAPI MCP

Naver OpenAPI

다시 본론으로 돌아와서, Naver에서는 자사의 다양한 검색 서비스를 OpenAPI로 제공하고 있습니다.

https://developers.naver.com/docs/common/openapiguide/README.md

API 공통 가이드 - Open API 가이드

API 공통 가이드 네이버 오픈API는 네이버 플랫폼의 기능을 외부 개발자가 쉽게 이용할 수 있게 웹 또는 SDK 형태로 공개한 기술들입니다. 네이버 오픈API로 활용할 수 있는 기술에는 네이버 로그인

developers.naver.com

네이버가 엄청 다양한 서비스를 제공하고 있는 큰 회사이다보니, OpenAPI를 제공해주는 목록도 굉장히 많습니다.

그 중에서 검색 서비스의 경우 하루 25,000회의 호출 제한이 있지만 네이버의 다양한 검색 서비스를 무료로 사용해볼 수 있습니다.

실행 준비

이러한 네이버의 OpenAPI를 MCP Server로 구현해둔 작업물이 있어, 이것을 활용해볼 예정입니다.

https://github.com/pfldy2850/py-mcp-naver

GitHub - pfldy2850/py-mcp-naver: python MCP NAVER

python MCP NAVER. Contribute to pfldy2850/py-mcp-naver development by creating an account on GitHub.

github.com

(맞습니다. 제가 만들었습니다..)

이 MCP 서버는 네이버에서 제공하는 검색 관련 OpenAPI들을 모두 사용할 수 있도록 래핑해둔 서버입니다.

먼저, 위 API를 사용하기 위해서 아래 링크에 들어가 api 사용 신청을 해야 합니다.

https://developers.naver.com/apps/#/register=datalab

애플리케이션 - NAVER Developers

developers.naver.com

신청이 완료되었으면, client id와 client secret을 확인할 수 있고, 이는 추후 mcp server 등록시 넣어주기 위해 환경변수로 작성합니다

export NAVER_CLIENT_ID=<YOUR NAVER CLIENT ID>
export NAVER_CLIENT_SECRET=<YOUR NAVER CLIENT SECRET>

이렇게 준비가 완료되었으면 위의 레포의 내용대로 설치합니다.

uv pip install mcp-naver

uv run python -m mcp-naver.hosts.claude_desktop \
  -e NAVER_CLIENT_ID=$NAVER_CLIENT_ID \
  -e NAVER_CLIENT_SECRET=$NAVER_CLIENT_SECRET

위의 명령어들을 다 실행했으면, 적용을 위해서 claude app을 종료하고 재시작합니다.

익숙한 Chat 인터페이스의 오른쪽 아래에 망치 아이콘과 함께 MCP tools를 14개 사용할 수 있다고 표시가 되어 있습니다.

이를 클릭해서 보면, Naver OpenAPI MCP 서버에서 제공하는 도구 목록이 보이는 것을 확인할 수 있습니다.

적용된 mcpServers에 대한 설정파일은 macOS는 ~/Library/Application Support/Claude/claude_desktop_config.json 경로에 있고, Windows는 %APPDATA%\Claude\claude_desktop_config.json 경로에 있으니 직접 파일을 수정할 수도 있습니다.

적용 결과

그러면 아까와 같이 Naver OpenAPI를 활용해서 영등포구청역 맛집을 검색해줘 라고 물어보겠습니다.

claude app은 필요한 내용을 찾기 위해 Naver OpenAPI의 search_local (지역 검색) tool을 활용하여, 영등포구청역 맛집 이라는 검색어를 생성해 검색합니다.

{
  `query`: `영등포구청역 맛집`,
  `display`: 10
}
{
	"lastBuildDate":"Thu, 20 Mar 2025 22:29:01 +0900",
	"total":5,
	"start":1,
	"display":5,
	"items":[
		{
			"title":"민똣",
			"link":"https:\/\/www.instagram.com\/mintot_official",
			"category":"음식점>베트남음식",
			"description":"",
			"telephone":"",
			"address":"서울특별시 영등포구 당산동1가 55 1층",
			"roadAddress":"서울특별시 영등포구 당산로10길 28-1 1층",
			"mapx":"1268989296",
			"mapy":"375213933"
		},
		{
			"title":"당산오돌 본점",
			"link":"https:\/\/blog.naver.com\/skill8114",
			"category":"한식>육류,고기요리",
			"description":"",
			"telephone":"",
            ...
 }

그러고 나서, 더 많은 맛집 정보를 찾아보겠다는 말과 함께 search_blog(블로그 검색)에 영등포구청역 맛집 추천 이라는 쿼리를 직접 생성하여 검색합니다.

{
  `query`: `영등포구청역 맛집 추천`,
  `display`: 5
}
{
	"lastBuildDate":"Thu, 20 Mar 2025 22:29:06 +0900",
	"total":4805,
	"start":1,
	"display":5,
	"items":[
		{
			"title":"[<b>맛집<\/b>] <b>영등포구청역 맛집<\/b> | 무제한 샤브샤브 <b>맛집 추천<\/b>... ",
			"link":"https:\/\/blog.naver.com\/hayoungju98\/223795238282",
			"description":"❗️영업 시간 매일 11:00 ~ 21:00 주말에만 브레이크 타임 15:00 ~ 17:00 외관 <b>영등포구청역 맛집<\/b> 샤브올데이 당산점의 외관. 생각보다 가게가 꽤 커서 놀랐다. 그리고 더 놀란건 가게 앞 웨이팅 ㅠㅋㅋㅋ 예약도... ",
			"bloggername":"Zero Blog",
			"bloggerlink":"blog.naver.com\/hayoungju98",
			"postdate":"20250313"
		},
		{
			"title":"<b>영등포구청역 맛집 추천<\/b> 고기집 동래정",
			"link":"https:\/\/blog.naver.com\/wj2796\/223530123811",
			"description":"내부 및 인테리어 영등포구청역 맛집 매장으로 들어서면 이렇습니다. 아담하면서 깔끔한 분위기가... 걸 추천드린다니 기대가 된답니다. 3. 메뉴 <b>영등포구청역맛집 추천<\/b> 동래정은 하이볼도 있는데요. 오후 3시... ",

그런 다음, 위의 검색 내용을 토대로 영등포구청역 주변 맛집 리스트를 다시 재생성하여 답변을 생성합니다.

영등포구청역 맛집에 대한 정보를 찾아드리겠습니다. Naver OpenAPI를 통해 검색해보겠습니다.

더 많은 맛집 정보를 찾아보겠습니다.

영등포구청역 맛집을 Naver OpenAPI를 통해 검색한 결과, 다음과 같은 추천 맛집들을 찾았습니다:

### 영등포구청역 주변 맛집 리스트

1. **민똣** (베트남음식)
   - 주소: 서울특별시 영등포구 당산로10길 28-1 1층
   - 인스타그램: @mintot_official

2. **당산오돌 본점** (육류, 고기요리)
   - 주소: 서울특별시 영등포구 국회대로37길 6 1층
   - 블로그: blog.naver.com/skill8114

3. **88냉삼 영등포구청직영점** (돼지고기구이)
   - 주소: 서울특별시 영등포구 당산로32길 1-6

4. **연탄불** (육류, 고기요리)
   - 주소: 서울특별시 영등포구 양산로17길 17

5. **팬팬떡볶이** (분식, 떡볶이)
   - 주소: 서울특별시 영등포구 영등포로 143 1층
   - 인스타그램: @panfan1997

### 블로그에서 추천하는 맛집

1. **샤브올데이 당산점** (무제한 샤브샤브)
   - 영업시간: 매일 11:00 ~ 21:00 (주말 브레이크 타임 15:00 ~ 17:00)
   - 가게가 크고 웨이팅이 있는 인기 맛집

2. **동래정** (고기집)
   - 아담하고 깔끔한 분위기의 매장
   - 하이볼 메뉴도 있음

3. **대박곱창구이** (곱창전문점)
   - 오동통한 소곱창이 특징
   - 천엽, 선지 해장국 서비스 제공
   - 메뉴: 마늘/황소/모둠 곱창, 특양/대창/막창 구이 등
   - 모둠곱창 250g 25,000원

4. **미락카츠 본점** (돈카츠 전문점)
   - 영등포구청 인근 카츠 맛집

이 중에서 더 자세한 정보나 특정 음식 종류에 대해 알고 싶으시면 말씀해주세요!

추가

Naver OpenAPI를 사용해달라는 지시어를 제외하더라도, 스스로 MCP를 잘 찾아서 사용합니다.

Q: 영등포구청역 맛집 찾아줘

A:
영등포구청역 주변 맛집을 찾아드리겠습니다.

영등포구청역 주변의 추천 맛집들을 소개해드립니다:

### 지역 맛집 리스트
1. **민똣** - 베트남 음식 전문점
- 주소: 서울특별시 영등포구 당산로10길 28-1 1층
- 인스타그램: mintot_official
2. **당산오돌 본점** - 육류, 고기요리 전문점
- 주소: 서울특별시 영등포구 국회대로37길 6 1층
- 블로그: skill8114
3. **88냉삼 영등포구청직영점** - 돼지고기구이 전문점
- 주소: 서울특별시 영등포구 당산로32길 1-6
4. **연탄불** - 육류, 고기요리 전문점
- 주소: 서울특별시 영등포구 양산로17길 17
5. **팬팬떡볶이** - 떡볶이 전문점
- 주소: 서울특별시 영등포구 영등포로 143 1층
- 인스타그램: panfan1997

### 블로그 추천 맛집
1. **샤브올데이 당산점** - 무제한 샤브샤브 전문점
- 영업 시간: 매일 11:00 ~ 21:00 (주말 브레이크 타임 15:00 ~ 17:00)
- 특징: 가게가 크고 인기가 많아 웨이팅이 있을 수 있음
2. **동래정** - 고기집
- 특징: 아담하고 깔끔한 분위기, 하이볼 메뉴도 있음
3. **대박곱창구이** - 소곱창 전문점
- 특징: 통통한 마늘 소곱창이 유명하며, 천엽/선지 해장국 서비스 제공
- 메뉴: 모둠곱창 250g 25,000원
- 마늘/황소/모둠 곱창, 특양/대창/막창 구이 등 다양한 메뉴 보유
4. **미락카츠 본점** - 카츠 전문점
- 영등포구청 카츠 맛집으로 유명

맛집을 더 자세히 알아보시거나 특정 음식 종류에 대한 추천이 필요하시면 말씀해주세요!

Q: 요즘 생수 가격이 얼마정도 해?

A:
현재 한국의 생수 가격에 대해 알아보겠습니다.
현재 한국의 생수 가격을 검색해 보니 다양한 종류와 용량별로 가격 차이가 있습니다. 주요 생수 가격은 다음과 같습니다:

1. 소용량 생수 (500ml)
- 동원샘물 무라벨 500ml x 20병: 4,500원 (병당 약 225원)
- 삼다수 500ml 무라벨 x 20개: 5,400원 (병당 약 270원)
- 노브랜드 미네랄워터 500ml x 20입: 3,800원 (병당 약 190원)
- 스파클 무라벨 500ml x 80개: 12,890원 (병당 약 161원)
2. 대용량 생수 (2L)
- 동원샘물 무라벨 2L x 6개: 1,500원 (병당 약 250원)
- 삼다수 2L 무라벨 x 6개: 3,500원 (병당 약 583원)
- 스파클 무라벨 2L x 24개: 9,290원 (병당 약 387원)
3. 기타 생수
- 몽베스트 330ml: 8,300원 (구체적인 개수는 명시되지 않음)
- 자연드림 JUST 기픈물 종이팩 1,000ml x 12입: 16,150원~17,950원 (팩당 약 1,350~1,500원)

일반적으로 브랜드, 용량, 구매 수량에 따라 가격이 다양하게 형성되어 있으며, 대형마트나 온라인 플랫폼별로도 가격 차이가 있습니다. 무라벨 제품이 많이 출시되어 있고, 대량 구매 시 병당 가격이 더 저렴한 경향이 있습니다.

결론

이번 포스트에서는 Claude Desktop App을 설치하고, Naver OpenAPI MCP Server를 활용하여 claude app에 naver 검색 능력을 활용할 수 있도록 실습을 진행하였습니다. 그 과정에서 FastMCP를 활용하여 Python MCP Server를 쉽고 간단하게 작성하는 방법에 대해서 간략하게 다뤘습니다.

MCP가 오픈소스로 공개되고 나서, 많은 참여자들이 MCP Server 개발에 참여하여 생태계를 폭발적으로 성장시키고 있는 중입니다. 이러한 상황에서 활용할 수 있는 많은 MCP를 적재적소에 활용해서 개인의 요구사항에 맞는 적절한 LLM agent를 만들기도 쉬워지는 것 같습니다.

물론 MCP는 아직 초기 단계이기 때문에 과장된 기대라는 시각도 있지만, 실질적인 사례가 쌓이고 있다는 점에서 단순한 유행보다는 AI 기술의 다음 단계를 여는 중요한 전환점이 될 가능성이 높아 보입니다. 앞으로 MCP가 AI 생태계에 어떤 변화를 가져올지 지속적으로 주목할 필요가 있을 것 같습니다.

MCP(Model Context Protocol)이 뭐길래?

pfldy2850 — Thu, 20 Mar 2025 23:39:33 +0900

인공지능(AI) 기술의 발전과 함께, AI 시스템이 외부 데이터와 효과적으로 연동되는 것이 점점 더 중요한 이슈로 떠오르고 있습니다. 기존에는 AI 모델이 내부적으로 훈련된 데이터만을 기반으로 작동하는 경우가 많았지만, 실시간 정보 활용과 동적 컨텍스트 유지가 필수적인 환경에서는 이러한 방식이 한계를 보였습니다. 이에 따라, AI 시스템이 외부 데이터와 원활하게 통신하고 정보를 활용할 수 있는 새로운 프로토콜이 필요해졌습니다.

2024년 11월, Anthropic이 Model Context Protocol(MCP)을 오픈 소스로 공개하면서, AI 생태계에서는 새로운 변화의 바람이 불기 시작했습니다. MCP는 AI 모델이 다양한 데이터 소스와 연결되어 실시간으로 정보를 주고받을 수 있도록 설계된 프로토콜로, 이를 활용하면 AI가 더욱 정확하고 풍부한 답변을 제공할 수 있습니다. 이러한 혁신적인 접근 방식은 기업과 개발자들에게 큰 관심을 끌고 있으며, AI의 활용 범위를 넓히는 데 중요한 역할을 하고 있습니다.

구글 검색어 트렌드

2024년 11월, Anthropic이 Model Context Protocol(MCP)을 오픈 소스로 공개하였지만 당시에는 큰 주목을 받지 못했습니다. 그러나 2025년 초부터 MCP에 대한 관심이 급증하고 있는데, 이러한 변화의 주요 요인 중 하나는 AI 에이전트와 에이전틱 워크플로우의 발전에 따라, 실제 비즈니스 시스템과 데이터를 AI 에이전트에 통합하는 필요성이 대두되었기 때문입니다. MCP는 이러한 통합 문제를 해결하는 표준으로서, 파일 시스템, 데이터베이스, API 등 기존 데이터 소스를 AI 워크플로우에 연결하는 방법을 정의하여, 생산 준비가 된 AI 에이전트를 구축하는 데 필수적인 요소로 부상하였습니다.

또한, 커뮤니티의 성장과 채택도 MCP의 인기에 기여했습니다. 몇 달 만에 MCP는 개념에서 성장하는 생태계로 발전하였으며, 주요 AI 기업과 오픈 소스 커뮤니티가 MCP를 채택하고 있습니다. 이러한 채택은 MCP를 기반으로 한 에이전틱 AI 시스템 구축을 촉진하고 있으며, 이는 MCP에 대한 관심 증가의 또 다른 요인입니다.

이러한 맥락에서, Manus AI와 같은 혁신적인 AI 에이전트의 출시는 MCP의 중요성을 더욱 부각시켰습니다. Manus AI는 사용자의 지시에 따라 웹 브라우징, 코드 작성 등 다양한 작업을 수행하는 범용 AI 에이전트로, 기존의 AI 모델인 Claude Sonnet 3.5와 Qwen을 기반으로 설계되었습니다. 이러한 AI 에이전트의 기능은 다양한 도구와의 통합을 통해 강화되며, 이 과정에서 MCP와 같은 프로토콜이 중요한 역할을 합니다. 따라서, Manus AI와 같은 AI 에이전트의 등장은 MCP에 대한 관심 증가에 직접적인 영향을 미쳤습니다.

MCP란 무엇인가

MCP는 "대규모 언어 모델이 외부 데이터와 시스템을 더 효과적으로 활용할 수 있도록 설계된 일종의 연결 프로토콜"입니다. 앤트로픽은 MCP를 USB-C 포트에 비유합니다. USB-C가 다양한 기기와 주변 장치를 표준화된 방식으로 연결하듯이, MCP는 AI 모델이 다양한 데이터 소스와 도구에 표준화된 방식으로 연결될 수 있게 해줍니다.

MCP의 주요 특징은 다음과 같습니다:

개방형 표준(Open Standard): MCP는 오픈소스로 공개되어 있어 누구나 자유롭게 사용하고 개선할 수 있습니다. 앤트로픽이 개발했지만 Claude와 같은 그들의 모델에만 국한되지 않고, 어떤 AI 시스템에서도 사용할 수 있습니다.
양방향 연결(Two-way Connection): MCP는 AI 모델과 데이터 소스 간의 양방향 통신을 지원합니다. 기존 API 호출 방식에서는 AI가 데이터를 요청하면 서버가 한 번 응답하고 끝나는 방식이었지만, MCP에서는 AI 모델과 데이터 소스가 지속적으로 연결된 상태에서 서로 정보를 주고받을 수 있습니다.
범용성과 표준화(Universality and Standardization): MCP는 다양한 데이터 소스와 도구를 하나의 표준 프로토콜로 연결할 수 있게 해줍니다. 개발자는 각 데이터 소스마다 별도의 커넥터를 유지할 필요 없이 단일 프로토콜을 통해 연결할 수 있습니다.
보안 및 신뢰성(Security and Reliability): MCP는 AI 모델과 데이터 소스 간의 안전하고 신뢰할 수 있는 연결을 제공합니다. 이를 통해 개인 정보 보호와 데이터 무결성을 유지할 수 있습니다.

MCP는 AI 모델이 단순히 텍스트를 생성하는 것을 넘어서, 필요한 정보를 실시간으로 가져오고 다른 소프트웨어나 데이터 시스템과 협업할 수 있도록 만들어 주는 기술입니다. 이를 통해 AI 모델의 성능과 실제 활용도를 높이는 것이 MCP의 핵심 목표입니다.

MCP의 핵심 구성 요소

MCP는 클라이언트-서버 아키텍처를 기반으로 하며, AI 모델과 외부 데이터 소스 간의 원활한 통신을 가능하게 하는 구조로 설계되었습니다. MCP는 다음과 같은 세 가지 핵심 구성 요소로 이루어져 있습니다:

호스트(Host)

AI 애플리케이션의 컨테이너이자 조정자 역할을 합니다.
여러 클라이언트 인스턴스를 관리합니다.
클라이언트 연결 권한과 생명주기를 제어합니다.
보안 정책과 동의 요구사항을 시행합니다.
AI/LLM 통합 및 샘플링을 조정합니다.
클라이언트 간 컨텍스트 집계를 관리합니다.
ex) Claude App, IDEs, AI 도구들

MCP 클라이언트(MCP Clients)

호스트에 의해 생성되며 서버와의 독립적인 연결을 유지합니다.
서버당 하나의 상태 유지 세션을 설정합니다.
프로토콜 협상 및 기능 교환을 처리합니다.
양방향으로 프로토콜 메시지를 라우팅합니다.
구독 및 알림을 관리합니다.
서버 간 보안 경계를 유지합니다.

MCP 서버(MCP Servers)

특화된 컨텍스트와 기능을 제공합니다.
MCP 기본 요소를 통해 리소스, 도구 및 프롬프트를 노출합니다.
독립적으로 작동하며 집중된 책임을 가집니다.
클라이언트 인터페이스를 통해 샘플링을 요청합니다.
보안 제약을 준수해야 합니다.
로컬 프로세스 또는 원격 서비스일 수 있습니다.

MCP의 작동 방식

MCP의 작동 방식은 다음과 같은 단계로 이루어집니다:

연결 설정(Connection Establishment)

호스트 애플리케이션(예: Claude Desktop)이 MCP 클라이언트를 생성합니다.
클라이언트는 MCP 서버와 연결을 설정합니다.
연결 설정 과정에서 프로토콜 버전, 기능, 권한 등이 협상됩니다.

컨텍스트 교환(Context Exchange)

서버는 클라이언트에게 데이터 소스의 컨텍스트 정보를 제공합니다.
클라이언트는 이 정보를 호스트 프로세스에 전달합니다.
호스트 프로세스는 여러 클라이언트로부터 받은 컨텍스트를 집계하여 AI 모델에 제공합니다.

도구 호출(Tool Invocation)

AI 모델은 특정 작업을 수행하기 위해 도구 호출을 요청할 수 있습니다.
호스트 프로세스는 이 요청을 적절한 클라이언트에 전달합니다.
클라이언트는 서버에 도구 호출 요청을 전송합니다.
서버는 요청된 작업을 수행하고 결과를 클라이언트에 반환합니다.

결과 처리(Result Processing)

클라이언트는 서버로부터 받은 결과를 호스트 프로세스에 전달합니다.
호스트 프로세스는 이 결과를 AI 모델에 제공합니다.
AI 모델은 이 정보를 바탕으로 응답을 생성합니다.

MCP의 기술적 구현

MCP는 다양한 프로그래밍 언어로 구현될 수 있으며, 앤트로픽은 다음과 같은 SDK를 제공합니다:

TypeScript SDK
Python SDK
Java SDK
Kotlin SDK

이러한 SDK를 사용하여 개발자는 MCP 서버와 클라이언트를 쉽게 구현할 수 있습니다.

MCP Server 구현

Python에서는 fastmcp라는 라이브러리를 활용해 간단하게 MCP 서버를 구현할 수 있습니다.

https://github.com/jlowin/fastmcp

GitHub - jlowin/fastmcp: The fast, Pythonic way to build Model Context Protocol servers

The fast, Pythonic way to build Model Context Protocol servers - GitHub - jlowin/fastmcp: The fast, Pythonic way to build Model Context Protocol servers

github.com

Python Fastmcp를 활용한 간단한 서버 구현 예제는 다음과 같습니다:

from typing import Any
import httpx
from mcp.server.fastmcp import FastMCP

# 서버 초기화
mcp = FastMCP("name-origin") 

# API 기본 URL
base_url = "https://api.nationalize.io"
    
# 메서드 정의
@mcp.tool() 
async def predict_origin(self, name: str) -> dict:
    """Nationalize API를 사용하여 주어진 이름의 출신 국가를 예측합니다
    Args:
        name (str): 출신 국가를 예측할 이름
    Returns:
        dict: 이름의 출신 국가
    """
    async with httpx.AsyncClient()  as client:
        response = await client.get(f"{base_url}/?name={name}")
        return response.json()

# 메서드 정의
@mcp.tool()
async def batch_predict(self, names: list[str]) -> dict:
    """여러 이름의 출신 국가를 한 번에 예측합니다
    Args:
        names (list[str]): 출신 국가를 예측할 이름 목록
    Returns:
        dict: 이름들의 출신 국가
    """
    results = {}
    for name in names:
        results[name] = await self.predict_origin(name)
    return results

if __name__ == "__main__":
    print("이름 출신 국가 서버 시작 중...")
    mcp.run(transport='stdio')

MCP Client 구현

from mcp import ClientSession, StdioServerParameters, types
from mcp.client.stdio import stdio_client

# Create server parameters for stdio connection
server_params = StdioServerParameters(
    command="python",  # Executable
    args=["example_server.py"],  # Optional command line arguments
    env=None,  # Optional environment variables
)


async def run():
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            # Initialize the connection
            await session.initialize()

            # List available prompts
            prompts = await session.list_prompts()

            # Get a prompt
            prompt = await session.get_prompt(
                "example-prompt", arguments={"arg1": "value"}
            )

            # List available resources
            resources = await session.list_resources()

            # List available tools
            tools = await session.list_tools()

            # Read a resource
            content, mime_type = await session.read_resource("file://some/path")

            # Call a tool
            result = await session.call_tool("tool-name", arguments={"arg1": "value"})


if __name__ == "__main__":
    import asyncio

    asyncio.run(run())

MCP와 기존 API의 차이점은 뭘까?

MCP는 기존의 API(Application Programming Interface) 및 함수 호출(Function Calling) 방식과 비교했을 때 여러 가지 중요한 차이점을 가지고 있습니다.

MCP 이전 방식들

커스텀 API 통합 (일회성 커넥터)

가장 일반적인 방법은 각 서비스마다 커스텀 코드를 작성하거나 SDK를 사용하는 방식입니다. 예를 들어, AI 에이전트가 Google Drive와 SQL 데이터베이스에 접근하려면, 각각 Google의 API와 데이터베이스 드라이버를 별도로 통합해야 하며, 각기 다른 인증 방식, 데이터 형식, 고유한 특징을 모두 고려해야 합니다. 매우 번거롭고 복잡한 작업입니다.

언어 모델 플러그인 (예: OpenAI Plugins 등)

2023년에는 모델이 외부 API를 안전하게 호출할 수 있도록 표준화된 플러그인 명세(OpenAPI 스키마 등)를 제공하는 방식도 등장했습니다. 대표적인 예로는 ChatGPT의 플러그인 시스템이 있습니다. 이 방식은 MCP처럼 도구 접근을 표준화한다는 점에서는 유사하지만, 폐쇄적이고 제한된 구조입니다. 각 플러그인은 개별적으로 구축 및 호스팅해야 하며, ChatGPT나 Bing Chat 같은 특정 플랫폼에서만 사용할 수 있습니다. 또한 대부분의 플러그인은 모델이 API를 호출해 정보를 받는 단방향 구조에 초점을 맞추고 있어, 지속적이고 상호작용적인 세션을 유지하지는 못합니다.

프레임워크 기반 도구 사용 (LangChain의 Tools, Agents 등)

LangChain과 같은 에이전트 오케스트레이션 프레임워크는 LLM에게 “도구”(함수)를 설명과 함께 제공하여, 모델이 상황에 따라 이를 호출하도록 하는 방식을 대중화했습니다. 예를 들어 search()나 calculate()와 같은 도구를 정의하고, 모델이 필요할 때 적절히 활용합니다.
이 방식은 매우 강력하지만, 각 도구는 여전히 내부적으로 커스텀 구현이 필요합니다. LangChain은 500개 이상의 도구를 일관된 인터페이스로 제공하고 있지만, 개발자는 여전히 각 도구를 자신의 요구에 맞게 연결하거나 수정해야 합니다.

MCP는 이러한 구조를 보완합니다. MCP는 도구를 구현하기 위한 표준화된 인터페이스를 제공하며, MCP 서버는 어떤 에이전트든 사용할 수 있는 도구의 라이브러리 역할을 합니다. 핵심적인 차이점은 표준화의 대상입니다. LangChain은 개발자 코드에서 도구를 통합하기 위한 표준을 제시하는 반면, MCP는 모델이 직접 런타임 중에 도구를 발견하고 사용하는 표준을 만듭니다. 즉, 특정 도구를 위해 에이전트 코드를 작성하지 않더라도, 모델은 MCP를 통해 해당 도구를 실시간으로 통합할 수 있습니다. 이러한 흐름은 점차 융합되고 있으며, 실제로 LangChain 팀은 MCP의 확산을 계기로 MCP 서버를 LangChain 도구처럼 활용할 수 있도록 어댑터를 제공하고 있습니다. 이로 인해 LangChain이나 다른 프레임워크 기반 에이전트도 MCP 도구를 자연스럽게 사용할 수 있게 되었으며, MCP 생태계의 이점을 함께 누릴 수 있게 되었습니다.

검색 기반 생성(RAG)과 벡터 데이터베이스

LLM에 외부 컨텍스트를 제공하는 가장 일반적인 방식 중 하나는 RAG(Retrieval-Augmented Generation)입니다. 이 방식은 지식 기반(문서, 임베딩 등)을 검색하여 관련 정보를 추출하고, 이를 프롬프트에 삽입하여 모델이 참고하도록 합니다. RAG는 모델의 지식 제한이나 메모리 부족 문제를 해결하는 데 효과적이지만, 주로 정적인 텍스트 조각을 제공하며, 모델이 직접 외부 시스템에 행동을 취하거나 동적 쿼리를 실행하는 것은 불가능합니다.

결과적으로, RAG는 수동적으로 컨텍스트를 제공하는 방식인 반면, MCP는 모델이 능동적으로 컨텍스트를 획득하거나 조작할 수 있도록 합니다. 특히 실시간 정보가 필요하거나, 데이터베이스 쿼리, 게시글 작성과 같은 동적인 작업이 필요한 상황에서는, MCP가 단순한 정보 조회를 넘어서 작업 실행까지 가능한 보다 범용적인 메커니즘으로 기능합니다.

기존 API 및 함수 호출의 한계

개별 통합의 필요성: 각 데이터 소스마다 별도의 API 연결을 설정하고 관리해야 했습니다. 예를 들어, AI가 구글 스프레드시트, 사내 문서 저장소, CRM 시스템에서 데이터를 가져와야 한다면, 이들 각각의 API를 별도로 설정하고 관리해야 했습니다.
단방향 통신: 대부분의 API 호출은 단방향 통신 방식으로, AI가 데이터를 요청하면 서버가 한 번 응답하고 끝나는 방식이었습니다. 지속적인 상호작용이 어려웠습니다.
개발자 중심 설계: API 통합은 주로 개발자를 위해 설계되어 있어, 기술적 지식이 없는 사용자가 활용하기 어려웠습니다.
확장성 제한: 여러 데이터 소스를 통합할수록 복잡성이 기하급수적으로 증가하여 확장성에 제한이 있었습니다.
컨텍스트 유지의 어려움: 여러 시스템 간에 컨텍스트를 유지하기 어려워, AI가 다양한 도구와 데이터 소스를 오가며 작업할 때 일관성을 유지하기 어려웠습니다.

MCP의 차별화된 특징

MCP는 이러한 한계를 극복하기 위해 설계되었으며, 다음과 같은 차별화된 특징을 가지고 있습니다:

표준화된 프로토콜: MCP는 모든 데이터 소스와 도구에 대한 단일 표준 프로토콜을 제공합니다. 개발자는 각 데이터 소스마다 별도의 커넥터를 유지할 필요 없이 하나의 프로토콜을 통해 모든 연결을 관리할 수 있습니다.
양방향 통신: MCP는 AI 모델과 데이터 소스 간의 양방향 통신을 지원합니다. AI와 데이터 소스가 지속적으로 연결된 상태에서 서로 정보를 주고받을 수 있어, 더 복잡하고 상호작용적인 작업이 가능합니다.
사용자 친화적 설계: MCP는 개발자뿐만 아니라 기술적 지식이 없는 사용자도 쉽게 활용할 수 있도록 설계되었습니다. 자연어로 AI의 행동을 조작할 수 있는 가능성이 커졌습니다.
확장성 향상: 표준화된 프로토콜을 통해 여러 데이터 소스와 도구를 쉽게 통합할 수 있어, 확장성이 크게 향상되었습니다.
컨텍스트 유지: MCP는 여러 시스템 간에 컨텍스트를 유지할 수 있어, AI가 다양한 도구와 데이터 소스를 오가며 작업할 때도 일관성을 유지할 수 있습니다.
오픈소스 생태계: MCP는 오픈소스로 공개되어 있어, 커뮤니티의 기여와 혁신을 통해 지속적으로 발전할 수 있습니다.

실제 사용 시나리오에서의 차이점

실제 사용 시나리오에서 MCP와 기존 API의 차이점을 살펴보겠습니다:

시나리오 1: 데이터 분석

기존 API 방식:

AI에게 데이터 분석을 요청합니다.
AI는 특정 데이터베이스에 접근하기 위한 API 호출을 생성합니다.
개발자가 이 API 호출을 구현하고 실행합니다.
데이터가 반환되면 AI는 이를 분석합니다.
추가 데이터가 필요한 경우 새로운 API 호출을 생성하고 과정을 반복합니다.

MCP 방식:

AI에게 데이터 분석을 요청합니다.
AI는 MCP를 통해 데이터베이스에 직접 연결됩니다.
AI는 필요한 데이터를 실시간으로 쿼리하고 분석합니다.
추가 데이터가 필요한 경우 같은 연결을 통해 즉시 요청할 수 있습니다.
분석 결과를 바탕으로 데이터베이스에 업데이트를 적용할 수도 있습니다.

시나리오 2: 문서 작성

기존 API 방식:

AI에게 회사 정책에 기반한 문서 작성을 요청합니다.
AI는 정책 문서에 접근하기 위한 API 호출을 생성합니다.
개발자가 이 API 호출을 구현하고 실행합니다.
정책 문서가 반환되면 AI는 이를 기반으로 문서를 작성합니다.
작성된 문서는 별도의 API 호출을 통해 저장해야 합니다.

MCP 방식:

AI에게 회사 정책에 기반한 문서 작성을 요청합니다.
AI는 MCP를 통해 정책 문서 저장소에 직접 연결됩니다.
AI는 필요한 정책 문서를 실시간으로 검색하고 참조합니다.
문서 작성 중 추가 정보가 필요한 경우 같은 연결을 통해 즉시 접근할 수 있습니다.
작성된 문서는 MCP를 통해 직접 저장소에 저장할 수 있습니다.

MCP가 최근 화제가 되는 이유

접근성과 사용 편의성 향상

MCP가 주목받는 첫 번째 이유는 개발자가 아닌 일반 사용자도 상대적으로 쉽게 활용할 수 있다는 점입니다. 기존 방식에서는 AI가 특정 데이터를 가져오려면 개발자가 직접 API를 설정해야 했지만, MCP를 활용하면 이런 과정이 훨씬 단순해지고 자연어로도 AI의 행동을 조작할 수 있는 가능성이 커집니다.

Claude Desktop 앱에서 MCP 서버를 쉽게 설치하고 연결할 수 있게 되면서, 기술적 지식이 없는 사용자도 AI가 로컬 파일 시스템, 데이터베이스, 웹 서비스 등에 접근할 수 있도록 설정할 수 있게 되었습니다. 이는 AI의 활용 범위를 크게 확장시키는 요인이 되고 있습니다.

오픈소스 생태계의 성장

MCP가 오픈소스로 공개되었다는 점은 혁신을 가속화하는 중요한 요인입니다. 누구나 자유롭게 MCP를 실험하고 개선할 수 있기 때문에 다양한 응용 사례가 빠르게 등장하고 있습니다. GitHub에서 MCP 관련 저장소는 이미 10,800명 이상의 팔로워를 보유하고 있으며, 다양한 언어(TypeScript, Python, Java, Kotlin 등)로 SDK가 제공되고 있습니다.

오픈소스 커뮤니티의 활발한 참여로 인해 다양한 데이터 소스와 도구에 대한 MCP 서버가 개발되고 있으며, 이는 MCP 생태계의 빠른 성장을 촉진하고 있습니다. 앤트로픽은 Google Drive, Slack, GitHub, Git, Postgres, Puppeteer 등 인기 있는 엔터프라이즈 시스템을 위한 사전 구축된 MCP 서버를 공유하고 있습니다.

다른 LLM과의 호환성

MCP는 앤트로픽의 Claude에만 국한되지 않고 다른 대규모 언어 모델(LLM)과도 호환된다는 점이 주목받고 있습니다. LinkedIn 포스트에 따르면, Amazon Bedrock과 같은 다른 LLM 서비스에서도 MCP를 활용할 수 있다는 것이 확인되었습니다. 이는 MCP가 특정 모델에 종속되지 않고 AI 생태계 전반에 영향을 미칠 수 있는 범용 표준으로 자리잡을 가능성을 보여줍니다.

다양한 LLM과의 호환성은 개발자들이 여러 AI 모델을 활용하는 애플리케이션을 더 쉽게 구축할 수 있게 해주며, 이는 MCP의 채택률을 높이는 요인이 되고 있습니다.

AI 에이전트 패러다임의 부상

최근 AI 분야에서는 단순한 질의응답을 넘어 복잡한 작업을 자율적으로 수행할 수 있는 AI 에이전트에 대한 관심이 높아지고 있습니다. MCP는 이러한 AI 에이전트 패러다임과 완벽하게 맞아떨어지는 기술입니다.

MCP를 통해 AI 에이전트는 다양한 데이터 소스와 도구에 접근하여 복잡한 작업을 수행할 수 있게 됩니다. 예를 들어, 코딩 작업을 수행하는 AI 에이전트는 MCP를 통해 코드 저장소, 개발 환경, 문서 등에 접근하여 더 정확하고 유용한 코드를 생성할 수 있습니다.

실제로 Zed, Replit, Codeium, Sourcegraph와 같은 개발 도구 회사들은 MCP를 활용하여 AI 에이전트가 코딩 작업 주변의 컨텍스트를 더 잘 이해하고, 더 정교하고 기능적인 코드를 생성할 수 있도록 하고 있습니다.

실질적인 활용 사례의 증가

처음 MCP가 공개되었을 때는 또 하나의 기술적 시도 정도로 여겨졌지만, 최근 들어 AI의 실질적인 활용 방식이 변화하면서 점점 더 많은 사람들이 이 기술을 주목하고 있습니다. 특히 X(구 트위터)와 같은 SNS 및 AI 커뮤니티에서는 MCP를 활용한 자동화 사례가 늘어나고 있으며, AI 에이전트가 실질적인 업무를 처리하는 모습도 점점 보이고 있습니다.

Block(구 Square)과 Apollo와 같은 기업들은 이미 MCP를 자사 시스템에 통합하고 있으며, 이는 MCP가 단순한 실험적 기술이 아닌 실제 비즈니스 환경에서 가치를 창출할 수 있는 기술임을 보여줍니다.

멀티턴 상호작용의 중요성 증가

AI와의 상호작용 방식이 단순한 일회성 질의응답에서 여러 차례의 대화를 통한 복잡한 작업 수행으로 변화하면서, 멀티턴(Multi-turn) 상호작용의 중요성이 커지고 있습니다. MCP는 이러한 멀티턴 상호작용을 효과적으로 지원하는 기술입니다.

MCP를 통해 AI는 사용자와의 대화 중에 필요한 정보를 실시간으로 가져오고, 이를 바탕으로 더 정확하고 유용한 응답을 제공할 수 있습니다. 또한, 여러 차례의 대화를 통해 복잡한 작업을 단계적으로 수행할 수 있어, AI의 활용 범위가 크게 확장됩니다.

결론

Model Context Protocol(MCP)은 앤트로픽이 2024년 11월에 오픈소스로 공개한 혁신적인 기술로, AI 모델과 외부 데이터 소스 및 도구 간의 원활한 연결을 가능하게 합니다. MCP는 단순한 기술적 혁신을 넘어, AI가 실제 세계의 데이터와 시스템과 상호작용하는 방식에 근본적인 변화를 가져오고 있습니다.

MCP의 주요 특징인 개방형 표준, 양방향 연결, 범용성과 표준화, 보안 및 신뢰성은 기존 API 및 함수 호출 방식의 한계를 극복하고, AI 모델의 활용 범위를 크게 확장시키고 있습니다. 특히 클라이언트-서버 아키텍처를 기반으로 한 MCP의 기술적 구조는 확장성, 모듈성, 보안성을 고려하여 설계되었으며, 이를 통해 AI 모델과 외부 데이터 소스 간의 원활한 통합이 가능해졌습니다.

MCP가 최근 화제가 되는 이유는 접근성과 사용 편의성 향상, 오픈소스 생태계의 성장, 다른 LLM과의 호환성, AI 에이전트 패러다임의 부상, 실질적인 활용 사례의 증가, 멀티턴 상호작용의 중요성 증가 등 다양한 요인이 있습니다. 이러한 요인들로 인해 MCP는 AI 커뮤니티에서 큰 관심을 받고 있으며, 실제 비즈니스 환경에서도 활용되고 있습니다.

현재 MCP는 소프트웨어 개발 및 코딩 지원, 기업 데이터 통합 및 분석, 문서 관리 및 지식 접근, 로컬 파일 시스템 접근, 데이터베이스 접근 및 쿼리 등 다양한 분야에서 활용되고 있습니다. 미래에는 AI 에이전트의 발전, 생태계의 확장, 산업별 특화 솔루션, 개인화된 AI 비서의 발전, 보안 및 개인정보 보호 강화, 멀티모달 통합 등을 통해 더 큰 영향을 미칠 것으로 전망됩니다.

물론 MCP는 아직 초기 단계이기 때문에 과장된 기대라는 시각도 있지만, 실질적인 사례가 쌓이고 있다는 점에서 단순한 유행보다는 AI 기술의 다음 단계를 여는 중요한 전환점이 될 가능성이 높아 보입니다. 앞으로 MCP가 AI 생태계에 어떤 변화를 가져올지 지속적으로 주목할 필요가 있습니다.

참고 자료

검색 시스템을 위한 Document Splitting

pfldy2850 — Sun, 26 Jan 2025 17:31:29 +0900

검색 시스템은 방대한 양의 데이터를 처리하여 사용자에게 적절한 정보를 제공하는 데 중점을 둡니다. 하지만 모든 데이터가 적절히 검색 가능한 형태로 저장되어 있지 않을 때, 검색 품질이 저하될 수 있습니다. 이를 해결하기 위한 핵심 기술 중 하나가 바로 Document Splitting입니다. 이 글에서는 Document Splitting의 개념, 필요성, 구현 사례를 다룹니다.

Document Splitting이란?

Document Splitting은 큰 문서를 더 작은 단위로 나누는 프로세스를 의미합니다. 이 단위는 문장(Sentence), 문단(Paragraph), 또는 사용자가 정의한 특정 논리적 단위(예: 섹션, 챕터 등)일 수 있습니다.

예를 들어, 10페이지에 걸쳐 있는 PDF 파일을 통째로 처리하는 대신, 페이지별 또는 문단별로 나누어 저장 및 검색할 수 있습니다. 이렇게 하면 검색 시스템이 더 효율적으로 작동하고, 검색 결과의 정확도를 높일 수 있습니다.

왜 Document Splitting이 필요한가요?

1. 효율적인 검색 결과 제공

사용자가 특정 질문을 검색할 때, 방대한 문서 전체를 결과로 반환하면 유용성이 떨어질 수 있습니다.

작은 단위로 나뉜 데이터를 처리하면, 더 구체적이고 관련성 높은 결과를 제공할 수 있습니다.

2. 검색 속도 향상

작은 단위로 나뉜 데이터는 검색 엔진이 더 빠르게 처리할 수 있습니다. 검색 쿼리가 단위 데이터에 적용되기 때문입니다.

3. 텍스트 임베딩의 효과 극대화

AI 기반 검색 시스템에서 자주 사용하는 텍스트 임베딩 기법은 입력 데이터의 크기에 민감합니다. 문서가 작게 분리될수록 임베딩의 품질과 관련성 점수가 향상됩니다.

4. 장문의 문서 처리 문제 해결

검색 엔진이 한 번에 처리할 수 있는 데이터 크기에는 제한이 있습니다. 이를 초과하는 문서는 일부가 잘리거나 처리가 실패할 수 있습니다. Splitting을 통해 이러한 문제를 예방할 수 있습니다.

Document Splitting 구현 사례

Document Splitting은 데이터의 특성과 목적에 따라 다양한 방법으로 구현할 수 있습니다. 아래는 일반적인 접근 방식입니다.

1. 문자열 분리

문서 내용을 특정 기준(예: 문장, 문단, 페이지)으로 나눕니다.

Python을 사용한 간단한 구현 예제:

from nltk.tokenize import sent_tokenize

# 큰 문서 예제
large_document = """검색 시스템은 데이터를 처리하여 정보를 제공합니다. Document Splitting은 이를 향상시킬 수 있는 방법입니다."""

# 문장을 기준으로 문서 분리
split_sentences = sent_tokenize(large_document)
print(split_sentences)

['검색 시스템은 데이터를 처리하여 정보를 제공합니다.', 'Document Splitting은 이를 향상시킬 수 있는 방법입니다.']

2. 구조 기반 분리

문서에 제목, 섹션 등의 계층적 구조가 있는 경우 이를 기반으로 분리합니다. 예를 들어 HTML, Markdown, PDF 같은 형식에서는 특정 태그나 스타일을 기준으로 나눌 수 있습니다.

from bs4 import BeautifulSoup

# HTML 문서 예제
html_doc = """
<h1>제목</h1>
<p>이 문단은 첫 번째 섹션입니다.</p>
<p>이 문단은 두 번째 섹션입니다.</p>
"""

soup = BeautifulSoup(html_doc, 'html.parser')
paragraphs = [p.text for p in soup.find_all('p')]
print(paragraphs)

['이 문단은 첫 번째 섹션입니다.', '이 문단은 두 번째 섹션입니다.']

3. Semantic Meaning 기반 분리

다른 방법들과 달리, Semantic 기반 분리는 텍스트의 내용을 실제로 고려합니다. 문서나 텍스트 구조를 의미의 대리자로 사용하는 대신, 텍스트의 의미를 직접 분석합니다.

구현 방식은 다양하지만, 개념적으로 텍스트 의미가 크게 변하는 지점을 기준으로 분리합니다.

예를 들어, 슬라이딩 윈도우(sliding window) 방식을 사용하여 임베딩을 생성하고, 임베딩 간의 차이를 비교해 의미 변화가 큰 지점을 찾을 수 있습니다.

from sentence_transformers import SentenceTransformer
import numpy as np

# 텍스트 예제
document = [
    "검색 시스템은 데이터를 처리하여 정보를 제공합니다.",
    "Document Splitting은 이를 향상시킬 수 있는 방법입니다.",
    "AI 기반 검색 엔진은 매우 효과적입니다."
]

# 임베딩 모델 초기화
model = SentenceTransformer('all-MiniLM-L6-v2')

# 슬라이딩 윈도우 방식으로 임베딩 생성
embeddings = [model.encode(sentence) for sentence in document]

# 임베딩 간 유사도 계산
for i in range(len(embeddings) - 1):
    similarity = np.dot(embeddings[i], embeddings[i+1]) / (np.linalg.norm(embeddings[i]) * np.linalg.norm(embeddings[i+1]))
    print(f"문장 {i}과 문장 {i+1}의 유사도: {similarity:.2f}")

임베딩 간의 유사도가 낮은 지점에서 분리하면, 더 의미적으로 일관된 섹션을 생성할 수 있습니다. 이 방법은 검색, 요약과 같은 후속 작업의 품질을 향상시킬 가능성이 높습니다.

LangChain 예제

How to split text based on semantic similarity | ️ LangChain

Taken from Greg Kamradt's wonderful notebook:

python.langchain.com

# Load Example Data
# This is a long document we can split up.
with open("state_of_the_union.txt") as f:
    state_of_the_union = f.read()
    

# Create Text Splitter
from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai.embeddings import OpenAIEmbeddings

text_splitter = SemanticChunker(OpenAIEmbeddings())


# Split Text
docs = text_splitter.create_documents([state_of_the_union])
print(docs[0].page_content)

Madam Speaker, Madam Vice President, our First Lady and Second Gentleman. Members of Congress and the Cabinet. Justices of the Supreme Court. My fellow Americans. Last year COVID-19 kept us apart. This year we are finally together again. Tonight, we meet as Democrats Republicans and Independents. But most importantly as Americans. With a duty to one another to the American people to the Constitution. And with an unwavering resolve that freedom will always triumph over tyranny. Six days ago, Russia’s Vladimir Putin sought to shake the foundations of the free world thinking he could make it bend to his menacing ways. But he badly miscalculated. He thought he could roll into Ukraine and the world would roll over. Instead he met a wall of strength he never imagined. He met the Ukrainian people. From President Zelenskyy to every Ukrainian, their fearlessness, their courage, their determination, inspires the world. Groups of citizens blocking tanks with their bodies. Everyone from students to retirees teachers turned soldiers defending their homeland. In this struggle as President Zelenskyy said in his speech to the European Parliament “Light will win over darkness.” The Ukrainian Ambassador to the United States is here tonight. Let each of us here tonight in this Chamber send an unmistakable signal to Ukraine and to the world. Please rise if you are able and show that, Yes, we the United States of America stand with the Ukrainian people. Throughout our history we’ve learned this lesson when dictators do not pay a price for their aggression they cause more chaos. They keep moving.

아래 글을 다양한 breakpoints에 대해 splitting

ANN(Approximate Nearest Neighbor) 알고리즘의 이해 #2 Flat, LSH, IVF, HNSW + SQ, PQ, RPQ

벡터 검색과 ANN(Approximate Nearest Neighbor) 알고리즘은 대규모 데이터셋에서 유사한 항목을 빠르게 찾는 데 필수적인 기술입니다. 본 글에서는 다양한 벡터 검색 인덱스에 대해 소개

dytis.tistory.com

embedding은 BAAI/bge-m3 사용

from langchain_community.embeddings import HuggingFaceBgeEmbeddings

model_name = "BAAI/bge-m3"
model_kwargs = {"device": "cpu"}
encode_kwargs = {"normalize_embeddings": True}
hf = HuggingFaceBgeEmbeddings(
    model_name=model_name, model_kwargs=model_kwargs, encode_kwargs=encode_kwargs
)

Percentile

text_splitter = SemanticChunker(hf, breakpoint_threshold_type="percentile")
text_splitter.create_documents([orgin_doc])

Standard Deviation

text_splitter = SemanticChunker(hf, breakpoint_threshold_type="standard_deviation")
text_splitter.create_documents([orgin_doc])

Interquartile

text_splitter = SemanticChunker(hf, breakpoint_threshold_type="interquartile")
text_splitter.create_documents([orgin_doc])

Gradient

text_splitter = SemanticChunker(hf, breakpoint_threshold_type="gradient")
text_splitter.create_documents([orgin_doc])