기업 AX 전략, 우리 회사는 어떤 업무부터 바꿔야 할까요?
기업 AX 전략 수립 전에 확인할 3가지
안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.
오늘의 인사이트 요약
기업 AX 전략은 개선할 업무와 목표를 구체적으로 정하는 데서 시작합니다.
첫 과제는 기대 효과뿐 아니라 데이터 준비 상태와 오류의 영향까지 보고 고릅니다.
테스트 결과를 기존 업무에 연결하고, 직원이 직접 운영할 수 있어야 적용 범위를 넓힐 수 있습니다.
“우리 회사도 AI를 도입해야 하는데, 어디부터 시작해야 할까요?”
기업 AX 전략을 고민할 때 가장 먼저 부딪히는 질문입니다. 영업팀은 제안서 작성을, 고객지원팀은 문의 응대를, 운영팀은 반복적인 자료 입력을 줄이고 싶어 합니다. 모두 필요한 일이지만 한꺼번에 시작하기에는 예산과 인력이 한정되어 있습니다.
이때 필요한 것은 먼저 바꿀 업무를 고르고, 효과가 확인되면 다음 업무로 넓혀갈 수 있는 계획입니다. 고객지원 업무를 예로 들어, 이 계획에 어떤 내용이 들어가야 하는지 살펴보겠습니다.
기업 AX 전략은 바꾸고 싶은 업무에서 시작합니다
기업 AX 전략은 AI를 활용해 어떤 업무를 바꾸고, 그 결과를 어떻게 확인할지 정하는 계획입니다. 여기에는 도입할 기술뿐 아니라 사용할 자료, 담당자의 역할, 검증 방법과 이후 운영 방식도 들어갑니다. 이 내용이 구체적이어야 예산과 일정을 논의할 때도 서로 같은 일을 떠올릴 수 있습니다.
예를 들어 고객지원팀이 답변을 작성하는 데 오래 걸린다고 가정해보겠습니다.
상담 기록을 살펴보니 문장을 쓰는 시간보다 상품 정책과 과거 답변을 찾는 시간이 더 길 수도 있습니다. 그렇다면 첫 목표는 ‘고객지원 전체 자동화’보다 ‘담당자가 필요한 자료를 빨리 찾도록 돕기’에 가까워집니다.
목표를 이렇게 좁히면 무엇을 만들어야 하는지도 달라집니다.
관련 문서를 검색하고 출처와 함께 답변 초안을 보여주는 기능부터 시험할 수 있고, 고객에게 보내는 최종 답변은 담당자가 확인하도록 둘 수 있습니다. 문제가 생기는 과정을 먼저 살펴봐야 AI에 맡길 일도 분명해집니다.
첫 AX 과제는 효과가 크고 실제로 시험할 수 있는 업무로 고릅니다.
부서별로 후보 업무를 모았다면 반복 횟수와 소요 시간, 사용할 자료의 상태, 오류가 났을 때의 영향을 함께 살펴보세요.
시간이 많이 드는 일이라도 담당자마다 처리 방식이 다르고 참고 자료가 흩어져 있다면, 테스트에 앞서 업무와 자료를 정리하는 시간이 필요합니다.
첫 과제로는 결과를 확인하기 쉽고 수정할 수 있는 업무를 검토해볼 만합니다. 가령 회의록에서 후속 할 일을 정리하거나 사내 문서에서 관련 내용을 찾아주는 기능은 담당자가 원문과 결과를 비교할 수 있습니다. 다만 사내 문서라도 접근 권한은 확인해야 하고, 회의 내용에 민감한 정보가 있다면 어떤 도구에 입력할 수 있는지 먼저 정해야 합니다.
반대로 결제 승인이나 고객 보상처럼 결과가 바로 돈과 권리에 영향을 주는 업무는 사람이 승인하는 절차를 함께 설계해야 합니다. 같은 ‘자동화’라도 확인해야 할 조건이 다른 만큼, 후보 업무를 한 줄씩 적고 기대 효과와 준비할 일을 나란히 비교해보면 우선순위를 정하기 수월해집니다.
AI가 참고할 자료와 사람의 역할을 정합니다
AX를 적용할 업무를 골랐다면 실제로 사용하는 문서부터 확인합니다.
고객지원 답변을 돕는 AI라면 최신 정책이 어디에 있는지, 서로 다른 안내가 섞여 있지는 않은지, 누가 자료를 고치는지 알아야 합니다. 오래된 문서를 정리하지 않은 채 연결하면 담당자가 결과를 다시 확인하는 부담이 커질 수 있습니다.
AI가 만든 결과를 누가 확인하고 어디까지 사용할지도 정해야 합니다. 출처가 없는 답변은 어떻게 처리할지, 판단하기 어려운 문의는 누구에게 넘길지, 잘못된 안내를 발견하면 누가 수정할지를 실제 업무 순서에 맞춰 적어보세요. 개발 담당자와 현업 담당자가 같은 사례를 놓고 이야기하면 빠진 조건을 찾기 좋습니다.
미국 국립표준기술연구소(NIST)의 AI 위험관리 프레임워크도 역할과 책임을 명확히 하고, 운영 중 점검을 계획하도록 제시합니다. 여기서 거버넌스는 도입 전에 한 번 끝내는 절차가 아니라 AI를 사용하는 동안 이어지는 관리 활동입니다. 우리 회사에서는 이를 자료 관리, 결과 검토, 문제 대응을 누가 맡을지 정하는 일부터 구체화할 수 있습니다.
AX는 작게 시험하되, 계속할 기준은 먼저 정합니다.
PoC는 본격적인 구축 전에 작은 범위에서 가능성을 확인하는 테스트입니다.
시작할 때부터 기존 방식과 무엇을 비교할지 정해두면, 시연이 잘됐다는 인상을 넘어 실제 업무에 쓸 수 있는지 판단하기 쉬워집니다.
고객지원 사례라면 자료 검색부터 최종 답변까지 걸린 시간, 수정 없이 활용한 초안의 비율, 잘못된 정책을 안내한 사례를 함께 기록할 수 있습니다. 테스트에는 간단한 문의와 예외 처리가 필요한 문의를 섞고, 기존 방식과 AI를 사용하는 방식에 비슷한 난도의 업무를 배정해야 비교가 의미를 갖습니다.
초안 작성은 빨라졌지만 검토 시간이 늘었다면 전체 시간은 줄지 않을 수 있습니다. 이때는 잘못된 결과가 자료 문제 때문인지, 검색이 빗나갔는지, 요청한 작업이 너무 넓었는지 살펴봐야 합니다. 확인한 원인에 따라 자료를 보완하거나 범위를 줄여 다시 시험하고, 계속 진행할지 판단합니다. 목표 수준과 허용할 수 없는 오류는 업무 담당자와 테스트 전에 합의해두는 편이 좋습니다.
검증한 업무를 현업에 붙이고, 그다음에 넓힙니다
테스트에서 쓸 만한 결과가 나왔다면 직원이 평소 일하는 화면에서 어떻게 사용할지 살펴봅니다. 매번 다른 창으로 이동해 내용을 복사해야 한다면 그 과정도 소요 시간에 포함해야 합니다. 기존 시스템과 연결할 범위, 사용자 권한, 사용량에 따른 운영비를 함께 확인해야 실제 도입 계획을 세울 수 있습니다.
교육에서는 버튼 사용법과 함께 결과를 믿어도 되는 조건, 다시 확인해야 하는 경우, 오류를 알리는 방법을 다룹니다. 운영을 시작한 뒤에는 직원이 어떤 기능을 쓰고 어디에서 다시 수작업으로 돌아가는지 살펴보세요. 다음 부서로 확대할 때도 자료와 업무가 얼마나 비슷한지 확인해야 같은 기능을 그대로 쓸 수 있을지 판단할 수 있습니다.
AX 전략을 세운 팀이 실제 구현까지 이어가야 합니다.
이 과정에서 전략을 세운 팀과 시스템을 만드는 팀이 다르면, 처음 정한 업무 범위와 우선순위를 다시 설명해야 할 수 있습니다. 테스트에서 발견한 예외나 현업 담당자의 요구가 개발 과정에 제대로 전달되는지도 챙겨야 합니다. 그래서 AX 파트너를 검토할 때는 진단 이후 누가 개발하고 운영을 개선하는지까지 확인하는 것이 좋습니다.
똑똑한개발자는 업무 분석과 AX 전략 수립부터 PoC, 시스템 개발, 운영·개선까지 하나의 팀에서 진행합니다. 어떤 업무를 왜 먼저 선택했는지, 테스트에서 무엇을 확인했는지를 실제 시스템을 만드는 과정까지 이어가는 방식입니다. 기존 시스템과 연결할 때도 API 연동이 가능한지, 화면 조작을 자동화하는 RPA가 필요한지 등 현재 환경에 맞는 방법을 함께 검토합니다.
시작부터 회사 전체의 시스템을 바꿀 필요는 없습니다.
똑똑한개발자는 데이터를 활용하기 쉽고 반복적으로 시간이 드는 업무를 골라 작은 파일럿으로 검증하는 방식을 제안합니다. 검증 결과에 따라 적용 범위를 넓히고, 필요하다면 기존 시스템을 유지하면서 AI 기능을 별도로 연결할 수도 있습니다.
기업 AX 전략을 준비하고 있다면, 아래 링크로 상담 신청 부탁드립니다 :)
AX 도입, 프로젝트 협업 등 궁금한 점을 남겨주세요.
https://www.toktokhan.dev/contact?utm_source=landing&utm_medium=ax-strategy&utm_campaign=ax-consulting-keyword&utm_term=기업ax전략