AI on kenji.blog

Microsoft.Windows.AI의 최신 API 활용 사례 및 샘플 코드

Fri, 11 Sep 2026 18:00:00 +0900

Microsoft.Windows.AI의 최신 API 활용 사례 및 샘플 코드: Windows Copilot Runtime의 심연을 탐구하다

1. 시작하며: AI가 네이티브로 내장되는 Windows의 새로운 시대

최근 AI 기술의 진화는 눈부시며, 클라우드 상에서의 대규모 언어 모델(LLM) 활용에서 엣지 디바이스(로컬 PC)에서의 AI 추론으로 급속히 패러다임 전환이 일어나고 있습니다. 그 핵심을 담당하는 것이 Microsoft가 Windows 11용으로 제공하는 “Windows Copilot Runtime"과 이를 제어하기 위한 “Microsoft.Windows.AI” API입니다.

클라우드 API(OpenAI나 Azure OpenAI 등)를 이용한 애플리케이션 개발은 쉽지만, 지연 시간(레이턴시), 프라이버시, 그리고 지속적인 비용이라는 과제가 따라다닙니다. 반면, 로컬에서 AI 모델을 구동함으로써 기밀 데이터를 디바이스 밖으로 내보내지 않고 오프라인에서도 작동하는 초저지연 애플리케이션을 구현할 수 있습니다.

본 기사에서는 앞으로의 Windows 애플리케이션 개발에서 필수가 될 로컬 AI 기능의 구현 방법에 대해 C# 및 C++의 실용적인 샘플 코드를 곁들여 아키텍처부터 성능 튜닝까지 아주 상세하게 철저히 해설합니다. 단순히 API를 호출하는 것에 그치지 않고, 그 이면에 있는 하드웨어(NPU 및 GPU)의 활용, DirectML과의 연동 등 고도의 기술적 세부 사항까지 깊이 파고듭니다.

2. Windows Copilot Runtime과 아키텍처의 전체상

Windows Copilot Runtime은 개발자가 Windows 상에서 AI 모델을 쉽게 통합하고 최고의 성능을 끌어낼 수 있도록 설계된 일련의 AI 스택입니다. 이 런타임은 OS 레벨에서 하드웨어 가속을 추상화하여 개발자에게 통일된 인터페이스를 제공합니다.

graph TD App["Windows 애플리케이션 (C# / C++)"] --> API["Microsoft.Windows.AI APIs"] App --> ORT["ONNX Runtime"] API --> WCR["Windows Copilot Runtime (OS 레이어)"] WCR --> SLM["로컬 모델 (Phi-Silica 등)"] ORT --> DML["DirectML Execution Provider"] SLM --> DML DML --> DXCore["DXCore / DirectX 12"] DXCore --> NPU["NPU (Neural Processing Unit)"] DXCore --> GPU["GPU (Graphics Processing Unit)"] DXCore --> CPU["CPU"]

위의 아키텍처 다이어그램이 보여주듯이, 애플리케이션은 고수준의 Microsoft.Windows.AI API를 이용함으로써 OS에 내장된 소규모 언어 모델(SLM: Phi-Silica 등)에 직접 접근할 수 있습니다. 또한, 커스텀 모델을 사용할 경우에는 ONNX Runtime과 DirectML을 통해 하드웨어 가속을 명시적으로 이용하는 것도 가능합니다. OS 레이어가 CPU, GPU, NPU로의 워크로드 분산을 최적화하므로, 개발자는 하드웨어의 차이를 깊이 의식하지 않고도 고성능 AI 앱을 구축할 수 있습니다.

3. 하드웨어 가속과 NPU의 수리적 평가

최신 Copilot+ PC에는 AI 처리에 특화된 프로세서인 NPU(Neural Processing Unit)가 탑재되어 있습니다. NPU의 성능은 일반적으로 TOPS(Tera Operations Per Second)로 평가됩니다.

AI 모델의 추론에 있어서, 특히 행렬 곱셈(GEMM: General Matrix Multiply)의 계산 능력이 처리량(Throughput)을 결정짓습니다. 하드웨어의 이론상 최대 성능 $P_{\text{peak}}$ 은 다음 수식으로 개략적으로 계산됩니다.

$$ P_{\text{peak}} = f \times N_{\text{cores}} \times N_{\text{MACs/core}} \times 2 $$

여기서,

$f$ 는 NPU의 클럭 주파수(Hz)
$N_{\text{cores}}$ 는 NPU 내의 코어 수
$N_{\text{MACs/core}}$ 는 1코어당 MAC(Multiply-Accumulate) 유닛 수
마지막의 $2$ 는, 1회의 MAC 연산이 곱셈과 덧셈의 2개 오퍼레이션(FLOPs/OPs)으로 계산되기 때문입니다.

예를 들어, 주파수 1.5GHz, 4코어, 각 코어가 4096MACs를 가진 NPU의 경우,

$$ P_{\text{peak}} = 1.5 \times 10^9 \times 4 \times 4096 \times 2 \approx 49.15 \text{ TOPS} $$

가 됩니다. Windows 11의 Copilot+ PC 요건인 40 TOPS를 만족하는 성능임이 수학적으로 증명됩니다.

또한, AI 모델, 특히 LLM의 추론(디코드 페이즈)은 **메모리 바운드(Memory-Bound)**가 되기 쉽습니다. 시스템 메모리의 이론적 대역폭 $BW$ 는 다음과 같이 계산됩니다.

$$ BW = f_{\text{mem}} \times W_{\text{bus}} \times \frac{2}{8} $$

LPDDR5x-8533 메모리($f_{\text{mem}} = 8533 \text{ MT/s}$), 128비트 버스($W_{\text{bus}} = 128$)의 경우, 대역폭은 약 $136 \text{ GB/s}$ 가 됩니다. AI 애플리케이션의 최적화에서는 이 대역폭을 어떻게 절약할지가 중요하며, 후술할 모델의 양자화(Quantization)가 필수적입니다.

4. 개발 환경 설정

최신 Windows AI API를 이용하려면, 다음의 환경과 툴체인을 갖추어야 합니다.

OS: Windows 11 버전 24H2 이상 (Copilot+ PC 요건을 만족하는 NPU 탑재 디바이스를 강력히 권장)
SDK: Windows App SDK (v1.5 이후의 AI 확장 대응 버전)
개발 환경: Visual Studio 2022 (v17.10 이상), C++를 사용한 네이티브 개발 워크로드 및 .NET 데스크톱 개발 워크로드
패키지: NuGet을 통해 Microsoft.Windows.AI 및 Microsoft.ML.OnnxRuntime.DirectML 설치

1
2
3
4
5
6


<!-- .csproj 설정 예시 -->
<ItemGroup>
 <PackageReference Include="Microsoft.Windows.AI" Version="1.0.0-preview1" />
 <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240311000" />
 <PackageReference Include="Microsoft.ML.OnnxRuntime.DirectML" Version="1.17.1" />
</ItemGroup>

5. 【Deep Dive 1】 C#을 이용한 로컬 언어 모델(Phi-Silica) 활용

Windows Copilot Runtime에는 Microsoft가 개발한 고효율 소규모 언어 모델인 “Phi-Silica"가 OS 표준 컴포넌트로 내장되어 있습니다. 이를 통해 GB 단위의 모델을 네트워크에서 다운로드할 필요 없이, 오프라인 환경에서 고도의 자연어 처리(문서 요약, 코드 생성, 챗봇)가 가능해집니다.

다음은 Microsoft.Windows.AI.Generative 네임스페이스를 사용하여 C#으로 채팅 AI를 구축하는 고급 샘플 코드입니다. 스트리밍 응답을 지원하며, UI 스레드를 차단하지 않고 실시간으로 텍스트를 생성합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Windows.AI.Generative;

namespace WindowsAI.Sample
{
 public class LocalLanguageModelService
 {
 private LanguageModel _languageModel;
 private bool _isInitialized = false;

 /// <summary>
 /// 언어 모델의 초기화를 수행합니다. NPU 사용 가능 여부를 확인하고 최적의 디바이스에 모델을 로드합니다.
 /// </summary>
 public async Task InitializeAsync()
 {
 if (_isInitialized) return;

 Console.WriteLine("로컬 AI 모델(Phi-Silica)의 시스템 요구 사항 및 가용성을 확인하고 있습니다...");

 // 모델이 시스템에서 사용 가능한지 확인 (미지원일 경우 다운로드가 촉구될 수 있음)
 var availability = await LanguageModel.CheckAvailabilityAsync();
 if (availability != LanguageModelAvailability.Available)
 {
 throw new InvalidOperationException($"로컬 AI 모델을 현재 사용할 수 없습니다. 상태: {availability}");
 }

 // 모델 인스턴스 생성 (이 타이밍에 메모리 공간으로의 매핑과 NPU 초기화가 수행됨)
 _languageModel = await LanguageModel.CreateAsync();
 _isInitialized = true;

 Console.WriteLine("언어 모델의 초기화가 완료되었습니다. DirectML을 통한 하드웨어 가속이 활성화되었습니다.");
 }

 /// <summary>
 /// 사용자의 프롬프트를 받아 스트리밍으로 응답을 생성합니다.
 /// </summary>
 public async Task GenerateResponseStreamAsync(string prompt, CancellationToken cancellationToken)
 {
 if (!_isInitialized) await InitializeAsync();

 Console.WriteLine($"\n[사용자 입력]: {prompt}\n[AI 어시스턴트]: ");

 // 생성 시 하이퍼파라미터 설정
 var options = new LanguageModelOptions
 {
 Temperature = 0.7f,
 TopP = 0.9f,
 MaxTokens = 2048,
 RepetitionPenalty = 1.1f
 };

 // 대화 컨텍스트 구축
 var context = new LanguageModelContext();
 context.AddSystemMessage("당신은 Windows의 로컬 NPU 상에서 직접 동작하는 고도의 AI 어시스턴트입니다. 단계별로 논리적으로 생각하고 간결하게 답변해 주세요.");
 context.AddUserMessage(prompt);

 try
 {
 // 스트리밍 추론 API 호출
 var responseStream = _languageModel.GenerateResponseStreamAsync(context, options);

 // IAsyncEnumerable로 반환되는 청크를 비동기로 반복 처리
 await foreach (var chunk in responseStream.WithCancellation(cancellationToken))
 {
 // 생성된 토큰(청크)을 실시간으로 콘솔에 출력
 // UI 애플리케이션의 경우, 여기서 DispatcherQueue를 사용하여 TextBox 등에 반영합니다
 Console.Write(chunk.Text);
 }
 Console.WriteLine();
 }
 catch (OperationCanceledException)
 {
 Console.WriteLine("\n[사용자 또는 시스템에 의해 생성이 취소되었습니다]");
 }
 catch (Exception ex)
 {
 Console.WriteLine($"\n[치명적인 오류가 발생했습니다: {ex.Message}]");
 }
 }
 }
}

5.1 C# 구현에서의 아키텍처 해설

이 코드의 핵심은 LanguageModel.CheckAvailabilityAsync() 에 의한 실행 전 검증과 GenerateResponseStreamAsync 에 의한 비동기 스트리밍입니다. OS 백그라운드에서 동작하는 Copilot Runtime은 이 API 호출을 받으면 내부적으로 ONNX Runtime을 기동하고, 시스템의 구성에 따라 최적의 Execution Provider(대부분의 최신 PC에서는 DirectML + NPU)를 선택합니다.

개발자는 모델의 텐서 형태, 토크나이저 구현, KV 캐시의 메모리 관리 등을 전혀 의식하지 않고, 단 몇 줄의 C# 코드로 최첨단 AI 추론 파이프라인을 애플리케이션에 통합할 수 있습니다.

6. 【Deep Dive 2】 C++와 DirectML을 이용한 커스텀 모델의 고속 추론

OS 표준 언어 모델만으로는 커버할 수 없는 특정 도메인(독자적인 이미지 세그멘테이션, 음성 인식, 커스텀 객체 탐지 모델 등)을 다룰 경우, 개발자는 Microsoft.Windows.AI 의 하위 레이어에 위치하는 ONNX Runtime과 DirectML을 직접 제어해야 합니다.

C++를 사용함으로써 메모리 할당을 극한까지 최적화하고 NPU/GPU의 최대 성능을 끌어낼 수 있습니다. 다음은 ONNX 형식의 커스텀 모델(예: YOLOv8)을 DirectML을 사용하여 C++로 실행하기 위한, 고급 초기화 및 추론 파이프라인의 핵심 구현입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99


#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>
#include <onnxruntime_cxx_api.h>
#include <dml_provider_factory.h>

class CustomVisionAIProcessor {
private:
 Ort::Env env;
 Ort::Session session{nullptr};
 Ort::AllocatorWithDefaultOptions allocator;

public:
 CustomVisionAIProcessor(const std::wstring& modelPath)
 : env(ORT_LOGGING_LEVEL_WARNING, "VisionAIProcessor") {

 Ort::SessionOptions sessionOptions;
 // 스레드 수 최적화
 sessionOptions.SetIntraOpNumThreads(1);
 // 그래프 최적화 레벨을 최대로 설정
 sessionOptions.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);

 // 1. DirectML Execution Provider (DML EP) 추가
 // device_id = 0 은 시스템의 기본 권장 어댑터(NPU 또는 고성능 GPU)
 const OrtApi& ortApi = Ort::GetApi();
 OrtDmlApi* dmlApi = nullptr;
 OrtStatus* status = ortApi.GetExecutionProviderApi("DML", ORT_API_VERSION, reinterpret_cast<void**>(&dmlApi));

 if (status == nullptr && dmlApi != nullptr) {
 Ort::ThrowOnError(dmlApi->SessionOptionsAppendExecutionProvider_DML(sessionOptions, 0));
 std::cout << "[Info] DirectML Execution Provider를 정상적으로 연결했습니다." << std::endl;
 } else {
 std::cerr << "[Warning] DirectML API 가져오기에 실패했습니다. CPU 폴백 모드로 실행합니다." << std::endl;
 if (status != nullptr) ortApi.ReleaseStatus(status);
 }

 // 2. 모델 로드 및 세션 생성
 try {
 session = Ort::Session(env, modelPath.c_str(), sessionOptions);
 std::cout << "[Info] ONNX 모델 로드에 성공하고 연산 그래프가 컴파일되었습니다." << std::endl;
 } catch (const Ort::Exception& e) {
 std::cerr << "[Error] 모델 로드 실패: " << e.what() << std::endl;
 throw;
 }
 }

 void RunInference(const std::vector<float>& imageTensor, const std::vector<int64_t>& inputShape) {
 // 3. 입력 텐서 버퍼 생성
 Ort::MemoryInfo memoryInfo = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
 Ort::Value inputTensor = Ort::Value::CreateTensor<float>(
 memoryInfo,
 const_cast<float*>(imageTensor.data()),
 imageTensor.size(),
 inputShape.data(),
 inputShape.size()
 );

 // 4. 입출력 노드 이름 동적 획득
 auto inputNamePtr = session.GetInputNameAllocated(0, allocator);
 auto outputNamePtr = session.GetOutputNameAllocated(0, allocator);
 const char* inputNames[] = { inputNamePtr.get() };
 const char* outputNames[] = { outputNamePtr.get() };

 // 5. 추론 실행 (DirectML을 통해 NPU/GPU로 오프로드됨)
 std::cout << "[Info] 추론 엔진 실행을 시작합니다..." << std::endl;
 auto startTime = std::chrono::high_resolution_clock::now();

 auto outputTensors = session.Run(Ort::RunOptions{nullptr}, inputNames, &inputTensor, 1, outputNames, 1);

 auto endTime = std::chrono::high_resolution_clock::now();
 auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - startTime);

 // 6. 결과 텐서 획득 및 분석
 float* outputData = outputTensors.front().GetTensorMutableData<float>();
 size_t outputSize = outputTensors.front().GetTensorTypeAndShapeInfo().GetElementCount();

 std::cout << "[Result] 추론 완료: " << duration.count() << " ms" << std::endl;
 std::cout << "[Result] 출력 텐서의 요소 수: " << outputSize << std::endl;
 // ※ 이 후, 출력 텐서에 대해 NMS(Non-Maximum Suppression)나 바운딩 박스 그리기 처리를 구현합니다
 }
};

int main() {
 try {
 // 실행할 ONNX 모델의 경로
 CustomVisionAIProcessor processor(L"models/yolov8n_quantized.onnx");

 // 추론용 더미 이미지 데이터 (배치 크기 1 x 3 채널 x 640 x 640)
 std::vector<int64_t> inputShape = {1, 3, 640, 640};
 std::vector<float> dummyImage(1 * 3 * 640 * 640, 0.5f);

 processor.RunInference(dummyImage, inputShape);
 } catch (const std::exception& e) {
 std::cerr << "프로그램이 비정상 종료되었습니다: " << e.what() << std::endl;
 return -1;
 }
 return 0;
}

6.1 C++에서의 메모리 관리와 제로 카피 추론의 중요성

C++에서 DirectML을 사용하는 최대의 장점은 DirectX 12(DX12)와의 긴밀한 통합이 가능하다는 점입니다. 위의 코드는 교육적 관점에서 표준적인 CPU 메모리로부터의 데이터 복사를 포함하고 있지만, 실제 게임 엔진이나 영상 처리 애플리케이션에서는 DX12를 사용하여 이미지(텍스처)를 이미 GPU나 NPU의 메모리 공간에 유지하고 있는 경우가 많습니다.

이 경우, OrtDmlApi 의 고급 바인딩 기능을 이용하여 DX12의 리소스를 직접 ONNX Runtime의 텐서로 매핑하는 “제로 카피 추론(Zero-Copy Inference)“을 구현할 수 있습니다. 이를 통해 PCIe 버스 간의 데이터 전송 오버헤드(앞서 언급한 대역폭 $BW$ 의 소비)가 완전히 사라져, 실시간 동영상 처리에서의 프레임 속도가 극적으로 향상됩니다.

7. 성능 최적화와 모범 사례

Windows AI API나 DirectML을 활용하여 최상급의 AI 애플리케이션을 개발할 때의 필수적인 최적화 전략을 아래에 정리합니다.

7.1 모델 양자화(Quantization)와 Olive Toolkit

NPU의 진정한 힘을 발휘시키려면, AI 모델의 가중치와 활성화 값을 FP32(단정밀도 부동소수점)에서 INT8 또는 INT4로 **양자화(Quantization)**하는 것이 절대적인 조건입니다. NPU의 아키텍처는 정수 연산에 특화되어 있어, FP32와 비교해 INT8에서는 이론상 4배의 처리량과 대폭적인 전력 절감을 실현합니다.

Microsoft가 제공하는 Olive (ONNX Live) 툴체인을 사용하면 PyTorch 등의 모델을 Windows 환경에 맞게 자동 최적화할 수 있습니다. Olive는 Transformer 모델에 대한 특수한 어텐션 최적화나 하드웨어별 그래프 컴파일을 강력하게 지원합니다.

7.2 배치 처리 vs 대화형 스트리밍의 트레이드오프

API 호출에 있어 여러 추론 요청을 묶어서 배치(Batch) 처리함으로써 NPU의 사용 효율(Compute Utilization)을 높일 수 있습니다. 그러나 챗봇과 같은 대화형 UI의 경우, 처리량보다도 첫 번째 토큰이 표시될 때까지의 시간(TTFT: Time To First Token)이 사용자 경험(UX)을 결정짓습니다. 따라서 대화형 UI에서는 배치 크기를 1로 설정하고, 스트리밍 생성을 우선하는 설계가 모범 사례가 됩니다.

7.3 백그라운드 작업과 OS의 연동

AI 추론은 로컬 전력과 시스템 리소스를 대량으로 소비합니다. Windows의 App Lifecycle API 와 연동하여, 애플리케이션이 백그라운드로 전환될 때는 우선순위가 낮은 추론 작업을 일시 중단(Suspend)하거나 리소스 소비를 줄이는 구현이 요구됩니다.

sequenceDiagram participant User as "사용자" participant App as "Windows 앱 (C#)" participant API as "Microsoft.Windows.AI" participant OS as "Windows Copilot Runtime" participant ORT as "ONNX Runtime (DML)" participant NPU as "NPU 하드웨어" User->>App: "프롬프트 입력" App->>API: "GenerateResponseStreamAsync()" API->>OS: "추론 작업 디스패치" OS->>ORT: "그래프 실행 요청" ORT->>NPU: "DirectML을 통한 명령 목록 실행" NPU-->>ORT: "계산 완료 (1 토큰 생성)" ORT-->>OS: "텐서 결과" OS-->>API: "디코딩된 텍스트" API-->>App: "IAsyncEnumerable 청크" App-->>User: "UI로의 실시간 문자 렌더링" Note over ORT,NPU: "완료될 때까지 이 루프를 고속으로 반복"

이 시퀀스 다이어그램은 UI 스레드를 전혀 차단하지 않고, 최하층의 NPU 하드웨어에서 애플리케이션의 프레젠테이션 계층까지 데이터가 흐르듯이 스트리밍되는 비동기 처리의 아름다움을 보여줍니다.

8. 향후 전망과 Windows AI의 진화

Microsoft.Windows.AI API와 Copilot Runtime은 현재 진행형으로 급속한 진화를 거듭하고 있습니다. 향후 개발자 대상 업데이트에서는 다음과 같은 패러다임 전환이 기대됩니다.

멀티모달 API의 OS 네이티브 통합: 텍스트뿐만 아니라 음성, 이미지, 나아가 라이브 비디오 피드를 매끄럽게 동시 처리하여 크로스모달 AI 추론을 OS 수준에서 기본 제공.
RAG(Retrieval-Augmented Generation) 시스템 수준 지원: 로컬 PC 내의 개인 문서들이나 Windows Search의 인덱스와 AI 모델을 OS의 안전한 샌드박스 내에서 연동시켜, 사용자의 프라이버시를 완벽히 보호한 상태에서의 초고도 개인 AI 어시스턴트 구축.
NPU의 동적 리소스 스케일링: 여러 AI 애플리케이션(예를 들어, 백그라운드에서의 노이즈 캔슬링과 포그라운드에서의 코드 생성)이 동시에 가동될 때, Windows 커널 스케줄러가 NPU의 실행 컨텍스트를 동적으로 전환하여 QoS(Quality of Service)를 보장하는 메커니즘.

9. 결론: 로컬 AI가 바꾸는 애플리케이션의 미래

Windows 11의 Copilot Runtime과 Microsoft.Windows.AI API는 모든 Windows 개발자에게 ‘로컬 AI’라는 극히 강력한 무기를 가져다주었습니다. 이제 클라우드 API에 전적으로 의존할 필요가 없습니다. 지연 시간을 없애고 프라이버시를 굳건히 지키면서도, 오프라인에서 완벽하게 작동하는 차세대 AI 경험을 사용자에게 제공하는 것이 가능해졌습니다.

본 기사에서 해설한 C#을 이용한 시스템 표준 언어 모델의 통합, 수리적인 성능 평가, 그리고 C++와 DirectML을 이용한 극한의 하드웨어 최적화 지식을 활용하여, 여러분의 손으로 차세대 “AI 네이티브” Windows 애플리케이션을 창조해 보세요. AI가 가져올 무한한 가능성은 여러분이 작성하는 코드의 바로 앞에 펼쳐져 있습니다.

※ 주의사항: 이 기사는 2026년 9월 현재의 프리뷰 버전 API 및 최신 사양을 바탕으로 작성되었습니다. Windows 업데이트에 따라 API 사양이나 하드웨어 요구 사항이 변경될 수 있으므로, 구현 시에는 반드시 Microsoft Learn의 공식 문서를 함께 참조해 주시기 바랍니다.

Python 필요 없음! C++만으로 AI 추론 엔진을 구축해 보았다

Fri, 11 Sep 2026 17:00:00 +0900

1. 시작하며: 왜 Python을 버리고 C++로 AI 추론 엔진을 만드는가?

현대 AI 개발에서 Python은 사실상의 표준(De facto standard)입니다. PyTorch나 TensorFlow 같은 강력한 프레임워크의 은혜 덕분에, 몇 줄의 코드만으로 복잡한 신경망을 구축하고 학습 및 추론시킬 수 있습니다. 하지만 이런 프레임워크의 이면에서는 C++이나 CUDA와 같은 로우 레벨(Low-level) 언어가 계산량이 많은 처리를 담당하고 있습니다. Python은 어디까지나 ‘접착제(Glue)’ 역할을 할 뿐입니다.

그렇다면 왜 굳이 Python을 배제하고 C++ 단독으로 AI 추론 엔진을 만들어야 할까요? 거기에는 몇 가지 강력한 이유가 있습니다.

극한의 성능과 짧은 지연 시간: Python의 GIL(Global Interpreter Lock)이나 동적 타이핑에 의한 오버헤드를 완전히 제거할 수 있습니다. 특히 실시간성이 요구되는 시스템에서는 밀리초 단위의 지연이 치명적일 수 있습니다.
배포의 용이성: Python 환경(거대한 라이브러리군, 의존성 지옥)을 최종 사용자의 환경에 구축하는 것은 매우 어렵습니다. C++이라면 정적으로 링크된 단일 실행 바이너리(.exe나 ELF 바이너리)를 배포하기만 하면 됩니다.
엣지 디바이스 대응: 스마트폰이나 임베디드 기기, 라즈베리 파이 같은 리소스 제약이 심한 환경에서 수 기가바이트의 메모리를 소비하는 Python 런타임을 구동할 여유는 없습니다.
하드웨어 직접 제어: 메모리 할당 타이밍, SIMD 명령어의 명시적 사용, GPU와의 메모리 전송 최적화 등 로우 레벨 제어는 C++에서만 가능합니다.

본 기사에서는 Georgi Gerganov 씨가 개발한 ‘GGML’ 라이브러리의 아키텍처에서 많은 영감을 받아, C++만으로 대규모 언어 모델(LLM) 등을 구동하기 위한 추론 엔진을 처음부터 구축해 나가는 과정을 기술적인 깊은 곳까지 파고들어 해설합니다.

2. 추론 엔진 아키텍처의 전체적인 모습

AI의 추론 처리는 본질적으로 ‘거대한 행렬 계산의 연속’입니다. 이를 효율적으로 실행하기 위해, 추론 엔진은 다음과 같은 컴포넌트로 구성되어야 합니다.

graph TD A["입력 데이터 (토큰/이미지)"] --> B["텐서 관리"] B --> C["계산 그래프 (DAG)"] C --> D["메모리 아레나 & 할당자"] C --> E["스케줄러 & 스레드 풀"] E --> F["CPU 백엔드 (AVX2/ARM NEON)"] E --> G["GPU 백엔드 (CUDA/Metal)"] F --> H["출력 결과"] G --> H

텐서(Tensor) 관리: 다차원 배열의 데이터 구조와 차원별 스트라이드(Stride)를 관리합니다.
계산 그래프(Computation Graph): 신경망 각 층의 연산을 방향성 비순환 그래프(DAG)로 표현합니다.
메모리 아레나(Memory Arena): 동적 메모리 확보(malloc이나 new)의 오버헤드를 피하기 위한, 사전 확보형 메모리 관리 메커니즘입니다.
백엔드(Backend): CPU나 GPU 등, 특정 하드웨어에 최적화된 연산 구현(커널)입니다.

이들을 C++의 강력한 기능(템플릿, 포인터 연산, RAII 등)을 사용하여 조립해 나갑니다.

3. 메모리 관리의 극의: 메모리 아레나와 SIMD 정렬

추론 엔진에서 메모리 관리는 성능과 직결되는 가장 중요한 요소 중 하나입니다. 추론 중, 특히 트랜스포머(Transformer) 모델의 각 층을 통과할 때 방대한 수의 중간 텐서가 생성됩니다. 이를 매번 표준 malloc으로 할당하고 해제한다면, 힙의 단편화와 OS의 컨텍스트 스위칭으로 인해 치명적인 속도 저하를 초래합니다.

그래서 ‘메모리 아레나(Memory Arena)‘라는 접근 방식을 채택합니다. 이는 추론 시작 시 필요한 최대 메모리 양을 계산(또는 미리 결정)하여 일괄적으로 할당하고, 포인터의 증가만으로 메모리를 잘라내어 사용하는 방법입니다.

3.1 정렬(Alignment)의 중요성

현대 CPU는 SIMD(Single Instruction, Multiple Data) 명령어를 지원합니다. Intel/AMD의 AVX2/AVX-512나 ARM의 NEON 등이 있습니다. 이 명령어들은 256비트(32바이트)나 512비트(64바이트)의 데이터를 한 번에 처리하지만, 처리 대상 데이터의 메모리가 특정 바이트 경계(보통 32바이트나 64바이트)에 정렬(Alignment)되어 있어야 합니다.

다음은 정렬을 고려한 메모리 아레나의 C++ 구현 예시입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // POSIX 계열이라면 posix_memalign, Windows라면 _aligned_malloc을 사용
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // 정렬 계산 (패딩 구하기)
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena out of memory");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // 메모리 해제는 포인터를 되돌리기만 하면 됨 (O(1))
 }
};

이처럼 텐서 생성 시에는 반드시 이 아레나를 통해 메모리를 얻습니다. 추론의 각 단계(토큰 생성마다 등)가 끝날 때마다 reset()을 호출하는 것만으로, 순식간에 메모리를 재사용할 수 있습니다.

4. 텐서 데이터 구조와 스트라이드의 마법

텐서는 스칼라, 벡터, 행렬을 일반화한 개념입니다. 구현에 있어 중요한 것은 실제 데이터가 메모리 상에 1차원의 연속된 배열로 배치되어 있는 반면, 이를 다차원으로 해석하기 위한 ‘스트라이드(Stride)‘라는 개념을 갖는다는 점입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


enum class DataType {
 FP32,
 FP16,
 INT8, // 양자화용
 INT4 // 양자화용
};

struct Tensor {
 int n_dims; // 차원의 수
 int64_t ne[4]; // 각 차원의 요소 수 (Number of Elements)
 size_t nb[4]; // 각 차원의 스트라이드 (Number of Bytes)
 DataType type; // 데이터 타입
 void* data; // 페이로드 포인터

 // 계산 그래프용
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

스트라이드 nb[i]는 차원 i에서 인접한 요소 간의 메모리 상 바이트 거리를 나타냅니다. 예를 들어 요소 수 $M \times N$인 행렬(FP32, 1요소 4바이트)이 Row-Major(행 우선)로 저장된 경우, 스트라이드는 다음과 같습니다.

nb[0] = 4 (바이트) : 열 방향 이동
nb[1] = $N \times 4$ (바이트) : 행 방향 이동

이를 이용하면 메모리 복사 없이 ‘전치(Transpose)‘나 ‘뷰(View)’ 같은 연산을 스트라이드 값의 교환만으로 구현할 수 있습니다. 매우 우아하고 빠릅니다.

5. 계산 그래프(DAG) 구축과 지연 평가

PyTorch 등과 마찬가지로, 우리의 추론 엔진도 ‘Define-by-Run’에 가까운 지연 평가(Lazy Evaluation)를 채택합니다. 즉, 연산 함수를 호출한 시점에서는 계산을 수행하지 않고, 그래프(노드 간의 의존 관계)만 구축합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b는 전치되어 있는 경우가 많음
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

추론 처리의 흐름은 다음과 같습니다.

graph LR A["텐서 정의"] --> B["연산을 통한 그래프 구축"] B --> C["위상 정렬"] C --> D["출력을 위한 메모리 할당"] D --> E["순서대로 노드 실행"]

그래프를 평가할 때(순전파 패스), 위상 정렬을 사용하여 의존 관계가 없는 노드부터 순서대로 처리를 실행합니다. 추론만 한다면 역전파용 기울기를 유지할 필요가 없으므로 메모리 관리가 매우 단순해집니다.

6. 수학과 최적화의 핵심: 행렬곱 (GEMM)

AI 추론 연산량의 90% 이상은 행렬 곱셈(GEMM: General Matrix Multiply)에 소요됩니다. 트랜스포머 모델의 핵심인 어텐션(Attention) 메커니즘도 피드포워드 신경망(FFN)도 궁극적으로는 거대한 행렬곱입니다.

두 행렬 $A$ (크기 $M \times K$)와 $B$ (크기 $K \times N$)의 곱 $C = A B$ (크기 $M \times N$)은 수식으로 표현하면 다음과 같습니다.

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

이를 단순한 삼중 루프로 구현하면 캐시 미스가 빈발하여 성능이 전혀 나오지 않습니다.

6.1 CPU에서의 캐시 블로킹과 SIMD 최적화

CPU에서 GEMM을 가속하기 위한 기본 전략은 다음과 같습니다.

루프 타일링(캐시 블로킹): L1/L2 캐시에 들어갈 수 있는 작은 블록으로 행렬을 분할하여 계산합니다.
데이터 팩킹: 메모리 접근 패턴이 연속적이 되도록 내부적으로 데이터를 재배열합니다.
SIMD 활용: AVX-512의 _mm512_fmadd_ps와 같은 FMA(Fused Multiply-Add) 명령어를 사용하여 한 클록 사이클에 다수의 곱셈 및 덧셈 연산을 처리합니다.

C++과 SIMD Intrinsics를 사용한 단순화된 벡터 내적(Dot Product)의 예를 보여드립니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


#include <immintrin.h> // AVX 명령어용

// AVX2를 활용한 FP32 고속 내적
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // 8개 요소씩 한 번에 처리 (256비트 = 32바이트 = 8 * 4바이트)
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // FMA 명령어: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // SIMD 레지스터 내의 값을 수평 가산
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // 나머지 처리
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

이 작은工夫(고안)만으로도 단순 구현에 비해 몇 배에서 십여 배의 속도 향상을 얻을 수 있습니다.

7. 하드웨어의 장벽을 넘다: CUDA 및 Metal 백엔드 통합

순수 C++ 구현만으로도 CPU 상에서는 어느 정도 동작하지만, LLM과 같은 거대 모델을 실용적인 속도(예: 1초당 20토큰 이상 생성)로 구동하기 위해서는 GPU의 병렬 계산 능력이 필수적입니다. 따라서 우리 엔진에 백엔드 추상화 레이어를 도입합니다.

7.1 백엔드 추상화

C++의 다형성을 이용하여 연산 실행기(Executor)를 전환할 수 있도록 합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // 각종 연산의 실행
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 NVIDIA CUDA 백엔드 구현

NVIDIA의 GPU를 활용하기 위해, CUDA C++ 확장을 사용하여 백엔드를 구현합니다. 독자적인 커널을 작성하는 것도 가능하지만, 행렬곱에 관해서는 NVIDIA가 제공하는 최고 수준의 라이브러리인 ‘cuBLAS’를 활용하는 것이 최선의 선택입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // CUDA는 기본이 Column-Major이므로 파라미터에 주의가 필요함
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // src1은 전치되어 있다는 전제

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

CUDA 메모리와 호스트(CPU) 메모리 간의 데이터 전송(cudaMemcpy)은 매우 무겁기 때문에, 추론 중에는 가급적 모든 가중치(웨이트 텐서)와 중간 텐서를 VRAM 상에 계속 유지하는 설계가 중요합니다.

7.3 Apple Silicon (Metal) 백엔드

최근 Mac의 M1/M2/M3 칩(Apple Silicon)은 AI 추론기로서 매우 우수합니다. 그 이유는 ‘통합 메모리(Unified Memory)‘에 있습니다. CPU와 GPU가 동일한 메모리 영역을 공유하고 있기 때문에, 앞서 언급한 CUDA와 같은 PCIe 버스를 통한 고비용의 호스트-디바이스 간 메모리 전송이 전혀 필요하지 않습니다.

C++에서 Metal을 호출하려면 Objective-C++(.mm 파일)을 브리지로 사용하거나, metal-cpp 라이브러리를 이용합니다. Metal의 Compute Shader(.metal 파일에 C++와 비슷하게 작성)를 사용하여 커널을 작성합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// Metal 셰이더 (kernel.metal)
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // 간략화됨
 }
 C[row * n + col] = sum;
 }
}

Apple Silicon 환경에서는 MPS(Metal Performance Shaders)라는 행렬곱 전용 최적화 라이브러리도 제공하고 있으므로, 실제 운용 시에는 이를 활용하여 경이로운 추론 속도를 달성할 수 있습니다.

8. 트랜스포머 모델 특유의 처리: 어텐션(Attention)과 KV 캐시

LLaMA 2/3이나 GPT와 같은 최첨단 LLM은 트랜스포머 아키텍처에 기반을 두고 있습니다. 이를 C++로 구현하기 위해서는 다음 수식으로 표현되는 ‘Scaled Dot-Product Attention’의 구축이 필수입니다.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

또한, 자기회귀형(Autoregressive) 토큰 생성에서는 과거 토큰의 계산 결과(Key와 Value)를 유지해 두어야 합니다. 이를 ‘KV 캐시(Key-Value Cache)‘라고 부릅니다.

graph TD T["현재 토큰"] --> Q["쿼리(Query)"] T --> K["키(Key)"] T --> V["값(Value)"] K --> KCache["KV 캐시에 추가"] V --> VCache["KV 캐시에 추가"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["스케일링 (1/sqrt(d))"] Scale --> Softmax["소프트맥스(Softmax)"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["컨텍스트 벡터"]

KV 캐시의 메모리 할당도, 사전에 최대 컨텍스트 길이(예를 들어 4096이나 8192 토큰)만큼의 메모리 공간을 아레나에 확보해 두어 링 버퍼처럼 운용합니다. 이를 통해 생성 단계마다 재할당되는 것을 방지할 수 있습니다.

또한 위치 인코딩(Positional Encoding)에는 최근 주류가 된 ‘RoPE(Rotary Position Embedding)‘를 구현합니다. 이는 복소 공간에서의 회전 벡터로 위치 정보를 임베딩하는 기법으로, C++에서의 sin 및 cos 함수 호출 최적화(룩업 테이블 등)가 성능의 열쇠를 쥐고 있습니다.

9. 모델 양자화(Quantization)를 통한 극한의 최적화

대규모 모델(예: 70억 파라미터의 LLaMA 모델)을 FP32(32비트 부동 소수점) 그대로 읽어 들이면 가중치만으로 약 28GB의 메모리(VRAM)를 소비합니다. 여기에 KV 캐시와 추론용 버퍼를 포함하면 30GB를 훌쩍 넘어 일반적인 소비자용 GPU에서는 실행이 불가능합니다.

따라서 필수가 되는 것이 ‘양자화(Quantization)‘입니다. 이는 GGML 포맷의 진면목이기도 합니다.

양자화란 가중치의 정밀도를 의도적으로 낮추는 기술입니다.

FP16 (16-bit): 크기 절반 감소. 정밀도 저하 거의 없음.
INT8 (8-bit): 크기 1/4 감소. 약간의 저하.
INT4 (4-bit): 크기 1/8 감소. 독자적인 블로킹과 스케일링 팩터를 사용하면 실용적인 추론 가능.

추론 엔진 측에서는 메모리에서 INT4(또는 INT8)로 압축된 가중치를 읽어내어, CPU나 GPU의 레지스터에 로드한 직후에 FP16 또는 FP32로 전개(Dequantize)하여 계산을 수행합니다.

놀랍게도 계산량을 늘려서라도 메모리에서 읽어들이는 데이터 양을 줄이는 쪽이 더 빠릅니다. 이는 현대 하드웨어에서 추론 작업의 병목 현상이 ‘계산 능력(Compute Bound)‘이 아니라 ‘메모리 대역폭(Memory Bandwidth Bound)‘에 있기 때문입니다. INT4 양자화를 적용한 C++ 구현 엔진이라면, 8GB VRAM을 가진 MacBook Air 등에서도 쾌적하게 로컬 LLM을 구동할 수 있습니다.

10. 성능 튜닝: NUMA 아키텍처와 스레드 풀

CPU를 이용한 추론을 할 경우 멀티스레딩은 필수입니다. 하지만 단순히 std::thread를 많이 띄우기만 해서는 최적이라 할 수 없습니다.

현대의 멀티 소켓 서버나 Ryzen Threadripper와 같은 하이엔드 CPU에서는 NUMA(Non-Uniform Memory Access) 아키텍처가 채택되어 있습니다. 어떤 CPU 코어에서 물리적으로 가까운 메모리(로컬 메모리)로의 접근은 빠르지만, 다른 프로세서에 연결된 메모리에 접근하는 것은 극단적으로 느려집니다.

고도화된 C++ 추론 엔진에서는 다음과 같은 기술을 구사합니다.

스레드 피닝(Thread Pinning): 각 스레드를 특정 CPU 코어에 고정(Affinity 설정)하여, 컨텍스트 스위치에 의한 캐시 무효화를 방지합니다.
NUMA 인식 할당(NUMA-aware Allocation): 데이터를 처리하는 스레드와 동일한 NUMA 노드 상에 메모리를 확보합니다.
워크 스틸링(Work-stealing) 기반 스레드 풀: 계산 그래프의 각 노드를 작은 태스크로 분할하고, 유휴 스레드가 자동으로 태스크를 훔쳐서(steal) 실행하는 효율적인 스케줄러를 구현합니다.

이들을 구사함으로써 CPU 사용률을 100% 부근에 딱 붙여 이론치에 가까운 처리량을 뽑아낼 수 있습니다.

11. 정리: C++의 ‘근육’으로 AI를 구동하는 즐거움

Python은 확실히 편리합니다. 연구 개발이나 프로토타이핑에 있어 그 생산성을 능가할 언어는 없습니다. 하지만 완성된 모델을 ‘현실 세계에서, 효율적으로, 모든 디바이스에서 구동한다’는 단계로 넘어가는 순간 C++이 나설 차례입니다.

메모리의 바이트 배열을 직접 조작하고, SIMD 명령어로 레지스터를 한계까지 몰아붙이며, GPU의 VRAM 대역폭과 씨름하며 만들어낸 추론 엔진이, 콘솔 상에 연이어 자연스러운 한국어(또는 일본어 등) 텍스트(토큰)를 생성해 나가는 모습을 보았을 때의 성취감은, Python 프레임워크에서 model.generate()를 호출했을 때는 결코 얻을 수 없는 ‘엔지니어로서의 순수한 기쁨’이 있습니다.

‘블랙박스’가 되기 쉬운 AI 기술이지만, 텐서 연산부터 메모리 할당에 이르기까지 모든 것을 내 손으로 C++로 작성함으로써 LLM이 어떻게 ‘생각’하는지 그 진정한 메커니즘을 깊이 이해할 수 있습니다.

만약 여러분이 C++에 대한 기초 지식이 있고 현재의 AI 기술에 강한 흥미가 있다면, 꼭 직접 추론 엔진 개발에 도전해 보시기 바랍니다. GGML이나 llama.cpp의 소스 코드는 최고의 살아있는 교과서가 될 것입니다.

자, Python의 무거운 런타임을 버리고 C++의 근육으로 최첨단 AI를 달리게 합시다!

온프레미스 환경에서 TinyLLaMA를 가장 빠르게 튜닝하는 방법

Fri, 11 Sep 2026 16:00:00 +0900

1. 시작하며: 왜 지금, TinyLLaMA와 온프레미스인가?

대규모 언어 모델(LLM)의 진화는 무서운 속도로 진행되고 있지만, 그에 따라 모델의 파라미터 수도 수천억 규모로 계속 팽창하고 있습니다. GPT-4나 Claude 3와 같은 초거대 모델은 비할 데 없는 성능을 자랑하는 반면, 추론이나 학습에 드는 계산 비용, 그리고 외부 API를 이용할 때의 보안 및 데이터 프라이버시 우려가 기업에게 큰 장애물이 되고 있습니다. 특히 기밀성이 높은 사내 데이터나 개인정보를 다루는 업무에서는 클라우드상의 퍼블릭 LLM API로 데이터를 전송하는 것이 컴플라이언스(GDPR이나 APPI 등) 관점에서 허용되지 않는 경우가 많습니다.

그래서 각광받고 있는 것이 **소규모 언어 모델(SLM: Small Language Models)**과 온프레미스 환경에서의 로컬 운영입니다. 그중에서도 ‘TinyLLaMA‘는 불과 1.1B(11억) 파라미터라는 콤팩트한 크기이면서도 약 3조 토큰이라는 방대한 데이터 세트로 사전 학습되어, 동급 모델과 비교해 경이로운 성능을 발휘합니다.

본 기사에서는 이 TinyLLaMA를 온프레미스 환경(로컬 서버나 워크스테이션)에서 자사 전용 태스크를 위해 ‘가장 빠르고 고효율’로 파인튜닝(미세 조정)하기 위한 완전한 가이드를 제공합니다. 수학적 배경부터 최신 최적화 기술, 그리고 구체적인 PyTorch 구현 코드까지 망라하여 해설해 나갈 것입니다.

2. TinyLLaMA의 아키텍처와 특징

TinyLLaMA는 Meta사가 개발한 LLaMA(Large Language Model Meta AI) 아키텍처를 따르고 있습니다. 파라미터 수를 1.1B로 억제하면서도 LLaMA 2와 같은 기술 스택을 이용하고 있어 생태계 호환성이 매우 높은 것이 특징입니다.

주요 아키텍처 컴포넌트

RMSNorm (Root Mean Square Normalization): 기존의 LayerNorm 계산에서 평균 뺄셈을 생략하여 계산 효율을 향상시킨 정규화 기법입니다. 학습의 안정성을 유지하면서 처리량(throughput)을 향상시킵니다.
SwiGLU 활성화 함수: 피드 포워드 네트워크(FFN)에서 기존의 ReLU나 GELU 대신 SwiGLU를 채택했습니다. 이는 수학적으로 다음과 같이 표현됩니다. $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ 여기서 $\otimes$는 요소별 곱(아다마르 곱)을 나타내며, Swish 함수는 $\text{Swish}(z) = z \cdot \sigma(\beta z)$ 입니다. 이로 인해 표현력이 크게 향상됩니다.
RoPE (Rotary Position Embedding): 절대적 위치 인코딩과 상대적 위치 인코딩의 장점을 결합한 기법입니다. 시퀀스 길이가 확장되었을 때도 높은 일반화 성능을 가집니다.
Grouped Query Attention (GQA): Multi-Head Attention (MHA)와 Multi-Query Attention (MQA)의 중간적인 접근 방식으로, 키와 밸류의 헤드를 그룹화함으로써 메모리 대역폭을 절약하고 추론 속도를 획기적으로 향상시킵니다.

다음 Mermaid 다이어그램은 TinyLLaMA의 전반적인 데이터 흐름과 Transformer 블록 구조를 보여줍니다.

graph TD A["입력 텍스트"] --> B["토크나이저 (BPE)"] B --> C["임베딩 레이어"] C --> D["트랜스포머 블록 (TinyLLaMA용 22개 레이어)"] D --> E["RMSNorm (최종)"] E --> F["선형 투영 (어휘 크기)"] F --> G["출력 확률 (Softmax)"] subgraph "트랜스포머 블록 구조" D1["입력 은닉 상태"] --> D2["RMSNorm"] D2 --> D3["그룹화된 쿼리 어텐션 (GQA)"] D3 --> D4["잔차 연결 (Residual Add)"] D4 --> D5["RMSNorm"] D5 --> D6["SwiGLU FFN"] D6 --> D7["잔차 연결 (Residual Add)"] D7 --> D8["다음 레이어로 출력"] D1 -.-> D4 D4 -.-> D7 end

3. 파인튜닝의 돌파구: LoRA와 QLoRA

온프레미스 환경에서 전체 파라미터의 파인튜닝을 수행하려면 1.1B 모델이라 하더라도 옵티마이저의 상태나 그래디언트를 유지하기 위해 수십 GB의 VRAM(비디오 메모리)을 소비합니다. 제한된 리소스로 효율적인 학습을 수행하기 위해 필수적인 것이 PEFT (Parameter-Efficient Fine-Tuning) 기법인 ‘LoRA‘와 그 양자화 확장인 ‘QLoRA‘입니다.

3.1 LoRA (Low-Rank Adaptation)의 수학적 배경

LoRA는 사전 학습된 가중치 행렬을 고정(프리즈)하고, 그 가중치의 업데이트 양($\Delta W$)을 낮은 랭크를 가진 두 개의 작은 행렬의 곱으로 근사하는 기법입니다.

사전 학습된 가중치를 $W_0 \in \mathbb{R}^{d \times k}$ 라고 합시다. 풀 파인튜닝에서는 $W_0$ 자체를 업데이트하여 $W_0 + \Delta W$ 로 만들지만, LoRA에서는 업데이트 행렬 $\Delta W$ 를 다음과 같이 분해합니다.

$$ \Delta W = B \times A $$

여기서 $B \in \mathbb{R}^{d \times r}$, $A \in \mathbb{R}^{r \times k}$ 이며, $r$은 랭크(Rank)라고 불리는 하이퍼파라미터로, $r \ll \min(d, k)$ 를 만족하는 매우 작은 값(보통 8, 16, 32 등)입니다.

포워드 패스의 계산은 다음과 같습니다.

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

초기 상태에서 행렬 $A$는 정규 분포(가우스 분포)로 무작위 초기화되고, 행렬 $B$는 영행렬로 초기화됩니다. 이에 따라 학습 시작 시의 $\Delta W$는 0이 되어, 베이스 모델의 출력을 완전히 유지한 상태에서 학습을 시작할 수 있습니다.

graph LR X["입력 벡터 x"] --> W0["고정된 사전 학습 가중치 (W_0)"] X --> A["학습 가능한 LoRA 행렬 A (r x k)"] A --> B["학습 가능한 LoRA 행렬 B (d x r)"] W0 --> Add["벡터 덧셈"] B --> Add Add --> Y["출력 벡터 h"]

3.2 QLoRA (Quantized LoRA)의 혁신성

QLoRA는 LoRA의 접근 방식을 더욱 발전시켜 베이스 모델 $W_0$ 를 4-bit 정밀도(NormalFloat 4, NF4)로 양자화하여 메모리에 로드하는 기법입니다. 이를 통해 VRAM 소비량을 획기적으로 줄입니다.

QLoRA에는 3가지 중요한 기술이 포함되어 있습니다.

4-bit NormalFloat (NF4) 양자화: 정규 분포를 따르는 가중치에 최적화된 이론적으로 가장 이상적인 데이터 타입.
Double Quantization (이중 양자화): 양자화 상수(스케일 팩터) 자체도 양자화하여 메모리를 추가로 절약.
Paged Optimizers: NVIDIA의 통합 메모리 기능을 활용하여 VRAM이 부족할 때 옵티마이저의 상태를 CPU의 RAM으로 일시적으로 대피시키는 메커니즘.

이에 따라 보통 16GB~24GB의 VRAM이 필요한 튜닝이 소비자용 GPU(RTX 3060 12GB나 RTX 4070 등)에서도 여유롭게 실행 가능해집니다.

4. 온프레미스 환경에서의 하드웨어 요구사항과 셋업

TinyLLaMA (1.1B)를 QLoRA로 튜닝할 경우 하드웨어 요구사항을 매우 낮출 수 있습니다.

권장 하드웨어 사양

GPU: NVIDIA RTX 3060 (12GB), RTX 3090/4090 (24GB), 또는 NVIDIA A10G/A100 등. VRAM은 최소 8GB만 있어도 동작하지만, 배치 크기를 확보하기 위해서는 12GB 이상을 권장합니다.
CPU: 8코어 이상의 모던 CPU (Intel Core i7/i9, AMD Ryzen 7/9)
RAM: 32GB 이상 (Paged Optimizers를 이용할 경우 VRAM에서의 대피소로서 중요)
스토리지: NVMe SSD (데이터 세트 로딩이나 모델 저장을 가속하기 위함)

소프트웨어 환경 구축

Ubuntu 22.04 LTS 환경을 가정한 셋업 절차입니다. Python 3.10 이상을 사용합니다.

1
2
3
4
5
6
7
8
9


# 가상 환경 생성 및 활성화
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# PyTorch 설치 (CUDA 12.1용)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# 트랜스포머 관련 라이브러리 설치
pip install transformers datasets peft trl accelerate bitsandbytes

5. 가장 빠른 튜닝을 위한 최적화 기술

단순히 스크립트를 돌리는 것뿐만 아니라, ‘가장 빠르게’ 튜닝을 완료하기 위해서는 다음과 같은 최적화 기법을 조합해야 합니다.

5.1 Flash Attention 2

표준적인 어텐션(Attention) 메커니즘은 시퀀스 길이 $N$ 에 대해 시간·공간 계산량이 $O(N^2)$ 가 됩니다. Flash Attention 2는 GPU의 SRAM과 HBM(High Bandwidth Memory) 사이의 메모리 접근을 최적화함으로써 계산량을 줄이지 않고도 I/O 병목을 해소하여 학습 속도를 수 배 끌어올리고 메모리 소비를 급감시킵니다.

5.2 Gradient Checkpointing (그래디언트 체크포인트)

포워드 패스에서 계산된 중간 활성화를 모두 VRAM에 저장하는 것이 아니라 일부만 저장하고, 백워드 패스에서 필요해졌을 때 다시 계산하는 기법입니다. 계산 시간은 약 20% 증가하지만 메모리 소비량을 획기적으로 줄일 수 있기 때문에, 결과적으로 더 큰 배치 크기를 설정할 수 있어 전체적인 처리량이 향상됩니다.

5.3 Mixed Precision Training (혼합 정밀도 학습)과 Bfloat16

GPU의 텐서 코어(Tensor Core)를 최대한 활용하기 위해 학습 시의 계산을 bfloat16 (Brain Floating Point)으로 수행합니다. float16 과 비교하여 지수부의 비트 길이가 float32 와 동일하기 때문에 오버플로·언더플로의 위험이 극히 낮아 학습이 안정됩니다.

6. 실전: TinyLLaMA의 QLoRA 파인튜닝 코드

그러면 위에서 언급한 모든 최적화를 포함한 가장 빠른 튜닝용 PyTorch 스크립트를 해설하겠습니다. 여기서는 Hugging Face의 trl (Transformer Reinforcement Learning) 라이브러리의 SFTTrainer 를 이용합니다.

6.1 데이터 세트 준비 및 모델 로드

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. 모델과 토크나이저 지정
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. QLoRA용 4-bit 양자화 설정
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # 계산은 bfloat16으로 수행
)

# 3. 모델 로드 (Flash Attention 2 활성화)
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # 속도 극대화의 핵심
)

# 4. 토크나이저 로드
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # fp16/bf16 트레이닝 시의 버그 회피를 위해 right로 설정

6.2 LoRA 어댑터 적용 및 데이터 세트 성형

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# 5. k-bit 학습 준비 및 그래디언트 체크포인트 활성화
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. LoRA 설정
peft_config = LoraConfig(
 r=16, # 랭크
 lora_alpha=32, # 스케일링 팩터
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # 모든 Linear 레이어를 타겟으로 하면 성능이 향상됨
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# 출력 예시: trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. 데이터 세트 로드 (여기서는 예시로 일본어 Instruction 데이터 세트를 사용)
# 실제로는 온프레미스의 프라이빗 JSONL 파일 등을 로드합니다.
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 ChatML 포맷이나 프롬프트 템플릿에 맞추어 문자열을 성형합니다.
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 트레이닝 실행

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


# 8. 트레이닝 인자 설정
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # VRAM에 여유가 있다면 올림
 gradient_accumulation_steps=2, # 실질적인 배치 크기 = 8 * 2 = 16
 optim="paged_adamw_32bit", # Paged Optimizer에 의한 VRAM 절약
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # 혼합 정밀도 학습 (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 테스트용으로 500 스텝. 실전에서는 에포크 수로 지정
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. SFTTrainer를 이용한 학습 시작
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # 예상되는 입력 길이에 맞춰 조정
 tokenizer=tokenizer,
 args=training_args,
)

print("Starting training...")
trainer.train()

# 10. LoRA 어댑터 저장
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Training complete and model saved.")

7. 성능 평가 및 트러블슈팅

온프레미스 환경에서 학습을 돌릴 때 자주 직면하는 문제와 그 해결책입니다.

OOM(Out Of Memory)이 발생한다:
- per_device_train_batch_size 를 1 로 낮춥니다.
- gradient_accumulation_steps 를 늘려 실질적인 배치 크기를 유지합니다.
- max_seq_length 를 2048 에서 1024 나 512 로 줄입니다.
Loss가 떨어지지 않는다·발산한다:
- 학습률 (learning_rate)이 너무 클 가능성이 있습니다. 2e-4 에서 5e-5 정도로 낮춰보세요.
- Bfloat16이 아닌 Float16을 사용하고 있을 경우 그래디언트의 언더플로가 일어나고 있을 가능성이 있습니다. bf16=True 를 확인하세요.
추론 시 알 수 없는 문자열이 생성된다:
- padding_side="right" 가 올바르게 설정되어 있는지 확인하세요. 또한 데이터 세트의 포맷(<|im_start|> 등의 특수 토큰)이 베이스 모델의 사전 학습 때와 일치하는지 확인이 필요합니다.

8. 튜닝 후 모델 배포 (Deployment)

튜닝이 완료되면 저장되는 것은 ‘베이스 모델 전체’가 아니라 수 MB~수십 MB의 ‘LoRA 어댑터 (차이점 가중치)‘뿐입니다. 추론을 고속으로 수행하기 위해서는 이 LoRA 가중치를 원래 베이스 모델에 병합(통합)하여 단일 모델로 저장해야 합니다.

모델 병합 스크립트

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# FP16/BF16으로 모델과 어댑터 로드
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# 가중치를 병합하여 저장
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Model merged and saved successfully!")

vLLM을 활용한 초고속 추론 서버 구축

온프레미스 환경에서의 배포에 있어 추론 속도(Tokens per second)를 극대화하기 위해서는 Hugging Face의 표준 pipeline 이 아니라 vLLM이나 TGI (Text Generation Inference) 의 사용을 강력히 권장합니다. vLLM은 PagedAttention 기술을 사용하여 GPU 메모리의 단편화를 방지하고 병렬 요청 처리 능력을 극적으로 향상시킵니다.

다음 Mermaid 다이어그램은 학습부터 추론 서버 배포까지의 파이프라인을 보여줍니다.

graph TD A["원시 프라이빗 데이터"] --> B["전처리 및 포맷팅 (JSONL)"] B --> C["QLoRA 파인튜닝 (SFTTrainer)"] C --> D["LoRA 어댑터 가중치 (.safetensors)"] D --> E["베이스 TinyLLaMA 1.1B와 병합"] E --> F["병합된 모델"] F --> G["vLLM 서버를 통해 배포"] G --> H["API 엔드포인트 / UI (예: 챗봇)"]

vLLM을 사용한 API 서버 실행은 다음 명령어 하나로 완료됩니다.

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

이것으로 OpenAI API 호환 엔드포인트가 온프레미스 환경에 구축되어, 안전하고 빠르게 로컬 AI를 활용할 수 있게 됩니다.

9. 마무리

본 기사에서는 1.1B라는 가벼운 파라미터 수임에도 불구하고 고성능인 ‘TinyLLaMA’를 대상으로 온프레미스 환경에서 가장 빠르고 메모리 효율적으로 파인튜닝을 수행하는 기법을 해설했습니다.

LoRA / QLoRA 를 통해 소비자용 GPU에서도 본격적인 LLM 튜닝이 가능해졌습니다.
Flash Attention 2 와 Gradient Checkpointing 을 구사하여 학습 시간과 VRAM 소비를 극한까지 최적화했습니다.
vLLM 을 활용한 배포로 프로덕션 환경에서도 높은 처리량을 실현했습니다.

온프레미스에서의 로컬 LLM 운영은 데이터의 기밀성을 보호할 뿐만 아니라, 특정 도메인(법무, 의료, 사내 규정 등)에 특화된 전문 AI를 저비용으로 구축하기 위한 최강의 무기가 됩니다. 꼭 본 가이드를 참고하여 자사 전용의 TinyLLaMA를 육성해 보시기 바랍니다.

AI 시대의 프로그래머는 어떻게 살아남아야 하는가?

Fri, 11 Sep 2026 15:00:00 +0900

AI 시대의 프로그래머는 어떻게 살아남아야 하는가? 코딩의 종말과 새로운 엔지니어링의 서막

2026년 현재, 소프트웨어 개발 현장은 그 어느 때보다 격변기를 맞이하고 있다. 불과 몇 년 전만 해도 ‘AI가 코드를 작성한다’는 개념은 기껏해야 보일러플레이트(상용구 코드) 생성이나 함수의 자동 완성 같은 프로그래머의 ‘보조 도구’ 역할에 머물러 있었다. 하지만 대규모 언어 모델(LLM)의 경이적인 진화로 인해 상황은 근본적으로 뒤집혔다. 현대의 AI는 단순한 ‘똑똑한 타자기’가 아니라, 요구사항 정의서를 주면 프론트엔드부터 백엔드의 로직, 데이터베이스의 스키마 설계, 심지어 CI/CD 파이프라인 구축에 이르기까지 시스템 전체를 순식간에, 그리고 자율적으로 조립하는 능력을 갖춘 ‘자율형 주니어 엔지니어’로 변모했다.

이러한 시대에 우리 ‘프로그래머’나 ‘소프트웨어 엔지니어’는 어떻게 살아남아야 할까? ‘코드를 작성한다’는 행위 자체의 경제적 가치가 급속히 디플레이션되는 가운데, 단지 특정 프로그래밍 언어의 문법(신택스)을 알고 특정 프레임워크의 API에 정통할 뿐인 ‘코더’는 급속히 시장에서 도태되고 있다.

본고에서는 AI 시대에 프로그래머의 생존 전략에 대해 기술적, 수학적, 그리고 철학적 관점에서 극히 상세하게 고찰해 본다. 이는 단순한 커리어론이 아니라, 소프트웨어 엔지니어링이라는 학문 자체의 재정의이다.

1. 추상화(Abstraction)의 역사와 ‘프로그래밍’의 재정의

소프트웨어 엔지니어링의 역사를 되돌아보면, 그것은 항상 ‘추상화(Abstraction)‘의 역사였음을 알 수 있다. 우리는 항상 더 인간에 가까운 언어로 더 복잡한 시스템을 기술하기 위한 레이어를 구축해 왔다.

초기 컴퓨터 과학자들은 천공 카드를 사용하여 물리적인 하드웨어의 스위치를 직접 조작하고 기계어(0과 1의 나열)로 컴퓨터에 지시를 내렸다. 그 후 어셈블리어(Assembly Language)가 등장하여 인간이 이해하기 쉬운 니모닉(Mnemonic)으로 하드웨어를 조작할 수 있게 되었다. 시대가 더 지나 C언어나 Fortran 같은 고급 언어가 등장하여 메모리 관리나 CPU의 레지스터와 같은 하드웨어의 복잡한 세부 사항을 캡슐화하는 데 성공했다. 이어서 등장한 Java, Python, Ruby, TypeScript 등의 모던한 언어로 인해 프로그래머는 ‘컴퓨터를 어떻게 움직일 것인가(How)‘가 아니라 ‘컴퓨터에게 무엇을 시킬 것인가(What)‘에 더욱 집중할 수 있게 되었다.

AI(LLM)의 등장은 이 추상화의 역사에 있어서 가장 최신이자 최대의 패러다임 시프트이다. 프로그래밍 언어의 진화가 ‘하드웨어의 은닉’이었다고 한다면, LLM의 진화는 ‘신택스(문법)의 은닉’이다.

graph TD A["기계어 / 천공 카드 (1940년대)"] --> B["어셈블리어 (1950년대)"] B --> C["컴파일형 고급 언어 (1970년대)"] C --> D["매니지드 / 스크립트 언어 (1990년대)"] D --> E["LLM을 통한 자연어 (2020년대)"] E --> F["자율형 AI 에이전트 (2026-)"] style E fill:#f9f,stroke:#333,stroke-width:2px style F fill:#fbb,stroke:#333,stroke-width:2px

더 이상 개발자가 메모리 누수를 걱정하며 포인터를 조작하거나, JSON 파싱 처리를 위한 정형 코드를 수백 줄씩 쓰는 시대는 끝났다. 자연어(한국어나 영어)라는, 인류에게 가장 추상도가 높은 언어를 사용하여 시스템을 정의하는 것이 2026년의 ‘프로그래밍’ 표준이 되었다.

2. 생산성의 수학적 모델: 기하급수적 성장의 파도에 올라타라

AI가 가져오는 생산성의 향상을 수학적 모델을 사용하여 정량적으로 평가해 보자. 기존 소프트웨어 개발에서 개인의 생산성 $P_{traditional}$은 개인의 스킬 수준 $S$, 도메인 경험 $E$, 그리고 도구의 효율성 $T$의 선형적인 조합으로 모델링할 수 있었다.

$$ P_{traditional} = c_1 \cdot S + c_2 \cdot E + c_3 \cdot T $$

하지만 AI를 활용한 현대의 개발에 있어서는, AI의 능력 $A(t)$가 인간의 능력을 증폭시키는 ‘강력한 레버리지(Multiplier)‘로서 작용한다. AI의 능력은 시간의 경과 $t$와 함께 기하급수적으로 성장(무어의 법칙의 AI 버전)하기 때문에, AI 시대의 생산성 $P_{AI}(t)$는 다음과 같은 방정식으로 나타낼 수 있다.

$$ P_{AI}(t) = \alpha \cdot S_{core} \cdot e^{\beta \cdot A(t)} $$

여기서 각 변수는 다음을 의미한다.

$\alpha$: 기초가 되는 인간의 생산성 계수
$S_{core}$: AI로 대체되지 않는 ‘인간의 핵심 스킬’(아키텍처 설계, 비즈니스 요구사항 이해, 윤리적 판단 등)
$A(t)$: 시간 $t$에서의 AI 모델의 절대적인 능력(파라미터 수, 컨텍스트 창, 추론 능력)
$\beta$: AI 도구를 얼마나 효과적으로 이끌어낼 수 있는가(프롬프트 엔지니어링의 질이나 AI와의 협업 워크플로우의 세련도)를 나타내는 계수

이 수식에서 도출되는 중요한 통찰은, $A(t)$가 기하급수적으로 증대하는 세계에서는 단순한 타이핑 속도나 특정 언어의 암기 같은 기존의 스킬이 전체 생산성에 미치는 영향이 극히 작아진다는 것이다. 대신, 기하급수적인 AI 성장에 편승하기 위한 계수 $\beta$와 AI가 커버할 수 없는 영역인 $S_{core}$가 엔지니어의 시장 가치를 결정짓는 지배적인 요인이 된다.

3. 작업의 자동화 확률(Probability of Automation)

그렇다면 어떤 작업이 자동화되고 어떤 작업이 인간의 손에 남게 될 것인가? 어떤 작업 $T$가 AI에 의해 완전히 자동화될 확률 $P_{auto}(T)$는 다음과 같이 정식화할 수 있다.

$$ P_{auto}(T) = 1 - \exp\left(-\lambda \cdot \frac{\text{Predictability}(T)}{\text{Complexity}(T) \times \text{Context Dependency}(T)}\right) $$

$\text{Predictability}(T)$: 작업의 예측 가능성(과거의 데이터에 패턴이 얼마나 존재하는가)
$\text{Complexity}(T)$: 작업의 복잡성
$\text{Context Dependency}(T)$: 작업이 의존하는 ‘암묵적인 컨텍스트(도메인 고유의 지식이나 인간관계)‘의 강도
$\lambda$: AI의 기술 진보율

API 라우팅 처리를 작성하거나 단순한 CRUD 화면을 만드는 등의 예측 가능성이 높고 컨텍스트 의존성이 낮은 작업은 $P_{auto} \approx 1$이 되어 거의 완전히 자동화된다. 반면, ‘기존의 레거시 시스템과 새로운 마이크로서비스를 어떻게 안전하게 통합할 것인가’나 ‘법무 부서의 요구를 충족하면서도 사용자 경험을 해치지 않는 인증 플로우를 어떻게 설계할 것인가’와 같이 컨텍스트 의존성이 극히 높은 작업은 자동화하기 어렵다.

4. 신택스(문법)에서 아키텍처(구조)로의 회귀

AI가 잘하는 것과 인간이 잘하는 것을 명확하게 분리하는 것이 생존의 절대 조건이 된다.

graph LR Sub1["AI가 뛰어난 영역"] Sub2["인간이 뛰어난 영역"] A["사양서로부터의 코드 생성"] --> Sub1 B["문법 오류 및 버그 수정"] --> Sub1 C["보일러플레이트 / 테스트 생성"] --> Sub1 D["로그 분석 및 패턴 매칭"] --> Sub1 E["시스템 아키텍처 설계"] --> Sub2 F["모호한 요구사항 해결"] --> Sub2 G["팀 간의 협상"] --> Sub2 H["윤리적 판단 / 책임"] --> Sub2

AI는 ‘국소적인 최적화’에 있어 인간을 능가한다. 하나의 함수, 하나의 클래스, 또는 단일 모듈을 기술하는 속도와 정확성에 있어서 인간은 승산이 없다. 하지만 AI는 ‘전역적인 최적화’나 ‘컨텍스트의 결여(Missing Context)‘에 대해서는 매우 취약하다.

앞으로의 프로그래머는 ‘코드를 작성하는 노동자’에서 ‘AI가 생성한 무수한 컴포넌트를 오케스트레이션하는 아키텍트’로 역할을 바꿔야 한다. 시스템 전체를 조감하고, 마이크로서비스의 경계를 어디에 그을지, CAP 정리에서의 가용성과 일관성의 트레이드오프를 비즈니스 문맥에 맞춰 어떻게 해결할지, 기술 부채를 어떻게 제어할지. 이들은 전체 그림과 비즈니스 목표를 이해하고 있는 인간만이 할 수 있는 고도의 지적 작업이다.

5. 요구사항 정의야말로 ‘진정한 프롬프트 엔지니어링’이다

최근 자주 듣는 ‘프롬프트 엔지니어링’이라는 말은 종종 ‘AI를 속여 원하는 출력을 얻어내기 위한 핵(hack)‘처럼 오해받곤 한다. 하지만 소프트웨어 개발에서의 프롬프트 엔지니어링의 본질은 틀림없는 **‘고도의 요구사항 정의(Requirements Engineering)’**이다.

자연어로 AI에게 지시를 내리고 의도한 대로 소프트웨어를 출력하게 만들기 위해서는 다음과 같은 요소들을 엄밀하게 언어화해야 한다.

목적(Why): 왜 이 기능이 필요한가. 비즈니스적 가치는 무엇인가.
제약 조건(Constraints): 성능 요구사항(레이턴시, 처리량), 보안 요구사항, 비용 제약.
엣지 케이스(Edge Cases): 사용자가 예기치 않은 입력을 했을 경우의 폴백(Fallback) 처리.
인터페이스(Interfaces): 기존 시스템과의 연동 사양.

모호한 지시(프롬프트)에서는 모호하고 취약한 시스템밖에 나오지 않는다. ‘고객이 진정으로 원했던 것’을 깊이 청취하고, 모순되는 요구사항을 정리하며, 논리적인 파탄이 없는 사양서(프롬프트)를 작성하는 능력. 이것이야말로 AI 시대의 최강의 ‘코딩 스킬’이다. 프로그래머는 코드 에디터가 아닌 Notion이나 Markdown 파일을 마주하고 시스템의 이상적인 모습을 텍스트로 정교하게 기술하는 시간이 늘어날 것이다.

6. 도메인 지식(Domain Knowledge)의 압도적 우위성

AI는 전 세계의 오픈 소스 코드나 공개 문서를 학습하고 있기 때문에 일반적인 웹 기술이나 알고리즘에는 정통하다. 하지만 AI가 접근할 수 없는 데이터가 있다. 그것은 ‘여러분의 회사 고유의 비즈니스 규칙’이며, ‘특정 업계(의료, 금융, 제조 등)에 깊이 뿌리내린 도메인 지식’이다.

예를 들어, 어떤 의료계 스타트업에서 전자 의무 기록 시스템을 개발하고 있다고 하자. AI는 ‘React로 표 형식의 UI를 만드는 방법’이나 ‘HL7 FHIR의 일반적인 데이터 구조’는 알고 있다. 하지만 ‘A병원의 특정 진료과에서 의사가 어떤 순서로 환자의 데이터를 열람하고, 어떤 UI여야 의료 실수의 위험을 최소화할 수 있는가’라는 암묵지까지는 학습하지 못했다.

기술 자체가 코모디티화(범용화)되는 세계에서 엔지니어의 진정한 가치는 ‘테크놀로지’와 ‘비즈니스 도메인’의 교차점에서 태어난다. 기술력만으로 승부하는 것이 아니라 의료, 금융, 물류, 엔터테인먼트 등 특정 도메인에 대한 깊은 전문 지식을 가지고, 그 도메인의 과제를 AI라는 강력한 도구를 사용하여 해결할 수 있는 인재가 앞으로의 시장을 견인해 나갈 것이다.

7. 소프트웨어 개발의 ‘트롤리 딜레마’: 누가 책임을 질 것인가

AI에 대한 의존도가 높아짐에 따라 우리는 중대한 철학적, 윤리적 문제에 직면하게 된다. 소프트웨어 엔지니어링에서의 ‘책임의 소재’라는 문제이다.

만약 AI가 자율적으로 생성한 코드가 프로덕션 환경에서 심각한 버그를 일으켜 기업에 수억 원의 손실을 입히거나, 인명과 관련된 의료 시스템에서 오작동을 일으켰을 경우, 누가 그 책임을 질 것인가? AI 모델을 개발한 기업인가? 아니면 프롬프트를 입력한 엔지니어인가? AI를 ‘해고’하거나 ‘체포’할 수는 없다.

시스템이 사회에 미치는 영향에 대한 ‘법적, 윤리적 책임(Accountability)‘을 떠맡는 주체로서의 ‘인간’의 역할은 기술이 아무리 진화하더라도 소멸하지 않는다. 오히려 코드의 생성 프로세스가 블랙박스화될수록 인간은 시스템에 대한 ‘최종 승인자(Approver)’ 및 ‘감독자(Supervisor)‘로서 무거운 책임을 지게 된다.

AI가 제시한 아키텍처나 코드가 보안 기준을 충족하는지, 윤리적으로 문제가 없는지(편향이 포함되어 있지 않은지), 컴플라이언스를 준수하고 있는지를 감사하고 최종적인 GO 사인을 내린다. 이 ‘책임을 지는’ 행위 자체가 엔지니어의 중요한 업무 중 일부가 된다.

8. AI 페어 프로그래밍과 인지 부하(Cognitive Load) 관리

AI와 함께 일함에 있어 인간의 ‘인지 부하(Cognitive Load)‘의 성질도 변화하고 있다. 제로에서 코드를 작성할 때의 인지 부하와, AI가 생성한 수백 줄의 미지의 코드를 ‘읽고 리뷰하는’ 때의 인지 부하는 전혀 다르다.

심리학의 인지 부하 이론에 따르면, 기존의 스키마(머릿속의 지식 구조)와 일치하지 않는 복잡한 정보를 처리할 때 인간의 작업 기억(Working Memory)은 금세 고갈된다. AI가 생성한 코드는 때로 인간이 생각하지 못한 고도의 최적화를 포함하고 있는 반면, 컨텍스트를 무시한 ‘환각(Hallucination)‘을 포함하고 있을 때도 있다.

이를 방지하기 위해서는 AI에 대한 리뷰 프로세스를 시스템화할 필요가 있다.

sequenceDiagram participant H as "인간 엔지니어 (아키텍트)" participant A as "AI 에이전트" participant S as "CI/CD & 테스팅" H->>A: "엄격한 요구사항 및 제약 조건 정의" A->>H: "아키텍처 및 초기 코드 제안" Note over H,A: 리뷰 단계: 높은 인지 부하 H->>A: "설계 선택 비판, 리팩토링 요청" A->>S: "최종 코드 생성 및 푸시" S-->>H: "자동화된 테스트 결과 및 정적 분석" H->>H: "최종 승인 및 책임 인수"

인간은 ‘작성하는’ 스킬 이상으로, ‘속독하고 논리적 결함을 순식간에 간파하는(Code Reading & Auditing)’ 스킬을 극한까지 끌어올려야 한다. 테스트 주도 개발(TDD)의 중요성은 AI 시대에 더욱 커지고 있다. AI에게 코드를 작성하게 하기 전에 인간 또는 다른 AI가 엄밀한 테스트 코드를 작성하고, 그 테스트를 통과할 때까지 AI에게 코드를 수정하게 하는 접근법이 주류가 될 것이다.

9. 구체적인 생존 전략: 내일부터 무엇을 배워야 하는가

지금까지의 분석을 바탕으로, 프로그래머가 AI 시대를 살아남기 위한 구체적인 액션 플랜을 제시한다.

기술의 ‘기초’를 철저하게 다시 배운다: 프레임워크의 사용법은 AI에게 맡기면 된다. 하지만 OS의 원리, 네트워크 프로토콜(TCP/IP, HTTP/3), 데이터베이스의 내부 구조(B-Tree, 트랜잭션 격리 수준), 자료 구조와 알고리즘에 대한 깊은 이해는 절대적으로 필요하다. AI의 출력이 올바른지 판단하기 위해서는 컴퓨터 과학의 확고한 기초가 필수적이다.
클라우드 아키텍처와 분산 시스템을 마스터한다: 개별 코드가 아니라 AWS, GCP, Azure 같은 클라우드 리소스를 어떻게 조합하여 확장 가능한 시스템을 구축할 것인가에 주력한다. Terraform 등 IaC(Infrastructure as Code)의 개념을 이해하고 시스템 전체를 코드로 설계하는 능력을 기른다.
비즈니스 도메인의 전문가가 된다: 자신이 속한 업계의 비즈니스 모델, 법적 규제, 사용자의 행동 심리를 깊이 배운다. 엔지니어의 틀을 넘어 프로덕트 매니저(PM)에 가까운 시각을 가져야 한다.
커뮤니케이션과 퍼실리테이션 스킬을 연마한다: 인간과 인간 사이에 있는 ‘모호함’을 해결하고 합의를 도출하는 프로세스는 AI가 대체할 수 없다. 이해관계자와 대화하고 진정한 과제를 발견하는 소프트 스킬은 가장 가치 있는 스킬이 될 것이다.
AI를 ‘동료’로 철저히 활용한다: AI 도구의 진화를 두려워할 것이 아니라 가장 강력한 무기로 활용한다. 최신 LLM이나 AI 코딩 에이전트를 일상적으로 사용하고, AI가 어디에서 실패하는지, 프롬프트를 어떻게 고안해야 최고의 퍼포먼스를 끌어낼 수 있는지에 대한 ‘암묵지’를 축적한다.

결론: 두려워하지 말고 파도에 올라타라

AI에 의한 프로그래밍의 자동화는 프로그래머라는 직업의 ‘죽음’을 의미하는 것이 아니다. 오히려 오타 수정이나 환경 구축의 트러블 슈팅, 지루한 보일러플레이트 작성과 같은 소프트웨어 개발에서의 ‘본질적이지 않은 노동’으로부터 우리를 해방시켜 주는 **‘르네상스(문예 부흥)’**이다.

역사상 자동 방직기가 등장했을 때도, 스프레드시트(Excel)가 등장했을 때도 일자리가 소멸할 것이라는 비관론이 만연했다. 하지만 현실은 생산성이 비약적으로 향상됨으로써 새로운 수요가 창출되었고, 더 고도화된 일자리가 생겨났다. 소프트웨어 세계에서도 같은 일이 일어날 것이다. ‘저렴하게 시스템을 만들 수 있게’ 됨으로써, 지금까지 비용이 맞지 않아 IT화되지 않았던 모든 영역에 소프트웨어가 침투하고 엔지니어가 해결해야 할 과제(What)는 무한히 넓어질 것이다.

우리 프로그래머는 지금, 코드를 작성하는 장인에서 AI라는 강대한 지능을 지휘하는 ‘오케스트라의 지휘자’로 진화할 기회를 부여받고 있다. 기술의 파도에 겁을 먹고 물가에 머무를 것이 아니라, 그 파도에 누구보다 먼저 올라타 더 크고 가치 있는 시스템을 창조하는 여행으로 노를 저어 나가자. AI 시대야말로 진정한 의미에서의 ‘엔지니어링’이 시작되는 시대인 것이다.

C++로 시작하는 소규모 AI 모델(TinyLLaMA 등) 개발 절차

Fri, 11 Sep 2026 14:00:00 +0900

C++로 시작하는 소규모 AI 모델(TinyLLaMA 등) 개발 절차

최근 대규모 언어 모델(LLM)을 로컬 환경에서 실행하는 것에 대한 관심이 급속히 높아지고 있습니다. 특히 TinyLLaMA(1.1B 파라미터)와 같은 소규모 모델은 제한된 리소스의 엣지 디바이스나 일반적인 노트북(Windows 환경 포함)에서도 실용적인 속도로 추론이 가능합니다. Python과 PyTorch를 이용한 개발이 주류인 반면, 궁극의 퍼포먼스와 메모리 절약을 추구할 경우 C++와 C언어 기반의 텐서 라이브러리인 ‘ggml’의 조합이 사실상의 표준이 되고 있습니다.

본 기사에서는 C++를 사용하여 TinyLLaMA를 로드하고, 텍스트 생성을 수행하기 위한 추론 엔진을 제로부터 구축(혹은 기존 llama.cpp의 내부 구조를 깊이 이해)하기 위한 매우 상세한 개발 절차를 해설합니다.

1. 왜 C++와 ggml인가?

AI 학습 단계에서는 유연성과 풍부한 생태계를 가진 Python이 압도적으로 유리합니다. 하지만 배포나 ‘추론(Inference)’ 단계에서는 다음과 같은 이유로 C++가 강력한 선택지가 됩니다.

오버헤드 감소: Python의 글로벌 인터프리터 락(GIL)이나 런타임 오버헤드를 완전히 배제할 수 있습니다.
메모리 효율과 아레나 할당: 메모리 확보 및 해제를 수동으로 제어할 수 있으므로 가비지 컬렉션으로 인한 예측 불가능한 스파이크를 방지할 수 있습니다.
하드웨어 직접 접근: AVX-512, AVX2, ARM NEON 등 SIMD 내장 함수(Intrinsics)를 직접 호출하여 CPU의 연산 능력을 극한까지 끌어올릴 수 있습니다.
의존성 배제: ggml은 의존성이 전혀 없는(Zero dependencies) C/C++ 라이브러리이며 컴파일러만 있다면 Windows의 MSVC 환경에서도 쉽게 빌드할 수 있습니다.

2. 아키텍처의 전체 구조

추론 파이프라인 전체의 흐름을 아래 Mermaid 다이어그램에 나타냅니다. 사용자의 입력 텍스트부터 시작하여 최종적으로 다음 토큰이 생성될 때까지의 일련의 과정입니다.

graph TD A["사용자 입력 텍스트"] --> B["BPE 토크나이저"] B --> C["토큰 ID 배열"] C --> D["임베딩 레이어 조회"] D --> E["트랜스포머 블록"] E --> F["RMSNorm"] F --> G["LM 헤드 레이어"] G --> H["로짓 배열"] H --> I["샘플러 모듈"] I --> J["다음 토큰 ID"] J --> K["디토크나이저"] K --> L["출력 텍스트 청크"] J -.-> |"컨텍스트에 추가"| C

자기 회귀 모델이므로 출력된 토큰은 다시 컨텍스트에 추가되어 다음 토큰 예측을 위한 입력으로 순환합니다(그림의 점선 부분).

3. 모델 포맷과 메모리 매핑 (mmap)

거대한 신경망의 가중치를 다루는 데 있어 가장 큰 장벽은 디스크 I/O와 메모리 소비입니다. C++ 구현에서는 이를 **메모리 매핑(mmap)**으로 해결합니다.

3.1 메모리 매핑의 원리와 Windows에서의 구현

mmap을 사용하면 파일 내용을 프로세스의 가상 메모리 공간에 직접 매핑할 수 있습니다.

제로 카피(Zero-copy): 데이터는 디스크에서 커널의 페이지 캐시로 직접 로드되며 사용자 공간으로의 불필요한 복사가 발생하지 않습니다.
온디맨드 로드(Page Fault): 실제로 CPU가 해당 메모리 주소에 접근하는 순간 페이지 폴트가 발생하며, 필요한 청크(일반적으로 4KB)만 물리 메모리에 로드됩니다.

Windows 환경에서는 POSIX의 mmap 대신 Win32 API의 CreateFileMapping과 MapViewOfFile을 사용합니다.

sequenceDiagram participant OS["Windows OS"] participant RAM["물리 메모리"] participant App["C++ 애플리케이션"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "가상 메모리 주소 포인터" App->>App: "포인터에서 텐서 데이터 읽기" OS->>RAM: "페이지 폴트 / 디스크에서 페이지 로드" RAM-->>App: "SIMD 연산용 데이터 준비 완료"

3.2 GGUF 포맷의 바이너리 구조

Hugging Face 등의 .safetensors 포맷에서 변환된 **GGUF (GPT-Generated Unified Format)**는 추론을 위한 궁극적인 포맷입니다. 다음과 같은 엄격한 바이너리 레이아웃을 갖습니다.

Magic Bytes: 0x46554747 (GGUF).
Version: 포맷의 버전 번호.
Tensor Count & Metadata Count: 텐서 개수와 메타데이터의 키-값 쌍 개수.
Metadata (Key-Value Pairs): 문자열 길이 접두사가 붙은 키와 타입이 지정된 값.
Tensor Info: 각 텐서의 이름, 차원 수, 데이터 타입(FP16, Q4_K 등), 파일 내의 오프셋 위치.
Padding: 텐서 데이터가 특정 경계(일반적으로 32바이트 또는 64바이트)에 정렬되도록 삽입되는 패딩. SIMD 명령(특히 AVX)에서의 빠른 메모리 접근에 필수적입니다.
Tensor Data: 정렬된 실제 가중치 데이터 배열.

4. TinyLLaMA의 수학적 기반과 C++ 알고리즘

TinyLLaMA는 효율화를 위해 몇 가지 고도화된 아키텍처적 개선을 도입했습니다. 이를 C++로 올바르게 구현하기 위한 수식 표현을 해설합니다.

4.1 RMSNorm (Root Mean Square Normalization)

LayerNorm에서 평균 중심화(centering)를 생략하고 분산 스케일링만 수행함으로써 계산 비용을 절감합니다.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$는 차원 수, $\gamma$는 학습된 스케일링 텐서입니다. C++로 구현할 경우 먼저 배열의 제곱합을 AVX2의 _mm256_fmadd_ps 등으로 빠르게 계산하고 역제곱근(_mm256_rsqrt_ps 명령 등)을 곱하여 최적화합니다.

4.2 RoPE (Rotary Position Embedding)

토큰의 위치 정보를 텐서 공간에서의 회전(Rotate)으로 적용하는 기술입니다. 복소 평면 위에서의 회전으로 간주할 수 있으며, 벡터 $x$의 인접한 차원 쌍 $(x_1, x_2)$에 대해 다음과 같은 회전을 적용합니다.

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

여기서 $m$은 토큰의 절대적인 위치 인덱스, $\theta$는 사전 계산된 기본 주파수입니다. ggml에서는 추론 그래프 구축 중에 ggml_rope 연산자를 추가하기만 하면 병렬로 실행됩니다.

4.3 Grouped-Query Attention (GQA)

일반적인 Multi-Head Attention(MHA)에서는 Query, Key, Value 각각에 대해 동일한 수의 헤드를 갖습니다. 그러나 TinyLLaMA는 메모리 대역폭과 KV 캐시 소비량을 극적으로 줄이기 위해 **Grouped-Query Attention(GQA)**을 채택했습니다.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

GQA에서는 여러 Query 헤드가 하나의 Key/Value 헤드를 공유합니다. C++ 구현에서는 행렬 곱 ggml_mul_mat를 실행하기 전에 KV 텐서를 Query의 수에 맞게 브로드캐스트하는 작업이 필요합니다.

4.4 SwiGLU 활성화 함수

Feed-Forward Network (FFN) 계층에서는 GELU 대신 SwiGLU가 사용됩니다.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

계산 그래프에서는 ggml_silu 연산자와 ggml_mul을 조합하여 표현합니다.

5. ggml을 통한 계산 그래프 구축 및 메모리 관리

ggml은 추론을 위한 정적인 계산 그래프를 구축하고 이를 나중에 평가(evaluate)하는 ‘Define-and-Run’ 방식을 취합니다.

5.1 ggml_context와 아레나 할당자

ggml의 가장 독특한 점은 추론 루프 내에서 동적인 메모리 할당(malloc이나 new)을 일절 수행하지 않는 ‘아레나 할당’입니다. 초기화 시 거대한 연속된 메모리 영역(아레나)을 확보하고, ggml_new_tensor 등을 호출할 때마다 이 영역의 포인터가 증가합니다. 추론의 1단계가 완료되면 할당 포인터를 초기 위치로 재설정하기만 하면 다음 추론 단계를 위한 메모리 확보가 즉시 완료됩니다.

5.2 그래프 구축의 구체적인 예

추론 단계마다 다음과 같은 계산 그래프를 메모리상에 조립합니다.

graph TD A["토큰 입력 ID"] --> B["임베딩 조회"] B --> C["ggml_rms_norm"] C --> D["Q / K / V 프로젝션"] D --> E["ggml_rope 위치 인코딩"] E --> F["KV 캐시 저장"] E --> G["KV 캐시 로드"] G --> H["셀프 어텐션"] H --> I["스케일 & 소프트맥스"] I --> J["어텐션 출력"] J --> K["출력 프로젝션"] K --> L["잔차 연결 추가"]

6. 양자화 (Quantization)와 Windows / SIMD 최적화

TinyLLaMA (1.1B)를 FP16으로 다루면 약 2.2GB의 메모리가 필요하지만, 4비트 양자화(Q4_K 등)를 통해 약 600MB 정도까지 극적으로 압축할 수 있습니다.

6.1 블록 양자화 아키텍처

ggml은 텐서 전체를 일률적으로 양자화하는 것이 아니라 ‘블록’ 단위로 수행합니다. Q4_0 포맷에서는 32개의 FP16 값을 1개의 블록으로 묶습니다.

스케일 팩터: 1개의 FP16 값 (2바이트)
양자화 데이터: 32개의 4비트 값 (16바이트) 이를 통해 국소적인 이상치의 영향을 최소화합니다.

6.2 AVX2를 통한 내적 연산 가속

Windows 환경의 최신 x86 CPU를 대상으로 빌드할 경우 /arch:AVX2 등의 컴파일러 플래그를 활용하여 다음과 같은 흐름으로 SIMD 처리가 이루어집니다.

로드: 256비트 AVX 레지스터에 메모리로부터 4비트 양자화 데이터를 로드합니다.
전개 및 언팩: 비트 마스크와 시프트 연산으로 4비트 값을 Int8 또는 Int16으로 전개합니다.
역양자화: 스케일 팩터를 곱하여 부동소수점으로 변환합니다.
FMA 연산: 활성화 값과 _mm256_fmadd_ps(Fused Multiply-Add)를 사용하여 곱셈-덧셈(積和) 연산을 병렬로 실행합니다.

7. KV 캐시의 구현 세부 사항

자기 회귀적 생성에 있어 과거 토큰의 Key와 Value 계산을 생략하기 위한 ‘KV 캐시’는 필수 기능입니다.

C++로 구현할 때의 핵심은 다음과 같습니다.

텐서 사전 확보: 최대 컨텍스트 길이(예: 2048 토큰)만큼의 거대한 텐서를 KV 캐시용으로 초기화합니다(FP16 권장).
오프셋 복사: 토큰 위치 $N$에 대한 계산이 수행되면 해당 단계에서 얻은 K와 V 벡터를 KV 캐시 텐서의 $N$번째 행에 ggml_cpy 등을 사용하여 저장(store)합니다.
어텐션 시의 뷰 생성: 어텐션을 계산할 때는 0부터 $N$번째 토큰 부분까지만 가리키는 ‘뷰(view)‘를 생성하여 행렬 곱에 전달합니다.

8. BPE 토크나이저와 디코딩

입력 문자열을 UTF-8 바이트 열로 취급하여 사전에 정의된 어휘 사전(Vocabulary)과 대조합니다. C++에서는 어휘 사전 검색을 가속화하기 위해 **트라이 트리(Trie tree)**나 우선순위 큐를 사용한 알고리즘을 구현합니다.

LM Head에서 출력되는 로짓(logit)에서는 Temperature 파라미터를 사용하여 확률을 스케일링하고 Top-K 추출이나 Top-P(Nucleus Sampling) 기법으로 후보를 좁힌 뒤, 난수를 사용하여 최종적인 다음 토큰을 결정합니다.

9. C++ 프로젝트 시작 (Windows / PowerShell 환경)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Windows (MSVC)를 위한 최적화 및 AVX2 플래그 설정
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

PowerShell에서의 빌드 명령어 예시:

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. 요약

C++와 ggml을 사용하여 TinyLLaMA와 같은 소규모 AI 모델의 추론 엔진을 제로부터 구현하는 것은 딥러닝의 블랙박스를 파헤치고 저수준 하드웨어 제어의 아름다움을 배울 수 있는 절호의 기회입니다. 메모리 매핑을 이용한 제로 카피 로드, SIMD 최적화, KV 캐시 구축 등 시스템 프로그래밍의 정수를 마음껏 맛보며 엣지 AI의 미래를 개척해 봅시다.

【RAG 구현 입문】 로컬 AI에 내 문서를 읽게 하는 방법

Fri, 11 Sep 2026 13:00:00 +0900

들어가며

최근 대규모 언어 모델(LLM)의 진화는 눈부시며, ChatGPT와 Claude 등을 필두로 많은 AI가 우리의 생활과 업무에 스며들고 있습니다. 하지만 일반적인 LLM에는 명확한 약점이 존재합니다. 바로 ‘학습 시점의 공개 정보’밖에 모른다는 점입니다. 사내 규정, 개인적인 메모, 미공개 프로젝트 자료와 같은 ‘비공개 문서’와 관련된 질문에는 당연히 대답할 수 없습니다. 무리하게 대답을 유도하면 사실과 다른 그럴듯한 거짓말(환각, Hallucination)을 생성할 위험이 커집니다.

그래서 현재 전 세계적으로 폭발적으로 보급되고 있는 것이 RAG(Retrieval-Augmented Generation: 검색 증강 생성) 라는 기술 아키텍처입니다. RAG를 사용하면 LLM에 독자적인 지식을 외부 데이터베이스로부터 동적으로 제공하고, 이를 바탕으로 정확하고 근거 있는 답변을 생성하게 할 수 있습니다.

또한, 엔터프라이즈 영역이나 개인의 기밀 정보를 다룰 경우, OpenAI와 같은 클라우드 기반 API에 데이터를 전송하는 것은 보안 정책상 허용되지 않는 경우가 많습니다. 여기서 요구되는 것이 로컬 AI(자신의 PC나 온프레미스 서버에서 독립적으로 동작하는 LLM)와 결합한 ‘로컬 RAG’의 구축입니다.

이 글에서는 RAG의 기초 이론부터 Python을 사용한 로컬 RAG의 구체적인 구현 방법, 수학적 배경(벡터 검색의 원리), 그리고 시스템을 실제 운영 환경에서 가동하기 위한 고급 기술까지 철저하게 해설합니다.

1. RAG의 전체 아키텍처

RAG는 단일 AI 모델이 아니라 여러 컴포넌트가 연계되는 시스템 아키텍처입니다. 크게 ‘수집(데이터 로드) 페이즈’와 ‘검색 및 생성(Retrieval & Generation) 페이즈’의 두 가지로 구성됩니다.

아래의 Mermaid 다이어그램은 RAG 시스템의 전체적인 모습을 보여줍니다.

graph TD subgraph "수집 페이즈 (사전 준비)" Doc["독자적인 문서 (PDF, TXT, etc.)"] --> Loader["문서 로더"] Loader --> Splitter["텍스트 분할 (청킹)"] Splitter --> EmbedModel1["임베딩 모델 (Embedding)"] EmbedModel1 --> VectorDB["벡터 데이터베이스"] end subgraph "추론 페이즈 (사용자 질의 시)" User["사용자의 질문 (쿼리)"] --> EmbedModel2["임베딩 모델 (Embedding)"] EmbedModel2 --> QueryVector["쿼리 벡터"] QueryVector --> Search["유사도 검색 (벡터 검색)"] VectorDB --> Search Search --> Context["관련 청크 추출 (컨텍스트)"] User --> PromptBuilder["프롬프트 구축"] Context --> PromptBuilder PromptBuilder --> LocalLLM["로컬 LLM"] LocalLLM --> Answer["최종적인 답변 생성"] end

수집 페이즈 (사전 준비)

문서 로드: PDF, Word, 텍스트 파일 등의 비정형 데이터를 읽어 들입니다.
청킹 (텍스트 분할): LLM의 입력 제한(컨텍스트 윈도우) 내에 맞추고 검색 정확도를 높이기 위해, 긴 문장을 의미 있는 덩어리(청크)로 분할합니다.
임베딩 (벡터화): 분할된 청크를 임베딩 모델(Embedding Model)에 입력하여 수백~수천 차원의 수치 배열(벡터)로 변환합니다.
데이터베이스에 저장: 변환된 벡터와 원본 텍스트 데이터를 연결하여 벡터 데이터베이스(Vector DB)에 저장합니다.

추론 페이즈 (실행 시)

쿼리 벡터화: 사용자의 질문 문장을 사전 준비와 동일한 임베딩 모델을 사용하여 벡터화합니다.
유사도 검색: 쿼리 벡터와 데이터베이스 내의 문서 벡터 간에 유사도 계산을 수행하여, 의미적으로 가까운(관련성이 높은) 텍스트 청크를 상위 몇 개 가져옵니다.
프롬프트 구축: 가져온 관련 텍스트를 ‘컨텍스트(배경지식)‘로서 사용자의 질문 문장과 결합하여 LLM에 입력할 프롬프트를 만듭니다.
답변 생성: 확장된 프롬프트를 받은 LLM이 제공된 컨텍스트 정보를 바탕으로 답변을 생성합니다.

2. 벡터 검색과 임베딩(Embeddings)의 깊은 이해

RAG의 핵심을 이루는 것이 ‘벡터 검색(시맨틱 검색)‘입니다. 기존의 키워드 검색(BM25 등)이 단어의 완전 일치나 빈도에 기반하는 반면, 벡터 검색은 ‘의미의 유사성’에 기반합니다. 예를 들어 ‘개’와 ‘강아지’, ‘PC’와 ‘컴퓨터’처럼 다른 단어라도 의미가 비슷하면 검색 결과에 나타납니다.

임베딩 모델(Embedding Model)이란 무엇인가?

임베딩 모델은 자연어 텍스트를 입력으로 받아, 고정 길이의 밀집 벡터(Dense Vector)를 출력하는 신경망입니다. 일반적인 모델(예를 들어 text-embedding-3-small이나 오픈소스인 multilingual-e5-large)은 텍스트를 384차원이나 1024차원의 실수 벡터로 매핑합니다.

이 다차원 공간(잠재 공간)에서는 의미가 비슷한 문장일수록 좌표 공간상의 거리가 가까워지도록 학습되어 있습니다.

유사도 계산의 수학적 배경: 코사인 유사도

벡터 데이터베이스가 관련 문서를 검색할 때 가장 일반적으로 사용되는 거리 지표가 코사인 유사도(Cosine Similarity) 입니다. 유클리드 거리(공간적인 절대 거리)와는 달리, 코사인 유사도는 ‘두 벡터가 이루는 각’에 주목합니다. 문장의 길이(벡터의 노름)에 영향을 덜 받기 때문에 텍스트의 유사도 계산에 매우 적합합니다.

수식으로 나타내면, 벡터 $\mathbf{A}$와 $\mathbf{B}$의 코사인 유사도는 다음과 같습니다.

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ 는 내적(Dot Product)을 나타냅니다.
$\|\mathbf{A}\|$ 는 벡터 $\mathbf{A}$ 의 L2 노름(길이)을 나타냅니다.
$n$ 은 벡터의 차원 수입니다.

코사인 유사도는 -1에서 1 사이의 값을 가집니다.

1 에 가까움: 두 벡터의 방향이 거의 같음 (의미가 매우 비슷함)
0 에 가까움: 두 벡터가 직교함 (무관함)
-1 에 가까움: 두 벡터의 방향이 정반대임 (의미가 반대임)

최근의 벡터 DB(Chroma, FAISS, Qdrant 등)는 HNSW(Hierarchical Navigable Small World)라고 불리는 근사 최근접 이웃 탐색(ANN) 알고리즘을 채택하고 있어, 수백만 건의 벡터 데이터에서도 밀리초 단위로 코사인 유사도가 높은 문서를 검색할 수 있도록 최적화되어 있습니다.

3. 로컬 RAG를 구축하기 위한 기술 스택

클라우드에 의존하지 않는 완전한 로컬 RAG를 구축하려면 오픈소스 생태계를 활용합니다. 아래에 권장되는 기술 스택을 소개합니다.

언어 모델 (LLM)
- 도구: Ollama 또는 Llama.cpp
- 모델: Llama-3-8B-Instruct, Gemma-2-9B-It, Qwen2-7B-Instruct 등의 경량·고성능 오픈 모델. 일본어 태스크에는 일본어 튜닝이 된 Llama-3-ELYZA-JP-8B 등이 적합합니다.
임베딩 모델 (Embedding)
- 모델: intfloat/multilingual-e5-large 또는 BAAI/bge-m3. 로컬에서 구동할 경우, Hugging Face에서 다운로드하여 Sentence-Transformers로 실행하는 것이 일반적입니다.
벡터 데이터베이스 (Vector DB)
- ChromaDB: Python 기반으로 설정이 매우 간단함. 로컬 개발에 최적.
- FAISS: Meta가 개발한 고속 벡터 검색 라이브러리.
- Qdrant / Milvus: 보다 대규모이며 프로덕션 환경용.
오케스트레이션 프레임워크
- LangChain: 컴포넌트들을 연결(Chain)하기 위한 사실상의 표준.
- LlamaIndex: 특히 RAG에 특화된 데이터 연결 프레임워크.

이번에는 도입이 가장 간단한 LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings 조합으로 구현합니다.

4. 구현 튜토리얼: Python을 활용한 완전한 로컬 RAG 구축

지금부터는 실제로 Python 코드를 작성하면서 로컬 RAG를 구축해 보겠습니다. 사전에 PC에 Ollama를 설치하고 백그라운드에서 실행해 두세요. 또한, Ollama에서 모델을 풀(pull)해 둡니다(예: ollama run llama3).

Step 1: 필요한 라이브러리 설치

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

Step 2: 구현 코드 전체 모습

다음은 PDF 파일을 읽어 벡터화하고 로컬 LLM이 질문에 답하게 하는 완전한 Python 스크립트입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. 문서 로드
 print("문서를 읽고 있습니다...")
 # 읽어 들일 PDF의 경로를 지정
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. 청크 분할 (Text Splitting)
 # 문장의 의미를 훼손하지 않도록 적당한 크기로 분할한다
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # 1청크당 최대 글자 수
 chunk_overlap=50, # 앞뒤 청크의 중복 글자 수 (문맥 단절 방지)
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"{len(chunks)}개의 청크로 분할되었습니다.")

 # 3. 임베딩 모델 초기화 (Local HuggingFace Model)
 # 일본어에 강한 다국어 모델 사용
 print("임베딩 모델을 로드하고 있습니다...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # GPU가 있는 경우 'cuda' 또는 'mps'
 )

 # 4. 벡터 데이터베이스 구축 (Chroma)
 print("벡터 데이터베이스를 구축하고 있습니다...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # 검색기(Retriever) 생성. 상위 3건의 관련 문서를 가져오도록 설정
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. 로컬 LLM 초기화 (Ollama)
 print("로컬 LLM에 연결하고 있습니다...")
 # 사전에 'ollama pull llama3' 등으로 모델을 다운로드해 둘 것
 llm = Ollama(model="llama3")

 # 6. 프롬프트 템플릿 정의
 prompt_template = """당신은 회사의 규정이나 사내 정보에 해박한 우수한 어시스턴트입니다.
아래의 컨텍스트(배경 정보)만을 사용하여 사용자의 질문에 한국어로 상세히 답해 주세요.
컨텍스트에서 답을 찾을 수 없는 경우, 함부로 추측하지 말고 '제공된 정보로는 알 수 없습니다'라고 솔직하게 답해 주세요.

【컨텍스트】
{context}

【질문】
{question}

【답변】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. RAG 체인 구축
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # 정보 출처를 반환할지 설정
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. 질문 실행
 query = "원격 근무 시 교통비 지급 조건에 대해 알려주세요."
 print(f"\n질문: {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【답변】")
 print(result['result'])
 print("\n---")
 print("【참조한 정보 출처】")
 for doc in result['source_documents']:
 print(f"- 페이지 {doc.metadata.get('page', '알 수 없음')}: {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

코드의 포인트 해설

RecursiveCharacterTextSplitter: 자연어 분할에서 가장 권장되는 스플리터입니다. 단락(\n\n), 줄(\n), 마침표(。) 순으로 분할을 시도하며, 의미 덩어리를 가능한 한 유지한 채 지정된 chunk_size에 맞도록 분할합니다. chunk_overlap을 설정함으로써 문맥의 경계가 끊어져 정보가 손실되는 것을 방지합니다.
HuggingFaceEmbeddings: intfloat/multilingual-e5-large는 다국어를 지원하는 매우 강력한 오픈소스 임베딩 모델입니다. 클라우드 API(OpenAI의 text-embedding-ada-002 등)를 사용하지 않고도, 오프라인으로 로컬 메모리상에서 텍스트를 벡터화할 수 있습니다.
ChromaDB: 인메모리 또는 로컬 스토리지(SQLite 기반)에서 동작하기 때문에 복잡한 데이터베이스 서버를 구동할 필요가 없습니다. persist_directory를 지정하면, 재실행 시 벡터화 프로세스를 건너뛰고 디스크에서 DB를 읽어올 수 있습니다.

5. 발전된 RAG 기법 (Advanced RAG Techniques)

위의 튜토리얼에서 구축한 기본 RAG 시스템(Naive RAG)으로도 동작하지만, 프로덕션 환경에서 높은 답변 정확도를 요구받을 경우 다음과 같은 고급 기술의 도입이 필요해집니다.

5.1 하이브리드 검색 (Hybrid Search)

벡터 검색은 ‘의미’를 파악하는 데에는 능하지만, ‘특정 고유명사’, ‘제품 모델명’, ‘직원 ID’ 등과 같은 엄밀한 키워드 검색에는 약할 수 있습니다. 그래서 벡터 검색에 의한 시맨틱 검색과 BM25 알고리즘 등을 사용한 키워드 검색을 병행하고, 양쪽의 결과를 스코어링하여 통합하는(Reciprocal Rank Fusion; RRF 등의 기법을 사용) 방식으로 검색 누락을 극적으로 줄일 수 있습니다.

5.2 리랭킹 (Re-ranking)

벡터 검색은 고속이지만, 반드시 컨텍스트의 정확한 문맥 적합성을 평가하고 있는 것은 아닙니다. 검색 정확도를 향상시키기 위한 일반적인 파이프라인은 다음과 같습니다.

초기 검색 (First-stage Retrieval): 벡터 DB에서 넓고 얕게 관련 청크를 20~30건 정도 가져옵니다.
재평가 (Re-ranking): Cross-Encoder라고 불리는 다른 더 무거운 머신러닝 모델(예: bge-reranker 등)을 사용하여, 사용자의 쿼리와 가져온 청크의 쌍을 입력해 의미적 적합도 점수를 다시 계산합니다.
선별: 점수가 높은 상위 3~5건만을 최종적인 컨텍스트로서 LLM의 프롬프트에 전달합니다.

이 기법을 통해 무관한 노이즈 정보가 LLM에 전달되는 것을 방지하고 답변의 정확도(Precision)를 대폭 높일 수 있습니다.

graph LR Query["쿼리"] --> VSearch["벡터 검색 (상위 20건)"] VSearch --> Reranker["리랭커 모델 (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["고정밀 상위 3건"] TopK --> LLM["LLM 생성"]

5.3 시맨틱 청킹과 부모 문서 검색

고정된 글자 수로 기계적으로 텍스트를 분할하는 것이 아니라, 문장의 의미 변화를 AI로 감지하여 분할하는 ‘Semantic Chunking(시맨틱 청킹)‘이라는 기법이 있습니다. 또한, ‘Parent 단락 검색(Parent Document Retriever)‘이라는 기법에서는 검색용으로 매우 작은 단위(문장 등)로 벡터화를 수행하여 정확도 높은 검색을 실현하면서도, LLM에 전달할 때는 그 문장이 포함된 ‘원래의 큰 단락(부모 문서)‘을 전달함으로써 LLM에 충분한 문맥(컨텍스트)을 제공합니다.

6. 로컬 RAG 운영 시의 과제와 대책

로컬 환경에서 RAG를 구축하고 운영할 때는 특유의 장벽이 존재합니다.

VRAM(비디오 메모리) 고갈: 로컬 LLM을 실용적인 속도(1초에 수십 토큰)로 구동하려면 GPU의 VRAM에 모델을 올려야 합니다. 8B 클래스의 모델을 fp16(16비트 부동소수점)으로 구동하려면 약 16GB의 VRAM이 필요하지만, 양자화(Quantization) 기술(GGUF나 AWQ 형식 등, 4bit나 8bit로 압축하는 기술)을 사용하면 8GB의 VRAM(일반적인 게이밍 PC 등)에서도 충분히 고속으로 동작시킬 수 있습니다. Llama.cpp나 Ollama는 기본적으로 이러한 양자화 포맷을 지원합니다.
컨텍스트 윈도우의 제한: 검색하여 가져온 컨텍스트의 양이 너무 많으면 LLM의 입력 상한(토큰 제한)을 초과해 버리거나, 모델이 정보의 중간 부분을 잊어버리는(Lost in the middle 현상) 경우가 있습니다. 추출할 청크 수의 조정이나 앞서 언급한 리랭킹 기술을 통한 엄선이 필수적입니다.
데이터 최신성 관리: 소스 문서가 업데이트된 경우, 벡터 데이터베이스 내의 해당 문서 벡터도 업데이트 및 삭제(CRUD 작업)할 필요가 있습니다. ChromaDB에서는 문서 ID 기반의 업데이트를 지원하므로, 파일의 해시값을 관리하여 변경 사항만을 동기화하는 배치 처리를 구성하는 것이 실용적입니다.

마무리

RAG(검색 증강 생성)는 AI를 일반적인 범용 어시스턴트에서 ‘당신 전속의 전문가’나 ‘사내 업무에 특화된 전문가’로 진화시키는 강력한 패러다임입니다.

클라우드 서비스를 이용할 수 없는 기밀성이 높은 요구사항이라도, Ollama, LangChain, ChromaDB 등의 오픈소스 생태계를 결합함으로써 완전한 ‘로컬 RAG’ 환경을 비교적 쉽게 구축할 수 있음을 알 수 있었습니다.

이 글에서 해설한 벡터 공간의 수학적 이해나 텍스트 분할, 리랭킹과 같은 발전된 접근 방식을 바탕으로, 꼭 자신이 보유한 데이터를 사용하여 독자적인 AI 시스템을 개발해 보시기 바랍니다. 로컬 AI의 진화 속도는 경이로우며, 오늘 구축한 시스템은 내일 등장할 더욱 똑똑한 경량 모델로 교체하는 것만으로 순식간에 성능을 업데이트할 수 있습니다.

본 블로그에서는 앞으로도 AI 기술이나 RAG에 관한 심층 기사를 게재할 예정입니다. 질문이나 피드백이 있으시다면 꼭 댓글란에 남겨주세요.

ChatGPT・Gemini・Claude의 API 철저 비교! 어떤 것을 선택해야 할까?

Fri, 11 Sep 2026 12:00:00 +0900

ChatGPT・Gemini・Claude의 API 철저 비교! 어떤 것을 선택해야 할까?

AI 기술의 진화는 눈부시며, 특히 대규모 언어 모델(LLM: Large Language Model) 분야에서는 OpenAI의 ChatGPT(GPT 시리즈), Google의 Gemini, Anthropic의 Claude가 삼파전의 치열한 패권 다툼을 벌이고 있습니다. 2026년 현재, 각 회사는 수개월, 아니 수주일 단위로 새로운 모델과 API 기능을 출시하고 있으며, 개발자나 기업의 IT 아키텍트에게 “어떤 API를 프로덕트에 통합해야 하는가"라는 질문은 프로젝트의 성공을 좌우하는 매우 중요한 의사 결정이 되었습니다.

본 기사에서는 이 3대 AI 제공업체의 API에 대해 단순한 스펙의 나열에 그치지 않고, 아키텍처 설계, 상세한 요금 구조, 지연 시간(레이턴시)의 수학적 분석, Python 및 Node.js를 이용한 구체적인 구현 예시, 프롬프트 캐싱 등 최신 비용 최적화 기법에 이르기까지 개발자의 관점에서 철저하게 비교하고 해설합니다.

독자 여러분이 자신의 유스케이스에 가장 적합한 LLM API를 선정하고, 확장 가능하며 비용 효율적인 AI 애플리케이션을 구축하기 위한 완전한 가이드가 되는 것을 목표로 합니다.

1. 각 LLM API의 철학과 설계 사상

기술 선정에 있어 우선 각 회사가 어떤 사상으로 모델과 API를 구축하고 있는지 이해하는 것은 매우 중요합니다.

1.1 OpenAI (ChatGPT)

OpenAI는 “범용 인공지능(AGI)의 실현"을 미션으로 내걸고 항상 업계의 사실상 표준을 견인하고 있습니다. GPT-4o나 GPT-4o-mini, 그리고 추론 특화형인 o1 모델 등 유스케이스에 맞춘 다양한 모델을 제공합니다. 생태계가 가장 성숙해 있으며, 공식·비공식 여부를 불문하고 라이브러리와 문서가 가장 풍부합니다.

1.2 Google (Gemini)

Google은 “AI First"를 내걸고, 자사의 인프라(TPU 네트워크)를 최대한 활용한 확장성을 무기로 삼고 있습니다. Gemini 1.5 Pro/Flash는 최대 200만 토큰이라는 압도적인 컨텍스트 윈도우(문맥 길이)를 가지며, 방대한 문서나 수 시간의 동영상·음성을 한 번에 처리할 수 있는 것이 가장 큰 특징입니다. Google Cloud (Vertex AI)와의 강력한 통합 역시 엔터프라이즈에게 매력적입니다.

1.3 Anthropic (Claude)

Anthropic은 전 OpenAI 멤버들이 설립한 기업으로, “Constitutional AI(합헌적 AI)“라는 독자적인 안전성 접근 방식을 채택하고 있습니다. Claude 3.5 Sonnet과 Opus는 뛰어난 추론 능력, 코드 생성 능력, 그리고 무엇보다 “인간처럼 자연스러운 대화"와 “할루시네이션(환각)의 적음"으로 많은 개발자들로부터 열광적인 지지를 얻고 있습니다.

2. 모델 패밀리의 스펙 철저 비교

2026년 현재 주력 모델의 스펙을 비교합니다.

제공업체	주력 모델	최대 컨텍스트 길이	주요 강점	권장 유스케이스
OpenAI	GPT-4o	128K	속도, 시각 인식, 음성 지원	인터랙티브한 앱, 범용 작업
OpenAI	o1-preview	128K	고도의 논리 추론, 수학, 코딩	복잡한 알고리즘 생성, 연구 용도
Google	Gemini 1.5 Pro	2,000K	초장문 처리, 멀티모달(동영상·음성)	거대한 코드베이스 분석, 동영상 요약
Google	Gemini 1.5 Flash	2,000K	저지연, 고처리량, 압도적인 저비용	실시간 처리, 대량 데이터의 일괄 처리
Anthropic	Claude 3.5 Sonnet	200K	코딩 능력, 자연스러운 문장 생성	소프트웨어 개발 지원, 고도화된 고객 지원
Anthropic	Claude 3.5 Haiku	200K	초고속 응답, 가성비	엣지 AI, 실시간 챗봇

3. 아키텍처 파고들기: API 요청의 이면

LLM API를 호출했을 때, 백엔드에서는 어떤 처리가 이루어지고 있을까요? 성능을 최적화하기 위해서는 이 아키텍처를 이해할 필요가 있습니다.

다음의 Mermaid 다이어그램은 클라이언트로부터 API 요청이 전송되고, 토큰이 스트리밍으로 반환되기까지의 전체적인 모습을 보여줍니다.

graph TD A["클라이언트 애플리케이션"] -->|HTTP/REST or gRPC| B["API 게이트웨이"] B --> C["로드 밸런서"] C --> D["추론 클러스터"] D --> E["토크나이저 (BPE / SentencePiece)"] E --> F["KV 캐시 및 어텐션 메커니즘"] F --> G["트랜스포머 블록 (정방향 패스)"] G --> H["출력 레이어 (Logits)"] H --> I["샘플러 (Temperature, Top-p, Top-k)"] I --> J["디토크나이저"] J -->|스트리밍 응답 (Chunk)| A

3.1 Tokenization(토큰화) 알고리즘

API에 입력된 텍스트는 내부적으로 ‘토큰’이라는 단위로 분할됩니다.

OpenAI (tiktoken): Byte-Pair Encoding (BPE) 채택. 특히 영어에서 매우 효율적으로 압축되지만, 한국어 등 비알파벳 언어에서는 토큰 수가 늘어나는 경향이 있습니다.
Google (Gemini): SentencePiece (Unigram Language Model) 채택. 다국어에 강하며, 한국어 텍스트에서도 비교적 적은 토큰 수로 표현할 수 있는 경향이 있습니다.
Anthropic (Claude): BPE의 맞춤형 버전 사용. 다국어 지원이 강화되어 있으며, Claude 3 이후로는 한국어 토큰 효율도 크게 개선되었습니다.

4. 지연 시간(레이턴시)과 성능의 수학적 분석

실시간 애플리케이션에서 지연 시간은 사용자 경험(UX)과 직결됩니다. LLM API의 지연 시간 $T_{total}$은 수학적으로 다음과 같이 모델링할 수 있습니다.

$$ T_{total} = T_{network} + T_{TTFT} + (N \times T_{TPOT}) $$

여기서 각 변수는 다음의 의미를 갖습니다.

$T_{network}$: 네트워크의 왕복 시간(RTT).
$T_{TTFT}$ (Time To First Token): 첫 글자가 생성되기까지의 시간. 프롬프트 길이(입력 토큰 수)의 제곱에 비례하는 어텐션 계산 비용에 크게 의존합니다.
$N$: 출력되는 토큰의 총 개수.
$T_{TPOT}$ (Time Per Output Token): 1토큰 당 생성 시간. 자기 회귀(autoregressive) 모델이므로 이전 출력에 의존하여 직렬로 계산됩니다.

4.1 자기 어텐션(Self-Attention) 메커니즘의 계산량

Transformer 아키텍처에서 자기 어텐션(Self-Attention)의 계산량은 입력 시퀀스 길이 $L$에 대해 이차 함수적으로 증가합니다.

$$ \text{Complexity} = O(L^2 \cdot d) $$

여기서 $d$는 임베딩 벡터의 차원 수입니다. 이 제약 때문에 일반적으로 프롬프트가 길어지면 $T_{TTFT}$가 급격히 악화됩니다. 하지만 Google의 Gemini 1.5는 “Ring Attention"이나 “Block-wise Compute"와 같은 혁신적인 최적화 아키텍처를 채택하여, 200만 토큰이라는 긴 문장을 입력해도 현실적인 시간(수 초~수십 초) 내에 첫 토큰을 생성하는 데 성공했습니다.

5. 요금 체계 및 비용 최적화 전략

API 비용은 기본적으로 입력 토큰 수와 출력 토큰 수를 기준으로 계산됩니다.

$$ Cost = (Tokens_{in} \times Rate_{in}) + (Tokens_{out} \times Rate_{out}) $$

하지만 최신 API에서는 비용을 극적으로 낮추기 위한 새로운 메커니즘이 도입되고 있습니다.

5.1 프롬프트 캐싱 (Prompt Caching)

방대한 시스템 프롬프트나, RAG로 검색한 대량의 문서를 매번 전송하면 막대한 비용이 발생합니다. 이에 대응하기 위해 각 회사는 캐시 기능을 제공하고 있습니다.

Anthropic(Claude)이나 Google(Gemini)에서는 특정 텍스트 블록을 캐싱함으로써 입력 비용을 대폭(최대 90%) 절감할 수 있습니다.

캐시를 이용할 경우의 비용 모델은 다음과 같습니다.

$$ Cost_{cached} = (Tokens_{cache\_write} \times Rate_{cache\_write}) + (Tokens_{cache\_read} \times Rate_{cache\_read}) + (Tokens_{out} \times Rate_{out}) $$

여기서 $Rate_{cache\_read}$는 일반적인 $Rate_{in}$의 10%~25% 수준으로 설정되어 있습니다. 이를 통해 수만 줄의 코드베이스를 배경 지식으로 항상 유지하면서도 저렴하게 챗봇을 운영할 수 있게 되었습니다.

5.2 배치 API (Batch API)

실시간성이 불필요한 작업(로그 분석, 대량의 데이터 분류 등)을 위해 OpenAI나 Anthropic은 배치 API를 제공합니다. 요청을 모아서 전송하고 24시간 이내에 결과를 받는 대신, 일반 API 요금의 절반(50% 할인)으로 이용할 수 있는 강력한 시스템입니다.

6. 개발자 경험(DX)과 SDK 비교

개발 효율의 관점에서 각 회사가 제공하는 SDK(Software Development Kit)를 비교합니다.

6.1 OpenAI API

가장 널리 사용되고 있으며, 서드파티 라이브러리(LangChain, LlamaIndex 등)의 지원도 가장 빠릅니다. 또한, Structured Outputs(구조화된 출력) 기능을 통해 JSON 스키마를 100%의 정확도로 준수한 응답을 반환하도록 보장되어 있어, 시스템 연동이 매우 용이합니다.

6.2 Anthropic API (Claude)

SDK 인터페이스가 세련되었으며, TypeScript의 타입 정의 등이 다루기 매우 쉽다는 평가를 받습니다. 특히 Message API의 구조가 직관적이고, 여러 장의 이미지를 포함한 멀티모달 요청도 간단하게 작성할 수 있습니다.

6.3 Google Gemini API

Google Cloud Vertex AI를 통한 액세스와 AI Studio를 통한 액세스(Google Gen AI SDK) 두 가지가 존재하여 초보자는 조금 혼란스러울 수 있습니다. 하지만 엔터프라이즈용 Vertex AI SDK는 GCP의 IAM(인증 및 인가 시스템)과 완벽하게 통합되어 있어 안전한 개발 환경을 구축할 수 있습니다.

7. 실전! Python을 활용한 다중 API 통합 테스트 구현

여기서는 Python을 사용하여 OpenAI, Anthropic, Gemini 등 3개의 API에 대해 동시에 비동기 요청을 보내고, 지연 시간을 비교하는 스크립트를 구현해 보겠습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


import asyncio
import time
import os
from openai import AsyncOpenAI
from anthropic import AsyncAnthropic
import google.generativeai as genai

# 클라이언트 초기화
openai_client = AsyncOpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
anthropic_client = AsyncAnthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
genai.configure(api_key=os.environ.get("GEMINI_API_KEY"))

prompt = "양자 컴퓨터의 기초와 그것이 현재의 암호 기술에 미치는 영향에 대해 초보자도 알기 쉽게 설명해 주세요."

async def fetch_openai():
 start_time = time.time()
 response = await openai_client.chat.completions.create(
 model="gpt-4o",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "OpenAI (GPT-4o)", elapsed, response.choices[0].message.content

async def fetch_anthropic():
 start_time = time.time()
 response = await anthropic_client.messages.create(
 model="claude-3-5-sonnet-20240620",
 messages=[{"role": "user", "content": prompt}],
 max_tokens=1024
 )
 elapsed = time.time() - start_time
 return "Anthropic (Claude 3.5 Sonnet)", elapsed, response.content[0].text

async def fetch_gemini():
 start_time = time.time()
 model = genai.GenerativeModel('gemini-1.5-pro')
 # Gemini Python SDK의 비동기 메서드 활용
 response = await model.generate_content_async(prompt)
 elapsed = time.time() - start_time
 return "Google (Gemini 1.5 Pro)", elapsed, response.text

async def main():
 print("각 LLM API로 요청을 전송 중...")

 # 3개의 API를 병렬로 실행
 results = await asyncio.gather(
 fetch_openai(),
 fetch_anthropic(),
 fetch_gemini()
 )

 for provider, latency, text in results:
 print(f"--- {provider} ---")
 print(f"Latency: {latency:.2f} seconds")
 print(f"Response (Excerpt): {text[:100]}...\n")

if __name__ == "__main__":
 asyncio.run(main())

이 스크립트를 실행함으로써 실제 네트워크 환경에서 어떤 모델이 가장 빠르게($T_{total}$을 최소화하여) 응답하는지 쉽게 측정할 수 있습니다.

8. Node.js에 의한 Tool Calling(Function Calling) 구현

LLM을 단순한 챗봇이 아니라 외부 시스템과 연동하는 ‘AI 에이전트’로 기능하게 하려면 Tool Calling(또는 Function Calling)이 필수적입니다. 다음은 Node.js(TypeScript)를 사용하여 OpenAI API가 날씨 API를 호출하도록 하는 예시입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


import OpenAI from "openai";

const openai = new OpenAI({
 apiKey: process.env.OPENAI_API_KEY,
});

async function runAgent() {
 const tools = [
 {
 type: "function",
 function: {
 name: "get_weather",
 description: "지정된 도시의 현재 날씨를 가져옵니다.",
 parameters: {
 type: "object",
 properties: {
 location: {
 type: "string",
 description: "도시 이름 (예: 서울, 뉴욕)",
 },
 },
 required: ["location"],
 },
 },
 },
 ];

 const response = await openai.chat.completions.create({
 model: "gpt-4o",
 messages: [{ role: "user", "content": "오늘 서울 날씨 어때? 우산 챙겨야 할까?" }],
 tools: tools,
 tool_choice: "auto",
 });

 const message = response.choices[0].message;

 if (message.tool_calls) {
 const toolCall = message.tool_calls[0];
 console.log(`LLM이 도구 호출을 요청했습니다: 함수 이름 = ${toolCall.function.name}`);

 const args = JSON.parse(toolCall.function.arguments);
 console.log(`인수: ${args.location}`);

 // 여기서 실제 날씨 API(예: OpenWeatherMap)를 호출하는 로직을 구현합니다
 // const weather = await fetchWeatherFromAPI(args.location);

 // 가져온 결과를 다시 LLM에 전달하여 최종 답변을 생성하게 합니다
 }
}

runAgent().catch(console.error);

Claude 3.5 Sonnet이나 Gemini 1.5 Pro도 동등한 Tool Calling 기능을 갖추고 있으며, 스키마 정의 방법에 약간의 차이는 있지만 기본적인 흐름은 동일합니다.

9. RAG vs Long Context Window: 어떤 것을 채택해야 할까?

현재 엔터프라이즈 AI 아키텍처에서 가장 큰 논쟁 중 하나는 “외부 지식을 가져오기 위해 RAG(검색 증강 생성)를 사용해야 할지, 아니면 거대한 컨텍스트 윈도우(Long Context)에 모든 것을 맡겨야 할지” 하는 문제입니다.

RAG (Retrieval-Augmented Generation)의 장점과 과제

장점: 비용이 저렴하며(필요한 청크만 프롬프트에 넣기 때문), 답변의 근거(출처)를 특정하기 쉽습니다.
과제: 시맨틱 검색의 정확도에 의존하기 때문에, 문맥이 여러 문서에 흩어져 있는 고도화된 추론 작업(예: “작년 전체 회의록에서 A 프로젝트가 지연된 근본 원인을 시계열로 분석해 줘”)에는 적합하지 않습니다.

Long Context (Gemini 1.5 Pro의 200만 토큰 등)

장점: 검색으로 인한 정보 누락이 없습니다. “건초 더미에서 바늘 찾기(Needle In A Haystack: NIAH)” 테스트에서도 Gemini 1.5 Pro나 Claude 3.5 Sonnet은 99% 이상의 정확도로 정보를 추출할 수 있습니다.
과제: 토큰 소비량이 방대해져 비용이 증가하며, 지연 시간($T_{TTFT}$)이 늘어납니다.

결론: 2026년의 모범 사례(Best Practice)는 **“하이브리드 접근법”**입니다. 일상적인 Q&A에는 벡터 데이터베이스를 활용한 RAG를 사용하고, 복잡한 분석이나 코드 전체 리뷰가 필요한 특화된 작업에는 프롬프트 캐싱을 활용한 Long Context를 사용하는 설계가 주류가 되고 있습니다.

10. 멀티모달 처리 능력 비교

차세대 AI 애플리케이션에서는 텍스트뿐만 아니라 이미지, 음성, 동영상을 직접 이해하는 능력이 요구됩니다.

sequenceDiagram participant User as "사용자" participant Client as "프론트엔드 앱" participant API as "LLM API (멀티모달)" User->>Client: 동영상 및 텍스트 프롬프트 업로드 Client->>API: 동영상 바이트/URI + 텍스트 전송 Note over API: 동영상 청킹 및 음성 분리 Note over API: 멀티모달 임베딩 모델 API-->>Client: 텍스트 요약 및 타임스탬프 반환 Client-->>User: 인사이트 표시

OpenAI (GPT-4o): 이미지 인식 정확도가 매우 뛰어나며, 손으로 그린 도면이나 복잡한 그래프를 읽어내는 데 탁월합니다. 또한, Realtime API를 이용한 초저지연(수백 밀리초) 네이티브 음성 대화 기능도 강력합니다.
Google (Gemini 1.5 Pro): 동영상 분석에 있어서 다른 모델들을 압도합니다. 1시간 분량의 동영상 파일(프레임 및 음성)을 그대로 입력하고, “12분 45초에 화면 오른쪽 끝에 나타난 인물이 들고 있는 자료의 제목은?“과 같은 핀포인트 질문에 답변이 가능합니다.
Anthropic (Claude 3.5 Sonnet): 이미지 인식(Vision) 능력은 GPT-4o와 동등한 수준으로 매우 우수합니다. UI 스크린샷을 넘겨주며 “이 화면의 React 컴포넌트 코드를 생성해 줘"라고 요구하는 프론트엔드 개발 지원에서 독보적인 강점을 발휘합니다.

11. 엔터프라이즈급 보안 및 컴플라이언스

기업이 LLM API를 프로덕션 환경에서 사용할 때 가장 우려하는 점은 “자사의 데이터가 AI 학습에 사용되지는 않는가"와 “컴플라이언스 요건을 충족하는가"입니다.

3사 모두 API를 통해 전송된 데이터(프롬프트 및 응답)를 모델 학습에 사용하지 않는다고(Zero Data Retention / No Training on Customer Data) 명시하고 있습니다(※무료 소비자용 웹 채팅 UI는 예외입니다).

더 높은 보안 수준이 요구될 경우:

OpenAI: Azure OpenAI Service를 경유함으로써 Microsoft의 엔터프라이즈급 보안, SLA, Azure Private Link를 통한 폐쇄망 연결을 이용할 수 있습니다.
Google: Google Cloud Vertex AI를 경유함으로써 VPC Service Controls를 이용한 엄격한 네트워크 분리 및 CMEK(고객 관리 암호화 키)를 통한 데이터 보호가 가능합니다.
Anthropic: AWS Bedrock 또는 Google Cloud Vertex AI를 경유하여 클라우드 제공업체의 견고한 보안 기반을 함께 이용할 수 있습니다.

12. 결론: 유스케이스별 궁극의 선택 가이드

지금까지 다각도로 비교해 왔지만, 결국 “어떤 것을 선택해야 하는가?“에 대한 결론은 유스케이스에 따라 다릅니다.

복잡한 소프트웨어 개발·코드 생성·고도의 추론: 👑 승자: Claude 3.5 Sonnet (Anthropic) 코드의 문맥 이해, 리팩토링, 자연스럽고 인간적인 문장 작성에 있어 현재 최고의 성능을 발휘합니다. API의 사용 편의성과 프롬프트 캐싱을 통한 비용 효율성도 뛰어납니다.
초장문 문서 분석·동영상/음성 일괄 처리: 👑 승자: Gemini 1.5 Pro (Google) 200만 토큰의 컨텍스트 윈도우는 유일무이한 무기입니다. 수백 페이지의 PDF 매뉴얼 분석이나 장시간의 회의 녹화 요약 등 데이터의 전체적인 윤곽을 파악해야 하는 작업에서는 Gemini를 따라올 모델이 없습니다.
범용성·실행 속도·안정적인 구조화된 출력(JSON): 👑 승자: GPT-4o / GPT-4o-mini (OpenAI) 모든 작업을 무난하게 소화하며, 서드파티 도구 지원도 가장 풍부합니다. Structured Outputs를 활용한 확실한 JSON 파싱이나, o1 모델을 이용한 초고도 논리 추론이 필요한 경우 OpenAI 생태계가 필수적입니다.

멀티 모델 라우팅 권장

단일 API에 의존(벤더 종속)하는 것이 아니라, 작업의 난이도나 중요도에 따라 모델을 동적으로 전환하는 “LLM 라우팅” 아키텍처가 향후의 트렌드입니다. 예를 들어, 사용자의 단순한 질문에는 저렴하고 빠른 GPT-4o-mini나 Gemini 1.5 Flash로 응답하고, 복잡한 처리가 필요하다고 판단되는 경우에만 Claude 3.5 Sonnet으로 작업을 폴백(fallback)시킴으로써 비용과 성능의 최적 균형을 실현할 수 있습니다.

AI의 진화는 멈추지 않습니다. 각 API의 장단점과 아키텍처의 특성을 깊이 이해하여 유연하고 확장 가능한 AI 애플리케이션을 구축하시기 바랍니다.

llama.cpp 사용법 및 C++를 이용한 커스터마이징 입문

Fri, 11 Sep 2026 11:00:00 +0900

최근 대규모 언어 모델(LLM)의 진화는 매우 빠르며, 그 응용 범위는 나날이 확대되고 있습니다. 하지만 수십억, 수백억 개의 매개변수를 가진 모델을 로컬 환경에서 구동하려면 보통 방대한 VRAM을 갖춘 하이엔드 GPU가 필요합니다. 이러한 ‘하드웨어의 벽’을 허물고, 일반적인 PC나 Mac, 심지어 Raspberry Pi와 같은 기기 위에서 LLM의 실용적인 추론을 가능하게 한 것이 바로 llama.cpp입니다.

본 기사에서는 단순한 명령줄 도구의 사용법에 그치지 않고, 그 기반 기술인 ggml의 아키텍처, Transformer 및 양자화(Quantization)의 수학적 배경, 그리고 C++ API를 이용하여 독자적인 애플리케이션에 LLM을 통합하고 커스터마이징하는 방법까지 엔지니어를 위해 매우 상세하게 해설합니다.

1. llama.cpp 및 ggml 개요

llama.cpp는 Georgi Gerganov 씨가 개발한, C/C++로 작성된 경량 LLM 추론 엔진입니다. 원래는 Meta의 LLaMA 모델을 Apple Silicon(M1/M2 Mac) 위에서 고속으로 동작시키는 것을 목적으로 탄생했지만, 현재는 다양한 아키텍처와 모델을 지원하고 있습니다.

가장 큰 특징은 외부 의존성을 가지지 않는 순수한 C/C++ 구현이라는 점입니다. Python이나 PyTorch 등의 거대한 에코시스템을 필요로 하지 않고, 단일 실행 파일로 컴파일할 수 있기 때문에 배포가 매우 쉽습니다.

이 llama.cpp의 심장부 역할을 하는 것이 텐서 연산 라이브러리 ggml입니다. ggml은 머신러닝에서의 행렬 연산을 CPU(및 일부 GPU) 상에서 극한까지 최적화하기 위해 처음부터 설계되었습니다.

1.1 llama.cpp는 왜 빠른가?

메모리 매핑(mmap) 활용: 모델의 가중치를 메모리에 로드할 때 OS의 mmap을 이용함으로써 RAM 전체 로드를 피하고, 빠른 실행과 메모리 절약을 실현합니다.
SIMD 명령의 철저한 최적화: AVX2, AVX-512, ARM NEON, Apple AMX 등 CPU 고유의 명령 세트를 활용하여 행렬 곱을 초고속화하고 있습니다.
양자화(Quantization): 16-bit 부동소수점(FP16) 가중치를 4-bit, 5-bit, 8-bit 정수로 압축하여 메모리 대역폭의 병목 현상을 해소합니다(자세한 내용은 후술).

2. 수학적 배경: Transformer와 양자화(Quantization)

llama.cpp를 깊이 이해하기 위해서는 그것이 계산하고 있는 수식과, 어떻게 계산을 근사화하고 있는지 알아야 합니다.

2.1 Transformer의 추론 프로세스

LLaMA 등의 모델은 자기회귀형(Auto-regressive) Transformer 디코더 아키텍처를 채택하고 있습니다. 텍스트 생성의 핵심이 되는 것은 Self-Attention 메커니즘입니다.

입력이 되는 은닉 상태의 행렬 $X \in \mathbb{R}^{N \times d}$에 대해, 쿼리 $Q$, 키 $K$, 값 $V$는 가중치 행렬과의 곱으로 계산됩니다.

$$ Q = X W_Q, \quad K = X W_K, \quad V = X W_V $$

여기서 Attention의 출력은 다음과 같이 정의됩니다.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

llama.cpp의 추론 루프에서 병목 현상이 발생하는 부분은 이 거대한 행렬 $W_Q, W_K, W_V$나 피드 포워드 네트워크(FFN)의 가중치 행렬과 벡터 $X$(생성 단계에서는 1토큰씩 처리하므로 $N=1$)의 곱, 즉 **GEMV (General Matrix-Vector Multiplication)**입니다.

2.2 양자화(Quantization)의 수학적 기초

메모리 액세스 대역이 병목이 되는 추론에 있어서, 가중치 매개변수를 작은 비트 수로 표현하는 양자화는 필수적입니다. llama.cpp에서 널리 쓰이는 블록 단위의 양자화(예: Q4_K나 Q4_0)의 기본 원리를 설명합니다.

예를 들어 FP16 가중치 행렬 $W$의 일부인 길이 $B$(보통 32나 64)의 블록 $w = [w_1, w_2, \dots, w_B]$를 생각합니다. 이 블록을 4-bit 정수 $q_i \in [-8, 7]$과 단일 스케일링 팩터 $\Delta$(FP16 또는 FP32)로 근사합니다.

$$ w_i \approx \Delta \times q_i $$

$\Delta$는 블록 내의 최대 절댓값을 바탕으로 결정됩니다.

$$ \Delta = \frac{\max_i |w_i|}{7} $$

양자화 후의 가중치를 이용해 내적 $y = w \cdot x$를 계산할 경우, 입력 벡터 $x$도 동일하게 양자화하여 $x_i \approx \Delta_x \times q_{x, i}$로 두면,

$$ y = \sum_{i=1}^{B} w_i x_i \approx \Delta \Delta_x \sum_{i=1}^{B} q_i q_{x, i} $$

이 $\sum q_i q_{x, i}$ 부분은 순수한 정수 연산이 되며, SIMD 명령을 사용하여 매우 빠르게 병렬 계산할 수 있습니다. 이것이 llama.cpp가 CPU 상에서 경이로운 속도를 내는 수학적인 트릭입니다.

3. 아키텍처 및 추론 흐름

llama.cpp의 내부 동작을 이해하기 위해, 다음의 Mermaid 다이어그램으로 시스템 전체의 아키텍처와 데이터 흐름을 나타냅니다.

graph TD A["사용자 입력 (String)"] --> B["llama.cpp Tokenizer"] B --> C["Token IDs (int32 배열)"] C --> D["컨텍스트 버퍼 (KV Cache)"] D --> E["ggml 계산 그래프"] E --> F["Transformer 레이어"] subgraph "ggml 엔진" F --> G["Self-Attention (RoPE)"] G --> H["Feed Forward Network"] H --> F end F --> I["Logits (어휘 크기)"] I --> J["Sampler (Temperature, Top-K, Top-P)"] J --> K["선택된 토큰 ID"] K --> L["llama.cpp Detokenizer"] L --> M["출력 문자열"] K -. "자기회귀 루프" .-> D

텍스트 생성은 하나의 토큰이 출력될 때마다 그것이 다음 입력으로 KV Cache에 추가되고, 다시 계산 그래프를 통과하는 자기회귀적인 루프로 되어 있습니다.

4. 환경 구축 및 빌드 방법

llama.cpp를 C++ 프로젝트에 통합하기 전에 먼저 소스 코드를 빌드해 봅시다.

4.1 리포지토리 클론

1
2


git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp

4.2 CMake를 사용한 빌드

C++ 프로젝트로서 다른 앱에 통합할 경우, CMake를 이용하는 것이 가장 표준적입니다. 플랫폼별 가속기(백엔드)를 활성화함으로써 연산을 고속화할 수 있습니다.

CPU 전용 (기본 빌드):

1
2
3


mkdir build && cd build
cmake ..
cmake --build . --config Release -j 8

NVIDIA GPU (CUDA)를 사용할 경우:

1
2
3


mkdir build && cd build
cmake .. -DGGML_CUDA=ON
cmake --build . --config Release -j 8

Apple Silicon (Metal)을 사용할 경우:

1
2
3


mkdir build && cd build
cmake .. -DGGML_METAL=ON
cmake --build . --config Release -j 8

빌드가 성공하면 build/bin/ 디렉터리에 llama-cli 등의 실행 파일과 후술할 C++ API에서 링크하기 위한 llama 라이브러리(및 ggml 라이브러리)가 생성됩니다.

5. C++ 커스터마이징 입문: llama.cpp API 활용

여기서부터는 본론인 C++ 코드를 통한 llama.cpp의 제어에 대해 해설합니다. 명령줄 도구를 사용하는 것뿐만 아니라, 자신의 애플리케이션(예: 게임 엔진, 데스크톱 앱, 임베디드 시스템 등)에 LLM을 포함시키려면 C++ API를 직접 호출해야 합니다.

llama.cpp는 주로 llama.h라는 헤더 파일로 C언어 인터페이스를 제공하고 있습니다. C++에서 호출할 때도 이 인터페이스를 이용합니다.

5.1 필요 최소한의 인클루드 및 설정

자신의 프로젝트에서 llama.cpp를 사용할 경우, 이하를 인클루드합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "llama.h"
#include <iostream>
#include <vector>
#include <string>
#include <stdexcept>

// 에러 핸들링을 위한 매크로
#define LLAMA_ASSERT(x) \
 do { \
 if (!(x)) { \
 std::cerr << "Assertion failed: " << #x << std::endl; \
 std::terminate(); \
 } \
 } while (0)

5.2 모델 로드 및 컨텍스트 초기화

먼저 .gguf 형식의 모델 파일을 로드하고, 추론을 위한 컨텍스트(메모리 공간과 KV 캐시)를 확보합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


int main(int argc, char ** argv) {
 if (argc < 2) {
 std::cerr << "Usage: " << argv[0] << " <model.gguf>" << std::endl;
 return 1;
 }
 std::string model_path = argv[1];

 // 1. 백엔드 초기화(CPU/GPU 등의 환경 셋업)
 llama_backend_init();

 // 2. 모델 매개변수의 기본 설정 가져오기
 llama_model_params model_params = llama_model_default_params();
 model_params.n_gpu_layers = 35; // GPU로 오프로드할 레이어 수

 // 3. 모델 로드
 llama_model * model = llama_load_model_from_file(model_path.c_str(), model_params);
 if (model == nullptr) {
 std::cerr << "Failed to load model" << std::endl;
 return 1;
 }

 // 4. 컨텍스트 매개변수 설정
 llama_context_params ctx_params = llama_context_default_params();
 ctx_params.n_ctx = 2048; // 최대 컨텍스트 크기(토큰 수)
 ctx_params.n_threads = 8; // 추론에 사용할 CPU 스레드 수

 // 5. 컨텍스트 생성
 llama_context * ctx = llama_new_context_with_model(model, ctx_params);
 if (ctx == nullptr) {
 std::cerr << "Failed to create context" << std::endl;
 llama_free_model(model);
 return 1;
 }

 std::cout << "Model and context loaded successfully!" << std::endl;
 // ... 이후의 처리

5.3 프롬프트 토큰화 (Tokenization)

LLM은 텍스트를 직접 이해하는 것이 아니라, 정수 ID(토큰)의 나열로써 처리합니다. 입력 문자열을 토큰으로 변환할 필요가 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 std::string prompt = "Q: 일본의 수도는 어디인가요?\nA:";
 std::vector<llama_token> tokens_list;
 tokens_list.resize(prompt.length() + 4); // 여유를 둔 버퍼 크기

 // 특수 토큰(BOS: Begin of Sequence 등)을 맨 앞에 추가할지 여부
 bool add_special = true;
 // 문자열을 토큰 ID의 배열로 변환
 int n_tokens = llama_tokenize(
 model,
 prompt.c_str(),
 prompt.length(),
 tokens_list.data(),
 tokens_list.size(),
 add_special,
 false // parse_special
 );

 if (n_tokens < 0) {
 // 버퍼가 부족한 경우는 재할당하여 재시도하는 처리가 필요(간략화를 위해 생략)
 std::cerr << "Failed to tokenize prompt" << std::endl;
 return 1;
 }
 tokens_list.resize(n_tokens);

5.4 추론 루프 및 샘플링

토큰을 모델에 입력하고, 다음 토큰의 확률 분포(Logits)를 구한 뒤 거기서 샘플링을 수행해 다음 토큰을 결정하는 루프를 구축합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


 // 생성할 최대 토큰 수
 const int max_gen_tokens = 100;

 // 배치 평가를 위한 구조체를 초기화
 llama_batch batch = llama_batch_init(512, 0, 1);

 // 프롬프트의 토큰을 배치에 추가
 for (size_t i = 0; i < tokens_list.size(); i++) {
 llama_batch_add(batch, tokens_list[i], i, { 0 }, false);
 }
 // 프롬프트의 마지막 토큰에서만 로짓(예측 결과)을 출력하도록 설정
 batch.logits[batch.n_tokens - 1] = true;

 // 첫 번째 평가(프롬프트를 모델에 제공)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "llama_decode() failed" << std::endl;
 return 1;
 }

 int n_cur = batch.n_tokens; // 현재의 컨텍스트 길이
 int n_decode = 0;

 std::cout << "\nOutput: ";

 // 샘플러 컨텍스트 초기화(Temperature, Top-K, Top-P 등의 설정)
 llama_sampler * smpl = llama_sampler_chain_init(llama_sampler_chain_default_params());
 llama_sampler_chain_add_top_k(smpl, 40);
 llama_sampler_chain_add_top_p(smpl, 0.9f, 1);
 llama_sampler_chain_add_temp(smpl, 0.7f);
 llama_sampler_chain_add_dist(smpl, 1234); // 시드 값

 while (n_decode < max_gen_tokens) {
 // 1. 샘플링: 현재 컨텍스트를 바탕으로 다음 토큰을 예측
 llama_token new_token_id = llama_sampler_sample(smpl, ctx, -1);

 // 2. 토큰이 EOS (End of Sequence) 라면 루프 종료
 if (llama_token_is_eog(model, new_token_id)) {
 break;
 }

 // 3. 토큰을 문자열(텍스트)로 디코드하여 표시
 char buf[128];
 int n_chars = llama_token_to_piece(model, new_token_id, buf, sizeof(buf), 0, false);
 if (n_chars > 0) {
 std::cout << std::string(buf, n_chars) << std::flush;
 }

 // 4. 새롭게 생성된 토큰을 다음 배치로 준비
 llama_batch_clear(batch);
 llama_batch_add(batch, new_token_id, n_cur, { 0 }, true);

 // 5. 모델 평가(KV 캐시를 갱신하고, 다음을 예측)
 if (llama_decode(ctx, batch) != 0) {
 std::cerr << "Failed to evaluate" << std::endl;
 break;
 }

 n_cur += 1;
 n_decode += 1;
 }

 std::cout << std::endl;

 // 정리(클린업)
 llama_sampler_free(smpl);
 llama_batch_free(batch);
 llama_free(ctx);
 llama_free_model(model);
 llama_backend_free();

 return 0;
}

이 코드는 llama.cpp의 기본 API를 사용하여 독자적인 추론 루프를 구현한 것입니다. llama_batch 구조체를 이용해 토큰 그룹을 관리하고, llama_decode로 신경망의 순전파(Forward Pass)를 실행합니다.

6. 고급 커스터마이징 사례: C++에 의한 로짓 조작 및 페널티 제어

단순한 텍스트 생성에 그치지 않고, 특정 포맷(예: JSON만)의 출력을 강제하거나, 특정한 금지 단어를 출력하지 않도록 제어하는 경우 샘플링 전의 **로짓(Logits)**을 C++ 쪽에서 직접 조작합니다.

모델이 각 토큰을 출력하기 직전의 원시 점수(확률로 변환되기 전의 값) 배열을 가져올 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 추론 직후, 샘플링을 실시하기 전에 원시 로짓 배열을 취득
float * logits = llama_get_logits_ith(ctx, batch.n_tokens - 1);
int n_vocab = llama_n_vocab(model);

// 금지 토큰의 ID 목록 (예: 1234, 5678)
std::vector<llama_token> forbidden_tokens = { 1234, 5678 };

// 금지 토큰의 출현 확률을 0(Logit을 마이너스 무한대)으로 만든다
for (llama_token bad_tok : forbidden_tokens) {
 logits[bad_tok] = -INFINITY;
}

이처럼 C++ API를 직접 다룸으로써 LangChain이나 Python 경유로는 실현하기 어렵거나 오버헤드가 커지는 **‘추론 사이클마다 마이크로 밀리초 단위의 개입’**이 가능해집니다.

7. 성능 튜닝의 극의

C++로 구현을 마친 후, 실제 운영을 위해 속도를 한계까지 높이기 위한 체크 포인트를 몇 가지 소개합니다.

배치 처리 최적화: 여러 사용자의 요청을 동시에 처리할 경우, llama_batch에 여러 시퀀스를 포함하여 한 번에 llama_decode를 호출합니다(Continuous Batching). 이를 통해 메모리 액세스를 공유하여 처리량(스루풋)을 획기적으로 향상할 수 있습니다.
Flash Attention 활성화: 컨텍스트 매개변수에서 ctx_params.flash_attn = true;를 설정함으로써, 메모리 사용량을 줄이면서 Attention 계산을 고속화할 수 있습니다. 긴 컨텍스트(수만 토큰)를 다룰 때는 필수적인 설정입니다.
NUMA 지원: 멀티 소켓 서버 환경에서는 llama_backend_init() 전에 NUMA 설정을 적절히 수행함으로써 메모리 액세스 대기 시간(레이턴시)을 줄일 수 있습니다.

8. 마치며

본 기사에서는 llama.cpp의 수학적인 배경부터 시작해 아키텍처 해설, 그리고 C++ API를 구사한 맞춤형 추론 엔진 구축 방법까지 상세하게 해설했습니다.

Python 생태계는 프로토타이핑에는 매우 편리하지만, 엣지 디바이스로의 배포, 게임에 통합, 실시간 처리가 요구되는 프로덕션 환경에서는 C/C++ 기반의 llama.cpp 직접 제어가 압도적인 힘을 발휘합니다.

여러분도 꼭 직접 C++ 코드를 작성하고, 로컬 환경에서 LLM을 자유자재로 다루는 즐거움을 경험해 보시길 바랍니다.

참고 링크 모음

llama.cpp Official Repository

ggml - Tensor Library

Attention Is All You Need (Vaswani et al., 2017)

【2026년 최신】 로컬 LLM을 Windows 환경에서 구동하는 완전 가이드

Fri, 11 Sep 2026 10:00:00 +0900

1. 소개: 왜 지금 Windows에서 로컬 LLM인가?

2026년 현재, 생성형 AI와 대규모 언어 모델(LLM)의 진화는 클라우드 상의 거대한 API 서비스에서 개인 PC나 온프레미스 환경에서 동작하는 ‘로컬 LLM’으로 큰 패러다임 전환을 보여주고 있습니다. OpenAI의 GPT-5나 Anthropic의 Claude 3.5와 같은 클라우드 AI는 매우 강력하지만, 기업이나 개인이 모든 데이터를 클라우드로 전송할 수 있는 것은 아닙니다. 개인정보 보호, 보안, 대기 시간(레이턴시), 그리고 장기적이고 지속 가능한 비용 관점에서 로컬 LLM에 대한 수요는 그 어느 때보다 폭발적으로 증가하고 있습니다.

특히 Windows 환경에서 로컬 LLM 생태계의 발전은 눈부십니다. 몇 년 전까지만 해도 “AI 개발 및 실행은 Linux"라는 것이 상식이었지만, 2026년 현재 Windows는 매우 강력하고 편리한 AI 플랫폼으로 변모했습니다.

본 기사에서는 2026년 최신 기술 동향을 바탕으로 Windows 환경에서 로컬 LLM을 구축, 운영 및 최적화하기 위한 완전한 가이드를 제공합니다. 초보자를 위한 Ollama를 사용한 간단한 구축부터, 고급 사용자를 위한 llama.cpp를 활용한 극한의 최적화, 나아가 VRAM 계산의 수학적 접근 및 아키텍처에 대한 깊은 이해, 그리고 로컬에서의 파인튜닝(미세조정)까지 압도적인 분량으로 철저하게 해설합니다.

1.1 2026년 로컬 LLM을 둘러싼 기술 트렌드

현재의 로컬 LLM 생태계를 형성하는 주요 트렌드는 다음과 같습니다.

GGUF 포맷의 완전한 보급: 메타데이터와 텐서를 단일 파일로 통합한 GGUF(GPT-Generated Unified Format)가 완전히 사실상 표준(De facto standard)이 되었습니다. 이를 통해 Hugging Face에서 파일 하나를 다운로드하는 것만으로 어떤 환경에서든 실행할 수 있게 되었습니다.
MoE(Mixture of Experts) 아키텍처의 대중화: 소규모이면서도 고성능인 MoE 모델이 다수 출시되었으며, 추론 시 일부 전문가(Expert)만 활성화함으로써 일반 소비자용 PC의 계산 부하를 억제하면서 거대 모델에 필적하는 성능을 내고 있습니다.
추론 엔진의 고도화된 추상화 및 최적화: Ollama, LM Studio, AnythingLLM 등의 도구가 세련되어져서 사용자가 CUDA 드라이버 설치 등 복잡한 의존성을 신경 쓸 필요가 없어졌습니다. 또한 FlashAttention 3의 Windows 네이티브 지원으로 추론 속도가 극적으로 향상되었습니다.
NPU 활용과 Windows Copilot+ PC의 대두: GPU가 없는 노트북에서도 탑재된 NPU(Neural Processing Unit)를 활용하여 소규모 LLM(SLM: Small Language Models)을 저전력으로 구동하는 기술이 실용화 단계에 접어들었습니다.

2. 하드웨어 요구 사항 및 OS 준비

로컬 LLM을 실용적인 속도(초당 15~30 토큰 이상)로 구동하기 위해서는 하드웨어 선택이 가장 중요합니다.

2.1 권장 하드웨어 구성

AI PC의 진화에 따라 요구 스펙도 변화하고 있습니다.

OS: Windows 11 Pro (24H2 이후). WSL2의 완전한 기능과 고급 메모리 관리, 나아가 DirectML의 최신 API를 활용하기 위해 필수적입니다.
CPU: Intel Core Ultra 200 시리즈 이상 또는 AMD Ryzen 9000 시리즈 이상. CPU 추론을 병행할 경우, 광대역 메모리 통신이 필수적입니다.
RAM: 최소 32GB, 권장 64GB 이상. 메인 메모리의 대역폭(MB/s)이 CPU 추론 시나 오프로드(Offload) 시 결정적인 병목 지점이 됩니다. DDR5-6000 이상의 고속 메모리가 이상적입니다.
GPU: NVIDIA RTX 4000/5000 시리즈. 로컬 LLM에서 가장 중요한 것은 연산 성능이 아니라 ‘VRAM 용량’입니다.
- 엔트리: RTX 4060 Ti (16GB 버전) - 가성비 최강. 8B~14B 클래스의 모델에 최적입니다.
- 미들레인지: RTX 4070 Ti SUPER (16GB) / RTX 4080 SUPER (16GB)
- 하이엔드: RTX 4090 (24GB) / RTX 5090 (32GB) - 30B~70B 클래스의 양자화 모델을 구동하기 위해 필요합니다.
스토리지: PCIe Gen4 또는 Gen5 NVMe SSD. 수십 GB에 달하는 모델 로드 시간을 극적으로 단축시킵니다.

2.2 WSL2 (Windows Subsystem for Linux 2) 설정

많은 GUI 도구는 Windows 네이티브로 동작하지만, Python을 사용한 개발, 최신 도구 컴파일, 후술할 LoRA 파인튜닝에는 WSL2가 매우 편리합니다. Windows 11의 최신 환경에서는 호스트 쪽에 NVIDIA 드라이버를 설치하는 것만으로 WSL2에서 투명하게 GPU(CUDA)를 사용할 수 있습니다.

관리자 권한으로 PowerShell을 열고 다음을 실행합니다.

1
2
3
4
5


# WSL2와 최신 Ubuntu 설치
wsl --install -d Ubuntu-24.04

# 커널 업데이트
wsl --update

설치 후 WSL2 터미널 내에서 nvidia-smi를 실행하여 GPU가 정상적으로 인식되면 성공입니다.

3. 로컬 LLM 아키텍처 및 추론 메커니즘

로컬 환경에서 모델이 어떻게 텍스트를 생성하는지, 그 내부 구조를 이해하는 것은 문제 해결(트러블슈팅)이나 최적화에 매우 유용합니다.

다음 Mermaid 다이어그램은 전형적인 로컬 LLM의 추론 파이프라인을 보여줍니다.

graph TD User["사용자 입력 (프롬프트)"] --> Tokenizer["토크나이저 (Tokenizer)"] Tokenizer --> Embedding["임베딩 계층 (Embedding)"] subgraph "Transformer Block (x Layers)" Embedding --> Attn["자기 주의 (Self-Attention)"] Attn --> KVCache["KV 캐시 (Key/Value 유지)"] Attn --> FFN["피드 포워드 네트워크 (FFN)"] end FFN --> Logits["로짓 계산 (Logits)"] Logits --> Sampler["샘플러 (Temperature, Top-K, Top-P)"] Sampler --> OutputToken["출력 토큰"] OutputToken --> |"자기 회귀 생성 (Autoregressive)"| Tokenizer OutputToken --> Decoder["디토크나이저 (Detokenizer)"] Decoder --> FinalOutput["최종 출력 텍스트"]

3.1 2가지 단계: Prefill과 Decode

LLM의 텍스트 생성은 계산 특성이 다른 두 가지 단계로 나뉩니다.

Prefill (프롬프트 처리) 단계: 입력된 프롬프트 전체를 한 번에 처리하고 이해하는 단계입니다. 병렬 계산이 가능하므로 GPU의 계산 능력(FLOPS)이 속도에 직결됩니다. 프롬프트가 길 경우 이 단계에 몇 초가 걸릴 수 있습니다.
Decode (토큰 생성) 단계: 1 토큰씩 예측하고 다음 입력으로 넘기는(자기 회귀, Autoregressive) 단계입니다. 이 단계에서는 병렬 계산이 제한되므로 GPU의 VRAM 대역폭(Memory Bandwidth)이 결정적인 병목 지점이 됩니다.

4. VRAM 소비량 계산 및 모델 크기의 수학적 이해

“내 PC에서 어떤 모델이 돌아갈까?“를 정확히 판단하려면 VRAM 계산 공식을 이해해야 합니다. VRAM 부족으로 인해 시스템 메모리(RAM)로의 폴백(Fallback)이 발생하면 추론 속도는 10배~100배 느려집니다.

4.1 파라미터 크기 기반 기본 VRAM

모델의 가중치(웨이트)를 VRAM에 로드하기 위한 메모리 양입니다. 모델 크기 $P$ (파라미터 수, 단위: 10억 = 1B)와 1 파라미터당 바이트 수 $B$를 사용하여 계산합니다.

$$ V_{base} = P \times B \quad \text{(GB)} $$

예를 들어, 8B(80억) 파라미터 모델을 FP16(반정밀도 부동소수점, 16비트=2바이트)으로 로드할 경우:

$$ V_{base} = 8 \times 2 = 16 \text{ GB} $$

즉, 16GB VRAM을 가진 GPU라도 모델을 로드하는 것만으로 거의 한계에 도달하게 됩니다.

4.2 양자화(Quantization)의 마법

여기서 ‘양자화’가 등장합니다. 파라미터의 정밀도를 낮춰 모델 크기를 극적으로 축소합니다. 가장 일반적인 4bit 양자화(예: Q4_K_M)의 경우, 1 파라미터당 평균 약 0.55바이트가 됩니다.

$$ V_{base\_4bit} = 8 \times 0.55 = 4.4 \text{ GB} $$

이를 통해 16GB의 VRAM이 있다면 충분한 여유를 가지고 8B 모델을 구동할 수 있습니다.

4.3 KV 캐시 계산 (GQA 지원 버전)

추론 시에는 과거의 문맥을 유지하기 위한 ‘KV 캐시’가 VRAM을 소비합니다. Llama 3 등 최신 모델에서는 메모리 절약을 위해 GQA(Grouped Query Attention)가 채택되었습니다.

KV 캐시 소비량 $V_{kv}$ (기가바이트)는 다음 수식으로 표현됩니다.

$$ V_{kv} = 2 \times b \times s \times l \times \left( \frac{h_{kv}}{h_q} \right) \times h_q \times d \times B_{kv} \div 10^9 $$

정리하면, 키와 값의 헤드 수 $h_{kv}$를 사용하여 단순하게 계산할 수 있습니다.

$$ V_{kv} = 2 \times b \times s \times l \times h_{kv} \times d \times B_{kv} \div 10^9 $$

여기서:

$b$: 배치 크기 (개인의 로컬 사용이라면 보통 1)
$s$: 시퀀스 길이 (컨텍스트 길이, 예: 8192)
$l$: 레이어 수 (예: 32)
$h_{kv}$: KV 헤드 수 (예: 8)
$d$: 헤드당 차원 수 (예: 128)
$B_{kv}$: KV 캐시의 바이트 수 (FP16이면 2)

계산 예 (Llama 3 8B, 컨텍스트 8192, FP16 캐시): $V_{kv} = 2 \times 1 \times 8192 \times 32 \times 8 \times 128 \times 2 \div 10^9 \approx 1.07 \text{ GB}$

컨텍스트 길이 $s$를 길게 할수록 필요한 VRAM은 선형적으로 증가한다는 점에 주의하십시오.

5. 실전 1: Ollama를 이용한 가장 빠르고 짧은 설정

이론을 이해했으니, 실제로 Windows 환경에서 LLM을 구동해 봅시다. 2026년 현재 가장 사용자 친화적인 도구가 ‘Ollama’입니다. Docker와 유사한 직관적인 CLI를 제공합니다.

5.1 설치 및 실행

Ollama 공식 웹사이트에서 Windows 버전 설치 프로그램을 다운로드하여 실행합니다.
PowerShell을 열고 다음 명령어를 입력합니다. 여기서는 일본어/한국어 등을 지원하는 llama3:8b를 사용합니다.

1

ollama run llama3:8b

최초 실행 시 모델 다운로드가 진행됩니다. 완료되면 터미널에서 바로 대화가 가능합니다.

5.2 Modelfile을 통한 사용자 정의 AI 생성

특정 페르소나를 가진 AI를 쉽게 생성할 수 있습니다. 임의의 위치에 Modelfile을 생성합니다.

1
2
3
4
5
6
7
8
9


FROM llama3:8b

SYSTEM """
당신은 매우 뛰어난 시니어 소프트웨어 엔지니어입니다.
사용자의 질문에 대해 반드시 코드 예시를 곁들여 논리적이고 간결하게 답변해 주세요.
"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192

다음 명령어로 자체 모델을 빌드하고 실행합니다.

1
2


ollama create SeniorDev -f ./Modelfile
ollama run SeniorDev

5.3 외부 앱 (AI 에디터)에서 활용

Ollama는 http://localhost:11434에 OpenAI 호환 API 엔드포인트를 공개합니다. Cursor나 Continue.dev와 같은 VS Code 확장 프로그램의 백엔드 설정에서 URL을 위와 같이 지정하고, 모델 이름에 SeniorDev 등을 지정하기만 하면 무료로 강력한 로컬 코딩 어시스턴트가 실현됩니다.

6. 실전 2: llama.cpp에 의한 극한의 성능 튜닝

세밀한 메모리 관리나 최신 포맷(EXL2나 IQ 양자화 등)을 가장 먼저 시도해보고 싶다면, 핵심 엔진인 llama.cpp를 직접 조작합니다.

6.1 llama.cpp 빌드 절차

Windows 환경에서는 CUDA Toolkit과 CMake를 사용하여 소스에서 빌드하는 것이 가장 좋습니다.

1
2
3
4
5
6
7
8


git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build
cd build

# CUDA 지원으로 구성하고 컴파일
cmake .. -DLLAMA_CUBLAS=ON -DBUILD_SHARED_LIBS=OFF
cmake --build . --config Release -j 16

6.2 서버 모드에서의 고급 실행

빌드된 llama-server.exe를 사용하여 모델을 호스팅합니다.

1
2
3
4
5
6
7


.\bin\Release\llama-server.exe `
 --model "C:\models\Llama-3-8B-Instruct.Q4_K_M.gguf" `
 --ctx-size 8192 `
 --n-gpu-layers 99 `
 --threads 8 `
 --flash-attn `
 --port 8080

--n-gpu-layers 99: 가능한 모든 레이어를 GPU VRAM으로 오프로드합니다.
--flash-attn: FlashAttention 3을 활성화하여 추론 속도를 향상시키고 KV 캐시의 VRAM 소비를 줄입니다.

7. GUI 프론트엔드: LM Studio 및 로컬 RAG 구축

명령줄(CLI)에 거부감이 있거나 RAG(검색 증강 생성)를 직관적으로 수행하고 싶은 경우 GUI를 이용합니다.

7.1 LM Studio

LM Studio는 모델 검색, 다운로드, 시스템 요구 사항 사전 확인, 그리고 채팅 UI까지 하나로 통합한 훌륭한 애플리케이션입니다. 앱 내의 “Local Server” 버튼을 누르기만 하면 OpenAI 호환 API가 시작됩니다.

7.2 AnythingLLM을 이용한 RAG 아키텍처

사내 문서나 개인 메모를 읽게 하는 RAG 환경의 아키텍처 다이어그램입니다.

graph LR Document["문서 (PDF, MD)"] --> Chunking["청크 분할 (Chunking)"] Chunking --> EmbedModel["임베딩 모델"] EmbedModel --> VectorDB["벡터 데이터베이스"] UserQuery["사용자 질문"] --> EmbedQuery["질문 임베딩"] EmbedQuery --> VectorDB VectorDB --> |"유사도 검색"| RetrievedDocs["관련 문서 추출"] UserQuery --> PromptBuilder["프롬프트 생성"] RetrievedDocs --> PromptBuilder PromptBuilder --> LocalLLM["로컬 LLM"] LocalLLM --> Answer["최종 답변"]

AnythingLLM 데스크톱 버전(Windows)을 사용하면 설정 화면에서 Ollama(LLM 및 Embedding)를 지정하고, 로컬 VectorDB(LanceDB)를 사용하도록 설정하는 것만으로 몇 분 만에 이 아키텍처가 완성됩니다. 데이터를 외부에 전혀 전송하지 않는 프라이빗 AI의 탄생입니다.

8. Windows WSL2 상에서의 파인튜닝 (LoRA)

로컬에서 구동할 뿐만 아니라 내 데이터로 모델을 똑똑하게 만들고 싶다면, LoRA(Low-Rank Adaptation)를 이용한 파인튜닝이 가능합니다. 2026년 현재 ‘Unsloth’라는 라이브러리를 사용하면 Windows의 WSL2 환경에서 16GB VRAM으로도 8B 모델의 학습을 몇 시간 만에 완료할 수 있습니다.

WSL2의 Ubuntu 내에서 다음을 실행하여 환경을 구축합니다.

1
2
3
4


conda create --name unsloth_env python=3.11
conda activate unsloth_env
pip install "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git"
pip install --no-deps trl peft accelerate bitsandbytes

Unsloth는 CUDA 커널을 극한까지 최적화하여, 표준 Hugging Face 라이브러리와 비교해 학습 속도가 약 2배, VRAM 소비량이 약 절반이 됩니다. Jupyter Notebook을 실행하고 데이터 세트(JSONL 형식)를 읽어 들이는 것만으로, VRAM 12GB~16GB의 RTX 4060 Ti 등에서도 몇 에포크(epoch)의 학습이 가능합니다.

9. 성능 및 문제 해결 (트러블슈팅)

자주 직면하는 문제와 그 해결책입니다.

1. 추론 속도가 극단적으로 느림 (1~2 tokens/s)

원인: 모델이 VRAM에 다 들어가지 못하고 시스템 메모리(RAM)로 오프로드되었습니다. 대책: 작업 관리자에서 “전용 GPU 메모리"를 확인해 주세요. 한계에 도달한 경우 컨텍스트 크기(-c)를 줄이거나 더 낮은 비트 수의 양자화 모델(Q4_K_M 등)을 사용하십시오.

2. “CUDA out of memory” 에러

원인: VRAM이 완전히 고갈되었습니다. 특히 대화가 길어져 KV 캐시가 비대해졌을 때 발생합니다. 대책: Ollama의 경우 num_ctx, llama.cpp의 경우 -c 값을 의도적으로 작게 제한합니다.

3. 언어(일본어/한국어 등) 생성이 이상함

원인: 프롬프트 템플릿의 불일치 또는 지원하지 않는 모델입니다. 대책: 모델 이름에 Instruct가 포함된 것을 사용하고, ChatML이나 Llama3 포맷 등 모델 작성자가 지정한 올바른 템플릿이 도구 측에서 선택되어 있는지 확인하십시오.

10. 요약 및 향후 전망

2026년, Windows 환경에서의 로컬 LLM 구축은 더 이상 일부 엔지니어들만의 특권이 아닙니다. GGUF 포맷의 사실상 표준화, Ollama나 LM Studio와 같이 세련된 생태계의 등장, 그리고 FlashAttention을 비롯한 하드웨어 최적화 덕분에 누구나 쉽게 엔터프라이즈급 AI 환경을 구축할 수 있게 되었습니다.

이 기사에서 설명한 다음 요점들을 꼭 활용해 보시기 바랍니다.

VRAM의 수학적 계산을 활용하여 내 PC 스펙에 최적화된 모델 크기와 양자화 수준을 논리적으로 선택한다.
Ollama를 사용하여 가장 빠르게 환경을 구축하고, AI 에디터와 연동하여 생산성을 극적으로 향상시킨다.
llama.cpp의 고급 파라미터 제어로 하드웨어의 한계 성능을 끌어낸다.
AnythingLLM으로 기밀 데이터를 다루는 안전한 로컬 RAG 시스템을 구축한다.
**Unsloth (WSL2)**를 활용하여 나만의 전문 지식을 가진 커스텀 AI를 육성한다.

AI의 ‘대중화’는 더 이상 버즈워드가 아니라 여러분의 Windows 데스크톱에서 작동하는 현실의 시스템입니다. 클라우드 API 사용 비용이나 정보 유출 위험에서 벗어나, 자유롭고 강력한 프라이빗 AI의 세계로 지금 당장 발을 들여놓아 보시기 바랍니다.