3.7연결 방식 선택

연결 방식을 고를 때 실제로 비교해야 하는 축은 누가 그것을 소유하고 누가 재사용하는가입니다. 기술적 차이보다 이 축이 결정을 좌우합니다.

방식	소유 주체	재사용 범위	결합도
직접 정의 툴	이 애플리케이션	이 애플리케이션만	높음
MCP 서버	별도 서비스	연결하는 모든 클라이언트	낮음
에이전트 간 위임	별도 에이전트	위임 가능한 모든 오케스트레이터	낮음, 단 비용 큼

직접 정의 툴은 가장 단순합니다. 애플리케이션 코드가 툴 함수를 갖고 있고 호출도 직접 합니다. 배포 단위가 하나라 운영이 가볍고, 자격 증명을 애플리케이션 쪽에 두기 쉽습니다. 대신 다른 팀이 같은 기능을 쓰려면 코드를 복사해야 합니다.

MCP 서버는 기능을 표준 인터페이스 뒤로 분리합니다. 여러 클라이언트가 같은 서버에 연결해 같은 툴을 씁니다. 조직에 같은 데이터에 접근하는 에이전트가 여럿이면 이쪽이 맞습니다. 대신 서버를 별도로 배포·운영·인증해야 합니다.

에이전트 간 위임은 기능이 아니라 판단을 넘기는 것입니다. 툴은 정해진 일을 하지만 위임받은 에이전트는 스스로 계획하고 여러 단계를 밟습니다. 넘기는 것이 "이 API를 호출해줘"가 아니라 "이 문제를 조사해줘"일 때 맞습니다.

세 방식은 배타적이지 않습니다. 실제 시스템은 대개 섞어 씁니다 — 자체 로직은 직접 툴로, 공용 데이터 접근은 MCP로, 넓은 조사 작업은 서브에이전트로.

선택을 감각이 아니라 기준으로 하려면 네 가지를 순서대로 묻습니다.

1. 다른 클라이언트도 이 기능을 쓰는가? 쓴다면 MCP 쪽으로 기울어집니다. 이 애플리케이션만 쓴다면 직접 정의가 단순합니다. 다만 "언젠가 쓸지도 모른다"는 이유로 MCP를 고르면 운영 부담만 먼저 옵니다.

2. 호출자가 자격 증명을 소유해야 하는가? 민감한 키를 애플리케이션 프로세스 안에 두고 싶다면 직접 정의 툴이 유리합니다. MCP로 분리하면 자격 증명도 서버 쪽으로 옮겨가고, 클라이언트와 서버 사이의 인증이 새로 필요해집니다.

3. 작업이 다단계 판단을 요구하는가? 정해진 입출력이면 툴입니다. 여러 단계를 스스로 계획해야 하면 에이전트 위임을 검토합니다. 판단 기준은 호출 결과를 미리 스키마로 정의할 수 있는가입니다. 정의할 수 있으면 툴로 충분합니다.

4. 왕복과 컨텍스트 비용을 감당할 수 있는가? 에이전트 위임은 가장 비쌉니다. 위임받은 쪽이 맥락을 다시 세우고, 작업하고, 보고하고, 오케스트레이터가 그 보고를 다시 읽습니다. 몇 번의 툴 호출로 끝날 일을 위임하면 순손실입니다.

[결정 흐름]
스키마로 정의 가능한 결과인가?
├─ 아니오 → 에이전트 위임 (독립적이고 규모가 큰 작업일 때만)
└─ 예 → 다른 클라이언트도 쓰는가?
         ├─ 예 → MCP 서버
         └─ 아니오 → 직접 정의 툴

이 흐름에서 자주 나오는 오답은 "표준이니까 MCP" 와 "에이전트니까 위임" 입니다. 둘 다 기준이 아니라 유행에 따른 선택이고, 운영 복잡도와 비용을 근거 없이 늘립니다.

MCP를 고르면 따라오는 것들이 있습니다. 선택 단계에서 이 비용을 함께 계산해야 정직한 비교가 됩니다.

선언의 짝 요건. 서버를 선언하는 것만으로는 툴이 붙지 않습니다. 서버 목록과 그 서버를 참조하는 툴셋 항목이 짝으로 있어야 합니다. 한쪽만 넣으면 검증 오류가 납니다.

mcp_servers = [
    {"type": "url", "name": "internal-docs", "url": "https://mcp.example.com/sse"},
]
tools = [
    {"type": "mcp_toolset", "mcp_server_name": "internal-docs"},  # 이름이 일치해야 한다
]

자격 증명의 분리. 서버 선언에는 인증 정보를 넣지 않는 것이 원칙입니다. 자격 증명은 별도 저장소에 두고 세션에 연결하는 구조라야, 재사용 가능한 에이전트 정의에 비밀이 섞이지 않습니다. 3.2에서 다룬 원칙이 그대로 적용됩니다.

주의할 점은 MCP 인증과 그 서비스의 일반 API 키가 다른 체계일 수 있다는 것입니다. 서비스의 REST API용 토큰이 그 서비스의 MCP 서버에는 통하지 않는 경우가 흔합니다. 연결이 안 될 때 흔히 헤매는 지점입니다.

네트워크 허용. 실행 환경이 제한 모드라면 MCP 서버 도메인이 나갈 수 있도록 허용해야 합니다. 이것을 빠뜨리면 툴이 조용히 실패하는데, 오류가 네트워크 문제로 보이지 않아 진단이 오래 걸립니다.

응답 크기. MCP 툴의 반환값이 크면 컨텍스트를 잠식합니다. 서버 쪽에서 필요한 필드만 돌려주도록 설계하는 것이 좋고, 매우 큰 출력은 파일로 떨어뜨리고 경로만 반환하는 방식이 쓰입니다.

툴 수의 증가. MCP 서버 하나를 붙이면 그 서버의 툴이 전부 목록에 들어옵니다. 서버를 여럿 붙이면 3.1에서 다룬 선택지 비대화가 빠르게 진행됩니다. 서버 단위가 아니라 툴 단위로 활성화 범위를 좁히는 구성을 검토해야 합니다.

에이전트 간 위임은 강력하지만 손익 계산이 명확해야 합니다.

이득이 나는 경우.

• 작업이 독립적으로 병렬화 됩니다. 조사할 대상이 열 개이고 서로 무관하면 열 갈래로 나눠 동시에 진행할 수 있습니다.
• 위임받은 쪽이 읽기 작업으로 컨텍스트를 채웁니다. 오케스트레이터가 직접 읽으면 자기 컨텍스트가 자료로 가득 차지만, 위임하면 결과 보고만 돌아옵니다.
• 역할마다 필요한 툴 집합이 다릅니다. 좁은 권한의 전문 에이전트를 여럿 두면 3.1의 최소 권한이 자연스럽게 지켜집니다.

손해가 나는 경우.

• 몇 번의 툴 호출로 끝날 작은 작업. 위임 왕복이 작업보다 큽니다.
• 검증이나 재확인 목적. 이런 것은 오케스트레이터 자신의 루프 안에서 하는 편이 빠릅니다.
• 하나의 작은 작업을 여러 조각으로 쪼개는 것. 조각마다 맥락을 다시 세워야 해서 순손실입니다.

설계상 반드시 기억할 것은 위임받은 에이전트가 오케스트레이터의 대화를 보지 못한다는 점입니다. 파일 시스템은 공유해도 대화 이력은 공유되지 않습니다. 따라서 위임하는 지시에는 필요한 경로·제약·보고 형식이 전부 담겨 있어야 합니다. "아까 말한 그 파일"은 전달되지 않습니다.

[나쁜 위임 지시]
"아까 찾은 문제들을 정리해줘"

[좋은 위임 지시]
"/workspace/logs/2026-08-11.log 에서 timeout 으로 끝난 요청을 찾아,
요청 ID·발생 시각·직전 호출 툴 세 가지를 표로 정리해 보고하라.
파일을 수정하지 말고 읽기만 하라."

위임 정책은 시스템 프롬프트에 명시해야 합니다. 무엇을 넘기고 무엇을 직접 하는지, 동시에 몇 개까지 띄우는지를 적어두지 않으면 과잉 위임이나 과소 위임 어느 한쪽으로 기웁니다.