AX PoC는 성공했는데 현업에서 쓰지 않는 이유: 업무·데이터·예외 처리부터 점검하기

PoC에서 무엇을 성공했다고 판단했는가

PoC는 정한 가설을 제한된 조건에서 확인하는 과정입니다. 예를 들어 준비된 상품 문서에서 답을 찾는 실험이 성공했다면, 그 결과는 해당 문서와 질문에서 답변 생성이 가능했다는 근거가 됩니다. 모든 영업 문의를 처리할 수 있다거나, 담당자 없이 고객에게 안내해도 된다는 근거까지 자동으로 생기지는 않습니다.

NIST의 생성형 AI 프로파일은 좁은 범위의 비체계적 평가나 일화적 평가에서 모델의 성능과 능력을 일반화하지 않도록 권고합니다. 배포와 유사한 조건에서 평가하고 적용 범위의 한계와 생성된 근거·인용을 확인하는 접근입니다.^[1]

다음은 실제 고객 사례가 아닌 가상의 B2B 유통회사 사례입니다. 이 회사는 상품 설명서를 연결한 AI로 거래처 문의에 답하는 PoC를 진행했습니다. 시연에서는 제품 규격과 배송 안내를 빠르게 찾아냈습니다. 그러나 현업 담당자는 여전히 기존 시스템을 열어 답변을 작성합니다.

문의에는 거래처별 계약 단가, 오늘 변경된 재고, 부분 출고와 취소 가능 여부가 섞여 있습니다. 이 정보는 상품 설명서에 없고, 고객이 보낸 주문번호가 다른 거래처 주문과 혼동될 수도 있습니다. AI의 문장을 쓰려면 담당자가 처음부터 확인해야 하므로, 작성 시간은 줄었어도 전체 처리 시간은 줄지 않는 구조입니다.

이 상황에서 다음 실험은 모델 교체만으로 정하기 어렵습니다. 어떤 업무 조건을 빠뜨렸는지 먼저 나눠야 합니다.

표의 오른쪽이 비어 있다면, 모델 성능을 개선하면서도 업무 연결은 별도 과제로 남겨야 합니다. 무엇을 아직 모르는지 표시해야 다음 투자와 검증 범위를 정할 수 있습니다.

첫 AX 업무는 빈도와 오류 비용을 함께 보고 고릅니다

이 글에서 AX는 AI를 포함한 기술로 업무의 수행 방식과 책임 구조를 바꾸는 활동을 뜻합니다. 첫 과제는 회사 전체를 설명하는 큰 명칭보다, 누가 어떤 입력으로 무엇을 완료하는지 한 문장으로 적을 수 있는 업무가 적합합니다.

Google의 People + AI Guidebook은 사용자 필요와 AI의 강점이 만나는 문제를 찾고, 자동화와 사람의 능력을 보조하는 방식을 구분하도록 안내합니다. 오류의 비용이 작은 성능 개선의 이익보다 큰지 살펴보라는 지침도 포함합니다.^[2]

아래는 후보 업무를 비교하기 위한 설계 예시입니다. 점수를 합산해 모든 위험을 상쇄하는 용도로 쓰지 않습니다. 데이터 사용이 허용되지 않거나 오류의 영향을 통제할 수 없는 후보는 처리량이 많아도 범위를 줄이거나 보류합니다.

가상 유통회사라면 첫 범위를 “공개 상품 문서에서 규격 근거를 찾아 상담 초안을 작성한다”로 정할 수 있습니다. 거래처별 가격 확정과 주문 변경은 기존 담당자가 처리합니다. 어떤 고객의 주문인지 확인되지 않으면 초안을 만들기 전에 식별 확인을 요청합니다.

AI가 필요하지 않은 부분도 함께 정리합니다. 정해진 환율로 값을 계산하거나 필수 필드 누락을 확인하는 작업은 명시된 규칙으로 처리할 수 있습니다. 문장 속 요청 의도를 해석하거나 여러 문서에서 설명을 찾아야 하는 부분에 AI를 적용하고 최종 금액 계산과 권한 검사는 별도의 규칙과 시스템으로 확인하는 구성을 검토합니다.

Anthropic은 에이전트 설계에서 가능한 한 단순한 방식부터 시작하고 추가 복잡성이 필요한지 판단하라고 설명합니다. 정해진 작업에는 미리 정의한 흐름이 예측 가능성을 주며, 자율적인 에이전트는 작업 수행 능력과 비용·지연 사이의 교환을 고려해야 합니다.^[3]

프롬프트를 쓰기 전에 업무의 완료 조건을 적습니다

“문의에 정확히 답한다”는 요구만으로는 개발팀과 운영팀이 같은 결과를 기대하기 어렵습니다. 담당자는 고객이 다음 행동을 할 수 있어야 완료라고 생각하지만 개발팀은 답변 문장이 생성되면 정상 처리로 기록할 수도 있습니다.

파일럿 착수 전에 다음 항목을 한 장에 적습니다. 아래 항목은 실무 적용을 위한 제안이며 특정 표준의 필수 서식은 아닙니다.

• 입력: 인증된 거래처의 문의 본문, 확인된 제품 식별자, 접근이 허용된 문서.
• 산출물: 답변 초안, 근거 문서와 위치, 확인되지 않은 조건, 필요한 후속 질문.
• 완료: 담당자가 근거와 대상 거래처를 확인하고 승인한 답변이 발송되어 원래 문의에 기록된 상태.
• 제외: 신규 계약 단가 확정, 환불 승인, 주문 수량 변경, 다른 거래처 자료 조회.
• 보류: 문서 충돌, 최신 상태 확인 실패, 제품 식별 불가, 권한 확인 실패.
• 책임: 업무 규칙 소유자, 시스템 운영자, 검토 담당자, 예외를 최종 결정할 책임자.

이렇게 정의하면 누락된 화면과 시스템도 드러납니다. 담당자가 초안을 보면서 근거를 다시 검색해야 한다면 근거 표시가 필요합니다. 답변이 잘못됐을 때 어느 문서에서 가져왔는지 알 수 없다면 문서 버전과 실행 기록이 필요합니다. 완료된 문의가 다시 대기열에 들어온다면 모델 외부의 상태 관리도 확인해야 합니다.

NIST AI RMF는 거버넌스, 맥락 파악, 측정, 관리를 연결해 AI 위험을 다룹니다. 이 글의 업무 정의표는 그 관점을 현업 프로젝트에 적용한 예시이며 표를 작성했다는 사실만으로 프레임워크 준수나 안전성을 보증하지는 않습니다.^[4]

데이터가 많다는 것과 업무에 쓸 수 있다는 것은 다릅니다

현업 연결에서 필요한 것은 자료의 양을 늘리는 것만이 아닙니다. 어떤 사실의 원천이 어디인지, 그 사실이 언제까지 유효한지, 누구에게 보여도 되는지를 설명할 수 있어야 합니다.

상품 규격은 제품 문서가 원천일 수 있지만 현재 재고는 재고 시스템, 거래처 단가는 계약 관리 시스템이 원천일 수 있습니다. 한 문서에 모든 정보를 복사해 넣으면 조회는 쉬워져도 변경 시점과 책임이 흐려집니다. 먼저 필요한 사실을 나누고, 사실별 원천과 확인 시점을 연결합니다.

가상 유통회사의 “이번 주 안에 받을 수 있나요?”라는 질문에는 최소한 제품, 수량, 배송지, 재고 확인 시각, 출고 마감 조건이 필요합니다. 정보가 부족하면 일반 배송 규정을 설명하고 누락 항목을 요청할 수도 있습니다. 확인되지 않은 도착일을 확정해서 답하는 방식은 완료 조건에서 제외해야 합니다.

문서 충돌도 정책으로 다룹니다. 상품 안내서와 공지가 서로 다르면 최신 파일명만 보고 자동 선택할지, 승인된 문서 상태를 확인할지, 담당자에게 넘길지를 정해야 합니다. 권한이 없는 자료는 검색 결과뿐 아니라 요약과 답변에서도 노출되지 않도록 검증 범위를 잡습니다. 구체적인 접근통제 구현은 사용하는 시스템과 데이터 정책에 맞춰 확인해야 합니다.

평가용 자료도 따로 준비합니다. 프롬프트를 고치면서 계속 확인한 예제만으로 최종 판단하면, 익숙한 입력에 맞춰진 결과를 전체 성능으로 오해하기 쉽습니다. 개발용 예제와 최종 평가용 예제를 분리하고 자주 발생하는 정상 업무와 드물지만 손실이 큰 예외를 나눠 봅니다. 예외를 많이 넣은 평가 묶음의 평균을 실제 운영 평균으로 그대로 보고하지 않도록 구성 비율도 남깁니다.

효과는 답변 생성 시간보다 업무 전체의 부담으로 비교합니다

AX 도입 전의 기준선이 없으면 무엇이 개선됐는지 설명하기 어렵습니다. 시작 시점의 처리량, 담당자가 실제로 일한 시간, 대기 시간, 재처리 비율을 같은 정의로 기록해야 합니다. 바쁜 주간과 한가한 주간의 총처리 시간만 비교하면 수요 차이를 개선 효과로 잘못 읽을 수 있습니다.

측정은 적어도 세 층으로 나눠 봅니다.

분모를 고정하는 것도 중요합니다. 전체 문의 1,000건 중 쉬운 문의 200건만 AI로 처리한 뒤 그 범위에서 얻은 완료율을 전체 성과처럼 보고하면 범위가 사라집니다. 전체 문의 수, 적용 대상 수, 실제 사용 수, 승인 완료 수, 보류·실패 수를 나란히 기록해야 합니다. 사람에게 넘긴 건도 결과에서 없애지 않습니다.

가능하다면 비슷한 난도의 업무를 기존 방식과 AI 지원 방식으로 나눠 비교합니다. 무작위 배정이 어렵다면 문의 유형·담당자의 경험·시기 차이를 함께 남기고 인과 효과를 단정하지 않습니다. 직원이 새 도구를 익히는 초기 구간은 별도로 표시하되, 교육과 학습에 실제로 들어간 비용은 도입비에서 제외하지 않습니다.

Google Cloud의 운영 가이드는 생성형 AI 애플리케이션을 배포한 뒤에도 실제 출력과 사용자 피드백, 평가 기준을 통해 성능을 계속 확인하는 접근을 설명합니다. 입력 분포가 평가 때와 달라질 수 있다는 점도 다룹니다. 파일럿 종료일의 결과를 유지 보수 없이 영구히 유효한 성능으로 취급하지 않는 이유입니다.^[5]

가상 계산: 120시간을 확보했다면 얼마를 절약한 것일까

다음 수치는 계산 방법을 설명하기 위한 가정입니다. 실제 IXC 고객 성과나 일반적인 AX 절감률이 아닙니다. 모든 문의의 난도가 같고 기존 평균 시간이 동일하다는 단순화도 포함합니다.

시간당 내부 원가를 3만 원으로 놓으면 확보된 여력의 환산 가치는 월 360만 원입니다. 여기에 인건비와 중복되지 않는 모델·도구·인프라 사용료를 월 70만 원으로 가정하면 월간 순효익의 추정치는 290만 원입니다. 초기 구축·교육·평가 비용이 870만 원이라면 단순 계산상 3개월에 해당합니다.

그러나 이 값은 확보한 시간을 실제 가치로 전환할 수 있다는 가정 아래의 계산입니다. 직원의 월급이 그대로이고 외주비·초과근무비도 줄지 않았다면 360만 원이 현금으로 절약된 것은 아닙니다. 실제 현금 흐름에서는 월 사용료 70만 원이 추가될 수 있습니다. 확보한 시간으로 밀린 문의를 처리했는지, 응답 지연을 줄였는지, 추가 매출에 기여했는지 따로 확인해야 합니다.

또한 계산의 “5분”에는 적용 대상에서 발생한 검토·수정과 실패 후 수동 처리의 평균 부담이 반영돼야 합니다. 성공한 건만 골라 5분을 구하면 절감량이 과장됩니다. 추가 운영 20시간과 건별 처리 시간에 같은 작업을 두 번 더하지 않도록 기록 기준을 맞춥니다. 평균뿐 아니라 유난히 오래 걸리는 문의가 어떤 유형인지 확인해야 담당자의 실제 불편도 설명할 수도 있습니다.

사람이 검토한다는 말은 화면과 권한으로 구체화해야 합니다

“마지막에 사람이 확인하니까 괜찮다”는 설계는 검토자가 무엇을 확인할 수 있는지까지 살펴야 성립합니다. 근거 문서와 현재 상태가 보이지 않고 답변만 승인하는 화면이라면 검토 업무를 수행하기 어렵습니다. 잘못된 결과를 발견해도 발송을 멈출 권한이 없거나 수정 내용이 사라진다면 형식적인 승인으로 남습니다.

Microsoft의 Responsible AI Standard v2는 운영·감독 책임자를 식별하고 해당 담당자가 사용 목적과 동작을 이해하며 개입·중단할 수 있도록 필요한 시스템 요소를 정의합니다. 감독 기능 자체를 현실적인 사용 조건에서 평가하는 요구도 포함합니다. 이는 Microsoft의 표준이며 모든 기업에 적용되는 법적 의무를 설명하는 것은 아닙니다.^[6]

우리 업무에 적용할 때에는 검토자가 원문과 답변을 함께 보고, 수치·대상·약속을 확인하며 수정·반려·인계를 선택할 수 있는지 시험합니다. 승인 대기열이 밀릴 때 어떤 업무부터 처리할지, 담당자가 부재하면 누가 이어받을지도 정합니다.

직원의 사용 여부를 로그인 횟수로만 평가하지 않는 편이 좋습니다. 사용하지 않은 업무를 살펴보고 근거를 찾는 데 시간이 더 걸렸는지, 권한 때문에 필요한 자료를 못 봤는지, 원래 쓰던 화면으로 결과를 옮겨야 했는지 구분합니다. 현업 담당자의 피드백은 “좋아요” 표시뿐 아니라 어떤 조건 때문에 초안을 버렸는지 기록할 수 있어야 개선 작업으로 이어집니다.

예외는 보류 이유와 다음 담당자가 함께 있어야 합니다

운영에서는 답변을 만들지 못한 문의도 계속 진행되어야 합니다. Google의 오류 대응 가이드는 오류의 원인을 구분하고 사용자가 실패 이후에 할 수 있는 다음 행동을 제공하도록 안내합니다.^[7]

가상 유통회사에 적용한다면 다음처럼 정할 수도 있습니다. 자동화의 일부가 실패해도 어디까지 처리됐는지 기록하고 같은 업무를 중복 실행하지 않도록 확인합니다.

복귀 절차는 문서만 만들어 두지 말고 파일럿에서 한 번 실행해 봅니다. AI 경로를 중지했을 때 대기 중 문의가 보존되는지, 담당자가 기존 화면에서 이어받을 수 있는지, 이미 수행된 행동을 중복하지 않는지 확인합니다. 원인 수정 후에는 문제가 발생한 입력을 회귀 검증에 넣고, 변경한 범위에 대한 재검증 결과를 남깁니다.

30일 파일럿은 완료 약속보다 판단 가능한 근거를 만드는 일정입니다

다음은 범위가 작은 상담 초안 업무를 가정한 일정입니다. 데이터 연결, 권한 승인, 업무량에 따라 더 길어질 수 있으며, 30일이 지났다는 이유로 운영 전환을 결정하지 않습니다.

파일럿 평가는 평균 점수 하나로 끝내지 않습니다. 아래는 숫자 목표를 확정하기 전 사용할 판정 구조의 예시입니다. 처리 시간 목표와 허용 오류 범위는 실제 기준선과 업무 위험에 맞춰 정합니다.

• 확대 검토: 정한 적용 대상에서 검토·재처리·운영을 포함한 부담이 개선되고 근거 확인과 권한 통제가 작동하며 예외를 담당자가 이어받을 수 있다. 검증된 범위와 새로 확대할 범위를 구분한다.
• 범위 조정: 특정 문의에서만 효과가 확인되거나 검토 부담이 큰 구간이 있다. 효과가 확인된 범위를 유지하고 나머지는 기존 절차로 보낸다.
• 보류: 결과를 확인할 근거가 없거나, 필수 데이터가 준비되지 않았거나, 담당자가 예외를 처리할 수 없다. 입력·업무·권한 조건을 보완한 뒤 다시 평가한다.
• 즉시 중지·조사: 고객정보의 잘못된 노출, 승인 없는 외부 실행, 같은 주문의 중복 처리 등 사전에 지정한 중대 사건이 발견된다. 영향을 줄이는 조치를 하고 원인과 범위를 확인한다.

파일럿에서 중대 사고가 관찰되지 않았다는 사실은 사고 가능성이 없다는 보증이 아닙니다. 적은 건수에서 드러나지 않은 위험은 남을 수 있습니다. 그래서 제한된 노출 범위, 탐지 방법, 중지 권한과 재검토일을 함께 남깁니다.

다음 회의에서 결정해야 할 다섯 가지

PoC 이후의 회의에서는 “어떤 모델을 추가할까”와 함께 다음 질문에 답해야 합니다.

1. 다음 달부터 실제로 바꿀 업무 하나는 무엇이며 누가 완료를 판단하는가?
2. 필요한 사실의 원천과 접근권한을 누가 책임지는가?
3. 담당자의 검토·수정·예외 처리까지 포함한 효과를 무엇으로 비교하는가?
4. 실패했을 때 어떤 조건으로 멈추고 누가 기존 절차를 이어받는가?
5. 확대를 승인할 책임자와 다음 검토일은 언제인가?

요구사항과 검증 결과를 기록하는 체계는 이 판단을 반복 가능하게 만드는 데 도움이 됩니다. IXC의 Qoretix는 공개 소개에서 실행 결과·실패 근거·미검증 범위·재검증 기록을 확인하는 QA 흐름을 안내합니다. AX 적용 시에는 이 기록을 어떤 사용자 경로와 연결할지 검토할 수도 있습니다. 다만 업무별 AI 답변 품질 기준과 평가 데이터, 사람이 수용할 위험은 별도로 정의해야 합니다. 공개 소개만으로 전용 LLM 평가나 모든 AI 위험의 자동 검증이 제공된다고 가정해서는 안 됩니다.^[8]

AX 파일럿의 업무 범위와 검증 기준을 정리해야 한다면 IXC에 프로젝트를 문의해 주세요. 현재 절차와 PoC 결과를 바탕으로 데이터·연동·QA에서 먼저 확인할 항목을 논의할 수도 있습니다.