#여러 Agent가 같은 MCP 서버를 함께 써도 되는가 — 세션모드·게이트웨이 풀링·인증 격리

← 전체 목차 · 이전: 여러 Agent가 동시에 뛸 때, 중복 실행과 기억 뒤섞임은 어떻게 막는가 · 다음: Agent 하나가 멈췄는데 왜 전체 스케줄링 클러스터가 무너지는가

"같은 MCP Server 인스턴스는 동시에 한 회화의 도구 호출만 처리할 수 있다"는 답은 절반만 맞다. MCP는 모델↔도구/리소스를 잇는 프로토콜(14)이고 A2A와의 경계 판단은 이미 다뤘지만(15), "여러 Agent가 동일 서버를 공유해도 되는가"는 다른 층위의 질문이다 — MCP 서버의 회화 모델(세션 vs 무상태), 연결 풀 유무, 인증이 Agent 단위로 격리됐는가 세 가지에 달려 있다.

#기본값이 막는 것이지 프로토콜이 막는 게 아니다

Agent가 MCP 도구를 호출하는 것은 본질적으로 서버에 하나의 회화 연결을 여는 것이다. 서버는 이 회화를 위해 세 가지를 유지한다 — 도구 목록, 인증 컨텍스트, 호출 상태. 기본값인 유상태 단일 회화 모드에서는:

Agent A 회화 수립 → 도구 호출 실행 중
        ↓
Agent B가 같은 회화에 다시 연결 시도
        ↓
서버가 거부 또는 대기열 진입 → "회화 사용 중" — 흔한 MCP 회화 충돌

이 조건에서 답은 확실히 "안 된다"다. 하지만 이건 프로토콜의 제약이 아니라 기본 설정의 결과다.

#동시성을 여는 두 경로

프로덕션 형태: 통합 MCP 게이트웨이를 세워 Agent별 연결을 독립 관리하고, 인증 정보를 Agent 단위로 바인딩하며, 요청을 후단 여러 MCP 서버 인스턴스로 분배한다. 새 요청은 게이트웨이가 유휴 인스턴스로 바로 라우팅한다. 이렇게 대기열 병목(모든 호출이 서버 하나로 몰림)과 인증 혼선/컨텍스트 오염(여러 Agent가 회화 하나를 공유) 두 사고를 동시에 피한다.

#격리를 안 했을 때: 보이지 않는 월권

회화 격리 미비
  → 여러 Agent가 MCP 연결 하나를 공유
  → A Agent의 인증 정보를 B Agent가 재사용
  → B가 A의 신원으로 "A만 권한 있는" 도구를 호출
  → 월권인데도 에러가 안 남 ← 정적 실패, 가장 발견하기 어려움

고위험 지점은 다중 Agent가 도구 풀을 공유하고 MCP 접속을 통일한 시점이다. 인증 컨텍스트가 연결/회화에 걸려 있고 그 연결이 재사용되면, 신원이 Agent가 아니라 연결을 따라간다. 정답은 인증을 호출 주체(Agent) 단위로 바인딩하는 것이지 연결 단위로 걸어두는 게 아니다.

#판정 순서

0. 공유 대상이 같은 MCP 서버 "인스턴스"인가, 같은 MCP "게이트웨이/접속점"인가 — 결론이 다르다
1. 회화 모드: 유상태(기본, 독점적) vs 무상태(호출 단위 독립)
2. 연결 풀 / 게이트웨이 풀링 유무: 없으면 후속 요청은 거부/대기열
3. 인증 격리: Agent 단위 바인딩(안전) vs 공유 연결에 걸림(A의 자격이 B에게 재사용될 위험)
4. 종합: 세 항목 모두 충족 → 공유 가능 / 유상태+풀링 없음 → 대기열만 가능
   / 공유는 되지만 인증 미격리 → 기술적으로는 되지만 보안상 올리면 안 됨

#핵심 통찰

1. 한계는 대개 기본 설정에서 오지 프로토콜 자체에서 오지 않는다 — MCP는 다중 Agent 동시 접속을 "금지"하는 게 아니라 기본값이 유상태 단일 회화일 뿐이다. "프로토콜이 금지한다"와 "기본 설정이 그렇다"를 구분하는 것이 문서를 읽은 사람과 실제로 붙여본 사람을 가른다.
2. 유상태 회화는 동시성의 첫 번째 천연 병목이다 — 서버가 회화를 위해 도구 목록·인증 컨텍스트·호출 상태 같은 가변 상태를 유지하는 순간, 그 회화는 독점성을 갖고 두 번째 호출자는 반드시 거부되거나 대기한다. 어떤 서비스든 병행 재사용 가능 여부를 판단하려면 먼저 "무슨 회화 상태를 들고 있는가"를 물어야 한다.
3. 동시성 해법은 두 층위 중 하나다: 상태를 없애거나, 위에 한 층을 더 얹거나 — 무상태 모드는 "상태를 사라지게" 하고, 게이트웨이+연결 풀은 "그 위에 격리와 분배를 한 층 더 쌓는" 것이다. 전자는 고빈도·경량·독립적 호출에, 후자는 회화 의미를 유지하면서 여러 호출자를 서비스해야 하는 상황에 맞는다.
4. 연결 격리와 부하분산은 흔히 한 컴포넌트의 양면이다 — 게이트웨이가 회화 ID로 요청을 서버 풀의 다른 인스턴스로 분배하는 동작 자체가 회화를 격리하면서 동시에 부하를 고르게 편다. 같은 컴포넌트가 두 목표를 동시에 달성할 수 있다는 뜻이다.
5. 공유 연결의 가장 위험한 결과는 에러가 아니라 에러가 안 나는 것이다 — A의 인증 정보가 B에게 재사용돼 B가 A 전용 도구를 호출해도 예외가 안 뜬다. 예외를 뱉는 장애는 언젠가 발견되지만 정적 월권은 발견되지 않는다. 따라서 인증 격리의 우선순위는 성능 최적화보다 높아야 한다.
6. 인증은 연결이 아니라 호출 주체에 묶여야 한다 — 인증 컨텍스트가 연결/회화에 걸려 있고 그 연결이 재사용되면, 신원이 연결을 따라가지 Agent를 따라가지 않는다. "Agent별 연결 독립 관리 + 인증을 Agent 단위로 바인딩"이 정답 구조다.
7. 다중 Agent 공유 도구 풀은 월권 문제의 고발생 구역이다 — 공유 정도가 높을수록, 접속이 통일될수록 격리 설계 결함의 대가가 커진다. 통합 접속은 편의를 낮추는 동시에 사고 반경도 넓힌다.
8. "공유 대상이 인스턴스인가 게이트웨이인가"를 먼저 확정하지 않으면 판정 자체가 무의미하다 — 같은 서버 인스턴스를 공유하는 것과 같은 게이트웨이/접속점을 공유하는 것은 결론이 다르다. 판정 순서의 0번 질문으로 먼저 경계를 확정해야 한다.

#엔지니어링 실전 Tips

• 무상태 모드와 게이트웨이 풀링의 적용면을 구분할 것. 고빈도·독립적 호출은 무상태 우선, 회화 의미를 유지해야 하는 다중 Agent 병렬은 게이트웨이 우선.
• 무상태 모드는 두 가지를 동시에 해결한다. 회화 상태 상호 오염 방지와 장기 연결의 자원 점유 방지 — 평가할 때 오염만 계산하지 말고 자원 점유도 같이 셈할 것.
• 게이트웨이의 라우팅 키를 명확히 고를 것. 회화 ID(회화 단위 분배)와 Agent 신원(호출 주체 단위 격리)은 서로 다른 목적이다 — 어느 쪽을 쓰는지 설계 문서에 명시할 것.
• 유휴 인스턴스 라우팅이 대기열 병목의 직접 해법이다. "새 요청은 유휴 인스턴스로 바로 라우팅"을 게이트웨이 라우팅 정책에 명시적으로 둘 것.
• "인증 혼선"과 "컨텍스트 오염"은 한 쌍의 연동 사고로 취급할 것. 여러 Agent가 회화 하나를 공유한 결과로 함께 나온다 — 하나가 보이면 다른 하나도 의심할 것.
• 월권 테스트는 "에러 안 나는 경로"까지 커버할 것. 통상적 에러 모니터링·경보로는 잡히지 않으므로, "B가 A의 신원으로 A 전용 도구를 호출"하는 케이스를 능동적으로 구성해 격리가 실제로 작동하는지 검증할 것.
• MCP 14/15의 감사 4요소(요청자/리소스 범위/작업 상태/에러 경로)를 게이트웨이 계층에도 그대로 적용할 것. 다중 Agent 공유 환경에서는 "요청자"가 연결이 아니라 Agent 신원으로 정확히 기록돼야 사고 조사가 가능하다.