#여러 Agent가 같은 도구를 동시에 부를 수 있는가

← 전체 목차 · 이전: 다단계 도구 호출, 중간에 실패하면 전부 어떻게 되돌리나 · 다음: 다중 도구를 병렬 호출할 때, 대화 상태는 먼저 갱신하나 나중에 갱신하나

"같은 도구를 여러 Agent가 동시에 호출할 수 있는가"라는 질문에 "안 된다, 도구 하나는 한 번에 하나의 요청만 처리한다"라고 답하면 틀리지는 않았지만 딱 절반만 맞다. 이어지는 "그런데 왜 어떤 프레임워크는 동시 호출이 되는가"라는 반문에 답하지 못하면, 그 지점이 바로 표면적 지식과 실전 경험을 가르는 선이다. 정답은 이분법이 아니라 "무엇에 달려 있는가"를 아는 것이다.

#충돌 판정은 도구 이름이 아니라 도구 인스턴스 단위에서 일어난다

Agent가 도구를 호출하는 실제 메커니즘:

Agent 호출 발생
  → "도구 실행기"에 호출 요청 제출
  → 자신의 작업 파라미터를 특정 "도구 인스턴스"에 바인딩
  → 프레임워크가 "도구 상태표"로 실시간 추적:
       · 어느 인스턴스가 점유 중인가
       · 그 인스턴스는 어느 실행 단계에 있는가

바인딩 대상은 인스턴스이지 도구의 "이름"이 아니다. 같은 이름의 도구라도 인스턴스가 여럿이면 충돌이 성립하지 않고, 같은 인스턴스가 두 번 걸리는 경우에만 충돌이 성립한다. 기본값인 단일 인스턴스 모드에서는 이미 점유된 인스턴스에 다른 Agent가 다시 요청하면 프레임워크가 차단 / 대기열 / 오류("도구가 이미 실행 중입니다") 중 하나로 처리한다 — 이것이 "동시 호출이 안 된다"의 정확한 근거다.

#두 개의 복용 스위치 — 혼동하면 사고가 난다

가장 흔한 오답은 인스턴스 복용을 켜놓고 병렬이 해결됐다고 착각하는 것이다. 복용은 시간축에서의 회전율을 최적화할 뿐, "동시에 한 요청만 서비스한다"는 제약 자체를 깨지 않는다.

#풀링이 켜지면 무슨 일이 일어나는가

1. 프레임워크가 동일 도구의 인스턴스 여러 개를 미리 초기화
2. 이 인스턴스들이 "도구 자원 풀"을 구성
3. 새 호출 요청 도착
4. 조정기가 "부하 분산 규칙"에 따라
5. 풀 안의 유휴 인스턴스로 요청을 분배

정규 다중 Agent 협업 시스템은 대부분 통합 도구 풀을 구축한다 — 모든 Agent가 동일한 도구 자원을 공유하고, 신규 요청은 조정기가 곧바로 유휴 인스턴스에 배정한다. 이 구조가 동시에 해소하는 두 문제:

• 대기열 병목: 모든 호출이 하나의 인스턴스로 몰리는 상황
• 경쟁 문제: 여러 Agent가 같은 인스턴스를 서로 먼저 잡으려 다투는 상황

#풀링 없이 다중 Agent를 올리면 생기는 사고

풀링 미설정
  → 그대로 다중 Agent 병렬 호출을 투입
  → 모든 요청이 전부 대기열에 적체
  → 배치 작업이 대규모로 타임아웃

이 장애의 위험한 특징은 에러가 아니라 지연으로만 나타난다는 점이다. 대기열 적체는 즉시 문제를 드러내지 않고 지연을 조금씩 쌓다가 타임아웃 임계값을 넘긴 뒤에야 터지므로, 압박 테스트 전에는 거의 보이지 않고 현업에서는 모델이 느리다거나 네트워크가 느리다는 쪽으로 오진되기 쉽다.

#충돌 여부를 가르는 판정 공식

도구 호출이 충돌하는가 = 인스턴스 수 + 스케줄링 전략 + 풀링 여부

도구 본연의 능력 문제가 아니다.

이 공식을 뒤집으면 실무 절차가 된다: 현재 도구가 단일 인스턴스인지 풀링됐는지 먼저 확인 → 필요한 것이 회전율(복용)인지 병렬도(풀링)인지 구분 → 통합 풀을 구성해 모든 Agent가 공유하게 함 → 조정기의 분배 규칙을 설정 → 대기열 병목/경쟁 두 실패 모드를 자가 점검 → 풀링 없이 병렬을 올리는 함정을 압박 테스트로 재현.

#핵심 통찰

1. "동시 호출이 되는가"는 도구의 속성이 아니라 자원 관리 설정 문제다 — 도구 자체에는 "한 번만 호출 가능"이라는 천연 제약이 없다. 제약은 프레임워크의 기본 단일 인스턴스 바인딩 전략에서 온다. 문제를 설정 층으로 재귀속하면 "설정을 바꾸면 된다"는 공학적 결론이 나오고, 도구 층으로 귀속하면 "안 된다"는 막다른 결론만 남는다.
2. 병렬의 진짜 단위는 "인스턴스"이지 "도구"가 아니다 — 상태표가 기록하는 것도 인스턴스 단위의 점유 상황이다. 이 입도 차이를 이해하면 "같은 도구를 여러 Agent가 부른다"는 문장은 자연히 "같은 도구의 서로 다른 인스턴스를 부른다"로 풀리고 충돌은 사라진다.
3. 복용과 풀링은 전혀 다른 문제를 푼다 — 혼동이 가장 흔한 실점 포인트다 — 복용은 시간축의 회전율(생성·소멸 비용 절감), 풀링은 공간축의 병렬도(동시 처리)다. 고빈도 직렬 작업에는 복용, 다중 Agent 동시 호출에는 반드시 풀링이 필요하다.
4. 도구 상태표는 프레임워크가 동시성 제어를 구현하는 핵심 데이터 구조다 — "어느 인스턴스가 점유됐고 어느 단계에 있는가"라는 두 필드가 차단·대기열·오류 세 행동을 결정한다. 이 표를 관측 대상에 포함시키면 "어느 인스턴스에서 막혔는가"를 가장 직접적으로 확인할 수 있다.
5. 풀링의 수익은 "동시 호출 가능"에 그치지 않고 자원 경쟁과 성능 병목까지 해소한다 — 통합 도구 풀은 기능성 문제(동시에 부를 수 있나)를 아키텍처 문제(시스템 처리량이 단일점에 막히는가)로 격상시킨다.
6. 다중 Agent 시스템의 기본값은 단일 Agent 시나리오를 위해 설계된 것이므로 그대로 가져다 쓰면 반드시 걸린다 — 단일 Agent 데모에서 다중 Agent 협업으로 넘어갈 때는 자원 층 설정을 반드시 재검토해야 한다.
7. 유상태 도구는 순수 부하 분산으로 풀링할 수 없다 — 외부 연결, 세션, 파일 핸들을 쥔 도구를 다중 인스턴스로 병렬화하면 정합성 문제가 새로 생긴다. 이런 도구는 임의의 유휴 인스턴스에 배분하는 대신 친화도 스케줄링(같은 세션은 같은 인스턴스로)이 필요하다.

#엔지니어링 실전 Tips

• 동작 전에 기본값부터 확인할 것: 다중 Agent 작업을 시작하기 전에 현재 프레임워크의 도구가 단일 인스턴스인지 풀링됐는지부터 확인한다. 기본값은 안전하지만 병렬은 아니며, 기본값을 그대로 둔 채 다중 Agent를 올리는 것이 가장 흔한 함정이다.
• "복용"과 "풀링"을 서로 다른 독립 스위치로 취급할 것: 목표가 고빈도 직렬 작업의 효율이면 복용, 여러 Agent가 동시에 같은 도구를 호출해야 하면 반드시 풀링을 켠다.
• 용량 계획은 도구 종류가 아니라 인스턴스 단위로 할 것: 충돌 판정이 인스턴스 입도에서 일어나므로, "동시 Agent 수 ↔ 풀 안 인스턴스 수"의 비율로 용량을 산정해야 한다.
• 다중 Agent 시스템은 각자 도구를 들지 말고 통합 풀을 공유할 것: 각자 대기열을 서는 구조보다 공유 풀이 전역 유휴 현황을 볼 수 있어 배분 효율이 높다.
• "타임아웃"을 대기열 적체의 신호로 우선 의심할 것: 배치 작업이 대규모로 타임아웃되면 타임아웃 임계값을 늘리기 전에 도구 층에서 대기열이 쌓이고 있지 않은지부터 확인한다 — 임계값만 늘리면 장애가 더 늦게 드러날 뿐이다.
• 도구 상태표를 관측 범위에 반드시 포함시킬 것: 인스턴스 점유율과 실행 단계 분포를 노출해두면 풀 크기가 부족한지 판단하는 1차 근거가 된다.
• 풀 크기와 동시 Agent 수를 함께 조정할 것: Agent 동시성만 늘리고 풀을 늘리지 않으면 병목이 도구에서 대기열로 자리만 옮긴다.