도입 검토 실무 안내
AI 도입 검토를 순서대로 따라가는 실무 안내
AI 도입 검토는 기술 선정에서 시작하지 않습니다. 어떤 업무를 맡길지, 데이터가 어디에 있고, 어떤 보안 조건을 통과해야 하는지가 먼저 정해져야 후보가 좁혀집니다. 이 페이지는 데이터 준비부터 보안 검토, 모델 선택, 파일럿 설계까지 검토 순서대로 확인할 항목을 정리합니다.
검토 순서가 뒤집히면 비교 작업을 두 번 하게 됩니다
이 안내는 여덟 단계로 이어집니다. 각 단계는 앞 단계의 결론을 입력으로 받습니다. 데이터 위치를 확인하기 전에 모델을 고르면, 보안 조건이 드러나는 순간 후보 목록을 처음부터 다시 만들어야 합니다.
순서를 건너뛰면 뒤 단계에서 되돌아오게 되므로, 처음에는 느려 보여도 이 흐름을 그대로 따라가는 편이 결국 짧습니다.
- 1단계 맡길 업무를 한 문장으로 정하기 결과물을 한 문장으로 쓸 수 있는지부터 확인
- 2단계 데이터가 어디에 있는지 확인하기 사내·외부·정리 상태를 먼저 파악
- 3단계 보안·규제 검토 항목 정리하기 배포 위치·권한·로그·반출 조건
- 4단계 모델 유형과 배포 방식 고르기 순위가 아니라 후보 목록을 확정
- 5단계 통합 방식 정하기 API 연동·RAG 구성·기존 시스템 연결
- 6단계 프롬프트와 평가 기준 만들기 정확도·누락·형식 준수 항목 정의
- 7단계 파일럿 범위와 기간 정하기 대상·인원·기간·성공 판단 기준
- 8단계 멀티모델과 모델 라우팅 검토 시점 확대 단계에서 운영 주체를 먼저 정함
각 단계의 판단 근거는 문서로 남겨두는 편이 좋습니다. 그 기록이 이후 모델 비교와 사후 검토의 기준이 됩니다.
1단계: 맡길 업무를 한 문장으로 정하기
출발점은 업무 정의입니다. "민원 답변 초안 작성", "설비 이상 징후 조기 감지"처럼 결과물이 무엇인지 한 문장으로 쓸 수 있어야 합니다. 이 문장이 흐려지면 이후 비교 기준도 함께 흐려집니다.
문서 요약처럼 검수가 쉬운 업무는 검토 부담이 낮고, 설비 제어처럼 결과가 즉시 영향을 주는 업무는 검토 범위가 넓어집니다. 첫 적용 대상은 검수 가능한 업무로 잡는 편이 안전합니다.
한 문장을 쓸 때 세 가지를 함께 적어두면 이후 단계가 편해집니다. 누가 결과를 검수하는지, 결과물이 어떤 형식이어야 하는지, 잘못된 결과가 나왔을 때 어떤 일이 생기는지입니다.
업무 정의에서 확인할 것
- 결과물이 문서인지, 알림인지, 제어 신호인지 구분되어 있는가
- 검수 담당자가 사전에 지정되어 있는가
- 잘못된 결과가 나왔을 때 되돌릴 수 있는 절차가 있는가
2단계: 데이터가 어디에 있는지 확인하기
AI가 쓸 데이터가 사내 시스템에 있는지, 외부에 있는지, 애초에 정리되어 있는지 확인합니다. 사내 문서 검색을 붙이려면 문서가 검색 가능한 형태로 정리되어 있어야 하고, 이 작업이 예상보다 오래 걸리는 경우가 많습니다.
정부망 업무라면 데이터가 외부로 나갈 수 없다는 전제가 먼저 깔립니다. 이 단계에서 확인한 제약이 모델 후보를 절반 가까이 줄여줍니다.
- 위치
- 사내 시스템, 업무망, 외부 SaaS 중 어디에 있는가
- 형태
- 검색과 인용이 가능한 문서 형태로 정리되어 있는가
- 품질
- 중복·구버전·스캔 이미지가 어느 정도 섞여 있는가
- 반출 조건
- 외부 처리 경로를 아예 쓸 수 없는 업무인가
3단계: 보안·규제 검토 항목 정리하기
보안 검토는 배포 위치, 접근 권한, 로그 보관, 데이터 반출 조건으로 나눠 봅니다. 정부망이나 사내망에서만 운영해야 하는 업무는 클라우드 기반 후보가 자동으로 제외됩니다. 금융·의료처럼 규제가 강한 영역은 감사 추적 가능성까지 요구됩니다.
검토 항목을 문서로 미리 정해두면 담당 부서와의 논의가 훨씬 짧아집니다. 이 문서는 이후 모델 비교표의 기준으로도 그대로 쓰입니다.
네 갈래로 나눠 적는 검토 항목
- 배포 위치
- 사내망, 정부망, 클라우드 중 어디까지 허용되는지 적어둡니다. 여기서 결정된 범위가 후보 목록의 상한이 됩니다.
- 접근 권한
- 누가 어떤 문서까지 조회할 수 있는지, 권한이 기존 계정 체계와 어떻게 연결되는지 확인합니다.
- 로그 보관
- 어떤 질의와 응답이 남는지, 보관 기간과 열람 권한이 감사 요구를 만족하는지 따져봅니다.
- 데이터 반출
- 학습이나 처리 목적으로 외부로 나갈 수 있는 데이터가 있는지, 있다면 어떤 조건이 붙는지 정리합니다.
4단계: 모델 유형과 배포 방식 고르기
보안 조건을 통과한 후보 중에서 모델 유형과 배포 방식을 정합니다. 한국어 문서 업무 비중이 높다면 한국어 품질과 검색 결합 맥락에서 언급되는 모델을 후보에 넣고, 정부망 업무라면 정부망 전용 인프라로 제공되는 모델을 확인합니다. 산업 특화 요구가 크면 제조·금융·의료용으로 확장된 기업용 모델을 함께 봅니다.
이 단계에서는 순위를 정하기보다 후보 목록을 확정하는 것이 목적입니다. 세부 비교는 비교 페이지 항목을 따릅니다.
한국어 문서 업무 비중이 높을 때
한국어 요약·분류 품질과 사내 검색 결합을 함께 볼 수 있는 후보를 우선 검토합니다. 문서 길이가 길고 표가 많은 업무라면 입력 길이 제한도 확인 항목에 넣습니다.
정부망·사내망 전용 운영
외부 연결 없이 운영할 수 있는 제공 형태가 있는지 확인합니다. 모델 자체의 성능보다 배포 조건이 먼저 걸러내는 경우가 많습니다.
산업 특화 요구가 클 때
제조·금융·의료용으로 확장된 기업용 모델을 함께 놓고 봅니다. 도메인 용어와 판단 기준이 일반 모델과 어떻게 다른지가 확인 포인트입니다.
범용으로 충분한 경우
요약, 초안 작성, 분류처럼 정답이 하나로 좁혀지지 않는 업무는 범용 모델로 시작하고 평가 결과에 따라 범위를 넓히는 편이 관리하기 쉽습니다.
5단계: 통합 방식 정하기
통합은 API 연동, RAG 구성, 기존 시스템 연결로 나뉩니다. API와 모델 기능을 이용해 서비스에 AI를 붙이는 방식은 개발 도구를 통해 구현하는 경우가 많고, 네이버 계열의 CLOVA Studio 같은 사례가 이 맥락에서 언급됩니다.
사내 지식 검색은 RAG 구성이 필요하며, 문서 정제 품질이 결과를 좌우합니다. 기존 업무 시스템과 연결할 때는 응답 실패 시 대체 흐름을 함께 설계합니다. 통합 난이도는 이후 운영 부담을 결정합니다.
연동 방식 비교
API 연동
모델 기능을 서비스 화면에 직접 붙입니다. 개발 도구와 키 관리, 호출 한도 설계가 함께 필요합니다.
난이도 낮음 · 통제 범위 넓음
RAG 구성
사내 문서를 검색해 근거와 함께 답하게 합니다. 문서 정제와 색인 갱신 주기가 품질을 좌우합니다.
난이도 중간 · 문서 작업 비중 큼
기존 시스템 연결
업무 시스템 흐름 안에 넣습니다. 응답 실패 시 담당자에게 넘기는 대체 경로를 같이 설계합니다.
난이도 높음 · 운영 부담 결정
6단계: 프롬프트와 평가 기준 만들기
같은 모델이라도 프롬프트 설계에 따라 결과가 크게 달라집니다. 실제 업무 문서를 준비해 요약 정확도, 누락 여부, 형식 준수를 확인하는 평가 기준을 만듭니다. 조례·규정 충돌 검토처럼 정밀도가 중요한 업무는 별도 평가 항목을 둡니다.
평가 기준은 파일럿 결과를 해석하는 근거가 되므로 사전에 문서로 남깁니다. 이 기준이 없으면 결과가 좋은지 나쁜지 판단할 수 없습니다.
- 요약 정확도 — 원문에 없는 내용을 만들어내지 않는지 확인합니다.
- 누락 여부 — 반드시 포함되어야 할 항목이 빠지지 않았는지 봅니다.
- 형식 준수 — 표, 항목 번호, 문체가 사내 양식과 맞는지 확인합니다.
- 규정 충돌 — 조례·규정과 어긋나는 서술이 있는지 별도 항목으로 봅니다.
7단계: 파일럿 범위와 기간 정하기
파일럿은 대상 업무, 참여 인원, 기간, 성공 판단 기준을 함께 정한다. 범위를 넓게 잡으면 실패 원인을 분리하기 어려워진다. 검수 가능한 업무 하나를 골라 좁게 시작하는 편이 결과 해석에 유리하다. 기간이 끝나면 평가 기준에 따라 계속 진행할지, 범위를 바꿀지 결정한다.
파일럿 결과가 다음 단계 확대 여부를 정한다.
대상 업무
검수가 가능한 업무 하나. 담당자가 결과를 확인할 수 있어야 합니다.
참여 인원
실제 업무 담당자와 개발 담당자를 최소 단위로 묶습니다.
기간
종료 시점을 먼저 정해두어야 판단이 미뤄지지 않습니다.
성공 판단 기준
6단계에서 만든 평가 항목을 그대로 사용합니다.
8단계: 멀티모델과 모델 라우팅 검토 시점
파일럿을 마치고 적용 범위를 넓히면 단일 모델로 감당하기 어려운 업무가 나옵니다. 이때 멀티모델 구성과 모델 라우팅을 검토합니다. 요청 성격에 따라 적합한 모델로 보내는 방식이며, MaaS 형태로 여러 모델을 묶어 쓰는 선택지도 있습니다.
특정 모델 의존이 줄어드는 대신 관리 대상이 늘어납니다. 운영 주체를 먼저 정해두지 않으면 확대 단계에서 부담이 커집니다.
확대 단계로 넘어가기 전에 확인할 것
요청을 어떤 기준으로 나눌지 정합니다. 문서 유형, 민감도, 응답 속도 요구 중 무엇이 우선인지 명확히 합니다.
라우팅 규칙을 누가 관리하고 언제 바꿀 수 있는지 정합니다. 규칙이 담당자 개인에게 묶이면 확대가 멈춥니다.
모델을 교체할 수 있는 구조인지 확인합니다. 호출 부분이 한 곳에 모여 있으면 교체 부담이 줄어듭니다.
도입 후 첫 3개월에 확인할 것
파일럿이 끝나고 운영에 들어가면 사용률, 검수 시간, 재작업 비율을 확인한다. 이 지표가 나빠지면 프롬프트나 문서 정제 단계로 돌아가야 한다. 사용자가 늘어나면 응답 지연과 비용 구조도 함께 바뀐다.
모델을 교체할 수 있는 구조를 만들어 두면 특정 모델 문제에 덜 묶인다. 3개월 시점에 확대 여부를 다시 판단하는 편이 안전하다.
파일럿 기간은 얼마나 잡아야 하나요?
업무 난이도에 따라 다르지만 검수 가능한 업무 하나로 좁게 시작하는 편이 결과 해석에 유리합니다. 기간과 성공 판단 기준을 함께 정해두어야 종료 시점에 판단이 가능합니다.
보안 검토는 언제 시작해야 하나요?
데이터 위치를 확인한 직후가 적절합니다. 보안 조건이 모델 후보를 크게 줄이기 때문에, 나중에 시작하면 비교 작업을 다시 해야 하는 경우가 생깁니다.
프롬프트는 누가 관리해야 하나요?
업무 담당자와 개발 조직이 역할을 나누는 편이 일반적입니다. 업무 담당자가 결과 품질을 판단하고, 개발 조직이 버전 관리와 배포를 맡는 구조가 운영에 유리합니다.
여덟 단계를 확인했다면 다음은 실제 비교입니다
이 페이지의 순서는 검토 기준을 세우는 데까지입니다. 실제 후보를 나란히 놓고 보려면 비교 페이지에서 항목별로 확인하고, 산업별 사례에서 비슷한 조건의 적용 상황을 참고하세요. 이해가 어려운 용어는 용어 사전에서 찾아볼 수 있습니다.
검토 과정에서 확인이 필요한 사항이 있으면 문의로 남겨주세요. 운영 시간은 월요일–금요일 09:00–18:00이며, 답변은 순차적으로 드립니다.