AI 에이전트 도입 전 자가진단 12문항 — 우리 팀에 맞는지 30분 점검 2026

AI 에이전트, 우리 팀에도 붙여야 하나 고민되시죠

경쟁사가 도입했다는 소식이 들리고, 위에서는 검토해보라고 하고, 벤더 미팅에 들어가면 다 된다고 하고요. 그런데 막상 우리 업무에 붙인 모습을 떠올려보면 그림이 안 그려져요. 안 하자니 뒤처지는 것 같고, 하자니 뭘 근거로 시작해야 할지 모르겠고요.

결론부터 말하면, 에이전트 도입의 성패는 모델 성능이 아니라 착수 전에 정한 조건에서 갈려요. 가트너는 2025년 6월 전망에서 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 봤고, 이유로 비용 상승·불분명한 사업 가치·미흡한 리스크 통제 세 가지를 들었어요. 셋 다 더 좋은 모델이 나온다고 해결되는 문제가 아니에요.

뒤집으면 이 조건들은 30분이면 점검할 수 있다는 뜻이기도 해요. 이번 글은 벤더를 만나기 전에 스스로 답해볼 12문항이에요. 업무 성격, 데이터, 권한, 비용, 중단 기준 순서로 짚어가면 우리 팀이 지금 시작해도 되는지, 아니면 무엇부터 준비해야 하는지가 나와요.

먼저 정리 — 에이전트와 자동화는 다른 물건이에요

12문항에 들어가기 전에 용어부터 맞춰야 해요. 이걸 섞어 쓰면 벤더 미팅에서 서로 다른 이야기를 하게 되거든요. 차이는 판단이 어디에 있는가 하나예요.

여기서 중요한 건 오른쪽이 왼쪽의 상위 호환이 아니라는 점이에요. 절차가 이미 정해진 업무라면 규칙 기반 자동화가 더 싸고 더 안정적이에요. 에이전트는 예측 가능성을 내주고 유연함을 얻는 거래예요. 그 거래가 남는 장사인 업무에만 붙여야 해요. 자동화 대상을 고르는 기준 자체가 처음이라면 무엇부터 자동화할지 정하는 우선순위 가이드를 먼저 보시는 게 순서예요.

1~3번: 업무가 맞는지부터

1. 이 업무에 사람의 판단이 실제로 들어가나요? 매번 같은 순서로 처리되는 일이라면 에이전트가 아니라 자동화가 답이에요. "상황에 따라 다르게 처리한다"고 답할 수 있어야 후보예요. 이 문항이 '아니오'면 나머지는 볼 것도 없어요.

2. 그 판단 기준을 말로 설명할 수 있나요? 설명이 안 되는 판단은 에이전트에도 못 넘겨요. 본인 요령 — 후배에게 3분간 설명해보세요. 설명이 막히면 그건 아직 사람 머릿속에만 있는 암묵지예요. 문서로 만드는 게 먼저예요.

3. 성공을 숫자로 정의했나요? "업무가 편해진다"는 기준이 아니에요. 처리 시간, 처리 건수, 재작업 횟수, 사람 개입 비율 중 하나로 목표를 정하세요. 이게 없으면 나중에 잘된 건지 아닌지 아무도 판정할 수 없고, 판정 못 하는 프로젝트가 조용히 취소되는 40%가 돼요.

4~6번: 데이터와 문서가 준비됐는지

4. 에이전트가 읽을 자료의 최신본이 어디인지 한 곳으로 정해졌나요? 같은 문서가 세 곳에 있고 내용이 조금씩 다르면 에이전트는 그중 하나를 골라 읽어요. 사람은 "이건 옛날 거지"를 알지만 에이전트는 몰라요.

5. 낡은 자료를 걸러낼 방법이 있나요? 작년에 폐기된 정책 문서가 그대로 남아 있으면 에이전트는 그걸 근거로 판단해요. 최소한 최종 수정일이라도 붙어 있어야 해요.

6. 대상 업무의 절차 문서가 있나요? 없다면 여기서 멈추는 게 맞아요. 순서가 거꾸로거든요. 절차 문서를 만드는 건 에이전트를 안 붙이더라도 남는 자산이에요. 반복 질문을 SOP 문서로 바꾸는 5단계로 문서부터 만들고 오시면 돼요. 이 문항에서 걸리는 팀이 생각보다 많아요.

7~9번: 권한과 안전장치

7. 에이전트에 어디까지 권한을 줄지 정했나요? 읽기만 시킬지, 초안까지 만들게 할지, 실제 실행까지 맡길지요. 본인 권장 — 첫 단계는 무조건 '초안까지'예요. 발송·결제·삭제 같은 되돌리기 어려운 행동은 사람이 누르게 두세요.

8. 잘못했을 때 어디에 기록이 남나요? 에이전트가 무엇을 근거로 어떤 판단을 했는지 추적할 수 없으면 개선도 불가능해요. 가트너가 지적한 '미흡한 리스크 통제'가 대부분 이 지점이에요.

9. 언제 멈출지 정했나요? 가장 많이 빠뜨리는 문항이에요. "4주 안에 3번의 목표에 도달 못 하면 중단한다"처럼 미리 못박아두세요. 중단 조건이 없는 프로젝트는 성과가 없어도 관성으로 굴러가고, 그 관성이 비용을 키워요.

10~12번: 비용과 사람

10. 실패한 시도의 비용까지 계산했나요? 에이전트는 한 번에 끝나지 않고 여러 번 시도해요. 실패한 시도에도 비용이 붙고요. 성공 건수만으로 계산한 예산은 실제와 어긋나요. 가트너가 첫 번째 취소 이유로 비용 상승을 든 배경이에요.

11. 사람의 검수 시간을 비용에 넣었나요? 초안을 사람이 확인해야 한다면 그 시간도 원가예요. 검수가 원래 업무보다 오래 걸리면 그 도입은 마이너스예요. 이 계산법은 자동화 효과를 시간·오류·처리량으로 측정하는 방법에 정리해뒀어요.

12. 이 업무를 하던 사람이 검토에 참여했나요? 현장이 빠진 도입은 대부분 실패해요. 예외 상황을 아는 사람이 그 담당자뿐이거든요. 위에서 정해 내려보내는 방식이 안 되는 이유예요.

파일럿은 잘 되는데 확장에서 막히는 이유

도입을 검토하는 팀이 가장 많이 듣는 이야기가 "파일럿은 잘 됐는데 확장이 안 된다"예요. 이게 특이한 사고가 아니라 흔한 경로라는 걸 알고 시작하는 게 좋아요. 이유는 대개 셋 중 하나예요.

• 파일럿은 좋은 조건만 골라서 돌려요. 깨끗한 데이터, 전형적인 사례, 옆에서 지켜보는 담당자까지 붙죠. 실전에는 셋 다 없어요.
• 예외의 밀도가 다릅니다. 한 유형만 돌릴 땐 예외가 가끔이지만, 다섯 유형으로 늘리면 예외끼리 겹쳐요. 겹친 예외는 사람도 판단이 갈리는 구간이고요.
• 검수 인력이 같이 늘지 않아요. 처리량은 열 배가 되는데 확인하는 사람은 그대로면, 결국 안 보고 넘기게 돼요. 그 순간 통제가 사라져요.

그래서 파일럿의 목표는 "되는 걸 보여주는 것"이 아니라 **"어디서 깨지는지 알아내는 것"**이어야 해요. 본인 요령 — 파일럿에 일부러 애매한 사례를 섞으세요. 잘 골라낸 사례로만 돌린 성공은 확장 때 그대로 무너져요. 깨지는 지점을 미리 아는 팀이 확장에서 살아남아요.

벤더 미팅에서 던질 질문 3개

가트너는 같은 발표에서 '에이전트 워싱'을 지적했어요. 기존 챗봇이나 RPA에 이름만 바꿔 다는 관행이고, 수천 개 업체 중 실제 에이전트로 볼 만한 곳은 약 130곳 정도로 추정했고요. 구분하는 데는 세 질문이면 충분해요.

• "이 제품이 스스로 정하는 게 정확히 무엇인가요?" — 답이 뭉개지면 규칙 기반 자동화예요.
• "실패한 판단은 어디에 어떻게 기록되나요?" — 답이 없으면 운영이 안 되는 제품이에요.
• "실패한 시도에도 과금되나요?" — 여기서 실제 비용 구조가 드러나요.

세 질문에 명확한 답이 오는 제품이면 검토를 이어갈 만해요. 데모 화면이 매끄러운 것과 우리 데이터에서 작동하는 건 완전히 다른 이야기니까요.

12문항을 통과했다면, 이렇게 작게 시작하세요

통과했다고 전면 도입은 아니에요. 첫 범위는 실패해도 사람이 30분 안에 수습 가능한 크기로 자르세요.

• 업무 하나가 아니라 그 업무의 유형 하나만 (예: 문의 전체가 아니라 배송 문의만)
• 실행이 아니라 초안까지만
• 기간은 4주, 그 안에 3번 문항의 숫자를 넘기는지만 확인

넘겼으면 유형을 하나 더 얹고, 못 넘겼으면 범위가 아니라 대상 업무를 바꾸세요. 범위를 키워서 해결되는 실패는 드물어요. 작게 시작하면 실패가 사고가 아니라 데이터가 되고, 그 데이터가 다음 판단의 근거가 돼요.

오늘 30분, 12문항에 답부터 적어보세요

지금 할 일은 도구 비교가 아니에요. 12문항을 그대로 문서에 붙여놓고 팀에서 답을 적어보세요. 1번·3번·9번 중 하나라도 '아니오'가 나오면 그 답이 이번 분기의 과제예요. 도입이 아니라요.

본인 경험으로는 6번(절차 문서 있나요)에서 막히는 경우가 제일 많았어요. 그렇다면 손해가 아니에요. 절차 문서는 에이전트를 붙이든 안 붙이든 그 자체로 남거든요. 그 문서를 만들면서 1번과 2번의 답도 자연스럽게 선명해지고요. 남들이 도입 소식을 낼 때 조용히 조건을 갖춰두는 팀이, 정작 붙일 때 40%가 아니라 60%에 들어가요.