AI,Blog,LLM

TL;DR — LLM은 구글의 2017년 Transformer 논문에서 출발해 다음 단어를 확률적으로
예측하는 대규모 언어 모델입니다. Claude·Gemini·ChatGPT는 프론티어 모델, 설치해 쓰는 것은
오픈소스 모델이라 부르며, 설치형은 CUDA 생태계 때문에 NVIDIA GPU가 사실상 표준입니다.

• LLM 도입의 출발점은 용어 정리다 — 생성형 AI와 LLM과 sLLM은 대등한 선택지가 아니라 포함 관계이고, 셋은 서로 다른 예산안을 요구한다
• 프론티어 모델을 부를지 오픈소스 LLM을 사내에 올릴지가 LLM 도입 비용 구조를 통째로 가른다
• 2026년 기업 소프트웨어의 40%가 에이전트형 AI를 갖춘다는 전망(Gartner)과 추론 단가 10분의 1 하락이 도입 논의를 앞당겼다
• GPU 장수는 모델 크기의 함수가 아니라 피크 동시 요청 × 컨텍스트 길이 × 목표 응답시간의 함수다
• NVIDIA 지배의 근거는 칩 성능이 아니라 CUDA 생태계다 — AMD·클라우드 TPU는 생태계 비용을 감수할 수 있을 때만 성립한다
• 총소유비용은 구매가가 아니라 3년치 전력·공간·인건비에서 갈린다. 민감 데이터만 설치형으로 내리는 2계층 구성이 대부분의 조직에 현실적이다

LLM(Large Language Model) 은 대규모 언어 모델의 약자로, 수천억 단어 규모의 텍스트를 학습해 다음 토큰을 확률로 예측하는 신경망이다. 사전에서 답을 찾아오는 검색과 달리 토큰을 하나씩 만들어 내기 때문에 생성형 AI의 대표 계열로 분류된다. 같은 계열 안에서 sLLM(small language model)은 수십억 파라미터 규모로 특정 도메인에 맞춰 학습한 모델을 가리킨다. LLM이 범용 두뇌라면 sLLM은 한 부서 업무에 맞춘 전담 두뇌다.

세 용어의 관계는 계층으로 정리하면 예산 논의가 쉬워진다. AI 안에 생성형 AI가 있고, 그 안에 LLM이 있으며, LLM의 경량·특화 판이 sLLM이다. “생성형 AI를 해야 한다”와 “LLM을 도입한다”는 결재 서류가 다르다. 생성형 AI는 이미지·음성 생성까지 포함하는 범위라 도구 구매에 가깝고, LLM은 텍스트 추론 인프라를 전제하므로 설비 투자에 가깝다. 논의의 대상을 LLM으로 좁히는 순간부터 GPU 대화가 성립하고, 그때 비로소 LLM 도입이 설비 계획이 된다.

그림 1. LLM · 생성형 AI · sLLM — 개념의 중첩 구조

동작은 세 단계다. 입력을 벡터로 바꾸는 임베딩, 어텐션이 토큰 사이의 관계를 계산하는 추론, 확률 분포를 다시 문장으로 되돌리는 디코딩이다. 어텐션 덕분에 모델은 문장 전체를 동시에 참조하지만 그 범위는 컨텍스트 창이라는 상한에 묶인다. 128K 토큰 모델이 500쪽짜리 문서를 통째로 “읽지” 못하는 이유가 여기 있다. 창에 넣는 것과 창을 유지하는 것은 비용이 다르기 때문이다. 이 차이를 모르고 컨텍스트 사양만 보고 장비를 계약하면, 실제 트래픽에서 응답이 느려지고 추가 구매 품의가 반년 만에 다시 올라온다.

LLM 도입 판단에서 정작 중요한 구분은 모델의 성능이 아니라 어디에 두느냐다. Claude·Gemini·ChatGPT처럼 공급사가 운영하는 모델을 부르는 방식이 프론티어 모델이고, 공개된 가중치를 받아 사내에 올리는 방식이 오픈소스 LLM, 즉 설치형 오픈소스 모델이다. 앞은 초기 비용이 없고 성능이 앞서지만 프롬프트가 사외로 나간다. 뒤는 데이터가 사내에 남지만 GPU와 운영 인력이 필요하다. LLM 도입에서 이 선택이 이후 모든 숫자를 결정한다.

지금이 LLM 도입 시점인지 묻는다면 근거는 정서가 아니라 가격 곡선이다. Stanford HAI의 AI Index 집계 기준으로 동급 성능 추론의 토큰당 단가는 2023년 대비 10분의 1 수준으로 내려왔다. 같은 예산으로 시범 사업이 아니라 실트래픽을 감당하는 구간이 열렸다는 뜻이다. 2026년 LLM 도입 논의의 변화는 모델이 똑똑해진 것이 아니라, 예산안에서 다루는 항목이 “모델을 살까”에서 “토큰 단가가 얼마인가”로 옮겨 간 것이다.

두 번째 변화는 사용 형태다. Gartner는 2026년 기업 소프트웨어의 40%가 에이전트형 AI 기능을 갖출 것으로 전망했다. 에이전트는 추론과 도구 호출을 반복하기 때문에 같은 업무라도 토큰 소모가 단순 챗봇의 몇 배에 이른다. 외부 모델 요금으로 그 비용을 먼저 경험한 조직이 자체 추론으로 눈을 돌리는 흐름이 여기서 생긴다. 세 번째는 규제다. 데이터 주권 요구가 강해지면서 외부로 보낼 수 없는 데이터가 늘었고, 그만큼 설치형 수요가 커졌다.

그러나 수요 확대의 부담은 그대로 GPU로 전가된다. NVIDIA GTC 2026 기조연설은 에이전트 워크로드가 추론 수요를 끌어올렸다는 점을 전면에 세웠고, AI 인프라 시장의 대부분을 한 공급사가 차지하고 있다는 통계가 반복 인용되는 것도 같은 맥락이다. 결론은 단순하다. 2026년의 LLM 도입 검토는 모델 평가와 인프라 계산을 동시에 진행해야 하며, 둘 중 하나만 끝난 품의서는 반드시 되돌아온다.

LLM 도입에서 GPU 산정은 세 변수에서 시작한다. 모델 파라미터 수, 서빙할 피크 동시 요청 수, 목표 응답시간이다. 70B 모델을 FP16으로 올리면 가중치만 140GB, FP8로 줄여도 KV 캐시와 오버헤드를 합치면 H100 3~4장이 한 세대의 마지노선이다. 동시 요청이 늘면 캐시가 메모리를 먹고 장수가 계단식으로 뛴다. “70B니까 2장” 같은 산수가 대부분 틀리는 지점이 여기다.

그림 2. GPU 몇 장인가 — 결정 나무

사양표에서 먼저 볼 숫자는 연산 성능이 아니라 메모리 대역폭이다. 응답을 한 토큰씩 만들어 내는 디코딩 구간은 메모리 대역폭에 묶여 있어서, 체감 속도가 대역폭에 거의 비례한다. 아래 표는 도입 검토에서 실제로 비교하게 되는 세 세대의 차이다.

같은 세대 안에서도 여러 장을 하나의 메모리처럼 묶는 연결 방식(NVLink)이 있느냐에 따라 대형 모델 단일 서빙 성능이 갈린다. 다만 표의 숫자는 후보를 좁히는 용도이지 결재 근거가 아니다. 정확한 장수는 벤치마크로 확정한다. MLPerf Inference는 같은 기준으로 측정한 GPU별 처리량을 공개하고, vLLM 같은 추론 엔진은 KV 캐시를 정리해 같은 하드웨어에서 처리량을 크게 끌어올린다. 같은 H100 8장도 엔진 설정에 따라 두 배 차이가 난다. LLM 도입에서는 하드웨어보다 추론 엔진을 먼저 고르는 편이 싸다.

LLM 도입의 총소유비용은 하드웨어 가격이 아니라 운영 기간의 전기·공간·인건비로 결정된다. 그리고 NVIDIA를 고르는 근거는 칩 성능이 아니라 CUDA 생태계다. 주요 추론 엔진과 최적화 도구가 NVIDIA를 1순위로 지원하기 때문에, 같은 문제를 푸는 데 드는 사람의 시간이 다르다. 이 시간이 3년치 인건비로 환산되면 하드웨어 할인폭을 넘어서는 경우가 많다.

계산의 분기점은 월 추론량이다. 설치형 8장 구성의 3년 총소유비용이 외부 모델 요금을 넘어서는 지점은 트래픽이 일정 수준을 넘길 때이고, 그 아래에서는 외부 모델이 거의 항상 싸다. 설치형으로 비용을 줄인 사례들은 단가를 깎은 것이 아니라 모델 크기를 줄여 필요한 장비를 줄인 쪽이다. sLLM이 총소유비용 논의에서 반복 등장하는 이유가 그것이다.

그래서 현실적인 절충은 하이브리드 2계층이다. 규제·기밀 때문에 밖으로 못 내보내는 트래픽만 설치형 sLLM으로 처리하고, 나머지 범용 작업은 외부 모델에 맡긴다. 이렇게 하면 GPU를 전체 트래픽이 아니라 민감 트래픽만 기준으로 계산하면 되므로 장수부터 줄어든다. 반대로 LLM 도입을 GPU 구매로 시작하면 이 계산 자체가 사라진다. 순서를 트래픽 추정 → 모델 결정 → GPU 산정으로 고정하는 것이 예산을 지키는 가장 확실한 방법이다.

모델을 고르는 일과 업무에 쓰는 일은 다른 문제다. LLM 도입의 다음 관문이 여기다. 사내 지식을 모델에 붙이는 방식은 세 갈래다. 프롬프트 엔지니어링은 가중치를 건드리지 않고 지시문으로 행동을 고친다. 비용은 거의 0이지만 사내 문서는 여전히 모른다. RAG(Retrieval-Augmented Generation)는 검색으로 찾아온 문서를 질문과 함께 넣어 답변의 근거로 삼는다. 파인튜닝은 가중치 자체를 갱신해 말투·출력 형식·도메인 습관을 몸에 익힌다.

그림 3. RAG vs 파인튜닝 — 지식 접목 방식의 선택

선택 기준은 데이터의 성격이다. 수시로 바뀌는 사내 문서를 묻는 업무라면 RAG가 정답이다. 문서를 갈아 끼우면 되고 답변에 출처를 붙일 수 있어 감사 대응도 된다. 반대로 정해진 형식의 보고서를 만드는 일처럼 행동 패턴이 문제라면 파인튜닝이 짧고 싸게 끝난다. 둘은 경쟁 관계가 아니라 순서 문제이고, RAG 없이 파인튜닝부터 시작한 조직은 낡은 지식에 말투만 매끄러운 시스템을 갖게 된다. 환각을 줄이는 효과도 RAG 쪽이 크다.

혼합 구성에서 주의할 것은 비용이 아니라 지연이다. 검색이 앞에 붙으면 응답시간에 검색 시간이 더해지고, 넣는 문서가 길수록 추론 시간도 늘어난다. 첫 응답까지 몇 초라는 체감 상한을 지키려면 검색 병렬화와 응답 캐시를 설계 단계에서 넣어야 한다. 반복 질의가 많은 사내 도메인에서는 캐시 하나가 호출량을 눈에 띄게 줄인다.

LLM 도입 전에 결재선에서 확인해야 할 리스크는 네 가지다. 첫째 환각 — 모델은 모르는 것을 그럴듯하게 지어낸다. 금융·의료처럼 오답 비용이 큰 영역은 출처 없는 답변을 막는 정책이 기술보다 먼저다. 둘째 데이터 유출 — 외부 모델로 나가는 질문은 사실상 사외 반출이다. 개인정보와 설계 자료가 질문에 섞이지 않도록 걸러 내는 장치와 기록 보존 정책을 함께 점검해야 한다.

그림 4. LLM 도입 리스크 네 가지 — 위험과 그 통제 수단

셋째 벤더 종속 — 한 모델에 맞춰 다듬은 지시문과 평가 자료는 모델을 바꾸는 순간 폐기물이 된다. 여러 모델에서 그대로 도는 중간 계층을 두면 이탈 비용이 내려간다. 넷째 비용 폭주 — 에이전트형 업무는 스스로 루프를 돌며 토큰을 태운다. 사용자별·업무별 상한과 이상 사용량 알림을 도입 첫 달에 켜 두지 않으면, 첫 청구서를 보고 나서야 알게 된다.

LLM 도입 이후의 리스크는 관측으로만 관리된다. 질문과 응답, 토큰 수와 비용, 지연을 기록으로 남기는 LLM 관측 체계는 선택이 아니라 1단계 항목이다. 기존 애플리케이션 성능 관리가 요청 단위를 추적한다면, LLM 관측은 세션과 호출 단위를 추적한다. 이 데이터가 없으면 다음 예산안에서 “잘 되고 있다”는 감상 외에 제출할 것이 없다.

LLM 도입의 권장 타임라인은 세 관문이다. 30일 차까지는 외부 모델로 업무 두세 개에 시범 적용하고 사용량과 실패 사례를 모은다. 이 단계에서 GPU는 사지 않는다. 사용량 데이터 없이 산정한 장수는 LLM 도입 회의에서 본 세 배 격차를 그대로 재현한다. 90일 차까지는 시범 트래픽으로 설치형 서빙을 검증하고, 실측값을 공개 벤치마크 수치와 대조해 사양표의 허수를 걸러낸다.

180일 차에는 본서비스 전환과 함께 평가 체계를 고정한다. 고정 평가 자료 기준 정확도, 환각률, P95 지연, 토큰당 비용 네 가지를 주간 보고 지표로 올린다. 지표 없는 도입은 “잘 되는 것 같다”로 끝나고, 다음 예산안에서 감 논쟁이 처음부터 다시 시작된다. LLM 도입의 성패는 모델 선택이 아니라 이 네 숫자의 운영에서 갈린다.

그림 5. 30일 · 90일 · 180일 — 도입 타임라인과 검증 단계

기준선은 시범 단계에서 나온다. 사내 정답 기준 RAG 정확도, 체감 상한 이내의 P95 첫 응답 지연, 업무가 허용하는 오차 이내의 환각률을 각각 숫자로 적어 둔다. 180일 관문에서 네 숫자가 채워지지 않았다면 전환을 미루는 것이 정답이다. 관문을 통과하지 못한 시스템을 본서비스로 올리는 비용이, 6개월을 더 쓰는 비용보다 언제나 크다.

LLM이라는 용어는 생성형 AI와 같은 말인가요?

엄밀히는 다릅니다. 생성형 AI는 텍스트·이미지·음성을 만들어 내는 AI 전체를 가리키고, LLM은 그중 텍스트를 다루는 언어 모델 계열입니다. 인프라 관점에서는 LLM 도입이 GPU 추론을 전제한다는 점에서 예산 항목이 달라지므로, 품의서에서는 두 용어를 구분해 쓰는 편이 안전합니다.

GPU는 몇 장부터 시작해야 하나요?

파라미터 수와 정밀도로 가중치 메모리를 구하고, 여기에 KV 캐시와 동시 요청 여유를 더합니다. 70B급을 FP8로 올리면 가중치가 약 70GB라 H100 기준 최소 2장, 동시 요청이 늘면 4장 이상으로 계단식으로 증가합니다. 정확한 값은 시범 트래픽 실측으로 확정해야 하며, 그 전에 구매를 확정하지 않는 것이 원칙입니다.

H100과 H200의 차이는 무엇인가요?

같은 세대이고 메모리가 다릅니다. H200은 HBM3e 141GB에 약 4.8TB/s로, 메모리 대역폭에 묶이는 디코딩 구간에서 토큰 생성이 더 빠릅니다. 긴 문서를 넣거나 동시 사용자가 많은 업무라면 메모리가 큰 쪽이 유리하고, 그렇지 않다면 H100으로 충분한 경우가 많습니다.

RAG와 파인튜닝 중 먼저 해야 할 것은?

대부분 RAG가 먼저입니다. 사내 문서의 최신성과 출처 제시가 필요한 업무가 다수이기 때문입니다. 말투·출력 형식·도메인 습관이 남은 문제가 되면 그때 파인튜닝을 두 번째 단계로 쓰는 것이 비용 면에서 합리적입니다.

LLM 도입에 반드시 필요한 인력은?

프롬프트 설계 담당과 모델 운영 담당이 최소선입니다. GPU를 직접 들이면 추론 엔진과 자원 배분을 다룰 인프라 담당이 추가로 필요합니다. 인건비가 총소유비용에서 차지하는 비중이 크다는 점을 예산안에 미리 명시해야, 장비만 승인되고 사람이 빠지는 상황을 피할 수 있습니다.

LLM 도입 검토에 바로 쓸 수 있도록 자사 채널 자료와 외부 1차 자료를 함께 정리했습니다.

자사 채널 자료

• LLM이란 무엇인가 — 원리부터 기업 도입 판단까지 — 이 글과 축이 겹치는 자사 LLM 개론. 정의와 판단 기준을 더 깊게 다룹니다
• RAG란 무엇인가 — 파이프라인 해부와 기업 도입 체크리스트 — RAG와 파인튜닝 판단을 설계 수준까지 내리는 체크리스트
• Agentic AI(에이전틱 AI)란 무엇인가 — 생성형 AI의 다음 단계 — LLM 위에 업무 루프를 얹는 다음 단계와 도입 순서
• AI 에이전트와 챗봇의 차이 — 5가지 기준 비교 — 모델 위에 얹는 서비스 형태를 구분하는 기준
• AX(AI 전환)란 무엇인가 — 정의부터 DX와의 차이, 추진 4단계까지 — LLM 도입을 개별 과제가 아닌 전환 프로그램으로 설계하는 방법
• 엔터프라이즈 AI란 무엇인가 — 이제는 AI 에이전트 시대 — 거버넌스와 운영 체계를 포함해 도입을 설계하는 가이드
• 프라이빗 sLLM Qwen — 데이터 주권과 총소유비용을 함께 — 모델을 직접 호스팅할 때의 총소유비용과 데이터 주권 계산
• AI LLM 가속 엔진 vLLM — GPU 병목과 도입 비용 줄이기 — 추론 엔진 하나가 GPU 비용을 어디까지 줄이는지 실측으로 보여주는 백서
• AI 에이전트를 위한 LLM 게이트웨이 — LiteLLM 도입 가이드 — 여러 모델 공급사를 한 곳에서 통제해 벤더 종속을 낮추는 자료
• LLM 기반 AIOps — 장애 대응을 바꾸는 7가지 기능과 도입 기준 — 도입한 LLM을 운영 업무에 붙이는 다음 단계
• AI 도입의 가장 큰 장벽 GPU 인프라 비용, 0원으로 시작하기 — GPU 초기 비용 장벽을 낮추는 자사 프로그램
• 쿠버네티스란 무엇인가 — AI 표준 플랫폼 — GPU 자원 배분과 멀티테넌시까지, 추론 런타임이 얹히는 플랫폼 입문서
• AI 투자 효율을 높이는 기준 — 모델 크기보다 중요한 MCP 전략 — 모델을 작게 쓰고 도구로 확장하는 관점에서 본 GPU 예산
• IT 운영 지능화의 시작 — AI Native Observability — 도입 후 관측 데이터를 어떻게 쓰는지로 이어지는 운영 관점
• APM과 옵저버빌리티의 차이 — 무엇부터 갖춰야 하나 — LLM 관측에 앞서 필요한 기존 관측 데이터의 출처

외부 1차 자료

• Attention Is All You Need — 트랜스포머 원 논문. 컨텍스트 창 개념의 출처
• Chinchilla — Training Compute-Optimal LLMs — 파라미터가 크다고 좋은 것이 아니라는 계산 최적 조건
• vLLM — PagedAttention 논문 — KV 캐시 관리가 처리량을 바꾸는 원리
• Llama 3 herd of models — 공개 가중치 모델의 학습 조건을 밝힌 보고서
• Stanford HAI — AI Index Report — 추론 단가 하락 곡선을 연 단위로 집계하는 연례 보고서
• MLCommons MLPerf Inference — GPU 추론 성능을 같은 기준으로 비교하는 벤치마크
• NVIDIA H100 Tensor Core GPU — 메모리 대역폭과 FP8을 사양으로 확인하는 페이지
• Gartner — 2026 Strategic Technology Trends — 에이전트형 AI 40% 전망의 원문
• Kubernetes — GPU 자원 할당(DRA) — GPU를 클러스터 자원으로 선언하는 정식 기능
• CNCF — Cloud Native AI whitepaper — 클라우드 네이티브와 AI의 결합을 다룬 공식 보고서
• Google Cloud — TPU vs GPU for AI inference — 가성비 축의 다른 선택지를 공급사 관점에서 비교

AI·LLM 인프라 도입, 다음 단계는 전문가와 상담하세요. 설치형 LLM 설계부터 GPU 운영까지 MSAP.ai가 함께합니다.

• AI 인프라 도입 상담
• MSAP.ai 플랫폼 소개
• GPU 인프라 비용 절감 프로그램