에이전트와 도구 사용 — 신뢰성의 산수

실행: python NN_30_agents.py (검증 환경: torch 2.8.0+cu129, RTX 5080) 이 글의 수치는 전부 그 스크립트를 돌려 얻은 것이다.

지금까지 모델이 무엇을 아는가를 봤다면, 이번엔 모델이 무엇을 하는가다. 추론 시간 계산 편에서 사고 사슬이 계산을 여러 단계로 나눴다면, 에이전트는 그 단계 하나하나를 바깥 세상에 대고 실행한다 — 검색하고, 코드를 돌리고, 파일을 고치고, 메일을 보낸다.

여기서 성질이 달라진다. 답은 틀려도 다시 물으면 그만이지만, 행동은 남는다. 그리고 단계가 여럿이면 성공은 곱해진다. 그 산수를 잰다.

환경: 상태는 0~210의 수, 도구 4개가 각각 +1·+3·+7·+11을 한다(mod 211). 목표 상태에 도달하면 성공이다. 최단 경로를 아는 정책을 학습시켰고(다음 도구 선택 정확도 99.9%), 도구는 확률 $q$ 로 실패한다(아무 일도 안 일어남).

1. 사슬은 곱셈으로 죽는다

$n$ 단계짜리 작업을 한 번에 계획하고 그대로 실행하면(열린 루프), 한 단계라도 어긋나는 순간 나머지 계획이 전부 헛돈다. 성공률은 이렇게 된다.

P(\text{성공}) = (1-q)^n

기호	뜻
$q$	도구 한 번이 실패할 확률
$n$	작업에 필요한 단계 수

직접 재 보기 A

에피소드 4,000개씩, 실패율과 단계 수를 바꿔 가며 쟀다.

에이전트 신뢰성

단계 수	1	2	4	8	12	16
실패율 0% (기준선)	98.9%	98.7%	98.5%	98.5%	98.5%	98.5%
실패율 2%	97.2%	94.6%	90.7%	84.0%	77.5%	71.3%
실패율 5%	94.6%	89.2%	80.4%	65.0%	52.5%	42.6%
실패율 10%	89.2%	79.1%	64.4%	42.8%	28.5%	19.3%
실패율 20%	79.8%	62.7%	40.2%	17.1%	7.0%	2.8%

(실패율 0%에서도 98.5%인 것은 정책 자체가 1.5%쯤 틀리기 때문이다 — 그게 이 실험의 천장이다.)

실측이 $(1-q)^n$ 과 거의 정확히 겹친다(10%·16단계에서 실측 19.3% 대 예측 18.5%). 눈여겨볼 것은 한 단계만 보면 멀쩡해 보인다는 점이다. 도구 성공률 90%는 나쁘지 않게 들리지만, 16단계를 이으면 다섯 번에 네 번은 실패한다. 에이전트 데모는 잘 되는데 실제 업무에 붙이면 무너지는 일이 흔한 이유가 이것이다 — 단계 수가 늘었을 뿐인데 체감이 완전히 달라진다.

2. 관측과 재시도가 사슬을 되살린다

해법은 계획을 더 잘 짜는 것이 아니다. 매 단계 결과를 보고 거기서 다시 계획하는 것이다(폐루프). 도구가 실패해도 상태가 그대로일 뿐이니, 다음 턴에 같은 자리에서 다시 시도하면 된다.

직접 재 보기 B

같은 정책, 같은 실패율로 열린 루프와 폐루프를 나란히 돌렸다(폐루프에는 단계 수의 2배를 예산으로 줬다).

실패율	방식	1단계	4단계	8단계	16단계
5%	한 번에 계획	94.0%	79.8%	65.3%	42.6%
5%	매 단계 관측	98.8%	99.9%	99.9%	99.9%
10%	한 번에 계획	89.2%	64.4%	42.8%	19.3%
10%	매 단계 관측	98.0%	99.7%	99.9%	99.9%
20%	한 번에 계획	79.1%	41.2%	16.9%	3.2%
20%	매 단계 관측	95.1%	98.7%	99.6%	99.9%

실패율 20%에서 16단계 작업의 성공률이 3.2%에서 99.9%로 올라간다. 모델도 도구도 바뀌지 않았다. 바뀐 것은 관측을 하느냐뿐이다.

더 흥미로운 것은 곡선의 모양이다. 열린 루프는 단계가 늘수록 떨어지는데, 폐루프는 단계가 늘수록 오히려 좋아진다(98.0% → 99.9%). 재시도 예산이 단계 수에 비례해 늘어나 실패를 흡수할 여유가 커지기 때문이다. 한 번에 다 맞히기에서 틀리면 다시 하기로 문제를 바꾸면, 긴 작업이 오히려 안전해진다.

이것이 오늘날 에이전트 하네스가 하나같이 관찰-행동 루프로 생긴 이유다. 계획을 길게 뽑아 놓고 그대로 실행하는 구조는 실패율에 지수로 노출되고, 매 턴 결과를 되먹이는 구조는 그렇지 않다.

3. 단, 되돌릴 수 있을 때만

2절의 마법에는 숨은 전제가 있다. 실패해도 아무 일도 일어나지 않았다는 것이다. 현실의 도구는 다르다. 파일을 지우고, 돈을 보내고, 메일이 나가고, 프로덕션 설정이 바뀐다. 그런 실패는 다시 시도할 자리가 없다.

직접 재 보기 C

실패율 10%를 고정하고, 그 실패 중 몇 %가 되돌릴 수 없는 사고인가를 바꿔 가며 폐루프로 돌렸다.

실패 중 비가역 비율	1단계	4단계	8단계	16단계
0% (전부 되돌릴 수 있음)	98.5%	99.9%	100.0%	100.0%
10%	97.7%	95.6%	91.4%	83.5%
30%	95.8%	87.5%	76.2%	59.2%
50%	94.0%	80.3%	64.4%	42.5%
100% (전부 비가역)	89.5%	65.1%	41.8%	18.3%

비가역 비율이 100%가 되면 폐루프의 이점이 통째로 사라진다(16단계 18.3% — 1절의 열린 루프 19.3%와 같다). 그리고 10%만 섞여도 16단계 성공률이 99.9%에서 83.5%로 떨어진다. 재시도는 되돌릴 수 있는 실패만 흡수할 수 있고, 되돌릴 수 없는 실패는 그대로 곱셈에 남는다.

여기서 권한 단조성 편이 왜 알고리즘 문제인지가 분명해진다. “에이전트에게 무엇을 허용할 것인가”는 안전 취향의 문제가 아니라 성공률의 문제다. 비가역 행동을 줄이면 (샌드박스, 드라이런, 승인 게이트, 되돌리기 가능한 커밋) 위 표에서 위쪽 줄로 이동한다. 그리고 명세 게이밍 편이 말한 대로, 에이전트가 목표를 이상하게 달성하는 경우에도 되돌릴 수 있으면 그냥 한 번의 실패지만 되돌릴 수 없으면 사고가 된다.

4. 흔한 오해와 한계

“모델이 더 똑똑해지면 해결된다” — 부분적으로만이다. 이 실험의 정책은 99.9% 정확한데도 열린 루프에서는 16단계 19.3%였다. 실패의 원인이 모델이 아니라 도구와 환경일 때, 모델을 키워도 곱셈은 그대로다.
“재시도하면 된다” — 되돌릴 수 있을 때만이다(3절). 그리고 재시도에는 예산이 든다(여기선 2배).
“성공률 95%면 쓸 만하다” — 몇 단계짜리 작업인지를 먼저 물어야 한다. 20단계면 $0.95^{20}=36\%$ 다.
“검증만 잘하면 된다” — 검증자가 틀리면 틀린 상태를 성공으로 확정한다. 추론 시간 계산 편의 생성-검증 격차가 여기서도 그대로 이득이자 위험이다.
이 글의 실험 — 상태가 하나의 수인 장난감 환경이고, 실패를 “아무 일도 안 일어남”으로 모형화했다. 실제 도구 실패는 엉뚱한 일이 일어나는 쪽이 많아 더 나쁘다. 99.9%·18.3% 같은 수는 이 설정의 값이고, 요점은 곱셈·되먹임·가역성이라는 세 가지 구조다.

5. 한 문단 요약

에이전트의 성패는 모델의 똑똑함보다 신뢰성의 산수가 지배한다. 도구가 10%만 실패해도 한 번에 계획해 실행하면 16단계 작업의 성공률은 $(1-q)^n$ 을 따라 19.3%로 무너진다(정책 정확도는 99.9%였는데도). 매 단계 결과를 관측하고 다시 계획하면 같은 조건에서 99.9%가 되고, 단계가 길수록 오히려 안전해진다 — 재시도 예산이 함께 늘기 때문이다. 다만 이 회복은 실패를 되돌릴 수 있을 때만 성립한다. 실패가 전부 비가역이면 폐루프도 18.3%로, 열린 루프와 같은 자리로 돌아간다. 그래서 에이전트 설계의 핵심 질문은 “모델이 얼마나 똑똑한가”가 아니라 “무엇을 되돌릴 수 있게 만들 것인가”다.

에이전트와 도구 사용 편까지 오며 — 중간 정리

여기까지를 관통한 질문은 결국 하나였다 — 무엇을 어디에 둘 것인가.

지식을 어디에 둘까: 가중치 안(사전학습)인가, 밖의 저장소(검색, RAG 편)인가.
계산을 어디서 살까: 파라미터(깊이, 크기)인가, 시간(반복, 사고 사슬, 루프 트랜스포머 편·추론 시간 계산 편)인가.
정밀도를 어디에 쓸까: 비트(양자화·혼합정밀도)와 메모리·속도의 거래.
권한을 어디까지 줄까: 되돌릴 수 있는 것과 없는 것의 선(권한 단조성 편).

그리고 이 연재를 쓰면서 가장 여러 번 확인한 것은 직접 재 보면 예상이 자주 틀린다는 사실이다. 플래시 어텐션의 온라인 소프트맥스는 한 줄을 빠뜨려 틀렸고, 제로샷은 대조 손실이 아니라 데이터 구조에서 왔고, “깊이를 늘리면 순차 문제가 풀린다”는 가설은 아예 반증됐다. 모든 수치를 돌려서 얻는다는 규칙은 글을 느리게 만들었지만, 틀린 확신을 여러 번 막아 줬다.

긴 문맥 편부터는 같은 방식으로 긴 문맥·증류·데이터·평가·분산 학습을 이어서 잰다.