AI 코딩 도구를 쓰다 보면 비용, 크레딧, 인터넷 연결, 코드 외부 전송 문제가 한 번씩 걸린다. 이럴 때 LM Studio로 로컬 LLM을 띄우고 VS Code에 연결하면 작은 수정, 코드 설명, 자동완성, 간단한 파일 생성은 내 컴퓨터 안에서 처리할 수 있다.
핵심은 설치 버튼이 아니라 모델 선택이다. 로컬 AI 코딩은 "가장 큰 모델을 받으면 끝"이 아니다. 내 GPU VRAM이나 Mac 통합 메모리에 모델이 안정적으로 올라가야 하고, 채팅용 모델과 자동완성용 모델도 다르게 잡아야 한다.

로컬 AI 코딩은 어디까지 기대해야 할까
로컬 모델을 쓰면 API 호출 비용 없이 내 컴퓨터에서 모델을 실행한다. 모델과 도구가 이미 준비되어 있다면 인터넷이 끊겨도 VS Code 안에서 코드 설명, 짧은 수정, 간단한 생성 작업을 이어갈 수 있다. 로컬 LLM 실행 방식 자체가 아직 낯설다면 먼저 2026년 기준 LLM 로컬 실행 방법 정리를 보면 Ollama, Docker Model Runner, 로컬 실행 환경의 큰 그림을 잡기 쉽다.
대신 클라우드 상위 모델과 같은 수준을 기대하면 바로 실망한다. 큰 레거시 프로젝트 전체를 이해시키거나 복잡한 구조 변경을 한 번에 맡기는 일은 아직 어렵다. 로컬 모델은 "비용 없이 무제한으로 쓰는 만능 코더"보다 "작은 작업을 빠르게 반복하는 보조 엔진"에 가깝다.
잘 맞는 작업은 이쪽이다.
- 짧은 함수 작성과 리팩터링
- 이미 맥락을 아는 파일의 일부 수정
- 작은 HTML/CSS/JavaScript 예제 생성
- 오프라인 상태에서 코드 설명 받기
- 크레딧을 아끼고 싶은 반복 수정
잘 안 맞는 작업도 분명하다. "이 프로젝트 전체를 분석해서 아키텍처를 바꿔줘" 같은 요청은 실패 원인도 좁히기 어렵다. 처음에는 작은 파일 하나, 작은 함수 하나부터 성공시키는 게 맞다.
모델 선택은 VRAM부터 본다
Windows PC나 NVIDIA GPU가 있는 데스크톱이라면 그래픽카드의 VRAM을 확인한다. 8GB, 12GB, 16GB, 24GB 같은 숫자가 로컬 모델의 현실적인 상한선을 만든다.
Apple Silicon Mac은 GPU 전용 VRAM이 아니라 통합 메모리를 본다. M 시리즈 Mac의 통합 메모리는 CPU와 GPU가 함께 쓰기 때문에, 64GB라고 해서 64GB 전부를 모델에 줄 수 없다. macOS, 브라우저, IDE, Docker, 화면 녹화 앱이 이미 일부를 가져간다.
출발점은 이렇게 잡으면 된다. 정확한 한계가 아니라 "처음 실패를 줄이는 기준"이다.
| 내 장비의 여유 메모리 | 먼저 시도할 크기 | 판단 기준 |
|---|---|---|
| 8GB VRAM 또는 16GB 통합 메모리 | 7B급 Q4 | 큰 모델보다 안정성이 먼저 |
| 12 |
14B급, 일부 30B-A3B Q4 | context length를 욕심내지 말 것 |
| 24GB VRAM 또는 48~64GB 통합 메모리 | 30B/32B급 Q4 | 로컬 코딩 모델을 본격적으로 체감 |
| 64GB 이상 통합 메모리 | 더 큰 양자화 모델 실험 | 들어가도 느리면 한 단계 낮추기 |
여기서 자주 하는 실수가 있다. 모델 파일이 디스크에 다운로드됐다고 실행도 잘 되는 것은 아니다. 모델 본체, context length, KV cache, 백그라운드 앱이 합쳐져 메모리를 먹는다. 한계를 넘으면 일부가 시스템 메모리나 디스크 쪽으로 밀리면서 응답이 크게 느려질 수 있다.
그래서 처음에는 Q4 같은 양자화 모델로 시작하는 편이 낫다. Q6가 더 좋아 보일 수 있지만, 로컬 코딩에서는 "조금 더 똑똑한데 답이 늦는 모델"보다 "충분히 쓸 만하고 빠른 모델"이 실제 작업에 더 맞는 경우가 많다.
채팅 모델과 자동완성 모델은 분리한다
VS Code에서 로컬 AI를 쓸 때 모델 하나로 모든 역할을 맡기면 체감이 어정쩡해진다. 채팅/편집/에이전트용 모델과 자동완성용 모델은 성격이 다르다. AI 코드 에이전트의 기본 흐름이 먼저 필요하다면 AI 코드 에이전트 가이드를 같이 참고해도 좋다.
자동완성 모델은 작고 빨라야 한다. 커서 앞뒤 코드를 보고 중간을 채우는 FIM(fill-in-the-middle) 성격의 작업이라, Qwen2.5-Coder 1.5B나 7B 같은 작은 coder 모델이 더 실용적일 수 있다. 타이핑 중에 2~3초씩 멈추는 자동완성은 사실상 자동완성이 아니다.
반대로 채팅, 파일 수정, 에이전트 모드에 쓸 모델은 조금 더 커도 된다. 대신 반드시 봐야 할 조건이 있다. tool use 또는 tool calling을 지원해야 한다. 이 기능이 약하면 모델은 코드 수정 방법을 설명할 수는 있어도, 파일 생성과 수정 흐름에서는 기대만큼 움직이지 못한다.
모델 검색 화면에서 이름이 비슷하게 보일 때는 아래를 같이 확인한다.
- 정확한 모델명: 예를 들어
Qwen2.5-Coder,Qwen3-Coder-30B-A3B - 양자화 수준: Q4, Q5, Q6 등
- 예상 메모리 사용량
- tool calling 지원 여부
- context length를 키웠을 때 추가로 드는 메모리
특히 A3B처럼 표시되는 모델은 전체 파라미터와 실제 활성 파라미터가 다를 수 있다. 예를 들어 Qwen3-Coder-30B-A3B-Instruct는 전체 파라미터와 활성 파라미터를 나눠 설명한다. 이런 구조는 효율에는 도움이 되지만, 파일 크기와 실행 메모리를 무시해도 된다는 뜻은 아니다.

LM Studio에서는 모델을 "받고, 로드하고, 서버를 켜야" 한다
LM Studio를 설치한 뒤 모델 검색 화면에서 원하는 모델을 다운로드한다. 여기까지는 쉽다. 막히는 지점은 그 다음이다. VS Code가 모델을 쓰려면 LM Studio 안에서 로컬 서버가 켜져 있어야 하고, 실제 사용할 모델도 로드되어 있어야 한다.
먼저 LM Studio의 chat 화면에서 모델 하나를 골라 단순 프롬프트를 던져 본다. 응답이 나오면 기본 실행은 성공이다. 이때 GPU offload는 가능한 높게 두고, context length는 내 메모리 안에서 무리하지 않는 값으로 잡는다.
그 다음 Developer 화면에서 server를 켠다. LM Studio의 OpenAI 호환 엔드포인트를 쓰면 VS Code나 다른 도구가 아래 같은 local base URL로 모델을 호출할 수 있다.
http://localhost:1234/v1
여기서 중요한 체크는 두 가지다.
- 채팅/에이전트용 모델이 load 상태인가
- 자동완성용 모델도 따로 쓸 계획이라면 같이 load했는가
서버는 켰는데 모델을 로드하지 않으면 VS Code 쪽 설정이 맞아도 요청이 제대로 처리되지 않는다. 반대로 모델은 로드했는데 서버를 꺼 둔 상태면 VS Code는 호출할 곳이 없다.
VS Code에는 Custom Endpoint로 연결한다
VS Code의 AI language models 문서를 보면 Language Models 설정에서 모델을 관리하고, Bring Your Own Key 방식으로 공급자를 붙이는 흐름을 확인할 수 있다. 로컬 LM Studio도 같은 관점에서 custom endpoint로 연결한다고 보면 된다.
설정할 때 핵심 값은 많지 않다.
| 항목 | 넣을 값 |
|---|---|
| API 방식 | Chat Completions |
| API key | 로컬 연결에서는 더미 문자열로 충분한 경우가 많음 |
| URL | LM Studio의 local endpoint |
| model id | LM Studio에서 복사한 정확한 모델 id |
| capabilities | 모델이 실제 지원하는 기능만 선택 |
여기서 욕심내면 꼬인다. vision을 지원하지 않는 모델에 vision을 켜거나, tool calling이 약한 모델을 에이전트용으로 고르면 VS Code 화면에는 모델이 떠도 실제 작업 품질이 떨어진다.
설정을 저장한 뒤 VS Code Chat에서 모델 목록을 열어 방금 추가한 로컬 모델을 선택한다. 첫 테스트는 작게 해야 한다.
나쁜 첫 테스트:
React로 체스 게임을 완성해줘.
좋은 첫 테스트:
현재 폴더에 index.html 하나를 만들고, 버튼을 누르면 숫자가 1씩 증가하는 예제를 만들어줘.
큰 과제를 바로 던지면 실패했을 때 원인이 모델 성능인지, tool calling인지, 파일 권한인지, 프롬프트 문제인지 구분하기 어렵다. 작은 파일 생성이 성공하면 그 다음에 수정, 리팩터링, 테스트 추가로 넓혀 가는 편이 낫다.
자동완성은 Continue로 따로 잡는 편이 덜 헷갈린다
VS Code의 로컬 모델 연결은 채팅과 에이전트 흐름에는 유용하다. 하지만 인라인 자동완성까지 같은 흐름으로 깔끔하게 맞추려면 버전과 설정에 따라 헷갈릴 수 있다. 이럴 때 Continue 확장을 쓰면 자동완성 모델을 별도로 지정하기 쉽다.
Continue의 autocomplete role 문서는 자동완성 모델을 일반 채팅 모델과 다르게 다룬다. roles에 autocomplete를 지정하고, Qwen2.5-Coder 같은 작은 coder 모델을 후보로 보는 이유도 여기에 있다.
구성은 이런 방향으로 생각하면 된다.
models:
- name: Qwen2.5 Coder Autocomplete
provider: lmstudio
model: 실제-LM-Studio-모델-ID
apiBase: http://localhost:1234/v1
roles:
- autocomplete
여기서 model 값은 예시 이름을 그대로 넣는 게 아니다. LM Studio에서 현재 로드한 모델 id를 복사해야 한다. 설정을 저장했는데 자동완성이 안 뜨면 VS Code를 재시작하고, LM Studio Developer logs에 요청이 들어오는지 확인한다.
안 될 때는 이 순서로 좁힌다
로컬 AI 코딩 설정은 한 번에 되는 것처럼 보여도 작은 어긋남이 자주 난다. 감으로 만지기보다 증상별로 좁혀야 한다.
| 증상 | 먼저 볼 것 |
|---|---|
| VS Code 모델 목록에 안 보임 | 설정 저장 여부, VS Code 재시작, 모델 id |
| 요청은 가는데 답이 없음 | LM Studio server 실행 여부, 모델 load 상태 |
| 응답이 지나치게 느림 | 모델 크기, context length, 메모리 스왑 |
| 에이전트가 파일을 못 고침 | tool calling 지원 여부 |
| 자동완성이 안 뜸 | Continue roles: autocomplete, 모델 id, 재시작 |
| 결과가 엉뚱함 | 첫 작업이 너무 큰지, 파일 범위가 넓은지 |
특히 Mac에서는 통합 메모리 압박을 자주 봐야 한다. 브라우저 탭, Docker, 화면 녹화, IDE가 동시에 떠 있으면 모델은 로드되는데 첫 응답이 늦거나 중간중간 멈출 수 있다. 이때는 context length를 더 키우는 게 아니라 모델을 한 단계 낮추는 쪽이 빠르다.
실제 프로젝트에서는 요청을 작게 쪼갠다
로컬 모델을 제대로 쓰려면 프롬프트도 로컬 모델에 맞춰야 한다. 클라우드 상위 모델에 던지던 큰 요청을 그대로 던지면 실패 확률이 올라간다.
나쁜 요청:
이 프로젝트 전체 구조를 개선하고 성능 문제도 고쳐줘.
좋은 요청:
src/utils/date.ts만 보고 중복 분기를 줄여줘. 기존 함수명은 바꾸지 말고, 변경 후 diff를 설명해줘.
로컬 모델에는 범위를 좁혀 주는 것이 가장 중요하다. 파일을 태그하고, 바꿀 조건을 정하고, 한 번에 하나의 변경만 맡긴다. 그리고 결과는 반드시 diff로 확인한다. 로컬에서 돌린다고 해서 모델의 변경이 자동으로 맞는 것은 아니다.
FAQ
로컬 모델이면 코드가 완전히 안전한가?
외부 API로 코드를 보내지 않는다는 장점은 있다. 다만 모델 파일, 확장 프로그램, 로컬 서버 노출 설정은 별개다. LM Studio 서버는 필요한 범위에서만 열어 둔다.
8GB VRAM에서도 쓸 만한가?
작은 작업은 가능하다. 7B급 이하, Q4 양자화, 짧은 context length부터 시작하는 편이 현실적이다. 느리면 설정을 더 복잡하게 만지기보다 모델을 낮추는 게 빠르다.
마무리
LM Studio와 VS Code를 연결하면 로컬 모델로도 AI 코딩 환경을 만들 수 있다. 다만 성공 기준은 "가장 큰 모델 실행"이 아니라 "내 장비에서 안정적으로 반복 사용"이다.
처음에는 자동완성용 작은 모델 하나, 채팅/에이전트용 tool calling 모델 하나로 나누자. LM Studio에서 서버와 모델 load 상태를 확인하고, VS Code에서는 아주 작은 파일 생성부터 테스트한다. 이 순서만 지켜도 로컬 AI 코딩은 실험용 장난감이 아니라 실제 작업에 붙여 볼 만한 보조 도구가 된다.
'SW > 인공지능' 카테고리의 다른 글
| AI 개발을 멈춰야 할까? 개발자가 봐야 할 4가지 신호 (0) | 2026.07.25 |
|---|---|
| 하네스 엔지니어링이란? AI 에이전트를 덜 망가뜨리는 실전 방법 (0) | 2026.07.24 |
| AI 코딩 에이전트로 앱 만들기: 데모를 제품으로 바꾸는 판단 기준 (0) | 2026.07.19 |
| AI Agent는 왜 프로덕션에서 자꾸 깨질까: Temporal Durable Execution 실전 기준 (0) | 2026.07.18 |
| Hermes Agent 초보 가이드: 24시간 AI 비서를 안전하게 시작하는 법 (0) | 2026.07.16 |