Docker로 띄운 Ollama·Qdrant·Redis는 기본 인증이 없습니다

핵심 요약

먼저 알아 둘 용어

6월 노트의 compose 예시가 연 포트

6월 노트는 Ollama·Qdrant·PostgreSQL·Redis를 한 compose 파일로 띄우는 예시를 실었습니다. 다섯 포트를 모두 "11434:11434"처럼 호스트 IP 없이 공개했습니다. Docker Compose 파일 참조는 호스트 IP를 지정하지 않으면 “모든 네트워크 인터페이스(0.0.0.0)에 바인드한다”고 적었습니다. 서비스별 기본값은 아래와 같습니다.

“모든 인터페이스에 열린다”가 곧 인터넷에 열린다는 뜻은 아닙니다. 실제로 어디까지 닿는지는 머신이 놓인 네트워크와 방화벽에 달려 있습니다. 문서가 밝힌 조건은 이렇습니다.

• Docker Engine(리눅스): 포트 공개 문서는 “Publishing container ports is insecure by default”라고 적고, 공개한 포트가 Docker 호스트뿐 아니라 외부에서도 접근 가능해진다고 설명합니다. 방화벽 문서에 따르면 Ubuntu의 ufw 규칙보다 Docker의 전달 규칙이 먼저 적용되므로, ufw로 막았다고 생각한 포트도 열려 있을 수 있습니다.
• Docker Desktop(macOS·Windows): 네트워킹 문서는 docker run -p가 기본으로 모든 인터페이스(0.0.0.0)에서 연결을 받는다고 적었습니다. Docker Desktop 네트워크 설정에서 기본 바인드를 localhost로 바꿀 수 있고, 호스트 방화벽은 com.docker.backend를 기준으로 연결을 거를 수 있습니다.
• Qdrant 문서의 단서: 로컬 개발 머신에는 대개 외부 접근을 막는 방화벽이 있지만, 공개 VPS나 전용 서버에서는 그렇지 않을 수 있다고 적었습니다. 같은 compose 파일을 클라우드 서버에 그대로 올리면 위험이 커집니다.

포트를 127.0.0.1에만 여는 compose 예시

아래는 6월 노트의 구성을 유지하면서 문서가 권하는 설정만 바꾼 예시입니다. 비밀값은 같은 폴더의 .env 파일에서 읽고, Redis 비밀번호만 설정 파일(./redis/redis.conf)에 둡니다. 이 블로그에서 실행해 보지는 않았고, 각 줄은 해당 공식 문서의 형식을 따랐습니다.

services:
  ollama:
    image: ollama/ollama
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama:/root/.ollama

  qdrant:
    image: qdrant/qdrant
    ports:
      - "127.0.0.1:6333:6333"
      - "127.0.0.1:6334:6334"
    environment:
      QDRANT__SERVICE__API_KEY: ${QDRANT_API_KEY}
    volumes:
      - qdrant:/qdrant/storage

  postgres:
    image: postgres:18
    ports:
      - "127.0.0.1:5432:5432"
    environment:
      POSTGRES_USER: ai
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: aidb
    volumes:
      - postgres:/var/lib/postgresql

  redis:
    image: redis:8
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    ports:
      - "127.0.0.1:6379:6379"
    volumes:
      - ./redis:/usr/local/etc/redis

volumes:
  ollama:
  qdrant:
  postgres:

# .env  (git에서 제외)
QDRANT_API_KEY=긴_임의_문자열
POSTGRES_PASSWORD=긴_임의_문자열

# ./redis/redis.conf  (git에서 제외)
requirepass 긴_임의_문자열

• 127.0.0.1 바인드: Docker 문서는 공개 플래그에 127.0.0.1(또는 ::1)을 넣으면 Docker 호스트만 그 포트에 접근할 수 있다고 적었습니다. 단 28.0.0 이전 Docker Engine에서는 같은 L2 네트워크 구간(같은 스위치에 연결된 머신처럼 라우터를 거치지 않고 바로 통신하는 범위)의 다른 호스트가 localhost에 공개한 포트에 접근할 수 있었다고 경고합니다. docker version으로 Engine 버전을 먼저 확인하세요.
• 컨테이너끼리만 쓰는 포트는 공개하지 않아도 됩니다. Compose 네트워킹 문서에 따르면 같은 compose 파일의 서비스는 기본 네트워크에서 서비스 이름(qdrant:6333)으로 서로 접근합니다. 호스트 포트는 Compose 기본 네트워크 밖에서 접근할 때만 쓰입니다. 앱을 호스트에서 uv run으로 실행한다면 위처럼 127.0.0.1로 공개합니다.
• Qdrant API 키: QDRANT__SERVICE__API_KEY를 설정하면 모든 요청에 api-key 헤더가 필요합니다. 조회만 하는 쪽에는 읽기 전용 키(QDRANT__SERVICE__READ_ONLY_API_KEY, 1.7.0부터)를 따로 줄 수 있습니다. Qdrant 문서는 키를 암호화되지 않은 연결로 보내면 유출될 수 있으므로 TLS를 함께 쓰라고 적었습니다. 호스트 밖에 열 계획이라면 TLS가 필요합니다.
• Redis 비밀번호: 공식 이미지 문서는 Redis를 외부에 열 계획이라면 설정 파일로 비밀번호를 지정하라고 권하고, 위처럼 redis.conf가 든 폴더를 /usr/local/etc/redis에 마운트해 redis-server에 넘기는 방법을 안내합니다. 위 예시처럼 ./redis/redis.conf에 requirepass 줄로 비밀번호를 적고, 이 파일은 .env처럼 git에서 제외합니다. 이 줄을 빼면 Redis는 127.0.0.1에서도 비밀번호 없이 열립니다.
• PostgreSQL 18의 볼륨 위치: 공식 이미지는 18부터 PGDATA를 /var/lib/postgresql/18/docker로 바꾸고 볼륨을 /var/lib/postgresql에 선언했습니다. 6월 노트처럼 postgres:16을 쓴다면 이전 위치(/var/lib/postgresql/data)에 마운트해야 데이터가 남습니다.
• macOS에서 Ollama: Ollama의 macOS 문서는 Apple M 시리즈에서 CPU와 GPU를 모두 지원한다고 적었습니다. 반면 Docker 문서에는 CPU 전용 실행과 NVIDIA·AMD GPU 실행 방법만 있습니다. macOS에서는 앱으로 설치하는 편이 문서의 설명과 더 잘 맞습니다. 이 경우 Ollama는 127.0.0.1에 바인드하므로 compose에서 ollama 서비스를 빼면 됩니다.

띄운 뒤에는 docker compose ps의 PORTS 열이 127.0.0.1:6333->6333/tcp처럼 루프백 주소로 시작하는지 확인합니다. 0.0.0.0:으로 시작하는 줄이 있으면 그 포트는 모든 인터페이스에 열린 것입니다.

같은 머신의 코딩 에이전트가 이 서비스에 닿는 경로

127.0.0.1 바인드는 다른 머신을 막지만 같은 머신의 프로세스는 막지 않습니다. 코딩 에이전트가 실행하는 테스트와 스크립트도 같은 머신의 프로세스입니다. 두 에이전트의 기본값은 서로 다릅니다(공식 문서, 2026-10-06 확인).

Codex 문서에는 2026-10-06 기준으로 바뀐 점이 하나 있습니다. approval_policy = "untrusted"가 폐지되어, 이 값이 설정 파일에 남아 있으면 Codex가 시작하지 못할 수 있습니다. 문서는 대신 ~/.codex/config.toml의 프로젝트 항목에 trust_level = "untrusted"를 두면 명령마다 승인을 요구하는 동작을 유지할 수 있다고 안내합니다.

MCP 서버를 붙일 때 확인할 기본값

Claude Code의 MCP 설정 범위와 승인

Claude Code MCP 문서, 2026-10-06 확인. 확인 시점의 최신 버전은 2.1.290(2026-10-05)입니다.

• 승인 창은 대화형 세션에서만 뜹니다. 문서는 .mcp.json의 프로젝트 범위 서버를 쓰기 전에 대화형 세션에서 승인을 묻는다고 적었습니다. 반면 claude -p 실행, Agent SDK 세션, 클라우드 세션에서는 승인 창을 띄울 수 없어 묻지 않고 불러옵니다. CI나 자동화에서 남의 저장소를 다룬다면 disabledMcpjsonServers로 막거나, --strict-mcp-config와 --mcp-config로 쓸 서버만 지정합니다.
• 저장소가 스스로 승인할 수는 없습니다. 2.1.196부터는 작업 폴더 신뢰 창을 수락하기 전이면, 저장소에 커밋된 .claude/settings.json의 enableAllProjectMcpServers·enabledMcpjsonServers를 무시합니다.
• API 키는 .mcp.json에 적지 않습니다. .mcp.json은 command·args·env·url·headers에서 ${VAR}와 ${VAR:-기본값} 형식을 환경 변수 값으로 치환합니다. 예를 들어 "Authorization": "Bearer ${API_KEY}"처럼 적고 값은 각자의 환경에 둡니다.

MCP 도구 정의: 6월 노트 예시의 필드 이름

6월 노트는 MCP 도구 예시에 input_schema를 썼습니다. MCP 명세의 필드 이름은 inputSchema입니다. input_schema는 Anthropic Messages API의 도구 정의 형식이고, MCP 명세(2026-07-28 판) 도구 문서에는 한 번도 나오지 않습니다. 명세 형식으로 고치면 이렇습니다.

{
  "name": "search_documents",
  "description": "문서 컬렉션에서 관련 근거를 검색합니다. 삭제나 수정은 하지 않습니다.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {"type": "string"},
      "collection": {"type": "string"},
      "top_k": {"type": "integer", "minimum": 1, "maximum": 20}
    },
    "required": ["query", "collection"]
  },
  "annotations": {"readOnlyHint": true}
}

• 어노테이션(annotations)은 선택 항목이고 힌트일 뿐입니다. 도구 정의에서 inputSchema는 필수이지만 어노테이션은 선택입니다. 명세 스키마에서 readOnlyHint의 기본값은 false이고, 읽기 전용이 아닐 때 destructiveHint의 기본값은 true입니다. 명세는 클라이언트가 신뢰하는 서버가 아니면 어노테이션을 믿지 말아야 한다(MUST)고 적었습니다.
• Codex는 이 어노테이션을 승인 판단에 씁니다. Codex 문서에 따르면 도구가 파괴적(destructive) 어노테이션을 선언하면 MCP 도구 호출에 항상 승인을 요구합니다. 읽기(read) 어노테이션이 함께 있으면 읽기 쪽이 우선합니다.
• 사람의 확인은 명세가 권하는 기본입니다. 명세 도구 문서는 사용자가 도구 호출을 거부할 수 있도록 사람이 개입해야 한다(SHOULD)고 적었습니다. 읽기 도구와 쓰기 도구를 서로 다른 서버나 다른 키로 나누면, 위의 Qdrant 읽기 전용 키처럼 서버 쪽에서도 권한을 줄일 수 있습니다.

6월 노트에서 바꾼 것

MCP 서버의 실제 동작을 다룬 측정은 에이전트에 bash만 주면 어떻게 되는가에, 에이전트 샌드박스의 격리 방식은 에이전트 샌드박스 세 층에 따로 정리했습니다.

체크리스트

1. docker compose ps의 PORTS 열을 보세요. 0.0.0.0:으로 시작하는 줄이 있으면 compose 파일의 ports:에 127.0.0.1:을 붙입니다.
2. Docker Engine 버전이 28.0.0 이상인지 확인하세요. 그 전 버전에서는 같은 L2 구간의 다른 호스트가 localhost에 공개한 포트에 접근할 수 있었습니다.
3. Qdrant에 API 키를, Redis에 비밀번호를 설정하세요. 127.0.0.1에 묶어도 같은 머신의 프로세스와 코딩 에이전트는 닿습니다. 조회만 하는 앱과 MCP 서버에는 Qdrant 읽기 전용 키를 줍니다.
4. 비밀번호를 compose 파일과 .env.example에 적지 마세요. ${POSTGRES_PASSWORD}처럼 .env에서 읽고, .env는 git에서 제외합니다.
5. Claude Code에서 샌드박스를 켤 계획이라면 allowLocalBinding과 자격 증명 읽기 범위를 함께 정하세요. 기본 읽기 범위에는 ~/.ssh 같은 파일이 포함됩니다. 샌드박스가 필수라면 failIfUnavailable을 켭니다.
6. 저장소의 .mcp.json을 승인하기 전에 내용을 읽으세요. 자동화(claude -p, Agent SDK)에서는 승인 창 없이 불러오므로 --strict-mcp-config나 disabledMcpjsonServers로 범위를 정합니다.
7. Codex 설정 파일에서 approval_policy = "untrusted"를 찾아 지우세요. 폐지된 값이라 Codex가 시작하지 못할 수 있습니다.
8. 직접 만든 MCP 도구는 inputSchema로 정의하고, 동작 성격을 어노테이션으로 밝히세요. 어노테이션은 선택 항목이지만, 조회 도구에 readOnlyHint: true를 붙이고 지우거나 고치는 도구는 destructiveHint를 기본값(true)대로 두면 Codex 같은 클라이언트가 승인 판단에 씁니다.

아직 결론이 아닌 것

• 이 글은 2026-06-16 초기 노트를 2026-10-06에 현재 기준으로 다시 쓴 것입니다. 6월 노트는 출처 없이 도구 추천과 설치 명령을 모은 글이었고, 이번 판은 공식 문서로 확인할 수 있는 기본값만 남겼습니다.
• 직접 측정하지 않았습니다. compose 예시를 실행하거나, 다른 기기에서 포트에 접속해 보거나, 에이전트 샌드박스에서 localhost 접근을 시험하지 않았습니다. 모든 동작은 공식 문서에 적힌 대로 옮겼습니다.
• “모든 인터페이스에 열린다”가 실제 노출 범위를 뜻하지는 않습니다. 공유기, 사내망, 클라우드 보안 그룹, 호스트 방화벽에 따라 실제로 접근할 수 있는 범위가 달라집니다. 이 글은 각 문서가 밝힌 기본값만 다룹니다.
• macOS에서 Ollama를 앱으로 설치하라는 권고는 문서를 대조한 추론입니다. Ollama 문서가 “Docker에서는 Apple GPU를 쓸 수 없다”고 직접 적은 것은 아니며, Docker 문서에 Apple GPU 실행 방법이 없다는 것만 확인했습니다.
• Codex 샌드박스의 읽기 범위와 샌드박스를 쓸 수 없을 때의 동작은 확인하지 않았습니다. 표의 빈칸은 확인하지 않은 칸입니다.
• 버전과 설정 키는 빨리 바뀝니다. Claude Code는 거의 매일 새 버전을 내고, Codex 문서는 확인 시점에 learn.chatgpt.com으로 옮겨져 있었습니다. 2026-10-06 이후의 변경은 반영하지 않았습니다.

참고자료

모든 문서는 2026-10-06에 열어 원문을 대조했습니다. 가능한 곳은 Markdown 원본이나 GitHub의 문서 원본을 받아 확인했습니다.

2026-06-16 초기 노트를 2026-10-06에 현재 기준으로 다시 썼습니다. 처음 판의 도구 추천표·권장 사양·설치 명령은 근거가 없어 뺐고, compose 예시와 MCP 도구 예시는 공식 문서에 맞게 고쳤습니다. 문서가 바뀌면 이 글을 고치고 개정 날짜를 적겠습니다.