스킬캠퍼스

오늘 끝나면

도입 로드맵

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

실습 미션

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

성공 조건

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

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

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

임베딩

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