Skip to main content

프롤로그. 왜 지금 로컬 코딩 툴인가

AI 코딩 도구는 이미 개발자의 일상으로 들어왔습니다. 예전에는 검색창(구글, 스택오버플로우 등)에 에러 메시지를 붙여 넣고, 검색결과, 문서 사이를 오가며 답을 찾았습니다. 지금은 IDE 안에서 여러 코딩 에이전트에게 바로 질문하고, 함수 이름을 쓰면 다음 코드를 제안받고, 테스트 코드까지 한 번에 만들어 달라고 요청합니다. 개발자는 더 이상 혼자 타이핑만 하는 사람이 아니라, AI와 함께 문제를 쪼개고, 검토하고, 결정하는 사람에 가까워졌습니다.

그런데 이 변화에는 아직 풀리지 않은 불편함이 있습니다. 좋은 AI 코딩 도구일수록 대개 클라우드에 연결되어 있습니다. 빠르고 똑똑하지만, 매달 비용이 나갑니다. 회사 코드나 고객 데이터가 외부 서버로 넘어가는지 보안도 걱정해야 합니다. 인터넷이 느리거나 끊기면 작업 흐름도 끊깁니다. 무엇보다 “내가 매일 쓰는 작은 개발 루틴까지 꼭 외부 모델에 맡겨야 하나”라는 질문이 남습니다.

이 책은 그 질문에서 시작합니다. 클라우드 AI를 쓰지 말자는 이야기가 아닙니다. 오히려 클라우드 모델은 여전히 강력합니다. 복잡한 아키텍처 설계, 긴 문서 분석, 어려운 추론이 필요한 문제에서는 고성능 클라우드 모델이 훨씬 안정적일 때가 많습니다. 다만 모든 작업이 클라우드 모델까지 갈 필요는 없습니다. 간단한 코드 설명, 함수 단위 리팩터링, 테스트 초안 작성, 주석 정리, 반복적인 스크립트 작성은 로컬 모델로도 충분히 처리할 수 있는 경우가 많습니다.

로컬 코딩 툴의 핵심은 “내 컴퓨터 안에서 돌아가는 AI 개발 보조자”를 만드는 것입니다. 모델은 내 장비에서 실행됩니다. IDE는 로컬 서버와 연결됩니다. 코드와 프롬프트는 기본적으로 내 컴퓨터 안에서 오갑니다. 이 구조를 이해하면 비용을 줄일 수 있고, 민감한 코드를 더 안전하게 다룰 수 있으며, 인터넷 연결 상태와 별개로 일정 수준의 AI 도움을 받을 수 있습니다.

물론 로컬 AI에는 한계도 있습니다. 내 컴퓨터의 RAM, VRAM, CPU, GPU 성능에 따라 사용할 수 있는 모델이 달라집니다. 작은 모델은 빠르지만 깊은 추론이 약할 수 있습니다. 큰 모델은 더 똑똑할 수 있지만 느리거나 아예 실행되지 않을 수 있습니다. 로컬 모델은 클라우드 대형 모델처럼 모든 문제를 한 번에 해결해 주지 않습니다. 그래서 이 책은 로컬 AI를 과장하지 않습니다. 대신 실제로 쓸 수 있는 수준에서, 어디까지 맡기고 어디서 사람이 판단해야 하는지를 차분하게 이야기합니다.

이 책에서 다루는 중심 흐름은 단순합니다. 먼저 로컬 AI 코딩의 구조를 이해합니다. 다음으로 내 장비에 맞는 모델을 고릅니다. 그다음 LM Studio로 모델을 실행하고 로컬 서버를 엽니다. 마지막으로 VS Code와 Continue를 연결해 코드 질문, 자동완성, 리팩터링, 프로젝트 컨텍스트 전달까지 실습합니다. Part 4까지 읽고 나면, 독자는 최소한 “내 컴퓨터에서 돌아가는 AI 코딩 어시스턴트”를 직접 구성하고, 실무 작업에 적용할 수 있어야 합니다.

[이미지 예정: 프롤로그-1] 클라우드 AI 코딩 도구와 로컬 AI 코딩 도구 흐름 비교

이 책은 초보자를 위한 책이지만, 얕게만 설명하지는 않습니다. 개발자가 겪는 병목, 설정 오류, 모델 선택의 애매함, 컨텍스트 부족 문제까지 같이 다루겠습니다. 설치 화면만 따라 하는 책은 도구가 업데이트되면 금방 뒤쳐집니다. 그러나 구조를 이해하면 도구 이름이 바뀌어도 다시 조립하고 응용 할 수 있습니다.

개인적으로는 앞으로 개발자의 AI 환경이 하나의 모델로 통일되기보다, 여러 모델과 여러 실행 방식을 섞는 방향으로 갈 가능성이 높다고 봅니다. 자동완성은 빠른 소형 모델이 맡고, 파일 단위 리팩터링은 중형 코딩 모델이 맡고, 어려운 설계 검토는 클라우드 대형 모델이 맡는 식입니다. 이 책에서 만드는 로컬 코딩 환경은 그 하이브리드 시대의 기본기입니다.

먼저 왜 로컬 AI 코딩 도구가 필요한지, 클라우드 AI 코딩 도구의 장점과 한계를 어떻게 바라봐야 하는지부터 살펴보겠습니다.

0장. 클라우드 AI 코딩 도구의 한계와 로컬 AI의 기회

0.1 AI 코딩 도구가 개발 방식을 바꾼 이유​

AI 코딩 도구가 개발 방식을 바꾼 가장 큰 이유는 “검색”과 “작성” 사이의 거리를 줄였기 때문입니다. 예전에는 개발자가 문서를 찾고, 예제를 읽고, 현재 프로젝트 상황에 맞게 코드를 다시 작성해야 했습니다. 이제는 IDE 안에서 질문하면 모델이 현재 파일이나 선택한 코드 조각을 바탕으로 설명과 수정안을 함께 제시합니다. 개발자는 답을 찾는 데 쓰던 시간을 줄이고, 더 빨리 가설을 세우고 검증할 수 있게 되었습니다.

여기서 중요한 점은 AI 코딩 도구가 개발자를 대체한다기보다, 개발자의 작업 단위를 바꾼다는 것입니다. 개발자는 더 이상 모든 줄을 처음부터 끝까지 직접 입력하는 데에만 집중하지 않습니다. 대신 요구사항을 작게 쪼개고, 모델에게 명확하게 지시하고, 결과를 검토하고, 테스트로 확인합니다. 실무에서 생산성이 올라가는 지점도 바로 여기에 있습니다. 모델이 코드를 대신 써 주기 때문이 아니라, 사람이 반복적으로 하던 조사와 초안 작성 시간을 줄여 주기 때문입니다.

예를 들어 React 컴포넌트를 만들 때를 생각해 보겠습니다. 개발자는 props 이름과 상태 흐름을 정합니다. AI는 보일러플레이트 코드, 조건부 렌더링, 기본 스타일 클래스, 간단한 테스트 코드를 빠르게 제안할 수 있습니다. Python 유틸 함수를 만들 때도 마찬가지입니다. 입력과 출력 조건을 설명하면 모델은 함수 초안을 만들고, 예외 처리나 테스트 케이스를 제안할 수 있습니다. 개발자는 그 초안을 그대로 믿는 것이 아니라, 프로젝트 규칙에 맞게 고치고 실행합니다.

이런 방식은 특히 초안 작성, 리팩터링, 테스트 작성, 문서화에 강합니다. 반면 요구사항이 애매하거나, 기존 코드베이스의 숨은 맥락이 중요하거나, 보안상 실수가 치명적인 영역에서는 사람이 더 적극적으로 판단해야 합니다. AI 코딩 도구는 “생각을 대신하는 도구”가 아니라 “생각을 빠르게 펼쳐 볼 수 있게 해 주는 도구”에 가깝습니다. 저는 이런 상태를 '첫 걸음을 떼는 데 큰 도움을 주는'것이라고 봅니다.

[표 추가예정 0-1] AI 코딩 도구와 로컬 코딩 도구 강점 비교 표

0.2 Claude, ChatGPT, Copilot을 쓰면서 생기는 비용 문제​

클라우드 AI 코딩 도구는 편합니다. 서비스 가입, 코드 에디터에서 확장 설치, API 키를 넣거나 인증을 하면 바로 쓸 수 있습니다. 모델은 최신이고, 하드웨어는 사용자가 신경 쓰지 않아도 됩니다. 문제는 사용량이 늘수록 비용이 같이 커진다는 점입니다. 개인 개발자라면 월 구독료와 토큰 비용이 부담 될 수 있고, 팀 단위로 도입하면 좌석 수, API 사용량, 모델 등급에 따라 비용 구조가 복잡해지고 예산이 빠르게 소진 될 수 있습니다.

비용 문제는 단순히 “돈이 아깝다”의 문제가 아닙니다. 개발자가 AI를 자주 쓰기 시작하면, 작은 질문까지 모두 클라우드 모델로 보내게 됩니다. “이 함수 설명해 줘”, “이 테스트 이름 괜찮아?”, “이 타입 정의 정리해 줘” 같은 요청이 쌓입니다. 하나하나는 작지만, 팀 전체가 매일 사용하면 총량이 커집니다. 그러다 보면 정말 고성능 모델이 필요한 작업과, 로컬 모델로도 충분한 작업이 섞여 버립니다.

2025년 1월부터 2026년 5월까지의 흐름을 보면 이 문제가 더 분명해집니다. 토큰 가격은 단순히 한 방향으로만 오르지 않았습니다. OpenAI는 GPT-4.1처럼 GPT-4o보다 저렴한 모델을 내놓았고, Anthropic도 Sonnet 계열의 가격을 비교적 안정적으로 유지했습니다. 그러나 개발자가 실제로 체감하는 비용은 다른 방향으로 움직였습니다. 코딩 업무의 중심이 “짧은 질문에 답하는 챗봇”에서 “긴 컨텍스트를 읽고, 여러 파일을 고치고, 테스트를 돌리고, 도구를 반복 호출하는 에이전트”로 옮겨 갔기 때문입니다. 같은 1회 요청이라도, 에이전트형 코딩 작업은 입력 토큰, 출력 토큰, 추론 토큰, 도구 호출, 캐시, 긴 컨텍스트 비용이 함께 붙습니다.

2025~2026년 주요 코딩 LLM 토큰 비용 변화​

아래 가격은 API 기준이며, 모두 100만 토큰당 달러 가격이다. 단순 챗봇 질문만 보면 일부 모델은 저렴해졌지만, 실제 개발 현장은 점점 더 긴 컨텍스트, 더 많은 출력, 더 강한 추론, 더 많은 도구 호출을 쓰는 방향으로 이동하고 있다. 그래서 개발자가 체감하는 비용은 다시 빠르게 커지고 있다.

OpenAI: GPT 계열 가격 변화​

시점기준 모델입력 비용출력 비용2025년 초 대비 출력 비용해석
2025.01GPT-4o$2.50$10.001.0배당시 실무형 고성능 모델
2025.04GPT-4.1$2.00$8.000.8배일시적으로 더 저렴해짐
2025.08GPT-5$1.25$10.001.0배입력은 싸지만 출력은 GPT-4o 수준
2025.12GPT-5.2$1.75$14.001.4배추론·에이전트형 작업 비용 상승
2026.03GPT-5.4$2.50$15.001.5배코딩·전문 업무용 모델 단가 상승
2026.05GPT-5.5$5.00$30.003.0배프런티어 코딩 모델 비용 확대
2026.05GPT-5.5 Pro$30.00$180.0018.0배최고 정확도 모델은 완전히 다른 가격대

Anthropic: Claude 계열 가격 변화​

시점기준 모델/사용 방식입력 비용출력 비용Sonnet 기준 대비해석
2025.01Claude 3.5 Sonnet$3.00$15.001.0배Claude 코딩 사용의 기준 가격대
2025.05Claude Sonnet 4$3.00$15.001.0배기본 Sonnet 단가는 유지
2025.05Claude Opus 4$15.00$75.005.0배고난도 코딩·에이전트 작업용 프리미엄
2026.05Claude Sonnet 4.6$3.00$15.001.0배기본형은 여전히 같은 가격대
2026.05Claude Opus 4.8$5.00$25.001.7배최신 Opus는 낮아졌지만 Sonnet보다는 비쌈
2026.05Opus 4.8 Fast mode$10.00$50.003.3배빠른 출력 선택 시 비용 상승
2026.05Opus 4.6/4.7 Fast mode$30.00$150.0010.0배속도 프리미엄은 매우 높은 가격대

Claude Code 실사용 비용 변화​

항목이전 추정2026년 4월 추정증가율
개발자 1인당 활성 사용일 평균 비용$6/일$13/일약 2.2배
90% 사용자 비용 상한$12/일 이하$30/일 이하약 2.5배

이 표에서 중요한 점은 “모든 모델의 기본 단가가 매달 오른다”는 것이 아닙니다. 더 정확히는 개발자가 실제로 쓰는 AI 코딩 방식이 단순 질문에서 긴 컨텍스트, 파일 단위 리팩터링, 테스트 생성, 도구 호출, 장시간 에이전트 실행으로 이동하면서 총비용이 커진다는 점입니다.

특히 코딩 작업은 출력 토큰이 많이 발생합니다. 함수 설명 한 번은 작지만, 에이전트가 여러 파일을 읽고, 계획을 세우고, 코드를 고치고, 테스트를 돌리고, 다시 수정하면 입력과 출력 토큰이 반복적으로 누적됩니다. 그래서 토큰당 단가가 몇 배 차이 나지 않아 보여도, 실제 월 비용은 훨씬 크게 벌어집니다.

이런 흐름은 로컬 코딩 LLM을 써야 하는 중요한 이유가 됩니다. 자동완성, 주석 정리, 작은 함수 리팩터링, 테스트 초안, 에러 메시지 설명처럼 반복적이고 위험도가 낮은 작업은 로컬 모델에서 처리하고, 복잡한 설계 판단이나 대규모 장애 분석처럼 정말 강한 모델이 필요한 작업만 클라우드 모델로 보내는 방식이 비용 면에서 훨씬 현실적입니다.

즉, 문제는 “가격표의 숫자 하나”가 아닙니다. 더 좋은 모델이 나오면 개발자는 더 큰 일을 맡깁니다. 더 큰 일을 맡기면 모델은 더 오래 생각하고, 더 많은 파일을 읽고, 더 많은 명령을 실행하고, 더 많은 중간 결과를 검증합니다. 모델이 토큰 효율적으로 좋아져도, 작업 자체가 커지면 월말 청구서는 커질 수 있습니다. 오히려 AI를 쓰면 퇴근이 빨라질 줄 알았는데 일이 더 많아졌다는 말은 괜히 나온것이 아닙니다.

Copilot의 사용량 기반 과금 전환이 보여 주는 시장 신호​

GitHub Copilot은 모델 제공사라기보다 개발자용 AI 제품이지만, 비용 흐름을 이해하는 데 중요한 신호입니다. GitHub는 2026년 4월 공지에서 Copilot이 1년 전의 “인에디터 보조 도구”가 아니라, 최신 모델을 쓰고 전체 저장소를 반복적으로 다루는 agentic platform으로 바뀌었다고 설명했습니다. 또 장시간 multi-step coding session의 compute와 inference 요구가 크게 높아져, 기존 premium request 모델이 지속 가능하지 않다고 밝혔습니다. 그래서 2026년 6월 1일부터 PRU 대신 GitHub AI Credits로 전환하고, 입력·출력·캐시 토큰 사용량과 모델별 API 요율에 따라 크레딧을 차감한다고 발표했습니다.

이 변화는 로컬 코딩 LLM을 써야 하는 이유를 더 분명하게 만듭니다. 앞으로 코딩 AI 비용은 “월 구독료 하나 내면 무제한에 가깝게 쓴다”가 아니라 “얼마나 긴 컨텍스트를 넣었는지, 어떤 모델을 골랐는지, 몇 번 도구를 호출했는지, 얼마나 오래 에이전트를 돌렸는지”에 가까워질 가능성이 큽니다. 개발자가 AI를 많이 쓸수록, 비용을 통제하려면 모델 선택 기준을 가져야 합니다.

로컬 AI의 기회는 여기에서 생깁니다. 모든 요청을 로컬로 바꾸자는 뜻이 아닙니다. 자주 반복되고 위험도가 낮은 작업은 로컬 모델에 맡기고, 복잡하고 중요한 판단은 클라우드 모델에 맡기는 식으로 역할을 나누자는 뜻입니다. 이렇게 하면 비용을 줄이면서도 고성능 클라우드 모델의 장점을 유지할 수 있습니다.

예를 들어 자동완성은 빠른 소형 모델을 로컬에서 실행하는 것이 잘 맞습니다. 입력 도중 매번 클라우드 API를 호출하면 지연 시간이 생기고 비용도 쌓입니다. 반면 자동완성은 보통 현재 줄, 현재 함수, 근처 컨텍스트만 있으면 됩니다. 따라서 로컬 모델이 충분히 빠르다면 실무 체감이 좋습니다. 반대로 “이 서비스의 인증 구조를 어떻게 바꿀지 설계해 달라” 같은 질문은 더 긴 컨텍스트와 강한 추론이 필요하므로 클라우드 모델이 나을 수 있습니다.

반복적인 테스트 초안 작성, 작은 함수 리팩터링, 로그 메시지 정리, 주석 생성, 타입 힌트 보강, 간단한 스크립트 작성도 로컬 모델에 잘 맞습니다. 이런 요청은 하루에 수십 번 발생합니다. 한 번당 비용은 작아 보여도, 팀 전체가 매일 반복하면 API 비용과 구독 한도가 빠르게 소모됩니다. 반대로 로컬 모델은 모델 다운로드와 장비·전기 비용을 제외하면 토큰당 API 과금이 없습니다. 개발자가 부담 없이 “한 번 더 설명해 줘”, “다른 방식으로 다시 써 줘”, “테스트 케이스를 5개 더 만들어 줘”라고 말할 수 있습니다.

비용 최적화의 핵심은 모델을 싸게 쓰는 것이 아니라, 작업에 맞는 모델을 쓰는 것입니다. 비싼 모델을 아껴 쓰는 것보다 더 중요한 것은, 어떤 요청을 어떤 모델에게 보낼지 기준을 세우는 일입니다. 이 책에서는 그 기준을 계속 반복해서 다루겠습니다. 간단한 반복 작업은 로컬 모델로, 민감한 코드의 1차 분석도 로컬 모델로, 큰 설계 판단과 복잡한 장애 분석은 클라우드 고성능 모델로 보내는 식입니다. 이런 하이브리드 구조를 갖추면 비용 상승 국면에서도 AI 코딩을 포기하지 않고, 오히려 더 자주 안전하게 사용할 수 있습니다.

0.3 회사 코드, 고객 데이터, 내부 문서를 외부로 보내는 리스크​

개발자가 AI 코딩 도구를 쓸 때 가장 민감한 문제는 코드와 데이터의 이동입니다. 회사 내부 코드, 아직 공개되지 않은 제품 로직, 고객 데이터가 섞인 로그, 보안 설정 파일, API 키가 포함된 코드 조각은 외부로 나가면 안 됩니다. 대부분의 클라우드 AI 서비스는 보안 정책과 데이터 처리 조건을 제공합니다. 하지만 회사 입장에서는 “정책상 안전하다”와 “우리 내부 규정상 보내도 된다”가 항상 같은 말은 아닙니다.

특히 스타트업이나 작은 팀에서는 이런 기준이 명확하지 않은 경우가 많습니다. 개발자는 생산성을 위해 AI 도구를 쓰고 싶고, 대표나 보안 담당자는 코드 반출을 걱정합니다. 규정이 모호하면 결국 두 가지 문제가 생깁니다. 하나는 개발자가 도구를 아예 못 쓰게 되어 생산성이 떨어지는 문제입니다. 다른 하나는 명확한 기준 없이 각자 알아서 쓰다가 나중에 리스크가 발견되는 문제입니다.

로컬 AI는 이 중간 지대를 만들어 줍니다. 로컬 모델은 기본적으로 내 컴퓨터에서 실행되므로, 프롬프트와 코드가 외부 모델 API로 전송되지 않습니다. 물론 로컬 툴 자체가 업데이트 확인, 모델 다운로드, 원격 기능을 사용할 수 있으므로 모든 네트워크 활동이 자동으로 사라지는 것은 아닙니다. 그러나 코드를 외부 추론 서버에 보내지 않고도 AI 도움을 받을 수 있다는 점은 분명한 장점입니다.

보안을 위해서는 “로컬이면 무조건 안전하다”가 아니라 “어떤 데이터가 어디로 이동하는지 확인한다”가 맞습니다. LM Studio 같은 로컬 모델 실행 도구를 쓸 때도 모델 다운로드 출처를 확인해야 합니다. VS Code 확장을 쓸 때도 어떤 요청이 어느 서버로 가는지 설정을 봐야 합니다. Continue 같은 확장도 로컬 모델과 연결할 수 있지만, 설정에 따라 외부 모델이나 원격 기능을 함께 사용할 수 있습니다. 따라서 로컬 AI 도입의 첫 단계는 도구 설치가 아니라 데이터 흐름을 그리는 일입니다.

[이미지 0-2 ] “데이터 흐름 확인표” 구조도.

0.4 로컬 AI가 잘하는 일과 아직 부족한 일​

로컬 AI가 잘하는 일은 명확합니다.

  • 첫째, 짧고 반복적인 코딩 보조입니다. 함수 이름과 주석을 보고 다음 줄을 제안하거나, 선택한 코드를 설명하거나, 작은 함수를 리팩터링하는 작업입니다.
  • 둘째, 민감한 코드에 대한 1차 분석입니다. 외부로 보내기 어려운 코드라도 로컬 모델에게 구조를 설명시키고, 위험해 보이는 부분을 물어볼 수 있습니다.
  • 셋째, 비용을 거의 추가하지 않고 많이 실험하는 일입니다. 로컬 모델은 전기료와 장비 비용을 제외하면 토큰당 API 비용이 없습니다.

반대로 부족한 점도 분명합니다. 로컬 모델은 내 장비 성능에 크게 묶입니다. RAM이 적으면 모델을 불러오지 못합니다. VRAM이 적으면 사용할 수 없는 모델이 많고, 속도가 느려집니다. CPU만으로도 실행은 가능하지만, 큰 모델에서는 응답이 실무 속도를 따라오지 못할 수 있습니다. 또한 작은 모델은 장기적인 설계 판단, 복잡한 디버깅, 여러 파일에 걸친 추론에서 오류가 늘어날 수 있습니다.

또 하나의 한계는 컨텍스트입니다. 로컬 모델이 내 컴퓨터에서 실행된다고 해서 프로젝트 전체를 자동으로 다 아는 것은 아닙니다. 모델은 프롬프트에 들어온 내용만 봅니다. IDE 확장이나 에이전트가 파일을 읽어 컨텍스트로 넣어 줄 수는 있지만, 그 역시 토큰 제한과 검색 품질의 영향을 받습니다. 그래서 로컬 AI 코딩의 실력은 모델만으로 결정되지 않습니다. 어떤 파일을 넣을지, 어떤 문서를 같이 줄지, 얼마나 작게 작업을 나눌지가 중요합니다.

이 책에서는 로컬 AI를 “클라우드 모델의 완전한 대체재”로 보지 않습니다. 더 정확히는 “개발자의 기본 작업대 위에 놓이는 개인 보조 도구”로 봅니다. 기본 작업은 로컬에서 처리하고, 복잡한 판단은 필요할 때 클라우드로 올리는 방식이 현실적입니다. 이런 관점을 갖고 시작하면 로컬 모델에 과도한 기대를 하지 않으면서도, 실제로 얻을 수 있는 이점을 놓치지 않을 수 있습니다.

물론 이런 현실도 빠른 시일내에 가성비 높은 로컬 하드웨어, 작은 파라미터로도 뛰어난 성능을 내는 새로운 모델과 임베딩등의 발전으로 지금보다 더 효과적인 로컬 모델의 성능 업그레이드는 계속 될 것입니다.

0.5 이 책에서 만들 최종 결과물: 나만의 로컬 코딩 에이전트 워크플로​

이 책에서 독자는 LM Studio에서 로컬 코딩 모델을 실행하고, 로컬 서버를 열고, VS Code의 Continue 확장과 연결해 사용하는 실습을 해볼 수 있습니다. 이어서 로컬 모델로 코드 질문을 하고, 선택한 코드를 리팩터링하고, 자동완성 모델과 채팅 모델을 분리하고, 프로젝트 컨텍스트를 전달하는 기본 흐름까지 경험 합니다.

구성은 다음과 같습니다. Part 1에서는 로컬 AI 코딩의 전체 구조를 이해합니다. 모델, 런타임, 로컬 서버, IDE 확장, 에이전트가 어떻게 연결되는지 봅니다. Part 2에서는 모델 선택을 다룹니다. 파라미터 수, 양자화, 컨텍스트 길이, 하드웨어 제약, 벤치마크 해석을 설명합니다. Part 3에서는 LM Studio를 설치하고 모델을 실행합니다. 로컬 서버, OpenAI 호환 API, 성능 설정까지 다룹니다. Part 4에서는 VS Code와 Continue를 연결해 실제 코딩 워크플로를 만듭니다. 부록에서는 LLM Fit을 사용해 내 로컬 시스템(윈도우, 맥OS, 리눅스 기반 PC)에서 사용가능한 모델을 확인할 수 있습니다.

이 흐름을 한 번 실험해보고, 클라우드 모델만큼의 성능은 아니어도, 실제 돌아가는 워크플로우를 경험하면, 도구가 바뀌어도 응용할 수 있습니다. LM Studio 대신 Ollama나 llama.cpp 서버를 쓸 수도 있고, VS Code 대신 다른 IDE를 쓸 수도 있습니다. 핵심은 “로컬에서 모델을 실행하고, IDE가 그 모델에 요청을 보내며, 개발자는 컨텍스트를 잘 설계한다”는 구조입니다.

[표 0-2] 학습 결과물.

이제 본격적으로 구조를 보겠습니다. 로컬 AI는 신기한 마법이 아니라, 생각보다 단순한 소프트웨어 구조입니다(LLM도 극단적으로 말하면 함수입니다). 이 구조를 이해하면 설치 오류도 덜 무섭고, 모델 선택도 훨씬 쉬워집니다.