MCP

Archestra 엔터프라이즈 AI 플랫폼: 누구에게 맞는가, 첫 Docker 실행 가이드

셀프 호스팅 환경에서 MCP 연결을 한곳에 모아 받고 싶은 팀이라면 Archestra의 Docker quickstart를 한 번 시험해 볼 만하다. 다만 시작 명령은 호스트의 /var/run/docker.sock을 마운트하고 로컬 데이터 볼륨에 기록하며 archestra/platform:latest는 보통 release candidate가 돈다. 이 두 지점을 받아들이고 나서 시도하라.

Official source · Archestra

Install

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

누구에게 맞는가

  • 공식 포지셔닝은 “올인원 오픈소스 엔터프라이즈 AI 플랫폼”: MCP registry, gateway, orchestrator를 함께 담으며 단일 용도의 MCP server가 아니다. 어울리는 형태는 팀이 자기 장비에 플랫폼을 직접 호스팅하고 사용자, agent, Claude / Codex / Cursor 클라이언트를 같은 URL 하나로 통일하는 것. 도구 호출은 플랫폼이 일괄 처리하고 클라이언트는 입구 하나만 알면 된다.
  • MCP gateway는 OAuth + On-Behalf-Of를 사용해 도구가 공유 서비스 계정이 아니라 사용자 본인 신분으로 실행된다. 호출마다 사람에게 귀속되기를 중요하게 보는 팀이 명확한 수혜자다.
  • 판단 기준: 문제가 “어떤 클라이언트에 도구 하나가 없다”뿐이라면 단일 MCP server면 충분하다. 여러 서비스, 여러 클라이언트, 여러 신원을 하나로 관리할 때 비로소 플랫폼 층이 필요하다.
  • 맞는 환경: 로컬이나 사내망에서 Docker를 돌릴 수 있고 소켓 마운트 비용을 평가할 의지가 있는 팀. quickstart는 포트를 루프백 주소에 묶으므로 단일 장비에서 먼저 시험하고 부작용을 받아들인 뒤 장기 운행으로 넘어가기 적합하다.
  • 실행 전제: 장비에 Docker가 있어야 한다. 증거에는 최소 리소스 구성, 지원 OS 범위, Docker 외 실행 방식이 없어 모두 확인되지 않았다.

3분 만에 첫 시험

  • 실행 전에 공식이 명시한 두 가지 부작용을 받아들이는지 확인하라. 첫째, 명령은 호스트의 /var/run/docker.sock을 마운트해 컨테이너가 호스트의 Docker 데몬을 조작할 수 있게 된다. 둘째, 이미지의 latest 태그는 최신 release를 가리키며 보통 release candidate가 돈다. 두 지점은 공식 설명에 적혀 있고 평가 단계부터 반영할 사안이지 배포 뒤에 처리할 세부사항이 아니다.
  • 첫 시작은 읽기 전용 작업도 아니다. 네임드 볼륨 archestra-postgres-data와 archestra-app-data가 데이터베이스와 앱 데이터를 로컬 Docker 볼륨에 기록한다. 공식 cleanup/취소 명령은 없고 반복 실험 사이에 오래된 데이터가 새 시작에 영향을 주는지도 증거에 없으니, 중요한 데이터가 있는 호스트에서 가볍게 시도하지 마라.
  • 받아들였다면 공식 빠른 시작 명령을 실행하라:
docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest
  • 확인 가능한 성공 신호는 여기까지다: 컨테이너가 계속 떠 있고 두 포트가 127.0.0.1 루프백 주소에만 묶여 있다. quickstart가 명시하는 설정은 ARCHESTRA_QUICKSTART=true와 이 포트·마운트 조합이 전부다. 루프백 묶음이라 기본적으로는 로컬 장비만 접근 가능하며 원격 접속 구성 방법은 증거에 없다.
  • 다음 단계는 Claude / Codex / Cursor를 이 URL 하나로 향하게 하는 것. URL의 구체적 값은 명령에 없고 플랫폼이 뜬 뒤 플랫폼 쪽에서 확인해야 한다. 첫 로그인 절차도 마찬가지로 언급되어 있지 않다.

사용 사례

  • 사례 1: 다중 클라이언트 통일 입구. 상황: 팀에서 Claude, Codex, Cursor를 함께 쓰는데 클라이언트마다 MCP를 따로 연결하고 싶지 않다. 방법: 위 절차대로 플랫폼을 빠르게 띄우고 클라이언트를 Archestra의 같은 URL로 향하게 한다. 기대: 도구 호출이 MCP gateway를 거쳐 사용자 본인 신분으로 실행되고 같은 도구가 세 클라이언트에서 같은 입구로 흐른다. 경계: 플랫폼이 구체적으로 어떤 서비스를 받을 수 있는지 목록이 증거에 없으니 연결 전에 필요한 서비스가 포함됐는지 확인하라.
  • 사례 2: 공유 서비스 계정에 남기지 않기. 상황: 모든 도구 호출이 공유 서비스 계정 명의로 기록되는 것을 팀이 받아들이지 않는다. 쓰는 것은 gateway의 같은 신원 메커니즘이다. 방법: 연결 뒤 도구가 사용자 본인 신분으로 도는지 확인한다. 지금 공유 계정으로 자동화를 돌린다면 전후 비교가 가능하다. 확인 가능한 것: 공식 설명이 그렇다는 것까지. 계정 설정 화면과 호출 로그의 생김새는 증거에 없으니 존재를 전제하지 마라.
  • 두 사례의 차이: 사례 1은 입구 통일을, 사례 2는 신원 귀속을 검증한다. 순서대로 한 번씩 시험해 보면 된다.

사용 경계

  • 읽기·쓰기 성격: 첫 시작부터 로컬 상태를 기록한다(네임드 볼륨 2개). 소켓 마운트로 컨테이너가 호스트의 컨테이너를 조작할 수 있는 것이 가장 무거운 부작용이며 평가 때 따로 검토해야 한다.
  • 자격증명과 신원: gateway는 OAuth에 의존한다. 공급자 구성 방법이나 신원 소스 연결이 필수인지는 증거에 설명이 없어 확인되지 않았다.
  • 클라이언트와 플랫폼의 관계: 공식 입장은 사용자, agent, 클라이언트를 URL 하나로 향하게 하고 나머지는 플랫폼에 맡기는 것. 각 클라이언트에 필요한 버전이나 플러그인은 증거에 없다.
  • 버전 경계: 공식 입장은 프로덕션 배포에 정확한 버전 태그를 고정해야 한다는 것. latest는 보통 release candidate에 해당하니 정식 부하에 그대로 쓰지 마라.
  • 행동 순서: 소켓 마운트와 버전 두 가지를 먼저 받아들이고 명령을 실행하라. 첫 시험은 로컬 루프백 환경에서 끝내고 바로 공개 네트워크에 열지 마라.
  • 아직 확인되지 않은 핵심 정보: 리소스 사용량, 업그레이드·롤백 절차, 데이터 백업 방식, 플랫폼 내 각 MCP 도구의 읽기·쓰기 선언, 초기 자격증명 정책은 증거에 모두 없다. 첫 시험 환경에 실제 데이터를 넣지 마라. 설명을 찾지 못한 것이 위험이 없다는 뜻은 아니며 결론은 공식 문서를 따른다.