강의와 함께 완성하는 실전 워크북

읽고 끝내지 않기 위한 구성

이 책의 마지막 목표는 지식을 정리하는 데서 멈추지 않는 것입니다. 독자가 자신의 조직 상황을 진단하고, 어떤 AI 워크로드부터 Kubernetes 위에 올릴지 판단하며, PoC 요구사항까지 작성할 수 있어야 합니다.

따라서 전자책은 짧은 강의와 워크북으로 함께 설계하는 것이 좋습니다. 강의는 개념을 압축해 전달하고, 워크북은 독자가 자신의 환경을 숫자와 문장으로 적게 만듭니다. 이 과정에서 자연스럽게 조직의 문제, 제약 조건, 우선순위가 드러납니다.

중요한 점은 이 패키지가 영업 제안서가 아니라는 것입니다. 독자가 "우리에게 지금 필요한 것은 무엇인가"를 정리하도록 돕는 진단 도구에 가깝습니다. 그 결과가 무료 진단, 기술 워크숍, 아키텍처 리뷰로 이어지면 충분합니다.

AI 생성 이미지

10~15분 강의로 압축하는 방법

각 챕터 강의는 세 가지 흐름으로 구성합니다.

1. 핵심 메시지: 이 장에서 반드시 기억해야 할 판단 기준

2. 현장 질문: 조직이 스스로 답해야 하는 질문

3. 워크북 과제: 강의 직후 작성할 산출물

강의가 길어지면 플랫폼 소개나 도구 비교에 치우치기 쉽습니다. 10~15분 강의에서는 "어떤 결정을 내릴 때 이 개념이 필요한가"에 집중해야 합니다.

각 강의의 마지막 슬라이드는 반드시 질문으로 끝내는 것이 좋습니다. 예를 들어 "GPU가 부족한가, 아니면 GPU를 기다리는 방식이 비효율적인가?", "모델 배포가 느린가, 아니면 승인 기준이 불명확한가?"처럼 문제를 구체화하는 질문이 필요합니다.

워크북 1: AI 워크로드 현황 진단표

첫 번째 워크북은 현재 AI 워크로드를 정리하는 표입니다. 여기서 중요한 것은 모든 프로젝트를 자세히 조사하는 것이 아니라, 운영 부담이 큰 대표 워크로드를 빠르게 찾는 것입니다.

다음 항목을 기준으로 작성합니다.

진단표를 작성할 때는 "가장 최신 기술을 적용할 워크로드"가 아니라 "운영 문제가 반복적으로 발생하는 워크로드"를 우선 후보로 삼는 것이 좋습니다. PoC는 멋진 데모보다 반복 가능한 운영 흐름을 증명하는 데 더 큰 가치가 있습니다.

워크북 2: GPU 비용 계산표

GPU 비용은 단순히 인스턴스 단가만으로 판단하기 어렵습니다. 실제로는 할당 시간, 사용률, 대기 시간, 실패 작업, 재실행 횟수가 함께 비용을 만듭니다.

기본 계산표는 다음 항목으로 시작할 수 있습니다.

단순 월 비용은 다음처럼 계산합니다.

GPU 단가 × GPU 개수 × 실행 시간 × 월 실행 횟수 × (1 + 실패·재실행 비율)

하지만 운영 판단에는 한 가지 값을 더 봐야 합니다. 바로 유효 사용 비용입니다. 평균 GPU 사용률이 낮다면, 같은 월 비용을 쓰고도 실제 연산에 쓰인 시간은 적습니다.

유효 사용 비용 = 월 비용 ÷ 평균 GPU 사용률

이때 평균 GPU 사용률은 45%라면 0.45처럼 소수로 넣어 계산합니다. 이 숫자는 비난을 위한 지표가 아닙니다. 어떤 작업을 예약 실행으로 바꿀지, 어떤 추론 서비스를 오토스케일링할지, 어떤 개발 실험에 쿼터를 둘지 논의하기 위한 기준입니다.

워크북 3: 보안 체크리스트

보안 체크리스트는 "운영 전에 한 번 점검하는 문서"가 아니라 PoC 단계부터 적용할 최소 기준입니다. 처음부터 복잡한 통제 체계를 만들 필요는 없지만, 나중에 바꾸기 어려운 기본값은 초기에 정해야 합니다.

체크리스트에서 모든 항목을 완료해야만 PoC를 시작할 수 있는 것은 아닙니다. 다만 운영 전환을 검토하려면 미정 항목이 어떤 위험을 만드는지 설명할 수 있어야 합니다.

미니 실습: 샘플 추론 서비스 배포하기

실습은 너무 많은 도구를 한 번에 다루지 않는 것이 좋습니다. 목표는 "Kubernetes에서 모델 추론 서비스가 어떻게 배포되고, 어떤 지표를 봐야 하는지"를 체감하는 것입니다.

권장 흐름은 다음과 같습니다.

1. 샘플 모델 서버 컨테이너 준비
   간단한 HTTP API를 가진 추론 서버를 사용합니다. 실제 대형 모델이 아니어도 됩니다. 중요한 것은 요청을 받고 응답하며 메트릭을 노출하는 구조입니다.

2. Deployment로 배포
   처음에는 KServe나 고급 서빙 프레임워크를 바로 쓰지 않고, Kubernetes Deployment와 Service로 기본 배포 흐름을 확인합니다.

3. 리소스 요청과 제한 설정
   CPU, 메모리 요청값을 명시합니다. GPU 실습 환경이 있다면 nvidia.com/gpu 요청을 추가합니다. GPU가 없다면 CPU 기반 샘플로도 운영 흐름을 익힐 수 있습니다.

4. Service 또는 Ingress로 호출 경로 구성
   내부 테스트라면 ClusterIP와 포트 포워딩으로 충분합니다. 외부 사용자 테스트가 필요할 때만 Ingress나 API Gateway를 연결합니다.

5. 부하 생성
   간단한 부하 도구로 요청 수를 늘려봅니다. 이때 평균 응답 시간보다 p95 지연 시간, 오류율, 타임아웃을 함께 봅니다.

6. 오토스케일링 지표 확인
   HPA를 사용한다면 CPU나 메모리 기준으로 시작할 수 있습니다. 비동기 추론 구조라면 KEDA와 큐 길이를 기준으로 확장하는 방식을 검토합니다. GPU 추론에서는 GPU 메모리, 동시 요청 수, 큐 대기 시간을 함께 보는 것이 좋습니다.

7. 롤백 시나리오 실행
   새 버전 이미지를 배포한 뒤 오류가 발생했다고 가정하고 이전 버전으로 되돌립니다. 실습의 핵심은 배포 성공이 아니라 되돌릴 수 있는 운영 흐름을 확인하는 것입니다.

실습 결과로는 배포 YAML, 호출 테스트 결과, 지연 시간 그래프, 오토스케일링 조건, 롤백 절차를 남깁니다. 이 다섯 가지가 있으면 단순 데모가 아니라 운영 검토 자료가 됩니다.

제출 가능한 PoC 요구사항 템플릿

강의 수강 후에는 다음 형식으로 PoC 요구사항을 제출할 수 있어야 합니다.

1. 배경과 문제

• 현재 AI 워크로드:

• 현재 실행 환경:

• 반복되는 운영 문제:

• Kubernetes 검토 이유:

2. PoC 범위

• 대상 워크로드:

• 포함할 기능:

• 제외할 기능:

• 사용할 데이터 범위:

• 사용할 모델 또는 샘플 모델:

3. 기술 요구사항

• 실행 방식: Job / CronJob / Deployment / 비동기 Worker

• GPU 필요 여부:

• 스토리지 요구사항:

• 모델 저장소 또는 레지스트리 요구사항:

• 네트워크 노출 방식:

• 인증·권한 요구사항:

4. 성공 기준

• 배포 자동화 기준:

• 추론 지연 시간 또는 처리량 기준:

• GPU 사용률 또는 비용 기준:

• 장애 복구 기준:

• 보안 체크 완료 기준:

• 운영 전환 판단 기준:

5. 제약 조건

• 일정:

• 예산:

• 사용 가능한 인력:

• 클라우드 또는 온프레미스 제약:

• 데이터 반출 제한:

이 템플릿은 완벽한 요구사항 정의서가 아닙니다. 대신 기술 워크숍을 시작할 수 있는 최소 공통 언어입니다. 작성 과정에서 빈칸이 많이 나오면, 그것 자체가 진단 결과입니다.

내부 설득용 1페이지 요약 문서

기술 검토가 내부 의사결정으로 이어지려면 짧은 요약 문서가 필요합니다. 이 문서는 엔지니어만이 아니라 의사결정자도 읽을 수 있어야 합니다.

구성은 다음 정도면 충분합니다.

1. 왜 지금 검토하는가
   GPU 비용 증가, 모델 배포 지연, 운영 장애, 보안 요구 등 현재 압박 요인을 한 문단으로 정리합니다.

2. 무엇을 검증할 것인가
   대표 워크로드 하나를 기준으로 학습, 배포, 추론, 관측, 보안 중 어디까지 확인할지 명시합니다.

3. 성공하면 무엇이 달라지는가
   배포 시간이 줄어드는지, GPU 사용이 설명 가능해지는지, 운영 장애 대응이 쉬워지는지처럼 기대 효과를 구체적으로 씁니다.

4. 무엇은 아직 하지 않는가
   전체 MLOps 플랫폼 구축, 전사 표준화, 모든 모델 이전처럼 범위가 커지는 항목은 제외한다고 명확히 적습니다.

5. 다음 의사결정
   무료 진단, 기술 워크숍, 아키텍처 리뷰, 4주 PoC 중 어떤 단계로 갈지 선택합니다.

이 문서의 목적은 구매를 설득하는 것이 아닙니다. 불확실한 논의를 다음 단계로 옮길 만큼 충분히 구체화하는 것입니다.

리드 전환 동선: 제안보다 진단

B2B 리드 전환은 제품 설명으로 시작하지 않는 편이 좋습니다. 특히 Kubernetes와 AI 워크로드는 조직마다 인프라, 보안, 데이터, 인력 조건이 크게 다릅니다. 따라서 자연스러운 동선은 다음과 같습니다.

1. 전자책 다운로드
   독자는 전체 개념과 도입 판단 기준을 이해합니다.

2. 짧은 강의 수강
   각 챕터의 핵심을 10~15분 단위로 확인하고, 워크북 작성 방법을 익힙니다.

3. 자가 진단표 작성
   AI 워크로드, GPU 비용, 보안 상태, PoC 후보를 스스로 정리합니다.

4. 무료 진단 신청
   작성한 표를 바탕으로 30~60분 정도의 진단 세션을 진행합니다. 이 단계에서는 솔루션 소개보다 문제 구조를 확인합니다.

5. 기술 워크숍
   대표 워크로드를 하나 선택하고 목표 아키텍처, 보안 기준, 비용 지표, PoC 범위를 함께 정의합니다.

6. 아키텍처 리뷰 또는 PoC 제안
   조직이 준비되었다고 판단될 때만 구체적인 PoC 계획으로 넘어갑니다.

이 흐름은 판매 압박을 줄이고, 대신 신뢰를 쌓습니다. 독자는 자신의 문제를 더 정확히 이해하게 되고, 제공자는 실제로 도울 수 있는 범위를 판단할 수 있습니다.

마지막 점검 질문

워크북을 마무리할 때는 다음 다섯 가지 질문에 답해봅니다.

• 우리 조직에서 Kubernetes 위에 올릴 만한 첫 번째 AI 워크로드는 무엇인가?

• 그 워크로드의 가장 큰 병목은 GPU, 배포, 데이터, 보안, 관측 중 어디에 있는가?

• PoC가 성공했다고 말하려면 어떤 숫자나 결과가 필요한가?

• 운영 전환 전에 반드시 해결해야 할 위험은 무엇인가?

• 내부 의사결정자가 읽을 수 있는 1페이지 요약이 준비되었는가?

이 질문에 답할 수 있다면 전자책과 강의의 역할은 충분히 끝난 것입니다. 다음 단계는 더 많은 정보를 읽는 것이 아니라, 작은 범위에서 검증하고 조직의 언어로 결과를 정리하는 일입니다.