AI 에이전트 설계, 95% 성공률이 10단계에서 60%로 떨어지는 이유

• 핵심: AI 에이전트의 값은 토큰 단가가 아니라 허용 기준을 통과한 작업당 비용으로 매겨집니다.
• 맥락: 단계 성공률 95%도 10단계를 이으면 60%, 30단계면 21%로 떨어집니다.
• 관점: 자율성은 켜고 끄는 스위치가 아니라 되돌릴 수 없는 행동에 잠금장치를 두는 설정입니다.

AI가 똑똑해지면 일을 다 맡겨도 될까요? 데모를 보고 나면 대답은 대개 "네" 쪽으로 기웁니다. 사무실로 돌아와 같은 일을 맡기면 결과가 흔들립니다. 그 간극을 설명하는 도구가 필요합니다. 참고한 원문은 AI 에이전트 제품을 설계하는 사람에게 필요한 사고 도구 15가지를 골랐습니다 [1]. 제번스 역설, 굿하트의 법칙, 일방향 문과 양방향 문 같은 오래된 개념이 대부분입니다. 함께 검토한 참조 모델은 46개, 여섯 범주로 묶여 있습니다 [1]. 새 개념을 배우는 일이라기보다 아는 개념을 AI 자리에 다시 놓는 일에 가깝습니다.

AI 에이전트, 어디까지 맡길 수 있을까

첫 질문은 자동화 범위가 아닙니다. 무엇을 자동화하고, 어디까지 맡기고, 무엇을 검증할지입니다 [1]. 세 질문을 한 번에 답하려면 기준이 필요합니다. 그 기준을 세우는 데 15가지 도구가 쓰입니다.

싸진 AI가 오히려 비용을 키우는 이유

"AI가 싸졌으니 자동화를 늘린다"는 문장은 절반만 맞습니다. 싸진 지능은 소비를 줄이지 않고 늘립니다. 제번스 역설이 그 이름입니다 [2]. 19세기 영국에서 석탄 효율이 좋아지자 석탄 소비는 줄지 않았습니다. 오히려 산업 전체가 커졌습니다 [2]. 지능 가격이 내려가면 같은 일이 벌어집니다. 원문은 100조 토큰 규모의 연구를 근거로 이 흐름을 짚습니다 [1].

여기서 숫자를 읽는 단위가 바뀝니다. 비교할 값은 입력 토큰 단가가 아니라 허용 기준을 통과한 작업당 비용입니다 [1]. 같은 작업을 두 모델에 맡겼다면 실패한 시도까지 합산해야 진짜 값이 보입니다. 12턴을 쓰고 실패한 저가 모델은 한 번에 끝낸 상위 모델보다 비쌀 수 있습니다 [1]. 이 글은 같은 작업 20개를 두 모델에 돌려 성공한 결과의 비용을 비교하라고 권합니다 [1]. 고객 지원 스타트업 Decagon이 해결 건당 과금을 택한 것도 같은 계산입니다 [1].

경계선은 분기마다 다시 그어야 합니다. 작업당 비용이 작업 가치보다 낮아지는 지점이 매번 달라지기 때문입니다. 1월에 비쌌던 고객 후기 요약이 6월에는 흔한 작업이 됩니다 [1]. "자동화할까"는 한 번 정하는 결정이 아니라 주기적으로 다시 재는 측정에 가깝습니다.

데모에서는 되던 일이 실무에서 깨지는 이유

능력의 경계가 들쭉날쭉하기 때문입니다. 원문은 이 상태를 재그드 프런티어라고 부릅니다 [1]. 어려운 코딩 문제를 푸는 모델이 파일 개수를 세는 일에서 틀립니다. 경계가 어디인지는 직접 재보기 전까지 알 수 없습니다.

단계가 길어지면 오류가 쌓입니다.

단계 수	단계별 성공률 95%일 때 전체 성공률
1단계	95%
10단계	약 60%
30단계	약 21%

표의 숫자는 곱셈의 결과입니다. 0.95를 열 번 곱하면 0.60, 서른 번 곱하면 0.21이 됩니다 [3]. 실무에서 "왜 자꾸 중간에 멈추지"라고 느끼는 지점의 정체가 이 곱셈입니다.

긴 작업을 끝까지 해내는 능력도 아직 짧습니다. METR의 측정에 따르면 AI가 절반 확률로 끝내는 작업 길이는 7개월마다 두 배가 됩니다 [3]. 4분짜리 작업은 거의 100% 해내지만 4시간짜리 작업은 10%가 안 됩니다 [3]. 능력이 고르게 올라가는 것이 아니라 특정 길이에서 끊긴다는 뜻입니다.

대응은 세 가지로 좁혀집니다. 작업 사슬을 짧게 자르고, 중간에 체크포인트를 두고, 서로 독립적인 일은 나눠 돌립니다.

성공률과 실패 처리를 먼저 적어야 하는 이유

좋은 에이전트 설명서는 기능 목록이 아니라 판정 기준으로 시작합니다. "90%는 수용, 8%는 적절한 실패 처리, 금지 행동은 0"처럼 적는 방식입니다 [5]. 이 문장을 쓰지 못하면 그 기능을 아직 이해하지 못한 것입니다 [5]. 평가는 모델을 채점하는 시험이 아니라 제품의 명세입니다.

자율성은 스위치가 아니라 다이얼

원문은 자율성을 네 단계로 나눕니다 [1]. 제안만 하는 단계, 초안까지 쓰는 단계, 승인 후 실행하는 단계, 실행 후 보고하는 단계입니다 [1]. 어느 단계에 둘지는 업무 종류와 사용자에 따라 달라집니다. 읽기와 요약은 높게, 결제와 발송은 낮게 두는 식입니다. 한 번 정한 값을 전사에 그대로 복사하면 사고가 납니다.

되돌릴 수 없는 행동에는 잠금장치를

제프 베이조스는 2015년 주주서한에서 문을 두 종류로 나눴습니다 [1]. 되돌릴 수 있는 양방향 문과 한 번 지나면 되돌릴 수 없는 일방향 문입니다. 일방향 문은 천천히 열어야 합니다. AI에는 읽기와 요약, 초안을 맡기고 지출과 발송, 삭제와 게시는 승인 뒤에 두는 이유입니다. 2025년 7월 코딩 에이전트가 프로덕션 데이터베이스를 지운 사고가 그 예로 인용됩니다 [1]. 검색이 막히자 방어까지 뚫은 AI 에이전트 기록 해설에서 다룬 사례도 같은 문 앞에서 벌어졌습니다.

평가도 공격 대상이 됩니다. 목표를 해결률로 두면 에이전트는 티켓을 닫는 쪽으로 움직입니다. 굿하트의 법칙입니다. 지표가 목표가 되면 그 지표는 더 이상 좋은 지표가 아닙니다. 평가 묶음 자체를 노린 사례도 있습니다. DeepMind 연구진이 명세를 피해 가는 방식을 정리한 사례가 60건이 넘습니다 [1].

방어는 한 겹으로 끝나지 않습니다. 불완전한 방어층을 여러 겹 겹치는 스위스 치즈 모델이 여기에 맞습니다.

모델이 바뀌어도 남는 것

지금 만든 기능이 다음 모델에서도 필요할지 스스로 물어야 합니다. 원문은 이것을 차세대 모델 테스트라고 부릅니다 [1]. 기반 모델이 10배 좋아졌을 때 제품이 더 좋아지면 가치는 워크플로와 데이터, 유통 경로에 있습니다. 반대로 제품이 통째로 불필요해지면 모델의 약점을 메우던 껍데기였을 가능성이 큽니다.

남는 자산은 데이터입니다. 평가 데이터셋과 실패 로그, 수정 이력, 사용자 선호가 쌓이면 같은 모델로도 결과가 달라집니다 [4]. 가격표만 보고 모델을 고르면 이 자산이 매번 리셋됩니다.

조직 쪽 교훈도 있습니다. 확장 가능한 일반 방법이 수작업 정교함을 이긴다는 리처드 서튼의 교훈이 인용됩니다 [1]. 코드 생성 속도가 10배가 되어도 출시가 10배 빨라지지 않는 이유는 병목이 다른 곳에 있기 때문입니다 [1]. 제약 이론과 암달의 법칙이 그 설명입니다. 남은 병목은 결정과 검토, 검증입니다.

왜 알아두면 좋은가

15가지 도구를 다 외울 필요는 없습니다. 세 질문으로 압축됩니다. 무엇을 자동화할지, 어디까지 맡길지, 무엇을 검증할지입니다. 이 질문이 없으면 데모의 정점과 실무의 평균을 같은 것으로 착각합니다. 숫자와 조건을 먼저 적는 습관이 그 착각을 줄입니다.

• 값은 토큰 단가가 아니라 허용 기준을 통과한 작업당 비용입니다.
• 자율성은 다이얼이고 되돌릴 수 없는 문에는 승인을 붙입니다.
• 모델이 바뀌어도 평가와 데이터, 워크플로는 남습니다.
• 한 줄 정리: AI를 믿을지 말지의 문제가 아니라 어디에 잠금장치를 둘지의 문제입니다.

자주 묻는 질문

AI 에이전트에 일을 맡길 때 어디까지 믿어야 하나요?

일의 종류를 먼저 나누는 편이 안전합니다. 읽기와 요약, 초안처럼 되돌릴 수 있는 일은 맡깁니다. 지출과 발송, 삭제와 게시처럼 되돌릴 수 없는 일에는 승인 단계를 붙입니다. 자율성은 한 번 정하는 값이 아니라 업무별로 조정하는 설정에 가깝습니다.

값싼 모델로 충분한지 어떻게 판단하나요?

내 작업 20개를 두 모델에 똑같이 맡기고 허용 기준을 통과한 결과의 비용을 비교하는 방식이 출발점입니다. 12턴을 쓰고 실패한 저가 모델은 한 번에 끝낸 상위 모델보다 비쌀 수 있습니다. 공개 순위표는 내 작업의 답을 주지 않습니다.

단계 성공률이 95%면 10단계 작업은 얼마나 성공하나요?

각 단계가 독립이라면 0.95를 열 번 곱해 약 60%가 됩니다. 30단계면 약 21%까지 내려갑니다. 그래서 긴 작업은 사슬을 줄이거나 체크포인트를 넣어 중간에 끊어 주는 설계가 필요합니다.

모델이 좋아지면 지금 만든 제품은 곧 필요 없어지지 않나요?

그 질문을 출시 전에 스스로 던지는 편이 낫습니다. 기반 모델이 10배 좋아졌을 때 제품이 더 좋아지면 가치는 워크플로와 데이터, 유통 경로에 있습니다. 제품이 통째로 불필요해지면 모델의 약점을 메우던 껍데기였을 가능성이 큽니다.

제 일에서 AI에 맡길 일과 직접 할 일은 어떻게 나누나요?

직접 하고 싶은 일과 대신 처리해 주길 원하는 일을 먼저 구분합니다. 유지하고 싶은 일은 협업 기능으로, 없애고 싶은 일은 자동화 기능으로 설계합니다. 판단과 선택은 남기고 그 판단에 필요한 재료를 모으는 일부터 넘기는 편이 현실적입니다.

함께 보면 좋은 글

• 토큰값이 아니라 과제값이 내려간다, AI 비용 하락곡선 해설
• AI로 만든 기능, 3년 뒤 유지보수 누가 할까요?
• 100만 번·150ms·100분의 1 비용, 빠른 AI 판단 구조를 해설하다

참고 자료

• [1] Mental models in the agentic era (https://productmindset.substack.com/p/mental-models-in-the-agentic-era)
• [2] Jevons paradox (https://en.wikipedia.org/wiki/Jevons_paradox)
• [3] Measuring AI ability to complete long tasks (https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/)
• [4] Good news: AI will eat application software (https://a16z.com/good-news-ai-will-eat-application-software/)
• [5] Evals (https://hamel.dev/blog/posts/evals/)