AI 에이전트 도입은 어디서 시작해 어디서 끝나나

AI 에이전트 도입은 손댈 업무 하나를 고르는 데서 시작해, 담당자가 매번 결정하지 않아도 업무가 돌아가는 상태에서 끝납니다. AI 에이전트 도입 절차는 그 사이를 다섯 구간으로 끊고, 구간마다 넘어가려면 확정해야 할 결정이 하나씩 놓여 있죠.

경쟁사가 AI 에이전트를 들였다는 소식은 대개 건너서 들려옵니다. 거래처 담당자의 한마디나 업계 뉴스 한 줄이면 충분하죠. 그때 머리에 먼저 떠오르는 물음은 “우리도 해야 하나”보다 “그래서 뭐부터 하는 건데”에 가깝습니다.

그런데 순서를 물으면 돌아오는 답은 대개 할 일의 목록입니다. 요구사항 정리, 업체 선정, 파일럿, 오픈. 순서 자체는 틀리지 않는데 그 목록을 손에 쥐어도 첫 회의는 여전히 막히죠.

프로젝트가 실제로 멈추는 자리가 할 일이 아니라 결정이기 때문입니다.

AI 에이전트 도입 절차를 ‘할 일’이 아니라 ‘결정’으로 봐야 하는 이유는?

각 구간은 작업이 끝났다고 닫히지 않고, 그 구간에서만 내릴 수 있는 결정이 확정돼야 닫히기 때문입니다. 결정이 미뤄진 채 다음 구간으로 넘어가면 그 부담은 뒤에서 몇 배로 돌아오죠.

용어부터 정리하고 가겠습니다. AI 에이전트는 질문에 답만 하는 챗봇과 달리, 목표를 받아 실제 처리까지 이어 가는 소프트웨어입니다. 주문 상태를 알려 주는 데서 멈추면 챗봇이고, 조회한 뒤 변경까지 마치면 에이전트인 셈이죠.

이 차이가 도입의 결을 바꿉니다. 답만 하는 도구는 붙여 두면 그만이지만, 일을 처리하는 도구는 권한과 예외와 책임을 회사가 미리 정해 줘야 움직이니까요. 그 ‘정해 주는 일’이 곧 결정입니다.

시장에서는 이 경계가 흐려지기도 합니다. 가트너는 2025년 6월 25일 발표에서 기존 AI 어시스턴트와 RPA, 챗봇을 실질적인 에이전트 역량 없이 이름만 바꿔 내놓는 관행을 ‘에이전트 워싱’이라 불렀고, 수천 곳에 이르는 공급업체 가운데 실제에 해당하는 곳을 약 130곳으로 추정했습니다. 이름표가 아니라 처리까지 맡길 수 있는지로 갈라 보셔야 하는 이유죠.

다섯 구간은 진단, 범위 설계, 검증, 연동과 본도입, 전사 운영입니다. 구간마다 확정할 결정이 다르고, 그 결정을 미뤘을 때 걸리는 자리도 다릅니다.

구간 이름 자체는 어느 도입 방법론에서나 비슷하게 나옵니다. 갈리는 것은 각 구간을 무엇으로 닫느냐죠. 작업이 끝나면 닫는다고 보면 일정표가 나오고, 결정이 확정되면 닫는다고 보면 판단 기준이 나옵니다.

첫 구간: 진단 — 무엇을 하지 않을지 어떻게 가리나?

진단에서 확정되는 결정은 ‘이번에 손댈 업무 하나’입니다. 고르는 일처럼 보이지만 실제로는 나머지를 이번 범위에서 덜어 내는 일이죠.

후보를 추릴 때 보는 것은 세 가지입니다. 얼마나 자주 반복되는가, 처리 규칙이 문장으로 적히는가, 틀렸을 때 되돌릴 수 있는가. 셋을 모두 채우는 업무가 첫 대상으로 안전합니다. 규칙이 담당자 머릿속에만 있거나 한 번의 실수가 곧장 고객 피해로 가는 업무는 뒤로 미루는 편이 낫죠.

제가 제조·물류·유통·서비스 현장에서 되풀이해 본 오판은 가장 아픈 업무를 첫 대상으로 고르는 것입니다. 손이 제일 많이 가는 업무는 대개 판단과 예외가 얽혀 있어 규칙으로 적히지 않죠. 아픈 곳부터 잡겠다는 결심이 첫 구간을 몇 달씩 늘리는 장면을 여러 번 봤습니다.

가상의 예로 그려 보겠습니다. 실제 고객사 자료가 아니라 흔한 상황을 재구성한 것인데, 어느 유통사의 후보가 반품 응대와 발주서 입력과 클레임 조율이었다고 해 보죠. 세 기준으로 재 보면 발주서 입력만 규칙이 문장으로 적히고 되돌리기도 쉽습니다. 가장 아픈 업무는 클레임 조율인데 첫 대상으로는 발주서 입력이 남는 셈이죠.

이 결정에 필요한 것은 긴 자료 조사가 아니라 며칠간의 관찰입니다. 담당자가 하루에 같은 화면을 몇 번 여는지, 같은 문장을 몇 번 복사해 붙이는지 세어 보면 후보는 대체로 저절로 드러나죠.

이 결정이 확정되지 않으면 견적부터 흔들립니다. 대상 업무가 모호한 채로 요청하면 업체마다 범위를 다르게 잡아, 같은 회사에 온 견적이 서로 다른 숫자를 말하는 상황이 생기죠.

진단이 닫히는 신호는 단순합니다. 담당자 셋에게 따로 물었을 때 같은 업무 이름이 나오면 닫힌 것입니다.

두 번째 구간: 범위 설계 — 성공을 무엇으로 볼지 언제 정하나?

착수 전에 정합니다. 성공 기준은 검증이 끝난 뒤 붙이는 평가표가 아니라, 검증을 시작하기 위한 조건이니까요.

이 구간에서 확정되는 결정은 두 개입니다. 무엇이 되면 성공으로 볼지, 그리고 어디까지가 이번 범위인지. 앞은 판단의 잣대이고 뒤는 일이 새어 나가는 것을 막는 울타리죠.

성공 기준을 처리 건수나 응답 속도로만 세우면 나중에 해석이 갈립니다. 건수는 늘었는데 담당자가 여전히 결과를 하나하나 확인하고 있다면 성공이라 부르기 어렵죠. 그래서 ‘사람이 손대야 하는 비율’처럼 남는 일의 양을 재는 기준이 함께 있어야 합니다. 처리량은 도구의 성적이고, 남는 일은 회사의 성적이니까요.

기준을 문장으로 적으면 이런 모양이 됩니다. 하루에 들어오는 발주서 가운데 사람이 손대야 하는 건이 다섯 건 중 하나 아래로 내려가면 계속한다. 숫자는 회사마다 다르고 방금 것도 형태를 보여 주기 위한 예시일 뿐이지만, 판정이 가능한 모양인지는 이 정도로도 가려집니다.

경계선은 세 방향으로 그립니다. 어떤 시스템까지 연결할지, 어떤 예외는 이번에 다루지 않을지, 어떤 데이터를 쓸지. 특히 ‘다루지 않을 예외’를 미리 적어 둔 회사가 뒤에서 덜 흔들립니다.

경계선이 없을 때 일이 새어 나가는 방식은 대개 비슷합니다. 잘 돌아가는 것을 본 옆 팀이 “우리 것도 조금만”을 얹고, 사소해 보이던 요청이 연결할 시스템을 하나씩 늘리죠. 범위가 늘면 일정과 비용은 뒤따라 늘지만 성공 기준은 처음 것으로 남아 있어, 나중에 무엇으로 판정할지가 흐려집니다.

그 비용이 국내 중소기업에는 가장 먼저 닿는 벽입니다. 중소기업중앙회가 스마트공장을 구축한 중소기업 502개사에 물어 2025년 10월 19일 공개한 조사에서 AI 도입이 어려운 이유 1순위는 초기 비용 부담(44.2%), 다음이 전문인력 부족(20.5%)이었죠. 범위의 경계선을 긋는 일이 곧 그 벽을 낮추는 일인 셈입니다.

여기서 단계별 문서와 승인 절차까지 파고들 수도 있지만, 그 층은 실무 담당자 손에 남는 산출물 이야기라 결이 다릅니다. 조망 단계에서는 결정 두 개가 문장으로 적혔는지만 확인하면 충분하죠.

세 번째 구간: 검증 — 계속할지 멈출지 무엇으로 가르나?

재현성이 가릅니다. 한 번 잘 나온 결과가 아니라, 다른 사람 손에서 다른 주에도 같은 결과가 나오는지가 판단 근거죠.

검증 구간의 결정은 세 갈래입니다. 계속, 중단, 재설계.

성공 아니면 실패로만 보면 ‘실패’ 판정을 피하려 판정 자체를 미루게 되고, 그것이 이 구간을 길게 끕니다. 셋 중 무엇을 고를지 가르는 조건표는 파일럿을 마친 회사가 따로 따질 층입니다.

오판이 자주 나는 자리는 데모입니다. 준비된 데이터로 준비된 시나리오를 돌리면 대개 잘 되죠. 문제는 실제 업무 데이터에 오탈자와 빈칸과 예전 양식이 섞여 있다는 것입니다. 검증 기간에 일부러 지저분한 데이터를 넣어 본 회사가 본도입 이후에 덜 놀랍니다.

중단을 실패로 여기는 분위기가 있으면 이 구간은 어김없이 늘어집니다. 두 주 만에 아니라고 판단한 프로젝트는 비용을 두 주에서 끊은 것이고, 반년을 끌다 접은 프로젝트는 같은 결론에 훨씬 비싼 값을 치른 것이죠. 중단이 정상적인 선택지라고 미리 말해 둔 회사가 검증을 빨리 끝냅니다.

중단이 드문 결말도 아닙니다. 앞서 든 가트너의 같은 발표는 2027년 말까지 에이전트 AI 프로젝트의 40% 이상이 취소될 것으로 내다봤고, 이유로 비용 상승과 불명확한 사업 가치, 미흡한 위험 통제를 들었습니다. 셋 다 검증 구간에서 판정할 수 있는 항목인데, 잣대가 없으면 취소도 계속도 아닌 연장으로 흘러갑니다.

성공 기준이 비어 있으면 검증은 끝나지 않고 연장만 됩니다.

네 번째 구간: 연동과 본도입 — 예외는 누가 받나?

이 구간에서 확정되는 결정은 예외 처리의 책임 소재입니다. 에이전트가 처리하지 못한 건을 사람이 받을지, 규칙을 더 만들어 시스템이 받게 할지 정하는 것이죠.

기술적으로는 기존 시스템에 연결하는 구간입니다. ERP의 발주 화면, 전자결재의 상신 양식, 그룹웨어와 메신저의 알림처럼 이미 쓰던 도구를 걷어내지 않고 그 특정 지점에 에이전트를 얹습니다.

예외 책임을 미뤄 두면 오픈 직후에 사고가 아니라 정체가 옵니다. 처리하지 못한 건이 어디로도 가지 못한 채 쌓이고, 담당자는 그걸 확인하느라 자동화 전보다 손이 더 가죠. 누가 몇 시간 안에 받아 처리하는지, 그 건을 어디에 기록하는지가 문장으로 정해져 있어야 합니다.

데이터를 사내에만 둘지 클라우드를 쓸지는 연동 설계보다 먼저 정해야 합니다. 사내에 두기로 하면 망 구성과 보안 검토가 연결 작업 앞에 붙어, 순서가 뒤집히면 짜 둔 설계를 다시 그리게 되죠.

연동이 끝나면 기존 절차 가운데 무엇을 없앨지도 함께 정해야 합니다. 에이전트가 처리한 뒤에도 예전 엑셀 대장을 그대로 채우고 있으면 일이 줄지 않고 두 벌이 되죠. 새로 만드는 일보다 걷어내는 일을 잊는 쪽이 제가 본 현장에서는 더 자주 남았습니다.

다섯 번째 구간: 전사 운영 — 다음 업무와 멈출 권한은 정해져 있나?

전사 운영 구간의 결정은 둘입니다. 다음 업무를 무엇을 보고 고를지, 그리고 이상이 생겼을 때 누가 멈출 수 있는지.

확장의 기준이 정해지지 않은 채 업무를 하나씩 늘리면, 새 업무를 얹을 때마다 연결과 권한과 예외 규칙을 처음부터 다시 만들게 됩니다. 앞에서 만든 것이 쌓이지 않고 매번 새 프로젝트가 되는 셈이죠. 그 기준을 무엇으로 잡아야 하는지는 확장 순서를 통째로 다뤄야 나오는 답이라, 조망 단계에서는 그 결정이 비어 있는지만 짚고 넘어갑니다.

이 구간의 또 다른 결정은 멈출 권한입니다. 에이전트가 이상하게 동작할 때 누가 즉시 끌 수 있는지, 껐다는 사실을 누구에게 알리는지가 정해져 있어야 하죠. 권한과 기록과 예외 승인을 정책 선언이 아니라 실제 통제점으로 세우는 방법은 따로 짚어 볼 만합니다.

처음 정한 규칙을 다시 볼 시점도 이 구간에서 잡아 둡니다. 업무가 바뀌면 예외의 모양도 바뀌는데 규칙은 처음 만든 채로 남기 쉬우니, 예외 목록을 펼쳐 보는 자리가 달력에 있어야 합니다.

전사 운영이라는 말이 전 직원이 쓴다는 뜻은 아닙니다. 회사가 정한 규칙 안에서 여러 업무가 돌아가는 상태를 가리키죠.

다섯 구간의 결정을 한 장으로 모으면

구간마다 확정할 결정과 그 결정을 미뤘을 때 걸리는 자리를 나란히 두면 지도가 한눈에 들어옵니다.

구간	이 구간에서 확정할 결정	미루면 걸리는 자리
진단	이번에 손댈 업무 하나(나머지는 이번 범위에서 제외)	견적·범위가 업체마다 달라짐
범위 설계	성공의 정의와 이번 범위의 경계선	검증이 닫히지 않고 연장됨
검증	계속·중단·재설계 중 하나	데모 인상만으로 본도입을 결정
연동·본도입	예외를 누가 받는가(책임 소재)	오픈 후 미처리 건이 쌓여 정체
전사 운영	다음 업무를 무엇을 보고 고를지와 멈출 권한	확장할 때마다 새 프로젝트가 됨

표를 세로로 읽으면 결정의 성격이 도중에 바뀌는 게 보입니다. 앞 두 구간은 무엇을 할지 고르는 결정이고, 뒤 세 구간은 누가 책임질지 정하는 결정이죠.

도입이 어려운 이유는 기술이 아니라 뒤쪽 결정이 사람과 조직에 걸려 있다는 데 있습니다.

구간 사이에는 순서만이 아니라 의존 관계가 있습니다. 진단이 정한 대상 업무가 있어야 성공 기준을 세울 수 있고, 성공 기준이 있어야 검증에서 계속 여부를 가릅니다. 어느 한 칸이 비면 그 뒤의 칸은 근거 없이 채워지는 셈이에요.

순서를 건너뛸 수 있는 구간은 없지만, 구간의 길이는 회사마다 크게 다릅니다. 업무 규칙이 이미 문서로 정리된 회사는 진단이 며칠이면 닫히고, 담당자 경험으로만 남아 있는 회사는 몇 주가 걸리죠.

구간을 건너뛰면 어디로 되돌아오나?

건너뛴 구간의 바로 그 자리로 돌아옵니다. 결정은 사라지지 않고 미뤄질 뿐이라, 뒤 구간에서 판단이 막히는 모습으로 다시 나타나죠.

제가 가장 자주 마주친 건너뜀은 진단을 생략하고 업체 미팅부터 잡는 것입니다. 대상 업무가 정해지지 않은 채 만나면 대화는 기능 소개로 흐르고, 회사는 무엇을 물어야 할지 모른 채 제안서를 받게 되죠. 그 제안서를 견주려면 결국 첫 구간으로 돌아가 대상부터 정해야 합니다.

범위 설계를 건너뛰면 검증 구간에서 회의가 길어집니다. 결과를 앞에 두고 잘 된 건지 아닌지를 그때부터 이야기하기 시작하는데, 잣대가 없으니 목소리 큰 쪽 의견이 판정을 대신하게 되죠.

되돌아오는 것 자체가 잘못은 아닙니다. 돌아왔다는 사실을 인정하지 않고 다음 구간의 일정을 그대로 밀고 가는 것이 문제죠. 어느 결정이 비어 있는지 확인하고 그 자리부터 채우면 전체 일정은 오히려 짧아집니다.

도입은 어디서 끝나고 무엇이 남나

도입 프로젝트가 끝나는 자리는 오픈일이 아닙니다. 담당자가 매번 결정하지 않아도 업무가 돌아가기 시작하는 지점이죠.

끝을 알아보는 표식은 세 가지입니다. 예외가 생겼을 때 누구에게 가는지 묻지 않아도 처리되고, 새 업무를 얹을 때 권한과 규칙을 처음부터 다시 만들지 않으며, 담당자가 바뀌어도 같은 방식으로 굴러가는 것. 이 셋이 갖춰지면 도입은 닫히고 운영이 시작됩니다. 오픈했는데 매주 같은 결정을 다시 하고 있다면 아직 네 번째 구간입니다.

생성 AI 업무 활용과 자동화를 주제로 한 기업 교육 자리에서 가장 자주 받는 질문이 “그래서 언제 끝납니까”입니다. 끝이 날짜가 아니라 상태라고 답하면 대개 잠깐 멈칫하시죠. 그런데 몇 달 뒤 다시 뵈면 오픈한 날이 아니라 손이 떨어진 날을 기점으로 이야기하시더군요.

그 상태가 되면 다음 업무는 다섯 구간을 처음부터 다시 밟지 않습니다. 대상과 성공 기준을 정하는 앞 두 구간은 다시 거치지만, 연결과 권한과 예외 규칙은 이미 서 있으니까요.

운영으로 넘어간 뒤에도 일이 없어지지는 않습니다. 바뀐 업무에 맞춰 규칙을 손보고, 쌓인 예외 목록을 줄이고, 새 업무를 하나씩 얹는 일이 남습니다. 다만 그 일은 프로젝트가 아니라 일상 업무의 성격을 띱니다.

직원이 이 전환을 어떻게 느끼는지는 또 다른 이야기입니다. 하루 일과의 어떤 조각이 옮겨 가는지는 도입 후 직무별 하루가 재구성되는 방식에서 짚었습니다.

우리 회사는 지금 어느 구간에 서 있을까?

지금 답이 막히는 질문이 어느 구간의 결정인지 보면 위치를 알 수 있습니다. 절차를 처음부터 밟을 것 없이, 막힌 결정 하나를 확정하는 데서 다시 출발하면 되죠.

손댈 업무를 아직 못 골랐다면 첫 구간입니다. 반복 빈도, 규칙의 명확성, 되돌림 가능성 세 가지로 후보를 추려 봅니다.
업무는 정했는데 성공 기준이 없다면 두 번째 구간입니다. 무엇이 되면 성공인지를 한 문장으로 적어 봅니다.
파일럿을 몇 달째 이어 가고 있다면 세 번째 구간입니다. 계속·중단·재설계를 가를 잣대가 문장으로 적혀 있는지부터 확인합니다.
오픈했는데 담당자 손이 더 간다면 네 번째 구간입니다. 예외를 누가 받는지부터 정합니다.
한 업무는 되는데 확장이 안 된다면 다섯 번째 구간입니다. 다음 업무를 무엇을 보고 고를지가 정해져 있는지 짚어 봅니다.

다만 증상이 난 자리가 곧 원인이 놓인 자리일까요? 눈에 보이는 막힘은 뒤 구간에서 나타나도, 비어 있는 결정은 앞 구간에 있는 경우가 많습니다.

다섯 줄 중 하나에서 손이 멈췄다면 그 자리가 지금 회사의 위치입니다. 막힌 결정을 어떻게 확정할지 함께 정리해 보고 싶다면, 현재 상황을 들고 도입 문의로 알려 주셔도 좋습니다.

자주 묻는 질문

앞 구간으로 되돌아가면 이미 쓴 비용은 버려지나요?

버려지는 몫과 남는 몫이 갈립니다. 되돌아가는 이유는 대개 결정이 비어 있어서지 만들어 둔 것이 틀려서가 아니라, 업무 규칙을 적어 둔 문서나 이미 연결해 둔 시스템은 그대로 쓰입니다. 반면 잣대 없이 돌린 검증 기간은 회수되지 않죠. 되돌아갈 때 무엇을 다시 쓰고 무엇을 접을지 먼저 나눠 두시면 왕복이 한 번으로 끝납니다.

규모가 작은 회사도 다섯 구간을 다 거쳐야 하나요?

구간을 건너뛰지는 않지만 각 구간이 아주 짧아질 수는 있습니다. 인원이 적으면 결정권자가 곧 실무자인 경우가 많아 회의 한 번으로 닫히는 구간도 생기죠. 규모가 줄이는 것은 구간의 개수가 아니라 길이입니다.

어느 구간에서 멈추는 일이 잦나요?

앞 구간의 결정이 비어 있는 채로 넘어간 자리에서 멈춥니다. 제가 본 사례에서는 파일럿을 마친 뒤 이어 갈지 말지를 가를 잣대가 없어 판단만 미뤄지는 경우가 많았죠. 그 갈림을 무엇으로 판정할지는 파일럿을 끝낸 회사가 따로 다룰 주제이고, 착수 전에 잣대를 문장으로 적어 두면 이 길목이 짧아집니다.

챗봇을 이미 쓰고 있어도 같은 순서를 밟나요?

밟습니다. 챗봇은 답변까지만 담당해 회사가 정해 줄 것이 적지만, 처리까지 맡기는 순간 권한과 예외를 정하는 결정이 새로 생기니까요. 이미 쓰는 챗봇이 있다면 진단에서 그 도구가 덮고 있는 범위를 먼저 빼는 것이 출발점입니다.

도입 도중에 대상 업무를 바꿔도 되나요?

검증 구간의 세 갈래 가운데 재설계에 해당하니 문제 될 일은 아닙니다. 다만 대상을 바꾸면 성공 기준과 경계선도 함께 다시 정해야 하고 앞 구간으로 돌아가는 셈이라는 점은 미리 공유해 두는 편이 낫습니다. 조용히 대상만 바꾸면 나중에 평가 잣대가 어긋납니다.

경쟁사가 이미 도입했다면 순서를 건너뛰어 속도를 낼 수 있나요?

속도는 순서를 건너뛰어서가 아니라 결정을 미루지 않아서 붙습니다. 남의 회사가 고른 업무가 우리 업무 구조와 같다고 보기는 어려워서, 그 회사의 순서를 그대로 옮겨 오면 대상부터 어긋나죠. 경쟁사 소식에서 가져올 정보는 ‘무엇을 하라’가 아니라 ‘이 업종에서도 자동화가 돌아가긴 하는구나’ 정도까지입니다.

참고 자료

유수호(하마다랩스 윈디플로 에반젤리스트·한양대 ERICA 겸임교수), 제조·물류·유통·서비스 업종 AI 에이전트 도입 현장 관찰 및 기업 교육 현장 관찰 — 자사 1차 자료(2026년 기준)
하마다랩스 AI 에이전트 구축 서비스 소개: https://www.hamadalabs.com/service/ai-agent
하마다랩스 윈디플로 플랫폼 소개(엔터프라이즈 시스템 커넥터·클라우드/온프레미스 배포 범위): https://www.hamadalabs.com/platform
Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027″(보도자료, 2025년 6월 25일) — 취소 전망 40% 이상과 사유 세 가지, ‘에이전트 워싱’ 정의, 실제 공급업체 약 130곳 추정: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
위 가트너 발표의 보도 확인 — SDxCentral, “According to Gartner, the future isn’t actually agentic”: https://www.sdxcentral.com/news/according-to-gartner-the-future-isnt-actually-agentic/
한국일보 보도 — 중소기업중앙회가 스마트공장 구축 중소기업 502개사에 실시해 2025년 10월 19일 공개한 ‘AI 도입에 대한 의견조사’ 결과(AI 도입이 어려운 이유: 초기 비용 부담 44.2%·전문인력 부족 20.5%): https://www.hankookilbo.com/News/Read/A2025101911550001829