AI 전략 · 도입 판단
AI 파일럿을 운영 가능한 실행체계로 바꾸는 세 가지 질문
AI 파일럿의 다음 단계는 모델을 하나 더 붙이는 일이 아닙니다. 누가 어떤 문제를 풀고, 어떤 결과물을 업무에서 사용하며, 누가 어떤 기준으로 반복 운영할지를 정해야 일회성 시연이 업무 변화로 이어집니다.
핵심 답 — 파일럿에서 먼저 확인해야 할 것
- 문제: AI가 누구의 어떤 판단이나 반복 업무를 바꾸는지 한 문장으로 설명할 수 있어야 합니다.
- 결과물: 데모가 아니라 다음 업무 단계로 전달할 수 있는 산출물이 있어야 합니다.
- 운영: 검토·승인·예외·변경 책임이 정해져 있어야 반복할 수 있습니다.
- 증거: 모델 성능보다 업무 흐름 전체가 재현되는지를 확인해야 합니다.
왜 AI 파일럿은 데모에서 멈추는가
“AI를 도입해보자”는 목표는 시작에는 충분하지만 운영 기준으로는 너무 넓습니다. 담당자는 보통 모델이나 도구를 먼저 고르고, 몇 개 프롬프트와 화면을 시연합니다. 그러나 실제 업무에서는 입력 데이터의 품질, 검토 책임, 승인 기준, 예외 처리와 결과 저장 위치가 함께 움직입니다. 이 조건이 정의되지 않으면 데모는 인상적이어도 다음 날 업무는 원래 방식으로 돌아갑니다.
그래서 파일럿의 질문을 “어떤 AI가 가장 좋은가?”에서 “현재 업무의 어떤 상태를 다음 상태로 바꿀 것인가?”로 바꾸는 것이 중요합니다. 이 질문이 정해지면 교육이 필요한지, 자동화가 필요한지, 별도 제품이나 내부 도구가 필요한지도 훨씬 선명해집니다.
질문 1. 누구의 어떤 결정을 바꾸는가
첫 문장은 기능이 아니라 사용자의 현재 행동으로 시작하는 편이 좋습니다. 예를 들어 “생성형 AI를 도입한다”보다 “영업 담당자가 매번 제안서 초안을 만들기 위해 과거 자료를 찾고 구조를 다시 짜는 시간을 줄인다”가 실행 범위를 더 정확하게 만듭니다.
여기서 확인할 것은 세 가지입니다. 누가 이 일을 하는지, 어떤 입력을 보고 판단하는지, 결과를 누가 다음 단계에서 사용하는지입니다. 이 세 가지가 없으면 자동화 범위도, UI도, 검증 기준도 계속 흔들립니다.
질문 2. 결과물이 실제 업무에서 사용 가능한가
AI가 만들어낸 결과가 “그럴듯하다”와 “업무에 사용 가능하다”는 다릅니다. 실제 사용 가능한 결과물은 다음 단계의 사람이 이해할 수 있고, 필요한 형식과 맥락이 있으며, 검토해야 할 부분이 분명합니다. 문서라면 버전과 출처가 필요할 수 있고, 데이터라면 스키마와 오류 기준이 필요하며, 고객에게 전달되는 결과라면 승인 책임과 금지 표현이 필요할 수 있습니다.
이 때문에 좋은 파일럿은 생성 품질만 보지 않고 input → generation → verification → handoff → archive 전체를 봅니다. 이 흐름에서 어느 한 단계가 계속 사람의 기억이나 복사·붙여넣기에 의존한다면, 그 부분이 다음 개선 후보입니다.
질문 3. 누가 어떤 기준으로 반복 운영하는가
파일럿 이후 실제 비용은 운영에서 발생합니다. 새로운 자료가 들어왔을 때 누가 업데이트하는지, 모델이나 프롬프트를 바꿨을 때 무엇을 다시 검증하는지, 민감한 데이터는 어디까지 허용되는지, 오류가 났을 때 누가 멈추는지를 정해야 합니다.
특히 AI 업무는 “자동화되었다”는 말 때문에 책임 경계가 흐려지기 쉽습니다. 그래서 자동으로 할 수 있는 일과 사람 승인이 필요한 일을 명시적으로 나누고, 실행 결과와 변경 이력을 남기는 편이 안전합니다. NIST의 AI Risk Management Framework도 AI 위험관리를 설계·개발·사용·평가의 전 과정에서 다루는 자발적 프레임워크로 제시합니다. 작은 조직이라도 운영 책임과 검증 기준을 초기에 잡아두면 이후 변경을 추적하기 쉬워집니다.
JERRYBAY가 구분하는 적용 범위
JERRYBAY는 같은 문제를 구축, 교육, 기획이라는 서로 다른 개입 수준으로 구분합니다. 업무 흐름이 명확하고 반복이 많다면 구축이 맞을 수 있고, 도구는 있지만 현업 사용이 막힌다면 교육이 먼저일 수 있습니다. 아직 어떤 문제를 풀지 결정되지 않았다면 기획을 통해 문제·사용자·근거부터 정리하는 편이 낫습니다.
제품·구축
AIKUS는 학습 화면과 업무 실행, 결과 축적을 하나의 제품 흐름으로 다루는 공개 가능한 사례입니다.
기획·프로젝트 관리
정부사업·프로젝트 관리 레퍼런스에서는 여러 이해관계자와 산출물을 연결한 수행 맥락을 확인할 수 있습니다.
파일럿 시작 전 체크리스트
- 대상 사용자를 한 역할로 특정했다.
- 현재 문제와 반복 비용을 관찰 가능한 행동으로 적었다.
- 이번 파일럿이 만들어야 할 결과물의 형식을 정의했다.
- 결과를 검토하거나 승인할 사람이 정해져 있다.
- 실패·예외 상황에서 자동 실행을 멈출 기준이 있다.
- 민감한 데이터와 외부 모델 사용 경계를 적었다.
- 성공 기준을 “시연 완료”가 아니라 실제 흐름 재현으로 정의했다.
자주 묻는 질문
파일럿은 얼마나 크게 시작해야 하나요?
가능하면 한 사용자 역할, 한 반복 문제, 한 결과물까지로 줄이는 편이 좋습니다. 범위가 작아도 입력부터 실제 사용까지 끝까지 연결하는 것이 중요합니다.
먼저 교육을 해야 하나요, 시스템을 만들어야 하나요?
문제가 도구 사용 미숙인지, 반복 업무 구조인지에 따라 다릅니다. 사용자가 이미 여러 도구를 쓰지만 결과가 축적되지 않는다면 시스템 설계가 더 중요할 수 있습니다.
처음부터 완전 자동화를 목표로 해야 하나요?
아닙니다. 초기에는 사람이 검토해야 하는 단계와 자동화해도 되는 단계를 분리해 근거를 쌓는 편이 안전합니다.
근거 자료
- NIST AI Risk Management Framework ↗ — 조직이 AI 위험을 관리하기 위한 공식 프레임워크와 운영 자료.
- NIST Generative AI Profile ↗ — 생성형 AI의 특수 위험과 대응 행동을 정리한 공식 프로필.
- JERRYBAY 기업·기관 협업 안내 — 구축·교육·기획의 현재 공개 범위.
- JERRYBAY 경험·기획 기록 — 프로젝트·강의·기획·정부사업의 공개 가능한 경험.