Jev로 판단은 빨라졌지만 에이전트 제어 체계가 속도 향상을 깎는다

Kendall Clark(Kendall Clark)와 Pentad Labs가 2026년 10월 14일 발표한 PLRN-031은 에이전트의 판단이 수십 밀리초로 빨라진 반면, 여러 업체 제품을 네트워크 훅으로 연결한 제어 체계는 여전히 수백 밀리초가 걸린다고 분석한다. 이 자료의 지연시간 모델에서 5개 계층의 제어 체계는 고객과 같은 클라우드 리전에서 중앙값 115ms, 공개 SaaS로 연결하면 450ms가 걸린다. 저자들은 제어가 판단보다 느려지는 이 시점을 ‘교차점’이라고 부르며, 에이전트가 빨라질수록 고정 제어 비용이 속도 향상을 제한한다고 주장한다.

판단보다 느린 제어 체계

2026년 8월에는 최첨단 모델 호출이 수초 걸려 수백 밀리초의 제어 검사가 눈에 띄지 않았다. 10월에는 소형 분류 모델이 같은 종류의 판단을 수십 밀리초에 내리기 시작했다. 반면 기업이 에이전트에 붙이는 런타임, 제어, 관측, 거버넌스, 오케스트레이션의 다섯 계층은 빨라지지 않았다. 이 계층들은 흔히 서로 다른 업체 제품으로 구성되고 네트워크 호출인 훅으로 연결된다.

저자들의 모델은 다섯 업체가 모두 고객 리전에서 실행될 때 중앙값 115ms, 90백분위수 195ms, 95백분위수 230ms, 99백분위수 318ms, 99.9백분위수 481ms로 추산한다. 공개 SaaS로 연결하면 각각 450ms, 666ms, 759ms, 993ms, 1,431ms다. 이는 특정 업체 제품을 직접 측정한 결과가 아니라 공개된 네트워크·업체 지연시간에 기초한 모델이다.

모델은 제어되는 작업이 최대 다섯 계층을 순차 통과한다고 가정한다. 각 계층은 별도 서비스이며 네트워크 왕복과 자체 처리가 필요하다. 앞 계층의 결과가 다음 계층에 필요하므로 호출은 순차적으로 이뤄지고, 마지막에 공통 실행 ID나 권한 ID가 없는 다섯 응답을 서로 연결한다. 각 지연은 로그정규분포로 모델링했다. 리전 내 왕복 중앙값은 AWS가 세 리전의 핑 테스트에서 보고한 교차 가용 영역 1.5ms를 썼고, 공개 SaaS 왕복 30ms는 가정이다. 처리 중앙값은 리전 내 15ms, SaaS 40ms이며 99백분위수는 중앙값의 8배로 잡았다. SaaS 처리값은 Lakera가 공개한 p95 지연시간(1,000자 입력에서 20ms 미만, 10,000자에서 100~200ms, 30,000자에서 300~400ms)에 근거한 보수적 중앙값이다. 응답 결합에는 리전 내 5ms, SaaS 10ms를 넉넉한 추정치로 적용했다.

민감도 분석에서 모든 업체가 리전에 있고 처리 중앙값이 5ms, p99가 중앙값의 4배인 가장 유리한 조건에서도 체인 지연은 p50 43ms, p99 78ms다. 처리 중앙값을 리전 내 15ms로 두면 p50 115ms·p99 317ms, 40ms로 두면 282ms·822ms다. 공개 SaaS에서는 처리 중앙값 5ms일 때 207ms·325ms, 40ms일 때 450ms·998ms다. 다섯 호출이 순차 실행될 때 각 호출이 자체 p99 이상에 도달할 확률은 1−0.99⁵, 약 4.9%다. 따라서 작업 20건 중 하나는 업체 지연의 꼬리를 경험할 수 있다. 병렬 실행도 계층 간 의존성을 없애지 못하고, 비동기 훅은 작업 전에 결정을 내리지 않으면 제어가 아니라 관측에 그친다.

소형 모델이 만든 교차점

에이전트가 묻는 판단은 입력 공격 여부, 개인정보 포함 여부, 도구 호출의 과업 범위 준수 여부처럼 범위가 좁다. TypeSafe AI는 2026년 9월 15일 Jev를 공개했다. Jev는 문장 대신 유형이 정해진 결정, 선택지, 점수 또는 예·아니요를 반환한다. 업체는 같은 수준의 최첨단 모델 지능으로 40~200배 빠르다고 주장했다. 서부 해안의 노트북에서 측정한 종단 간 지연은 70~500ms이며 백분위수는 공개하지 않았다. a16z는 투자 발표 3주 뒤 첫 사흘 동안 1조 토큰을 처리했고 Fortune 500 기업의 4분의 1이 통합했다고 전했다.

독립 측정에서는 공개된 20억 매개변수 모델 this-that-model-1.0이 노트북 GPU에서 30.9ms에 판단을 내렸고, 대체 대상인 최첨단 모델 호출은 8,758ms였다. 공개 GitHub 프로젝트 조사에서는 9월 22일까지 Jev를 호출하는 프로젝트가 2,170개로 집계됐다. REFLEX 연구는 강한 모델 앞에 system-one 모델을 선택적 제어 계층으로 두어 과업 성공률 95%에서 강한 모델 호출을 72.7% 줄였다고 보고했다. 다만 Jev 업체의 지연 주장은 업체 자료이며, 호스팅 서비스의 독립적인 백분위수 측정은 공개되지 않았다.

소형 분류 모델은 그전에도 있었다. 메타의 Prompt Guard 2 모델 카드에 따르면 A100에서 512토큰 입력을 분류하는 데 22M 모델은 19.3ms, 86M 모델은 92.4ms가 걸린다. WunderOS의 경로 내 점수 모델은 새 입력에서 89ms, 캐시 입력에서 12µs이며, 작업 시작 전 모든 작업이 통과하는 승인 판단은 p99 142µs다. 이 값은 해당 자료 작성 시점의 master에서 측정한 수치다. 자료가 §4에서 모델링하는 빠른 호출은 고객 리전이나 장치에서 실행하는 공개 system-one 모델이며, 공개 인터넷을 거치는 판단은 훅 하나의 비용을 추가한다. 코딩 에이전트용 Jev 기반 도구 pi-jev는 왕복 약 300ms를 보고했다.

자료는 2026년 8월의 약 3초짜리 짧은 최첨단 모델 호출에서 10월의 30.9ms짜리 공개 2B 모델 또는 Prompt Guard 2의 19~92ms 판단으로 지연이 약 두 자릿수 규모 줄었지만, 다섯 계층 훅 체인은 그대로라고 설명한다. 3초는 비자명한 작업의 p10에 가깝다.

고정 제어 비용이 속도 향상을 제한한다

Requesty가 2026년 4월 게이트웨이 전체 트래픽에서 측정한 종단 간 지연은 Anthropic이 p50 5.8초·p95 52.6초, OpenAI가 2.5초·17.9초, Vertex의 Claude가 13.7초·115.2초였다. Requesty는 Vertex의 긴 꼬리가 주로 에이전트 코딩 작업에서 나온다고 설명했다. 이 수치는 사소한 호출도 포함한다. TraceLab v0.0.2에 기록된 Claude Code·Codex 호출 665,453건을 분석한 분포에서는 호출 p10이 1.9초, 중앙값이 6.3초였다. 출력 토큰이 1,000개 이상인 생성 호출의 중앙값은 27.9초, 2,000개 이상이면 46.7초였고 p95는 108~147초, p99는 280초를 넘었다. O’Connor가 운영 에이전트에 가드레일 도구 여섯 개를 인라인으로 붙여 측정한 경험에 따르면 약 50ms를 넘는 검사는 사용자가 느끼고, 약 200ms를 넘으면 장애 중 누군가 끄게 된다.

에이전트가 일부 차례의 판단을 소형 모델이나 결정적 게이트에 맡기면 그 차례는 1분 대신 수십 밀리초에 끝난다. 그러나 훅 체인의 차례당 비용은 판단 속도와 무관하게 고정된다. 자료는 이를 Amdahl의 법칙에 따른 직렬 부분으로 설명한다. 계산의 비율 p를 s배 빠르게 만들면 전체 속도 향상은 1/((1−p)+p/s)이며, 빨라지지 않는 부분이 최종 상한을 정한다.

계산 모델은 느린 차례의 판단을 60초, 빠른 차례를 50ms로 둔다. 60초는 자료가 인용한 가장 무거운 생성 부류의 46.7초 중앙값보다 큰 반올림 값이고, 50ms는 분류기 측정 범위의 중간값이다. 빠른 차례의 비율을 f, 차례마다 같은 제어 비용을 C라 한다. 평균 차례 시간은 T(f)=(1−f)J_s+fJ_f+C이며, 빠른 차례가 늘어날 때의 속도 향상은 (J_s+C)/T(f)다. f가 1에 가까워지면 상한은 (J_s+C)/(J_f+C)가 된다.

빠른 차례가 0%, 10%, 50%, 90%, 99%, 100%일 때 경로 내 제어의 속도 향상은 각각 1.0배, 1.1배, 2.0배, 9.9배, 92배, 1,200배다. 리전 내 훅은 1.0배, 1.1배, 2.0배, 9.8배, 79배, 364배이며, 공개 SaaS 훅은 1.0배, 1.1배, 2.0배, 9.3배, 55배, 121배다. 빠른 차례만 놓고 보면 제어가 차지하는 시간은 리전 내 훅에서 70%, SaaS 훅에서 90%다. 모든 차례가 빠르면 각각 전체 시간의 70%와 90%를 제어가 차지한다.

훅 체인은 경로 내 제어가 허용하는 속도 향상의 약 30%(리전 내), 약 10%(공개 SaaS)만 남긴다. 느린 모델 호출이 3초, 60초, 180초여도 이 비율은 거의 달라지지 않는다. 빠른 호출을 50ms에서 5ms로 줄여도 SaaS 상한은 121배에서 133배, 리전 내 상한은 364배에서 501배로만 높아진다. 경로 내 제어에서는 같은 변화가 1,200배에서 12,000배로 상한을 높인다. 훅의 중앙값 대신 꼬리 지연을 적용하면 상한은 더 낮다. 평균적으로 차례당 통제되는 작업은 1.12개이며, 세 작업을 통제하는 경우는 중앙값이 아니라 95백분위 구조다. 이 구조를 반영하면 SaaS 체인의 상한은 평균 구조에서 약 110배, 세 호출 구조에서 44배로 내려간다.

자료는 에이전트 활동 시간의 비용도 추산한다. Li(2026)는 Codex 작업 시간당 15.50~18.19달러, Claude Code 작업 시간당 24.34~50.16달러를 측정하고, 기준값으로 에이전트 시간당 30달러를 사용했다. 컨텍스트가 50만 토큰을 넘는 세션은 시간당 38.99~104.75달러였다. 에이전트 시간의 15~70%를 차지하는 리전 내 제어는 기준 시간당 30달러에서 4.50~21달러에 해당하며, SaaS 제어의 41~90%는 12.30~27달러에 해당한다. 가장 긴 컨텍스트 세션에서는 90달러를 넘을 수 있다. 이는 API가 대기 시간을 청구한다는 뜻이 아니라, 그 시간에 수행할 수 있었던 작업을 잃는 비용이라는 설명이다.

2026년 10월 기준, 자료는 차례별 교차점이 이미 지난 것으로 본다. SaaS 체인의 중앙값 450ms는 Prompt Guard 2 86M의 92.4ms보다 길고, 리전 체인의 115ms도 22M의 19.3ms보다 길다. 에이전트 전체 시간에서 제어가 판단보다 커지는 임계점은 느린 호출 시간에 따라 달라진다. SaaS 체인에서는 느린 차례가 60초일 때 빠른 차례 비율 99.3%, 10초일 때 96.0%, 3초일 때 86.4%, 1초일 때 57.9%, 500ms일 때 11.1%가 임계점이다. 리전 체인은 같은 조건에서 각각 99.9%, 99.3%, 97.8%, 93.2%, 85.6%다.

임계점의 날짜는 측정값이 아니라 가정한 경로에 따른 전망이다. 선도 집단의 빠른 차례 비율이 2026년 10월 90%에서 1년 뒤 99%로 오르고, 빠른 판단 지연이 매년 절반으로 줄며, 느린 호출은 60초로 유지된다고 가정한다. 이 경로에서 평균 판단 시간은 약 6초에서 1년 뒤 625ms로 낮아지고, SaaS 체인은 2027년 말, 리전 체인은 2028년 중반에 넘어선다. 느린 호출을 180초로 늘려도 SaaS 교차는 약 5개월 늦어지는 데 그친다. 빠른 차례 비율 50%에서 출발해 같은 속도로 증가하는 집단은 SaaS 체인을 2029년 초, 리전 체인을 2029년 가을에 넘는다. 남은 느린 호출이 그때 10초라면 두 시점은 각각 2028년 봄과 가을로 앞당겨진다. 90%에서 99%까지 오르는 데 2년이 걸리면 선도 집단의 시점은 SaaS 2029년 초, 리전 2030년 초가 된다. 빠른 호출 지연을 50ms에 고정하면 SaaS 시점은 그대로고 리전 시점은 3개월 늦어진다.

빠른 호출 지연이 매년 절반으로 줄어들 때, 경로 내 제어가 허용하는 속도 향상 중 훅 체인이 유지하는 비율은 리전 내에서 2026년 10월 30%, 2027년 18%, 2028년 10%, 2029년 5.2%로 줄고, SaaS에서는 10%, 5.3%, 2.7%, 1.4%로 줄어든다. 차례당 통제 도구 호출이 세 개라면 제어 비용이 세 배가 되므로 마지막 비율도 3분의 1이 된다. 자료의 계산에서는 2029년 SaaS 체계를 쓰는 에이전트가 경로 내 제어의 속도 향상 중 절반의 1%에도 못 미치는 몫을 보유한다.

이 전망은 라우팅 비율을 측정한 결과가 아니다. 입력 길이가 제한되고 판정만 반환하거나 캐시된 접두부를 읽는 분류 형태의 호출을 전제로 한다. 저자들은 분류기 지연을 매년 절반으로 잡았으며, 관측된 두 달간의 두 자릿수 규모 하락보다 느린 속도라고 설명한다. 60초의 느린 호출도 고정 가정이며, 자료가 측정한 가벼운 호출 6.3~27.9초를 적용하면 교차 시점은 더 빨라진다.

늦은 검사는 통제가 아니라 기록이다

자료는 에이전트의 절반 이상이 빠른 차례를 수행하면 중앙값 차례가 빠른 차례가 된다고 본다. 그때 단일 빠른 차례에서 제어가 차지하는 시간은 리전 내 70%, SaaS 90%다. 따라서 작업자가 추적 기록을 보면 전형적인 차례가 허가를 기다리는 시간에 주로 쓰이는 상황을 확인하게 된다. 에이전트의 평균 시간에서 제어가 판단보다 커지는지는 별도로 평균 판단 시간과 제어 비용의 비교로 정해진다.

Anderson의 1972년 참조 모니터 원칙은 모든 접근에서 호출되고, 변조할 수 없으며, 검증할 만큼 작아야 한다고 규정한다. Saltzer와 Schroeder의 완전한 매개 원칙도 모든 객체 접근을 검사해야 한다고 말한다. 자료는 이 원칙에 시간 조건을 더한다. 확인 대상의 작업이 끝난 뒤 도착하는 검사는 허가를 매개한 것이 아니라 이미 일어난 일을 관찰한 것이다. 검사 시점과 사용 시점 사이에 상태가 변하는 시간 검사-사용 시점 결함(TOCTOU)은 다중 호출 검사에서 더 커진다. 다섯 계층의 응답은 115~450ms 동안 서로 다른 순간의 상태를 나타낼 수 있고, 그사이에 에이전트의 다음 행동이 시작될 수 있다.

제어 이론의 표본화 조건에 따르면 디지털 제어기는 제어 대상의 동역학에 비해 충분히 빠르게 표본을 취하고 작동해야 한다. WunderOS는 에이전트를 제어 대상, 즉 비결정성의 원천으로 보고 그 주위에 제어기를 둔다. 에이전트 단계가 수십 밀리초로 줄어들면 수백 밀리초 뒤 판단하는 제어기는 현재 상태가 아니라 과거를 읽는다. 자료가 제시하는 조건은 제어 결정이 작업 경로에서 호출되고, 작업 효과가 발생하기 전에 끝나며, 작업 자체 시간의 작은 일부만 차지해야 한다는 것이다.

다섯 계층이 만들지 못하는 데이터 연결

지연시간 외에도 각 계층이 필요한 정보 일부만 보유한다는 문제가 있다. 예를 들어 개인정보를 읽었고 예산 할당을 초과했으며 오늘 만료되는 권한으로 실행 중인 작업을 멈추려면, 관측 업체의 읽기 기록, 오케스트레이션 업체의 예산, 제어 업체의 권한을 결합해야 한다. 세 제품에 공통 식별자가 없으면 여러 차례 호출해 연결해야 하고, 결정은 실행이 진행된 뒤 도착할 수 있다. 자료는 이런 규칙이 단순히 느린 것이 아니라 실제로 작성되지 않는 경우가 많다고 주장한다. 각 업체가 자기 데이터로 판단할 수 있는 제어만 제공하면 기업은 전체 실행 상태가 아니라 다섯 부분 관점의 합집합을 얻는다.

하나의 제어 지점이 모든 행동을 보고 그 상태를 보유하며 마이크로초 단위로 판단하면 다음과 같은 제어가 가능하다고 자료는 설명한다. 기록·예산·권한을 함께 평가하는 결합 제어, 매 차례 예산을 다시 판단하거나 결과를 보존하는 가장 저렴한 수단으로 각 단계를 보내는 단계별 경제성, 실행 기록을 이용한 결정적 재생과 나중의 보상·되돌리기, 데이터 읽기와 쓰기를 거쳐 반출 지점까지 이어지는 정보 흐름 추적, 여러 형식으로 흩어진 기록이 아닌 완전한 추적 자료를 통한 개선이다. 관련 자료는 PLRN-008, PLRN-014, PLRN-021, PLRN-022, PLRN-002, PLRN-011, PLRN-027, PLRN-016에 있다.

통합 플랫폼은 자기 플랫폼의 에이전트에 대해서는 계층을 한곳에 모을 수 있지만 업체 중립성을 보장하기 어렵다. Databricks, Snowflake, Salesforce, ServiceNow는 각자 플랫폼에서 계층을 통합할 수 있으나 기업은 여러 업체의 AI를 함께 쓰며, 중앙 통제에서 벗어난 에이전트는 그 플랫폼 밖에서 만들어진 에이전트다. Dataiku와 Harris Poll의 2026년 조사에서 CIO 685명 중 81%는 공식 경로 밖에서 만들어진 에이전트를 완전히 감독하지 못한다고 답했다. Gartner 분석가들은 플랫폼 중립적인 가디언 에이전트를 권고했다.

자료가 요구하는 조건은 세 가지의 결합이다. 제어가 행동 경로 안에서 제때 작동하고, 상태가 한곳에 모이며, 업체 간 중립성을 가져야 한다. 다섯 업체의 훅 연결은 중립적이지만 빠르지 않고 상태도 분산돼 있다. 통합 플랫폼은 자기 에이전트에 대해서는 경로 내 제어와 통합 상태를 제공하지만 중립적이지 않다. 자료는 이 세 조건을 모두 갖춘 방안으로 에이전트 운영체제(agent OS)를 제시한다.

전망의 조건과 한계

저자들은 특정 업체 체계의 실제 지연시간이 모델과 같다고 주장하지 않는다. 다섯 제품을 실제 에이전트 작업으로 구동해 계층별 p50·p99를 측정해야 하며, 아직 그 측정은 없다. 훅이 무용하다는 주장도 아니다. 비동기 훅은 관측에 유용하며, 논점은 행동의 효과 전에 작동해야 하는 제어다. 통합이 에이전트 결과를 개선한다고 입증한 것도 아니다. 통합으로 특정 제어가 가능해진다는 주장과, 이를 쓴 에이전트가 실패를 줄이거나 개입을 덜 필요로 하는지는 별도의 실증 문제다.

이 분석의 근거는 Amdahl(1967)의 직렬 부분, Dean과 Barroso(2013)의 꼬리 지연, Anderson(1972)의 참조 모니터, Saltzer와 Schroeder(1975)의 완전한 매개, Bishop과 Dilger(1996)의 시간 검사-사용 시점 연구, Åström과 Wittenmark(1997)의 디지털 제어 표본화 원칙이다. Meta의 LlamaFirewall은 에이전트 프로세스 안에 가드레일을 구성하는 사례로 제시된다. 이는 훅 체인을 피하는 대신 검사 위치를 에이전트가 접근할 수 있는 곳에 둔다.

WunderOS는 자체 구현이 요구사항을 충족한다고 설명한다. 도구 호출마다 기능 확인을 하고 Rego를 가져오는 정책 판단 지점과 매 차례 예산 재판정을 두며, 측정값으로 새 입력 점수 모델 89ms·캐시 입력 12µs, 승인 판단 p99 142µs를 제시한다. 상태는 Merkle 봉인 로그와 이중 시간 인덱스에 모으며, 캐시에 상주하는 8MiB 구간에서 기록당 재생 p50 1.1~1.8µs를 보고한다. 합성 사이클에서 종단 간 재생은 원래 실행 시간의 1.17배이고, 새 VMM 재개는 25.3ms다. 이는 업체가 이 자료에서 공개한 master 측정치이며 독립 검증 결과로 제시된 것은 아니다.

계산의 재현 자료에는 plrn031_projection.py, plrn031_chain_model.py, plrn031_tracelab_extract.py, plrn031_weka_tree_check.py가 포함된다. 체인 모델은 배포 유형마다 행동 100만 건을 시뮬레이션했으며 시드 31을 사용했다. 네트워크 왕복의 p99/중앙값 비율은 3배, 처리 비율은 8배, 최종 결합 단계는 6배로 설정했다. 민감도 분석은 행별 40만 건, 시드 7을 사용했다. TraceLab 분포는 2025년 9월부터 2026년 7월까지 8,058개 세션의 Claude Code·Codex 호출 665,453건에서 추출했다. 논문과 데이터 출처에는 TraceLab 논문, TraceLab 데이터셋, Jev 소개, this-that-model-1.0, REFLEX, Prompt Guard 2 모델 카드, Lakera 지연시간 벤치마크가 있다.

추적 자료가 보여주는 에이전트 작업 분포

Claude Code와 Codex의 8,058개 세션에서 수집한 57,604개 차례 중 61%는 모델 호출 한 번으로 끝났고, 중앙값 차례도 한 번의 호출이다. 나머지 39%는 중앙값 모델 시간 100초, p95 20분 초과인 다중 라운드 작업이다. 라운드 수는 p90에서 22회, p99에서 148회였으며 가장 긴 측정 체인은 7,786회였다. 전체 차례의 평균은 11.2라운드로 중앙값보다 크게 길다.

다중 라운드 부류 안에서 하위 p90은 전체 차례의 29%이며 라운드 수는 2~21회, 해당 부류의 p25 모델 시간은 43초다. p90~p99 구간은 9%, 라운드 수 22~147회, p90 모델 시간 614초다. 상위 1%는 라운드가 148회 이상이고 해당 부류의 p95가 1,261초다. 한 번의 평균에 맞춰 승인·예산·재생 용량을 설정하면 짧은 차례에서는 자원이 놀거나 긴 체인의 꼬리를 감당하지 못할 수 있다는 것이 자료의 설명이다.

기록된 665,453개 라운드 중 72%는 도구 호출 하나, 14%는 호출 없음, 6%는 두 개, 8%는 세 개 이상을 냈다. 도구 호출 수 p99는 4다. 제어 비용이 작업별로 부과되면 중앙값 라운드는 저렴하지만 호출 수가 많은 꼬리에서 비용이 배가된다. 자료는 속도 상한의 기본 사례로 도구 호출 한 번, 스트레스 사례로 약 p95에 해당하는 세 번을 썼다.

한 단계 위의 세션 트리에서도 작업은 고르게 분포하지 않는다. SemiAnalysis의 2026년 6월 WEKA 자료에 담긴 Claude Code 트리 393개 중 45%는 하위 에이전트로 분기했다. 분기 트리는 중앙값 하위 에이전트 그룹이 4개, 모델 호출이 233회로 평면 트리의 48회보다 많았다. 하위 에이전트 작업은 기록된 호출의 42.5%를 차지했다. 내부 호출의 77%는 주 에이전트와 같은 최첨단 Opus 모델을 썼지만, 작업과 출력이 짧아 호출당 중앙값은 5.0초로 주 스트림의 8.3초보다 짧았다. 자료는 현재의 이전이 작은 모델보다 작은 작업으로 먼저 진행된다고 설명한다.

따라서 핵심 쟁점은 제어가 필요한지 여부가 아니라, 작업이 빨라지는 동안 제어가 행동 전에 완료될 수 있는지다. 자료의 예측에 따르면 빠른 차례가 절반에 이르면 전형적인 차례에서 제어 대기가 두드러지고, 평균 작업 시간 기준으로는 라우팅이 임계값에 도달하는 시점에 제어가 판단보다 많은 시간을 차지한다. 공개 SaaS 훅 체계에서는 제어를 끄거나, 속도를 낮추거나, 대체 체계로 옮기는 선택이 뒤따를 수 있다. 규제 대상 기업은 검사를 끄기 어려워 속도를 제한하거나 체계를 교체해야 한다는 것이 저자들의 주장이다.