AI 전환 파트너를 고를 때 기능 목록보다 먼저 볼 것

AI 전환 파트너의 제안서는 대개 기능과 기술 설명으로 시작합니다. 하지만 실제 도입의 성패는 기능 수보다 업무의 책임 구조를 얼마나 정확히 읽고, 현장에 남길 운영 기준까지 설계하는지에 달려 있습니다. 특히 승인과 이력이 중요한 업무에서는 “무엇을 할 수 있는가”보다 “어떤 조건에서 쓰고 누가 확인하는가”가 더 중요한 비교 기준입니다.

제안서에서 어떤 근거를 요구해야 할까요?

가령 ‘문서 검토를 AI로 개선한다’는 제안이라면, 정확도 수치만 볼 일은 아닙니다. 어떤 문서 집합을 참조하는지, 최신 기준은 누가 관리하는지, 누락 후보를 누가 원문과 대조하는지까지 답해야 합니다. 이 질문이 빠진 데모는 실제 업무에서 다시 설계해야 할 가능성이 큽니다.

짧은 검증이 운영 가능성까지 보여줄까요?

짧은 검증은 가치와 작동 가능성을 확인하는 데 유용합니다. 다만 테스트용 데이터와 좁은 시나리오에서 보인 결과가 곧 운영 가능성을 뜻하지는 않습니다. 검증 계획에는 데이터 접근, 검토자, 예외 발생 시 중단 방식, 결과를 본 적용안에 반영하는 방법이 포함되어야 합니다.

파트너가 특정 고객명이나 일반화하기 어려운 성과를 앞세우기보다, 적용 조건과 한계를 설명하는지도 살펴볼 만합니다. 복잡한 업무일수록 정직한 범위 설정이 확산 속도를 높입니다.

계약 전에 누구의 책임인지 문장으로 남깁니다

계약 범위에는 대상 업무, 연계 범위, 제공 데이터, 고객과 수행사의 역할, 승인 기준, 운영 인수 시점을 구체적으로 적습니다. “AI가 검토한다”가 아니라 “AI가 승인된 자료에서 누락 후보를 제시하고, 품질 담당자가 원문 대조 후 보완 요청을 확정한다”처럼 업무 문장으로 합의하는 방식이 좋습니다.

비교표의 최종 질문은 하나입니다. 이 파트너가 프로젝트 종료 후에도 고객이 기준을 설명하고 조정할 수 있는 구조를 남기는가. 그 답이 분명할수록 AI는 일회성 기능이 아니라 운영 개선의 출발점이 됩니다.

실제 업무 한 건을 함께 설계하게 해보세요

평가 단계에서 파트너에게 실제 업무 하나를 놓고 질문해 볼 수 있습니다. 예컨대 접수된 협력사 문서에서 누락 자료를 확인하는 업무라면, 어떤 문서를 입력으로 쓸지, 최신 기준이 바뀌면 어디서 갱신할지, AI가 확신하지 못할 때 누구에게 넘길지를 묻습니다. 좋은 답은 기능 시연으로 끝나지 않고 역할·예외·기록의 흐름으로 이어집니다.

특히 ‘자동화율’만을 성공 지표로 제시하는 제안은 주의할 필요가 있습니다. 보완 요청처럼 외부 관계에 영향을 주는 업무에서는 자동 처리 비율이 높아도 잘못된 요청 한 건의 비용이 더 클 수 있습니다. 검토 시간, 반려 사유, 재작업, 기준 자료의 갱신 상태처럼 업무 결과를 함께 보아야 합니다.

선정 뒤에는 수행사와 고객이 각각 소유할 기준을 구분합니다. 파트너는 설계와 구현을 지원할 수 있지만, 기준 자료의 최신성, 최종 승인, 운영 정책의 소유자는 고객 조직 안에 남아야 합니다. 이 경계가 명확해야 파트너 교체나 적용 범위 확장에도 운영이 멈추지 않습니다.

평가 일정이 촉박하다면 한 번의 종합 데모보다 짧은 설계 워크숍이 더 많은 정보를 줍니다. 파트너가 모호한 업무 요청을 어떻게 질문으로 나누는지, 기존 시스템과의 제약을 어떻게 기록하는지, 불확실한 지점에서 무엇을 검증 범위 밖으로 두는지를 볼 수 있기 때문입니다. 범위를 잘 줄이는 역량은 복잡한 AI 전환에서 기능을 많이 보여주는 것만큼 중요합니다.

같은 예외에서 후보마다 어떤 판단을 내릴까요?

평가팀은 실제 업무를 일반화한 하나의 시나리오를 준비하고, 모든 후보에게 같은 흐름을 설명해 달라고 요청하는 편이 좋습니다. 예를 들어 협력사 제출 문서에서 누락을 찾아 보완을 요청하는 일을 고릅니다. 문서가 도착하는 순간부터 검토, 보완 요청, 재제출, 완료 승인까지를 따라가게 합니다. 이때 중요한 것은 누락 후보를 많이 찾는가가 아니라, 근거가 부족할 때 무엇을 멈추고 누구에게 넘기는가입니다.

좋은 파트너는 첫 질문부터 기능을 고르지 않습니다. 기준 문서의 소유자, 기준이 바뀌는 주기, 업무의 완료 조건, 담당자 부재 시 대리 처리, 메일로 처리되는 예외를 차례로 확인합니다. 반면 곧바로 모델과 화면 목록을 제시하면 프로젝트 후반에 책임과 예외를 다시 설계할 가능성이 큽니다. 업무 이해는 산업 용어를 많이 아는지보다 모호한 요구를 검증 가능한 결정으로 바꾸는지에서 드러납니다.

가상의 워크숍 둘째 날에는 기준 문서 한 항목을 바꿔 봅니다. 이미 검토 중인 요청에 새 기준을 적용할지, 기존 기준을 유지할지, 누가 그 예외를 승인할지 묻는 방식입니다. 파트너가 영향 항목과 재검토 대상을 설명할 수 있다면 운영까지 생각하고 있는 것입니다. 자료를 다시 학습시키거나 프롬프트를 바꾸겠다는 답만으로는 진행 중인 업무의 책임을 설명하기 어렵습니다.

운영 중 오류가 발견되면 즉시 답변을 다시 생성하는 것으로 끝내면 안 됩니다. 먼저 잘못된 결과가 사용된 요청과 후속 조치를 찾아 담당자가 원문을 재검토합니다. 다음으로 오류가 기준 자료 최신성, 입력 범위, 권한, 업무 규칙, 결과 표현 중 어디에서 생겼는지 분류합니다. 수정 후에는 전체 확산 대신 제한된 표본에서 검토·반려·복구 흐름을 다시 확인합니다. 이 절차를 인수 계획에 포함할 수 있는 파트너라야 프로젝트 종료 뒤에도 고객 조직이 기준을 설명하고 조정할 수 있습니다.

총액보다 포함된 변경의 경계를 비교합니다

초기 제안은 같은 범위를 설명하는 것처럼 보여도 ‘포함된 변경’의 정의가 다를 수 있습니다. 어떤 후보는 화면과 모델 설정만 범위로 보고, 다른 후보는 기준 데이터 정리와 승인 흐름의 합의까지 포함할 수 있습니다. 총액만 비교하면 프로젝트 중 업무 규칙이 드러날 때마다 별도 변경으로 처리되거나, 반대로 불명확한 요구를 수행사가 임의로 해석할 위험이 있습니다. 평가팀은 산출물별 완료 조건, 고객이 제공해야 할 결정, 가정이 틀렸을 때 다시 협의할 절차를 나란히 놓고 봐야 합니다.

특히 데이터 준비를 ‘고객 책임’이라는 한 줄로 넘기지 않는지 확인합니다. 고객이 기준 자료의 소유자라는 사실과 파트너가 데이터 상태를 진단하고 적용 가능한 범위를 설명할 책임은 함께 존재할 수 있습니다. 어느 자료가 필요하며 결측·중복·권한 문제를 어떻게 드러낼지, 준비가 안 됐을 때 검증 범위를 어떻게 줄일지 제안해야 합니다. 데이터가 완벽하다고 가정한 일정은 빠르게 보이지만 실제 현장에서는 첫 연계부터 흔들릴 수 있습니다.

지식 이전도 교육 횟수로 평가하기 어렵습니다. 운영 담당자가 기준 문서를 바꾸고, 권한을 회수하고, 실패한 작업을 찾아 재처리하며, AI 적용 범위를 제한하는 과정을 직접 수행할 수 있어야 합니다. 파트너가 사용하는 설정과 변경 이력, 주요 설계 결정, 알려진 제한을 고객이 읽을 수 있는 형태로 남기는지 확인합니다. 특정 담당자에게만 질문해야 운영되는 구조는 인수 완료로 보기 어렵습니다.

불확실한 상황에 답하는 방식이 협업을 보여줍니다

평가 워크숍에서는 정상 시나리오보다 애매한 상황을 제시해 보는 것이 유용합니다. 기준 문서 두 개가 서로 다르거나, 승인자가 부재하거나, 이미 외부에 보낸 초안에서 오류가 발견된 상황을 줍니다. 모든 답을 즉석에서 아는지가 아니라 불확실성을 표시하고 필요한 결정자를 찾으며 안전한 임시 조치를 제안하는지를 봅니다. 근거가 부족한데도 자동화 가능 범위를 단정하는 태도는 운영 단계의 과장을 예고할 수 있습니다.

보완 요청 업무에서 파트너가 최신 기준을 잘못 연결한 상황도 가정해 봅니다. 책임 있는 대응은 모델의 답만 수정하는 것이 아닙니다. 외부 발송을 중단하고 영향을 받은 요청을 식별하며, 고객의 업무 책임자가 재검토할 수 있도록 원문과 이력을 제공합니다. 이후 수행사와 고객이 함께 기준 자료의 갱신 경로, 연계 시점, 검토 화면 중 원인을 나누고 수정합니다. 제한된 사례를 다시 통과시킨 뒤 누가 재개를 승인하는지도 합의합니다. 이런 장애 대응을 계약과 인수 계획에서 설명할 수 있는지 확인해야 합니다.

최종 선정에서는 최고 점수를 받은 데모보다 함께 남길 결정 구조를 봅니다. 고객은 업무 기준과 승인 책임을 소유하고, 파트너는 불명확한 요구를 드러내며 구현·검증 가능한 구조로 바꿔야 합니다. 양측이 변경과 실패를 같은 기록에서 논의할 수 있어야 일정 충돌도 범위와 위험의 문제로 풀 수 있습니다. 다음 과제로 확장할 때 고객이 이전 산출물을 재사용하고 새 파트너에게도 설명할 수 있다면, 그 협력은 기술 공급을 넘어 조직의 전환 능력을 남긴 것입니다.