AI 에이전트 간에 속도 제한(Rate Limits)을 추가한 이유

대부분의 개발자들은 API 경계에서의 속도 제한(Rate Limits)을 생각합니다.

데이터베이스를 보호합니다.

외부 서비스를 보호합니다.

모델 제공자(Model providers)를 보호합니다.

공개 엔드포인트(Public endpoints)를 보호합니다.

이것은 표준적인 인프라 설계입니다.

우리를 놀라게 했던 것은 우리가 결국 속도 제한(Rate Limits)이 가장 절실하게 필요했던 지점이었습니다.

AI 에이전트(AI agents) 사이였습니다.

사용자와 에이전트 사이가 아닙니다.

에이전트들 상호 간이었습니다.

처음에는 모든 것이 괜찮아 보였습니다

우리의 워크플로(Workflows)는 단순하게 시작되었습니다.

하나의 에이전트가 작업을 처리합니다.

추가 정보가 필요하면, 다른 전문 에이전트를 호출합니다.

그 두 번째 에이전트는 검색 서비스(Retrieval service)를 호출할 수도 있습니다.

또는 세 번째 에이전트를 호출할 수도 있습니다.

혹은 외부 통합(External integration)을 호출할 수도 있습니다.

아키텍처(Architecture)는 깔끔해 보였습니다.

책임(Responsibilities)은 분리되어 있었습니다.

각 에이전트는 집중된 목적을 가지고 있었습니다.

테스트 중에는 시스템이 잘 작동했습니다.

그러다 우리는 이를 프로덕션(Production) 환경에 배치했습니다.

에이전트는 인간보다 더 많은 작업을 생성합니다

인간은 본질적으로 느립니다.

에이전트는 그렇지 않습니다.

에이전트는 거의 즉각적으로 의사결정을 내리고 후속 조치를 트리거(Trigger)할 수 있습니다.

여러 에이전트가 지속적으로 상호작용하기 시작하기 전까지는 이 점이 아주 좋게 들립니다.

단일 사용자 요청은 다음과 같은 작업을 트리거할 수 있습니다:

문서 검색 (Document retrieval)
분류 (Classification)
검증 (Validation)
요약 (Summarization)
워크플로 계획 (Workflow planning)
작업 실행 (Action execution)

각 단계는 추가적인 에이전트 상호작용을 포함할 수 있습니다.

부하(Load)가 걸리면, 이러한 상호작용은 빠르게 증폭되었습니다.

그 결과는 예상치 못한 인프라 압박이었습니다.

사용자가 늘어났기 때문이 아닙니다.

에이전트가 늘어났기 때문입니다.

에이전트 간 증폭(Agent-to-Agent Amplification)은 실재합니다

우리가 처음으로 목격한 것 중 하나는 증폭(Amplification)이었습니다.

시스템에 들어오는 단일 요청이 수십 개의 내부 요청을 생성할 수 있었습니다.

예를 들어:

에이전트 A가 컨텍스트(Context)를 요청합니다.
에이전트 B가 추가 컨텍스트를 요청합니다.
에이전트 C가 정보를 검증합니다.
에이전트 D가 확인(Verification)을 수행합니다.
에이전트 B가 신뢰도가 낮아 재시도(Retries)합니다.

기술적으로 잘못된 것은 아무것도 없습니다.

모든 동작은 합리적으로 보입니다.

하지만 집합적으로, 워크플로(Workflow)는 급격히 확장됩니다.

하나의 요청이 열 개가 됩니다.

열 개가 쉰 개가 됩니다.

쉰 개가 수백 개가 됩니다.

인프라는 사용자 트래픽과는 완전히 무관한 압박을 받게 됩니다.

피드백 루프(Feedback Loops)는 찾아내기 어렵습니다

가장 위험한 문제는 높은 볼륨(High volume)이 아니었습니다.

바로 피드백 루프(Feedback loops)였습니다.

에이전트들은 때때로 서로에게 지속적으로 정보를 요청하는 상호작용 패턴을 형성했습니다.

무한히 반복되는 것은 아니었습니다.

하지만 상당한 낭비를 초래할 만큼은 반복되었습니다.

예시로는 다음과 같은 것들이 있었습니다:

반복적인 검증 사이클 (Validation cycles)
중복된 검색 요청 (Duplicate retrieval requests)
재귀적 계획 동작 (Recursive planning behavior)
신뢰도 확인 루프 (Confidence verification loops)
불필요한 재시도 (Unnecessary retries)

출력값은 여전히 올바르게 보였습니다.

사용자들은 거의 알아차리지 못했습니다.

하지만 인프라 비용은 증가했습니다.

지연 시간(Latency)이 증가했습니다.

리소스 사용량(Resource utilization)이 증가했습니다.

상세한 모니터링 없이는 이러한 패턴을 감지하기 어려웠습니다.

더 높은 지능이 더 많은 인프라 부하를 생성합니다

흔히 하는 가정은 더 똑똑한 에이전트가 작업 부하를 줄여줄 것이라는 점입니다.

때로는 그 반대의 상황이 발생합니다.

추가적인 추론(Reasoning)은 종종 추가적인 동작을 생성합니다.

더 많은 계획(Planning)은 다음과 같은 것들을 만들어낼 수 있습니다:

더 많은 검색 호출 (Retrieval calls)
더 많은 검증 요청 (Validation requests)
더 많은 조정 메시지 (Coordination messages)
더 많은 실행 경로 (Execution paths)

응답 품질이 향상되더라도 시스템은 운영 측면에서 더 무거워집니다.

이로 인해 우리는 에이전트를 분산 시스템(Distributed systems)과 동일한 방식으로 생각해야만 했습니다.

모든 상호작용에는 비용이 따릅니다.

속도 제한(Rate Limits)이 경계선을 만들었습니다

결국 우리는 에이전트 워크플로(Agent workflows) 사이에 내부 속도 제한(Internal rate limits)을 도입했습니다.

에이전트들이 실패하고 있었기 때문이 아닙니다.

그들이 너무 열정적으로 성공하고 있었기 때문입니다.

우리는 다음과 같은 항목들을 제어하기 시작했습니다:

워크플로당 요청 수 (Requests per workflow)
에이전트 상호작용 빈도 (Agent interaction frequency)
재시도 볼륨 (Retry volume)
검증 사이클 (Validation cycles)
검색 확장률 (Retrieval expansion rates)

목표는 제한이 아니었습니다.

목표는 폭주하는 동작(Runaway behavior)을 방지하는 것이었습니다.

경계선은 워크플로가 효율성을 유지하도록 강제했습니다.

예상치 못한 이점

가장 큰 이점은 인프라 비용의 절감이 아니었습니다.

더 나은 시스템 동작이었습니다.

상호작용 제한이 존재하게 되자, 비효율적인 워크플로가 명확하게 드러나기 시작했습니다.

무제한 실행 뒤에 숨겨져 있던 아키텍처 문제(Architectural problems)들이 갑자기 수면 위로 드러났습니다.

우리는 다음과 같은 문제들을 발견했습니다:

중복된 에이전트 책임 (redundant agent responsibilities)
불필요한 검증 단계 (unnecessary validation stages)
중복된 검색 패턴 (duplicated retrieval patterns)
과도한 계획 루프 (excessive planning loops)

속도 제한(Rate limits)은 진단 도구(diagnostic tool)와 같은 역할을 했습니다.

제한이 없었다면 보이지 않았을 비효율성을 드러내 주었습니다.

AI 시스템에는 리소스 거버넌스(Resource Governance)가 필요합니다

전통적인 분산 시스템(distributed systems)은 이미 이 원칙을 이해하고 있습니다.

모든 서비스는 제한 범위 내에서 작동합니다.

모든 리소스에는 제약 조건이 있습니다.

모든 워크플로에는 경계가 있습니다.

AI 시스템에도 동일한 규율이 필요합니다.

에이전트 아키텍처가 더욱 정교해짐에 따라, 리소스 거버넌스(resource governance)의 중요성은 점점 더 커지고 있습니다.

제한이 없다면 복잡성은 예상보다 빠르게 증가합니다.

그리고 그 복잡성은 결국 운영 리스크(operational risk)가 됩니다.

더 큰 교훈

멀티 에이전트 시스템(multi-agent systems)의 과제는 에이전트들이 서로 통신하게 만드는 것이 아닙니다.

현대의 프레임워크들은 그것을 비교적 쉽게 만들어 줍니다.

진정한 과제는 그들이 얼마나 많이 통신하는지를 제어하는 것입니다.

왜냐하면 일단 에이전트가 다른 에이전트를 위한 작업을 생성할 수 있게 되면, 인프라 부하(infrastructure load)는 더 이상 사용자 수요와 직접적으로 연결되지 않기 때문입니다.

대신 시스템 동작(system behavior)과 연결됩니다.

그리고 시스템 동작은 누구도 예상하는 것보다 훨씬 더 빠르게 확장될 수 있습니다.

이것이 우리가 AI 에이전트 사이에 속도 제한(rate limits)을 추가한 이유입니다.

그들의 속도를 늦추기 위해서가 아닙니다.

예측 가능하게(predictable) 유지하기 위해서입니다.