‘2025년은 AI 에이전트의 해’, 2026년을 앞두고 있는 지금은?
"2025년은 AI 에이전트의 해가 될 것이다."
작년 이맘때 실리콘밸리에서 가장 자주 들리던 말입니다. AI가 스스로 판단하고 업무를 처리하는 시대, 사람은 지시만 하면 되는 미래가 온다고 했죠. 테크 컨퍼런스마다 AI 에이전트 데모가 쏟아졌고 투자자들은 관련 스타트업에 수천억 원을 쏟아부었습니다.
하지만 2025년 12월 20일, Google Cloud와 Replit은 한 AI 컨퍼런스에서 솔직하게 인정합니다.
"The tooling is not there."(도구가 아직 준비되지 않았다)
AI 에이전트를 만드는 두 거대 기업조차 어려움을 겪고 있다는 겁니다. 화려한 데모와 달리, 실제 현장에선 AI 에이전트가 제대로 작동하지 않는다는 거죠.
또 하나의 AI 에이전트 관련 실패 사례가 있습니다. 올해 초 Replit에서 일어난 사고입니다. AI 코더가 테스트 중 회사 전체 코드베이스를 삭제해버렸습니다. 백업이 없었다면 회사가 멈췄을 겁니다.
AI 에이전트 도입은 왜 이렇게 어려울까요? 그리고 Google과 Replit 같은 AI 전문 기업도 어려움을 겪고 있을까요?
AI 에이전트란 무엇인가 - 챗봇과의 결정적 차이
본격적으로 이야기하기 전에, AI 에이전트가 정확히 뭔지 짚고 넘어가겠습니다. 많은 사람들이 ‘AI 챗봇’과 ‘AI 에이전트’를 헷갈려하거든요.
일반 AI 챗봇 vs AI 에이전트
AI 챗봇은 사람이 질문하면 답변을 주는 도구입니다.
예를 들어볼까요? 사용자가 "이 문서 요약해줘"라고 하면, AI가 요약된 텍스트를 제공하고 끝입니다. 간단합니다. 한 가지 작업을 요청하면, 그 작업만 수행하고 끝나죠.
반면 AI 에이전트는 목표만 주면 알아서 계획을 세우고 실행합니다.
사용자가 "이번 분기 보고서 준비해줘"라고 하면, AI 에이전트는 1) 어떤 데이터가 필요한지 파악하고, 2) 데이터베이스에서 매출, 비용, 고객 데이터를 수집하고, 3) 데이터를 분석하고 차트를 생성하고, 4) 보고서 문서를 작성하고, 5) 관련자들에게 검토 요청 이메일을 발송합니다. 스스로 판단하며 여러 단계를 수행하는 거죠.
핵심 차이를 정리하면 이렇습니다.
AI 챗봇: 지시받은 일만 수행 → 한 가지 작업 → 사람이 다음 단계 지시
AI 에이전트: 목표 달성을 위해 필요한 일을 스스로 찾아서 수행 → 여러 단계 자동 실행 → 사람 개입 최소화
자율성이 핵심이자 위험 요소
AI 에이전트의 핵심은 자율성(Autonomy)입니다. 사람이 일일이 지시하지 않아도 AI가 알아서 다음 단계를 판단합니다. 필요하면 다른 시스템에 접근하고 데이터를 가져오고 작업을 실행합니다.
그런데 이게 왜 문제일까요? 자율성이 클수록 통제는 어려워집니다. 신입 직원이라면 중간중간 확인하고 피드백을 줄 수 있죠. 하지만 AI 에이전트는 한번 실행되면 200분 동안 혼자 돌아갑니다. 그 사이에 무슨 일이 벌어질지 아무도 모릅니다. Replit의 사고가 바로 그 결과였습니다.
왜 데모는 성공하고 실전에서는 실패할까?
"대부분은 toy examples일 뿐이다"
Replit의 CEO는 한 AI 컨퍼런스에서 이렇게 말했습니다.
"기업들이 에이전트를 만들면 모두 신이 납니다. 하지만 실제로 배포하면 제대로 작동하지 않습니다."
대부분의 AI 에이전트는 toy examples(장난감 예제)에 불과하다는 겁니다.
Toy Examples은 데모나 시연용으로만 작동하는 프로토타입을 말합니다. 통제된 환경에서는 완벽하게 작동하고, 데모 데이터로는 문제가 없습니다. 하지만 실제 현장에 배포하면 온갖 오류가 터집니다.
왜 이런 일이 벌어질까요? 실제 기업 환경은 데모 환경과 완전히 다르기 때문입니다. 데모 환경은 깨끗하게 정리된 테스트 데이터, 단순한 업무 프로세스, 예상 가능한 시나리오로 구성됩니다. 반면 실제 기업 환경은 10년 전부터 쌓인 지저분한 데이터, 부서마다 다른 복잡한 업무 방식, 예상 못한 예외 상황 투성이입니다.
PoC(Proof of Concept, 개념 검증)는 성공했지만 실전 배포(Production)는 실패하는 케이스가 대부분입니다. 회의실에서 시연할 땐 완벽했는데, 막상 현장에 배포하면 온갖 문제가 터지는 거죠. 이것이 대표적인 AI 에이전트 사례입니다.
Replit의 실제 사고, 바이브코딩 문제점의 사례
올해 초, Replit은 충격적인 사고를 겪었습니다. AI 코더가 테스트 중 회사 전체 코드베이스를 통째로 삭제한 겁니다. 실제 운영 중인 코드가 사라졌습니다. 서비스가 멈췄습니다. 다행히 백업이 있어서 복구했지만, 만약 없었다면 회사가 멈췄을 겁니다.
더 황당한 건, 이 사고가 일어난 경위입니다. 개발 환경과 프로덕션 환경을 분리하지 않았던 겁니다.
소프트웨어 개발에는 철칙이 하나 있습니다. 개발 환경과 프로덕션 환경을 반드시 분리한다는 원칙입니다.
개발 환경: 테스트용 공간입니다. 여기서는 마음껏 실험하고 코드를 망가뜨려도 됩니다. 데이터베이스를 날려도 시스템을 다운시켜도 상관없습니다. 아무도 피해를 입지 않으니까요.
프로덕션 환경: 실제 사용자들이 쓰는 공간입니다. 여기서 문제가 생기면 진짜 비즈니스가 멈춥니다. 그래서 극소수의 신뢰받는 시니어 엔지니어만 접근할 수 있습니다. 접근하려면 여러 단계의 승인과 검증을 거쳐야 합니다.
하지만 Replit은 이 기본 원칙을 지키지 않았습니다. AI에게 개발 환경과 프로덕션 환경에 대한 무제한 접근 권한을 줬던 겁니다. 그 결과, AI가 테스트 중 실제 코드베이스를 삭제해버렸습니다. 이것은 마치 회사에 첫 출근한 인턴에게 회사 금고 열쇠를 주고 은행 계좌 비밀번호까지 알려주는 것과 같습니다.
AI는 자신이 받은 명령을 나름대로 해석해서 실행합니다. 때로는 지시를 오해하고 때로는 샌드박스 환경을 탈출하려고 시도하기도 합니다.
사고 이후 Replit은 어떻게 했을까요? 개발 환경과 프로덕션 환경을 완전히 분리했습니다. AI가 테스트 코드를 아무리 망가뜨려도 실제 운영 코드에는 영향이 없도록 말이죠. 뒤늦은 조치였지만 이제라도 기본을 지키게 된 겁니다. 이것이 바이브코딩 문제점을 극명하게 보여주는 사례입니다.
Google도 "어떻게 다뤄야 할지 모른다"
구글 클라우드의 디렉터도 2025년은 AI 에이전트의 해라는 기대와 달리, 실제로는 프로토타입만 잔뜩 만든 해라고 말했습니다. 수백 개의 데모, 수천 개의 PoC를 진행했다고 하는데요.
그리고 그 중에서 성공적으로 배포된 사례는 좁은 범위, 신중한 설계, 철저한 감독이 있는 경우뿐이었다고 합니다.
Google이 관찰한 성공 패턴이 하나 있습니다. 성공하는 기업은 상향식(bottom-up) 접근을 한다는 겁니다.
조금 더 자세히 설명을 해보면 이렇습니다. 현장에서 no-code나 low-code 도구로 작은 성공을 쌓아갑니다. "이 반복 작업만 자동화하자", "이 데이터 조회만 AI로 하자" 같은 식으로요. 그게 검증되면 더 큰 에이전트로 확장하는 거죠. 일단 도입하고 보자와 같은 접근 방식은 대부분 실패합니다. 왜냐하면 현장의 복잡한 맥락을 이해하지 못한 상태에서 도구가 주어진다면 그 도구를 제대로 쓸 수 없기 때문입니다.
AI 자동화 실패하는 3가지 구조적 이유
Replit CEO는 이렇게 말합니다.
"문제는 신뢰성(reliability)과 통합(integration)입니다. 지능(intelligence) 자체가 아닙니다."
AI가 똑똑하지 못해서 실패하는 게 아닙니다. 기업 환경과 맞지 않아서 실패하는 겁니다. AI 자동화가 실패하는 3가지 구조적 이유를 깊이 파헤쳐보겠습니다.
레거시 시스템과의 충돌
첫 번째 이유는 레거시 워크플로우(Legacy Workflows)입니다. 레거시 워크플로우는 오랜 기간 사용해온 기존 업무 방식과 시스템을 말합니다.
많은 기업이 착각하는 게 있습니다. AI 에이전트를 도입하면 기존 업무가 자동으로 돌아갈 것이라고 생각하는 거죠. 하지만 그렇지 않습니다. AI 에이전트는 기존 업무 방식을 그대로 자동화하는 게 아닙니다. 완전히 새로운 프로세스를 요구합니다.
예를 들자면 기존 업무 방식은 이렇습니다.
직원A가 데이터를 엑셀로 정리하고,
팀장이 검토하고 수정 지시하고,
직원A가 수정하고,
최종 승인 후 보고서를 작성합니다.
그런데 AI 에이전트 도입 시는 이렇게 달라집니다.
AI가 여러 시스템에서 데이터를 자동 수집하고,
AI가 분석하고 보고서를 자동 생성합니다.
그런데 그러면 팀장이 검토하는 시점과 직원 A가 수정하는 시점은 언제가 되어야 할까요? AI 에이전트가 도입이 되면 일하는 프로세스가 완전히 달라집니다. 일하는 방식 자체를 재설계해야 하는 겁니다.
AI 에이전트 도입과 관련해서 많은 기업이 겪는 문제들을 보면 다음과 같은 문제들이 있습니다.
핵심 문제 4가지를 정리해 봤습니다.
승인 프로세스 충돌: 어느 시점에 사람이 확인해야 하나?
책임 소재 불명확: AI 실수는 누가 책임질까?
부서 간 협업 단절: 기존 직원 간 소통이 끊기고 업무 맥락 공유 어려움
예외 처리 불가: ‘이번만 특별히’ 같은 유연한 대응 어려움.
더 큰 문제는 시스템 통합입니다. 기업에는 수십 년간 쌓인 시스템들이 있습니다. 1990년대 ERP 시스템, 2000년대 CRM, 2010년대 각종 SaaS 도구들, 2020년대 클라우드 시스템. 이 모든 게 서로 다른 방식으로 작동합니다.
데이터 형식도 다르고, 접근 방법도 다르고, 권한 체계도 다릅니다. AI 에이전트가 이 모든 시스템에 접근해서 데이터를 가져오고 작업을 실행하려면 각 시스템마다 연동 작업이 필요합니다. 그리고 이게 말처럼 쉽지 않습니다.
‘AI 에이전트 도입하면 자동화되겠지’ 생각했다가 기존 업무가 더 복잡해지는 경우가 많습니다. 왜냐하면 AI 때문에 프로세스를 전부 다시 짜야 하기 때문입니다.
복잡하고 분산된 데이터
두 번째는 데이터 문제입니다.
많은 기업의 데이터 현실을 보면 이렇습니다.
1) 부서마다 다른 시스템 사용: 영업팀은 CRM 시스템, 재무팀은 회계 프로그램, 생산팀은 제조실행시스템(MES), 마케팅팀은 구글 애널리틱스, 인사팀은 HRIS. 각각 다른 형식, 다른 권한, 다른 접근 방식입니다.
2) 표준화되지 않은 데이터 형식: 같은 매출이라는 데이터인데 부서마다 다르게 기록합니다. 날짜 형식도 제각각으로 기록하는 경우가 많습니다.
3) 누가 어떤 데이터를 갖고 있는지 모름: 담당자가 퇴사한 경우도 있고 로컬 어딘가에 있는 경우가 많습니다.
AI 에이전트는 이런 데이터를 크롤링 해야 합니다. 여기저기 흩어진 데이터를 찾아다니며 수집하는 거죠. 그런데 이게 말처럼 쉽지 않습니다.
먼저 접근 권한의 문제가 있습니다. 각 시스템마다 권한이 다릅니다. AI에게 모든 시스템 접근 권한을 줄 순 없죠. 보안 문제가 있으니까요.
다음은 데이터 품질 문제입니다. 오래된 데이터는 오류투성이입니다. 중복된 데이터, 누락된 데이터, 잘못 입력된 데이터 등이 존재합니다.
그리고 실시간 변경 문제도 있습니다. AI가 데이터를 가져오는 순간, 다른 부서에서 그 데이터를 수정하면? 데이터 불일치가 발생합니다.
데이터 접근이 어려운 3가지 이유는 다음과 같습니다.
접근 권한 문제: 시스템마다 다른 권한. AI에게 전체 권한 부여는 보안 리스크.
데이터 품질 문제: 중복, 누락, 오류 데이터 투성이. 정제 작업 필수.
실시간 변경 문제: AI가 읽는 동안 다른 곳에서 수정하면 데이터 불일치.
더 큰 문제는 암묵지입니다. Replit CEO가 지적한 많은 일들은 글로 쓰여있지 않다는 게 이겁니다. "이 데이터는 이렇게 해석해야 해", "이 컬럼은 사실 저 의미야", "이 고객 데이터는 특별히 처리해야 해". 이런 걸 어떻게 AI에게 알려줄까요? 매뉴얼에 다 쓸 수도 없고 사람들도 정확히 기억 못 하는 경우가 많습니다.
결국 AI 에이전트는 불완전한 데이터를 가지고 판단해야 합니다. 그리고 그 판단이 틀릴 확률이 높아집니다.
AI 에이전트 도입 성공하는 3가지 원칙
절망적인 이야기만 한 건 아닙니다. Google은 성공 사례도 분석했습니다. 성공한 AI 에이전트 배포의 공통점은 3가지입니다. 하나씩 자세히 살펴보겠습니다.
원칙 1: 좁은 범위부터 시작하는 AI 자동화
Google이 분석한 성공 사례의 첫 번째 특징은 좁은 범위입니다.
❌ 잘못된 접근 : 이렇게 시작하면 실패합니다.
AI 에이전트로 전사 업무 자동화
모든 고객 문의를 AI가 처리
영업부터 생산까지 AI로 통합
✅ 올바른 접근 : 작고 구체적인 문제 하나부터 시작하기
"고객 문의 중 배송 조회만 자동화",
"데이터 분석 업무 중 월간 리포트 생성만 자동화",
"반복되는 코드 검증 작업만 자동화".
원칙 2: 신중한 범위 설정
두 번째는 신중한 범위 설정입니다. ‘범위를 좁게’와 ‘신중하게 설정’은 다릅니다. ‘범위를 좁게’는 어떤 업무를 자동화할지 정하는 거고, ‘신중하게 설정’은 그 업무 안에서 AI가 어디까지 할 수 있는지 명확히 정하는 겁니다.
도입 전 반드시 답해야 할 질문들이 있습니다. 아래와 같은 질문이 그 예시입니다.
1) 어떤 데이터에 접근할 것인가?
2) 에이전트가 어디까지 결정할 수 있는가?
3) 위험한 작업은 어떻게 차단할 것인가?
원칙 3: 철저한 감독 체계
세 번째는 철저한 감독입니다. AI에게 맡기면 알아서 하겠지와 같은 이런 기대는 위험합니다.
성공한 배포의 공통점을 보면 다음과 같은 특징들이 있습니다.
실시간 모니터링 시스템: AI가 무엇을 하고 있는지 실시간 확인, 이상 동작 감지 시 즉시 중단, 모든 행동 로그 기록. 예를 들어 데이터 분석 AI라면, 어떤 쿼리를 실행하는지 표시, 얼마나 많은 데이터에 접근하는지 표시, 예상 밖 행동 시 경고.
중요 의사결정엔 사람이 최종 승인: 고액 지출은 사람 승인, 계약 체결은 사람 검토, 데이터 삭제는 사람 확인, 외부 공개는 사람 최종 체크. AI가 초안을 만들고 사람이 최종 결정하는 구조입니다.
지속적인 피드백과 개선 루프: "이건 잘했어" / "이건 잘못됐어" 피드백, AI가 학습하며 점점 나아짐, 정기적인 성능 검토.
최종적으로는 완전 자율이 아닌 사람+AI 협업이 현실적인 목표입니다. AI가 80%를 하고, 사람이 20% 확인하는 구조. 이게 지금 가장 잘 작동하는 방식입니다.
AI 에이전트, 아직은 먼 미래인가?
아닙니다. 제대로 접근하면 지금도 가능합니다.
3가지 원칙만 기억하시면 됩니다.
1. 좁은 범위부터 시작 (Narrow)
2. 신중하게 설계 (Carefully Scoped)
3. 철저히 감독 (Heavily Supervised).
Google과 Replit의 실패는 우리에게 값진 교훈을 줍니다. 바로 ‘천천히, 하지만 확실하게’ 입니다.
2025년은 프로토타입의 해였습니다. 수많은 기업이 AI 에이전트 데모를 만들었지만 실제로 배포한 곳은 소수였습니다. 2026년은 어떨까요? 실전 배포의 해가 될 수 있을까요? 그건 우리가 이 교훈들을 얼마나 진지하게 받아들이느냐에 달려 있습니다.
AI 인사이트, 더 보고 싶으신가요?
실용적인 AI 활용 인사이트와 최신 트렌드를 더 알고 싶으시다면 디피니트의 DARVIS 블로그를 구독해보세요. (블로그 구독시 AI 관련 오프라인 행사 초대장을 우선 공유드립니다.)
DARVIS 블로그에서는 매주 업데이트되는 AI 활용 노하우와 실제 사례를 통해 업무 생산성을 높이는 방법을 공유합니다.
더 많은 AI 인사이트들이 궁금하시다면 아래의 ‘AI 인사이트 더 보러가기’를 통해서 둘러보세요.
참고 자료
Even Google and Replit struggle to deploy AI agents reliably — here's why