LLM 서비스는 이제 “프롬프트를 잘 쓰는가”만으로 설명되지 않습니다. 어떤 모델을 고르고, 왜 GPU 비용이 올라가며, vLLM 서빙에서 TTFT와 TPOT가 무엇을 말해주는지 이해해야 제품과 인프라의 판단이 선명해집니다. 김현진 강사의 「AI 입문을 위한 LLM 아키텍처 이해와 GPU 활용전략」은 Public API 활용 단계에서 한 걸음 더 들어가고 싶은 실무자를 위한 초급 LLM 아키텍처 강의입니다. Transformer와 Attention 구조부터 HuggingFace, vLLM, Runpod GPU, OpenWebUI, FastAPI, Tool Calling, JMeter, Prometheus, Grafana, Multi GPU 전략까지 하나의 서비스 흐름으로 연결합니다. 복잡한 수식을 먼저 밀어붙이는 강의라기보다, “LLM이 실제 서비스에서 어떤 구조로 움직이는가”를 읽는 눈을 만드는 강의에 가깝습니다. 개발자, 인프라 엔지니어, PM, 기획자가 AI 시스템 아키텍처를 함께 논의해야 한다면 특히 살펴볼 만합니다.
API 호출 너머, LLM 서비스를 운영 관점으로 읽기
ChatGPT나 Claude 같은 Public API를 잘 쓰는 것과, LLM 기반 서비스를 설계하는 것은 다른 문제입니다. 제품이 커질수록 질문은 더 구체적으로 바뀝니다.
- •이 기능은 Public API로 충분한가?
- •자체 GPU 기반 서빙을 고려해야 하는 시점은 언제인가?
- •모델 크기, 응답 지연, GPU 비용은 어떻게 연결되는가?
- •vLLM, KV Cache, Paged Attention 같은 용어는 실제 운영에서 무엇을 바꾸는가?
- •PM과 개발자, 인프라 담당자가 같은 그림을 보고 의사결정하려면 무엇을 알아야 하는가?
이 강의는 LLM을 “마법 같은 API”가 아니라 서비스 아키텍처의 한 구성 요소로 바라보게 만듭니다. 그래서 단순한 LLM 강의라기보다, AI 시스템 아키텍처를 이해하기 위한 입문 지도에 가깝습니다.
강의 상세와 최신 수강 가능 여부는 인프런 강의 페이지에서 확인할 수 있습니다.
프롬프트 사용자를 넘어 LLM 서비스 구조를 판단하는 실무자로 이동합니다.
Transformer와 Attention을 수식보다 구조로 이해합니다
LLM 아키텍처 강의에서 가장 먼저 막히는 지점은 Transformer입니다. Encoder, Decoder, Attention, Head, Embedding, Tokenizer 같은 단어가 한꺼번에 등장하면 모델을 배우기도 전에 용어에 지치기 쉽습니다.
이 강의는 Transformer와 Attention을 구조 중심으로 풀어갑니다. HuggingFace 모델을 다운로드하고, tokenizer와 embedding을 확인하고, model config를 읽으면서 “모델을 구성하는 정보가 어디에 있고 무엇을 뜻하는지”를 따라가도록 구성되어 있습니다.
특히 Attention 파트에서는 MHA, MQA, GQA, MLA처럼 발전해 온 흐름을 다룹니다. 이 용어들은 논문 제목처럼 보이지만, 실제로는 LLM 서빙 성능과 메모리 사용량을 이해하는 핵심 단서입니다.
간단히 정리하면 다음과 같습니다.
| 개념 | 강의에서 보는 관점 |
|---|---|
| Tokenizer | 텍스트가 모델 입력으로 바뀌는 첫 단계 |
| Embedding | 토큰이 벡터 공간에서 표현되는 방식 |
| Encoder / Decoder | Transformer 구조를 나누어 읽는 기준 |
| Attention | 문맥을 참조하고 다음 토큰 생성을 가능하게 하는 핵심 메커니즘 |
| KV Cache | 반복 계산을 줄여 서빙 효율을 높이는 구조 |
| MQA / GQA / MLA | Attention을 더 빠르고 효율적으로 만들기 위한 발전 흐름 |
LLM의 내부 구조를 용어 암기가 아니라 모델을 읽는 기준으로 익힙니다.
HuggingFace에서 vLLM까지, 모델을 서비스로 올리는 흐름
LLM을 공부할 때 흔히 “모델 구조”와 “서비스 배포”가 따로 떨어져 있습니다. 하지만 실제 현장에서는 두 가지가 계속 맞물립니다. 모델 config를 읽는 능력은 배포 방식의 판단으로 이어지고, GPU 메모리 제약은 어떤 서빙 엔진을 쓸지 결정하게 만듭니다.
이 강의는 HuggingFace에서 모델을 가져오는 단계부터 vLLM 기반 서빙까지 이어갑니다.
- •HuggingFace 모델 다운로드와 추론
- •tokenizer, embedding, config.json 확인
- •Transformer와 vLLM 성능 차이 이해
- •vLLM의 고성능 서빙 원리
- •OpenAI-compatible API 방식의 서빙
- •SSE Protocol을 활용한 스트리밍 응답 흐름
vLLM 강의를 찾는 분이라면 단순 설치법보다 “왜 vLLM이 필요한가”를 함께 보는 구성이 중요합니다. 이 강의는 Paged Attention, KV Cache, OpenAI Compatible 인터페이스를 연결해 LLM 서빙의 실무적 그림을 잡도록 돕습니다.
모델을 다운로드하는 수준에서 멈추지 않고 API로 서빙하는 흐름까지 연결합니다.
Runpod, OpenWebUI, FastAPI로 보는 3-tier AI 서비스 구조
LLM 서빙을 이해하려면 GPU 서버만 알아서는 부족합니다. 사용자가 만나는 UI, 요청을 처리하는 백엔드, 모델을 올리는 GPU 인프라가 어떻게 나뉘는지 봐야 합니다.
강의에서는 Runpod GPU 서버, OpenWebUI, FastAPI를 활용해 3-tier AI 서비스 구조를 다룹니다. 이 흐름은 AI 제품을 기획하거나 개발할 때 매우 현실적인 기준이 됩니다.
- •Runpod GPU 서버 구성
- •OpenWebUI를 통한 사용자 인터페이스 확인
- •FastAPI Backend 구성
- •SSH 연결과 서버 운영 팁
- •로컬 환경과 클라우드 GPU 환경의 역할 분리
- •Google Colab T4 GPU 활용 흐름
수강 전 참고할 점도 있습니다. 실습에는 Runpod GPU 서버 비용이 별도로 발생할 수 있으며, 안내 기준으로 약 $10~$20 정도를 고려할 수 있습니다. 로컬 환경은 CPU 4Core 이상, Memory 8GB 이상, 디스크 여유 공간, Windows 또는 MacOS 환경을 기준으로 안내됩니다.
이 부분은 단순한 도구 소개가 아니라, “LLM 서비스를 어디까지 직접 운영할 수 있는가”를 판단하는 실전 감각을 줍니다.
GPU 서버, 백엔드, UI를 나누어 보며 실제 AI 서비스 구조를 이해합니다.
Tool Calling까지 연결해야 ‘서비스’가 됩니다
LLM이 답변만 생성한다면 챗봇에 머물기 쉽습니다. 실제 서비스에서는 외부 도구를 호출하고, API 결과를 받아오고, 사용자의 요청을 업무 흐름으로 연결해야 합니다. 그래서 Tool Calling은 LLM 서비스 기획과 개발에서 빠르게 중요한 주제가 되었습니다.
이 강의는 Tool Calling을 별도의 고급 주제로만 밀어두지 않고, LLM 서빙 흐름 안에서 다룹니다.
- •Tool Calling 기본 개념
- •실시간 Weather Tool 예시
- •온라인 서빙 환경에서 Tool 연결
- •Chat Template 이해
- •Tool Call Parser 흐름
PM이나 기획자에게도 이 파트는 유용합니다. “LLM이 외부 시스템과 연결된다”는 말이 실제로 어떤 구조를 뜻하는지 알면, 기능 정의와 개발 커뮤니케이션이 훨씬 구체적이 됩니다. 개발자에게는 FastAPI 기반 백엔드와 Tool Calling을 함께 바라볼 수 있다는 점이 장점입니다.
LLM을 단순 답변 생성기에서 외부 도구와 연결되는 서비스 컴포넌트로 확장합니다.
TTFT, TPOT, JMeter, Prometheus, Grafana로 성능을 읽습니다
LLM 서비스를 운영할 때 “느리다”는 말만으로는 아무것도 개선할 수 없습니다. 어느 구간이 느린지, 첫 토큰이 늦는지, 토큰 생성 속도가 낮은지, 처리량이 부족한지 지표로 봐야 합니다.
강의에서는 vLLM 성능 테스트와 모니터링 관점을 함께 다룹니다.
- •TTFT: Time To First Token, 첫 토큰이 나오기까지의 시간
- •TPOT: Time Per Output Token, 출력 토큰당 생성 시간
- •Throughput: 일정 시간 동안 처리 가능한 요청 또는 토큰량
- •vLLM bench를 통한 서빙 성능 확인
- •JMeter 기반 성능 테스트
- •Prometheus와 Grafana를 통한 모니터링 흐름
이 파트는 백엔드·인프라 엔지니어에게 특히 중요합니다. 동시에 PM에게도 유용합니다. “응답 속도가 느리다”를 감각이 아니라 지표로 말할 수 있어야 모델, GPU, 서빙 엔진, UX 사이의 trade-off를 논의할 수 있기 때문입니다.
LLM 서빙 품질을 감으로 평가하지 않고 운영 지표로 읽는 방법을 익힙니다.
Multi GPU 전략은 ‘나중 문제’가 아니라 구조 판단의 기준입니다
처음부터 대규모 Multi GPU 시스템을 운영하지 않더라도, 병렬화 전략을 모르면 모델 선택과 확장 전략을 이야기하기 어렵습니다. 이 강의는 초급자를 대상으로 하면서도 Multi GPU의 큰 그림을 다룹니다.
다루는 주제는 다음과 같습니다.
- •Multi GPU가 필요한 이유
- •Tensor Parallel
- •Pipeline Parallel
- •Data Parallel
- •MIG
- •Multi Node GPU
- •NVLink
- •GPUDirect RDMA
물론 이 강의 하나로 대규모 GPU 클러스터 전문가가 된다고 말할 수는 없습니다. 다만 LLM 서비스가 성장할 때 어떤 병목이 생기고, 어떤 병렬화 전략이 논의되는지 큰 지도를 얻을 수 있습니다.
또한 DeepSeek, SharedExpert, MTP, mHC, Engram, Linear Attention, Mamba, Mamba2, xLSTM 같은 최신 구조 변화도 커리큘럼에 포함되어 있어, LLM 아키텍처의 현재 흐름을 넓게 조망할 수 있습니다.
멀티 GPU와 최신 모델 구조를 통해 LLM 시스템 확장의 언어를 익힙니다.
이 강의가 잘 맞는 사람, 그리고 수강 후 손에 남는 것
이 강의는 모든 사람에게 필요한 강의는 아닙니다. 단순히 ChatGPT 사용법이나 프롬프트 예시를 찾는 분이라면 더 가벼운 입문 강의가 나을 수 있습니다. 반대로 LLM을 서비스와 인프라 관점에서 이해하고 싶다면 잘 맞을 가능성이 높습니다.
추천 대상은 다음과 같습니다.
- •생성형 AI 서비스를 쓰고 있지만 내부 동작 원리를 알고 싶은 실무자
- •LLM 서빙과 시스템 구조를 체계적으로 배우고 싶은 AI 입문자
- •Transformer와 Attention을 수식보다 구조와 실습 중심으로 이해하고 싶은 개발자
- •GPU 최적화와 멀티 GPU 환경의 흐름이 필요한 백엔드·인프라 엔지니어
- •AI 서비스 기획과 개발 과정에서 LLM 구조와 GPU 활용 전략을 이해해야 하는 PM·기획자
수강 후 기대할 수 있는 산출물은 명확합니다.
- •HuggingFace 모델과 config를 읽는 기본 감각
- •Transformer, Attention, KV Cache를 설명할 수 있는 구조적 이해
- •vLLM 기반 LLM 서빙 흐름에 대한 입문 경험
- •Runpod GPU, OpenWebUI, FastAPI를 연결한 서비스 구조 이해
- •Tool Calling과 OpenAI-compatible API에 대한 실무적 관점
- •TTFT, TPOT, JMeter, Prometheus, Grafana로 성능을 바라보는 기준
- •Tensor Parallel, Pipeline Parallel, Data Parallel 등 Multi GPU 전략의 큰 그림
공개 데이터 기준으로 이 강의는 수강생 166명, 좋아요 74개, 수강평 7개, 평점 5.0을 기록하고 있습니다. 총 54개 수업, 약 14시간 27분 분량이며, 미리보기 7개와 미리보기 영상 7개가 제공됩니다. 최초 공개일은 2026년 4월 3일, 최근 업데이트일은 2026년 5월 26일입니다.
최신 가격, 커리큘럼, 수강 가능 여부는 인프런에서 변동될 수 있으니, 결정 전 강의 상세 페이지에서 직접 확인해 보세요.
LLM을 API가 아니라 운영 가능한 시스템으로 이해하고 싶은 사람에게 적합합니다.
LLM 아키텍처 강의 추천: vLLM 서빙과 GPU 활용 전략까지
인프런에서 강의 상세 보기