기업에서 AI 파일럿을 진행할 때는 모델의 응답 품질과 처리 속도가 먼저 눈에 들어옵니다. 정제한 샘플 데이터로 원하는 결과가 나오면 실제 업무에도 곧 적용할 수 있을 것처럼 보이는데요. 실제 운영으로 옮기려면 모델 성능뿐 아니라 데이터가 오가는 경로와 호출 권한, 결과를 기록할 시스템, 오류가 발생했을 때의 처리 방법까지 확인해야 합니다.
보안팀은 어떤 데이터가 외부 모델에 전달되는지 확인해야 합니다. 업무 담당자는 결과가 어느 시스템으로 돌아오는지, 데이터·플랫폼팀은 누가 모델을 호출할 수 있고 어떤 로그를 남길지 정해야 하는데요. 장애가 발생했을 때 업무를 멈추거나 사람이 검토하도록 전환할 조건도 필요합니다. 파일럿에서 확인한 결과를 실제 업무에서 반복하려면 이 항목들이 먼저 정해져 있어야 합니다.
미국 국립표준기술연구소(National Institute of Standards and Technology, NIST)의 AI 위험관리 프레임워크(AI Risk Management Framework, AI RMF)는 실제 운영 환경과 비슷한 조건에서 AI 시스템을 시험하도록 권고하는데요. 시험에서 확인한 성능과 한계를 문서로 남기고, 운영을 시작한 뒤에도 시스템이 의도한 대로 작동하는지 계속 살펴봐야 합니다.
결국 AI 파일럿을 실제 운영 단계로 전환할 때는 모델 점수만 다시 측정해서는 안 됩니다. 업무 요청 한 건이 시작돼 승인된 모델을 거쳐 결과가 원래 시스템에 기록될 때까지, 각 단계의 데이터와 권한, 실행 기록과 실패 처리를 순서대로 시험해야 합니다.
핵심 요약
- 파일럿에서 확인한 모델 성능만으로 실제 업무 적용 여부를 결정해서는 안 됩니다.
- 데이터를 읽을 시스템과 외부로 보낼 필드·파일, 결과가 돌아갈 시스템을 먼저 정합니다.
- 사용할 모델과 호출 권한, 처리 지역, 로그와 보존 조건을 업무별로 승인합니다.
- 실제 운영과 비슷한 데이터·권한·연동 조건에서 요청부터 결과 기록까지 시험합니다.
- 모델·정책 변경과 오류, 사람의 수정·거부 기록을 확인하고 중단·복구 기준을 미리 정합니다.
파일럿 성과만으로 현업 적용을 결정할 수는 없습니다
파일럿에서는 제한된 데이터와 소수의 사용자, 정해진 질문으로 모델이 업무에 도움이 되는지 확인하는데요. 이 단계에서는 답변 정확도나 처리 시간처럼 모델 자체의 결과를 비교하기가 쉽습니다.
실제 운영 단계에서는 모델에 데이터를 보내기 전과 응답을 받은 뒤의 처리까지 확인해야 합니다. 실제 데이터에는 개인정보뿐 아니라 고객 번호, 계약 코드, 장비 식별자, 내부 분류 체계처럼 조직 안에서만 의미가 통하는 값도 섞여 있는데요. 같은 모델을 사용하더라도 호출하는 사용자와 전달하는 데이터, 결과를 기록하는 시스템이 달라지면 필요한 권한과 보호 정책도 달라집니다.
파일럿에서 사용한 정제 데이터만으로는 실제 사용자 권한이나 결과 기록 문제를 확인하기 어렵습니다. 운영 전환을 검토할 때는 모델 평가와 별도로 데이터 경로, 접근 권한, 시스템 연동, 결과 기록과 장애 대응을 함께 살펴봐야 합니다.
데이터가 오가는 경로를 먼저 확인합니다
먼저 모델을 고르기보다 업무 요청 한 건이 지나가는 경로부터 정리해야 합니다. 데이터가 어느 시스템에서 시작되는지, 어떤 필드를 읽는지, 모델에는 무엇을 보내고 결과는 어디에 기록하는지 순서대로 표시합니다.
계약 검토 업무를 예로 들어보겠습니다. 문서 저장소에서 계약서를 읽고 승인된 모델이 조항을 분석한 뒤, 결과를 검토 화면이나 업무 티켓에 남기는 흐름인데요. 계약서 파일만 확인해서는 충분하지 않습니다. 고객 코드, 담당 조직, 문서 버전, 참조 조항처럼 분석 결과를 원래 계약과 연결하는 정보도 함께 살펴봐야 합니다.
요청 경로를 그려보면 실제 운영 전에 무엇을 정해야 하는지 확인할 수 있습니다. 샘플 파일을 올리고 결과를 확인하는 데서 끝났던 파일럿과 달리 실제 운영에는 다음 항목이 필요합니다.
- 데이터를 읽을 시스템과 필드
- 외부 또는 내부 모델에 전달할 데이터 범위
- 원본값과 내부 매핑을 보관할 위치
- 결과를 기록할 시스템과 권한
- 요청부터 결과 기록까지 남길 실행 이력
요청의 시작점과 도착점이 없으면 “데이터를 보호했나요?”처럼 범위가 불분명한 질문만 남게 되는데요. 데이터를 읽을 시스템과 결과가 돌아갈 시스템을 정해야 보호할 값과 필요한 권한, 남겨야 할 로그를 구체적으로 결정할 수 있습니다.
모델과 권한은 업무마다 달라집니다
같은 조직에서도 모든 업무에 같은 모델을 적용할 필요는 없습니다. 일반 문서 요약에는 승인된 외부 모델을 사용할 수 있지만, 외부 전송이 허용되지 않는 데이터라면 내부 모델이 필요할 수 있는데요. 업무마다 사용할 모델과 엔드포인트, 처리 지역, 전달할 데이터 유형을 따로 정해야 합니다.
승인 기록에는 최소한 업무 목적, 데이터 유형, 호출 주체, 사용할 모델, 처리 지역, 로그와 보존 조건을 남깁니다. 여기서 호출 주체는 모델을 요청한 사용자나 시스템을 말하는데요. 자동화된 업무라면 사람이 직접 버튼을 누르지 않더라도 어느 시스템이 어떤 권한으로 모델을 호출했는지 추적할 수 있어야 합니다.
NIST의 생성형 AI 프로필(Generative Artificial Intelligence Profile)은 외부 AI 서비스를 도입할 때 공급자와 데이터 입력, 계약, 기술 통제를 구분해 검토하도록 권고합니다. 실제 승인 과정에서는 요청과 응답을 얼마나 오래 보관하는지, 입력 데이터를 모델 학습에 사용하는지, 운영자나 지원 인력이 어떤 조건에서 접근할 수 있는지 확인해야 합니다. 계약서에 적힌 조건과 실제 계정·엔드포인트 설정이 일치하는지도 검증해야 합니다.
결과가 돌아갈 시스템도 함께 정해야 하는데요. 모델 응답이 임시 화면에만 표시되는지, 원래 업무 티켓에 기록되는지, 사람이 검토한 뒤 반영되는지에 따라 권한과 오류 처리 방식이 달라집니다. 승인 기록에는 모델 호출뿐 아니라 결과를 기록할 시스템과 사람의 검토 단계까지 포함합니다.
시험 조건은 실제 업무와 같아야 합니다
NIST AI RMF는 AI 시스템을 실제 운영 환경과 비슷한 조건에서 평가하고, 시험하지 않은 데이터나 사용자 환경에는 결과를 그대로 일반화하지 않도록 한계를 문서로 남길 것을 권고합니다. 프로덕션 전환을 검토할 때도 이 원칙을 적용할 수 있습니다.
시험을 시작하기 전에는 통과 기준과 최종 승인자를 정해야 합니다. 업무에 필요한 답변 품질과 허용할 오류, 사람이 반드시 검토할 상황을 먼저 합의하고, 시험 결과를 바탕으로 누가 운영 전환 여부를 결정할지도 명확히 해 둡니다.
정제한 샘플 몇 건을 다시 시험하는 것만으로는 충분하지 않습니다. 실제 사용자가 다루는 문서 형식과 길이뿐 아니라 필드 누락, 권한이 없는 요청, 지원하지 않는 입력, 제한 시간 안에 응답이 오지 않는 상황도 포함해야 하는데요. 문제가 생겼을 때 모델 호출이 중단되는지, 원래 업무 기록은 갱신되지 않는지, 오류 원인이 로그에 남는지도 확인해야 합니다.
업무마다 세부 검증 항목은 다르지만 아래 질문을 공통 기준으로 삼을 수 있습니다.
- 실제 사용자가 다루는 대표 입력으로 시험했나요?
- 권한이 없는 사용자나 시스템의 요청은 차단되나요?
- 허용되지 않은 값이 발견되면 요청을 중단하거나 검토 단계로 넘기나요?
- 모델 호출이 실패했을 때 원래 업무 기록이 잘못 갱신되지 않나요?
- 결과가 같은 업무 건에 중복 기록되지 않나요?
- 적용한 정책과 모델 경로를 실행 이력에서 확인할 수 있나요?
이 질문에 시험 결과와 실행 기록으로 답할 수 있어야 프로덕션 전환 여부를 판단할 수 있습니다. 단순히 “보안 검토를 마쳤다”고 표시하기보다 어떤 조건을 시험했고 어떤 문제가 남았는지 보여주는 편이 운영팀과 승인팀에 더 유용한 근거가 됩니다.
운영 중에도 변화와 오류를 살펴봐야 합니다
프로덕션 전환은 시스템을 배포하는 순간 끝나지 않습니다. 입력 데이터와 사용자 행동, 모델 버전, 업무 정책은 시간이 지나면서 달라지는데요. 파일럿에서 정한 기준이 계속 유효한지 운영 중에도 확인해야 합니다.
NIST AI RMF는 운영 중인 AI 시스템을 계속 모니터링하고, 사용자 의견과 사고 대응, 복구와 변경 관리까지 계획하도록 권고하는데요. 기업 AI 업무에서는 모델 품질 지표만 볼 것이 아니라 어떤 데이터와 정책이 적용됐는지, 실패가 어디에서 발생했는지, 사람이 어떤 결과를 수정하거나 거부했는지도 함께 살펴봐야 합니다.
문제가 생겼을 때 바로 대응하려면 운영 전에 다음 기준을 정해 둬야 합니다.
- 자동 실행을 멈추고 사람 검토로 전환할 조건
- 모델 또는 정책 버전이 바뀔 때 다시 시험할 범위
- 입력 오류, 권한 오류, 모델 오류를 구분하는 기록 방식
- 잘못 반영된 결과를 찾고 복구하는 절차
- 실행 기록과 업무 결과의 보존 기간
모니터링 결과는 AI를 계속 실행할지 판단하는 근거인데요. 이 기록을 보고 자동화를 유지할지, 사람 검토로 전환할지, 운영을 멈출지 결정합니다.
한 가지 업무부터 전환 조건을 점검해 보세요
처음부터 여러 파일럿을 한꺼번에 전환할 필요는 없는데요. 실제로 사용 중인 업무 한 건을 골라 데이터의 시작점과 결과가 돌아갈 시스템부터 정합니다. 그런 다음 사용할 모델 경로와 권한, 실패 처리, 실행 기록을 하나씩 연결합니다.
업무 한 건만 골라 시험하면 모델 답변과 실제 운영 조건을 따로 확인할 수 있습니다. 답변은 좋지만 데이터 경로가 정해지지 않았는지, 기술 연동은 가능하지만 호출 권한이나 중단 기준이 빠졌는지 구체적으로 확인할 수 있습니다.
앞에서 살펴본 질문에 시험 결과와 실행 기록으로 답하면 빠진 설정과 실패한 항목이 드러납니다. 운영팀과 승인 담당자는 이 기록을 보고 데이터 경로, 권한, 오류 처리 가운데 무엇을 보완해야 하는지 판단할 수 있습니다.
LLM Capsule이 데이터를 모델에 보내고 결과를 연결하는 방식
LLM Capsule은 운영 시스템에서 읽은 민감한 값을 고객 환경 안에서 바꾼 뒤 승인된 AI 모델로 보냅니다. 원본값과 바뀐 값을 연결하는 내부 매핑은 고객 환경 안에 두는데요. 민감한 값은 바꾸되 업무에 필요한 데이터 사이의 관계는 유지해서 모델에 전달합니다.
모델 응답이 돌아오면 고객 환경 안에서 재구성(Reconstruction)을 수행해 바뀐 값을 원래 업무값과 다시 연결합니다. 재구성된 결과는 티켓이나 보고서, 업무 기록에 반영할 수 있는데요. LLM Capsule 아키텍처는 운영 시스템에서 읽은 값이 승인된 모델을 거쳐 돌아온 뒤 원래 업무값과 다시 연결되는 순서를 설명합니다.
민감한 값을 바꾸고 모델 응답을 원래 업무값과 다시 연결하는 것과, 사용할 모델을 승인하는 것은 별개의 문제입니다. 조직은 업무와 데이터에 맞춰 모델과 처리 지역, 전달할 데이터, 보존 조건을 별도로 승인해야 하는데요. 승인된 경로로 실행한 뒤에는 어떤 정책과 모델이 적용됐는지 실행 기록에서 확인할 수 있습니다.
