2026년 7월 2일, Meta의 사내 타운홀 미팅에서 마크 저커버그(Mark Zuckerberg)가 AI 에이전트 개발에 대해 심도 있는 발언을 했다. 적어도 최근 4개월간의 에이전트 개발 궤도는 우리가 기대했던 것만큼 가속화되지 않고 있다는 취지의 내용이다. Meta는 2026년에 AI 인프라에 최대 1,450억 달러, 일본 엔화로 약 21조 엔을 투자할 것으로 보인다. 그 규모의 투자를 주도하는 당사자가, 사내용이긴 하지만 진척의 지연을 인정한 셈이다.

이 발언은 일본 엔지니어들에게도 남의 일이 아니다. 2025년부터 2026년에 걸쳐 많은 일본 기업이 'AI 에이전트로 업무를 자율화한다'는 전제로 PoC(Proof of Concept, 개념 증명)나 예산 계획을 세워왔다. SIer의 제안서에도, 사내 품의서에도 에이전트가 인력을 대체한다는 그림이 그려져 있다. 그 그림을 그리는 프론티어 기업이 '아직 오지 않았다'라고 말할 때, 우리는 무엇을 읽어내야 하는가.

여기서 가장 해서는 안 될 일은 이 발언을 'AI는 역시 버블이었다'라고 받아들이는 것이다. 사실 데이터를 보면 AI의 능력 그 자체는 지금도 지수 함수적으로 성장하고 있다. 성장하고 있는데 실운용이 진전되지 않는다. 이 일견 모순된 두 가지 사실이 동시에 성립하는 이유야말로 본 기사의 핵심이다. 결론부터 말하자면, 원인은 모델의 똑똑함이 아니라, 긴 절차를 거치며 쌓이는 '오차의 복리'에 있다.

참고로, Qiita에는 이미 에이전트 평가를 CI(Continuous Integration, 지속적 통합)에 올리는 구현 절차를 친절하게 해설한 좋은 글이 존재한다. 본 기사는 그 전 단계, 즉 '왜 실전에서 실패하는가'를 수식과 외부 데이터로 설명하며, 일본 기업이 에이전트 투자를 어떻게 판단해야 하는지에 대한 경영·조달 측면의 시각에 집중한다. 구현 가이드와 보완 관계에 있다고 생각해주길 바란다.

먼저 사실관계를 1차 보도에 가까운 정보로부터 정리한다.

저커버그는 2026년 1월부터 2월의 계획 단계에서는 경영진이 Anthropic의 Claude Code와 같은 도구에 '초낙관적'이었다고 회상하며, 그 도박은 아직 결실을 보지 못했다고 말했다. 동시에 향후 3~6개월 내에 더 큰 효과가 나타나기 시작할 것이라는 기대도 나타냈다. 이 발언의 배경에는 Meta가 2026년 5월에 약 10%의 인원을 감축하고, 약 7,000명을 AI 관련 팀으로 재배치한 조직 개편이 있다. 즉, 조직을 에이전트 전제로 재편한 직후에 그 전제의 안착이 늦어지고 있다는 구도다.

중요한 것은 이것이 Meta 한 회사의 약한 소리가 아니라는 점이다. 동일한 현상을 전혀 다른 각도에서 측정하고 있는 연구가 두 가지 있다.

하나는 METR에 의한, AI가 얼마나 긴 태스크를 완수할 수 있는지에 대한 지속적인 측정이다. 그들은 '50%의 확률로 성공할 수 있는 태스크의 길이'를 시간축으로 정의했다. 현시점의 프론티어 모델은 인간이라면 4분 미만으로 끝낼 태스크는 거의 100% 수행하는 반면, 인간이 4시간을 초과하는 태스크는 10% 미만만이 성공한다. 50% 성공의 지평선은 약 1시간이며, 이 지평선은 약 7개월마다 배증하는 페이스로 계속 늘어나고 있다.

또 하나는 Sierra의 τ-bench(타우벤치)다. 이는 도구를 사용하여 사용자와 대화하며 업무를 수행하는 에이전트를 평가한다. 그들이 도입한 pass^k라는 지표가 보여준 것은 잔혹한 숫자였다. gpt-4o는 소매 도메인의 태스크를 한 번에 통과하는 성공률(pass@1)이 50% 미만이며, 동일한 태스크를 8회 연속으로 모두 성공시킬 확률(pass^8)은 25%를 밑돈다. 한 번 할 수 있는 것과 매번 할 수 있는 것 사이에는 이 정도의 단절이 있다.

세 주체는 입장도 측정 방식도 다르지만, 동일한 벽을 다른 면에서 건드리고 있다. 저커버그는 사업의 안착 측면에서, METR은 달성 가능한 태스크 길이 측면에서, Sierra는 시행 간의 일관성 측면에서, 모두 '단발로는 가능하지만 길고 확실하게 지속할 수는 없다'라는 동일한 한계를 보고하고 있는 것이다.

여기서부터가 본론이다. 능력이 향상되고 있음에도 실운용이 진전되지 않는 이유를 수식으로 설명한다.

에이전트의 업무는 단발적인 질의응답과 달리, 여러 절차를 직렬로 연결한다. 파일을 읽고, API를 호출하고, 결과를 판단하고, 다음 행동을 결정하는 절차의 연속이다. 여기서 각 절차가 독립적으로 확률 p로 성공한다고 단순화하면, N개의 절차를 모두 성공시켜야 비로소 완료되는 태스크의 성공률은 대략 p의 N제곱이 된다.

이것이 얼마나 큰 영향을 미치는지 표로 나타내면 직관과는 반대되는 결과가 나온다.

1절차당 성공률 p = 0.95 (언뜻 보기엔 꽤 우수함)
10절차 태스크 → 0.95^10 ≒ 0.60
20절차 태스크 → 0.95^20 ≒ 0.36
...

각 단계에서 95% 정확한 모델은 단발적으로 보면 믿음직스럽다. 하지만 50단계의 워크플로 (Workflow)에 태우면 완주율은 1할(10%)을 밑돈다. 이것이 바로 '오차의 복리'다. 이자가 원금에 쌓이는 것과 마찬가지로, 실패 확률이 단계를 거듭할수록 곱연산으로 작용하기 때문이다.

이 식은 현장에서 자주 듣는 세 가지 증상을 명쾌하게 설명한다. 첫째, 데모가 잘 작동하는 이유. 데모는 단계가 짧고, 사람이 잘 수행된 실행 결과만을 골라서 보여주기 때문에 복리가 아직 작다. 둘째, 10번에 한 번꼴로 실패하는 이유. 한 단계의 작은 실패 확률이 긴 연쇄(Chain)의 어느 한 지점에서 현재화된다. 셋째, 모델을 새로 바꿨더니 중간 판단이 어긋나 이후 과정이 전부 엉망이 되는 이유. 3번째 단계의 실패는 그 자체의 실패로 끝나지 않고, 오염된 상태가 후속 모든 단계로 전파된다.

그리고 이 식은 저커버그의 발언과 METR 데이터 사이의 모순도 풀어낸다. METR이 측정하는 '50% 지평선 (50% horizon)'은 어디까지나 반반의 확률로 도달할 수 있는 길이일 뿐이다. 사업에 사용하기에는 반반의 확률로는 이야기가 되지 않는다. 만약 업무 요건이 '99% 확실하게 완주하기를 원한다'라면, 필요한 것은 50% 지평선이 아니라 훨씬 앞쪽에 있는 '고신뢰 지평선 (High-reliability horizon)'이다. 능력의 중앙값(50% 지평선)은 7개월 만에 두 배로 늘어났을지라도, 실운용이 요구하는 꼬리 부분(고신뢰 지평선)은 훨씬 짧은 상태로 아주 천천히 늘어날 뿐이다. 저커버그가 보고 있는 것은 후자이며, 벤치마크가 자랑하는 것은 전자다. 양자 사이의 격차가 바로 그가 말하는 '기대만큼 가속화되지 않고 있다'의 정체다.

$\tau$-bench의 $pass^k$는 바로 이 꼬리 부분을 측정하기 위해 만들어진 지표라고 이해하면 납득이 간다. $pass@1$이 단발적인 기민함을 측정하는 반면, $pass^k$는 'k번 연속으로 실수하지 않는가'라는 일관성, 즉 업무에 투입할 수 있는 신뢰성 그 자체를 측정하고 있다. 에이전트 평가의 주전장이 정답률에서 일관성으로 이동하고 있는 것은 바로 이 벽을 정면으로 마주하고 있기 때문이다.

덧붙이자면, METR은 능력 향상의 주요 원천이 단일 단계의 지식이나 기술이 아니라, 긴 행동 연쇄를 이어붙이는 힘의 개선에 있다고 분석한다. 뒤집어 말하면, 모델은 개별 단계에서는 이미 충분히 똑똑하며, 병목(Bottleneck)은 연쇄의 유지에 있다는 뜻이다. 그렇기에 모델 교체만으로는 벽을 넘을 수 없으며, 시스템 측면의 설계로 복리를 억제해야 한다.

지금까지의 논리를 일본 현장의 판단 기준으로 적용해 보자. 핵심은 3~6개월 기다리면 해결될 문제가 아니라는 점이다. 기다린다고 해도 지수의 밑바닥(1단계당 성공률)은 극적으로 올라가지 않는다. 해야 할 일은 태스크의 단계 수 $N$을 설계로 줄이고, 실패를 저렴하게 되돌릴 수(Rollback) 있도록 하여 복리가 이빨을 드러내기 전에 끊어내는 것이다.

복리 식은 투자 판단의 척도를 그대로 제공한다. 단계 수가 적고 실패해도 되돌릴 수 있는 영역은 현재의 모델로도 충분히 가치가 있다(Pay). 반대로 단계가 길고 실패가 불가역적인 영역은 현시점에서는 자율에 맡겨서는 안 된다.

영역의 성질	지금 바로 자율화해도 좋은가	구체적인 예시
단계가 짧고 가역적임	적극적으로 도입	정형 메일 초안 작성, 사내 문서 검색 및 요약, 코드 차이(Diff) 리뷰 보조
...	...	...
이 표의 판단 기준은 유행이 아니라, $p$의 $N$제곱이라는 하나의 식으로부터 기계적으로 도출될 수 있다. 품의나 제안 자리에서 "왜 여기는 자율이고, 저기는 인력을 남겨두는가"라는 질문을 받았을 때, 이 식은 감각론이 아닌 근거가 된다.

자율화할 때도 복리를 방치해서는 안 된다. 유효한 유형은 세 가지가 있다.

첫째는 분할이다. 50단계의 통짜 구조를 인간이나 결정적인 코드가 승인하는 지점에서 '5단계 $ imes$ 10블록'으로 나눈다. 각 블록의 입구에서 상태를 검증한 뒤 다음으로 진행하면, 실패의 전파는 블록 내부에서 멈춘다. $0.95^{50}$이 $0.08$이라 하더라도, 중간에 7번의 체크포인트를 두어 다시 실행할 수 있다면 전체 완주율은 현실적인 수준까지 회복할 수 있다.

둘째는 멱등성 (Idempotency)과 롤백 (Rollback)이다. 앞서 언급한 Qiita 기사에서도 지적하듯, "최종적인 답은 올바르게 보이지만, 중간에 몰래 결제 API를 두 번 호출했다"는 사고는 복리가 가시화되지 않는 전형적인 사례다. 부작용(Side effect)을 가진 단계는 반드시 고유한 키를 사용하여 멱등하게 만들고, 되돌릴 수 있는 형태로 만들어 두어야 한다.

# 에이전트의 부작용은 "멱등 키 + 검증 + 롤백 가능"으로 감싸야 함
def execute_side_effect(action, state):
    key = idempotency_key(action) # 동일한 행동은 동일한 키
    ...

셋째는 신뢰성으로 측정하는 것이다. 본운 투입 판단을 잘 수행된 단 한 번의 데모가 아니라, 동일 태스크를 $k$번 흘려보냈을 때의 전 문항 정답률, 즉 $pass^k$적인 지표로 내려야 한다. 사내 수락 기준을 '한 번 성공하면 합격'에서 '10번 연속으로 성공하면 합격'으로 바꾸는 것만으로도 복리에 대한 방어력은 크게 달라진다. 이 이후의 구체적인 CI 구현에 대해서는 앞서 언급한 Qiita 기사에 자세히 나와 있다.

엔지니어가 경영진에게 전달해야 할 것은 단순하다. 에이전트의 ROI(투자 대비 수익)는 모델의 똑똑함(1단계 성공률)보다, 태스크(Task)를 얼마나 짧고, 가역적(Reversible)이며, 검증 가능(Verifiable)하게 설계할 수 있느냐에 따라 결정된다. 벤더의 데모가 100단계를 일괄적으로 처리하는 것처럼 보이더라도, 그것은 복리(Compounding)가 아직 작은 선택된 실행일 뿐일지도 모른다. 평가는 반드시 자사의 실제 데이터로, 여러 번의 연속 시도를 통해 수행해야 한다. Zuckerberg가 말한 3~6개월이라는 기대치는, 뒤집어 말하면 지금 이 순간 무인 풀 자율(Full Autonomy)에 모든 것을 거는 것은 시기상조라는 프론티어(Frontier) 당사자들의 실무적인 시그널이기도 하다.

• 에이전트의 태스크는 단계 수 $N$을 세고, $p$의 $N$제곱으로 완주율을 개략적으로 계산한 뒤 설계한다. 이 식은 '왜 실운용에서 실패하는가'를 정량적으로 설명해 준다.
• 도입 대상은 '단계가 짧거나, 또는 실패가 가역적인 것'을 최우선으로 한다. 길고 비가역적인 영역은 인간을 체크포인트(Checkpoint)로 남겨둔다.
• 부작용이 있는 단계는 멱등 키(Idempotency Key)와 보상 트랜잭션(Compensating Transaction)으로 감싸서, 복리가 사고로 이어지기 전에 되돌릴 수 있도록 한다.
• 수락 기준을 단발성 성공에서 $pass^k$와 같은 연속적 성공으로 바꾼다. 평가는 자사 데이터와 여러 번의 시도로 수행한다.
• 능력(METR의 50% 지평선)은 계속 성장하지만, 실운용이 요구하는 고신뢰 지평선은 훨씬 앞쪽에 있다. 이 차이를 메우는 것은 모델의 교체가 아니라, 복리를 죽이는 시스템 설계라는 점을 이해해야 한다.

AI 에이전트는 환멸기에 접어든 것이 아니다. 단발적인 기교라는 지표로는 측정할 수 없는 '일관성(Consistency)'이라는 또 다른 산을 업계 전체가 오르기 시작했을 뿐이다. 일본 엔지니어의 승리 전략은 프론티어의 진화를 기다리는 것이 아니라, 오차의 복리를 자신들의 설계로 억제하고, 지금 바로 수익(Pay)이 발생하는 영역부터 확실하게 거두어들이는 데 있다.

• Mark Zuckerberg tells staff that AI agents haven't progressed as quickly as he'd hoped (TechCrunch)
• Exclusive-Meta's Zuckerberg says AI agent tech progressing slower than expected (Reuters/Yahoo Finance)
• Measuring AI Ability to Complete Long Tasks (METR 공식 블로그)
• Measuring AI Ability to Complete Long Software Tasks (arXiv 2503.14499)
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv 2406.12045)
• τ-bench 해설 (Sierra 공식 블로그)
• tau-bench 코드와 데이터 (GitHub / sierra-research)
• Zuckerberg says AI agent development going slower than expected (Hacker News 토론)
• 정보 보안 10대 위협 2026 (IPA · AI 관련 리스크의 위치 설정)