스킬캠퍼스
15강 · 도입 로드맵
강의

오늘 끝나면

도입 로드맵

  • 도입 로드맵의 핵심 문제를 한 문장으로 설명한다
  • 오른쪽 실습에서 도입이 어떻게 움직이는지 관찰한다
  • 다음 강의와 이어지는 한계를 말할 수 있다

실습 미션

파일럿에서 전사 확산까지 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.

성공 조건

  • 실습의 기본값을 먼저 관찰
  • 입력값이나 모드를 한 번 이상 바꿔 결과 비교
  • 왜 결과가 바뀌었는지 한 문장으로 설명

Enterprise LLM · 15

도입
로드맵

사내 LLM은 한 번에 전사로 깔지 않음.
파일럿 → 검증 → 확장 → 전사. 작게 시작해 단계마다 키움.
거버넌스·보안을 먼저 깔고, 빠른 성공으로 신뢰를 모으며 올라감.

P.01Enterprise LLM · 15

한 번에 전사로 안 감 — 단계로 키움

“전 직원이 쓰는 사내 챗봇 깔자.” 좋은 목표지만, 시작점은 거기가 아님.

도입은 단계로 키움.
파일럿은 한 팀 한 과제로 작게 검증함.
확장은 검증된 패턴을 인접 팀으로 넓힘.
전사는 표준 플랫폼으로 상시 운영함.

단계가 올라갈수록 대상·사용자·돈·리스크가 같이 커짐.
그래서 한 칸씩 올라가며 매번 “이 다음으로 넘어가도 되나”를 게이트로 점검함.
앞 단계에서 확인 못 한 위험을 전사 규모로 키우지 않으려는 것임.

파일럿 → 확장 → 전사 — 범위가 커지는 순서
범위가 커지는 순서 — 작게 시작
1파일럿10~30명

1팀 · 1과제

2확장100~500명

3~5팀 · 유사 과제

3전사전 직원

전 부서 · 다수 과제

대상↑ · 사용자↑ · 리스크↑ — 그래서 한 칸씩
P.02Enterprise LLM · 15

파일럿부터 — 작게 검증해 위험을 가둠

파일럿은 “가장 멋진 과제”가 아니라 “좁고 측정 가능한 과제”를 고름.

좋은 파일럿은 범위가 좁음.
한 팀의 한 업무 / 반복적이고 / 잘됐는지 숫자로 잴 수 있어야 함.
정답이 명확한 일(분류·요약·검색)이 위험도 낮고 효과도 빨리 보임.

왜 좁게 가두나? 실패해도 피해가 작고, 성공하면 근거가 또렷하기 때문임.
수동 대비 기준값(정확도·처리 시간)을 미리 재 두면 효과를 숫자로 증명할 수 있음.
이 숫자가 다음 단계 예산과 신뢰를 끌어오는 카드가 됨.

좋은 파일럿 유스케이스의 조건
좋은 파일럿 ↔ 피할 파일럿
고름
+ 좁은 범위 — 한 팀 · 한 업무
+ 반복적 · 자주 일어남
+ 숫자로 측정 가능 (정확도·시간)
+ 정답이 명확 (분류·요약·검색)
피함
전사 동시 오픈
정답 모호 · 측정 불가
한 번에 핵심 업무 전부
좁게 가둘수록 실패는 작고 성공은 또렷함
P.03Enterprise LLM · 15

검증과 확장 — 빠른 성공이 신뢰를 만듦

파일럿이 통과하면 바로 전사로 안 뜀. 인접한 비슷한 팀으로 먼저 넓힘.

확장의 연료는 빠른 성공 사례임.
“옆 팀이 이걸로 처리 시간 40% 줄였다” 같은 한 건이 회의실 열 번보다 셈.
숫자로 증명된 사례 하나가 조직의 의심을 신뢰로 바꿈.

이때 만든 자산을 재사용 가능하게 묶음.
RAG·평가 파이프라인 · 프롬프트 · 거버넌스 정책을 팀마다 새로 짜지 않고 공유함.
동시에 단위 비용과 한도 모니터링을 켜서, 규모가 커져도 비용이 새지 않게 잡음.

파일럿 성공 → 인접 팀으로 확산
성공 사례 → 인접 팀으로
파일럿 성공 사례
처리 시간 −40% · 정확도 검증 완료
숫자로 증명된 한 건이 조직의 신뢰를 끌어옴
↓ 재사용 자산을 묶어서
A팀
유사 과제
B팀
유사 과제
C팀
유사 과제
팀마다 새로 안 짜고 공유
RAG · 평가 파이프라인
프롬프트 · 템플릿
거버넌스 정책
비용 모니터링
P.04Enterprise LLM · 15

직접 굴려보기 — 게이트를 통과하며

오른쪽에서 직접 단계를 올려 보셈.
체크포인트를 다 채워야 다음 단계 게이트가 열림.

파일럿 단계에선 유스케이스 정의 · 기준값 측정 · 기본 보안 가드를 통과해야 함.
하나라도 비면 확장으로 못 넘어감. 이게 게이트임.

단계가 올라갈수록 통과할 체크가 늘어남.
확장에선 거버넌스 문서화·비용 모니터링이, 전사에선 감사 로그·운영 오너·정기 리뷰가 붙음.
무게가 커지는 만큼 점검도 늘어나는 구조임 — 실무 의사결정도 정확히 이렇게 굴러감.

체크포인트를 채우면 다음 단계가 열림
도입 로드맵 보드 · 체크포인트 통과
진행 단계 — 게이트를 통과해야 넘어감
1단계
파일럿
진행 중
2단계
확장
잠김
3단계
전사
잠김
파일럿0/3 통과

좁은 유스케이스 · 작게 검증

대상 범위
1개 팀 · 1개 과제
사용자 규모
10~30명
체크포인트 — 다 통과해야 다음 단계 열림
체크포인트 3개 더 채워야 넘어감

단계가 올라갈수록 대상·사용자가 커지고, 필요한 거버넌스·운영도 같이 무거워짐. 그래서 한 번에 전사로 안 감 — 작게 검증하고 게이트를 통과하며 키움.

P.05Enterprise LLM · 15

전사 확산 — 거버넌스가 먼저, 확산은 그 위에

전사로 가면 한 번의 실수가 전 직원 규모로 번짐. 그래서 거버넌스가 확산의 전제임.

순서가 중요함. 보안·거버넌스를 깔고 그 위에 확산을 얹음 — 반대로 안 함.
전사 단계의 게이트는 공통 게이트웨이 표준화 · 감사 로그·접근통제 상시화 · 운영 오너와 온콜 · 정기 품질·리스크 리뷰임.

이건 속도를 늦추는 규제가 아니라 규모를 감당하는 토대임.
작게 검증하고 게이트마다 위험과 신뢰를 관리하며 올라왔기에, 전사 확산이 도박이 아니라 다음 한 칸이 됨.
그게 파일럿부터 시작한 전체 이유임.

Q. 사내 LLM 도입을 전사 일괄이 아니라 파일럿부터 하는 이유는? (작게 검증해 위험·신뢰 관리 · 기술이 어려워서 · 모델이 비싸서 · 직원이 반대해서)정답은 작게 검증해 위험·신뢰를 관리하기 위해서임.
좁은 유스케이스로 시작하면 실패해도 피해가 작고, 성공하면 숫자로 증명된 근거가 남음.
그 근거가 다음 단계의 예산과 조직의 신뢰를 끌어옴. 검증 안 된 위험을 전사 규모로 키우지 않으려는 것임.
그래서 파일럿 → 확장 → 전사로 게이트를 통과하며 단계적으로 키움.
단계마다 무거워지는 거버넌스·운영
거버넌스 무게 — 단계마다 무거워짐
파일럿
기본 보안 가드
사내망 · 접근권한
확장
정책 문서화 · 비용 모니터링
사용·금지·책임 · 단위 비용 한도
전사
감사 · 표준 · 운영 체계
감사 로그 · 공통 게이트웨이 · 온콜 · 정기 리뷰

거버넌스를 깔고 그 위에 확산을 얹음 — 반대로 안 함

3줄 요약

  1. 1파일럿에서 전사 확산까지
  2. 2도입 로드맵은 도입 방식 → RAG·연동 → SAP → 보안·거버넌스 → 운영 흐름 안의 한 칸이다.
  3. 3개념을 외우는 것보다 입력을 바꾸면 무엇이 달라지는지 보는 것이 우선이다.

완료 전 점검

복습 카드

도입

파일럿에서 전사 확산까지

RAG

사내 문서를 검색해 답을 보강하는 방식

임베딩

의미를 숫자 벡터로 바꾼 표현