MCP 2026-07-28 마이그레이션 가이드: 무상태 서버

요약: MCP 2026-07-28은 프로토콜 수준의 세션과 필수 초기화 핸드셰이크를 제거합니다. 프로덕션 팀은 숨겨진 세션 의존성을 찾아내고, 요청당 프로토콜 메타데이터를 도입하며, 다중 왕복 요청(MRTR)을 구현하고, 게이트웨이 정책을 업데이트한 뒤, 레거시 동작을 중단하기 전에 새 프로토콜을 카나리 배포해야 합니다.

2026년 7월 28일 공개된 Model Context Protocol 사양은 원격 전송 지원이 추가된 이후 MCP에 가장 큰 아키텍처 변경을 도입했습니다.

프로토콜은 이제 상태 비저장 요청-응답 코어를 사용합니다. 필수였던 initialize 및 notifications/initialized 교환이 사라졌고, Mcp-Session-Id가 제거되었으며, 각 요청이 처리에 필요한 프로토콜 정보를 자체적으로 포함합니다.

이번 릴리스에는 다중 왕복 요청(MRTR), HTTP 라우팅 헤더, 캐시 가능한 목록 응답, 더 엄격한 인가 동작, 확장 프레임워크, 공식 사용 중단 수명주기도 포함됩니다. 프로토콜 수준의 세부 사항은 공식 MCP 2026-07-28 릴리스 공지와 전체 사양 변경 로그를 참조하세요.

이러한 변경은 표준 HTTP 인프라 뒤에서 원격 MCP 서버를 확장하기 쉽게 만들어 줍니다. 그러나 기존 애플리케이션을 자동으로 상태 비저장으로 만들지는 않습니다.

프로덕션 서버는 여전히 인메모리 워크스페이스, 스티키 라우팅, 세션 기반 자격 증명, 장기 스트림, 서버 주도 상호작용에 의존할 수 있습니다. 이 가이드는 이러한 의존성을 찾아 대체하는 데 초점을 맞춥니다.

더 기초적인 구현 안내서는 마이그레이션을 시작하기 전에 How to Create an MCP Server for Claude Code를 참고하세요.

누가 마이그레이션해야 하나요?

필요한 작업량은 시스템에서 MCP를 사용하는 방식에 따라 달라집니다.

상태를 요청 간에 유지하지 않는 로컬 서버는 SDK 업그레이드와 호환성 테스트만 필요할 수 있습니다.

세션, OAuth, 스트리밍 또는 서버 주도 요청을 사용하는 원격 배포는 단계적 마이그레이션이 필요합니다.

MCP 2026-07-28에서 무엇이 변경되었나요?

1. 기존 구현 감사

업그레이드 전에 클라이언트, 서버, 게이트웨이 및 배포 구성에서 이전 프로토콜 가정을 검색하세요.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

그런 다음 다음 질문에 답하십시오:

1. 초기화가 완료될 때까지 서버가 호출을 거부하나요?
2. 세션 ID가 사용자, 자격 증명, 워크스페이스 또는 대화를 선택하나요?
3. 다른 서버 인스턴스가 첫 번째 인스턴스에서 시작된 워크플로를 이어갈 수 있나요?
4. 로드 밸런서에 세션 어피니티가 필요한가요?
5. 툴이 확인을 요청하기 전에 부작용을 수행하나요?
6. 게이트웨이가 메서드나 툴을 식별하기 위해 본문을 파싱하나요?
7. OAuth 자격 증명이 발급한 인가 서버 정보 없이 저장되어 있나요?
8. 클라이언트가 SSE 재연결이나 메시지 재전달에 의존하나요?
9. 툴 또는 리소스 목록이 연결별로 달라지나요?
10. 어떤 사용 중단 예정 기능이 아직 프로덕션 트래픽을 받고 있나요?

Mcp-Session-Id의 제거는 애플리케이션이 그 뒤에 어떤 내용을 저장하는지 이해한 후에 진행하세요.

헤더를 제거했지만 상태를 로컬 메모리에 유지하는 서버는 개발 중에는 동작할 수 있으나, 요청이 여러 인스턴스로 분산되면 간헐적으로 실패할 수 있습니다.

2. 숨겨진 세션 상태 교체

MCP 2026-07-28은 프로토콜 수준 세션만 제거하며, 애플리케이션 상태는 제거하지 않습니다.

호출 간 필요한 상태는 다음 세 가지 패턴 중 하나를 사용해야 합니다.

명시적 핸들

한 툴에서 서버가 발급한 핸들을 반환하고 이후 호출에서 이를 요구합니다.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

이후 요청은 일반 인자로 핸들을 전달합니다:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

이렇게 하면 의존성이 툴 계약에 명시되어, 호환 가능한 어느 서버 인스턴스라도 요청을 처리할 수 있습니다.

공유 스토리지

다음과 같은 경우에는 데이터베이스, 분산 캐시, 오브젝트 스토어 또는 내구성 있는 작업 시스템을 사용하세요:

• 여러 워커가 동일한 상태를 필요로 함
• 워크플로가 재시작 이후에도 유지되어야 함
• 상태가 핸들로 담기에는 너무 큼
• 워크플로가 단일 요청보다 오래 지속됨
• 트랜잭션 또는 단일 사용 보장이 필요함

보호된 requestState

MRTR은 서버가 불투명한 requestState 값을 반환하고, 클라이언트가 원래 요청을 재시도할 때 이를 그대로 에코하도록 할 수 있습니다.

이 값은 클라이언트를 경유하므로 HMAC 또는 인증된 암호화로 보호하세요. 재생 방지가 필요할 때 인증된 주체, 원래 작업, 중요한 파라미터, 만료 시간, nonce에 바인딩하세요.

클라이언트가 변경 없이 되돌려 보냈다는 이유만으로 서명되지 않은 requestState 값을 신뢰하지 마십시오.

3. 자기완결적 요청과 디스커버리 도입

최신 MCP 요청은 _meta에 프로토콜 컨텍스트를 포함합니다.

Streamable HTTP 툴 호출 예시는 다음과 같습니다:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

새 프로토콜을 대상으로 하는 서버는 지원 버전, 역량, 서버 ID를 광고하는 server/discover를 구현해야 합니다. 클라이언트는 다른 작업 전에 이를 호출하거나 레거시 폴백이 필요한지 판별하는 데 사용할 수 있습니다.

응답 계약은 공식 server/discover documentation을 참조하세요.

TypeScript SDK 버전 협상

TypeScript SDK를 업그레이드하는 것만으로는 클라이언트가 자동으로 새 프로토콜로 전환되지 않습니다.

v2 SDK를 사용하는 클라이언트는 명시적으로 옵트인해야 합니다:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

자동 모드에서 SDK는 server/discover로 프로브하고, 레거시 서버를 만나면 이전 초기화 흐름으로 폴백할 수 있습니다.

아직 @modelcontextprotocol/sdk v1을 사용하는 팀은 먼저 공식 TypeScript SDK v1→v2 마이그레이션 가이드를 따르세요. 이미 v2를 사용하는 팀은 별도의 2026-07-28 프로토콜 지원 가이드를 사용하세요.

4. 서버 주도 요청을 MRTR로 교체

이전 MCP 구현은 elicitation/create, sampling/createMessage, roots/list와 같은 요청을 서버가 클라이언트로 전송할 수 있었습니다.

새 프로토콜은 이 모델을 다중 왕복 요청(MRTR)으로 대체합니다.

흐름은 다음과 같습니다:

1. 클라이언트가 원래 요청을 전송합니다.
2. 서버는 resultType: "input_required"를 반환합니다.
3. 클라이언트는 요청된 정보나 승인을 수집합니다.
4. 클라이언트는 새로운 JSON-RPC ID로 원래 작업을 재시도합니다.
5. 재시도에는 inputResponses와 원래의 requestState가 포함됩니다.
6. 서버는 요청을 완료하거나 또 다른 라운드를 시작합니다.

예시 응답:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

클라이언트는 원래 작업을 재시도합니다:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

프로덕션 MRTR 구현은 다음을 정의해야 합니다:

• 최대 라운드 수
• 요청 상태 만료
• 취소 및 거부 동작
• 응답 스키마 검증
• 매 재시도 시 인가 검사
• 재생 공격 방지
• 부작용의 멱등성
• 클라이언트가 요청된 역량을 지원하지 않을 때의 동작

구매, 삭제, 크레딧 차감 또는 외부 쓰기를 완료하기 전에 input_required를 반환하지 않는 동작은 피하세요.

단계적 작업이나 멱등성 키를 사용하여 재시도가 작업을 중복 수행하지 않도록 하십시오. 전체 상호작용 모델은 공식 MRTR 사양을 참고하세요.

5. 게이트웨이, 캐싱, 인가 업데이트

인프라 변경 사항은 서로 밀접하게 관련되어 있으므로 함께 테스트해야 합니다.

MCP 라우팅 헤더 검증

Streamable HTTP POST 요청은 다음을 포함합니다:

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

이 헤더를 사용하면 게이트웨이가 모든 JSON 본문을 파싱하지 않고도 트래픽을 라우팅, 측정, 인가, 레이트 리미팅할 수 있습니다.

예를 들어 다음과 같은 제어를 지원할 수 있습니다:

• 툴별 레이트 제한
• 목록과 실행 메서드에 대한 분리된 정책
• 비용이 큰 툴을 위한 전용 워커 풀
• 고위험 작업에 대한 접근 제한
• 툴별 지연 시간 및 오류 메트릭
• 인프라 비용 귀속

해당 값은 여전히 클라이언트가 제공합니다. 정책 적용 전 JSON-RPC 본문과 비교하세요.

요청이 본문에서는 다른 툴을 호출하면서 헤더 Mcp-Name에 저위험 툴을 주장할 수 있어서는 안 됩니다. 헤더-본문 불일치는 거부하고 로깅해야 합니다.

인가 인지 캐시 키 사용

새 프로토콜은 다음과 같은 캐시 가능한 결과에 ttlMs와 cacheScope를 추가합니다:

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

캐시 키는 일반적으로 다음을 포함해야 합니다:

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

TTL이 만료되지 않았다는 이유만으로 개인 캐시 엔트리를 사용자나 테넌트 간에 재사용하지 마십시오.

툴의 결정적 정렬도 중요합니다. 안정적인 카탈로그는 불필요한 캐시 미스를 방지하고, 툴 정의가 프롬프트에 삽입될 때 모델 프롬프트 캐시 재사용을 개선할 수 있습니다.

OAuth 발급자 처리 강화

인가 마이그레이션 중에는 다음을 수행하세요:

• 반환된 iss 값을 해당 플로우에 기록된 발급자와 검증
• 저장된 클라이언트 자격 증명을 발급자 기준으로 키잉
• 다른 인가 서버에서 자격 증명을 재사용하지 않기
• DCR 중 적절한 application_type 설정
• Client ID Metadata Documents 도입 대비

Dynamic Client Registration은 하위 호환을 위해 여전히 사용할 수 있지만, 기본 등록 방식으로는 사용 중단 방향입니다.

6. 알림, Tasks 및 사용 중단 기능 마이그레이션

이전 HTTP GET 알림 경로와 resources/subscribe 또는 resources/unsubscribe 흐름은 subscriptions/listen으로 대체되었습니다.

클라이언트는 장기 POST-응답 스트림을 열고 필요한 알림 범주를 옵트인합니다. 요청별 진행 상황 및 로그 알림은 해당 요청을 설명하는 응답 스트림에 계속 연결됩니다.

멀티 인스턴스 배포에서, 한 서버 인스턴스에서 생성된 알림이 다른 곳에 연결된 구독에 도달해야 한다면 공유 이벤트 버스를 사용하세요.

Tasks 확장

장기 작업은 코어 프로토콜의 실험적 기능에서 다음으로 이동했습니다:

io.modelcontextprotocol/tasks

해당 확장은 다음을 사용합니다:

• tasks/get 폴링용
• tasks/update 클라이언트→서버 업데이트용
• 내구성 있는 작업 핸들
• 옵트인된 업데이트를 위한 subscriptions/listen

이전의 tasks/result 및 tasks/list 패턴은 새 구현으로 가져오지 마십시오.

사용 중단(Deprecated) 기능

다음 기능은 사용 중단 예정입니다:

사용 중단 기능은 사용 중단 기간 동안 계속 제공되지만, 새 구현에서 채택하지 마십시오. MCP 수명주기 정책은 최소 12개월의 사용 중단 기간을 제공하지만, 모든 기능에 동일한 제거 시점을 보장하지는 않습니다.

퇴출 시점을 정하기 전에 공식 사용 중단 기능 레지스트리를 검토하세요.

7. 마이그레이션을 안전하게 롤아웃

클라이언트, 서버, 게이트웨이, 캐싱, 인가를 관측 없이 하나의 릴리스로 변경하지 마십시오.

권장 마이그레이션 순서

1. 프로토콜 버전, SDK, 세션, SSE 트래픽, DCR 클라이언트, 사용 중단 메서드를 인벤토리화
2. 비프로덕션 SDK 업그레이드
3. server/discover 및 버전 협상 추가
4. 숨겨진 세션 의존성 교체
5. MRTR 구현 및 보안 강화
6. 검증된 라우팅 헤더와 범위 기반 캐시 추가
7. 인가 발급자 경계 테스트
8. 레거시 경로와 함께 최신 프로토콜 카나리 배포
9. 텔레메트리 검토 후에만 구 동작 퇴출

카나리 중 호환성

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

새 MCP 사양의 릴리스가 생태계 전체 전환을 의미하지는 않습니다. 클라이언트, 서버, SDK, 호스티드 플랫폼은 서로 다른 속도로 마이그레이션됩니다.

수집해야 할 텔레메트리

성공적인 원샷 tools/call 요청만으로 마이그레이션을 측정할 수는 없습니다. 반복적으로 타임아웃되거나 불필요한 입력을 요구하거나 외부 쓰기를 중복 수행하는 워크플로는 여전히 프로덕션 실패입니다.

CometAPI가 MCP 아키텍처에 맞는 방식

MCP는 모델 API를 대체하지 않습니다. 두 레이어는 서로 다른 통합 문제를 해결합니다.

일반적인 프로덕션 아키텍처는 다음과 같습니다:

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP는 에이전트가 툴과 컨텍스트와 상호작용하는 방식을 표준화합니다. 모델 가격, 공급자 자격 증명, 추론 엔드포인트, 공급자 페일오버는 표준화하지 않습니다.

이는 사용 중단된 Sampling 기능에서 마이그레이션할 때 특히 유용합니다. MCP 서버나 이를 소비하는 에이전트가 여전히 모델 추론이 필요하다면, 애플리케이션은 더 이상 기존 MCP Sampling 흐름에 의존하지 않고 모델 API를 직접 호출할 수 있습니다.

통합 모델 게이트웨이가 도움이 되는 경우

다음 상황에서 통합 모델 게이트웨이는 운영 작업을 줄일 수 있습니다:

• 여러 MCP 서버가 다양한 모델 공급자에 접근해야 하는 경우
• 서로 다른 툴이 서로 다른 모델을 필요로 하는 경우
• 팀이 공급자별 통합을 다시 작성하지 않고 모델을 전환하려는 경우
• 자격 증명, 사용량, 과금을 중앙에서 관리해야 하는 경우
• 모델 접근을 MCP 전송 변경과 독립적으로 유지해야 하는 경우

CometAPI는 MCP 애플리케이션 뒤에서 모델 접근 계층으로 사용할 수 있는 OpenAI 호환 엔드포인트를 제공합니다. 이를 통해 모델 공급자 로직을 MCP 툴, 리소스, 작업 오케스트레이션으로부터 분리할 수 있습니다.

예를 들어, MCP 툴은 애플리케이션의 다른 곳에서 사용하는 동일한 OpenAI 호환 클라이언트를 통해 모델을 호출할 수 있습니다:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

MCP 서버는 툴 계약, 인가, 상태 및 결과 처리에 계속 책임을 집니다. 모델 게이트웨이는 모델 선택, 공급자 접근, 추론 응답을 처리합니다.

이 레이어를 분리하면 두 가지 실용적 이점이 있습니다:

1. MCP 클라이언트와 서버는 모델 통합 레이어를 변경하지 않고 새 프로토콜로 마이그레이션할 수 있습니다.
2. 모델 공급자는 MCP 툴이나 전송 동작을 재설계하지 않고도 교체할 수 있습니다.

자세한 구현 정보는 CometAPI 퀵스타트, API 문서, 멀티 모델 AI 애플리케이션 가이드를 참조하세요.

MCP 2026-07-28 마이그레이션 체크리스트

클라이언트

• 호환 가능한 SDK로 업그레이드
• 최신 버전 협상 활성화
• server/discover 지원
• 모든 요청에 프로토콜 메타데이터 포함
• resultType 처리
• MRTR 지원 또는 명시적 거부
• 재시도에 새 JSON-RPC ID 사용
• requestState 보존 및 반환
• OAuth 발급자 검증
• 발급자 기준으로 자격 증명 저장
• 캐시 힌트 준수
• 필요 시 subscriptions/listen 지원

서버

• 최신 요청의 초기화 게이트 제거
• Mcp-Session-Id 의존성 제거
• server/discover 구현
• 숨겨진 상태를 핸들이나 공유 스토리지로 교체
• resultType 반환
• 서버 주도 요청을 MRTR로 교체
• requestState 보호
• 모든 inputResponses 검증
• 부작용 멱등성 추가
• 결정적 목록 반환
• 보수적 캐시 힌트 게시
• 장기 작업을 Tasks 확장으로 이전

게이트웨이 및 인프라

• MCP 요청 헤더 검증
• 헤더와 요청 본문 비교
• 불필요한 스티키 라우팅 제거
• 여러 인스턴스에 걸친 요청 테스트
• 인가 경계별 캐시 파티셔닝
• 필요 시 공유 알림 버스 추가
• 레거시 및 사용 중단 트래픽 추적
• 카나리 중 롤백 경로 유지

자주 묻는 질문(FAQ)

MCP 2026-07-28이란?

MCP 2026-07-28은 2026년 7월 28일 공개된 Model Context Protocol 사양으로, 상태 비저장 프로토콜 코어, 다중 왕복 요청, HTTP 라우팅 헤더, 캐시 가능한 결과, 인가 변경, 확장, 공식 사용 중단 수명주기를 도입합니다.

Mcp-Session-Id가 제거되었나요?

예. 새 Streamable HTTP 프로토콜은 더 이상 Mcp-Session-Id를 사용하지 않습니다.

애플리케이션은 여전히 명시적 핸들, 공유 스토리지, 내구성 있는 작업 또는 보호된 요청 상태 값을 통해 상태를 보존할 수 있습니다.

MCP 초기화 핸드셰이크가 제거되었나요?

예. 최신 요청은 더 이상 initialize 및 notifications/initialized 교환을 요구하지 않습니다.

서버는 server/discover를 구현해야 하지만, 클라이언트가 매 작업 전에 이를 호출할 필요는 없습니다.

상태 비저장 MCP가 툴의 상태 보존을 금지하나요?

아니오. 상태 비저장은 프로토콜 레이어를 의미합니다.

툴은 여전히 상태를 저장할 수 있지만, 요청 처리가 숨겨진 전송 결속이나 특정 서버 프로세스에 의존해서는 안 됩니다.

MRTR란?

다중 왕복 요청(MRTR)은 지속적으로 열린 양방향 연결을 통한 서버 주도 요청 없이, 서버가 추가 클라이언트 또는 사용자 입력을 요청할 수 있게 합니다.

서버가 input_required를 반환하면, 클라이언트는 요청된 응답을 포함하여 원래 작업을 재시도합니다.

HTTP+SSE가 즉시 제거되나요?

아니오. 즉시 제거가 아닌 사용 중단 예정입니다.

새 서버는 Streamable HTTP를 사용하고, 기존 시스템은 남은 HTTP+SSE 트래픽을 측정하여 마이그레이션하세요.

TypeScript SDK v2 클라이언트가 자동으로 MCP 2026-07-28을 사용하나요?

아니오. TypeScript v2 SDK는 최신 프로토콜 사용을 위해 명시적 버전 협상 구성이 필요합니다.

클라이언트가 최신 및 레거시 서버 모두와 작동해야 한다면 자동 협상을 사용하세요.

최종 권고

MCP 2026-07-28은 원격 MCP 인프라를 더 쉽게 확장, 라우팅, 캐싱, 가시화할 수 있게 합니다. 주요 마이그레이션 위험은 헤더나 핸드셰이크의 제거 그 자체가 아니라, 여전히 이에 의존할 수 있는 숨겨진 애플리케이션 상태와 상호작용 로직입니다.

배포 전에:

초기화와 Mcp-Session-Id에 대한 모든 의존성을 찾아내십시오.

1. 필요한 상태를 명시적 핸들이나 공유 스토리지로 이동
2. 만료, 재생 방지, 멱등성을 갖춘 MRTR 구현
3. MCP 헤더를 JSON-RPC 본문과 대조하여 검증
4. 테넌트와 인가 범위별로 캐시를 분할
5. OAuth 발급자 검증 강화
6. 사용 중단 메서드와 레거시 전송 트래픽 측정
7. 퇴출 전에 최신/레거시 프로토콜 경로를 카나리 배포

이번 마이그레이션을 단순 SDK 업그레이드가 아닌 인프라 변경으로 취급하세요.

MCP 레이어가 상태 비저장이고 관측 가능해지면, 모델 접근은 별도 인터페이스 뒤에 유지하십시오. 이렇게 하면 툴 프로토콜과 모델 공급자 레이어가 서로 독립적으로 발전할 수 있습니다.