사내 데이터 AI 연동 완전 가이드: 연동 방식 4가지 선택 기준과 RAG 지식베이스 구축 6단계

회의실 화면에 사내 규정집 PDF가 떠 있다. 누군가 “이걸 챗GPT에 그냥 넣으면 안 되나요”라고 묻는다. 옆에서는 ERP에 있는 실적 숫자를 AI가 바로 읽게 할 수 없냐는 말이 나온다. 보안팀은 팔짱을 끼고 있고, 개발팀은 “어느 데이터부터요?”라고 되묻는다. 이 자리에서 논의가 멈추는 이유는 대부분 같습니다. 사내 데이터 AI 연동을 도구 선택 문제로 보고 있기 때문입니다.

이 글을 처음부터 끝까지 읽을 필요는 없습니다. 우리 회사 데이터가 문서 위주인지 DB 위주인지만 정해졌다면 해당 섹션만 봐도 됩니다. 진단 문항과 템플릿이 먼저 필요하다면 팬덤퍼널 자료실의 실무 템플릿에서 바로 받아 쓰는 편이 빠릅니다.

핵심 요약

• 사내 데이터 AI 연동의 4가지 축 — API 연동, DB·데이터웨어하우스 직결, RAG 지식베이스, MCP 서버. 선택 기준은 데이터 형태(정형/비정형)와 실시간성 요구
• 규정·매뉴얼·회의록 같은 비정형 문서는 RAG, ERP·CRM의 정형 데이터 조회는 API 연동이 정답
• 실패의 8할은 모델이 아니라 데이터 품질과 권한 동기화에서 발생 — 정리 안 된 원본을 벡터DB에 넣으면 오답도 그대로 재생산
• 개인정보보호법·ISMS-P 사전 체크리스트 미통과 시 PoC 성공에도 전사 확산은 차단

지금 많은 조직이 같은 지점에서 멈춰 있습니다. 개인 계정으로 챗GPT를 쓰는 직원은 늘었는데, 정작 회사 자산인 문서와 데이터는 AI 바깥에 남아 있는 상태입니다. 사내 데이터 AI 연동은 여기서부터 시작되는 아키텍처 결정입니다.

문제는 이 결정을 툴 비교로 대신하려 할 때 생깁니다. Gemini Enterprise가 나은지, Microsoft Copilot이 나은지, Claude Cowork이나 ChatGPT Work은 어떤지를 먼저 따집니다. 하지만 정작 물어야 할 질문은 하나입니다. 우리 데이터가 어떤 형태로 어디에 있는가.

제약사 사업부에서 교육을 진행한 적이 있습니다. 이미 AI로 부서용 앱까지 만들어 쓰는 팀이었는데도, 요청은 도구가 아니라 “출처를 어떻게 믿게 만들 것인가”였습니다. 규제 산업일수록 질문이 이렇게 구체적으로 내려옵니다.

이 글은 연동 방식 4가지의 판단 기준, RAG 지식베이스 구축 6단계 파이프라인, 방식별 예상 기간과 리소스, 국내 규제 기준 보안 체크리스트를 순서대로 다룹니다. 읽고 나면 우리 데이터의 유형과 보안 등급을 스스로 진단해 연동 방식을 고를 수 있습니다. 조직의 현재 위치부터 확인하고 싶다면 AI 활용 성숙도 5단계를 먼저 보는 편이 순서에 맞습니다.

왜 좋은 AI를 도입해도 “우리 회사 데이터”를 물어보면 답을 못 할까요?

도구를 잘못 골랐나 싶으실 겁니다. 대개는 아닙니다.

범용 LLM은 공개된 텍스트로 학습했습니다. 우리 회사의 취업규칙, 제품 스펙 시트, 지난달 개정된 계약서 조항은 애초에 학습 대상에 없었습니다.

그래서 “우리 회사 기준으로는요?”라는 질문에 그럴듯한 거짓말이 돌아옵니다. 모델 성능 문제가 아니라 데이터가 연결되지 않은 문제입니다.

많은 팀이 파일 업로드로 이 틈을 메웁니다. 그런데 대화창을 새로 열 때마다 같은 문서를 다시 올려야 하고, 어떤 버전을 올렸는지는 아무도 추적하지 않습니다.

더 곤란한 건 권한입니다. 인사팀 문서를 올려둔 대화창은 그 사람만의 것이라, 팀 전체가 쓰는 순간 볼 수 없는 사람이 보게 됩니다. 사내 데이터 AI 연동은 편의 기능이 아니라 권한 설계 문제입니다.

한 제약사 사업부 강의는 요청부터 결이 달랐습니다. 이미 부서용 앱까지 만들어 쓰는 팀이었는데, 다음 고민은 도구가 아니라 ‘출처를 어떻게 믿게 만들 것인가’였습니다.

이 글은 그 지점만 다룹니다. 연동 방식 선택, RAG 기반 사내 지식베이스 AI 구축, 국내 규제 대응, 그리고 운영 지표까지입니다.

조직 전체의 도입 순서가 궁금하다면 AI 활용 성숙도 단계를 먼저 확인하는 편이 낫습니다. 문서 검색 AI는 성숙도 3단계 이후에 붙이는 과제입니다.

사내 데이터를 AI에 연결하는 4가지 방식, 무엇이 어떻게 다른가요?

“RAG 하면 되는 거 아닌가요?”라는 말을 자주 듣습니다. 데이터 종류에 따라 답이 갈립니다.

정형 데이터를 실시간 조회한다면: REST API와 Bulk API

재고 수량, 고객 등급, 이번 달 매출처럼 표에 들어가는 값은 검색이 아니라 조회의 영역입니다. 이때는 ERP·CRM이 이미 열어둔 RestAPI를 씁니다.

단건 질의는 REST API, 야간에 수십만 건을 한 번에 내리는 작업은 Bulk API로 나눕니다. 응답은 JSON으로 표준화하고 API Gateway를 경유시켜야 인증·로그·트래픽 제어가 한곳에 모입니다.

AWS 데이터 웨어하우스나 BI 툴에 직결하는 방법도 있습니다. 속도는 빠르지만 스키마가 바뀔 때마다 연동이 깨지는 대가를 치릅니다. AWS 데이터 플랫폼 API 연동 사례가 구조를 이해하는 데 도움이 됩니다.

비정형 문서를 다룬다면: RAG와 벡터DB

규정집, 회의록, 제안서, 매뉴얼은 API로 못 부릅니다. 여기서 RAG 구축 방법이 등장합니다.

흐름은 셋입니다. 문서를 의미 단위로 자르고(청킹), 숫자 벡터로 바꿔 벡터DB에 넣고, 질문이 오면 유사한 조각을 찾아 그 근거만으로 답을 만듭니다.

출처 링크가 답변에 함께 붙는 것이 이 방식의 진짜 이점입니다. 규제 산업일수록 답보다 근거를 먼저 봅니다.

여러 도구를 한 번에 연결한다면: MCP 서버와 커넥터

Notion에 기획서가, Google Workspace에 회의록이, 사내 그룹웨어에 결재 이력이 흩어져 있는 상황이 보통입니다.

MCP 서버는 이 도구들을 AI가 호출할 수 있는 표준 규격으로 감싸줍니다. 도구마다 개별 연동을 짜던 작업이 커넥터 등록으로 줄어듭니다.

여기서 한 걸음 더 나간 것이 에이전틱 RAG입니다. “작년 대비 이 제품 클레임이 왜 늘었나”라는 질문을 스스로 쪼개, CRM과 문서 저장소를 각각 조회한 뒤 합쳐서 답합니다.

우리 회사는 어떤 방식을 골라야 할까요? 의사결정 플로우와 기간·리소스 비교

선택지가 넷이면 결정이 늦어집니다. 질문 네 개로 줄이면 대개 30분 안에 끝납니다.

4개 질문으로 끝내는 방식 선택 플로우

1. 연결할 데이터가 정형인가, 비정형 문서인가 — 정형이면 API 연동, 비정형이면 RAG입니다.
2. 답변에 실시간 값이 필요한가 — 재고·잔액처럼 분 단위로 바뀌면 배치 적재는 부적합합니다.
3. 폐쇄망 안에서 돌아야 하는가 — 그렇다면 온프레미스 모델과 사내 벡터DB가 전제가 됩니다.
4. 문서별로 열람 권한이 다른가 — 다르면 SSO 연동과 문서 단위 권한 필터가 1순위 요건입니다.

방식별 예상 소요 기간·리소스 비교표

아래 수치는 중견기업 기준 추정치입니다. 사내 데이터 정리 상태가 나쁘면 기간은 1.5배까지 늘어납니다.

연동 방식	적합 데이터	예상 기간(추정)	필요 인력	초기 비용	유지보수
REST/Bulk API	ERP·CRM 정형 데이터	3~6주	백엔드 1, 현업 0.5	중	중(스키마 변경 대응)
클라우드 RAG	규정·매뉴얼 등 문서	4~8주	엔지니어 1, 문서 담당 1	낮음~중	낮음
MCP 서버·커넥터	Notion·Workspace 등 다중 도구	2~4주	엔지니어 1	낮음	중(커넥터 버전)
온프레미스 RAG	폐쇄망 민감 문서	3~6개월	인프라 1, ML 1, 보안 0.5	높음	높음

온프레미스는 데이터가 밖으로 나가지 않는다는 확실한 장점이 있습니다. 대신 GPU 비용을 떠안고, 모델 최신성이 클라우드보다 반년가량 뒤처집니다.

반대로 Gemini Enterprise, ChatGPT Work, Microsoft Copilot, Claude Cowork 같은 클라우드 제품은 최신 모델과 커넥터를 바로 씁니다. 엔터프라이즈 AI 제품 비교 분석이 제품별 차이를 정리해두었습니다.

결재하는 쪽에 앉아 품의서를 승인하고 반려해본 입장에서 말하면, 표의 ‘예상 기간’보다 ‘필요 인력’에서 막힙니다. 사람이 없으면 방식이 아니라 일정이 바뀝니다.

내부 리소스 현황이 애매하다면 AI 성숙도 자가진단 30문항으로 데이터·인프라 영역 점수만 먼저 확인해도 됩니다. 예산 항목 구성은 기업 AI 교육 비용 정리와 함께 보면 품의서 초안이 빨라집니다.

RAG 기반 사내 지식베이스, 실제로 어떻게 만드나요?

“문서 폴더를 통째로 넣으면 되는 거 아닌가요.” 자주 듣는 말입니다.

그렇게 출발한 프로젝트는 대개 검색 품질에서 멈춥니다. 순서만 지켜도 상당 부분은 피해 갈 수 있는 문제입니다.

1~3단계: 문서 수집·정제·청킹

1. 대상 문서 범위 확정 — 전사 확산이 아니라 1개 부서·1개 업무에서 시작합니다. 인사팀 취업규칙 문의처럼 질문 유형이 좁을수록 초기 정확도가 올라갑니다.
2. 데이터 정제 — 중복 문서를 걷어내고 폐기된 규정을 삭제한 뒤, 최신 버전 원본을 하나로 단일화합니다. 표는 마크다운으로, 이미지는 캡션 텍스트로 뽑는 규칙을 여기서 정해둡니다.
3. 청킹과 메타데이터 태깅 — 문서를 조항·제목 경계 안에서 자르고, 부서·작성일·열람등급을 태그로 붙입니다. 이 태그를 빼먹으면 나중에 권한 필터를 붙이려 할 때 전체를 다시 적재해야 합니다.

4~6단계: 임베딩·검색 튜닝·응답 검증

1. 4단계 임베딩과 벡터DB 적재 — 한국어 문서 성능이 검증된 임베딩 모델을 고르고, 재적재 비용까지 계산해 벡터DB를 선택합니다.
2. 5단계 검색 품질 튜닝 — 키워드 검색과 벡터 검색을 함께 쓰는 하이브리드 구성에 리랭킹을 얹으면, 사내 약어와 제품 코드 검색이 눈에 띄게 나아집니다.
3. 6단계 응답 검증 — 실무자가 실제로 물을 질문 30~50개로 정답셋을 만들고, 근거 문서 출처가 없으면 답하지 않도록 강제합니다.

한 제약사 사업부 교육에서는 요청부터 결이 달랐습니다. 이미 부서용 앱까지 만들어 쓰던 팀이었는데, 다음 고민은 도구가 아니라 ‘출처를 어떻게 믿게 만들 것인가’였습니다.

규제 산업일수록 이 6단계가 협상 대상이 아니라는 걸 먼저 압니다. 엔터프라이즈 AI 데이터 구축 관점의 정리도 같은 순서를 짚습니다.

처음부터 완성형을 만들 필요는 없습니다. GPTs 사내 활용으로 문서 20개짜리 파일럿을 돌려 질문 로그를 모으고, 그다음 기업 챗봇 구축과 문서 검색 AI 고도화로 넘어가는 경로가 현실적입니다. 파일럿 범위를 어디까지 잡을지는 AI 활용 성숙도 단계에 맞춰 정하면 무리가 없습니다.

20년 된 ERP와 폐쇄망도 AI에 연결할 수 있나요?

“우리 ERP는 2000년대 초에 만든 겁니다.” 그 말 뒤엔 대체로 포기하는 표정이 따라옵니다.

연결 자체가 불가능한 경우는 생각보다 드뭅니다. 레거시 시스템 연동은 다섯 유형으로 나뉩니다. API 제공형, DB 직접 접근형, 화면(UI) 스크래핑형, 파일 배치 연동형, 그리고 완전 폐쇄망형입니다.

API가 없다면 읽기 전용 복제 DB를 따로 두는 편이 안전합니다. 운영 DB에 조회 부하를 주지 않으면서 데이터 파이프라인을 만들 수 있습니다.

스크래핑형은 RPA를 병행해 화면 값을 긁고, 배치형은 야간에 CSV로 추출해 적재하는 방식이 무난합니다. 폐쇄망 AI는 온프레미스 sLLM 또는 프라이빗 클라우드에 내부 벡터DB를 붙이는 조합으로 풀립니다.

정작 일정을 잡아먹는 건 기술이 아닙니다. EUC-KR 인코딩 깨짐, 스키마 문서 부재, 그리고 당시 담당자가 이미 퇴사했다는 사실. 이 셋이 거의 매번 등장합니다.

레거시 시스템에 AI를 연결하는 접근을 다룬 글들도 같은 지점을 지적합니다. 실시간 연동을 처음부터 욕심내기보다 일 1회 동기화로 시작하면, 업무 시스템 연동의 실패 확률이 크게 떨어집니다.

보안과 권한은 어디까지 설계해야 하나요? 국내 규제 체크리스트

“보안팀이 반대하면 끝”이라고들 합니다. 실제 사고는 다른 데서 납니다.

권한 설계: SSO와 역할 기반 접근 통제

원칙은 하나입니다. 원문서의 열람 권한이 AI 답변에도 그대로 상속되어야 합니다. 권한 동기화 실패는 사내 데이터 AI 연동에서 가장 큰 사고 원인입니다.

• SSO(싱글 사인온)로 사용자 신원을 확인한 뒤 검색이 실행되는 구조인가
• 역할 기반 접근 제어(RBAC)가 인사 시스템의 조직 변경과 자동으로 동기화되는가
• 청킹 단계에서 붙인 열람등급 메타데이터로 검색 결과가 사전 필터링되는가
• 퇴사·부서이동 시 접근 권한 회수 시점이 규정에 명시돼 있는가
• 모든 호출이 API Gateway를 경유해 인증·쿼터·로깅이 한곳에 모이는가

개인정보보호법·ISMS-P 대응 체크리스트

결재하는 쪽에 앉아 있을 때, 보안 검토란이 비어 있는 품의는 내용과 상관없이 되돌려보냈습니다. 그 항목은 대체로 아래 일곱 가지로 압축됩니다.

• 주민번호·연락처 등 개인정보가 포함된 문서를 가명처리 후 적재하는가
• 입력 데이터의 모델 학습 활용 여부가 계약서에 명시돼 있는가
• 데이터 국외 이전이 발생하는지, 발생 시 고지·동의 절차를 밟았는가
• 프롬프트와 응답의 보관 기간·파기 시점이 정해져 있는가
• 누가 언제 무엇을 조회했는지 감사추적 로그가 남는가
• 민감정보 입력 차단 규칙과 위반 시 알림 체계가 있는가
• 연 1회 이상 권한 재검토 일정이 데이터 거버넌스 문서에 들어 있는가

열두 항목 중 절반 이상이 비어 있다면, 기술 검토보다 규정 정비가 먼저입니다. 우리 조직이 지금 어느 지점에 서 있는지는 AI 성숙도 자가진단 30문항으로 3분 안에 확인할 수 있고, 그 리포트는 AI 교육 품의서 작성 시 배경란에 그대로 붙일 수 있습니다.

직접 구축 대신 엔터프라이즈 플랫폼을 쓰면 안 되나요?

여기까지 읽으면 드는 생각이 있죠. 이걸 우리가 다 만들어야 하나.

아닙니다. 상용 엔터프라이즈 플랫폼은 커넥터, 권한 상속, 감사 로그를 이미 기본으로 제공합니다. 자체 구축은 그것으로 해결되지 않을 때 가는 길입니다.

1차 선택 기준은 모델 성능이 아니라 지금 쓰는 오피스 스택입니다. 문서와 메일과 권한 체계가 이미 그쪽에 있기 때문입니다.

플랫폼	강점	권한·커넥터	고려점
Microsoft Copilot	Microsoft 365 문서·메일·팀즈 통합	기존 SharePoint 권한 상속	M365 라이선스 종속
Gemini Enterprise	Google Workspace 드라이브·메일 검색	드라이브 공유 설정 승계	워크스페이스 외 데이터는 별도 연동
ChatGPT Work(Enterprise)	범용 응답 품질, 사내 GPTs 배포	커넥터·MCP 서버 확장	리전·보관 정책 계약 확인 필요
Claude Cowork	긴 문서 해석, 문서 작업 협업	MCP 서버 기반 도구 연결	사내 시스템 연동은 개발 리소스 수반

비교 기준은 넷으로 좁히면 충분합니다. 커넥터 지원 범위, 권한 상속 방식, 온프레미스 지원 여부, 국내 리전 제공 여부. 엔터프라이즈 AI 플랫폼 4종 비교 자료도 함께 보면 판단이 빨라집니다.

자체 RAG가 유리한 상황도 분명히 있습니다. 사내 용어·제품 코드 검색 품질을 직접 튜닝해야 할 때, 폐쇄망일 때, 그리고 사용자 수가 많아 좌석당 과금이 불리해질 때입니다.

사내 AI 도입을 정할 때 조직의 현재 단계부터 보는 편이 안전합니다. AI 활용 성숙도 5단계에서 2단계에 머물러 있다면, 자체 구축보다 플랫폼으로 시작하는 쪽이 실패 확률이 낮습니다.

구축은 했는데 아무도 안 씁니다: 실패 원인과 성공 지표

오픈 2주째에 접속 그래프가 꺾입니다. 흔한 장면입니다.

원인은 대체로 셋입니다. 문서가 갱신되지 않아 답이 낡았고, 검색 품질을 정답셋으로 검증한 적이 없고, 기존 업무 동선과 떨어진 별도 창구로 만들어졌습니다.

직원이 사내 AI 대신 ChatGPT를 계속 쓰는 이유도 같은 자리에 있습니다. 더 빠르고, 화면이 익숙하고, 답이 낫기 때문입니다. 사내 AI를 도입해도 ChatGPT를 쓰는 이유를 정리한 사례도 결이 다르지 않습니다.

40곳 넘는 기업에서 교육을 하며 반복해 본 장면이 있습니다. 한 제약사 사업부는 이미 AI로 부서용 앱까지 만들어 쓰고 있었습니다. 그런데도 다음 고민은 도구가 아니라 ‘출처를 어떻게 믿게 만들 것인가’였습니다.

그래서 지표는 이수율이나 접속 수가 아닙니다. 주간 활성 사용률, 재질문율, 응답 만족도, 출처 클릭률, 문서 갱신 주기 준수율. 이 다섯이 사내 지식베이스 AI의 체온계입니다.

운영 루틴은 단순할수록 오래 갑니다. 월 1회 오답 로그를 열어 원인 문서를 보완하고, 정답셋으로 재검증하는 사이클 하나면 됩니다.

측정 설계가 막막하다면 AI 교육 효과 측정 지표의 계산 방식을 그대로 옮겨 쓸 수 있습니다. 현재 데이터 거버넌스 수준이 궁금하다면 AI 성숙도 자가진단 체크리스트가 병목을 먼저 짚어줍니다.

AX 컨설팅이나 외부 파트너는 언제 필요할까요. 내부에 데이터 오너가 지정돼 있지 않거나, 레거시 스키마를 아는 담당자가 이미 퇴사한 경우입니다. 반대로 문서 정리와 권한 체계가 살아 있다면 외주보다 기업 AI 교육 도입 8단계로 내부 역량을 먼저 올리는 편이 남습니다.

자주 묻는 질문

사내 데이터를 AI에 연동할 때 가장 먼저 확인해야 할 것은 무엇인가요?

데이터의 형태와 보관 위치, 그리고 문서별 열람 권한 구조 세 가지를 먼저 확인해야 합니다. 정형 데이터(ERP·CRM·데이터 웨어하우스)인지 비정형 문서(매뉴얼·계약서·회의록)인지에 따라 API 연동과 RAG 중 무엇이 맞는지가 갈립니다. 보관 위치는 폐쇄망 여부를 결정하고, 권한 구조는 SSO 연동과 메타데이터 설계의 난이도를 결정합니다. 이 세 가지를 표로 정리하지 않은 채 도구부터 고르면, 구축 중반에 아키텍처를 다시 뒤엎게 됩니다.

레거시 시스템(폐쇄망, 오래된 ERP)도 AI 연동이 가능한가요?

가능합니다. 다만 실시간 연동이 아니라 우회 경로를 전제로 해야 합니다. API가 없는 시스템은 읽기 전용 복제 DB를 따로 두거나, 야간 배치로 CSV를 추출해 벡터DB에 적재하는 방식이 현실적입니다. 폐쇄망이라면 온프레미스 sLLM이나 프라이빗 클라우드에 내부 벡터DB를 붙이는 조합으로 풉니다. 제약은 분명히 있습니다. 인코딩 깨짐, 스키마 문서 부재, 담당자 퇴사가 거의 매번 등장합니다. 일 1회 동기화로 시작해 주기를 좁혀가는 편이 안전합니다.

API 연동과 RAG 기반 연동 중 어떤 방식을 선택해야 하나요?

실시간으로 바뀌는 정형 데이터는 API, 잘 바뀌지 않는 비정형 지식은 RAG입니다. 재고 수량이나 오늘자 매출처럼 조회 시점의 값이 중요한 데이터는 REST API 단건 조회가 맞습니다. 반면 사규·제품 매뉴얼·과거 제안서처럼 문맥을 이해해야 하는 자료는 RAG가 훨씬 유리합니다. 실무에서는 대개 둘을 함께 씁니다. RAG로 규정을 찾아 답하고, 숫자는 API로 조회해 붙이는 하이브리드 구성이 일반적입니다.

사내 AI를 도입했는데도 직원들이 ChatGPT를 계속 쓰는 이유는 무엇인가요?

사내 AI가 업무 동선 밖에 있고, 응답 속도와 검색 품질이 범용 도구보다 떨어지기 때문입니다. 메신저나 문서 도구 안에서 부를 수 없고 별도 사이트에 로그인해야 한다면, 그 순간 선택지에서 밀립니다. 검색 품질도 문제입니다. 원하는 문서가 두 번 만에 안 나오면 사람은 바로 익숙한 도구로 돌아갑니다. 개선은 사용 창구를 기존 협업 도구 안으로 옮기고, 오답 로그를 월 단위로 리뷰해 문서를 보완하는 데서 시작합니다.

사내 데이터 연동 시 보안과 권한 관리는 어떻게 설계해야 하나요?

원문서의 열람 권한이 AI 답변에 그대로 상속되도록 설계하는 것이 첫 원칙입니다. SSO로 사용자를 인증하고, 역할 기반 접근 제어와 문서 메타데이터 필터링을 검색 단계에서 적용해야 합니다. 개인정보가 섞인 문서는 가명처리 후 적재하고, 학습 데이터 활용 여부와 국외 이전 조항을 계약서에서 확인해두면 좋습니다. ISMS-P 심사를 염두에 둔다면 프롬프트와 응답 로그의 보관 기간·감사추적 정책을 처음부터 문서로 남기는 편이 낫습니다.

마무리

• 방식 선택의 기준은 도구가 아니라 데이터의 형태·위치·권한 구조
• RAG는 문서 정제와 메타데이터 태깅의 품질이 곧 답변 품질
• 실패의 최대 원인은 기술이 아니라 권한 동기화와 업무 동선 이탈
• 전사 확산이 아니라 1개 부서·1개 업무에서 시작하는 축소 검증

지금 할 수 있는 첫 행동은 하나입니다. 한 부서를 골라, 그 부서가 한 달간 가장 자주 찾는 문서 20개의 목록과 각 문서의 열람 등급을 한 장에 적어보는 일입니다.

이 한 장이 연동 방식 선택의 절반을 끝냅니다. 남은 절반은 AI 활용 성숙도 단계에 따라 달라지고요.

그런데 이 문서를 다 만들어도 여전히 안 풀리는 게 남습니다. 예산입니다.

기술 검토는 실무진이 하는데, 결재는 다른 언어를 씁니다. 결재하는 쪽에 앉아 교육 품의서를 승인하고 반려해본 입장에서 보면, 반려는 대개 기술 설명이 부족해서가 아니라 ‘보안은 어떻게 하나’, ‘효과를 무엇으로 증명하나’라는 두 질문에 답이 없어서 생깁니다. 품의 단계의 항목 구조는 AI 교육 품의서 작성과 기업 AI 교육 도입 로드맵에서 따로 다뤘습니다.

이미 한 번 반려당한 상태라면, 빈 양식보다 필요한 건 채워진 문서입니다. 가상 기업 시나리오로 전 칸을 채운 품의서 완성 예시본과, ‘보안은?’ ‘내년에 하자’ 같은 반려 사유 5가지별 재상신 문구가 그대로 들어 있습니다.

AI 교육 도입 서류 3종 무료로 받기 — 전 칸을 채운 품의서 완성 예시본과 반려 사유 5가지별 재상신 문구 포함 (편집용 DOCX)