갱신 에이전트(renewal agent)는 CRM, 이메일, 캘린더, 지원(support), 문서 검색, 그리고 계약 시스템을 호출할 수 있습니다. 첫 실행 시, 에이전트는 한 명의 고객과 관련된 모든 정보를 모든 시스템에 요청합니다.

그 결과는 철저해 보입니다. 수백 개의 CRM 필드, 수년간의 티켓 이력, 전체 이메일 스레드, 그리고 여러 메시지에 첨부된 동일한 계약서 등이 나타납니다. 하지만 에이전트는 이제 갱신 작업을 진행하기 전에 어떤 기록이 중요한지 결정하는 데 시간과 토큰(tokens)을 소비해야 합니다.

에이전트는 연결성이 좋습니다. 하지만 동시에 더 느려지고, 더 비싸지며, 불확실성도 높아집니다.

도구를 추가하는 것은 에이전트가 접근할 수 있는 범위를 확장합니다. 하지만 그것이 에이전트가 올바른 기능을 선택하거나, 제한된 결과(bounded result)를 검색하거나, 작업을 완료할 수 있을 만큼 충분한 실행 예산(execution budget)을 보존할 수 있음을 보장하지는 않습니다.

도구 스키마(Tool schemas)는 첫 번째 호출 전부터 주의력(attention)을 소비합니다

LLM은 도구를 선택하기 전에 사용 가능한 각 도구의 이름, 설명, 그리고 입력 스키마(input schema)가 필요합니다. 여러 도구가 유사한 동작을 노출할 때, 선택은 라우팅(routing) 문제로 변합니다.

다음과 같은 광범위한 인터페이스를 생각해 보십시오:

{
  "name": "manage_account",
  "description": "계정에 대해 검색, 업데이트, 할당, 노트 추가, 단계 변경 또는 작업 생성",
...

유연해 보이지만, 매 호출마다 모델은 어떤 선택적 매개변수(optional parameters)의 조합이 의도한 동작을 나타내는지 추론해야 합니다. 그런 다음 검증(validation)과 권한(permissions)은 동일한 인터페이스 뒤에 숨겨진 모든 모드를 고려해야 합니다.

작업 중심의 읽기(task-shaped read)는 덜 야심 차게 구성됩니다:

{
  "name": "get_renewal_record",
  "description": "소스 타임스탬프를 포함하여 한 고객에 대한 승인된 갱신 뷰를 반환",
...

범위가 좁은 도구가 선택, 권한 부여, 테스트 및 복구(recover)하기에 더 쉽습니다. 이는 추가적인 오케스트레이션(orchestration) 단계를 요구할 수 있으며, 미래의 모든 계정 워크플로우를 커버하지는 못할 것입니다. 이것은 실제적인 트레이드오프(tradeoff)입니다. 이점은 지원되는 각 단계가 모호성을 덜 수 있다는 것입니다.

따라서 도구의 개수는 실행이 시작되기 전에 두 가지 비용을 발생시킵니다:

• 모든 스키마 (schema)가 컨텍스트 (context)를 점유합니다.
• 중복되는 설명은 라우팅 (routing)의 불확실성을 증가시킵니다.

연결된 시스템의 개수만을 보고하는 대시보드에서는 이러한 비용이 전혀 나타나지 않습니다.

연결성이 응답의 형태를 제어하지는 않습니다

CRM API가 계정에 대해 180개의 필드 (fields)를 반환한다고 가정해 보겠습니다. 갱신 (renewal) 결정을 내리는 데 필요한 필드는 다음 8개뿐입니다:

• 갱신 날짜 (renewal date);
• 계약 가치 (contract value);
• 계정 소유자 (account owner);
• 현재 단계 (current stage);
• 제품 세트 (product set);
• 공개된 상업적 리스크 (open commercial risks);
• 마지막으로 확인된 고객 연락 (last verified customer contact);
• 그리고 소스 타임스탬프 (source timestamps).

180개의 필드 전체를 모델에 전달하는 것은 데이터 선택 (data-selection) 문제를 워크플로 (workflow)에서 가장 비용이 많이 드는 부분으로 옮기는 것과 같습니다. 이메일 커넥터 (email connector)가 헤더 (headers)나 짧은 추출물 (short extracts) 대신 전체 메시지 본문을 반환할 때, 또는 문서 커넥터 (document connector)가 해당 문서를 참조하는 모든 메시지에 대해 동일한 첨부 파일을 매번 보낼 때도 동일한 문제가 발생합니다.

불필요한 값은 각각 무언가를 소비합니다. 모델 컨텍스트 (model context)에 배치될 때는 토큰 (tokens)을 사용하고, 컨텍스트 외부에 유지될 때는 저장 공간과 전송 비용을 사용하며, 에이전트 (agent)가 이를 필터링해야 할 때는 추론 주의력 (reasoning attention)을 사용합니다.

커넥터는 작업 형태에 맞춘 뷰 (task-shaped view)를 반환해야 합니다:

{
  "customer_id": "cus_1842",
  "renewal_date": "2026-09-30",
...

원시 레코드 (Raw records)은 모든 프롬프트 (prompt)에 주입되지 않고도 검토를 위해 사용할 수 있는 상태로 남겨둘 수 있습니다. 에이전트는 제한된 검색 (bounded search)을 통해 관련 레코드를 식별한 후에만 전체 이메일 본문이나 문서를 가져올 수 있습니다.

모델에게 "중요한 것에 집중하라"고 프롬프팅 (prompting)하는 것은 과도한 페이로드 (payload) 문제를 해결해주지 못합니다. 그 시점에 이르면 시스템은 이미 데이터를 검색하고 노출하는 데 비용을 지불한 상태이기 때문입니다.

MCP는 교환을 표준화할 뿐, 비즈니스 의미를 표준화하지는 않습니다

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 호환 가능한 시스템들이 도구와 컨텍스트를 노출할 수 있는 공통된 방법을 제공합니다. 이러한 인터페이스 경계 (interface boundary)는 유용하지만, 갱신 에이전트 (renewal agent)가 CRM에서 무엇을 필요로 하는지, 또는 레코드 간에 정보가 불일치할 때 어떤 소스가 우선되어야 하는지를 결정할 수는 없습니다.

MCP 서버는 기술적으로는 유효하지만 여전히 시스템의 잘못된 부분 (slice)을 반환하는 도구를 노출할 수 있습니다. 이는 다음과 같은 질문에 자동으로 답해주지 않습니다:

• 이것이 현재 정책인가요, 아니면 보관된 버전인가요?
• 응답에 모든 페이지가 포함되어 있나요?
• 이 쓰기(write) 작업은 안전하게 재시도할 수 있나요?
• 두 레코드가 동일한 고객을 나타내나요?
• 호출자가 근본적인 지원 인시던트(support incident)를 볼 수 있도록 허용됩니까?

프로토콜 호환성(Protocol compatibility)과 컨텍스트 품질(context quality)은 서로 다른 속성입니다. 호출을 표준화한다고 해서 비즈니스 작업에 맞춰 도구 계약(tool contract)을 설계해야 할 필요성이 사라지는 것은 아닙니다.

페이지네이션(Pagination)은 불완전한 결과를 완전한 것처럼 보이게 할 수 있습니다

에이전트가 모든 미결 지원 티켓(open support tickets)을 요청합니다. API는 50개의 레코드와 계속하기 토큰(continuation token)을 반환합니다.

만약 도구 출력(tool output)이 해당 토큰을 명확하게 노출하지 않거나, 도구 계약에 페이지네이션이 언제 필요한지 명시되어 있지 않다면, 첫 번째 페이지가 전체 결과처럼 보일 수 있습니다. 에이전트는 계정 리스크를 설명하는 티켓을 놓친 채로 확신에 찬 갱신 요약(renewal summary)을 생성할 수도 있습니다.

"모든 페이지를 가져오기"가 항상 올바른 수정 방법은 아닙니다. 수년간의 활동 기록이 있는 계정은 수천 개의 레코드를 가질 수 있습니다. 워크플로(workflow)에는 다음과 같은 완료 조건(completeness condition)이 필요합니다:

• 모든 미결 티켓을 검색합니다.
• 관련 날짜 경계 이후에는 중단합니다.
• 알려진 레코드가 발견될 때까지 계속합니다.
• 결과가 검토 가능한 한도를 초과하면 에스컬레이션(escalate)합니다.

이러한 조건은 워크플로와 도구 계약에 포함되어야 합니다. 그렇지 않으면 모델은 런타임(runtime)에 이를 스스로 만들어내야 합니다.

재시도(Retries)는 도구 인터페이스의 일부입니다

읽기(Reads)와 쓰기(writes)는 실패하는 방식이 다릅니다.

CRM 읽기 작업이 시간 초과(timeout)가 발생했다면, 다른 시도는 해롭지 않을 수 있습니다. 하지만 후속 작업을 생성하라는 요청이 서버에 커밋(commit)된 후 시간 초과가 발생했다면, 재시도 시 중복 데이터가 생성될 수 있습니다. 재시도를 거부하면 에이전트는 해당 작업이 수행되었는지 여부에 대해 불확실한 상태에 놓이게 됩니다.

실제 운영 환경의 쓰기 도구에는 다음과 같은 명확한 답변이 필요합니다:

1. 요청이 실행 전 혹은 실행 후에 실패했습니까?
2. 해당 작업이 멱등성 키(idempotency key)를 허용합니까?
3. 에이전트가 커밋된 작업을 조회할 수 있습니까?
4. 성공적인 쓰기를 식별할 수 있는 증거는 무엇입니까?
5. 재시도 대신 사람의 개입이 필요한 오류는 무엇입니까?

이러한 세부 사항들은 짧은 데모에서는 거의 중요하지 않습니다. 하지만 에이전트가 비즈니스 상태 (business state)를 변경하기 시작하는 순간부터는 매우 중요해집니다.

사용 가능한 도구가 아닌, 수락된 결과물을 측정하세요

유용한 평가는 하나의 결과물에서 시작됩니다. 예를 들어, 현재의 상업적 조건, 해결되지 않은 지원 리스크, 출처 참조, 그리고 필요한 증거가 누락되었을 때의 에스컬레이션 (escalation)을 포함하여 갱신 요약본을 준비하는 작업이 될 수 있습니다.

그런 다음 이를 생성하는 시스템을 측정합니다:

• 수락된 요약본당 지연 시간 (latency);
• 수락된 요약본당 토큰 (tokens) 및 도구 호출 (tool calls) 횟수;
• 불완전하거나 중복된 기록;
• 안전하지 않거나 불필요한 재시도 (retries);
• 검토자의 수정 사항;
• 특정 기능이 의도적으로 지원되지 않아 에스컬레이션된 사례.

광범위한 도구를 제거하면, 팀이 더 안전한 기능을 설계할 때까지 엣지 케이스 (edge case)를 처리할 수 없게 될 수도 있습니다. 하지만 자신의 한계를 식별할 수 있는 제한된 에이전트 (bounded agent)는 방대한 도구 카탈로그를 통해 추측하며 나아가는 에이전트보다 종종 더 신뢰할 수 있습니다.

실질적인 질문은 "에이전트가 얼마나 많은 시스템을 호출할 수 있는가?"가 아닙니다. 질문은 "각 연결이 우리가 테스트할 수 있는 조건 하에서 올바른 정보를 반환하거나 올바른 동작을 수행하는가?"여야 합니다.

이것이 도구 목록에서는 유능해 보이지만, 비용, 지연 시간 (latency), 또는 비즈니스 상태 (business state)에 대한 통제력을 잃지 않고 워크플로우 (workflow)를 완료할 수 있는 에이전트 사이의 차이점입니다.

이 기사는 Coryntas에서 처음 게시된 More Tools Can Make an Agent Slower를 DEV 커뮤니티를 위해 각색한 것입니다.