MCP 리소스와 도구: 차이점과 각각의 사용 시기는?

Model Context Protocol(MCP)은 AI 애플리케이션이 모델을 외부 컨텍스트 및 기능과 연결할 수 있는 표준 방식을 제공합니다. MCP 서버를 구축하는 개발자에게 가장 중요한 설계 결정은 종종 놀랄 만큼 단순합니다. 기능을 리소스로 노출해야 할까요, 아니면 도구로 노출해야 할까요?

이 구분은 에이전트가 정보를 발견하는 방식, 토큰을 소비하는 시점, 변경할 수 있는 대상, 그리고 사용자가 위험을 평가하는 방식에 영향을 줍니다. 잘못 모델링된 기능은 통합을 이해하기 어렵게 만들 수 있습니다. 정적 참조 데이터가 불필요한 함수 호출이 되거나, 중요한 작업이 무해한 컨텍스트처럼 보일 수 있습니다.

실무적으로 MCP 리소스는 애플리케이션이 AI 시스템에 제공할 수 있는 읽기 전용 정보를 제공합니다. MCP 도구는 모델이 요청할 수 있는 실행 가능한 작업을 노출합니다. 이 둘의 경계를 이해하는 것은 신뢰할 수 있고 안전하며 토큰 효율적인 MCP 서버 개발의 기본입니다.

MCP에서 리소스와 도구의 구분이 중요한 이유

AI 에이전트에는 정보와 행동할 수 있는 능력이 모두 필요합니다. 그러나 정보 검색과 작업 실행은 서로 다른 신뢰 모델을 가집니다.

모델은 가능한 쿼리를 이해하기 위해 데이터베이스 스키마가 필요할 수 있습니다. 이후 승인된 쿼리를 실행하기 위한 별도의 기능이 필요할 수 있습니다. 이 둘을 동일한 유형의 통합으로 취급하면 의도가 모호해지고, 권한 관리가 복잡해지며, 과도한 컨텍스트 사용으로 이어질 수 있습니다.

리소스와 도구의 구분이 중요한 이유는 다음을 명확히 하기 때문입니다.

• 에이전트 동작: 모델은 작업을 요청하는 것과 별개로 안정적인 컨텍스트를 검사할 수 있습니다.
• 보안 경계: 읽기 권한과 쓰기 권한을 서로 다르게 검토, 범위 지정 및 관리할 수 있습니다.
• 사용자 신뢰: 사용자는 에이전트가 시스템에 대해 학습하는 것과 해당 시스템을 변경하는 것을 구분할 수 있습니다.
• 토큰 효율성: 관련 컨텍스트는 모든 프롬프트에 무차별적으로 삽입하는 대신 필요할 때 가져올 수 있습니다.
• 서버 설계: 기능의 이름 지정, 문서화, 테스트 및 유지 관리가 더 쉬워집니다.

MCP는 사용 가능한 모든 리소스가 자동으로 모델 컨텍스트에 배치된다는 의미가 아닙니다. 리소스는 MCP 기능 모델을 통해 사용할 수 있으며, 호스트 애플리케이션이 이를 표시하거나 읽는 방법과 시점을 결정합니다. 사용 가능한 정보가 광범위하거나 민감하거나 로드 비용이 클 때 이러한 호스트 제어 방식은 필수적입니다.

MCP 리소스란 무엇인가요?

MCP 리소스는 MCP 서버가 노출하는 읽기 전용 URI 기반 컨텍스트 조각입니다. AI 시스템이 작업을 완료하는 동안 검사, 요약, 추론 또는 인용해야 할 수 있는 정보를 위해 설계되었습니다.

리소스는 단순히 임의의 파일이나 일반적인 API 엔드포인트가 아닙니다. Model Context Protocol에서 이는 일반적으로 URI로 식별되는, 발견 가능한 컨텍스트 데이터 단위입니다. 서버는 문서, 구성, 스키마, 프로젝트 메타데이터, 지식 베이스 페이지 또는 생성된 상태 정보를 나타내는 리소스를 노출할 수 있습니다.

일반적인 예로는 리포지토리 아키텍처 가이드, `README` 파일, OpenAPI 스키마, 데이터베이스 테이블 정의 또는 배포 환경의 현재 구성이 있습니다. 이러한 정보는 에이전트가 작업을 제안하거나 수행하기 전에 시스템의 상태와 규칙을 이해하도록 돕기 때문에 유용합니다.

프로토콜 수준에서 서버는 `resources/list`를 통해 사용 가능한 컨텍스트를 알릴 수 있습니다. 그런 다음 클라이언트는 `resources/read`를 통해 특정 항목을 가져올 수 있습니다. 이 분리를 통해 호스트와 에이전트는 콘텐츠 자체를 로드하기 전에 사용 가능한 항목을 확인할 수 있습니다.

리소스는 답변이 기존의 안정적인 정보에서 도출되어야 할 때 특히 유용합니다. 예를 들어 익숙하지 않은 서비스를 검토하는 에이전트는 통합을 제안하기 전에 서비스의 API 계약이 포함된 리소스를 읽을 수 있습니다. 리소스는 근거와 컨텍스트를 제공할 뿐, 변경을 수행하지는 않습니다.

MCP 도구란 무엇인가요?

MCP 도구는 모델이 MCP 서버를 통해 발견하고 호출할 수 있는 실행 가능한 기능입니다. 이는 작업, 즉 에이전트가 연결된 시스템에 수행하도록 요청할 수 있는 일을 나타냅니다.

도구는 API 요청을 수행하거나, 이슈를 생성하거나, 배포 검사를 실행하거나, 보고서를 생성하거나, 메시지를 보내거나, 데이터베이스에 쓸 수 있습니다. 많은 도구에는 부작용이 있을 수 있지만, 부작용이 필수 요건은 아닙니다. 예를 들어 읽기 전용 데이터베이스 쿼리도 입력, 실행 로직 및 구조화된 결과를 갖춘 작업이라면 도구로 올바르게 모델링할 수 있습니다.

서버는 `tools/list`를 통해 도구 정의를 노출합니다. 각 정의는 명확한 이름, 설명 및 입력 스키마를 전달해야 합니다. 모델은 도구가 예상하는 입력과 일치하는 인수를 제공하여 `tools/call`을 통해 선택된 기능을 호출합니다.

핵심 설계 원칙은 도구가 서버에 작업 수행을 요청한다는 것입니다. 그 출력은 데이터일 수 있지만, 해당 데이터는 직접 주소 지정 가능한 컨텍스트 아티팩트가 아니라 실행의 결과입니다.

예를 들어 `create_linear_ticket`은 외부 워크플로가 새 티켓을 생성하게 하므로 도구입니다. 서버가 제공된 환경 및 서비스 매개변수를 사용하여 실시간 시스템을 쿼리해야 하는 경우 `get_deployment_status`도 도구가 될 수 있습니다. 두 작업 모두 명시적인 호출이 필요하지만, 반드시 상태를 변경하는 작업은 하나뿐입니다.

MCP 리소스와 도구: 주요 차이점

이 표는 실용적인 경계를 보여 줍니다. 리소스는 정보를 설명하거나 노출하는 반면, 도구는 동작을 실행합니다. 잘 설계된 MCP 서버에서는 두 기능이 동일한 더 넓은 워크플로를 지원하더라도 이러한 구분이 유지됩니다.

리소스와 도구 중 선택하는 방법

한 가지 질문에서 시작하세요. 에이전트가 정보를 검사해야 하나요, 아니면 서버가 작업을 수행해야 하나요?

정보가 읽기 전용이고, 자연스럽게 주소를 지정할 수 있으며, 컨텍스트로 유용하다면 리소스를 사용하세요. 구성 파일, 제품 사양, 정책 문서 또는 데이터베이스 스키마는 일반적으로 이 모델에 적합합니다. 클라이언트는 항목을 검색하고, 관련성이 있는지 판단하며, 비즈니스 로직을 실행하지 않고 읽을 수 있습니다.

작업에 입력, 실행 또는 정적 컨텍스트로 표현할 수 없는 결과가 필요하다면 도구를 사용하세요. 지원 티켓 생성, 필터링된 보고서 가져오기, 빌드 시작 또는 레코드 업데이트는 도구로 제공해야 합니다.

일부 워크플로에는 두 가지 기본 요소가 모두 필요합니다. 릴리스 관리 통합을 예로 들어 보겠습니다:

1. 릴리스 정책과 환경 정의를 리소스로 노출합니다. 2. 선택한 서비스의 실시간 배포 상태를 가져오는 도구를 제공합니다. 3. 승인된 배포를 실행하는 별도의 도구를 제공합니다.

이 설계를 통해 에이전트는 먼저 정책과 환경 제약 조건을 이해하고, 그다음 현재 운영 데이터를 요청하며, 그 후에야 중요한 작업을 요청할 수 있습니다. 이러한 분리는 사용자가 감사하기 쉽고 제품 팀이 보안을 적용하기도 쉽습니다.

모든 쿼리를 리소스로 만들지 마세요. 정보가 동적이거나 매개변수화되어 있거나 계산 비용이 높다면 일반적으로 도구가 더 적합합니다. 반대로 URI 기반 리소스가 목적을 더 명확하게 보여 줄 수 있는데도 단순하고 안정적인 참조 콘텐츠를 도구로 감싸는 일은 피하세요.

실용적인 MCP 서버 설계 예시

리포지토리 문서 서버는 코딩 표준, 아키텍처 의사결정 기록 및 서비스 소유권 맵을 리소스로 노출할 수 있습니다. 이러한 항목은 예측 가능한 주소를 가진 유용한 참조 자료입니다. `search_repository_docs` 기능은 키워드를 받고 대규모 문서 컬렉션 전체에서 대상 검색을 실행한다면 도구가 될 수 있습니다.

데이터베이스 통합의 경우 테이블 스키마와 승인된 데이터 사전은 리소스로 적합합니다. `run_readonly_query` 기능은 쿼리 또는 구조화된 필터를 받고, 이를 검증하고, 실시간 시스템에서 실행한 뒤 결과를 반환하므로 도구로 모델링하는 것이 더 좋습니다. 별도의 쓰기 도구는 동일한 모호한 인터페이스 뒤에 절대 숨겨서는 안 됩니다.

프로젝트 관리 통합도 동일한 패턴을 따릅니다. 리소스는 스프린트 보드의 워크플로 정의 또는 이슈 레이블 분류 체계를 제공할 수 있습니다. 도구는 티켓을 생성하고, 상태를 업데이트하거나, 담당자를 지정할 수 있습니다. 정보는 에이전트가 충분한 정보를 바탕으로 요청하도록 돕고, 도구는 요청된 변경을 수행합니다.

보고서 생성은 또 다른 유용한 경계 사례입니다. 고정된 분기별 보고서 템플릿은 리소스가 될 수 있습니다. `generate_quarterly_report` 작업은 기간을 받고, 실시간 데이터를 선택하며, 비즈니스 로직을 적용하고, 결과물을 생성하므로 도구입니다. 생성된 보고서는 다른 에이전트가 검사해야 하는 안정적인 아티팩트가 되면 나중에 리소스로 노출할 수 있습니다.

기술 업무에서 프레젠테이션으로 이어지는 워크플로에 Pi MCP 사용하기

Presentation Intelligence (Pi)는 기술 업무를 명확한 이해관계자 커뮤니케이션으로 전환해야 하는 팀을 위한 MCP 워크플로를 지원합니다. Pi MCP는 코드 편집기, 소스 제어, 데이터베이스 또는 기타 MCP 서버를 대체하지 않습니다. 이는 제공 프로세스의 고유한 단계를 다룹니다. 즉, 승인된 기술 컨텍스트를 구조화되고 비즈니스에 적합한 프레젠테이션으로 변환합니다.

1. 비즈니스 로직이 슬라이드 스타일링보다 우선합니다

Claude Code와 같은 AI 코딩 또는 에이전트 환경에서는 팀이 강력한 프레젠테이션을 위한 원자료를 이미 보유한 경우가 많습니다. 기술 브리프, 프로젝트 메모, 아키텍처 설명, 릴리스 요약 및 코드베이스에서 도출된 인사이트가 그 예입니다. 과제는 이러한 자료를 서로 연결되지 않은 슬라이드 모음이 아니라 청중에 적합한 내러티브로 전환하는 것입니다.

Pi MCP를 사용하면 에이전트 워크플로가 정의된 브리프 또는 승인된 컨텍스트를 Presentation Intelligence에 전달하여 로직 우선의 프레젠테이션 구조를 만들 수 있습니다. 이는 스토리라인이 기반 구현만큼 신뢰할 수 있어야 하는 엔지니어링 로드맵 업데이트, 경영진 프로젝트 검토, 기술 영업 자료, 컨설팅 보고서 및 제품 출시 내러티브에 유용합니다.

2. 생성 과정이 기존 워크플로에서 계속 보입니다

그렇지 않으면 프레젠테이션 제작을 위해 개발자와 제품 팀이 작업 환경을 떠나 기술 메모를 수동으로 재구성하고, 별도의 제작 프로세스를 반복적으로 확인해야 할 수 있습니다. Pi MCP를 통해 팀은 기존 에이전트 워크플로 내에서 프레젠테이션 작업을 시작하고 생성 진행 상황을 추적할 수 있습니다.

자료가 변화하는 프로젝트 컨텍스트에 의존할 때 이러한 연속성은 중요합니다. 팀은 커뮤니케이션을 사후 고려 사항으로 취급하지 않고 브리프를 개선하고, 청중의 요구를 명확히 하며, 프레젠테이션 워크플로를 모니터링할 수 있습니다. Pi의 Multi-Agent AI 접근 방식은 팀이 공유할 컨텍스트에 대한 제어를 유지하면서 복잡한 입력을 전문적인 구조와 고품질 비즈니스 프레젠테이션 결과물로 전환하도록 지원합니다.

안전하고 토큰 효율적인 MCP 통합을 위한 모범 사례

훌륭한 MCP 서버 개발은 범위가 좁고 이해하기 쉬운 기능에서 시작됩니다. 리소스는 에이전트가 실제로 필요로 하는 정보로 범위를 제한하세요. 방대하고 구분되지 않은 지식 덤프는 의사결정을 개선하지 못한 채 토큰을 소비할 수 있습니다. 의미 있는 URI, 명확한 설명 및 예측 가능한 경계를 갖춘 더 작은 리소스를 선호하세요.

도구에는 정확한 이름과 명시적인 입력 스키마를 사용하세요. `create_customer_ticket`은 `manage_ticket`보다 더 많은 정보를 전달하며, 제목, 우선순위 및 고객 ID를 구분하는 스키마는 모호성을 줄입니다. 에이전트가 같은 도구를 반복 호출하지 않고 무슨 일이 발생했는지 판단할 수 있도록 구조화되고 실행 가능한 결과를 반환하세요.

가능한 경우 읽기와 쓰기 작업을 분리하세요. 시스템을 검사하고 변경하는 도구는 권한 검토를 더 어렵게 만듭니다. 레코드 삭제, 외부 메시지 전송 또는 프로덕션 배포 실행처럼 작업이 중요한 결과를 초래하는 경우 최소 권한 액세스를 적용하고 호스트 환경에서 적절한 사용자 확인을 요구하세요.

마지막으로 점진적 공개를 고려해 설계하세요. 에이전트가 먼저 기능을 검색하고, 관련 리소스만 가져오며, 작업이 필요할 때만 도구를 호출하도록 하세요. 이 접근 방식은 토큰 낭비를 줄이고 민감한 데이터의 노출을 제한하며 에이전트의 추론 경로를 더 이해하기 쉽게 만듭니다.

실용적인 결론: 컨텍스트는 리소스로, 작업은 도구로 모델링하세요

MCP 설계를 위한 가장 신뢰할 수 있는 규칙은 간단합니다. 지속적이고 읽기 전용인 컨텍스트는 리소스로 노출하고, 실행 가능하며 매개변수화된 작업은 도구로 노출하세요. 이 경계는 보안 검토를 개선하고 에이전트 동작을 해석 가능하게 유지하며, 팀이 유용한 액세스를 희생하지 않고 컨텍스트 예산을 관리하도록 돕습니다.

복잡한 워크플로의 경우 가장 강력한 설계는 두 가지를 결합하는 경우가 많습니다. 리소스는 에이전트에 필요한 사실과 제약 조건을 제공하고, 도구는 이에 따라 행동할 수 있는 신중하게 관리되는 방법을 제공합니다. Pi MCP는 기술 커뮤니케이션에 동일한 패턴을 적용하여 팀이 업무가 이미 이루어지는 AI 환경 내에서 승인된 프로젝트 컨텍스트를 구조화된 프레젠테이션으로 전환하도록 돕습니다.