MCP 서버는 1C, 코드 에디터, 그리고 게임 애플리케이션을 동일한 클라이언트로 만드는 것이 아닙니다. 이들은 서로 다른 데이터, 서로 다른 권한, 그리고 서로 다른 오류 비용을 가집니다. 1C 회계 데이터베이스에서의 잘못된 SELECT는 게임 샌드박스에서의 불필요한 생성 실행보다 훨씬 더 큰 비용을 초래합니다. 따라서 "클라이언트가 MCP를 지원한다"라는 문구는 호환성 계약이 아니라, 단지 공통된 프로토콜 사전을 사용하겠다는 신청에 불과합니다.

아래 내용은 프로토콜 마케터가 아닌 통합 아키텍트(Integration Architect)가 분석합니다. 독자의 과제는 간단하면서도 엄격합니다. 직접 검증하지 않은 호환성을 시스템에 약속하지 않는 것입니다. 본문에는 "시스템-프로토콜-권한-상태" 지도가 수록되어 있으며, 각 조합을 확인됨(Confirmed), 적응 가능함(Adaptable), 또는 확인되지 않음(Unverified)으로 분류할 수 있는 '3가지 상태 규칙'이 포함되어 있습니다. 오직 첫 번째 카테고리만이 연결 가능합니다.

두 시스템 간에 MCP라는 용어가 일치한다는 것은 단지 두 시스템 모두 Model Context Protocol을 통해 대화할 수 있음을 의미할 뿐입니다. 이는 어떤 전송 방식(Transport)이 사용되는지, 어떤 권한이 부여되었는지, 그리고 채널 장애 시 어떤 일이 발생하는지에 대해서는 아무것도 말해주지 않습니다. MCP라는 브랜드가 아니라, 바로 이 세 가지 요소가 연결의 안전성을 결정합니다.

왜 MCP라는 단어가 호환성 계약이 아닌가?

권한 모델이 결정되는 기준인 전송 방식(Transport)부터 시작하겠습니다. MCP 사양(modelcontextprotocol.io, 2026-07-18 접속)은 정확히 두 가지 표준 클라이언트-서버 전송 방식을 정의합니다: stdio(stdin/stdout을 통한 서브프로세스)와 Streamable HTTP입니다. 사양의 문구에 따르면 클라이언트는 가능한 경우 stdio를 지원해야(SHOULD) 합니다. 여기서 이미 불편한 결론이 도출됩니다: "MCP 지원" 그 자체만으로는 어떤 전송 방식을 사용하는지 알려주지 않으며, 따라서 특정 "클라이언트-시스템" 쌍이 어떤 권한 모델을 사용하는지도 알 수 없습니다.

다음은 인증(Authorization) 단계입니다. 인증 페이지에 대해 (이것은 2026-07-18 기준 현재 초안(draft) 버전의 명세서입니다), MCP에서 인증은 선택 사항(OPTIONAL)입니다. HTTP 전송(HTTP-transports)은 OAuth 2.1 흐름을 따라야 하며(SHOULD), stdio 전송(stdio-transports)은 이 명세를 전혀 따를 필요가 없으며(SHOULD NOT) 대신 로컬 환경(local environment)에서 직접 자격 증명(credentials)을 가져옵니다. 실질적인 의미는 다음과 같습니다: "인증된" stdio 연결과 "인증된" HTTP 연결은 동일한 메커니즘이 아니라 구조적으로 서로 다른 권한 메커니즘을 통해 검증된다는 것입니다. 한쪽의 신뢰를 다른 쪽으로 전이할 수 없습니다.

벤더에 의존하지 않는 프로토콜 수준의 거부 모드(protocol-level rejection mode)도 존재합니다. Streamable HTTP 섹션에서 명세서는 다음과 같이 직접 경고합니다: 서버는 DNS 리바인딩 공격(DNS-rebinding-attacks)을 방지하기 위해 반드시(MUST) Origin 헤더를 검증해야 하며, 로컬 실행 시에는 localhost만 수신해야 하고(SHOULD), 모든 연결에 대해 인증을 구현해야 합니다(SHOULD). 이는 특정 클라이언트의 문제가 아니라 전송 계층(transport level)의 취약점입니다. 만약 HTTP 전송을 선택하고 Origin 검증을 누락했다면, 반대편의 IDE나 1C 서버가 아무리 훌륭하더라도 보안 구멍(vulnerability)은 발생합니다.

MCP 클라이언트의 이면에 있는 모델은 연결 프로토콜과는 별개의 선택 사항입니다. 모델을 변경한다고 해서 전송 계층이나 MCP 서버 자체의 권한이 검증되는 것은 아니며, 그 반대도 마찬가지입니다. 따라서 이 두 가지 결정은 한 번에 처리할 것이 아니라 별도로 내려야 합니다.

mcp-1c의 사례로 보는 검증 가능한 결합 방식은?

지도가 추상적인 개념으로만 남지 않도록 1C를 위한 구체적인 구현 사례를 살펴보겠습니다. mcp-1c 서버(github.com/feenlace/mcp-1c)는 stdio를 통해 MCP 클라이언트와 통신하지만, 별도로 게시된 1C:Enterprise의 HTTP 서비스(Apache 또는 IIS를 통해)로 연결해 주는 단일 Go 바이너리(Go-binary)입니다. 이 HTTP 서비스를 위해 --user/--password(또는 MCP_1C_USER/MCP_1C_PASSWORD 환경 변수)를 통한 선택적 Basic 인증을 지원합니다. 별도의 --db-user/--db-password는 구성 확장(configuration extension)을 내장하는 일회성 단계인 --install 명령에만 필요합니다. 즉, 이 결합 방식은 서로 다른 적용 범위(scope)를 가진 두 가지의 서로 다른 자격 증명 세트를 가지며, 이를 혼동해서는 안 됩니다.

여기서 권한의 최소 표면(minimal surface of rights)은 명확합니다. mcp-1c의 execute_query 도구는 요청을 SELECT/ВЫБРАТЬ로 명시적으로 제한하며, 실행 없이 구문만 확인하기 위한 별도의 validate_query가 존재합니다. 일반적인 도구 사용을 통해서는 어떠한 쓰기 작업도 노출되지 않습니다. 이는 이 결합 방식에 필요한 최소한의 권한이 1C 데이터베이스의 메타데이터 및 쿼리에 대한 읽기 전용 접근 권한만으로 충분함을 의미합니다. 이는 실무에서 "최소 권한"이 어떻게 구현되는지를 보여주는 좋은 사례입니다. 즉, "1C에 대한 접근"이 아니라 "중간 HTTP 서비스를 통한 특정 데이터베이스에 대한 읽기 전용(read-only) 쿼리"인 것입니다.

이러한 결합을 위한 stdio 클라이언트 설정은 간결하며, 권한이 정확히 어디에 위치하는지 즉시 확인할 수 있습니다:

{
  "mcpServers": {
    "mcp-1c": {
...

이러한 결합 방식조차 귀하의 데이터베이스에서 검증하기 전까지는 "확정된(proven)" 것이라고 부를 수 없습니다. 명세(specification)와 README는 계약(contract)을 설명하지만, 상태는 이러한 최소 권한과 명확한 거부 경계(boundary of refusal)를 가진 연결이 검증된 후에야 부여됩니다. 검증 전까지 이 방식은 정직하게 "적응 가능한(adaptable)" 상태라고 불립니다. 즉, 계약은 알려져 있지만 귀하의 환경에 대한 적용 가능성은 아직 확인되지 않은 상태입니다.

1C는 권한 측면에서 IDE나 게임과 어떻게 다른가?

이제 동일한 MCP라는 단어를 사용하는 인접 시스템들을 살펴보고, 이들의 권한 모델이 일치하는지 확인해 보겠습니다. 결론부터 말씀드리면, 일치하지 않으며 이것이 핵심 논지입니다.

1C를 위한 두 번째 서버는 동일한 도메인 내에서도 격차가 존재함을 보여줍니다. Infostart MCP는 (mcp-1c처럼 stdio + HTTP 서비스 조합이 아닌) SSE 또는 HTTP 트랜스포트 (transport)를 사용하며, 프라이빗 레지스트리(docker.f-pix.ru)에 대한 Docker 인증과 메타데이터 기반 RAG (Retrieval-Augmented Generation) 검색을 위한 벡터 데이터베이스 Qdrant 및 임베딩 (embedding) 서비스에 대한 네트워크 액세스를 요구합니다. 이 서버는 1C:EDT를 지원하지 않는다고 명시적으로 밝히고 있습니다. 동일한 도메인 레이블을 가진 두 개의 "1C MCP 서버"가 서로 호환되지 않는 연결 요구 사항을 가지고 있는 것입니다. 만약 당신이 하나를 선택하고 두 번째 서버의 설정도 동일할 것이라고 판단했다면, 첫 번째 명령을 내리기도 전에 이미 틀린 것입니다.

게임 엔진은 세 번째 동의 모델을 추가합니다. Unity의 공식 MCP 서버(Unity AI Assistant 패키지)는 stdio를 통해 로컬 릴레이 (relay) 바이너리에 연결되며, 이 바이너리는 IPC (Inter-Process Communication, 명명된 파이프 또는 Unix 소켓)를 통해 Unity 에디터와 통신합니다. 이 모델은 "AI Gateway connections" (사용자 개입 없이 자동 승인됨)와 "direct connections" (Project Settings의 대화를 통해 명시적 동의가 필요함)를 구분합니다. 이는 1C의 SELECT 제한이나 그 어떤 OAuth 흐름과도 관련이 없는 이중 계층 동의 모델입니다. 여기서 출처의 주의 사항이 중요합니다: 검증된 것은 바로 Unity 번들(bundle)이며, mcp-unity와 같은 커뮤니티 대안들은 다른 트랜스포트와 권한을 가지고 존재하며 본 분석에서는 심층적으로 검증되지 않았습니다. 이 사실 관계 집합 내에서 Unity를 제외한 다른 게임 MCP 서버는 확인되지 않았습니다.

코드 편집기 클라이언트(Clients-editors)는 또 다른 계층을 형성하며, 클라이언트를 시스템과 혼동해서는 안 됩니다. Cursor는 세 가지 MCP 연결 방식을 문서화하고 있습니다: stdio (로컬, 단일 사용자), SSE 및 Streamable HTTP (원격, 다중 사용자)이며, 각 방식에 따라 인증 방식이 다릅니다. 즉, 로컬 stdio의 경우 수동 자격 증명(manual credentials)을 사용하는 반면, 원격 HTTP/SSE는 OAuth를 사용합니다. 기본적으로 Cursor는 서버나 도구가 기업용 MCP 허용 목록(Allowlist)에 등록되어 있지 않은 경우, MCP 도구 인자(arguments)의 호출마다 승인을 요구합니다. 더욱이, Cursor의 자체 보안 권장 사항은 모든 MCP 서버의 출처를 확인하고, 해당 서버가 어떤 데이터와 API에 접근할 수 있는지 검토하며, 설치 전 최소 권한을 가진 키를 사용할 것을 직접적으로 지시합니다. 이는 주요 클라이언트 벤더의 명확한 입장 표명입니다: 신뢰와 서버의 범위는 MCP 브랜드에서 유도되는 것이 아니라, 각 서버별로 검증되어야 한다는 것입니다.

Claude Code는 승인 여부가 서버 간에 전송되지 않는다는 점을 보여줍니다. 이 시스템의 권한은 도구 유형에 따라 다층적입니다: 작업 디렉토리 내의 읽기 전용(read-only) 도구(파일 읽기, grep)는 확인을 요구하지 않지만, Bash는 내장된 읽기 전용 명령 세트를 제외하고는 확인을 요구하며, 파일 수정은 항상 확인을 거쳐야 합니다. 허용/거부/질문(allow/deny/ask) 규칙은 mcp__<server>__<tool> 이름 템플릿을 통해 각 MCP 서버와 도구별로 설정됩니다. 하나의 MCP 서버 도구에 부여된 권한은 다른 서버나 클라이언트로 확장되지 않습니다. 이는 '한 번 설정하면 어디서든 작동한다'는 순진한 아이디어를 깨뜨리는 바로 그 특성입니다.

왜 하나의 요청이 서로 다른 시스템으로 이어지는가?

사용자들은 검색을 통해 이 문제에 도달하며, 검색어(query) 자체만으로도 훌륭한 회귀 샘플(regression sample)이 됩니다. 즉, "AI 연결하기"라는 하나의 의도가 서로 호환되지 않는 시스템들로 어떻게 분산되어 있는지를 보여줍니다. 이러한 요청들을 하나의 픽스처(fixture)로 모아보면, 브랜드와 계약(contract) 사이의 간극이 명확하게 드러납니다.

이러한 픽스처가 실무에서 유용한 이유는 다음과 같습니다. 구성(configuration) 단계에 도달하기 전, 입력 단계에서 호환성에 대한 잘못된 약속을 포착해 냅니다. 실제 사용되는 문구들을 분석해 보면, 하나의 동사 뒤에 서로 다른 클라이언트, 서로 다른 데이터, 그리고 서로 다른 오류 비용(cost of error)이 존재한다는 것을 즉시 알 수 있습니다.

• IDE 계열: как подключить ии к vs code(VS Code에 AI를 연결하는 방법)라는 요청과 그 무료 버전인 как подключить нейросеть к vs code бесплатно(VS Code에 신경망을 무료로 연결하는 방법)는 Cursor나 Claude Code와 유사한 권한 모델을 가진 에디터 클라이언트로 이어지며, 여기서는 도구(tool)를 호출할 때마다 승인이 필요합니다.
• 1C 계열: mcp серверы для вайб кодинга в 1с(1C를 위한 바이브 코딩용 MCP 서버)는 mcp-1c와 같은 읽기 전용(read-only) 연결이나, Docker 및 Qdrant를 사용하는 Infostart의 RAG 스택으로 이어집니다. 이는 하나의 도메인 용어 아래 존재하는 두 가지 서로 다른 구성입니다.
• 게임 계열은 다른 계열보다 훨씬 더 이질적입니다. 가장 광범위한 입력은 как подключить нейросеть к игре(게임에 신경망을 연결하는 방법)라는 요청입니다. 이 요청은 엔진을 전혀 언급하지 않으므로 프로토콜이나 상태를 확정할 수 없으며, 특정 시스템으로 좁혀지기 전까지 방법론적으로 검증되지 않은 상태로 남습니다. как подключить нейросеть к майнкрафту(마인크래프트에 신경망을 연결하는 방법)와 как подключить нейросеть к скайриму(스카이림에 신경망을 연결하는 방법)라는 요청은 이미 구체적이고 오래된 게임들을 지칭하고 있지만, 검증된 사실 집합(fact set) 내에서 이들 중 어느 것에 대해서도 문서화된 MCP 서버가 존재하지 않으므로 상태는 동일하게 '미검증'입니다. Roblox에 관한 두 가지 옵션인 как подключить ии к роблокс студио(Roblox Studio에 AI를 연결하는 방법)와 как подключить нейросеть к роблокс студио(Roblox Studio에 신경망을 연결하는 방법)는 단순한 게임이 아닌 동일한 제품인 Roblox Studio를 가리킵니다. "AI"에서 "신경망"으로 동사를 바꾸더라도 검증된 집합 내에 이 조합에 대한 MCP 서버가 없기 때문에 상태는 변하지 않습니다.

grand mobile에 신경망을 연결하는 방법이라는 요청은 여기서 가장 니치(niche)한 사례입니다. 검증된 소스 패키지 내에 후보조차 없으므로, 이는 매트릭스의 제로 단계(zero stage)에 있는 문제입니다. 즉, 권한을 논하기 전에 먼저 프로토콜과 서버를 찾아야 합니다. 검증된 사실 집합 내의 전체 분기 중에서는 이중 합의(two-level consent)를 갖춘 공식 Unity MCP 서버만이 확인되었습니다. 위에 나열된 모든 요청은 검증되지 않은 상태로 남아 있으며, 완성된 것으로 간주되어서는 안 됩니다.

• 주변부 분기: 왓츠앱에 AI를 연결하는 방법 및 lenovo ai glasses v1 api 스마트 글래스: 이것들은 검증된 패키지의 MCP 클라이언트가 아니라, 자체 API를 가진 외부 시스템입니다. 확인 없이 이들을 "MCP 호환" 범주에 포함시켜서는 안 됩니다.

별도로 바이브 코딩(Vibe Coding) 주문 제작이라는 상업적 요청을 살펴볼 필요가 있습니다. 이러한 작업을 맡는 사람은 단순히 하나의 설정을 타인의 환경으로 옮기는 것이 아니라, 바로 그 조합의 검증을 판매하는 것입니다. 만약 수행자가 "MCP는 어디서든 작동한다"라고 약속한다면, 이는 그가 매트릭스를 구성하지 않았다는 첫 번째 신호입니다.

이러한 요청 중 그 어느 것도 그 자체로 벤더나 제품에 대한 사실이 아닙니다. 이것들은 의도의 표현이며, 픽스처(fixture)의 가치는 모호한 "AI 연결"을 구체적인 질문으로 바꾼다는 데 있습니다. 즉, 어떤 프로토콜인지, 어떤 클라이언트인지, 최소 권한은 무엇인지, 그리고 연결 지점이 확인되었는지에 대한 질문입니다.

[