LocalAI 딥다이브
— 하나의 API 뒤에 여러 AI 엔진을 연결하는 법

1프로젝트 한줄 요약

LocalAI는 여러 추론 엔진을 설치·실행·관리하고, 그 위에 공통 HTTP API와 웹 화면을 제공하는 자체 호스팅 AI 서버입니다. 텍스트는 llama.cpp나 vLLM, 음성은 Whisper 계열이나 TTS 엔진, 이미지는 생성 엔진에 맡기고, 사용자는 하나의 서버 주소를 통해 요청합니다.

핵심은 역할 구분입니다. 같은 API를 유지하면서 실제 추론을 맡는 엔진을 바꿀 수 있게 만드는 것이 LocalAI의 중심 설계입니다. 이 경계를 이해하면 새로운 모델을 직접 학습하지 않아도 AI 서비스를 만드는 데 필요한 서버 기술을 배울 수 있습니다.

1-1. 사용자에게 보이는 최소 단위

다음은 채팅 요청의 형태입니다. model은 설치된 모델 설정의 이름이고, messages는 역할과 내용을 가진 대화 목록입니다. 이 JSON 자체가 AI를 계산하는 것은 아닙니다. 서버가 이를 해석해 적절한 엔진으로 전달합니다.

{
  "model": "study-chat",
  "messages": [
    {"role": "user", "content": "API와 함수의 차이를 쉽게 설명해 줘."}
  ],
  "stream": false
}

실제 등록 지점은 core/http/routes/openai.go의 RegisterOpenAIRoutes()입니다. /v1/chat/completions와 /chat/completions가 같은 ChatEndpoint()를 사용합니다. 경로가 두 개여도 처리 코드를 공유하는 사례입니다.

1-2. 이 저장소를 읽고 얻을 것

2왜 주목받는가

2026-10-23 GitHub Trending Go Weekly #4에 선정되었고, GitHub 기준 스타는 49,866개입니다. 순위만으로 관심의 원인을 증명할 수는 없습니다. 여기서는 README의 기능 설명과 소스 구조를 바탕으로 관심을 끌 만한 기술적 이유를 해석합니다.

• 기존 클라이언트와 연결하기 쉽습니다. 익숙한 채팅·임베딩 API 경로를 제공하므로 서버 주소와 모델 이름을 바꾸는 방식으로 통합을 시작할 수 있습니다. 세부 필드와 도구 호출 동작은 따로 확인해야 합니다.
• 텍스트 밖의 기능도 같은 플랫폼에서 관리합니다. backend/backend.proto에는 GenerateImage, AudioTranscription, TTS, GenerateVideo 같은 RPC가 함께 정의되어 있습니다.
• 필요한 엔진을 분리해서 공급합니다. README의 작은 코어·선택적 백엔드라는 방향은 별도 백엔드 이미지, 설치 카탈로그, 외부 실행 파일 등록 코드로 이어집니다.
• 개인 실험에서 운영까지 이어질 여지가 있습니다. React 관리 화면, 사용자 인증, 사용량 기록, 선택적 분산 모드가 소스에 있습니다. 기능 수가 늘어난 만큼 설정과 운영의 학습량도 늘어납니다.

LocalAI의 차별점은 하나의 추론 엔진보다 여러 엔진을 함께 운영하는 공통 계층에 있습니다. 따라서 경쟁 도구와 비교할 때도 단순 속도 순위보다 어디까지 묶어서 제공하는지를 살펴봐야 합니다.

2-1. 비슷해 보여도 공부하는 층이 다르다

비교 근거: Ollama 호환 API 문서, vLLM 서빙 문서, llama.cpp 공식 저장소. 각 도구의 지원 범위는 계속 바뀌며, 위 표는 속도·품질 벤치마크가 아닙니다.

2-2. 최근 커밋에서 읽히는 방향: 엔진도 라이브러리로 관리

f1ff707의 제목은 feat(addons): list and install backends from a library (#12816)입니다. 대응 소스인 core/gallery/backend_library.go는 gallery/backends/index.yaml을 백엔드 목록의 원본으로 설명하고, backend/index.yaml은 이전 릴리스와의 호환을 위한 생성본으로 구분합니다.

BackendLibraryEntries()는 플랫폼별 이미지 정보를 라이브러리 항목으로 바꾸고, BackendsFromLibrary()는 기존 갤러리 형식으로 되돌립니다. .github/workflows/backend-library.yml은 실제 목록의 변환과 생성본 일치 여부를 검사합니다. 새 저장 형식을 도입하면서 기존 소비자를 유지하는 호환성 설계 사례입니다.

2-3. 소개 문구는 설정과 함께 읽는다

최신 릴리스 v4.12.0은 2026-10-22에 공개되었고, 분석 기준 커밋은 다음 날의 커밋입니다. 따라서 이 글의 모든 소스 관찰을 v4.12.0의 배포 기능과 동일시하면 안 됩니다.

3기술 스택 전체 지도

3-1. Go 백엔드: API와 실행 제어의 중심

루트 go.mod의 모듈은 github.com/mudler/LocalAI, Go 선언은 1.26.0입니다. 현재 HTTP 서버가 가져오는 프레임워크는 Echo입니다. 의존성 목록에 다른 웹 프레임워크가 간접 의존성으로 보이더라도 주 서버라고 판단하면 안 됩니다.

SQLite·Postgres는 모델 가중치를 넣는 필수 저장소라는 뜻이 아닙니다. 가중치 파일, 모델 YAML, 인증 DB, 분산 상태의 역할이 다릅니다. core/application/distributed.go의 initDistributed()도 분산 모드가 꺼져 있으면 서비스를 만들지 않고 반환합니다.

3-2. 추론 백엔드: 언어도 의존성도 엔진마다 다르다

두 requirements 파일은 모두 backend/python/vllm/ 아래에 있습니다. backend/python/vllm/install.sh에는 Intel·ROCm·Darwin·Jetson별 분기가 있고 Python 3.12 선택도 분기별로 다릅니다. 이 저장소 전체의 Python·PyTorch·vLLM을 단일 버전으로 요약하는 것은 부정확합니다.

3-3. 프론트엔드: React와 JavaScript/JSX

현재 UI는 core/http/react-ui/의 React 앱입니다. 페이지의 실제 확장자는 주로 .jsx이며, TypeScript 앱이라고 소개할 근거는 없습니다. 이전 UI 자산은 core/http/static/에 남아 있습니다.

^19.1.0은 19.1.0 하나만 허용하는 표기가 아닙니다. 설치 가능한 범위는 의존성 선언에서, 기록된 해결 버전은 잠금 파일에서 확인해야 합니다. 두 Router 패키지는 선언과 잠금 파일 모두 서로 다른 주 버전입니다. 숫자를 임의로 통일해서 읽지 마세요.

core/http/react-ui/vite.config.js의 개발 서버는 3000번 포트이고, 기본 API 대상은 http://localhost:8080입니다. /api, /v1, /models 등을 프록시합니다. 배포 결과는 dist에 생성되고 Go 서버가 이를 포함합니다.

// core/http/app.go — 정적 UI를 Go 바이너리에 포함
//go:embed react-ui/dist/*
var reactUI embed.FS

core/http/react-ui/src/router.jsx는 React의 lazy()와 동적 import로 페이지를 나누고, preloadRoute()로 미리 불러올 수 있게 합니다. core/http/react-ui/src/utils/api.js의 streamChat()은 stream: true를 보내고 응답의 ReadableStream을 반환합니다.

3-4. 인프라 · 빌드 · CI

이미지 태그와 일부 Python 의존성이 가변적이고, Dockerfile은 npm ci 대신 npm install을 사용합니다. 잠금 파일이 있다는 사실만으로 모든 설치 경로의 완전한 재현성을 보장할 수는 없습니다.

4아키텍처 심화 분석

4-0. 전체 시스템 구조

아래 그림은 일반적인 로컬 채팅 경로를 중심으로 단순화했습니다. 인증·라우팅·압축·도구 사용은 설정에 따라 달라지고, 분산 모드는 별도 분기입니다. 다운로드는 준비 단계, gRPC 추론은 실행 단계라는 점을 구분하세요.

4-1. 패턴 ① 어댑터와 공통 계약

어댑터는 서로 다른 인터페이스 사이의 번역기입니다. LocalAI에서는 HTTP JSON을 받는 코드와 각 엔진을 호출하는 코드 사이에 Protocol Buffers 계약이 놓여 있습니다. 엔진마다 고유한 인자를 HTTP 핸들러 곳곳에 직접 넣지 않도록 경계를 만듭니다.

1. RegisterOpenAIRoutes()가 채팅 핸들러와 요청 해석 미들웨어를 조합합니다. 전역 인증은 core/http/app.go가 설치합니다.
2. ChatEndpoint()는 해석된 OpenAIRequest와 ModelConfig를 컨텍스트에서 꺼냅니다. 대화 메시지와 시스템 프롬프트를 정리합니다.
3. core/http/endpoints/openai/inference.go의 ComputeChoices()가 backend.ModelInferenceFunc를 호출합니다.
4. ModelInference()는 로더로 백엔드를 준비하고 실제 예측용 함수를 반환합니다. ComputeChoices()가 그 함수를 호출할 때 예측이 진행됩니다.
5. 엔진별 서버가 LoadModel·Predict·PredictStream을 자신의 구현에 연결합니다.

// backend/backend.proto — 주요 계약만 발췌
service Backend {
  rpc Health(HealthMessage) returns (Reply) {}
  rpc LoadModel(ModelOptions) returns (Result) {}
  rpc Predict(PredictOptions) returns (Reply) {}
  rpc PredictStream(PredictOptions) returns (stream Reply) {}
  rpc Embedding(PredictOptions) returns (EmbeddingResult) {}
  rpc TTS(TTSRequest) returns (Result) {}
}

C++ 쪽은 backend/cpp/llama-cpp/grpc-server.cpp의 BackendServiceImpl이 이 계약을 구현합니다. LoadModel()에는 params_parse(), llama_backend_init() 등이 보입니다. Python 쪽은 backend/python/vllm/backend.py의 BackendServicer.LoadModel()이 AsyncEngineArgs를 만들고 AsyncLLMEngine.from_engine_args()로 엔진을 초기화합니다.

추상화의 효과는 구현 차이를 감추는 데 있지만, 기능 지원 여부와 실패까지 없애 주지는 않습니다. 예를 들어 선택적 RPC는 백엔드에 따라 UNIMPLEMENTED를 반환할 수 있습니다. 이때 HTTP 경로가 존재한다는 사실만으로 실행 성공을 예상하면 안 됩니다.

4-2. 패턴 ② 지연 로딩과 같은 작업에 합류하기

모델은 일반 객체보다 훨씬 큽니다. 같은 모델을 요구하는 요청 10개가 동시에 들어왔다고 가중치를 10번 읽고 프로세스 10개를 띄우면 메모리가 부족해질 수 있습니다. 로컬 모드의 pkg/model/loader.go는 이 문제를 loading 맵과 채널로 조정합니다.

// loadModel()의 핵심 흐름을 줄인 의사 코드
잠금 획득
이미 준비된 모델이 있으면 반환
같은 modelID의 로딩 채널이 있으면:
    잠금 해제
    채널이 닫힐 때까지 기다림
    준비된 모델 확인 또는 재시도 경로로 이동
새 로딩 채널 등록
잠금 해제

모델 로딩 실행                 // 오래 걸리는 작업
결과를 모델 저장소에 등록
로딩 채널 정리·닫기

실제 함수는 LoadModelWithFile() → loadModel()입니다. 오래 걸리는 loader(...) 호출 동안 전역 잠금을 잡지 않는 점이 중요합니다. 다른 모델의 로딩까지 같은 잠금으로 막히는 일을 줄입니다. 실패한 모델을 계속 요청할 때 새 프로세스를 반복 생성하지 않도록 실패 후 대기 시간도 둡니다.

pkg/model/initializers.go의 spawnGRPCModel()은 실행 파일이면 StartProcess()를 호출하고, 주소이면 그 서버에 연결합니다. 준비 상태 확인 후 LoadModel RPC를 보내며, 실패하면 준비한 프로세스를 정리합니다. 로컬 실행 주소는 127.0.0.1의 빈 포트에서 선택합니다.

메모리 관리도 이 수명 관리와 연결됩니다. ModelLoader.Load()는 새 모델 로딩 전 그룹 배타성과 LRU 제한을 검사하고, pkg/model/watchdog.go는 사용 중인 요청·유휴 시간·고정 모델 등을 추적합니다. 다만 DefaultWatchDogOptions()에서는 유휴 검사·사용 중 시간 검사·메모리 회수 기능이 꺼져 있고 LRU 제한은 0, 즉 무제한입니다. 실제 활성화 설정을 함께 읽어야 합니다.

분산 모드에는 중요한 예외가 있습니다. loadModel()은 로컬 캐시로 요청을 고정하지 않고 라우터를 다시 거칩니다. 이전 요청의 원격 복제본만 계속 재사용하면 부하 분산이 무너지기 때문입니다. 같은 캐시 정책을 로컬과 분산에 무조건 적용할 수 없다는 교훈입니다.

4-3. 패턴 ③ 설정 기본값의 단계적 적용

서버에는 모델 이름, 엔진, 샘플링 값, 문맥 길이, 스레드 수, 하드웨어 옵션이 함께 들어옵니다. core/config/model_config.go의 ModelConfig.SetDefaults()는 이 설정을 순서대로 보완합니다. 아래는 로직의 주요 순서입니다.

하드웨어 단계를 마지막에 두는 이유가 주석으로 명확합니다. 배치 크기 판단에 최종 문맥 길이가 필요하기 때문입니다. 긴 문맥에서 큰 배치를 고르면 연산용 메모리가 커질 수 있으므로, 문맥을 추정하기 전에 하드웨어 값을 확정하면 잘못된 결정을 할 수 있습니다.

# ModelConfig에 대응하는 학습용 YAML 예시
# 파일 이름은 실제로 준비한 GGUF 파일로 바꿔야 합니다.
name: study-chat
backend: llama-cpp
parameters:
  model: example.Q4_K_M.gguf
  temperature: 0.3
context_size: 4096
threads: 4
template:
  use_tokenizer_template: true

Name은 API에 노출하는 이름이고, parameters.model은 엔진이 읽는 모델 참조입니다. 둘이 반드시 같을 필요는 없습니다. Threads나 여러 불리언 옵션을 포인터로 둔 것도 살펴보세요. 설정이 없다는 상태와 사용자가 0·false를 명시한 상태를 구분하는 데 사용됩니다.

위 YAML은 필드 관계를 설명하기 위한 예시입니다. 모든 모델이 같은 대화 템플릿을 쓰지는 않습니다. use_tokenizer_template 경로에서는 구조화된 메시지를 엔진에 넘기고, 다른 경로에서는 Go 템플릿 평가기가 프롬프트를 구성합니다.

4-4. 패턴 ④ 스트리밍 파이프라인과 취소 전달

채팅 응답을 조금씩 보여주려면 엔진의 출력과 HTTP 응답을 연결해야 합니다. 바깥은 SSE이고 안쪽은 gRPC 서버 스트림입니다. ChatEndpoint()는 text/event-stream 헤더를 설정하고 채널에서 응답 조각을 받아 씁니다.

# SSE 응답 형태를 줄인 예시
data: {"choices":[{"delta":{"content":"안녕"}}]}

data: {"choices":[{"delta":{"content":"하세요"}}]}

data: [DONE]

pkg/grpc/client.go의 Client.PredictStream()은 stream.Recv()를 반복하며 콜백에 조각을 전달합니다. ctx.Done()과 RPC 오류를 확인하고, defer로 연결 종료와 사용 중 상태 정리를 예약합니다. HTTP 쪽도 요청 컨텍스트 취소를 확인합니다.

core/backend/llm.go에는 초보자에게 유용한 세부 구현이 있습니다. 수신 바이트를 partialRune에 모은 뒤 utf8.DecodeRune()으로 완성된 문자를 분리합니다. 한글 한 글자의 UTF-8 바이트가 서로 다른 응답 조각에 나뉠 수 있기 때문입니다. 네트워크 조각과 글자·토큰은 일대일 관계가 아닙니다.

소스 연결: 라우트 조합 · 추론·문자 조각 처리 · 로딩 합류 · 프로세스 준비 · gRPC 클라이언트.

5디렉토리 구조 해부

5-1. 읽는 순서를 책임 순서로 바꾸기

요청 처리의 출발점은 core/http/endpoints/openai/chat.go입니다. 처음에는 core/http/의 요청 경로에서 필요한 호출만 따라가고, core/services/의 분산 노드나 에이전트 기능은 그다음에 살펴보세요.

큰 저장소를 읽을 때는 폴더를 모두 훑기보다 하나의 입력이 통과하는 책임 경계를 따라가면 이해가 빨라집니다. 같은 방법으로 음성을 공부할 때는 TranscriptEndpoint()와 AudioTranscription 계약을 새 출발점으로 삼을 수 있습니다.

5-2. 이름이 비슷한 세 가지 목록

• 모델 목록: 어떤 가중치·설정으로 무엇을 실행할지 설명합니다. gallery/models/ 등에서 찾을 수 있습니다.
• 백엔드 목록: 장치·플랫폼에 맞는 엔진 배포물을 설명합니다. 현재 원본은 gallery/backends/index.yaml입니다.
• 부가 기능 목록: 호스트에 추가할 앱·기능을 설명합니다. gallery/addons/와 addons/를 함께 읽습니다.

공통 카탈로그를 사용하더라도 설치하는 대상의 의미는 다릅니다. 모델 이름, 백엔드 이름, 부가 기능 ID를 모두 같은 식별자로 생각하면 설정과 로그를 해석하기 어려워집니다.

6학습 포인트 (기술별)

AI 서버 공부에서도 빠른 피드백을 만드는 핵심은 실제 모델 없이 검증할 수 있는 경계를 찾는 것입니다. 실제 엔진과의 연동, 장치별 추론 속도와 답변 품질은 엔진·가중치·장치를 갖춘 환경에서 따로 검증해야 합니다.

7하드웨어 / 시스템 요구사항

7-1. 하나의 최소 사양으로 요약하기 어려운 이유

LocalAI 코어가 시작되는 것과 선택한 모델을 메모리에 올리는 것은 다릅니다. 모델 크기, 양자화, 문맥 길이, 동시 요청, 모달리티에 따라 요구 자원이 크게 달라집니다. README의 CPU 지원을 모든 영상·이미지 모델에도 같은 비용으로 적용할 수는 없습니다.

컨테이너 안내는 docs/content/getting-started/containers.md, 장치별 빌드 분기는 backend/cpp/llama-cpp/Makefile과 .github/backend-matrix.yml에서 확인할 수 있습니다. GPU 제조사가 같아도 모든 세대가 같은 백엔드를 지원하는 것은 아닙니다.

7-2. 메모리는 가중치 파일보다 더 필요하다

가중치의 이론적 크기 ≈ 파라미터 수 × 저장 비트 수 ÷ 8
실행 메모리 ≈ 가중치 + KV 캐시 + 연산용 버퍼 + 런타임 여유

7B 모델의 단순 가중치 계산:
  16비트: 7,000,000,000 × 16 ÷ 8 = 약 14 GB
   4비트: 7,000,000,000 ×  4 ÷ 8 = 약 3.5 GB

# GB는 십진 단위입니다. GGUF의 실제 크기·필요 RAM과 다릅니다.
# 양자화 메타데이터, 혼합 정밀도, 부가 모델도 비용에 포함됩니다.

KV 캐시는 이전 토큰의 계산 결과를 보관하는 공간입니다. 문맥 길이와 동시 처리 슬롯이 늘면 이 공간도 커질 수 있습니다. 같은 모델 파일을 사용하더라도 긴 대화를 여러 개 처리하면 메모리 부족이 발생할 수 있습니다.

모델 파일이 메모리보다 작다는 사실만으로 그 모델의 실행 가능 여부를 판단할 수는 없습니다. 처음에는 작은 모델·짧은 문맥·단일 요청을 기준으로 측정하고 하나씩 조건을 바꾸는 편이 원인을 찾기 쉽습니다.

7-3. 소스에 있는 보수적 기본값

출처는 core/config/defaults.go, core/config/hardware_defaults.go, core/config/model_config.go입니다. 이 숫자는 전체 백엔드의 고정 실행값이 아닙니다. 명시적 설정·모델 정보·백엔드별 처리가 최종값에 영향을 줍니다.

PhysicalBatchForContext()는 Blackwell 장치라도 VRAM이 알려져 있지 않거나 문맥에 비해 여유가 부족하면 512를 유지합니다. 여러 GPU의 메모리 합이 아니라 장치 하나의 연산 버퍼 여유를 고려한다는 점도 읽을 만합니다.

7-4. 디스크·네트워크·저장 위치

가중치 외에 백엔드 배포물, Python 환경, 다운로드 캐시, 생성 결과도 공간을 차지합니다. 루트 Dockerfile은 /models, /backends, /configuration, /data를 볼륨 대상으로 선언합니다. 컨테이너를 교체해도 필요한 데이터가 남도록 각각의 역할을 확인해야 합니다.

8직접 해볼 수 있는 실습 과제

실습은 난이도 순서입니다. 모델이 없는 환경에서는 1·4·5번을 먼저 진행할 수 있습니다. 요청 실습은 별도로 준비한 로컬 서버와 설치된 채팅 모델을 전제로 하며, 예시의 모델 이름·인증 키를 그 환경에 맞춰 바꿉니다.

# 인증이 설정된, 이미 준비된 로컬 실습 서버의 예시
curl http://127.0.0.1:8080/v1/models \
  -H "Authorization: Bearer $LOCALAI_STUDY_KEY"

curl -N http://127.0.0.1:8080/v1/chat/completions \
  -H "Authorization: Bearer $LOCALAI_STUDY_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "study-chat",
    "messages": [{"role":"user","content":"동시성을 한 문장으로 설명해 줘."}],
    "stream": true,
    "max_tokens": 80
  }'

입력: "안녕하세요"를 UTF-8 바이트로 변환
전송: 1바이트, 2바이트, 1바이트, 나머지 순서로 조각 전송
수신: 미완성 바이트는 다음 조각까지 보관
출력: 원래 문자열과 같은지 비교
취소: 둘째 조각 뒤 중단 신호를 보내 생산자 종료 확인

실습 결과물은 실행 성공 화면보다 입력·예상·관측·실패 조건을 함께 남긴 기록이어야 합니다. 이 네 가지가 있으면 모델이나 장치를 바꿔도 배운 설계 지식을 재사용할 수 있습니다.

9관련 기술 심화 학습 로드맵

주차는 진도의 예시입니다. HTTP·JSON·기본 함수 호출을 알고 있다는 전제이며, 낯선 개념이 있으면 해당 주차를 더 길게 잡아도 됩니다. 매주 읽을 범위를 제한하고 설명 가능한 결과물을 하나씩 만드세요.

학습 범위를 넓힐 때도 core/http/endpoints/openai/chat.go의 호출부터 따라가세요. HTTP 처리는 core/http/endpoints/openai/, 화면은 core/http/react-ui/src/, 인증은 core/http/auth/, 라이브러리 변환은 core/gallery/에 모여 있습니다.

9-1. 6주 뒤 고를 수 있는 심화 갈래

• 추론 엔진: backend/cpp/llama-cpp/grpc-server.cpp에서 llama.cpp 호출을 따라가고 토크나이저·양자화·KV 캐시를 공부합니다.
• 분산 시스템: core/services/nodes/와 core/application/distributed.go를 읽고 노드 선택·복제본·장애·공유 상태를 공부합니다. 다중 모델 분산과 한 모델의 분할 실행을 구분하세요.
• 도구와 에이전트: core/http/endpoints/mcp/, pkg/mcp/, core/services/agentpool/을 읽고 도구 발견·권한·실행 반복의 경계를 공부합니다.
• 배포 재현성: core/gallery/backend_library.go와 CI를 읽고 가변 태그·다이제스트·서명 정책·형식 변환 검증을 공부합니다.

학습 범위는 기능 개수보다 설명할 수 있는 실패 상황의 수로 넓혀 가는 것이 좋습니다. 성공 경로를 읽은 뒤에는 같은 모델의 동시 요청, 잘못된 설정, 끊긴 스트림, 오래된 배포 파일을 차례로 추가해 보세요.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소 · 문서

• LocalAI 공식 저장소 · 공식 문서 · v4.12.0 릴리스
• 아키텍처 설명 · 빠른 시작 · 컨테이너 안내
• 인증·권한 안내 · 클라우드 프록시 안내
• 분석 기준 README · 분석 기준 커밋

11-2. 핵심 소스와 의존성

• Go 의존성 · UI 의존성 선언 · UI 잠금 파일
• 채팅 핸들러 · 예측 실행 연결 · 공통 RPC 계약
• 모델 설정과 기본값 적용 · 문맥 기본값 · 하드웨어 기본값
• llama.cpp 연결 구현 · vLLM 연결 구현 · 백엔드 라이브러리 변환
• 서버 Dockerfile · 빌드·검사 명령 · 핵심 테스트 CI · 목록 호환성 검사 CI

11-3. 관련 기술 공식 자료

• Go 기초 · Go 파이프라인과 취소 · Echo 문서
• gRPC 핵심 개념 · Protocol Buffers 언어 안내
• React 지연 로딩 · Vite 안내 · Playwright 안내
• llama.cpp · vLLM 호환 서버 · Ollama 호환 API
• MCP 소개 · Docker 다단계 빌드 · NATS 문서

현재 상태 (2026-10-23 확인)

11-4. 코드 규모를 숫자 그대로 해석하지 않기

다음은 커밋 f1ff707의 Git 추적 일반 파일을 확장자로 분류한 물리적 줄 수입니다. 주석·빈 줄·테스트·추적된 자료를 포함하며, 심볼릭 링크·서브모듈과 별도로 다운로드하는 모델 가중치·외부 엔진 전체 소스는 제외합니다. 추적된 일반 파일은 총 5,580개입니다.

Go 중 _test.go는 1,408개·495,882줄입니다. 특히 tests/e2e-aio/sample_data_test.go 하나가 240,009줄이라 총량을 크게 부풀립니다. 테스트와 swagger/docs.go의 15,246줄을 제외하면 참고값은 288,056줄입니다. 이 값도 엄밀한 실행 코드 줄 수는 아닙니다.

React UI 경로만의 JavaScript/JSX 파일은 616개·108,628줄입니다. Python의 *_pb2.py·*_pb2_grpc.py 생성본은 Git 추적 파일에 없으며, 백엔드 준비 과정에서 생성됩니다. YAML의 큰 비중은 모델·백엔드 목록과 설정 자료의 규모를 보여 줍니다. 파일 확장자로 센 양과 직접 작성한 프로그램 로직의 양을 구분하세요.