제6부 생성형 AI 플랫폼

6.1 생성형 AI 라이프사이클 개관

6.1.1 이 장에서 배우는 것 / 선수 지식

제5부(5.1~5.15)에서 우리는 이미 학습된 모델을 최적화·서빙했다 — 추론의 사면체, TensorRT·TRT-LLM·Triton. 이제 한 단계 올라간다. 제6부(생성형 AI 플랫폼)는 그 모델을 어떻게 얻고·자기 것으로 만들고·정렬하고·배포하고·지식과 연결하나 를 다룬다. 이 장은 제6부 전체의 지도 — 생성형 AI 라이프사이클(데이터 → 학습/커스터마이즈 → 정렬 → 배포 → RAG/에이전트)과, 그 각 단계를 채우는 엔비디아 플랫폼 구성요소(NeMo·NIM·NeMo Retriever·Guardrails)의 지형을 세운다.

이 장의 가장 실용적인 결론은 적응 스펙트럼이다: 대부분의 팀은 모델을 처음부터 학습하지 않는다. 프롬프트 → RAG → PEFT(LoRA) → 전체 파인튜닝 → 계속 사전학습 → 처음부터 사전학습 의 사다리에서 필요한 만큼만 올라간다. 비용·제어·데이터 요구가 단계마다 급증하기 때문이다. 이 사다리를 손에 쥐면 "내 문제에 무엇이 맞나"가 정리된다.

배우는 것:

생성형 AI 라이프사이클의 단계와, 각 단계를 채우는 엔비디아 구성요소(NeMo·Curator·NIM·Retriever·Guardrails).
적응 스펙트럼 — 프롬프트·RAG·LoRA·파인튜닝·사전학습의 비용·제어·데이터 트레이드오프와 "언제 무엇을".
라이프사이클이 이전 부와 어떻게 연결되나 — 학습은 병렬화(4.14), 배포는 TRT-LLM·Triton·NIM(5.7~5.15).
제6부 장들(6.2~6.11)의 로드맵 — NeMo I~IV, Curator, NIM I~II, RAG I~II, 가드레일·에이전트.
의사결정 워크스루 — 유스케이스를 받아 라이프사이클 경로를 고르기.

선수 지식: 5.1(추론 사면체·배포 선택 — 라이프사이클의 배포 단계), 5.7~5.15(TRT-LLM·Triton·NIM — 배포 계층), 4.14(병렬화 — 학습 단계), 1.14·5.4~5.5(정밀도·양자화 — 효율). 이 장은 개관이라 코드보다 지형·의사결정 중심.

정직: 엔비디아 생성형 AI 플랫폼은 명칭·구성·통폐합이 매우 잦다(NeMo·NIM·NeMo Retriever·NeMo Guardrails 등의 범위·이름이 리브랜딩됨). 이 장은 변하지 않는 라이프사이클 구조·적응 스펙트럼·의사결정을 가르치고, 제품명은 "그 시점 명칭, 확인 필요"로 다룬다. 구체 기능·가용성은 그 시점 공식 문서로 확인("시점 의존").

6.1.2 생성형 AI 라이프사이클 — 큰 그림

생성형 AI 시스템은 한 번의 학습이 아니라 순환하는 라이프사이클이다:

단계별 한 줄(어느 장에서 깊어지나):

① 데이터 큐레이션 — 대규모 텍스트·멀티모달 데이터를 수집·정제·중복제거·품질 필터·개인정보 처리. 모델 품질의 8할이 데이터. → NeMo Curator(6.6).
② 학습/커스터마이즈 — 사전학습(드묾)·SFT(지도 미세조정)·PEFT(LoRA 등) 로 모델을 자기 도메인에 맞춤. 대규모는 병렬화(4.14). → NeMo(6.2~6.4).
③ 정렬(alignment) — 사람 선호·정책에 맞게(RLHF·DPO 등). 유용성·안전성·형식. → NeMo(6.5).
④ 최적화·배포 — 학습된 모델을 양자화·엔진화(TRT-LLM)·서빙(Triton)·마이크로서비스화(NIM). → 5.7~5.15, NIM 6.7~6.8.
⑤ 지식 연결·에이전트 — 모델을 외부 지식(RAG)·도구·정책(가드레일)과 연결. → Retriever 6.9~6.10, 가드레일·에이전트 6.11.
순환 — 운영에서 모은 피드백·실패 사례로 데이터·정렬을 갱신(MLOps, 제7부 7.7).

핵심: 이 라이프사이클은 선형이 아니라 순환이다. 대부분의 가치는 ④⑤(배포·RAG)에서 빠르게 나오고, ②③(학습·정렬)은 필요할 때 투자한다. 그리고 운영 피드백이 다시 데이터·정렬로 돌아간다.

6.1.3 적응 스펙트럼 — 필요한 만큼만 올라간다

제6부에서 가장 중요한 의사결정 도구. 모델을 "내 것"으로 만드는 방법은 비용·제어가 점증하는 사다리다.

왼쪽에서 오른쪽으로 갈수록 비용·데이터·제어가 증가한다.

각 단계의 본질·언제:

방법	무엇을	언제	비고
프롬프트 엔지니어링	가중치 그대로, 입력만 설계	일반 능력으로 충분, 빠른 시작	가장 비용이 낮고 즉시. few-shot·시스템 프롬프트
RAG	외부 지식을 검색해 문맥 주입	최신·사실·사내 지식 필요	가중치 안 바꿈, 지식 갱신 쉬움(6.9~6.10)
PEFT(LoRA)	소수 어댑터만 학습	스타일·형식·도메인 적응, 데이터 적당	저렴·빠름·여러 어댑터(6.4)
전체 파인튜닝(SFT)	전체 가중치 학습	깊은 행동 변화·LoRA로 부족	비용이 크고 데이터 필요(6.4)
계속 사전학습	대규모 도메인 코퍼스로 추가 사전학습	새 도메인·언어 깊이	매우 비쌈, 큰 코퍼스
처음부터 사전학습	밑바닥부터	파운데이션 제공자·특수 요구	극히 비쌈(4.14 병렬·6.3)

견해: 아래에서 시작해 필요한 만큼만 올라가라. 대부분의 실무 문제는 프롬프트 + RAG로 풀리고(지식·사실), 스타일·형식·도메인 어조가 필요하면 LoRA, 그래도 부족한 깊은 행동 변화에만 SFT. 계속 사전학습·처음부터는 데이터·컴퓨트가 막대해 소수만. "파인튜닝부터" 또는 "우리 모델을 처음부터"는 대개 과투자다 — RAG로 풀 수 있는 것을 파인튜닝으로 풀지 말 것(6.1.6).

6.1.4 엔비디아 플랫폼 지형

라이프사이클 각 단계를 채우는 엔비디아 구성요소(명칭·범위는 시점 의존):

NeMo: 학습·커스터마이즈·정렬의 프레임워크(데이터 Curator, 학습 PEFT/SFT, 정렬 RLHF/DPO). 대규모 병렬(4.14·6.3)을 누린다.
NIM: 학습된(또는 기성) 모델을 TRT-LLM/Triton으로 최적화해 OpenAI 호환 마이크로서비스로 패키징 — 제5부의 배포 스택을 "완제품 API"로 감싼 것(6.7~6.8).
NeMo Retriever: RAG의 검색 구성요소(임베딩·리랭킹·벡터DB 연결) — 6.9~6.10.
NeMo Guardrails: 입출력 안전·정책·주제 제한·에이전트 흐름 제어 — 6.11.

핵심: 이 구성요소들은 라이프사이클 단계에 매핑된다. 제6부는 이를 단계 순서(데이터→학습→정렬→큐레이션→배포→RAG→가드레일)로 판다. 명칭은 바뀌어도 단계와 역할은 안정적이다.

6.1.5 이전 부와의 연결 — 라이프사이클은 책 전체를 묶는다

생성형 AI 라이프사이클은 앞에서 배운 것들이 제자리를 찾는 틀이다:

라이프사이클 단계	연결되는 이전 부·장
① 데이터 큐레이션	GPU 가속 데이터 처리(3.8 데이터 로딩, CUDA 2.1~2.16)
② 학습	병렬화 TP/PP/DP(4.14), 텐서코어·정밀도(1.11~1.14), NCCL(4.13)
③ 정렬	학습의 한 형태(보상모델·강화학습), 같은 인프라
④ 배포	TRT-LLM·Triton·NIM(5.7~6.8), 양자화(5.4~5.5), KV·배칭(5.8)
⑤ RAG·에이전트	추론 엔드포인트 + 검색(임베딩도 추론, Triton 5.11)

즉 제1~4부(컴퓨팅·CUDA·라이브러리·스케일)는 ①②의 토대, 제5부(추론)는 ④의 핵심, 제6부는 이들을 생성형 AI 워크플로로 조립한다. 그래서 5.1의 사면체·5.7의 KV·6.7의 NIM이 여기서 다시 등장한다.

6.1.6 워크스루 — 라이프사이클 경로 선택

유스케이스를 받아 적응 스펙트럼에서 경로를 고르는 워크스루.

시나리오 A — 사내 문서 Q&A 봇.

   요구: 사내 위키·매뉴얼의 '사실'을 정확히 답. 문서가 자주 갱신됨.
   분석: 지식이 핵심이고 자주 변함 → 가중치에 욱여넣으면 갱신 때마다 재학습(낭비)
   경로: 프롬프트 + RAG(6.9~6.10). 문서를 임베딩·검색해 문맥 주입.
        파인튜닝 불필요(지식은 검색으로). 가드레일로 범위 제한(6.11).
   배포: 기성 모델 NIM(6.7) + NeMo Retriever.

시나리오 B — 특정 어조·형식의 고객 응대.

   요구: 회사 톤·정해진 응답 형식(JSON·정중체)으로 일관 응대. 사실은 RAG로.
   분석: '스타일·형식' 적응이 필요 → 프롬프트로 부족하면 경량 학습
   경로: LoRA(PEFT, 6.4)로 어조·형식 학습 + RAG(사실) + 구조적 출력.
        전체 파인튜닝까지 갈 필요 보통 없음. 여러 어조는 어댑터 여러 개.

시나리오 C — 전문 도메인(의료·법률) 깊은 추론.

   요구: 일반 모델이 모르는 전문 추론·용어. RAG로도 부족한 '능력'.
   분석: 깊은 행동·지식 변화 → SFT(전체 파인튜닝), 데이터 충분하면
   경로: 도메인 SFT(6.4) + 정렬(6.5) + RAG(최신 사실) + 가드레일(안전).
        데이터·컴퓨트 큼. 그래도 처음부터 사전학습은 거의 불필요(기성 모델 위에).

시나리오 D — 새 언어·도메인의 파운데이션 모델.

   요구: 기존 모델이 약한 언어·도메인을 깊이. 대규모 코퍼스 보유.
   경로: 계속 사전학습(6.3) + SFT + 정렬. 큰 투자. NeMo 병렬화(4.14).
        '처음부터'는 파운데이션 제공자급 자원이 있을 때만.

결정 축:

질문	"예"면
필요한 것이 '최신·사실 지식'인가?	RAG(가중치 안 건드림)
'스타일·형식·어조' 적응인가?	LoRA(PEFT)
'깊은 능력·행동' 변화인가?	SFT(전체 파인튜닝)
새 언어·도메인을 밑바닥부터?	계속/처음부터 사전학습(소수)
안전·정책·범위 제한 필요?	가드레일(어느 경로든 추가)

견해: "RAG로 풀 수 있으면 RAG, 스타일이면 LoRA, 그 이상만 SFT." 가장 흔한 실수는 지식 문제를 파인튜닝으로 푸는 것 — 비용이 크고, 지식이 굳어 갱신이 어렵고, 환각도 안 준다. 지식은 검색(RAG)으로, 행동·스타일은 학습으로 — 이 구분이 핵심.

6.1.7 중간 점검 (체크포인트)

[ ] 생성형 AI 라이프사이클 5단계(데이터·학습·정렬·배포·RAG/에이전트)와 각 단계의 엔비디아 구성요소를 제시한다.
[ ] 적응 스펙트럼(프롬프트→RAG→LoRA→SFT→계속/처음 사전학습)의 비용·제어·데이터 트레이드오프를 설명한다.
[ ] 유스케이스를 받아 적절한 경로를 고르고(특히 지식=RAG vs 스타일=LoRA vs 능력=SFT), 근거를 제시한다.
[ ] 라이프사이클이 이전 부(학습=4.14 병렬, 배포=5.7~5.15)와 어떻게 연결되는지 안다.
[ ] NeMo·Curator·NIM·Retriever·Guardrails가 어느 단계를 채우는지 매핑한다.

증상→의심: 파인튜닝했는데 지식이 안 늘고 환각 → 지식 문제를 학습으로 푼 오류 → RAG로. RAG인데 어조·형식이 일관되지 않음 → 스타일은 검색으로 안 됨 → LoRA·프롬프트. LoRA로 부족한 깊은 추론 → 능력 변화 필요 → SFT. 재학습 비용 폭발 → 처음부터/계속 사전학습 과투자 → 기성 모델 위 적응으로. 배포 방법이 불명확 → 제5부(TRT-LLM·Triton·NIM) 연결(6.7).

6.1.8 트레이드오프·대안

커스터마이즈 전략 선택.

전략	누구에게	비용	비고
프롬프트만	일반 능력 충분·빠른 시작	최저	즉시, 제어 약
RAG	최신·사실·사내 지식	낮음(인프라)	지식 갱신 쉬움, 가중치 불변
LoRA(PEFT)	스타일·형식·도메인 어조	중	빠름·여러 어댑터·저장 작음
SFT	깊은 행동·능력	높음	데이터·컴퓨트, 모델 1벌
계속 사전학습	새 언어·도메인 깊이	매우 높음	큰 코퍼스
처음부터	파운데이션 제공자	극히 높음	거의 불필요(대부분)

견해: RAG + 프롬프트가 1차 선택, LoRA가 스타일·도메인 적응의 가성비 지점, SFT는 그 이상만. 기성 오픈웨이트·상용 API를 출발점으로 삼아 위에서 적응하는 것이 거의 항상 합리적이다. 사전학습은 데이터·자원·전문성이 갖춰진 소수의 일. 그리고 어느 경로든 가드레일·평가·관측을 붙인다(6.11·7.7).

비엔비디아 정직: 이 라이프사이클·적응 스펙트럼은 엔비디아 고유가 아니라 생성형 AI의 일반 패턴이다. NeMo·NIM 대신 다른 학습 프레임워크(HF Transformers·Axolotl·PyTorch Lightning), 다른 RAG 스택(LangChain·LlamaIndex), 다른 서빙(vLLM, 5.15)으로도 같은 라이프사이클을 순환한다. 엔비디아의 강점은 GPU 가속·대규모 병렬(NeMo)·최적 배포(TRT-LLM/NIM)·엔드투엔드 통합이다. 구성요소는 교체할 수 있으니 단계와 의사결정을 이해하는 것이 본질.

6.1.9 흔한 함정

지식 문제를 파인튜닝으로. 최신·사실 지식은 RAG로. 파인튜닝은 비용이 크고 지식이 굳어 갱신이 어렵고 환각을 안 준다.
처음부터/계속 사전학습 과투자. 대부분은 기성 모델 위 적응으로 충분. 사전학습은 데이터·자원이 갖춰진 소수.
스타일을 RAG로. 어조·형식은 검색으로 안 된다 — LoRA·프롬프트. 지식과 스타일을 혼동 말 것.
사다리를 건너뜀. 프롬프트·RAG를 안 해보고 바로 SFT → 과투자. 아래에서 위로 필요한 만큼.
가드레일·평가 생략. 어느 경로든 안전·평가·관측이 없으면 production 부적합(6.11·7.7).
제품명에 매몰. NeMo·NIM 명칭이 바뀌어도 단계·역할은 같다. 라이프사이클을 본다.
배포를 나중 생각. 학습만 하고 배포(TRT-LLM·NIM·서빙)를 안 그리면 운영 단계에서 차단된다 — 제5부와 연결.
데이터 품질 경시. 모델 품질은 데이터가 좌우(②의 8할은 ①). 큐레이션(6.6)을 과소평가하지 말 것.

6.1.10 연습문제

연습 1 (경로 선택). 다음 각각에 프롬프트/RAG/LoRA/SFT/사전학습 중 무엇을 권하나: (a) 사내 HR 정책 Q&A(정책 분기마다 갱신), (b) 항상 정해진 JSON 스키마로 답하게, (c) 기존 모델이 약한 소수 언어의 전반 능력 향상, (d) 회사 브랜드 어조로 마케팅 카피.

정답

(a) RAG — 정책은 사실·지식이고 자주 갱신되므로 검색으로 최신 문서를 문맥 주입(가중치 불변, 갱신 쉬움). 파인튜닝하면 갱신마다 재학습. (b) LoRA + 구조적 출력/프롬프트 — 출력 '형식'은 스타일 적응 → 경량 학습 또는 문법 제약 디코딩. (c) 계속 사전학습 + SFT — '언어 전반 능력'은 깊은 변화라 대규모 도메인/언어 코퍼스로 계속 사전학습 후 SFT·정렬. 큰 투자. (d) LoRA(또는 프롬프트) — '브랜드 어조'는 스타일이라 LoRA로 학습하거나 잘 만든 시스템 프롬프트로. SFT까지 보통 불필요. 모두 가드레일·평가 병행.

연습 2 (지식 vs 스타일). "우리 제품 매뉴얼로 모델을 파인튜닝했는데 새 버전 정보를 못 답하고 환각한다"는 문제를 진단하고 올바른 접근을 제시하라.

정답

진단: 지식 문제를 파인튜닝으로 푼 오류. 파인튜닝은 ① 학습 시점 지식을 가중치에 굳혀 새 버전 정보를 모르고(재학습 전까지), ② 사실을 명시적으로 검증·인용하지 못해 환각을 안 줄이며, ③ 갱신마다 재학습 비용이 든다. 올바른 접근: RAG(6.9~6.10) — 매뉴얼을 임베딩·검색해 최신 문서를 문맥으로 주입, 모델은 그 근거로 답하고 출처 인용. 매뉴얼이 갱신되면 인덱스만 갱신(재학습 불필요). 어조·형식이 필요하면 그 부분만 LoRA. 지식=검색, 스타일=학습의 구분이 핵심.

연습 3 (사다리). 한 팀이 곧장 "우리 도메인 모델을 처음부터 사전학습"하려 한다. 이를 말리고 더 낮은 단계부터 검토하도록 설득하는 논거를 비용·데이터·시간 관점에서 제시하라.

정답

논거: ① 비용·컴퓨트: 처음부터 사전학습은 막대한 GPU·시간·전문성(4.14 대규모 병렬)이 필요 — 파운데이션 제공자급. ② 데이터: 양질의 대규모 코퍼스가 있어야 하고 큐레이션(6.6)만도 큰 일. ③ 시간·위험: 몇 달, 실패 위험 큼. 대안 사다리: 프롬프트·RAG로 먼저 얼마나 풀리는지 본다(대개 상당). 부족한 스타일·도메인 어조는 LoRA, 깊은 능력은 SFT, 그래도 도메인 코퍼스가 크고 언어가 근본적으로 약하면 계속 사전학습(기성 모델 위). '처음부터'는 이 모든 것이 불충분하고 자원이 갖춰진 극소수에만. 기성 오픈웨이트 위에서 적응하면 비용·시간·위험을 1~2자릿수 줄인다.

연습 4 (라이프사이클 연결). 사내 코드 어시스턴트를 만든다. 라이프사이클 5단계 각각에서 무엇을 하고 어느 엔비디아 구성요소·이전 장이 관여하는지 매핑하라.

정답

① 데이터: 사내 코드·문서 수집·정제·라이선스/시크릿 필터 → NeMo Curator(6.6), GPU 데이터 처리(3.8). ② 학습/커스터마이즈: 기성 코드 모델에 사내 코드 스타일·라이브러리 적응 → LoRA(6.4), 부족하면 SFT. 대규모면 병렬(4.14). ③ 정렬: 안전·정확·형식 선호로 정렬 → DPO 등(6.5). ④ 배포: 양자화·엔진(TRT-LLM 5.7~5.9)·서빙(Triton 5.11~5.14)·마이크로서비스(NIM 6.7~6.8). ⑤ RAG·에이전트: 사내 코드베이스·문서를 검색 주입(6.9~6.10), 도구 호출(테스트 실행)·가드레일(시크릿·취약 코드 차단, 6.11). 순환: 사용 로그·실패로 데이터·정렬 갱신(7.7). 대부분 가치는 ④⑤(배포+RAG)에서, 스타일만 ②.

연습 5 (구성요소 중립성). 이 라이프사이클을 엔비디아 NeMo/NIM 없이 다른 도구로 실행된다면 각 단계를 무엇으로 대체할 수 있는지 예를 들고, 그래도 변하지 않는 것은 무엇인지 답하라.

정답

대체 예: ① 데이터 큐레이션 = 자체 파이프라인·오픈 도구. ② 학습/PEFT = HF Transformers·PEFT·Axolotl·PyTorch Lightning. ③ 정렬 = TRL(RLHF/DPO) 등. ④ 배포 = vLLM/SGLang(5.15)·Triton·자체 서버. ⑤ RAG = LangChain·LlamaIndex + 오픈 벡터DB·임베딩 모델, 가드레일 = 오픈 가드레일 라이브러리. 변하지 않는 것: 라이프사이클 단계와 순서(데이터→학습→정렬→배포→RAG/에이전트), 적응 스펙트럼(프롬프트→RAG→LoRA→SFT→사전학습)의 의사결정, 지식=RAG·스타일=학습 구분, GPU 가속·병렬화의 물리. 엔비디아 스택의 가치는 GPU 가속·대규모 병렬·최적 배포·엔드투엔드 통합이지, 라이프사이클 자체는 도구 중립이다. 그래서 단계와 의사결정을 이해하는 것이 본질.

6.1.11 요약 · 다음 장

생성형 AI는 순환하는 라이프사이클 — ① 데이터 큐레이션 ② 학습/커스터마이즈 ③ 정렬 ④ 최적화·배포 ⑤ RAG·에이전트, 그리고 운영 피드백으로 순환. 대부분 가치는 ④⑤에서 빠르게, ②③은 필요할 때.
적응 스펙트럼: 프롬프트 → RAG → LoRA → SFT → 계속/처음 사전학습. 비용·제어가 점증 — 필요한 만큼만 올라간다. 핵심 구분: 지식=RAG, 스타일=LoRA, 깊은 능력=SFT.
엔비디아 플랫폼이 단계를 채운다: NeMo(학습·정렬)·Curator(데이터)·NIM(배포)·Retriever(RAG)·Guardrails(안전). 명칭은 바뀌어도 단계·역할은 안정적.
라이프사이클은 책 전체를 묶는 틀 — 학습은 병렬화(4.14), 배포는 TRT-LLM·Triton·NIM(5.7~5.15). 제6부는 이를 워크플로로 조립.
정직: 제품명·구성은 리브랜딩 잦음(확인 필요), 라이프사이클·의사결정은 도구 중립, 어느 경로든 가드레일·평가·관측을 붙인다.

다음 장: 6.2 NeMo I — 프레임워크 구조·데이터. 라이프사이클의 ②(학습/커스터마이즈)로 들어간다. NeMo 프레임워크의 구성(모델·데이터·학습 루프), 대규모 학습을 위한 데이터 경로(토크나이즈·인덱싱·셔플), 그리고 다음 장(6.3)의 병렬화로 이어지는 구조를 본다.