저는 이탈리아 기업들을 위해 AI 에이전트(AI agents)와 자동화(automations)를 구축하고 있습니다. 그래서 저는 "에이전트가 세상을 집어삼키고 있다"는 모든 스레드를 읽을 때마다 한 가지 숫자를 머릿속에 담아둡니다. 바로 대부분의 에이전트 프로젝트는 수익을 내지 못한다는 사실입니다. MIT의 2025년 연구에 따르면, 생성형 AI (generative AI) 파일럿 프로젝트의 약 95%가 손익 계산서(P&L)에 측정 가능한 수익을 가져다주지 못했습니다. 847개의 에이전트 배포 사례를 별도로 분석한 결과, 76%가 90일 이내에 위기에 처한 것으로 나타났습니다.

흥미로운 점은 실패율 그 자체가 아니라 그 원인입니다. 이러한 프로젝트를 몇 개 출시해 본 후 내린 솔직한 판단은, 모델(model)이 원인인 경우는 거의 없다는 것입니다.

진짜 실패 원인은 AI의 상류(upstream)에 있다

에이전트 프로젝트가 중단될 때, 사후 분석(post mortem)은 대개 잘못된 계층을 비난합니다. 프롬프트(prompt), 프레임워크(framework), 도구 호출(tool calls), 컨텍스트 윈도우(context window) 같은 것들 말이죠. 이것들은 실제 문제이며, 버클리(Berkeley)의 MAST 연구는 멀티 에이전트 시스템(multi-agent systems)에서 14가지의 뚜렷한 실패 모드(failure modes)를 분류하기도 했습니다. 하지만 이것들은 증상일 뿐입니다.

근본적인 원인은 거의 항상 기업이 표준화되지 않은 프로세스에 에이전트를 투입했다는 점에 있습니다. 업무는 사람들의 머릿속에만 존재했고, 규칙에는 아무도 기록하지 않은 세 가지 예외 사항이 있었으며, 데이터는 서로 일치하지 않는 네 곳에 흩어져 있었습니다. 에이전트는 이를 해결하지 못합니다. 오히려 증폭시킵니다. 혼란을 자동화하면 이제 그 혼란이 대규모로 실행될 뿐입니다.

에이전트는 무질서를 줄이지 않습니다. 에이전트는 무질서를 포함하여 당신이 투입한 프로세스가 무엇이든 그 규모를 확장할 뿐입니다.

이와 관련된 데이터도 있습니다. 한 분석에 따르면, 명확하게 정의된 문제를 가진 프로젝트는 약 58%의 성공률을 보인 반면, "AI를 추가하라"와 같은 모호한 명령에서 시작된 프로젝트의 성공률은 22%에 불과했습니다. 표준이 기록되지 않는 이유는 구조적입니다. 버클리(Berkeley)의 연구에 따르면 운영 노하우(operational know-how)의 약 80%는 암묵적(tacit)이고 문서화되지 않은 채 업무를 수행하는 사람들에게 귀속되어 있다고 추정합니다. 이것이 바로 에이전트가 추론할 수 없는 부분입니다.

방법론: AI는 첫 번째가 아니라 마지막 3분의 1이다

저의 성공률을 바꾼 사고방식의 전환은 에이전트를 프로젝트 그 자체로 취급하는 것을 멈추는 것이었습니다. 에이전트는 작업의 마지막 3분의 1입니다. 이제 제가 따르는 방식은 실제 워크플로(workflow)를 위해 엔드 투 엔드(end to end)로 약 6개월이 소요되는 다음과 같은 형태입니다.

1~2개월 차: 워크플로(workflow)를 찾고 기준점(baseline)을 측정합니다. 가장 짜증 나는 프로세스가 아니라, 비즈니스 영향력(business impact)이 높으면서도 표준화할 수 있을 만큼 충분히 반복 가능한 프로세스를 찾아야 합니다. 이는 종종 가장 큰 불만이 터져 나오는 곳이 아니라, 전체 흐름을 저해하는 병목 지점(bottleneck)인 경우가 많습니다. 프로세스를 건드리기 전에 현재 상태를 측정하십시오. 그렇지 않으면 에이전트(agent)가 실제로 무언가를 해냈는지 결코 증명할 수 없을 것입니다.

3~4개월 차: 표준화(standardize)합니다. 절차를 작성하고, 의사결정 기준을 명시하며, 서로 충돌하는 네 가지 데이터 소스를 하나의 단일 진실 공급원(source of truth)으로 통합합니다. 이것은 모두가 건너뛰는 매력적이지 않은 단계이지만, 상위 5%가 결정되는 지점입니다. 표준화는 단순히 매뉴얼을 쓰는 것을 의미하지 않습니다. 프로세스를 반복 가능하고 측정 가능하게 만드는 것을 의미합니다.

5~6개월 차: 에이전트를 구축하고 테스트에 투입합니다. 이제 본격적인 AI 작업이 시작됩니다: 계획(planning), 도구(tools), 메모리(memory), 평가(evals), 가드레일(guardrails). 이 시점에 이르면 에이전트는 견고한 기반을 갖추게 되므로, 구축 속도는 빨라지고 실패는 미스터리한 현상이 아닌 지루한 과정이 됩니다.

만약 이 일정이 느리게 느껴진다면, 바로 그것이 핵심입니다. 95%에 속하는 팀들은 이를 "1~2주 차: 에이전트 설치"로 압축해 버립니다. 반면 5%에 속하는 팀들은 모델을 실행하기 전 대부분의 기간을 이 준비 과정에 사용합니다.

메모리(memory)가 위치하는 곳

이러한 프로젝트들이 실패하는에는 더 조용한 이유가 있습니다. 바로 시스템에 메모리(memory)가 없다는 점입니다. 모든 새로운 세션은 제로(zero) 상태에서 시작됩니다. 지난달에 내린 결정은 증발해 버리고, 사람은 똑같은 컨텍스트(context)를 영원히 다시 설명함으로써 조직의 메모리 역할을 수행하게 됩니다.

따라서 프로덕션 에이전트(production agent)를 만들기 전에, 저는 프로젝트 자체에 메모리를 부여합니다. 표준, 결정 사항, 미결 질문들이 시스템이 읽고 다시 쓸 수 있는 일반 파일(plain files)에 존재하게 합니다. 검증할 수 없는 채로 무언가를 기억해주길 바라는 채팅창에 두는 것이 아닙니다. 이는 "모델에게 기억하도록 가르치는 것"이라기보다 "열어보고, 수정하고, 신뢰할 수 있는 메모리를 프로젝트에 부여하는 것"에 가깝습니다. 저는 이 작업을 위해 사용하는 작은 키트를 cowork-os라는 이름으로 Claude Cowork를 위해 오픈 소스로 공개했습니다. 구조를 확인하고 싶다면 참고하시기 바랍니다.

솔직한 답변이 "아직은 아니다"일 때

잠재 고객에게 제가 해주는 가장 유용한 조언은 때때로 "아직은 이것을 자동화하지 마세요"라는 말입니다. 낮은 처리량(Low volume), 불안정한 프로세스, 단순히 현대적으로 보이고 싶어 하는 목표, 혹은 상류(upstream) 단계에서 이미 망가져 있는 프로세스—이 모든 경우에 에이전트(agent)를 도입하는 것은 잘못된 첫 번째 단계입니다. 먼저 프로세스를 수정하거나 폐기하십시오. 이 말을 솔직하게 하는 것이 그 어떤 데모보다 더 많은 신뢰를 얻게 해주었습니다.

이것은 결코 AI에 반대하는 것이 아닙니다. 오히려 그 반대입니다. 에이전트 하단의 프로세스가 실질적이라면, 에이전트는 진정으로 쉬운 부분입니다. 성공하는 5%의 비결은 모델링(modeling)의 비밀이 아니라, 순서(sequencing)를 지키는 규율에 있습니다.

만약 당신이 도입했다가 실패한 에이전트를 경험했다면, 저는 이것이 궁금합니다. 당신의 타임라인 중 프로세스에 투입한 시간과 모델(model)에 투입한 시간의 비율은 어떠했나요? 그리고 다음번에는 그 비율을 다르게 가져가시겠습니까?

출처 (Sources)

• MIT, "The GenAI Divide: State of AI in Business 2025" (파일럿 프로젝트의 약 95%가 손익(P&L) 수익을 내지 못함), via Fortune, 2025.
• 847개의 AI 에이전트 배포 사례 분석: 90일 이내에 76%가 위기에 처함, Medium, 2026.
• "Why Agentic AI Projects Fail" (정의된 문제 58% vs 모호한 명령 22%; 약 14%만이 프로덕션(production) 단계에 도달), Ampcome, 2026.
• "Tacit Knowledge Is Your Next Competitive Moat" (운영 노하우의 약 80%가 문서화되지 않음), California Management Review (Berkeley), 2026.
• MAST, "Why Do Multi-Agent LLM Systems Fail?" (14가지 실패 모드), UC Berkeley, arXiv:2503.13657.
• "Agentic workflow architecture: planning, tools, memory, evals, guardrails," Vellum, 2026.