P6-15.1 도구와 자원을 공통 형식으로 연결하는 MCP¶

Section ID: P6-15.1 Version: v2026.07.23

P6-14.2에서는 에이전트(agent)가 계획, 행동, 관찰의 반복 구조를 가진다는 점을 보았습니다. 이제는 이런 도구와 상태를 여러 시스템 사이에서 더 일관되게 연결하려면 무엇이 필요한지 봐야 합니다.

MCP(Model Context Protocol)는 모델, 에이전트, 애플리케이션이 외부 도구와 데이터에 더 일관되게 연결되도록 돕는 인터페이스 관점입니다. 즉, 여러 도구와 데이터를 제각각 붙이지 말고 더 일정한 방식으로 연결하자는 약속에 가깝습니다.

도구와 자원을 잇는 공통 연결 형식¶

먼저 닫을 문제는 도구와 자원을 어떤 공통 형식으로 연결할 것인가입니다. 실행을 감싸는 운영 장치는 연결을 쓴 실행을 어떻게 기록하고 재현할지의 문제이고, 인증과 권한이 실제 실패 대응과 만나는 지점은 운영 통제의 문제로 남습니다.

여기서는 MCP를 도구 연결을 덜 제각각으로 만들려는 표준화 관점으로 읽습니다.

에이전트 루프가 여러 읽기와 실행을 어떤 반복 구조로 이어 갈까를 다뤘다면, MCP 관점은 그 루프가 쓰는 도구와 자원을 어떤 공통 형식으로 드러내야 다음 실행과 기록이 덜 흔들리는지 다룹니다. 여기서는 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)을 모델 능력과 도구 연결 형식을 섞지 않게 하는 공통 연결 인터페이스로 읽는 기준을 잡습니다. 실행 기록과 재현 환경은 P6-15.2의 하네스에서 따로 봅니다.

여기서 먼저 못 박을 것은 어떤 도구와 자원을 어떤 공통 형식으로 노출할지와 연결 인터페이스를 일정하게 만드는 일입니다.

MCP에서 먼저 정리할 연결 정보	왜 필요한가	이후 이어지는 확인
도구 설명과 자원 설명	어떤 도구와 자원이 어떤 이름·입력 형식으로 노출되는지 드러나야 호출 실패와 연결 불일치를 줄일 수 있어서	P6-15.2의 trace/replay와 도구 연결 메모로 이어집니다
권한 경계와 승인 조건	어떤 호출이 바로 실행 가능하고 어떤 호출이 승인을 거쳐야 하는지 함께 보여야 운영 실패를 줄일 수 있어서	P6-15.2의 승인 기록, P6-17.2의 실패 대응으로 이어집니다

공통 형식이라는 말이 아직 추상적으로 느껴질 수 있습니다. 이때는 프로토콜 이름을 먼저 외우기보다, 같은 목표를 처리할 때 도구마다 입력 형식이 제각각이면 어디서 먼저 흔들리는지를 떠올리는 편이 더 안전합니다.

예를 들어 한 에이전트가 아래 세 가지를 같이 써야 한다고 해 봅시다.

검색 도구: query, top_k
파일 읽기 도구: path
일정 조회 도구: date, room_id

이 셋이 서로 전혀 다른 규칙으로만 붙어 있으면, 에이전트는 무슨 정보를 넘길까보다 이번 도구는 어떤 모양으로 불러야 하지를 먼저 신경 써야 합니다. 검색 결과를 읽기 단계로 넘길 때는 경로가 필요하고, 일정 조회로 넘어갈 때는 다시 날짜와 방 ID 형식이 필요하므로, 중간 변환과 예외 처리가 빠르게 늘어납니다.

반대로 공통 연결 관점이 있으면, 에이전트는 먼저 검색 가능한 도구, 읽을 수 있는 자원, 조회 가능한 도구가 어떤 이름과 입력 형식으로 노출되는지 일정한 방식으로 확인할 수 있습니다. 즉, MCP는 개별 도구의 목적을 바꾸는 것이 아니라 다음 단계에 무엇을 넘길 수 있는가를 더 예측 가능하게 만드는 층으로 읽는 편이 맞습니다.

같은 장면을 아주 짧게 줄이면 다음과 같습니다.

같은 목표 흐름에서 먼저 흔들리는 것	공통 연결 관점이 약할 때	공통 연결 관점이 있을 때
어떤 도구를 고를지	도구마다 설명 위치와 이름 체계가 달라 선택부터 헷갈리기 쉽습니다.	어떤 도구와 자원이 노출되는지 한 방식으로 확인하기 쉬워집니다.
다음 단계에 무엇을 넘길지	검색 결과, 경로, 조회 인자를 매번 다른 형식으로 바꿔야 합니다.	다음 단계가 기대하는 입력 형식을 더 예측 가능하게 맞추기 쉬워집니다.
실패 원인을 어디서 찾을지	모델 판단 문제인지 연결 형식 문제인지 섞여 보이기 쉽습니다.	연결 규칙과 실행 판단을 더 분리해 다시 보기 쉬워집니다.

모델 능력과 도구 연결 규칙의 구분¶

도구 사용이 한두 개일 때는 개별 연결을 직접 만들어도 됩니다. 하지만 에이전트 구조가 커지면 도구 수가 늘고, 연결 방식이 제각각이 되기 쉽습니다. MCP 같은 연결 관점은 도구 설명, 요청 형식, 응답 형식을 일정하게 맞추어 모델보다 주변 연결 환경이 덜 혼란스럽게 만들려는 시도입니다.

서비스 구조 관점으로 말하면, tool use는 도구를 부른다에 가깝고, MCP는 그 도구들을 어떤 공통 형식으로 드러낼까를 다루는 단계입니다. 모델이 텍스트를 이해하고 생성하는 능력과, 외부 도구가 어떤 이름, 입력 형식, 반환 형식으로 노출되는지는 서로 다른 층위입니다. 이 구분을 먼저 잡아야 모델 자체 한계인지, 도구 노출 방식과 연결 설계 문제인지 원인을 나눠 볼 수 있습니다.

모델은 주어진 입력을 읽고, 다음에 필요한 말이나 행동 후보를 고르는 능력을 중심으로 합니다. 반면 MCP 같은 연결 관점은 모델 바깥에 있는 파일, 검색, 데이터베이스, API 같은 외부 도구와 데이터에 어떻게 접근할지를 중심으로 합니다. 따라서 MCP는 모델 내부 능력이라기보다, 모델 주변의 실행 환경을 어떤 형식으로 연결할지에 가까운 문제입니다.

예를 들어 agent 구조가 커지면 한 작업 안에서 여러 종류의 도구가 함께 필요해집니다.

어떤 도구는 파일을 읽고
어떤 도구는 검색을 하고
어떤 도구는 데이터베이스를 조회하고
어떤 도구는 API를 호출합니다

이 연결이 모두 제각각이면 시스템은 점점 다루기 어려워집니다. 도구가 늘어날수록 모델이 무엇을 쓸 수 있고 어떤 형식으로 써야 하는지를 일정하게 맞추지 않으면, 실패 원인이 도구마다 다르게 흩어지기 때문입니다.

그래서 MCP가 있으면 먼저 다음 세 가지가 쉬워집니다. 도구 목록을 일정한 방식으로 드러내기 쉬워지고, 요청과 응답 구조를 더 일관되게 유지하기 쉬워지며, 여러 시스템을 바꿔도 연결 관점을 재사용하기 쉬워집니다. 즉, MCP는 새 능력 생성기라기보다 연결 정리 도구에 가깝습니다.

같은 요청 흐름 안에서 역할을 다시 놓으면, 프롬프트는 요청을 적고, RAG는 읽을 문서를 붙이며, 도구 사용은 실행할 기능을 부릅니다. 에이전트는 여러 단계를 이어 가고, MCP는 그 연결들을 더 일정한 형식으로 다루게 돕습니다. 이 순서를 잡아야 MCP를 모델 성능이나 하네스 기록 환경과 섞지 않을 수 있습니다.

이 절에서 필요한 학습은 MCP의 모든 세부 구현을 외우는 것이 아닙니다. MCP를 입문 수준에서 설명하고, 모델 능력과 연결 인터페이스를 구분하며, agent와 tool use가 커질수록 왜 연결 표준이 중요해지는지 말할 수 있으면 됩니다. 그 다음에 연결된 실행을 P6-15.2의 하네스(harness) 기록 환경으로 어떻게 넘길지 이어서 보면 됩니다.

먼저 가를 장면은 아래처럼 정리할 수 있습니다.

먼저 보인 막힘	먼저 떠올릴 질문	왜 이 질문이 먼저 필요한가
같은 목표를 처리하는데 도구마다 이름과 입력 형식이 너무 달라 호출 전부터 흔들림	어떤 도구와 자원이 어떤 이름과 입력 형식으로 노출되는가?	연결 형식이 제각각이면 모델 판단보다 형식 변환과 예외 처리부터 먼저 늘어나기 때문입니다.
호출은 성공했는데 반환값 모양이 달라 다음 단계가 자꾸 끊김	응답 형식도 공통 규칙으로 읽히는가?	입력만 맞춰도 출력 구조가 제각각이면 다음 단계 연결이 다시 불안정해지기 때문입니다.
도구는 늘었는데 어떤 것을 먼저 써야 하는지 설명이 제각각임	도구 설명과 자원 설명을 한 방식으로 확인할 수 있는가?	선택 기준이 흩어져 있으면 같은 목표 흐름도 도구 선택부터 흔들리기 때문입니다.
권한이 필요한 호출과 바로 실행 가능한 호출이 섞여 있음	권한 경계와 승인 조건이 연결 설명 안에서 같이 보이는가?	승인 문제를 뒤늦게 알면 연결 성공과 운영 실패를 같은 오류처럼 뭉개기 쉽기 때문입니다.

이 표를 기준으로 아래 내용을 읽으면, MCP를 프로토콜 이름보다 도구와 자원을 덜 제각각으로 연결하게 만드는 공통 형식으로 더 직접 읽을 수 있습니다.

flowchart LR
  A["사용자 과업"]
  B["에이전트가 도구 선택"]
  C["공통 연결 규칙"]
  D["도구 또는 리소스"]

  A --> B
  B --> C
  C --> D

이 그림에서 핵심은 에이전트가 매번 도구마다 다른 사적 규칙을 외우는 대신, 공통 연결 규칙을 통해 도구와 자원을 본다는 점입니다.

MCP를 기술 세부보다 먼저 역할 기준으로 이해하면 연결 문제를 더 쉽게 구분할 수 있습니다. MCP가 먼저 표준화하려는 것은 어떤 도구가 있는가, 어떤 데이터나 리소스를 읽을 수 있는가, 어떤 형식으로 요청하고 응답할 것인가입니다. 따라서 MCP는 모델이 더 똑똑해지는 방법이 아니라, 모델과 외부 시스템이 덜 혼란스럽게 연결되는 방법으로 읽는 편이 정확합니다.

여러 도구 흐름에서 보이는 차이¶

flowchart TD
  A["모델 또는 에이전트"]
  B["공통 연결 인터페이스"]
  C["도구와 데이터 소스"]

  A --> B
  B --> C

이 도식의 핵심은 MCP를 모델과 도구 사이의 연결 계층으로 읽는 데 있습니다.

같은 내용을 연결 혼잡도 관점으로 다시 비교하면 다음과 같습니다.

상태	모델이나 에이전트가 알아야 하는 것	흔한 운영 문제
MCP 같은 공통 연결 관점이 약할 때	도구마다 다른 이름, 인자 형식, 반환 형식	형식 불일치, 예외 처리 증가, 새 도구 추가 비용 증가
MCP 같은 공통 연결 관점이 있을 때	공통 방식으로 노출된 도구 목록과 리소스 정보	연결 자체보다 권한, 품질, 평가 문제를 더 분리해 다루기 쉬워짐

MCP가 있다고 해서 도구 품질, 권한 문제, 잘못된 호출, 평가가 자동으로 해결되지는 않습니다. 연결 형식이 정리되는 것과 실제 운영 품질이 좋아지는 것은 다른 문제입니다. 그래서 MCP는 새 능력 생성기가 아니라, 프롬프트, RAG, 도구 사용, 에이전트 흐름이 늘어날 때 그 연결들을 더 일정한 형식으로 다루게 돕는 연결 정리 관점으로 읽는 편이 좋습니다.

사례 및 예시¶

이 사례들의 초점은 도구가 무엇인가보다 어디에서 연결 규칙이 먼저 흔들리는가입니다.

사례 1. 문서 읽기와 검색을 함께 쓰는 에이전트¶

사내 정책 문서를 찾아 답하는 에이전트를 생각해 볼 수 있습니다. 사람은 파일 읽기와 문서 검색이 둘 다 문서를 보는 일이니 비슷하게 붙이면 된다고 생각하기 쉽습니다. 하지만 이 에이전트는 어떤 경우에는 파일을 직접 열어야 하고, 어떤 경우에는 검색으로 관련 문서를 먼저 찾아야 합니다. 예를 들어 정확한 파일 경로를 이미 아는 경우와, 키워드만 알고 있어 후보 문서를 먼저 찾아야 하는 경우는 접근 방식이 다릅니다.

그런데 파일 읽기 도구와 검색 도구가 서로 다른 호출 규칙과 결과 형식을 쓰면, 에이전트는 답을 만들기 전에 어떤 방식으로 접근해야 하는가부터 따로 배워야 합니다. 이 연결이 뒤섞이면 답변 전 준비 단계에서 잘못된 도구를 골라 검색해야 할 문서를 직접 읽으려 하거나, 반대로 경로가 있는 파일을 괜히 검색으로 돌릴 수 있습니다.

여기서 바뀌는 점은 둘 다 문서를 보는 일인가를 보던 기준에서 읽을 자원과 검색할 자원을 같은 형식으로 구분해 다룰 수 있는가를 보는 기준으로 이동한다는 것입니다. MCP 같은 연결 계층은 이런 자원을 더 일정한 형식으로 드러내어 읽을 수 있는 것, 검색할 수 있는 것을 같은 방식으로 다루기 쉽게 만듭니다. 그래서 이 사례에서 확인해야 할 결과는 경로가 있는 문서는 바로 읽고, 경로가 없는 질문은 먼저 검색하는 식으로 도구 선택이 실제로 더 일관되게 갈라지는가입니다.

시작 상태	먼저 써야 하는 것	연결 규칙이 흔들리면 생기는 문제
정확한 파일 경로를 알고 있음	읽기 자원 호출	괜히 검색부터 돌아 응답이 길어지거나 엉뚱한 후보를 탐색함
경로는 모르고 주제만 앎	검색 자원 호출	읽기 도구에 잘못된 경로를 넣고 바로 실패함
검색 결과에서 후보를 골라야 함	검색 결과와 읽기 자원 연결	검색 결과를 다음 읽기 단계로 넘기는 형식이 제각각이어서 흐름이 끊김

사례 2. 코딩 에이전트¶

코딩 에이전트가 코드베이스를 검색하고, 파일을 읽고, 테스트를 실행하고, 패치를 적용한다고 해 봅시다. 사람은 보통 검색 도구 하나, 실행 도구 하나씩 따로 붙이면 될 것처럼 생각하기 쉽습니다. 하지만 직접 스크립트를 붙이면 각 도구의 입력 형식과 반환 형식이 제각각이라 한 단계씩 별도 예외 처리가 늘어나기 쉽습니다. 예를 들어 검색 결과는 파일 목록인데 테스트 실행기는 디렉터리 경로를 기대하고, 패치 도구는 또 다른 형식을 요구할 수 있습니다.

이렇게 되면 실제 코드를 고치는 일보다 도구를 서로 이어 붙이는 일이 더 큰 부담이 될 수 있습니다. 이 연결이 불안정하면 패치 자체는 맞아도 테스트 실행 단계에서 형식 불일치로 멈춰, 결과적으로 수정 검증이 끝나지 않을 수 있습니다. 여기서 바뀌는 점은 도구를 각각 붙였는가를 보던 기준에서 도구 사이 입력과 반환 형식이 예측 가능하게 이어지는가를 보는 기준으로 이동한다는 것입니다. 연결 표준 관점이 들어오면 에이전트는 검색 가능 도구, 읽기 가능 자원, 실행 가능 도구를 더 예측 가능한 방식으로 다룰 수 있습니다. 그래서 이 사례에서 확인해야 할 결과는 패치 내용보다 먼저 입력 형식 불일치로 멈추던 단계가 줄고, 검색 결과에서 테스트 실행까지의 연결이 실제로 더 안정되는가입니다.

단계 연결	각 도구가 따로는 성공해도 생길 수 있는 문제	공통 연결 관점이 주는 이점
검색 결과 -> 파일 읽기	파일 후보 목록을 읽기 자원이 바로 못 받아 추가 변환이 필요함	어떤 항목이 읽을 수 있는 자원인지 더 예측 가능하게 드러남
파일 읽기 -> 패치 적용	위치 정보와 패치 대상 형식이 달라 중간 가공이 늘어남	패치 대상으로 넘길 최소 정보 구조를 더 일정하게 맞추기 쉬움
패치 적용 -> 테스트 실행	파일 기준 결과를 디렉터리/명령 기준 실행기가 바로 못 씀	실행 가능 도구를 공통 방식으로 호출해 다음 단계 연결이 덜 흔들림

사례 3. 조직 내부 시스템 연결¶

조직 내부에서 문서 저장소, 업무 DB, 캘린더 API를 함께 쓰는 비서를 떠올려 볼 수 있습니다. 사람은 필요한 데이터만 있으면 연결 자체는 큰 문제가 아니라고 생각하기 쉽습니다. 하지만 실제로 손으로 붙이면 문서는 검색 쿼리, DB는 SQL 비슷한 질의, 캘린더는 별도 API 인자처럼 접근 방식이 모두 달라집니다. 예를 들어 같은 오늘 일정 확인 요청도, 사람 정보는 DB에서 찾고 일정은 캘린더 API에서 조회하며 관련 안내는 문서 저장소에서 다시 읽어야 할 수 있습니다.

이때 문제는 데이터가 없다가 아니라 데이터마다 접근 규칙이 너무 다르다는 데 생깁니다. 접근 규칙이 제각각이면 한 시스템에서 얻은 값을 다음 시스템 호출에 넘기는 과정에서 형식 오류나 누락이 쉽게 생길 수 있습니다. 여기서 바뀌는 점은 필요한 데이터가 있나를 보던 기준에서 서로 다른 시스템 접근 규칙을 일정한 형식으로 다룰 수 있는가를 보는 기준으로 이동한다는 것입니다. MCP 같은 연결 계층은 이런 시스템을 모델 친화적으로 드러내어, 에이전트가 어떤 자원에 접근 가능한지와 어떤 형식으로 써야 하는지를 더 일정하게 만듭니다. 그래서 이 사례에서 확인해야 할 결과는 사람 정보 조회, 일정 조회, 안내 문서 읽기가 서로 다른 규칙 때문에 자주 끊기지 않고 하나의 작업 흐름으로 더 안정적으로 이어지는가입니다.

세 사례를 연결 안정성 관점으로 다시 묶으면 다음과 같습니다.

상황	공통 연결 관점이 없을 때 먼저 흔들리는 것	공통 연결 관점이 있을 때 먼저 안정되는 것
문서 읽기 + 검색	읽기 자원과 검색 자원 선택 규칙	어떤 자원은 읽고 어떤 자원은 검색하는 구분
코딩 에이전트	도구별 입력·반환 형식 연결	검색에서 실행까지의 형식 예측 가능성
내부 시스템 연결	시스템마다 다른 접근 규칙	사람 정보, 일정, 문서 조회의 연결 흐름

연결 규칙을 먼저 봐야 하는 장면¶

MCP를 처음 읽을 때 자주 생기는 오해는 도구가 잘 안 붙는다는 문제를 곧바로 모델 성능 부족으로 읽는 점입니다. 하지만 먼저 봐야 하는 것은 모델이 똑똑하냐보다 도구와 자원이 어떤 공통 형식으로 노출되어 있는가입니다. 앞에서 나눈 기준을 실제 점검 질문으로 바꾸면 다음처럼 읽을 수 있습니다.

이런 의심이 들면	먼저 던질 질문
`도구는 있는데 왜 자꾸 연결이 흔들리지?`	도구 설명과 요청 형식이 공통 규칙으로 노출돼 있는가?
`검색 다음 읽기 단계에서 자꾸 끊긴다`	읽을 자원과 검색 결과를 같은 연결 관점으로 넘길 수 있는가?
`호출은 됐는데 다음 단계가 또 따로 가공을 요구한다`	반환값도 다음 단계가 바로 읽을 수 있는 공통 형식인가?
`도구 추가가 왜 이렇게 비싸지?`	새 도구를 같은 인터페이스 안에 넣기 쉬운가?

먼저 익혀야 하는 기준은 단순합니다. MCP는 모델을 더 똑똑하게 만드는 기능이 아니라, 도구 설명, 자원 접근, 요청/응답 형식을 덜 제각각으로 만들어 연결 불안정을 줄이는 공통 인터페이스 관점입니다.

연습 및 예제¶

예제의 목표는 실제 프로토콜 전체를 구현하는 것이 아니라, 공식 Python SDK에서 MCP 서버가 도구(tool)와 자원(resource)을 어떤 형식으로 노출하는지 보는 것입니다. 이 예제는 Python 3.10 이상과 mcp Python SDK가 필요합니다. 설치되어 있지 않다면 pip install "mcp[cli]>=1.27,<2"로 안정 릴리스 계열을 설치한 뒤 실행합니다.

아래 코드에서 먼저 볼 것은 두 가지입니다. @mcp.tool()로 등록한 함수는 실행 가능한 도구로 노출되고, @mcp.resource("policy://refund/latest")로 등록한 함수는 읽을 수 있는 자원으로 노출됩니다. 즉, 에이전트가 외부 시스템을 마음대로 직접 아는 것이 아니라, 서버가 공개한 도구 이름, 입력 형식, 자원 URI를 연결 대상으로 보게 됩니다.

from pprint import pprint

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("AiBook MCP demo", json_response=True)

POLICY_INDEX = {
    "refund": "policy://refund/latest",
    "security": "policy://security/baseline",
}
POLICY_TEXT = {
    "policy://refund/latest": "Latest refund policy: request review before final reply.",
    "policy://security/baseline": "Security baseline: approval is required for account changes.",
}

@mcp.tool()
def search_policy(query: str) -> list[dict[str, str]]:
    """Search policy resources by keyword."""
    hits = [
        {"keyword": keyword, "resource_uri": uri}
        for keyword, uri in POLICY_INDEX.items()
        if keyword in query.lower()
    ]
    return hits

@mcp.resource("policy://refund/latest")
def refund_policy() -> str:
    """Read the latest refund policy resource."""
    return POLICY_TEXT["policy://refund/latest"]

request = {"query": "refund rule for a customer support answer"}
tool_result = search_policy(**request)
resource_uri = tool_result[0]["resource_uri"]
resource_text = POLICY_TEXT[resource_uri]

print("[mcp server exposes]")
pprint(
    {
        "tools": ["search_policy(query: str)"],
        "resources": ["policy://refund/latest"],
    }
)
print("[tool call]")
pprint({"name": "search_policy", "arguments": request, "result": tool_result})
print("[resource read]")
pprint({"uri": resource_uri, "text": resource_text})

실행 결과 예시는 다음처럼 읽을 수 있습니다.

[mcp server exposes]
{'resources': ['policy://refund/latest'],
 'tools': ['search_policy(query: str)']}
[tool call]
{'arguments': {'query': 'refund rule for a customer support answer'},
 'name': 'search_policy',
 'result': [{'keyword': 'refund', 'resource_uri': 'policy://refund/latest'}]}
[resource read]
{'text': 'Latest refund policy: request review before final reply.',
 'uri': 'policy://refund/latest'}

이 출력에서 search_policy(query: str)는 실행할 수 있는 도구이고, policy://refund/latest는 읽을 수 있는 자원입니다. 중요한 점은 함수 내부 계산보다, 도구 이름과 입력 형식, 자원 URI가 서버에 등록된다는 데 있습니다. 실제 MCP 클라이언트는 이런 서버 노출 정보를 기준으로 도구와 자원을 발견하고 호출합니다. MCP가 정리하는 것은 환불 정책을 잘 요약하는 능력이 아니라, 환불 정책을 찾는 도구와 읽을 자원을 어떤 공통 형식으로 드러낼지입니다.

같은 원리를 여러 요청으로 확장하면 연결 형식의 차이가 더 분명해집니다. 아래 그래프는 SDK 사용법을 설명하려는 그림이 아니라, 도구·자원 노출 형식이 일관될 때와 흔들릴 때를 비교하는 보조 실험입니다. 도구 카탈로그 CSV p6-15-1-mcp-tool-catalog.csv, 자원 카탈로그 CSV p6-15-1-mcp-resource-catalog.csv, 요청 CSV p6-15-1-mcp-connection-requests.csv를 사용해 36개 요청을 공통 연결 계층(common_layer)과 제각각 연결 계층(mixed_layer)에 흘려 보내고, 요청 완료, 연결 준비, 도구 해석, 자원 해석이 어디서 갈리는지 비교합니다.

MCP 연결 계층 점검

이 차트는 공통 연결 계층과 제각각 연결 계층의 차이를 요청 완료, 연결 준비, 도구 해석, 자원 해석으로 나누어 보여 줍니다. 공통 연결 계층에서도 승인과 입력 누락 때문에 완료 수는 19건에 머물지만, 연결 준비는 36건 모두 통과합니다. 반대로 제각각 연결 계층은 도구와 자원을 어느 정도 찾더라도 입력 형식과 자원 타입이 흔들려 연결 준비와 요청 완료가 급격히 줄어듭니다.

이 그래프에서 확인해야 할 결과는 모델이나 에이전트가 외부 시스템을 제각각 직접 다루는 것이 아니라, 도구와 리소스를 공통 인터페이스로 드러내는 연결 계층을 통해 접근한다는 점입니다.

이 절에서 직접 바꿔 볼 수 있는 조정은 다음과 같습니다.

SDK 예제에서 security가 들어간 질문으로 search_policy()를 호출해 다른 자원 URI가 반환되는지 보기
SDK 예제에 @mcp.tool() 도구를 하나 더 추가하고, 도구 이름과 입력 형식이 출력 설명에 어떻게 반영되는지 보기
CSV 보조 실험에서 mixed_layer의 도구 하나에만 input_schema를 추가해도 전체 일관성이 왜 아직 깨지는지 확인하기

여기서 한 단계 더 가면, MCP가 직접 정리하는 문제와 아직 하네스나 운영으로 넘겨야 하는 문제를 분리해 두는 편이 좋습니다.

상황	MCP가 직접 정리하는 것	MCP만으로는 아직 남는 것
도구마다 이름과 입력 형식이 제각각임	공통 이름, 입력 형식, 자원 타입 노출	실행 trace 저장, replay, 평가 기록
자원 접근 방식이 시스템마다 다름	읽기 가능한 자원과 실행 가능한 도구를 같은 연결 층에서 드러냄	어떤 실행이 실제로 안전했는지의 판정
새 도구를 추가할 때 연결이 자주 깨짐	연결 형식을 일정하게 유지해 추가 비용을 낮춤	승인 게이트, 실패 복구, 비용 통제
모델 성능 문제인지 연결 문제인지 헷갈림	연결 해석 실패를 모델 내부 성능 문제와 분리	연결이 된 뒤 품질과 운영을 어떻게 관리할지

이 표의 핵심은 MCP가 연결을 일정하게 만드는 층이지, 실행을 기록하거나 품질을 판정하는 층이 아니라는 점입니다. 하네스는 같은 연결을 실제 실행 trace와 replay로 남기고, 평가와 운영은 그 기록을 품질 판단과 통제 조치로 읽습니다.

도구 개수보다 연결 형식¶

이 축약된 연결 구조는 도구가 많아지는 시대에 중요한 것이 도구 개수보다 어떻게 같은 방식으로 연결하느냐라는 점을 보여 줍니다. MCP 관점은 도구를 더 많이 붙이는 기술이 아니라 붙인 도구들을 같은 방식으로 읽고 호출하게 만드는 연결 규칙입니다. 더 중요하게 붙잡아야 할 점은 모델이 무엇을 말하는가와 그 모델이 어떤 시스템과 어떤 형식으로 연결되는가가 같은 문제가 아니라는 것입니다.

체크리스트¶

MCP를 새 모델 능력이 아니라 도구와 자원을 공통 형식으로 드러내는 연결 인터페이스 관점으로 설명할 수 있어야 합니다.
모델 문제와 연결 문제를 다른 층위로 나눠 봐야 한다는 점을 말할 수 있어야 합니다.
연결된 실행은 다시 어떤 기록과 재현 환경 안에서 관리할지의 문제로 이어진다는 점을 잡고 있어야 합니다.

출처와 참고 자료¶

Model Context Protocol, What is the Model Context Protocol (MCP)?, 확인 날짜: 2026-07-19.
OpenAI, MCP and Connectors, OpenAI API Docs, 확인 날짜: 2026-07-19.
OpenAI, Using tools, OpenAI API Docs, 확인 날짜: 2026-07-19.