AI 에이전트 도입, 기술 말고 이 3가지부터 확인하세요

1분 요약 읽기💡

AI 에이전트 파일럿이 실제 업무 운영까지 가는 비율은 11~14%입니다. 나머지 86~89%는 시범 운영에서 끝납니다. 원인 1순위는 AI 성능이 아니라 책임 소재가 흩어져 있는 관리 구조였습니다. 여러 부서의 에이전트를 하나로 묶어 관리하는 체계를 갖춘 조직은 7~8%, 에이전트가 무슨 작업을 했는지 끝까지 확인할 수 있는 조직은 23%에 그쳤습니다.

도입 전 확인할 것은 세 가지입니다. 공통 표준(MCP·A2A)을 쓰는가, 작업 기록과 사람 승인 절차가 있는가, 에이전트를 여러 대 굴릴 때 중앙에서 통제할 수 있는가. 이렇게 여러 에이전트를 묶어 설계·관리하는 일을 AI 에이전트 오케스트레이션이라고 부릅니다.

이 글의 수치는 FifthRow가 2026년 5월 4일 공개한 「AI Agent Orchestration Goes Enterprise: The April 2026 Playbook」에서 가져왔습니다.

AI 에이전트 도입 프로젝트, 10개 중 8개가 멈추는 지점은 기술이 아니었습니다. AI 모델 성능은 분기마다 좋아지고 있는데, 왜 시범 운영에서 실제 업무로 넘어가는 사례는 늘지 않는 걸까요.

AI 에이전트는 "이거 알아서 처리해줘"라고 시키면 여러 단계를 스스로 밟아 결과를 내는 소프트웨어입니다. 아마 여러분 회사에서도 한 번쯤 돌려봤을 겁니다. 문제는 그 시범 운영이 회사의 정식 업무 프로세스로 자리 잡는 경우가 드물다는 겁니다.

파일럿은 왜 실무로 안 넘어가는가

FifthRow 조사에서 파일럿이 프로덕션(실제 운영) 단계까지 간 비율은 11~14%였습니다. 열 개를 시작하면 여덟 개 이상이 중간에 멈춥니다. 그리고 다음 분기에 다른 팀이 비슷한 걸 또 시작합니다.

실패 원인으로 지목된 것들을 보면 기술 얘기가 거의 없습니다.

· 책임 구조 분산: 에이전트를 누가 계속 관리하고 책임질지 정해지지 않음
· 관리 체계(거버넌스) 부재: 부서별 에이전트를 묶어서 볼 체계가 없음
· 레거시 시스템: 예전에 급하게 만들어둔 사내 시스템이 연동을 막음
· 연동 난이도: 다른 시스템과 붙이는 과정에서 문제 발생
· 벤더 종속: 특정 업체 제품에 묶여 확장이 어려움

비용도 만만치 않습니다. 에이전트 하나를 만드는 데 6만~30만 달러(대략 8천만 원~4억 원)가 들고, 그중 연동과 관리 체계 구축에만 전체 예산의 60%까지 들어갑니다. 유지보수가 20~50% 더 붙습니다. 즉 돈이 가장 많이 드는 곳은 AI를 똑똑하게 만드는 부분이 아니라, 그 AI를 회사 안에서 굴러가게 만드는 부분입니다.

체크포인트 1. AI끼리 통하는 '공통 언어'를 쓰고 있습니까?

AI 에이전트 오케스트레이션 공통 표준 비교 — MCP는 AI 에이전트가 사내 데이터와 외부 도구에 접근하는 규칙, A2A는 에이전트끼리 일을 주고받는 규칙

특정 업체 전용 방식으로 만들면, 나중에 시스템을 바꿀 때 처음부터 다시 만들어야 합니다.

에이전트를 도입할 때 가장 먼저 확인할 건 성능이 아니라 연결 방식입니다. 통신사가 달라도 전화가 걸리는 이유는 공통 규칙이 있기 때문입니다. AI 에이전트 쪽에도 그런 공통 규칙이 두 가지 자리를 잡아가고 있습니다.

MCP(Model Context Protocol)는 AI가 외부 도구나 사내 데이터에 접근하는 방법을 정한 규칙입니다. Anthropic이 제안했고 OpenAI, 구글, 마이크로소프트, 아마존이 함께 쓰기로 하면서 사실상 업계 표준이 됐습니다. 기업 서버 1만 곳 넘게 적용돼 있습니다.

A2A(Agent to Agent)는 에이전트끼리 직접 말을 걸고 일을 주고받는 방법을 정한 규칙입니다. 리눅스 재단이 관리하고, 150개 넘는 조직이 실제 업무에 쓰고 있습니다.

(이 숫자들은 빠르게 늘어나는 중이라 지금 찾아보면 더 커져 있을 겁니다.)

현장 반응도 이쪽으로 기울었습니다. IT 담당자의 87%가 "우리 에이전트가 다른 회사 시스템과도 연결되는 것이 가장 중요하다"고 답했고, 51%는 지금 쓰는 벤더 시스템을 전부 갈아엎기보다 그 위에 공통 규칙을 얹는 방식을 선호한다고 답했습니다. 반대로 벤더 종속을 걱정한다는 응답은 76~81%에 달했습니다.

실무 확인 질문 하나. 지금 검토 중인 솔루션이 MCP나 A2A를 지원하나요? 지원하지 않는다면, 3년 뒤 다른 제품으로 옮길 때 무엇을 다시 만들어야 하나요?

다만 오해하면 안 되는 부분이 있습니다. 공통 규칙은 에이전트끼리 대화하는 방법만 정해줍니다. 그 대화를 누가 지켜보고 책임질지는 여전히 회사가 따로 정해야 합니다. 그게 두 번째 체크포인트입니다.

체크포인트 2. "누가 무슨 일을 했는지" 기록이 남고 있습니까?

에이전트의 작업 과정을 끝까지 확인할 수 있는 조직은 23%뿐이었습니다.

회사 안에서 AI는 이미 여기저기서 늘어나고 있습니다. 영업팀이 하나 붙이고, 인사팀이 하나 붙이고, 개발팀이 또 하나 붙입니다. 각각은 잘 돌아갑니다. 그런데 전체를 한 화면에서 보는 사람이 없습니다.

FifthRow 조사에서 여러 부서에 흩어진 에이전트를 통합 관리하는 체계를 갖춘 조직은 7~8%였고, 에이전트가 어떤 판단을 거쳐 어떤 작업을 했는지 전 과정을 추적할 수 있는 조직은 23%였습니다. 열 곳 중 일고여덟 곳은 AI가 뭘 하고 있는지 부분적으로만 압니다.

이게 왜 문제인지는 사고가 나야 드러납니다. 고객에게 잘못된 견적이 나갔을 때, 그 판단을 어느 단계에서 누가 승인했는지 되짚을 수 없으면 원인 파악도 재발 방지도 안 됩니다.

그래서 필요한 장치는 두 가지입니다.

작업 기록(로그)을 나중에 손댈 수 없는 형태로 남기기. 언제, 어떤 데이터를 보고, 어떤 결정을 했는지가 남아 있어야 합니다.
사람이 최종 승인하는 지점 정하기(Human-in-the-loop). 모든 걸 사람이 볼 수는 없습니다. 금액 기준, 대외 발송 여부, 개인정보 접근 여부처럼 선을 미리 그어두는 것이 핵심입니다.

규제도 이 지점을 겨누고 있습니다. EU AI Act는 채용, 신용평가처럼 사람의 삶에 영향이 큰 분야에서 여러 에이전트를 엮어 쓰는 것을 고위험으로 분류하고, 사람의 확인 절차, 변경 불가능한 작업 기록, 사전 테스트, 에이전트 신원 확인을 요구합니다. 미국 콜로라도주도 연간 위험 점검과 소비자 고지를 요구하는 법을 만들었습니다.

규제 대응을 마지막에 붙이는 항목으로 두면 비용이 커집니다. 기록을 남기는 방식과 사람이 확인하는 지점은 설계 단계에서 넣어야 나중에 뜯어고치지 않습니다.

체크포인트 3. 에이전트가 늘어났을 때 중앙에서 통제할 수 있습니까?

MCP·A2A 표준으로 AI 에이전트 허브와 데이터·툴 카드가 연결된 아이소메트릭 일러스트

에이전트 한 대를 잘 만드는 것과, 여러 대가 서로 일을 넘기게 만드는 것은 난이도가 다릅니다. 여러 에이전트가 서로 일을 넘기도록 설계하고 그 전체를 관리하는 것을 AI 에이전트 오케스트레이션이라고 합니다. 오케스트라 지휘자처럼 각자 맡은 파트를 정해주고 순서를 통제한다는 뜻입니다.

에이전트 하나만 쓸 때는 담당자가 결과를 보고 이상하면 고치면 됩니다. 그런데 에이전트 A가 정리한 데이터를 에이전트 B가 이어받아 판단하고, 그 판단을 에이전트 C가 실행하는 구조가 되면 문제가 달라집니다. 결과가 틀렸을 때 어디서부터 틀렸는지 찾는 것 자체가 일이 됩니다.

한 곳에서 생긴 작은 오류가 뒤에 이어지는 에이전트로 그대로 번지기 때문입니다. 사람 조직으로 치면 인수인계 문서가 잘못됐는데 아무도 원본을 확인하지 않고 다음 단계로 넘기는 상황입니다.

그래서 이 단계에서 필요한 건 더 좋은 AI가 아니라 운영 규칙입니다.

· 어떤 에이전트가 어떤 업무 범위까지 맡는지 경계를 정합니다.
· 에이전트 간 인수인계 지점에서 결과를 검증하는 기준을 둡니다.
· 오류나 이상 상황이 생기면 어느 담당자에게 보고되는지 경로를 정합니다.
· 성과는 벤더가 주는 자료가 아니라 직접 확인합니다. 우리가 관리 중인 에이전트가 몇 개인지 전부 파악하고 있는지, 오류 보고가 몇 건 있었는지 같은 지표가 실질적입니다.

그래서 실무자에게 필요한 역량은 무엇이 달라질까요?

프롬프트를 잘 쓰는 능력에서, AI를 업무 시스템에 안전하게 붙이고 관리하는 능력으로 옮겨가고 있습니다.

지금까지 정리한 실패 요인을 뒤집어 보면 필요한 역량이 나옵니다. 실패 원인이 기술 성능이 아니었으니, 필요한 역량도 "AI를 잘 다루는 법"에만 머물지 않습니다.

연결 역량: 우리 회사 시스템과 AI를 공통 표준 기반으로 붙일 수 있는가. 도구 사용법을 익히는 것과는 다른 층위입니다.
관리 역량: AI의 실수나 보안 사고를 막는 가이드라인을 세울 수 있는가. 결과물을 검수하는 것을 넘어 작업 기록, 승인 지점, 권한 범위를 설계하는 일입니다.
통합 역량: 실제 업무 절차 안에 AI를 오류 없이 녹여낼 수 있는가. 오류를 발견해 고치는 수준이 아니라, 오류가 다음 단계로 번지지 않게 경계를 긋는 일입니다.

이 세 가지는 개발자만의 몫이 아닙니다. 어느 업무를 맡길지, 어디서 사람이 확인할지를 정하는 건 그 업무를 가장 잘 아는 현업 담당자의 판단입니다. 도입이 멈추는 회사와 넘어가는 회사의 차이가 여기서 갈립니다.

자주 묻는 질문 (FAQ)

Q. MCP와 A2A는 각각 무엇을 하는 표준인가요?

MCP는 AI 에이전트가 외부 도구와 데이터에 접근하는 방법을 정한 공통 규칙이고, A2A는 에이전트끼리 직접 일을 주고받는 방법을 정한 공통 규칙입니다. 둘 다 특정 업체 제품에 묶이지 않고 시스템을 연결하기 위한 기반 규칙입니다.

Q. AI 거버넌스는 구체적으로 무엇부터 준비해야 하나요?

작업 기록과 승인 지점입니다. 에이전트가 언제 어떤 데이터를 보고 어떤 결정을 했는지 나중에 수정할 수 없는 형태로 기록을 남기고, 금액이나 대외 발송처럼 사람이 반드시 확인할 지점을 미리 정해두는 것이 출발점입니다. 여러 부서의 에이전트를 하나로 묶어 볼 수 있는 담당 체계도 함께 필요합니다.

Q. Human-in-the-loop가 뭔가요?

AI가 처리하는 과정 중 중요한 결정 단계에 사람의 확인이나 승인을 넣는 방식입니다. 모든 작업을 사람이 검토한다는 뜻이 아니라, 되돌리기 어려운 결정(계약, 지급, 대외 커뮤니케이션, 개인정보 처리)에 확인 지점을 두는 설계에 가깝습니다. EU AI Act가 고위험 분야에 요구하는 항목 중 하나이기도 합니다.

Q. AI 에이전트 시대에 실무자에게 필요한 역량은 무엇인가요?

프롬프트 작성 능력을 넘어 세 가지가 필요합니다. 공통 표준 기반으로 사내 시스템과 AI를 연결하는 연결 역량, 오류와 보안 사고를 막는 가이드라인을 세우는 관리 역량, 실제 업무 절차에 AI를 녹여내는 통합 역량입니다. 어느 업무를 맡길지 판단하는 건 그 업무를 가장 잘 아는 현업 담당자의 몫이라, 개발 직군만의 역량이 아닙니다.