왜 AI는 프로젝트의 90% 동안은 매우 똑똑해 보이다가도 마지막 10%를 결코 끝내지 못하는가

자신의 모델이 실패하도록 설계되어 있다고 확신하는 분이 또 계신가요? 마치 우리를 계속 붙잡아 두기 위해 적당히 잘 작동하도록 만들어졌을 뿐, 100% 완료된 프로젝트를 절대 주지는 않도록 설계된 것처럼 말이죠.

요약 (TL;DR): AI 기업들이 프로젝트 완료 직전에 모델을 의도적으로 실패하게 만든다는 확실한 공개적 증거는 없다고 생각합니다. 다만, 오늘날의 에이전트(Agents)들은 검증된 결과물보다는 설득력 있는 진행 상황을 보여주는 데 최적화되어 있는 경우가 많다고 생각합니다. 이러한 차이가 "거의 다 끝났었는데, 갑자기 무너져 버렸다"는 느낌을 주는 많은 이유를 설명해 줍니다.

이 글의 주장

• AI 에이전트(AI agents)는 실제 수락 기준(Acceptance criteria)을 충족하지 못하면서도 생산적으로 보일 수 있습니다.
• 장기 프로젝트에서는 아주 작은 신뢰성 격차(Reliability gaps)가 오류의 누적으로 이어져 큰 타격을 줍니다.
• "한 번 성공할 수 있다"는 것은 "안정적으로 성공할 것이다"와 같은 의미가 아닙니다.
• 더 많은 컨텍스트(Context)와 더 많은 에이전트(Agents)는 주변 시스템이 상태(State), 도구(Tools), 권한(Permissions), 그리고 검증(Verification)을 관리할 때만 도움이 됩니다.
• 업계는 유창한 진행 보고서를 완료된 작업의 증거로 판매하는 것을 멈춰야 합니다.

목차

1. 언어 모델(Language model)은 실제로 노동자가 아니다
2. 장기 프로젝트의 수학은 잔혹하다
3. "거의 완료된 효과"는 측정 가능하다
4. 왜 마지막 10%가 더 어려운가
5. 더 많은 컨텍스트(Context)가 더 많은 메모리(Memory)와 같은 것은 아니다
6. 비즈니스 인센티브(Business incentive)는 어떠한가?
7. 왜 더 많은 에이전트(Agents)가 자동으로 이를 해결하지 못하는가
8. 진정한 완료 시스템(Completion system)에 필요한 것
9. 사용자가 지금 당장 할 수 있는 것
10. 나의 결론

이 말이 어떻게 들리는지 알고 있습니다. 음모론처럼 들리겠죠.

하지만 약 3년 동안 매일 AI를 지켜보고, 그것으로 무언가를 만들고, 비용을 지불하고, 도구(Tools)에 연결하며, 에이전트(Agents)들이 결과물을 내놓지 못한 채 "작업 중"이라고 주장하는 것을 반복해서 지켜본 결과, 이 질문이 미친 소리라고는 생각하지 않습니다.

이 패턴은 실재합니다.

AI agent workflow moving toward a finish line but stopping at red failed verification gates.

검증 게이트 (verification gates)가 여전히 실패하고 있음에도, 눈에 보이는 워크플로우 (workflow)는 완료된 것처럼 보일 수 있습니다.

AI는 몇 초 만에 계획을 세울 수 있습니다. 수천 줄의 코드를 생성하고, 전문가 수준의 인터페이스를 설계하며, 아키텍처 (architecture)를 설명하고, 문서를 작성하며, 프로젝트가 거의 완료되었다고 자신 있게 말할 수 있습니다. 하지만 결과물을 테스트해보면 로그인이 작동하지 않거나, 데이터베이스 (database)가 연결되지 않았거나, 버튼의 절반이 가짜이거나, 테스트가 실패하거나, 배포 (deployment)가 깨져 있거나, 혹은 에이전트 (agent)가 완료하기 세 단계 전에서 조용히 멈춰버린 것을 발견하게 됩니다.

초반 80~90%는 마법처럼 느껴질 수 있습니다. 하지만 마지막 10%는 프로젝트 전체를 직접 수행하는 것보다 더 오래 걸릴 수 있습니다.

그렇다면 이 시스템들은 결승선 직전에 실패하도록 의도적으로 설계된 것일까요?

저의 솔직한 답변은

1. 긴 작업(long tasks) 중에 아키텍처(architecture)가 자연스럽게 신뢰할 수 없게 됩니다. 이에 대한 강력한 증거가 있습니다.
2. 모델 주변의 제품(product)이 긴 작업을 중단시키는 제한 사항을 부과합니다. 이는 많은 시스템에서 실제로 발생하는 현상입니다. 컨텍스트 제한(Context limits), 타임아웃(timeouts), 속도 제한(rate limits), 권한(permissions), 토큰 예산(token budgets), 안전 규칙(safety rules), 그리고 최대 도구 호출(maximum tool calls) 횟수 등은 실재하는 제약입니다.
3. 학습(Training) 과정이 검증된 완료(verified completion)보다 유용해 보이는 모습(appearance of helpfulness)에 더 큰 보상을 줍니다. 이 주장의 일부, 특히 추측(guessing), 과잉 확신(overconfidence), 그리고 사용자에 대한 동조(agreement with users)에 대해서는 상당한 증거가 있습니다.
4. AI 기업들이 고객이 계속 결제하도록 모델이 완료 직전에 실패하도록 의도적으로 설계합니다. 이것이 가장 심각한 주장이며, 현재 이를 증명할 수 있는 확실한 공개적 증거는 없습니다.

네 번째가 사실이 아니더라도, 처음 세 가지 요소만으로도 서두에서 설명한 것과 정확히 일치하는 경험을 만들어낼 수 있습니다.

핵심 차이점: 시스템은 비밀리에 사보타주(sabotage)되지 않더라도 정직하게 신뢰할 수 없는 상태일 수 있습니다. 그럼에도 사용자 경험은 여전히 용납할 수 없는 수준일 수 있습니다.

그렇다고 해서 업계의 책임을 면제해 줄 수는 없습니다. 기업이 제품을 허위로 묘사하기 위해 반드시 비밀리에 사보타주를 할 필요는 없습니다. 만약 시스템이 일관성이 없고, 자신의 작업 내용을 스스로 검증할 수 없으며, 인터페이스가 작업 중임을 암시함에도 불구하고 작업을 계속하지 않는다는 사실이 알려져 있다면, 이를 자율적인 작업자(autonomous worker)로 마케팅하는 것 자체가 여전히 문제입니다.

따라서 적절한 질문은 "음모론인가 아닌가"보다 더 커야 합니다.

우리는 다음과 같은 질문을 던져야 합니다:

• 시스템은 실제로 무엇을 최적화하도록 구축되었는가?
• 시스템은 무엇을 기억하는가?
• 시스템은 무엇을 관찰할 수 있는가?
• 시스템은 자신이 완료되었다는 것을 어떻게 아는가?
• 누가 시스템의 상태 보고서를 검증하는가?
• 평균 벤치마크 점수 뒤에 숨겨진 실패율은 얼마인가?
• 어떤 제한이 기술적인 것이고, 어떤 것이 안전 관련이며, 어떤 것이 상업적 선택인가?
• 의도적인 스로틀링(throttling)과 일반적인 신뢰성 부족을 구분할 수 있는 증거는 무엇인가?

이러한 질문들은 우리가 실제로 조사할 수 있는 대상을 제공합니다.

언어 모델은 실제로 작업자가 아니다

첫 번째 문제는 "에이전트(agent)"라는 단어입니다.

언어 모델은 확률적으로 높은 토큰 시퀀스 (sequences of tokens)를 생성합니다. 모델 자체에는 지속적인 작업 공간, 안정적인 메모리, 장기적인 목표, 사용자의 컴퓨터에 대한 접근 권한, 또는 시작한 일을 끝내야 한다는 내부적인 욕구가 없습니다.

AI 에이전트 (AI agent)는 해당 모델을 중심으로 구축된 시스템입니다. 일반적으로 다음과 같은 요소들이 추가됩니다:

• 목표를 설명하는 프롬프트 (prompt)
• 파일 읽기, 코드 편집, 브라우징 또는 API 호출을 위한 도구 (tools)
• 모델이 여러 번의 행동을 취할 수 있게 하는 루프 (loop)
• 단기 메모리 또는 외부 메모리의 일종
• 권한, 시간, 비용 및 중단 시점에 관한 규칙
• 이상적으로는 작업의 정확성을 판단할 수 있는 테스트 또는 다른 검증기 (verifier)

이는 에이전트가 마치 하나의 연속된 직원처럼 들릴 수 있지만, 실제로는 주어진 컨텍스트 (context)로부터 상황을 매번 재구성하는 일련의 분리된 모델 호출 (model calls)일 뿐임을 의미합니다.

이것이 바로 "작업 중입니다"라는 말이 오해를 불러일으킬 수 있는 이유 중 하나입니다. 메시지 사이의 시간 동안 지속적으로 작동하는 마음(mind)은 존재하지 않을 수도 있습니다. 주변 시스템이 실제 백그라운드 프로세스 (background process), 작업 큐 (task queue), 저장된 상태 (saved state), 그리고 관찰 가능한 활동을 갖추고 있지 않는 한, 모델은 어딘가에 앉아 작업을 계속하고 있는 것이 아닙니다. 모델은 단지 대화에 적합한 문장을 생성했을 뿐입니다.

에이전시 (agency, 주체성)에 관한 언어는 에이전시를 구현하는 엔지니어링 (engineering)보다 앞서 나가고 있습니다.

모델, 챗봇, 에이전트, 그리고 워크플로우는 같은 것이 아니다

이 용어들은 종종 서로 교체 가능한 것처럼 사용되지만, 실제로는 서로 다른 계층 (layers)을 설명합니다:

모델은 매우 유능할 수 있지만, 그 모델을 중심으로 구축된 에이전트는 형편없을 수 있습니다. 그 반대의 경우도 발생할 수 있습니다. 좋은 도구, 엄격한 스키마 (schemas), 지속적인 상태 (persistent state), 그리고 결정론적 테스트 (deterministic tests)를 갖춘 정교하게 설계된 워크플로우 (workflow) 내의 작은 모델이, 느슨한 "완료되었다고 생각될 때까지 계속 시도하라"는 루프에 놓인 거대 모델보다 더 많은 작업을 완수할 수도 있습니다.

이것이 바로 모델 이름만 비교하는 것이 프로젝트의 완수 여부에 대해 거의 아무런 정보도 주지 못하는 이유입니다. 결과는 전체 시스템에 달려 있습니다:

Outcome = model + instructions + context + tools + permissions + orchestration + environment + verification (결과 = 모델 + 지시사항 + 컨텍스트 + 도구 + 권한 + 오케스트레이션 + 환경 + 검증)

이 계층 중 어느 하나라도 깨져 있다면, 사용자는 "AI가 실패했다"라고 경험하게 됩니다.

실질적인 번역: 모델 선택도 중요하지만, 모델을 둘러싼 래퍼 (wrapper)가 실제로 작업이 완료될지를 결정하는 경우가 많습니다.

"작업 중입니다"라는 말이 인터페이스 측면에서 매우 심각한 주장인 이유

사람이 "그 일을 하고 있습니다"라고 말할 때, 우리는 몇 가지 사항을 가정합니다:

• 문장이 끝난 후에도 작업이 계속된다.
• 그 사람이 할당된 업무를 기억하고 있다.
• 대화 외부의 어딘가에 진행 상황이 존재한다.
• 그 사람이 차단 요소 (blockers)를 인지할 수 있다.
• 작업을 완료하거나, 혹은 진실된 상태를 가지고 돌아올 것이다.

이러한 가정들은 챗봇 (chatbot)에게 자동으로 적용되지 않습니다.

시스템이 백그라운드 작업 (background job)을 실행하고 있지 않다면, 턴 (turn) 사이에는 아무런 작업도 일어나지 않습니다. 만약 상태 (state)가 저장되지 않았다면, 다음 호출 시 프로젝트를 불완전하게 재구성할 수 있습니다. 만약 에이전트 (agent)가 배포 (deployment), 편지함, 데이터베이스 (database), 또는 리포지토리 (repository)를 조사할 수 없다면, 그 상태는 관찰 (observation)이 아닌 추론 (inference)일 뿐입니다.

진실된 인터페이스는 다음과 같은 상태들을 구분해야 합니다:

이러한 구분 없이는 "작업 중", "완료됨", "배포됨"이 기술적인 사실이 아닌 대화상의 기분 (moods)이 되어버립니다.

장기 프로젝트의 수학은 잔혹합니다

99%의 확률로 올바른 결정을 내리는 모델이라 할지라도, 긴 작업에서는 형편없을 수 있습니다.

100개의 의존적인 단계가 필요한 프로젝트를 상상해 보십시오. 만약 모든 단계가 99%의 정확도를 가지고 있고, 수정되지 않은 단 하나의 실수가 최종 결과를 망칠 수 있다면, 100개의 단계를 모두 맞출 확률은 다음과 같습니다:

0.99¹⁰⁰ = 36.6%

이제 단계별 신뢰도를 약간만 낮춰 보겠습니다:

실제 프로젝트는 이 단순화된 계산보다 더 복잡합니다. 어떤 오류는 해롭지 않고, 어떤 오류는 수정될 수 있으며, 어떤 단계들은 독립적이지 않습니다. 하지만 실제 프로젝트에는 분기 결정 (branching decisions), 숨겨진 의존성 (hidden dependencies), 모호한 요구사항 (vague requirements), 변경되는 파일, 만료되는 자격 증명 (expiring credentials), 도구 실패 (tool failures), 그리고 이후의 결정들을 오염시키는 실수들이 포함되어 있습니다.

기본적인 교훈은 변하지 않습니다: 작은 오류들이 서로 사슬처럼 연결될 때 거대한 실패가 됩니다.

Long AI agent task timeline showing small checked steps branching into multiple red error paths.

긴 작업은 마지막 단계에서만 실패하는 것이 아닙니다. 초기 가정이 이후의 수많은 오류로 분기될 수 있습니다.

이 지점이 바로 지능 (intelligence)과 신뢰성 (reliability)의 차이가 명확해지는 부분입니다. 모델은 마주치는 모든 개별 문제를 해결할 만큼 충분히 똑똑할 수 있지만, 동시에 전체 시퀀스 (sequence)를 망쳐버릴 만큼 충분히 신뢰할 수 없을 수도 있습니다.

단순한 방정식은 사실 관대한 편입니다

위의 계산은 각 단계가 독립적이라고 가정합니다. 실제 에이전트 (agent)의 실수들은 그렇지 않은 경우가 많습니다.

에이전트가 6번째 단계에서 프로젝트가 실제로 MongoDB를 사용함에도 불구하고 PostgreSQL을 사용한다고 잘못 결정했다고 가정해 봅시다. 그 가정은 스키마 (schema), 쿼리 (queries), 환경 변수 (environment variables), 테스트 (tests), 배포 지침 (deployment instructions), 그리고 디버깅 전략 (debugging strategy)에 영향을 미칠 수 있습니다. 시스템은 여섯 개의 개별적인 실수를 저지르는 대신, 그 결과가 프로젝트의 나머지 부분으로 퍼져나가는 하나의 근본적인 실수 (root mistake)를 저지르게 됩니다.

이를 오류 전파 (error propagation)라고 부릅니다. 이후의 행동들은 에이전트의 내부 논리(internal story)와는 일관될 수 있지만, 실제 프로젝트 관점에서는 완전히 틀릴 수 있습니다.

긴 작업(Long tasks)에는 되돌릴 수 없거나 비용이 많이 드는 행동들이 포함되어 있습니다. 잘못된 메뉴를 클릭하는 것은 수정할 수 있습니다. 하지만 데이터를 삭제하거나, 잘못된 고객에게 이메일을 보내거나, 미완성된 사이트를 게시하거나, 프로덕션 비밀키(production secret)를 교체하거나, 라이브 브랜치(live branch)에 머지(merge)하는 것은 되돌리기가 쉽지 않을 수 있습니다. 이는 신뢰성(reliability)이 단순히 에이전트가 얼마나 자주 실패하느냐에 대한 문제만이 아님을 의미합니다. 그것은 또한 에이전트가 얼마나 심각하게 실패하는지, 그리고 시스템이 그 피해를 억제할 수 있는지에 관한 것이기도 합니다.

따라서 유용한 신뢰성 모델에는 적어도 네 가지 수치가 필요합니다:

• 단계 정확도 (Step accuracy): 각 결정이 얼마나 자주 정확한가?
• 탐지율 (Detection rate): 시스템이 오류를 얼마나 자주 인지하는가?
• 복구율 (Recovery rate): 탐지 후 오류를 얼마나 자주 복구할 수 있는가?
• 실패 심각도 (Failure severity): 복구에 실패했을 때의 비용은 얼마인가?