LLM 시스템 엔지니어링: 모델, 하드웨어, 워크로드를 연결하는 일

Open Weight 모델의 성능이 빠르게 높아지고 있습니다. GLM, Kimi, DeepSeek 같은 모델이 프론티어 모델에 몇 달 차이로 따라 붙었습니다. Open Weight 모델은 기업들이 자신들을 위한 특화 모델을 만들거나 자체 서빙을 할 수 있는 기반이 됩니다. 이런 흐름에서 inference engineering을 비롯해 LLM systems engineering의 중요성이 높아지고 있습니다.

LLM 시스템 엔지니어링이란?

LLM 시스템 엔지니어링은 모델의 계산을 주어진 하드웨어에서 수행하고, 작업이 요구하는 품질·속도·규모를 만족하도록 실행 방식을 설계하고 최적화하는 일입니다.

같은 모델과 GPU를 사용해도 요청을 어떻게 묶고, 데이터를 어디에 저장하며, 계산을 여러 장치에 어떻게 나누는지에 따라 실행 결과는 달라집니다. 이러한 선택을 이해하기 위해 이 시리즈에서는 모델, 하드웨어, 워크로드라는 세 가지 관점을 사용합니다.

모델, 하드웨어, 워크로드 — 그리고 실행 시스템

모델: 어떤 계산과 상태가 필요한가?

모델은 입력을 처리하는 계산의 형태를 정의합니다. 어떤 연산을 어떤 순서로 수행하는지, 그 과정에서 어떤 데이터를 읽고 어떤 상태를 유지해야 하는지가 모델에 따라 달라집니다.

예를 들어 LLM에서 핵심이 되는 Attention 구조는 토큰 사이의 관계를 계산하는 방식에 영향을 주고, MoE 구조는 입력을 처리할 expert를 선택하는 계산을 포함합니다. 모델을 이해한다는 것은 이러한 구조가 실행에 어떤 요구를 만드는지 살펴보는 것입니다.

하드웨어: 어떤 자원과 제약이 있는가?

하드웨어는 계산이 수행되는 물리적 기반입니다. GPU의 연산 성능뿐 아니라 메모리 용량과 대역폭, 여러 장치를 연결하는 통신망도 실행에 영향을 줍니다.

계산할 수 있는 속도가 빨라도 필요한 데이터를 충분히 빠르게 가져오지 못할 수 있습니다. 하나의 GPU에 들어가지 않는 모델은 여러 장치에 나누어 실행해야 하고, 이때는 장치 사이의 데이터 교환도 고려해야 합니다.

하드웨어를 이해한다는 것은 사용할 수 있는 자원과 그 자원을 활용하는 데 따르는 제약을 파악하는 것입니다.

워크로드: 어떤 일을, 어떤 조건에서 수행하는가?

워크로드는 모델로 수행하는 작업과 그 작업의 규모·패턴·목표를 의미합니다. 입력과 출력의 길이, 동시에 처리할 요청의 수, 허용할 수 있는 대기시간 등이 여기에 포함됩니다.

추론은 모델을 실행해 출력을 생성하는 작업입니다. 긴 문서를 읽고 짧게 요약하는 경우와 짧은 요청으로 긴 코드를 생성하는 경우는 서로 다른 실행 특성을 갖습니다. 사용자가 답변을 기다리는 실시간 서비스와 결과를 나중에 받아도 되는 대량 처리의 목표도 다릅니다. 에이전트처럼 모델 호출과 도구 실행이 반복되는 작업에서는 호출 사이의 의존성과 전체 작업 시간까지 살펴봐야 합니다.

학습은 데이터를 이용해 모델의 파라미터를 업데이트하는 작업입니다. Pretraining과 SFT에서는 순전파, 손실 계산, 역전파, 파라미터 업데이트가 이어집니다. 모델과 데이터의 규모에 따라 필요한 메모리와 계산량이 달라지고, 여러 장치를 사용한다면 계산과 상태를 나누는 방식이 중요해집니다.

RL 기반 Post-training은 생성과 평가, 학습이 피드백 순환으로 연결되는 작업입니다. 모델이 출력이나 행동을 생성하고, 보상 평가를 바탕으로 정책을 업데이트한 뒤, 갱신된 모델로 다시 생성합니다. 따라서 추론과 학습 각각의 효율뿐 아니라 두 과정 사이의 데이터 전달과 모델 가중치 동기화도 다뤄야 합니다.

실행 시스템: 세 가지 조건에 어떻게 대응할 것인가?

실행 시스템은 모델이 요구하는 계산을 하드웨어 위에서 수행하면서 워크로드의 목표를 만족시키는 소프트웨어입니다. 커널, 메모리 관리, 병렬화, 스케줄링과 같은 실행 방법이 여기에 포함됩니다.

추론에서는 vLLM, SGLang, TensorRT-LLM, 학습에서는 Megatron-LM과 TorchTitan, RL 기반 Post-training에서는 Miles, slime, NeMo RL, verl 같은 프로젝트가 이러한 역할을 수행합니다. 이들은 서로 다른 범위를 담당하며, RL 프레임워크처럼 추론 엔진과 학습 엔진을 연결해 전체 작업을 구성하는 경우도 있습니다.

이 관계에서 중요한 점은 좋은 실행 방식이 모델이나 하드웨어 하나만으로 결정되지 않는다는 것입니다.

이 시리즈에서는 실행 소프트웨어의 기능을 살펴볼 때마다 그 설계가 어떤 조건에 대응하는지 살펴보겠습니다. 모델이 무엇을 요구하고, 하드웨어가 무엇을 제한하며, 워크로드가 무엇을 달성하려 하는지를 연결해서 이해하는 것이 중요합니다.

앞으로의 학습 순서

시리즈는 공통 → 추론 → 학습 → RL 기반 Post-training 순서로 진행합니다.

단계	다룰 내용
공통	텐서와 행렬 연산, 모델의 기본 계산, GPU와 메모리, 데이터 이동과 성능 측정
추론	입력 처리와 토큰 생성, KV cache, 요청 스케줄링과 배치 처리, 분산 추론
학습	Pretraining·SFT의 실행 과정, 역전파와 파라미터 업데이트, 메모리 관리와 분산 학습
RL 기반 Post-training	생성·보상 평가·정책 업데이트의 연결, 자원 배분과 가중치 동기화

SFT도 일반적으로 post-training에 포함됩니다. 이 시리즈에서는 실행 구조를 단계적으로 이해하기 위해 Pretraining과 SFT를 학습 편에서 다루고, 생성과 학습이 연결되는 RL 기반 Post-training을 별도로 살펴보겠습니다.

각 글은 작은 예시에서 시작해 원리와 실행 과정을 설명하는 방식으로 구성할 예정입니다. 모델·하드웨어·워크로드 중 하나를 중심으로 다루더라도, 다른 두 조건이 실행 방식에 어떤 영향을 주는지 함께 살펴보겠습니다.

이를 통해 새로운 모델이나 프레임워크를 만났을 때도 설계의 이유를 이해하고, 병목에 대한 가설을 세우며, 측정으로 확인할 수 있는 기반을 만들어가겠습니다.