Part 1. 로컬 AI 코딩의 기본 구조

1장. 로컬 AI는 어떻게 동작하는가

1.1 로컬 LLM, SLM, 코딩 모델의 차이

로컬 AI 코딩을 시작할 때 가장 먼저 만나는 단어가 LLM입니다. LLM은 Large Language Model, 즉 대형 언어 모델입니다. 대량의 텍스트와 코드 데이터를 학습해 다음 토큰을 예측하는 모델이라고 이해하면 됩니다. 여기서 토큰은 단어와 글자 사이의 작은 단위입니다. 모델은 사용자의 문장을 보고 다음에 올 가능성이 높은 토큰을 계속 생성합니다. 우리가 보기에는 답변을 쓰는 것처럼 보이지만, 내부적으로는 확률적으로 다음 토큰을 고르는 과정이 반복됩니다.

SLM은 Small Language Model, 즉 소형 언어 모델을 가리킬 때 자주 쓰는 표현입니다. 정확한 경계가 정해져 있는 것은 아니지만, 보통 대형 클라우드 모델보다 훨씬 작은 파라미터 수를 가진 모델을 말합니다. 로컬 코딩 환경에서는 SLM이 매우 중요합니다. 내 노트북이나 데스크톱에서 쾌적하게 실행하려면 모델이 너무 커서는 안 됩니다. 작은 모델은 빠르고 가볍지만, 복잡한 추론이나 긴 컨텍스트 이해에서는 한계가 있을 수 있습니다.

코딩 모델은 일반 대화 모델과 목적이 다릅니다. 일반 모델은 설명, 요약, 번역, 글쓰기 등 넓은 작업을 잘하도록 학습됩니다. 코딩 모델은 코드 생성, 버그 수정, 함수 설명, 테스트 작성, fill-in-the-middle 자동완성 같은 작업에 더 맞춰져 있습니다. 코딩 모델이라고 해서 항상 일반 모델보다 좋은 것은 아닙니다. 하지만 개발 작업에서는 코드 문법, 라이브러리 사용 패턴, 에러 메시지, 테스트 구조를 더 잘 다루는 모델이 유리합니다.

로컬 코딩 모델을 고를 때는 “한국어로 친절하게 설명을 잘하는가”와 “코드를 정확하게 만드는가”를 구분해야 합니다. 어떤 모델은 한국어 설명이 부드러워 보여도 실제 코드 품질은 낮을 수 있습니다. 반대로 어떤 모델은 한국어 답변은 딱딱하지만 코드 생성은 안정적일 수 있습니다. 개발 도구로 쓸 모델은 말투보다 결과 코드가 중요합니다. 설명이 조금 투박해도 테스트를 통과하는 코드를 잘 만들면 실무에서는 가치가 있습니다.

[표 1-1] LLM, SLM, 코딩 모델 비교.

1.2 내 컴퓨터에서 모델이 실행된다는 것의 의미

클라우드 AI를 사용할 때 모델은 외부 서버에서 실행됩니다. 사용자의 IDE나 브라우저는 프롬프트를 서버로 보내고, 서버는 모델을 실행한 뒤 응답을 돌려줍니다. 사용자는 서버의 GPU, 메모리, 배포 구조를 신경 쓰지 않아도 됩니다. 대신 네트워크, 계정, 요금제, 서비스 정책에 의존합니다.

로컬 AI에서는 모델 파일이 내 컴퓨터에 저장되고, 추론도 내 컴퓨터에서 일어납니다. 모델 파일은 몇 GB에서 수십 GB까지 커질 수 있습니다. 모델을 실행하면 RAM이나 VRAM에 모델 가중치가 올라갑니다. 사용자가 질문하면 내 컴퓨터의 CPU와 GPU가 계산을 수행하고 답변을 생성합니다. 그래서 로컬 AI 성능은 모델의 똑똑함뿐 아니라 내 장비의 자원과 직접 연결됩니다.

이 구조가 주는 가장 큰 변화는 제어권입니다. 어떤 모델을 쓸지, 어떤 버전을 쓸지, 어느 정도 컨텍스트를 열지, GPU에 얼마나 올릴지를 사용자가 직접 조정할 수 있습니다. 또한 외부 API 호출 없이도 모델을 실행할 수 있습니다. LM Studio 공식 문서에서도 모델 파일을 미리 받아 두면 오프라인으로 동작할 수 있다고 안내합니다. 출판 시점에 따라 세부 메뉴는 달라질 수 있지만, 로컬 실행의 핵심은 “모델 추론 위치가 내 장비”라는 점입니다.

반대로 사용자가 책임져야 하는 것도 늘어납니다. 모델이 느리면 원인을 찾아야 합니다. VRAM이 부족하면 더 작은 모델이나 더 낮은 양자화를 골라야 합니다. 모델 ID가 맞지 않으면 IDE 연결이 실패합니다. 서버 포트가 충돌하면 API 호출이 되지 않습니다. 클라우드에서는 보이지 않던 실행 환경의 문제가 로컬에서는 사용자 앞에 나타납니다.

그래서 로컬 AI를 시작할 때는 설치법보다 구조를 먼저 이해하는 것이 좋습니다. 모델 파일, 런타임, 로컬 서버, IDE 확장이 어떤 순서로 연결되는지 알면 오류 메시지를 봐도 덜 당황합니다.

[이미지 제안 1-1] 로컬 모델 실행 흐름. “모델 파일 다운로드 → 런타임이 모델 로드 → 로컬 서버 실행 → IDE 확장이 API 호출 → 모델 응답 반환” 순서로 그립니다.

1.3 GPU, VRAM, RAM, CPU가 하는 역할

로컬 AI에서 가장 많이 듣는 하드웨어 용어는 GPU와 VRAM입니다. GPU는 대규모 행렬 계산에 강한 장치입니다. 내 PC 또는 맥안에 AI 전용으로 작은 컴퓨터 한 대가 추가 됐다고 생각하시면 됩니다. 언어 모델 추론은 많은 행렬 연산을 반복하므로 GPU를 잘 활용하면 속도가 크게 좋아집니다. VRAM은 GPU 전용 메모리입니다. 모델의 가중치와 추론 중 필요한 데이터가 VRAM에 올라갈수록 빠르게 계산할 수 있습니다.

RAM(램, Random Access Memory)은 시스템 메모리입니다. 모델 전체가 VRAM에 들어가지 않으면 일부가 RAM에 머물 수 있습니다. 이 경우 실행은 가능하지만, GPU와 RAM 사이 또는 CPU 연산이 섞이면서 속도가 떨어질 수 있습니다. Apple Silicon Mac은 구조가 조금 다릅니다. CPU와 GPU가 통합 메모리를 공유하므로 NVIDIA GPU의 전용 VRAM 구조와 다르게 생각해야 합니다. 그래도 핵심은 같습니다. 모델과 컨텍스트를 담을 메모리가 충분해야 하고, 계산 장치가 빠를수록 응답이 빨라집니다.

CPU는 모든 컴퓨터에 있는 중앙 처리 장치입니다. CPU만으로도 로컬 모델을 실행할 수는 있습니다. 작은 모델이나 짧은 테스트에는 괜찮을 수 있습니다. 그러나 코딩 작업에서 매번 수십 초 이상 기다려야 한다면 작업 흐름이 끊깁니다. 자동완성처럼 즉시성이 중요한 기능은 특히 GPU 가속의 영향을 많이 받습니다.

초보자가 흔히 하는 실수는 “모델 파일 크기가 내 디스크에 들어가면 실행될 것”이라고 생각하는 것입니다. 디스크에 저장되는 것과 메모리에 올라가는 것은 다릅니다. 8GB짜리 모델 파일이 있다고 해서 8GB RAM 장비에서 항상 여유롭게 실행되는 것은 아닙니다. 모델 가중치 외에도 컨텍스트, KV 캐시, 런타임, 운영체제, IDE, 브라우저가 메모리를 씁니다.

[표 1-2] 하드웨어 요소별 역할.

1.4 토큰, 컨텍스트 윈도우, 프롬프트, 응답의 구조

로컬 코딩 모델을 잘 쓰려면 토큰과 컨텍스트 윈도우를 이해해야 합니다. 토큰은 모델이 읽고 쓰는 기본 단위입니다. 영어는 단어 조각 단위로 잘 나뉘고, 한국어는 형태나 글자 단위로 더 잘게 나뉘는 경우가 많습니다. 코드는 기호와 단어가 섞여 있어 토큰 수가 빠르게 늘어날 수 있습니다.

컨텍스트 윈도우는 모델이 한 번에 볼 수 있는 토큰의 최대 범위입니다. 사용자의 질문, 시스템 지시문, 선택한 코드, 현재 파일 내용, 이전 대화, 모델이 생성할 응답까지 모두 이 범위 안에 들어갑니다. 컨텍스트 윈도우가 8,192토큰이라고 하면, 입력과 출력의 총량이 그 범위를 넘지 않도록 관리해야 합니다.

코딩에서 컨텍스트가 중요한 이유는 코드가 주변 맥락에 의존하기 때문입니다. 함수 하나만 보면 맞아 보이는 코드도, 실제 프로젝트의 타입 정의, 환경 변수, 라우팅 규칙, 에러 처리 정책과 맞지 않을 수 있습니다. 모델에게 현재 파일만 줄지, 관련 타입 파일까지 줄지, README와 API 문서를 같이 줄지에 따라 답변 품질이 달라집니다.

하지만 컨텍스트를 무조건 많이 넣는 것이 답은 아닙니다. 로컬 모델은 큰 컨텍스트를 처리할수록 메모리를 더 많이 쓰고 느려질 수 있습니다. 또한 불필요한 파일을 많이 넣으면 모델이 중요한 부분을 놓칠 수 있습니다. 좋은 컨텍스트 설계란 “많이 넣기”가 아니라 “작업에 필요한 것을 정확히 넣기”입니다.

프롬프트는 모델에게 주는 요청입니다. 응답은 모델이 생성하는 결과입니다. 코딩 작업에서는 프롬프트 안에 역할, 목표, 입력 코드, 제약 조건, 출력 형식을 넣으면 품질이 좋아집니다. 예를 들어 “이 코드 고쳐 줘”보다 “아래 TypeScript 함수에서 null 처리 버그를 찾고, 기존 함수 시그니처는 유지한 채 수정안을 제시해 주세요. 변경 이유를 3줄 이내로 설명해 주세요”가 훨씬 낫습니다.

1.5 로컬 모델 실행 방식: 앱, 서버, CLI, IDE 플러그인

로컬 모델을 실행하는 방식은 크게 네 가지로 나눌 수 있습니다. 첫째는 앱 방식입니다. LM Studio처럼 데스크톱 앱을 설치하고, 모델을 검색해 다운로드하고, 채팅 UI에서 바로 실행하는 방식입니다. 초보자에게 가장 접근성이 좋습니다. 모델 다운로드, 실행, 설정을 그래픽 화면에서 처리할 수 있기 때문입니다.

둘째는 서버 방식입니다. 모델을 로컬 서버로 띄우고, 다른 도구가 HTTP API로 호출하는 구조입니다. 이 책에서 LM Studio와 Continue를 연결할 때 핵심이 되는 방식입니다. LM Studio는 로컬 서버를 열고, Continue는 그 서버의 API 주소로 요청을 보냅니다. 주소가 http://localhost:1234/v1처럼 보이면, 내 컴퓨터 안의 1234번 포트에서 OpenAI 호환 API를 제공한다는 뜻입니다.

셋째는 CLI 방식입니다. 터미널에서 명령어로 모델을 실행하거나, 코딩 에이전트를 호출하는 방식입니다. CLI는 처음에는 낯설지만 자동화에 강합니다. 프로젝트 폴더에서 명령을 실행하고, 파일을 읽고 쓰는 에이전트와 결합하기 좋습니다. 이 책의 Part 6에서 다루는 터미널 기반 에이전트는 이 방식과 가깝습니다.

넷째는 IDE 플러그인 방식입니다. VS Code, JetBrains 같은 개발 환경에 확장을 설치하고, 채팅, 자동완성, 코드 편집 기능을 쓰는 방식입니다. Continue는 대표적인 예입니다. IDE 플러그인은 개발자가 이미 머무는 공간에 AI 기능을 붙여 주기 때문에 실무 체감이 좋습니다.

중요한 것은 이 네 가지가 서로 배타적이지 않다는 점입니다. 실제 워크플로에서는 앱으로 모델을 테스트하고, 서버로 IDE와 연결하고, CLI로 자동화 작업을 하고, IDE 플러그인으로 매일 코딩할 수 있습니다. 로컬 AI 코딩 환경은 하나의 프로그램이 아니라 여러 요소를 연결한 작업 흐름입니다.

[이미지 1-2] 로컬 모델 실행 방식 4분류.

1.6 로컬 AI 코딩 툴의 전체 아키텍처

로컬 AI 코딩 툴의 전체 구조는 생각보다 단순합니다. 가장 아래에는 하드웨어가 있습니다. CPU, GPU, RAM, VRAM, SSD입니다. 그 위에 모델 파일이 있습니다. 모델 파일은 GGUF, MLX, safetensors 같은 형식일 수 있습니다. 그 위에 런타임이 있습니다. 런타임은 모델 파일을 읽고 실제 추론을 수행합니다. LM Studio는 내부적으로 이런 런타임을 사용해 모델을 실행합니다.

그다음에는 로컬 서버가 있습니다. 로컬 서버는 IDE나 스크립트가 모델에 요청을 보낼 수 있는 통로입니다. OpenAI 호환 API를 제공하면 기존 OpenAI 클라이언트나 도구가 base URL만 바꿔서 로컬 모델을 호출할 수 있습니다. 마지막으로 개발자와 가장 가까운 층에는 IDE 확장과 에이전트가 있습니다. Continue 같은 확장은 현재 파일, 선택한 코드, 터미널 출력, 프로젝트 구조를 컨텍스트로 모아 모델에 전달합니다.

이 구조를 한 문장으로 정리하면 이렇습니다. “IDE가 컨텍스트를 모으고, 로컬 서버에 요청하고, 로컬 런타임이 모델을 실행하고, 응답이 다시 IDE로 돌아온다.” 이 문장만 기억해도 많은 설정 문제가 이해됩니다. 연결이 안 되면 서버 주소를 봐야 합니다. 답변이 엉뚱하면 컨텍스트를 봐야 합니다. 너무 느리면 모델 크기와 하드웨어 사용량을 봐야 합니다.

[이미지 1-3] 로컬 AI 코딩 아키텍처 계층도.

1.7 클라우드 모델과 로컬 모델의 결정적 차이

하드웨어 관점에서 보면 클라우드 모델과 로컬 모델의 차이는 실행 위치입니다. 클라우드 모델은 외부 서버에서 실행되고, 로컬 모델은 내 컴퓨터에서 실행됩니다. 이 차이가 비용, 보안, 속도, 품질, 운영 방식의 차이를 만듭니다.

클라우드 모델은 대개 더 큰 모델과 더 강한 인프라를 사용할 수 있습니다. 사용자는 하드웨어를 구매하지 않아도 되고, 최신 모델에 빠르게 접근할 수 있습니다. 대신 요청량에 따른 비용, 데이터 전송, 서비스 의존성이 생깁니다. 로컬 모델은 사용자의 장비에 묶이지만, 반복 작업을 저비용으로 처리하고, 민감한 코드를 외부로 보내지 않는 구성을 만들 수 있습니다.

실무에서 중요한 결론은 둘 중 하나만 선택할 필요가 없다는 것입니다. 로컬 모델은 빠르고 사적인 기본 도구로 두고, 클라우드 모델은 어려운 문제를 해결하는 고성능 도구로 두면 됩니다. 개발자는 작업마다 어떤 도구가 맞는지 판단하면 됩니다. 자동완성, 간단한 설명, 작은 리팩터링은 로컬 우선. 복잡한 설계, 긴 문서 기반 분석, 여러 시스템이 얽힌 디버깅은 클라우드 우선. 이 정도 기준으로 시작하면 충분합니다.

[표 1-3] 클라우드 모델과 로컬 모델 비교.

---