팀 Ollama 서버, 이렇게 잠가야 합니다 — 보안 설정·vLLM 전환·멀티에이전트 오케스트레이션까지

이 글은 Nginx와 Docker를 다뤄본 경험이 있는 분을 대상으로 합니다. 팀 내 Ollama 서버를 운영 중이거나 도입을 검토 중인 분이라면 특히 도움이 될 내용입니다.

2026년 현재 전 세계 130개국에서 약 17만 5천 개의 Ollama 서버가 인증 없이 인터넷에 노출된 채 발견되었습니다. curl http://your-server:11434/api/generate를 직접 날려봤는데 아무런 인증 없이 응답이 돌아왔을 때의 그 서늘함은, 저도 직접 경험해봤습니다. 분명 "사내망이니까 괜찮겠지"라고 생각하고 올렸다가 포트를 미처 닫지 못한 사례들이 그 숫자 안에 포함되어 있을 겁니다.

로컬에서 ollama serve 한 줄로 모델 띄우고, MCP(Model Context Protocol) 서버 연결해서 팀 슬랙에 공유하는 순간까지는 정말 신납니다. 그런데 팀원 여럿이 쓰기 시작하면서 상황이 달라집니다. 보안 구멍이 드러나고, 동시 요청이 늘어나면 레이턴시가 수십 초로 폭발하고, 에이전트를 여러 개 조합하려니 어느 프레임워크를 선택해야 할지 막막해집니다. 이 글은 그 세 가지 문제를 하나의 맥락으로 묶어 이야기합니다. Ollama + MCP 에이전트를 팀 단위로 안전하게 운영하는 보안 설정(MCP security), Ollama에서 vLLM으로의 전환 시점(vLLM migration), 그리고 Microsoft Agent Framework(MAF)와 fast-agent를 활용한 멀티에이전트 오케스트레이션(multi-agent orchestration) 을 순서대로 다룹니다.

핵심 개념

1. Ollama + MCP: 팀 배포가 왜 생각보다 까다로운가

Ollama는 로컬 LLM 서빙에서 정말 편리한 도구입니다. OpenAI 호환 API를 그대로 노출해주니 기존 코드 수정도 거의 없고, 60초 안에 모델 하나 띄우는 건 일도 아닙니다. 그런데 "팀원들도 같이 쓰자"고 서버에 올리는 순간부터 이야기가 달라집니다.

Ollama에는 기본 인증 메커니즘이 없습니다. 직접 curl http://your-server:11434/api/generate -d '{"model":"llama3.2","prompt":"test"}'를 날려보면 아무런 인증 없이 응답이 돌아옵니다. 팀 내부망에만 올린다고 해도 사내 네트워크 안에서 누구나 요청을 보낼 수 있다는 뜻이고, 그것이 17만 5천 개 노출 서버가 그냥 나온 숫자가 아닌 이유이기도 합니다.

MCP는 에이전트가 외부 도구 및 데이터 소스와 표준화된 방식으로 연결되는 프로토콜입니다. 2026년 현재 주요 에이전트 프레임워크 6종이 모두 지원하는 사실상의 표준(de facto standard)이 되었고, Google의 Agent-to-Agent Protocol(A2A)과 역할을 나눠 사용됩니다.

프로토콜 역할 분담: MCP는 에이전트↔툴 연결을, A2A는 에이전트↔에이전트 통신을 담당합니다. 둘은 경쟁 관계가 아니라 상호 보완 관계입니다.

MCP가 강력한 이유는 에이전트에 파일 시스템 접근, 웹 검색, DB 조회 같은 실제 능력을 부여할 수 있기 때문입니다. 바로 그 점이 공격 면적이기도 합니다. 에이전트가 외부 데이터를 읽고 도구를 실행할 수 있다면, 그 경로로 악의적인 명령이 들어올 수 있다는 뜻이니까요.

2. vLLM: 언제 갈아타야 하나

vLLM은 PagedAttention 기반의 연속 배칭(continuous batching)과 고효율 KV 캐시로 높은 동시 처리량을 지원하는 프로덕션급 추론 엔진입니다. 2026년 NVIDIA A100 기준 벤치마크에서 8개 동시 요청 시 토큰 생성 속도(tokens/sec) 는 vLLM이 793, Ollama가 41로 약 19배 차이가 납니다. P99 레이턴시도 80ms vs 673ms입니다.

여기서 지표를 정확히 구분해야 합니다. 종종 언급되는 "처리량 2.3배"는 요청 처리량(requests/sec) 기준이고, 793 vs 41은 토큰 처리량(tokens/sec) 기준입니다. 두 지표는 다르며, 어느 쪽을 봐도 동시 사용자가 많을수록 vLLM이 압도적으로 유리하다는 결론은 같습니다.

연속 배칭(Continuous Batching): 요청이 들어오는 즉시 배치에 편입해 처리하는 방식. 기존 정적 배칭처럼 배치가 꽉 찰 때까지 기다리지 않아 GPU 활용률이 크게 높아집니다.

단, 단일 요청 레이턴시만 따지면 Ollama가 약 18% 앞섭니다. 동시 사용자가 없는 개발 환경에서는 Ollama가 오히려 더 빠를 수 있습니다.

"동시 사용자 5명 초과 시 전환"이라는 기준은 어디서 나온 걸까요? Ollama는 기본적으로 요청을 직렬로 처리합니다. OLLAMA_NUM_PARALLEL 환경변수로 병렬 처리 수를 늘릴 수 있지만, GPU VRAM을 그만큼 더 사용합니다. 16GB VRAM에 8B 모델을 올리면 병렬 처리 여유가 거의 없어 동시 요청이 큐에 쌓이기 시작합니다. 실무 경험상 5명 전후에서 "왜 이렇게 느려요?"라는 말이 나오기 시작합니다. GPU 사양에 따라 달라지므로, 이 숫자는 절대적 기준이 아닌 "슬슬 모니터링을 시작해야 할 신호"로 받아들이는 것이 좋습니다.

3. Microsoft Agent Framework vs fast-agent

멀티에이전트 오케스트레이션 프레임워크 선택에서 2026년 가장 큰 변화는 AutoGen이 공식적으로 유지보수 모드에 진입했다는 점입니다. Microsoft는 AutoGen과 Semantic Kernel을 통합한 Microsoft Agent Framework(MAF) 를 2026년 4월 1.0 GA로 출시하고 신규 프로젝트에 MAF를 권장합니다.

한편 fast-agent는 MCP를 네이티브로 완전 구현한 Python 경량 프레임워크입니다. 엔드-투-엔드 MCP 기능(샘플링·엘리시테이션 포함)을 완전히 구현한 첫 번째 프레임워크이며, 로컬 Ollama와의 연동이 직관적이어서 빠른 프로토타이핑에 적합합니다.

항목	MAF	fast-agent
성숙도	엔터프라이즈 GA (1.0)	경량·빠른 이터레이션
언어	.NET, Python	Python
MCP 지원	내장 MCP 클라이언트	MCP 네이티브 (완전 구현)
오케스트레이션	Workflow 추상화, 상태 관리	Chain/Parallel/Router/Orchestrator
적합 환경	엔터프라이즈, Azure 연동	빠른 프로토타이핑, 로컬 Ollama

실전 적용

예시 1: 팀 공유 Ollama 보안 아키텍처 구성

솔직히, 저도 처음에 팀 서버에 Ollama 올릴 때 OLLAMA_HOST=0.0.0.0으로 그냥 바인딩했습니다. "사내망이니까 괜찮겠지"라는 생각이었는데, 그건 정말 위험한 발상이었습니다. 사내망 내부에서도 권한 없는 접근, 로그 미수집, 레이트 리미팅 부재 같은 문제가 그대로 남기 때문입니다.

권장 아키텍처는 이렇습니다:

[팀원 클라이언트]
      ↓ HTTPS (TLS 1.3)
[Nginx 리버스 프록시]
  - API 키 검증 (Authorization 헤더)
  - Rate Limiting (zone 기반)
  - 접근 로그 수집
      ↓ HTTP (localhost only)
[Ollama 서버: 127.0.0.1:11434]
      ↓
[MCP 툴 실행: Docker 샌드박스]

Nginx 설정의 핵심 부분입니다:

nginx

# /etc/nginx/sites-available/ollama-gateway
limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=10r/m;
 
server {
    listen 443 ssl;
    server_name ollama.internal.your-team.com;
 
    ssl_certificate     /etc/ssl/certs/ollama.crt;
    ssl_certificate_key /etc/ssl/private/ollama.key;
    ssl_protocols       TLSv1.3;
 
    location /api/ {
        # ⚠️ 주의: location 블록 안에서의 if 지시어는 Nginx 공식 문서에서
        # "if is Evil"로 표현하는 안티패턴입니다. proxy_pass와 조합 시
        # 예기치 않은 동작이 생길 수 있습니다. 이 예시는 구조 이해용 데모이며,
        # 프로덕션에서는 auth_request 모듈 또는 OpenResty/Lua 기반 검증을 권장합니다.
        if ($http_authorization != "Bearer ${OLLAMA_API_KEY}") {
            return 401 '{"error": "Unauthorized"}';
        }
 
        limit_req zone=ollama_limit burst=5 nodelay;
 
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
    }
 
    location /admin/ {
        allow 10.0.0.0/8;
        deny all;
    }
}

OLLAMA_API_KEY 값은 절대 설정 파일에 직접 넣지 않는 것이 좋습니다. git에 올라가는 순간 팀 전체에 노출됩니다. Nginx를 실행하는 환경의 환경변수나 시크릿 매니저에서 주입하는 방식을 권장합니다.

Ollama 자체는 반드시 127.0.0.1에만 바인딩되도록 설정해야 합니다:

bash

# /etc/systemd/system/ollama.service 또는 .env
OLLAMA_HOST=127.0.0.1:11434
 
systemctl restart ollama

MCP 툴 실행 환경은 Docker로 격리하는 것을 권장합니다. 다만 아래 예시의 mcp/filesystem-server:latest는 공식 이미지 이름이 아닐 수 있습니다. docker pull mcp/filesystem-server가 실패한다면, 공식 MCP 레퍼런스 서버 실행 방식인 npx @modelcontextprotocol/server-filesystem 또는 uvx mcp-server-filesystem을 사용하거나 Docker Hub에서 이미지명을 직접 확인해볼 것을 권장합니다:

yaml

# docker-compose.yml (MCP 툴 실행 환경)
services:
  mcp-filesystem:
    # ⚠️ 이미지명은 실제 레지스트리에서 확인 필요
    # 대안: command: npx @modelcontextprotocol/server-filesystem /workspace
    image: mcp/filesystem-server:latest
    volumes:
      - ./workspace:/workspace:ro
    networks:
      - mcp-internal
    environment:
      - ALLOWED_PATHS=/workspace
 
  mcp-fetch:
    image: mcp/fetch-server:latest
    networks:
      - mcp-internal
 
networks:
  mcp-internal:
    internal: true

보안 설정을 제대로 갖추고 나면 팀 사용이 안정화됩니다. 그런데 사용자가 늘어나면서 이번엔 "서버가 너무 느려요"라는 소리가 나오기 시작합니다. 그게 바로 vLLM 전환을 진지하게 고민해야 할 신호입니다.

예시 2: vLLM 전환 — 환경 변수 두 개로 끝나는 마이그레이션

처음 vLLM 전환을 준비하면서 코드를 얼마나 뜯어고쳐야 할지 걱정했는데, 환경변수 두 개만 바꾸면 된다는 걸 알고 약간 허탈했습니다. Ollama와 vLLM 모두 OpenAI 호환 API를 노출하기 때문에, 코드를 한 줄도 건드리지 않아도 됩니다:

bash

# Ollama 사용 시
OPENAI_API_BASE=http://localhost:11434/v1
OPENAI_API_KEY=ollama  # Ollama는 키 값 무관, 형식만 맞추면 됨
 
# vLLM 전환 시 — 바뀌는 것은 이 두 줄뿐
OPENAI_API_BASE=http://your-vllm-server:8000/v1
OPENAI_API_KEY=your-vllm-api-key

vLLM 서버는 Docker로 이렇게 띄울 수 있습니다:

bash

docker run --gpus all \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --max-model-len 4096 \
  --api-key your-vllm-api-key

전환 판단 기준은 다음 표를 참고해볼 수 있습니다:

상황	권장 스택	이유
프로토타입, 1~3명 사용	Ollama 유지	셋업 속도, 단일 요청 레이턴시 유리
동시 사용자 5명 초과	vLLM 전환	연속 배칭으로 큐 적체 해소
레이턴시 SLA가 있는 경우	vLLM 전환	P99 레이턴시 80ms vs 673ms
GPU 서버 운영, 최대 처리량 목표	vLLM	GPU 활용률 최적화 설계
단일 요청 레이턴시가 최우선	Ollama	~18% 우위

레이턴시가 수십 초로 폭발하는 걸 경험하고 나서 "아, 진작 바꿀 걸" 하는 경우가 많습니다. 전환 자체가 워낙 간단하다 보니 오히려 결정을 미루게 되는 역설이 있는데, 동시 사용자가 3~5명을 넘기 시작하는 시점에 미리 vLLM 서버를 셋업해두는 것을 권장합니다. 사용자가 늘고 인프라가 안정화되면, 그다음 자연스럽게 떠오르는 고민이 멀티에이전트입니다.

예시 3: fast-agent로 MCP 네이티브 멀티에이전트 파이프라인 구성

fast-agent는 Ollama와의 연동이 직관적이고, MCP 서버를 에이전트에 붙이는 방식이 선언적으로 깔끔합니다. 실제 fast-agent API는 FastAgent 인스턴스를 생성하고 @app.agent, @app.chain 데코레이터를 사용하는 패턴입니다. 아래 코드는 공식 GitHub 패턴을 따랐으며, 최신 API는 공식 문서에서 확인해볼 것을 권장합니다:

python

# pipeline.py
from fast_agent import FastAgent
 
app = FastAgent("Research Pipeline")
 
@app.agent(
    name="researcher",
    model="ollama/llama3.2",
    servers=["filesystem", "fetch"],
    instruction="주어진 주제를 웹에서 조사하고 핵심 내용을 요약합니다."
)
async def researcher(agent):
    return await agent("AI 보안 트렌드 2026을 조사하고 요약해줘")
 
@app.agent(
    name="writer",
    model="ollama/llama3.2",
    servers=["filesystem"],
    instruction="전달받은 조사 내용을 개발자 블로그 포스트 형식으로 작성합니다."
)
async def writer(agent):
    return await agent("조사 결과를 바탕으로 블로그 포스트를 작성해줘")
 
# Chain 패턴: researcher 결과가 writer 입력으로 자동 전달
@app.chain(
    name="research_and_write",
    sequence=["researcher", "writer"]
)
async def research_and_write(agent):
    pass
 
async def main():
    async with app.run() as pipeline:
        result = await pipeline.research_and_write.send("AI 보안 트렌드 2026")
        print(result)

MCP 서버 설정 파일은 이렇게 관리할 수 있습니다:

yaml

# fastagent.config.yaml
mcp:
  servers:
    filesystem:
      command: npx
      args:
        - "@modelcontextprotocol/server-filesystem"
        - "./workspace"
    fetch:
      command: uvx
      args:
        - mcp-server-fetch
 
default_model: ollama/llama3.2

fast-agent가 지원하는 워크플로 패턴은 Chain 외에도 Parallel, Router, Orchestrator, Evaluator-Optimizer 등이 있습니다. 복잡한 태스크는 Orchestrator 패턴으로 LLM이 다음 에이전트를 동적으로 선택하도록 위임할 수도 있습니다. 빠른 프로토타이핑과 로컬 Ollama 연동이 목적이라면 fast-agent가 가장 진입 장벽이 낮습니다.

예시 4: Microsoft Agent Framework Workflow 패턴

팀 규모가 커지거나 Azure 연동이 필요한 엔터프라이즈 환경이라면 MAF의 Workflow 추상화가 유용합니다. 결정론적 실행 경로와 동적 오케스트레이션을 모두 다룰 수 있습니다.

아래 코드는 개념을 설명하기 위한 예시입니다. 실제 패키지명과 import 경로는 공식 문서(Microsoft Learn)에서 반드시 확인해볼 것을 권장합니다. MAF는 GA 이후에도 API가 빠르게 정비되고 있어, 아래 경로는 달라졌을 수 있습니다:

python

# maf_workflow.py
# ⚠️ 실제 패키지명은 공식 문서에서 확인 필요
# (예: microsoft_agents, agent_framework 등)
from microsoft.agent_framework import AgentRuntime, Workflow, Agent
from microsoft.agent_framework.mcp import MCPClientPlugin
 
runtime = AgentRuntime()
runtime.add_plugin(MCPClientPlugin(servers=["filesystem", "fetch"]))
 
@runtime.agent(
    name="analyzer",
    model="ollama/llama3.2",
    instructions="코드 변경사항을 분석하고 보안 리스크를 식별합니다."
)
class AnalyzerAgent(Agent):
    pass
 
@runtime.agent(
    name="reviewer",
    model="ollama/llama3.2",
    instructions="분석 결과를 검토하고 개선 제안을 작성합니다."
)
class ReviewerAgent(Agent):
    pass
 
# 확정적 워크플로: 실행 경로가 고정됨
workflow = Workflow(
    name="code-review-pipeline",
    steps=[
        {"agent": "analyzer", "input": "{{user_input}}"},
        {"agent": "reviewer", "input": "{{analyzer.output}}"},
    ]
)
 
async def main():
    result = await runtime.run_workflow(
        workflow,
        user_input="PR #42의 변경사항을 검토해줘"
    )
    print(result)

MAF의 강점은 세션 기반 상태 관리, 미들웨어·필터·텔레메트리가 내장되어 있다는 점입니다. OpenTelemetry 연동으로 에이전트 행동을 추적하는 것도 바로 붙일 수 있어, 프로덕션 가시성이 중요한 팀에 잘 맞습니다.

장단점 분석

실제로 팀에서 가장 많이 당하는 것만 꼽으면 "기본 인증 없음"과 "MCP 이미지 버전 미고정" 이 두 가지입니다. 나머지는 알면서도 나중으로 미루다가 터지는 경우가 많습니다.

장점

항목	내용
데이터 온프레미스 유지	민감 데이터가 외부 LLM API로 나가지 않음
OpenAI 호환 API	기존 코드 변경 최소화, Ollama↔vLLM 전환 용이
MCP 표준화	6개 이상의 주요 프레임워크 지원, 툴 재사용 가능
빠른 셋업	Ollama 기준 60초 이내 모델 서빙 시작
전환 유연성	환경 변수 2개 변경으로 Ollama → vLLM 마이그레이션 가능

단점 및 주의사항

항목	내용	대응 방안
Ollama 기본 인증 없음	그대로 노출 시 누구나 접근 가능	Nginx/Caddy 리버스 프록시 + API 키 필수
Ollama 낮은 동시성	직렬 처리 기본, 사용자 증가 시 레이턴시 급등	동시 사용자 5명 초과 시 vLLM 전환 검토
프롬프트 인젝션	사용자 입력을 통해 에이전트가 의도치 않은 명령 실행	입력 검증, 샌드박스 실행, Human-in-the-loop
툴 포이즈닝	MCP 서버 툴 정의 변조 시 위험 동작 유발	버전 고정, 서명된 툴 정의 사용
자격증명 노출	설정 파일 내 시크릿이 형상 관리 도구에 노출	환경변수 또는 시크릿 매니저 사용
과도한 권한	에이전트의 파괴적 작업(DB 삭제 등) 무방비 실행	최소 권한 원칙 + Human-in-the-loop 체크포인트

툴 포이즈닝(Tool Poisoning): MCP 서버가 제공하는 툴 정의(이름, 파라미터, 설명)가 악의적으로 변조되어 에이전트가 의도와 다른 위험한 동작을 수행하게 만드는 공격입니다. 2025년 Supabase Cursor 에이전트 사건처럼 지원 티켓을 통한 통합 토큰 유출이 실제 사례로 문서화되어 있습니다.

Human-in-the-loop: 에이전트가 파괴적이거나 되돌리기 어려운 작업(DB 레코드 삭제, 대용량 데이터 전송 등)을 실행하기 전에 반드시 사람의 확인을 거치도록 설계하는 패턴입니다.

실무에서 가장 흔한 실수

OLLAMA_HOST=0.0.0.0으로 직접 바인딩: "사내망이니까 괜찮겠지"라는 생각이 가장 많이 보이는 실수입니다. 반드시 127.0.0.1에만 바인딩하고 앞단에 프록시를 두어야 합니다.
MCP 서버 버전을 latest로 고정: 업스트림에서 툴 정의가 바뀌면 에이전트 동작이 예고 없이 달라집니다. 특정 버전 태그 또는 이미지 다이제스트를 고정하는 것을 권장합니다.
vLLM 전환을 너무 오래 미루기: 전환이 환경변수 두 개라 오히려 결정을 미루게 되는 역설이 있습니다. 동시 사용자가 3~5명을 넘기 시작하는 시점에 미리 vLLM 서버를 준비해두는 편이 훨씬 수월합니다.

마치며

팀 단위 Ollama 운영에서 보안 게이트웨이는 선택이 아닌 필수입니다. 규모가 커지면 vLLM 전환 시점을 미리 계획해두는 것이 중요합니다. 멀티에이전트 오케스트레이션은 팀 규모와 목표에 맞는 프레임워크를 골라 시작하면 됩니다.

지금 바로 시작해볼 수 있는 3단계:

Ollama를 127.0.0.1에만 바인딩하고 Nginx 게이트웨이를 앞에 붙여볼 수 있습니다 — 인증 없이 노출된 서버가 17만 5천 개라는 현실을 고려하면, 이것 하나만으로도 가장 큰 리스크를 줄일 수 있습니다.
fast-agent를 설치하고 MCP 서버 하나를 연결해볼 수 있습니다 — pip install fast-agent-mcp 후 fastagent.config.yaml에 filesystem 서버를 추가하고 체인 파이프라인을 돌려볼 수 있습니다. Ollama와의 연동이 가장 직관적이어서 첫 시작으로 적합합니다.
동시 연결 수를 모니터링하고 vLLM 전환 기준을 미리 설정해두는 것을 권장합니다 — Nginx 로그나 OpenTelemetry로 레이턴시를 측정하다가, P99 1초를 넘기 시작하면 환경변수 두 개만 바꿔 전환하면 됩니다.

참고 자료

#Ollama#MCP#vLLM#멀티에이전트오케스트레이션#LLM보안#Nginx#fast-agent#Docker#MicrosoftAgentFramework#OpenAI호환API

How to Lock Down Your Team's Ollama Server — Security Configuration, vLLM Migration, and Multi-Agent Orchestration | DEV BAK - 기술블로그

팀 Ollama 서버, 이렇게 잠가야 합니다 — 보안 설정·vLLM 전환·멀티에이전트 오케스트레이션까지

핵심 개념

1. Ollama + MCP: 팀 배포가 왜 생각보다 까다로운가

프로토콜 역할 분담: MCP는 에이전트↔툴 연결을, A2A는 에이전트↔에이전트 통신을 담당합니다. 둘은 경쟁 관계가 아니라 상호 보완 관계입니다.

2. vLLM: 언제 갈아타야 하나

연속 배칭(Continuous Batching): 요청이 들어오는 즉시 배치에 편입해 처리하는 방식. 기존 정적 배칭처럼 배치가 꽉 찰 때까지 기다리지 않아 GPU 활용률이 크게 높아집니다.

단, 단일 요청 레이턴시만 따지면 Ollama가 약 18% 앞섭니다. 동시 사용자가 없는 개발 환경에서는 Ollama가 오히려 더 빠를 수 있습니다.

3. Microsoft Agent Framework vs fast-agent

항목	MAF	fast-agent
성숙도	엔터프라이즈 GA (1.0)	경량·빠른 이터레이션
언어	.NET, Python	Python
MCP 지원	내장 MCP 클라이언트	MCP 네이티브 (완전 구현)
오케스트레이션	Workflow 추상화, 상태 관리	Chain/Parallel/Router/Orchestrator
적합 환경	엔터프라이즈, Azure 연동	빠른 프로토타이핑, 로컬 Ollama

실전 적용

예시 1: 팀 공유 Ollama 보안 아키텍처 구성

권장 아키텍처는 이렇습니다:

[팀원 클라이언트]
      ↓ HTTPS (TLS 1.3)
[Nginx 리버스 프록시]
  - API 키 검증 (Authorization 헤더)
  - Rate Limiting (zone 기반)
  - 접근 로그 수집
      ↓ HTTP (localhost only)
[Ollama 서버: 127.0.0.1:11434]
      ↓
[MCP 툴 실행: Docker 샌드박스]

Nginx 설정의 핵심 부분입니다:

nginx

# /etc/nginx/sites-available/ollama-gateway
limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=10r/m;
 
server {
    listen 443 ssl;
    server_name ollama.internal.your-team.com;
 
    ssl_certificate     /etc/ssl/certs/ollama.crt;
    ssl_certificate_key /etc/ssl/private/ollama.key;
    ssl_protocols       TLSv1.3;
 
    location /api/ {
        # ⚠️ 주의: location 블록 안에서의 if 지시어는 Nginx 공식 문서에서
        # "if is Evil"로 표현하는 안티패턴입니다. proxy_pass와 조합 시
        # 예기치 않은 동작이 생길 수 있습니다. 이 예시는 구조 이해용 데모이며,
        # 프로덕션에서는 auth_request 모듈 또는 OpenResty/Lua 기반 검증을 권장합니다.
        if ($http_authorization != "Bearer ${OLLAMA_API_KEY}") {
            return 401 '{"error": "Unauthorized"}';
        }
 
        limit_req zone=ollama_limit burst=5 nodelay;
 
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
    }
 
    location /admin/ {
        allow 10.0.0.0/8;
        deny all;
    }
}

Ollama 자체는 반드시 127.0.0.1에만 바인딩되도록 설정해야 합니다:

bash

# /etc/systemd/system/ollama.service 또는 .env
OLLAMA_HOST=127.0.0.1:11434
 
systemctl restart ollama

yaml

# docker-compose.yml (MCP 툴 실행 환경)
services:
  mcp-filesystem:
    # ⚠️ 이미지명은 실제 레지스트리에서 확인 필요
    # 대안: command: npx @modelcontextprotocol/server-filesystem /workspace
    image: mcp/filesystem-server:latest
    volumes:
      - ./workspace:/workspace:ro
    networks:
      - mcp-internal
    environment:
      - ALLOWED_PATHS=/workspace
 
  mcp-fetch:
    image: mcp/fetch-server:latest
    networks:
      - mcp-internal
 
networks:
  mcp-internal:
    internal: true

예시 2: vLLM 전환 — 환경 변수 두 개로 끝나는 마이그레이션

bash

# Ollama 사용 시
OPENAI_API_BASE=http://localhost:11434/v1
OPENAI_API_KEY=ollama  # Ollama는 키 값 무관, 형식만 맞추면 됨
 
# vLLM 전환 시 — 바뀌는 것은 이 두 줄뿐
OPENAI_API_BASE=http://your-vllm-server:8000/v1
OPENAI_API_KEY=your-vllm-api-key

vLLM 서버는 Docker로 이렇게 띄울 수 있습니다:

bash

docker run --gpus all \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --max-model-len 4096 \
  --api-key your-vllm-api-key

전환 판단 기준은 다음 표를 참고해볼 수 있습니다:

상황	권장 스택	이유
프로토타입, 1~3명 사용	Ollama 유지	셋업 속도, 단일 요청 레이턴시 유리
동시 사용자 5명 초과	vLLM 전환	연속 배칭으로 큐 적체 해소
레이턴시 SLA가 있는 경우	vLLM 전환	P99 레이턴시 80ms vs 673ms
GPU 서버 운영, 최대 처리량 목표	vLLM	GPU 활용률 최적화 설계
단일 요청 레이턴시가 최우선	Ollama	~18% 우위

예시 3: fast-agent로 MCP 네이티브 멀티에이전트 파이프라인 구성

python

# pipeline.py
from fast_agent import FastAgent
 
app = FastAgent("Research Pipeline")
 
@app.agent(
    name="researcher",
    model="ollama/llama3.2",
    servers=["filesystem", "fetch"],
    instruction="주어진 주제를 웹에서 조사하고 핵심 내용을 요약합니다."
)
async def researcher(agent):
    return await agent("AI 보안 트렌드 2026을 조사하고 요약해줘")
 
@app.agent(
    name="writer",
    model="ollama/llama3.2",
    servers=["filesystem"],
    instruction="전달받은 조사 내용을 개발자 블로그 포스트 형식으로 작성합니다."
)
async def writer(agent):
    return await agent("조사 결과를 바탕으로 블로그 포스트를 작성해줘")
 
# Chain 패턴: researcher 결과가 writer 입력으로 자동 전달
@app.chain(
    name="research_and_write",
    sequence=["researcher", "writer"]
)
async def research_and_write(agent):
    pass
 
async def main():
    async with app.run() as pipeline:
        result = await pipeline.research_and_write.send("AI 보안 트렌드 2026")
        print(result)

MCP 서버 설정 파일은 이렇게 관리할 수 있습니다:

yaml

# fastagent.config.yaml
mcp:
  servers:
    filesystem:
      command: npx
      args:
        - "@modelcontextprotocol/server-filesystem"
        - "./workspace"
    fetch:
      command: uvx
      args:
        - mcp-server-fetch
 
default_model: ollama/llama3.2

예시 4: Microsoft Agent Framework Workflow 패턴

python

# maf_workflow.py
# ⚠️ 실제 패키지명은 공식 문서에서 확인 필요
# (예: microsoft_agents, agent_framework 등)
from microsoft.agent_framework import AgentRuntime, Workflow, Agent
from microsoft.agent_framework.mcp import MCPClientPlugin
 
runtime = AgentRuntime()
runtime.add_plugin(MCPClientPlugin(servers=["filesystem", "fetch"]))
 
@runtime.agent(
    name="analyzer",
    model="ollama/llama3.2",
    instructions="코드 변경사항을 분석하고 보안 리스크를 식별합니다."
)
class AnalyzerAgent(Agent):
    pass
 
@runtime.agent(
    name="reviewer",
    model="ollama/llama3.2",
    instructions="분석 결과를 검토하고 개선 제안을 작성합니다."
)
class ReviewerAgent(Agent):
    pass
 
# 확정적 워크플로: 실행 경로가 고정됨
workflow = Workflow(
    name="code-review-pipeline",
    steps=[
        {"agent": "analyzer", "input": "{{user_input}}"},
        {"agent": "reviewer", "input": "{{analyzer.output}}"},
    ]
)
 
async def main():
    result = await runtime.run_workflow(
        workflow,
        user_input="PR #42의 변경사항을 검토해줘"
    )
    print(result)

장단점 분석

장점

항목	내용
데이터 온프레미스 유지	민감 데이터가 외부 LLM API로 나가지 않음
OpenAI 호환 API	기존 코드 변경 최소화, Ollama↔vLLM 전환 용이
MCP 표준화	6개 이상의 주요 프레임워크 지원, 툴 재사용 가능
빠른 셋업	Ollama 기준 60초 이내 모델 서빙 시작
전환 유연성	환경 변수 2개 변경으로 Ollama → vLLM 마이그레이션 가능

단점 및 주의사항

항목	내용	대응 방안
Ollama 기본 인증 없음	그대로 노출 시 누구나 접근 가능	Nginx/Caddy 리버스 프록시 + API 키 필수
Ollama 낮은 동시성	직렬 처리 기본, 사용자 증가 시 레이턴시 급등	동시 사용자 5명 초과 시 vLLM 전환 검토
프롬프트 인젝션	사용자 입력을 통해 에이전트가 의도치 않은 명령 실행	입력 검증, 샌드박스 실행, Human-in-the-loop
툴 포이즈닝	MCP 서버 툴 정의 변조 시 위험 동작 유발	버전 고정, 서명된 툴 정의 사용
자격증명 노출	설정 파일 내 시크릿이 형상 관리 도구에 노출	환경변수 또는 시크릿 매니저 사용
과도한 권한	에이전트의 파괴적 작업(DB 삭제 등) 무방비 실행	최소 권한 원칙 + Human-in-the-loop 체크포인트

툴 포이즈닝(Tool Poisoning): MCP 서버가 제공하는 툴 정의(이름, 파라미터, 설명)가 악의적으로 변조되어 에이전트가 의도와 다른 위험한 동작을 수행하게 만드는 공격입니다. 2025년 Supabase Cursor 에이전트 사건처럼 지원 티켓을 통한 통합 토큰 유출이 실제 사례로 문서화되어 있습니다.

Human-in-the-loop: 에이전트가 파괴적이거나 되돌리기 어려운 작업(DB 레코드 삭제, 대용량 데이터 전송 등)을 실행하기 전에 반드시 사람의 확인을 거치도록 설계하는 패턴입니다.

실무에서 가장 흔한 실수

OLLAMA_HOST=0.0.0.0으로 직접 바인딩: "사내망이니까 괜찮겠지"라는 생각이 가장 많이 보이는 실수입니다. 반드시 127.0.0.1에만 바인딩하고 앞단에 프록시를 두어야 합니다.
MCP 서버 버전을 latest로 고정: 업스트림에서 툴 정의가 바뀌면 에이전트 동작이 예고 없이 달라집니다. 특정 버전 태그 또는 이미지 다이제스트를 고정하는 것을 권장합니다.
vLLM 전환을 너무 오래 미루기: 전환이 환경변수 두 개라 오히려 결정을 미루게 되는 역설이 있습니다. 동시 사용자가 3~5명을 넘기 시작하는 시점에 미리 vLLM 서버를 준비해두는 편이 훨씬 수월합니다.

마치며

지금 바로 시작해볼 수 있는 3단계:

Ollama를 127.0.0.1에만 바인딩하고 Nginx 게이트웨이를 앞에 붙여볼 수 있습니다 — 인증 없이 노출된 서버가 17만 5천 개라는 현실을 고려하면, 이것 하나만으로도 가장 큰 리스크를 줄일 수 있습니다.
fast-agent를 설치하고 MCP 서버 하나를 연결해볼 수 있습니다 — pip install fast-agent-mcp 후 fastagent.config.yaml에 filesystem 서버를 추가하고 체인 파이프라인을 돌려볼 수 있습니다. Ollama와의 연동이 가장 직관적이어서 첫 시작으로 적합합니다.
동시 연결 수를 모니터링하고 vLLM 전환 기준을 미리 설정해두는 것을 권장합니다 — Nginx 로그나 OpenTelemetry로 레이턴시를 측정하다가, P99 1초를 넘기 시작하면 환경변수 두 개만 바꿔 전환하면 됩니다.

참고 자료

#Ollama#MCP#vLLM#멀티에이전트오케스트레이션#LLM보안#Nginx#fast-agent#Docker#MicrosoftAgentFramework#OpenAI호환API

팀 Ollama 서버, 이렇게 잠가야 합니다 — 보안 설정·vLLM 전환·멀티에이전트 오케스트레이션까지

목차

핵심 개념

1. Ollama + MCP: 팀 배포가 왜 생각보다 까다로운가

2. vLLM: 언제 갈아타야 하나

3. Microsoft Agent Framework vs fast-agent

실전 적용

예시 1: 팀 공유 Ollama 보안 아키텍처 구성

예시 2: vLLM 전환 — 환경 변수 두 개로 끝나는 마이그레이션

예시 3: fast-agent로 MCP 네이티브 멀티에이전트 파이프라인 구성

예시 4: Microsoft Agent Framework Workflow 패턴

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

팀 Ollama 서버, 이렇게 잠가야 합니다 — 보안 설정·vLLM 전환·멀티에이전트 오케스트레이션까지

목차

핵심 개념

1. Ollama + MCP: 팀 배포가 왜 생각보다 까다로운가

2. vLLM: 언제 갈아타야 하나

3. Microsoft Agent Framework vs fast-agent

실전 적용

예시 1: 팀 공유 Ollama 보안 아키텍처 구성

예시 2: vLLM 전환 — 환경 변수 두 개로 끝나는 마이그레이션

예시 3: fast-agent로 MCP 네이티브 멀티에이전트 파이프라인 구성

예시 4: Microsoft Agent Framework Workflow 패턴

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

목차

핵심 개념

1. Ollama + MCP: 팀 배포가 왜 생각보다 까다로운가

2. vLLM: 언제 갈아타야 하나

3. Microsoft Agent Framework vs fast-agent

실전 적용

예시 1: 팀 공유 Ollama 보안 아키텍처 구성

예시 2: vLLM 전환 — 환경 변수 두 개로 끝나는 마이그레이션

예시 3: fast-agent로 MCP 네이티브 멀티에이전트 파이프라인 구성

예시 4: Microsoft Agent Framework Workflow 패턴

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

목차

핵심 개념

1. Ollama + MCP: 팀 배포가 왜 생각보다 까다로운가

2. vLLM: 언제 갈아타야 하나

3. Microsoft Agent Framework vs fast-agent

실전 적용

예시 1: 팀 공유 Ollama 보안 아키텍처 구성

예시 2: vLLM 전환 — 환경 변수 두 개로 끝나는 마이그레이션

예시 3: fast-agent로 MCP 네이티브 멀티에이전트 파이프라인 구성

예시 4: Microsoft Agent Framework Workflow 패턴

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

Ragas와 Ollama로 RAG 파이프라인 품질을 수치로 측정하는 법

SGLang RadixAttention: 동일 문서 블록의 KV 캐시를 재사용해 RAG 파이프라인 처리량을 5배 끌어올리는 방법

vLLM APC vs SGLang RadixAttention: KV 캐시 구조 차이와 워크로드별 선택 기준

Ollama·LangChain으로 API 비용 없이 사내 문서 Q&A 구현 — 하이브리드 검색과 리랭킹으로 프라이버시와 검색 품질을 동시에

Ollama + MCP tool calling 연결 (2026): 로컬 LLM이 파일·Git·DB를 직접 다루는 에이전트 구성

Ollama vLLM 전환은 언제? — 동시 사용자 수로 결정하는 LLM 서빙 선택 기준