18. 호스트 통합과 컨텍스트 비용, 여러 서버 다루기

17장이 "클라이언트가 서버를 어떻게 부르나"였다면, 이 장은 한 단계 위 — 호스트(LLM을 품은 앱) 안에서 서버들이 어떻게 어울리고, 그게 서버 설계에 어떤 제약을 거는가입니다. 서버 제작자가 자주 놓치는 부분입니다.

도구 스키마는 공짜가 아니다

핵심 통찰부터: 모델에 노출된 모든 도구의 정의(name·description·inputSchema)는 모델의 컨텍스트 윈도를 차지합니다. 호스트는 모델이 "어떤 도구를 부를지" 판단하게 하려고, 사용 가능한 도구 스키마를 프롬프트(또는 그에 준하는 자리)에 넣습니다. 도구가 늘수록 그 텍스트가 커지고, 컨텍스트와 비용(토큰)을 먹습니다.

flowchart TD
    subgraph CTX["모델 컨텍스트 윈도 (유한)"]
        SYS["시스템 프롬프트"]
        TOOLS["도구 스키마 N개\n(name+description+inputSchema)"]
        HIST["대화 기록"]
        ROOM["남는 공간"]
    end
    TOOLS -.->|"N이 커지면"| SHRINK["남는 공간 축소\n비용↑ 혼란↑"]
    classDef ctx fill:#bfdbfe,stroke:#1d4ed8,color:#000;
    classDef warn fill:#fca5a5,stroke:#b91c1c,color:#000;
    class SYS,TOOLS,HIST,ROOM ctx;
    class SHRINK warn;

도구가 너무 많을 때 — 세 가지 문제

여러 서버를 동시에 붙이면(호스트는 흔히 그렇게 함) 도구 수가 금세 수십~수백 개가 됩니다. 그때 생기는 문제:

1. 선택 혼란: 비슷한 도구가 많으면 모델이 엉뚱한 걸 고르거나 머뭇거립니다. 이름·설명이 모호하면 더합니다.
2. 컨텍스트·비용 팽창: 위에서 본 대로 스키마가 토큰을 먹어, 정작 작업에 쓸 공간과 예산이 줄어듭니다.
3. 이름 충돌·모호성: 서로 다른 서버가 search, create, delete 같은 흔한 이름을 쓰면 모델이 혼동합니다.

리소스는 모델이 직접 못 본다 (복습 + 설계 함의)

11장에서 본 현실을 호스트 관점에서 다시 짚습니다. 리소스 접근은 클라이언트 측 동작이라, 모델은 도구처럼 리소스를 자동으로 끌어오지 못합니다. 호스트마다 처리도 달라서 — 사용자가 명시적으로 고르게 하거나, 휴리스틱으로 자동 주입하거나, 모델에게 고르게 하거나 합니다.

설계 함의: 모델이 자동으로 써야 하는 데이터라면 도구로 (또는 리소스+도구 래핑으로) 노출하세요. "리소스로만 노출했는데 모델이 안 쓴다"는 흔한 혼란은 이 차이에서 옵니다.

서버 제작자를 위한 "좋은 시민" 지침

호스트 안에서 다른 서버들과 잘 어울리는 서버를 만들려면:

• 도구는 적게, 응집도 높게: 한 서버가 모든 걸 하려 들지 말고, 명확한 책임 범위를 갖습니다.
• 이름은 구체적·고유하게: 흔한 동사 단독(search)보다 도메인 맥락을 담아(search_issues). title로 사람용 표시명을 줍니다.
• 설명은 모델용 UX: "언제 이 도구를 쓰는지/안 쓰는지"를 명확히. 입력 스키마에 Field(description=...)로 인자 의미를 설명(15장).
• 출력은 컨텍스트 친화적으로: 거대한 JSON을 통째로 쏟지 말고 요약·핵심·페이지네이션을 제공. 큰 데이터는 리소스 링크로.
• 얇고 대체로 무상태: 스펙·실무 관점 모두, MCP 서버는 내부 시스템 위의 인터페이스 계층이 되는 게 좋습니다. 자체적으로 두꺼운 상태 계층이 되기보다 얇게 유지하면 확장·운영이 쉽습니다(8부).

🔒 여러 서버 = 신뢰 표면 합산: 호스트가 서버 여러 개를 붙이면, 한 악성·취약 서버가 다른 서버의 맥락에 영향을 줄 수 있습니다(예: 한 서버의 도구 설명에 숨긴 지시가 모델 행동을 오염). 제작자는 자기 서버를 견고하게 만들고, 호스트/사용자는 신뢰할 수 있는 서버만 함께 붙여야 합니다. 1차 벤더 선호·런타임 감사는 21장에서 다룹니다.

호스트 통합의 큰 그림

flowchart TB
    subgraph HOST["Host (LLM 앱)"]
        LLM["LLM\n(컨텍스트 예산 관리)"]
        UI["동의·도구 노출 UI"]
        C1["Client → Server A"]
        C2["Client → Server B"]
        C3["Client → Server C"]
    end
    SA["파일 서버"]
    SB["GitHub 서버"]
    SC["DB 서버"]
    C1 <--> SA
    C2 <--> SB
    C3 <--> SC
    LLM -.->|"도구 스키마가 컨텍스트 차지"| LLM
    classDef host fill:#fef3c7,stroke:#a16207,color:#000;
    classDef client fill:#fde68a,stroke:#b45309,color:#000;
    classDef server fill:#5eead4,stroke:#0f766e,color:#000;
    class LLM,UI host;
    class C1,C2,C3 client;
    class SA,SB,SC server;

호스트는 (1) 어떤 서버에 붙을지 관리하고, (2) 각 서버의 도구를 모델에 어떻게·얼마나 노출할지 정하고, (3) 사용자 동의와 도구 호출 승인을 중재하고, (4) 컨텍스트 예산을 관리합니다. 서버 제작자는 이 모든 제약 안에서 자기 서버가 매력적인 선택이 되도록 설계합니다.

이 장에서 배운 것

• 도구 스키마는 모델의 컨텍스트 윈도를 소비한다. 도구가 많을수록 비용↑·선택 혼란↑.
• 완화책: 도구를 적게·명확하게, 이름에 도메인 접두, 출력은 컨텍스트 친화적으로, 서버는 얇고 무상태로.
• 모델이 자동으로 쓸 데이터는 도구로 노출한다(리소스는 모델이 직접 못 부름).
• 여러 서버는 신뢰 표면을 합산한다 — 견고한 서버 설계와 신뢰 가능한 서버 선택이 함께 필요.

✍️ 확인 문제

1. "도구를 많이 노출할수록 좋은 서버"라는 생각의 두 가지 문제점을 들어 보자.
2. 세 서버가 모두 search라는 도구를 노출한다. 제작자로서 무엇을 바꿔야 모델 혼란을 줄일 수 있나?
3. 사내 위키 문서를 "모델이 알아서 참고"하게 하려면, 리소스와 도구 중 무엇으로 노출해야 하나? 이유는?

6부 끝. 다음은 7부 · 인증과 보안(19장 OAuth)으로 이어집니다. 보안을 1급 주제로 깊이 다룹니다.