도입 가이드
AI 도입, 요구사항부터 파일럿까지
처음 도입을 검토하는 조직은 대개 같은 지점에서 막힌다. 무엇부터 정해야 하는지 순서가 안 잡히기 때문이다. 요구사항 정의부터 데이터 주권 검토, 배포 형태 선택, 파일럿 설계까지 순서대로 따라갈 수 있게 정리했다.
- 요구사항 문장화 업무·담당·빈도
- 데이터 위치·주권 저장·반출 경로
- 배포 형태 선택 온프레미스·하이브리드
- 모델·플랫폼 후보 RAG·파인튜닝
- 추론 비용·인프라 칩·운영 인력
1단계: 요구사항을 문장으로 적기
"AI로 업무 효율을 높인다"는 목표는 검토에 쓸 수 없다. 어떤 업무를, 누가, 얼마나 자주, 어떤 결과물로 처리하는지를 문장으로 적어야 한다. 예를 들어 "고객 문의 분류를 상담원이 하루 200건 처리하는데, 1차 분류를 자동화한다" 수준까지 좁혀야 비교가 가능해진다.
문장으로 적어두면 이후 단계에서 판단 기준이 흔들리지 않는다. 후보를 비교할 때도, 파일럿 성공 여부를 판단할 때도 결국 이 문장으로 돌아오게 된다. 담당 부서와 실제 사용자가 같은 문장을 보고 있는지 확인하는 것도 이 단계에서 해두는 편이 좋다.
업무·담당자·처리량·결과물 네 가지가 문장에 들어가면 비교 기준으로 쓸 수 있다.
2단계: 데이터 위치와 주권 확인
사내 데이터가 어디에 저장되고 어떤 경로로 처리되는지 먼저 확인한다. 금융, 공공, 제조처럼 규제와 보안 요구가 강한 곳은 이 단계에서 배포 형태가 사실상 정해진다. 데이터 반출이 어렵다면 온프레미스나 하이브리드 구성이 전제가 된다.
반대로 실험 목적이면 클라우드형으로 시작해 검증 후 옮기는 편이 낫다. 데이터 주권은 저장 위치만의 문제가 아니다. 학습에 어떤 데이터가 들어가는지, 추론 로그가 어디에 남는지, 외부 모델 제공자의 학습에 재사용되지 않는지까지 함께 확인해야 한다.
- 학습 데이터가 사내에 남는지, 외부로 나가는지
- 추론 로그와 프롬프트가 어디에 저장되는지
- 모델 제공자의 재학습 정책과 계약 조건
- 감사·규제 대응에 필요한 기록이 남는지
이 단계가 배포 형태를 정한다
데이터 반출이 어려운 조직은 온프레미스나 하이브리드가 출발점이 되고, 실험 목적이면 클라우드형으로 검증한 뒤 옮기는 순서가 자연스럽다. 제약을 먼저 적어두면 다음 단계에서 후보를 좁히는 기준이 생긴다.
3단계: 배포 형태 선택
정답은 없다. 2단계에서 정한 제약이 기준이 된다. 세 가지 구성의 성격을 나란히 두고 자기 조직에 맞는 쪽을 고르면 된다.
온프레미스
통제가 강하고 부담도 크다
데이터가 사내를 벗어나지 않는다. 대신 초기 구축과 운영 부담이 크고, 모델 교체 주기를 자체적으로 감당해야 한다.
하이브리드
민감 데이터만 안에 둔다
민감 데이터는 내부에, 나머지는 외부 자원에 두는 절충안이다. 경계를 어디에 그을지 설계가 필요하다.
클라우드형
빠르지만 위치 제약을 받는다
도입 속도는 빠르다. 데이터 위치 제약이 있는 조직에는 맞지 않을 수 있어 2단계 확인이 먼저다.
추론 비용은 결국 어디에서 얼마나 돌리느냐의 문제로 돌아온다
4단계: 모델과 플랫폼 후보 추리기
한국어 비중이 높으면 HyperCLOVA X 같은 한국어 중심 플랫폼이 후보에 오른다. 초거대 모델이 필요하면 LG AI Research의 EXAONE 2.0처럼 규모를 키운 축을 검토한다. 다만 모델 선택은 시작일 뿐이고, RAG 구성이나 파인튜닝 계획까지 같이 세워야 한다. 필요하면 운영 층으로 VESSL AI 같은 MLOps 플랫폼을 함께 본다.
후보를 추릴 때는 모델 성능표보다 자기 데이터로 돌려본 결과가 우선이다. 같은 모델이라도 문서 검색 구조와 프롬프트 설계에 따라 체감 품질이 크게 갈린다. 후보 단계에서 비교 축을 정해두면 리뷰와 비교 페이지를 함께 볼 때 판단이 빨라진다.
후보를 볼 때 함께 확인할 것
- 한국어 문서·용어 처리 품질
- RAG 구성과 사내 문서 연동 방식
- 파인튜닝 계획과 필요 데이터
- 운영 층 도구와 인력 요건
5단계: 인프라와 추론 비용 점검
서비스가 커지면 추론 비용이 판단을 좌우한다. 데이터센터 추론이면 FuriosaAI 같은 국산 AI 반도체 축을, 현장형 처리면 DeepX 같은 엣지 AI 축을 검토할 수 있다. 칩 도입은 소프트웨어 스택과 운영 인력까지 함께 봐야 하므로, 파일럿 단계에서 미리 실험해두는 편이 안전하다.
비용은 하드웨어 값만으로 결정되지 않는다. 모델 크기, 동시 요청 수, 응답 지연 허용 범위가 함께 얽힌다. 이 세 가지를 먼저 적어두면 어떤 구성이 현실적인지 판단하기 쉬워진다.
6단계: 파일럿 설계
범위를 좁게 잡는다. 성공 기준을 미리 정하고, 무엇을 측정할지 문서로 남긴다. "잘 되는 것 같다"는 판단은 나중에 문제가 된다. 기간보다 측정 항목이 결과를 좌우한다.
파일럿이 끝나면 확장 여부를 판단할 근거가 있어야 한다. 측정 항목을 미리 정해두면 결과가 애매하게 나와도 다음 결정을 내릴 수 있다.
7단계: 운영 계획 세우기
파일럿은 대개 잘 끝난다. 문제는 그다음이다. 학습, 배포, 실험 관리가 반복 가능하게 돌아가지 않으면 모델은 방치된다. 운영 인력, 모니터링 항목, 재학습 주기를 미리 정해두면 확장 단계가 흔들리지 않는다.
운영 계획에는 담당자를 이름으로 정하는 편이 좋다. 조직이 바뀌어도 책임이 남아 있어야 모델이 조용히 멈추는 일을 막을 수 있다.
운영에서 미리 정해둘 것
- 운영 담당 인력과 역할
- 모니터링 항목과 알림 기준
- 재학습 주기와 데이터 갱신
- 배포·실험 관리 절차
산업별로 다른 출발점
같은 순서를 따르더라도 어디서 시작하는지는 산업마다 다르다. 자기 산업의 출발점을 찾는 데는 산업별 활용 페이지가 도움이 된다.
제조·물류
결과가 눈에 보이는 영역부터
비전 검사, 스마트팩토리 자동화처럼 판정 결과가 바로 드러나는 업무가 첫 후보가 된다.
커머스
추천·검색·운영 자동화
상품 탐색과 반복 운영 업무가 우선순위로 올라온다. 데이터가 이미 쌓여 있어 파일럿 설계가 수월하다.
공공·교육
규격화된 업무 지원 먼저
민원·행정 문서처럼 형식이 정해진 업무가 출발점이 된다. 데이터 주권 검토가 특히 중요한 영역이다.
흔히 하는 실수
세 가지 모두 순서를 지키면 피할 수 있다. 순서를 건너뛰는 만큼 나중에 되돌아오는 비용이 커진다.
-
기술부터 정하는 것
모델을 먼저 고르고 업무를 나중에 맞추면 파일럿이 끝나도 현업에 남지 않는다. 1단계 문장이 먼저다.
-
성공 기준을 정하지 않는 것
측정 항목 없이 진행하면 결과를 두고 해석이 갈린다. 6단계에서 기준을 문서로 남긴다.
-
운영 계획을 빼먹는 것
배포와 재학습이 반복되지 않으면 모델은 방치된다. 7단계를 파일럿과 함께 준비한다.
산업마다 첫 파일럿으로 삼기 좋은 업무가 다르다
자주 묻는 질문
도입 검토 중 자주 나오는 질문 세 가지
파일럿 기간은 얼마나 잡아야 하나?
기간보다 측정 항목이 중요하다. 범위를 좁게 잡고 성공 기준을 미리 문서로 정해두면 판단이 흔들리지 않는다.
온프레미스가 항상 더 안전한가?
통제는 강하지만 초기 구축과 운영 부담이 크다. 민감 데이터만 내부에 두는 하이브리드가 더 맞는 경우도 많다.
RAG와 파인튜닝 중 무엇부터?
사내 문서 검색처럼 최신 정보 반영이 중요하면 RAG부터 검토하는 편이 일반적이다. 도메인 표현 자체를 맞춰야 하면 파인튜닝을 함께 본다.