AI 도입 후 기업이 경험하는 다섯 가지 병목을 실제 업무 흐름 중심으로 해부한다.
입력 병목
AI는 좋은 입력을 먹고 좋은 출력을 낸다. 그런데 기업의 입력은 대개 정리되어 있지 않다. 고객 정보는 CRM에 있고, 최신 논의는 메신저에 있고, 계약서는 드라이브에 있고, 과거 이슈는 이메일에 있고, 결정의 이유는 회의에 참석한 사람의 기억 속에 있다. 사람이 일할 때는 여기저기 물어보며 맥락을 모은다. AI에게는 그 경로가 없다.
그래서 AI 도입의 첫 병목은 프롬프트가 아니다. 데이터 위치와 입력 구조다. 무엇을 넣어야 하는지, 어디서 가져와야 하는지, 어떤 자료가 최신인지, 어떤 자료는 넣으면 안 되는지 정해져 있지 않으면 AI는 매번 담당자의 손작업에 의존한다. 그러면 AI가 빠르게 처리하는 시간보다 사람이 입력을 준비하는 시간이 더 커진다.
실무에서는 “AI가 답을 잘 못한다”는 말 뒤에 입력 병목이 숨어 있는 경우가 많다. 질문이 나쁜 것이 아니라 회사 데이터가 AI가 읽을 수 있는 형태로 준비되어 있지 않은 것이다.
맥락 병목
기업 업무에는 문서화되지 않은 맥락이 많다. 이 고객은 가격에 민감하다. 저 임원은 숫자보다 리스크를 먼저 본다. 이 표현은 법무팀이 싫어한다. 이 파트너는 과거에 약속을 어긴 적이 있다. 이 프로젝트는 겉으로는 일정 문제지만 실제로는 책임 소재 문제다. 이런 맥락은 오래 일한 사람이 자연스럽게 안다.
AI는 문서에 없는 맥락을 모른다. 그래서 답은 문법적으로 맞고 논리적으로 그럴듯하지만 조직적으로 틀릴 수 있다. 기업 AX에서 중요한 것은 AI에게 모든 인간 맥락을 신비롭게 주입하는 것이 아니다. 어떤 맥락은 규칙으로 만들고, 어떤 맥락은 데이터로 만들고, 어떤 맥락은 사람이 승인해야 하는 예외로 남기는 것이다.
맥락 병목을 풀려면 회사는 “우리 회사다운 판단”을 설명할 수 있어야 한다. 좋은 제안서란 무엇인지, 위험한 고객 답변은 무엇인지, 어떤 경우 팀장 승인이 필요한지, 어떤 표현을 피해야 하는지, 어떤 데이터는 최신본으로만 써야 하는지를 정리해야 한다. AI는 회사의 암묵지를 비추는 거울이다. 암묵지가 너무 암묵적이면 AI는 평균적인 답밖에 못한다.
검토 병목
AI는 작성 속도를 폭발적으로 높인다. 그러나 검토 속도는 자동으로 높아지지 않는다. 이 차이가 조직의 새로운 병목을 만든다. 예전에는 한 명이 하루에 보고서 한 개를 가져왔다. 이제는 AI로 세 개 버전을 가져온다. 예전에는 고객 문의 답변을 하나씩 썼다. 이제는 수십 개 초안이 한꺼번에 올라온다. 승인자는 더 많은 것을 봐야 한다.
많은 회사가 이 지점에서 피로해진다. “AI를 쓰니 초안은 빨라졌는데 검토가 더 힘들다.” 이것은 실패가 아니라 자연스러운 병목 이동이다. 작성자가 병목이던 조직에서 검토자가 병목인 조직으로 바뀐 것이다. 이때 필요한 것은 더 많은 검토 시간이 아니라 검토 방식의 재설계다.
검토 기준을 체크리스트화하고, 위험도 낮은 산출물은 샘플링 검수로 바꾸고, 반복 오류는 프롬프트와 데이터에 반영하고, 고위험 결과만 사람에게 올려야 한다. 모든 AI 결과물을 사람이 꼼꼼히 읽는 구조는 지속 가능하지 않다. AI가 만든 모든 박스를 사람이 다시 들고 확인한다면 트럭을 쓸 이유가 없다.
책임 병목
기업에서 AI가 실행 단계로 가지 못하는 가장 큰 이유는 책임이다. AI가 고객에게 답변을 보냈는데 틀리면 누가 책임지는가. AI가 계약 위험을 놓치면 누가 설명하는가. AI가 잘못된 데이터를 기반으로 임원 보고서를 만들면 누가 고치는가. 이 질문이 정리되지 않으면 AI는 계속 초안 도구에 머문다.
책임 병목을 풀려면 업무를 위험도별로 나눠야 한다. 낮은 위험의 작성과 요약은 AI가 많이 처리하고 사람이 사후 확인할 수 있다. 중간 위험의 고객 응대와 내부 보고는 사람이 승인한 뒤 나가야 한다. 높은 위험의 계약, 인사, 금융, 법무, 외부 실행은 명확한 승인권자와 감사 로그가 필요하다.
중요한 것은 “AI가 책임진다”는 말은 아직 기업 운영 문장이 될 수 없다는 점이다. 책임은 사람이 진다. 다만 사람이 모든 작업을 직접 하지 않아도 되도록, AI가 어디까지 준비하고 어디서 멈추며 누가 승인하는지를 설계해야 한다.
시스템 병목
AI가 좋은 답을 만들어도 마지막에 사람이 복사해서 시스템에 붙여 넣어야 한다면 한계가 있다. 고객 문의를 분류했지만 티켓 상태는 사람이 바꾼다. 회의 액션 아이템을 정리했지만 프로젝트 관리툴 등록은 사람이 한다. 계약 위험을 추출했지만 결재 상신은 사람이 한다. 이러면 AI는 중간 보조 도구에 머문다.
기업 AX가 Agent 구조로 가야 하는 이유가 여기에 있다. Agent는 단순히 답변하는 챗봇이 아니라 필요한 도구를 호출하고, 권한 안에서 시스템을 읽고, 승인된 범위에서 기록하고, 실패하면 로그를 남기고, 예외를 사람에게 넘기는 운영 단위다. 물론 모든 것을 바로 실행형 Agent로 만들 수는 없다. 하지만 시스템 병목을 보지 않으면 AI 도입은 문서 생산성에 갇힌다.
병목은 나쁜 것이 아니다. 병목은 다음 설계 지점을 알려준다. AI 도입 후 어디가 막히는지 잘 보면 회사의 진짜 구조가 드러난다. AX 리더는 AI가 잘한 사례보다 AI가 막힌 지점을 더 열심히 봐야 한다.