Skip to main content

6장. LM Studio 설치와 첫 모델 실행

6.1 LM Studio가 로컬 코딩 워크플로에서 하는 역할​

LM Studio는 로컬 AI 입문자에게 좋은 출발점입니다. 모델 검색, 다운로드, 실행, 채팅 테스트, 로컬 서버 실행을 한 앱 안에서 처리할 수 있기 때문입니다. 로컬 LLM을 처음 접하는 개발자는 모델 포맷, 런타임, 포트, API 호출을 한꺼번에 이해해야 해서 어렵게 느낄 수 있습니다. LM Studio는 이 과정을 그래픽 인터페이스로 묶어 줍니다.

이 책의 워크플로에서 LM Studio는 세 가지 역할을 합니다. 첫째, 모델 관리자입니다. Hugging Face 등에 공개된 모델을 검색하고 내려받습니다. 둘째, 실행 환경입니다. 모델을 로드하고 채팅 UI에서 테스트합니다. 셋째, 로컬 API 서버입니다. VS Code의 Continue가 연결할 수 있도록 OpenAI 호환 엔드포인트를 제공합니다.

LM Studio는 “AI 코딩 도구 전체”가 아닙니다. LM Studio는 모델을 실행하는 중심축입니다. 실제 코딩 경험은 VS Code와 Continue 같은 IDE 확장에서 만들어집니다. 다시 말해 LM Studio는 엔진룸이고, Continue는 운전석에 가깝습니다. 엔진룸이 안정적으로 돌아야 운전석에서 좋은 경험을 할 수 있습니다.

[이미지 6-1] LM Studio의 역할.

6.2 Windows, macOS, Linux 설치 흐름​

LM Studio 설치는 운영체제별로 약간 다릅니다. 공식 사이트에서 설치 파일을 내려받고 실행하는 흐름은 비슷하지만, 지원 조건은 확인해야 합니다. LM Studio 공식 시스템 요구사항에 따르면 macOS는 Apple Silicon과 macOS 14 이상을 기준으로 하며, Windows x64 환경에서는 AVX2 지원이 필요합니다. Linux는 AppImage로 배포되고, Ubuntu 20.04 이상을 기준으로 안내됩니다.

설치 전에 가장 먼저 확인할 것은 장비 사양입니다. RAM은 최소 16GB 이상을 권장합니다. Windows 환경에서는 전용 GPU VRAM 4GB 이상이 권장됩니다. Apple Silicon Mac에서도 16GB 이상이 더 안정적입니다. 8GB 장비에서도 작은 모델로 실험은 가능하지만, 이 책의 실습을 쾌적하게 따라가려면 16GB 이상을 권장합니다.

설치 과정 자체는 어렵지 않습니다. 다만 회사 장비에서는 보안 정책에 따라 앱 설치가 제한될 수 있습니다. 이 경우 IT 담당자에게 로컬 모델 실행 도구의 목적과 데이터 흐름을 설명해주세요. 특히 모델 파일이 크고, 외부 모델 저장소에서 내려받는 과정이 있으므로 네트워크 정책도 확인해야 합니다.

[실습 제안 6-1] LM Studio 공식 다운로드 페이지 화면.

6.3 모델 검색과 다운로드​

LM Studio를 실행하면 모델을 검색하고 다운로드할 수 있습니다. 이때 모델 이름에 담긴 정보를 읽는 습관이 중요합니다. 예를 들어 모델 이름에는 보통 기반 모델, 파라미터 수, 지시 튜닝 여부, 코딩 특화 여부, 양자화 수준, 포맷이 들어갑니다. 7B, 14B, Coder, Instruct, Q4, Q5, GGUF, MLX 같은 단어를 눈여겨봐야 합니다.

처음에는 너무 많은 후보를 받지 않는 것이 좋습니다. 모델 파일은 큽니다. 몇 개만 내려받아도 디스크를 빠르게 사용합니다. “자동완성 후보 1개”, “채팅 후보 1개”, “비교용 후보 1개” 정도로 시작합니다. 특히 코딩 실습에서는 코딩 특화 모델을 우선 고릅니다. 일반 대화 모델도 쓸 수 있지만, 리팩터링과 테스트 생성에서는 코딩 모델이 더 안정적일 가능성이 높습니다.

모델 상세 페이지에서는 라이선스를 확인해야 합니다. 개인 실험과 회사 업무는 기준이 다를 수 있습니다. 상업적 사용이 가능한지, 재배포가 가능한지, 모델 출력물 사용 조건이 있는지 확인합니다. 이 책에서는 특정 모델을 절대적인 정답으로 추천하기보다 선택 기준을 강조합니다. 모델 생태계는 빠르게 바뀌므로, 이름보다 기준을 익히는 편이 오래갑니다.

6.4 GGUF, MLX, 모델 포맷의 기본 개념​

모델 포맷은 모델 파일이 저장되는 방식입니다. 로컬 AI에서는 GGUF와 MLX를 자주 보게 됩니다. GGUF는 llama.cpp 계열 런타임에서 널리 쓰이는 포맷입니다. Hugging Face 문서는 GGUF를 빠른 로딩과 저장에 최적화된 바이너리 포맷으로 설명하고, GGML 및 다른 실행기에서 사용되도록 설계되었다고 안내합니다.

MLX는 Apple Silicon 환경에서 중요합니다. Apple은 MLX를 Apple Silicon의 통합 메모리 구조에 최적화된 머신러닝 프레임워크로 설명합니다. LM Studio도 Apple Silicon Mac에서 MLX 엔진을 지원하며, MLX 모델을 채팅 UI나 로컬 서버에서 사용할 수 있다고 소개한 바 있습니다. Mac 사용자는 GGUF와 MLX 모델을 모두 볼 수 있으므로, 같은 모델이라도 어떤 포맷이 내 장비에서 더 빠르고 안정적인지 비교해 볼 수 있습니다.

초보자는 포맷을 너무 어렵게 생각하지 않아도 됩니다. 중요한 것은 “내 실행 도구가 지원하는 포맷인가”, “내 장비에서 빠른가”, “원하는 양자화 버전이 있는가”입니다. LM Studio 안에서 검색하고 실행할 수 있는 모델이라면 기본 호환성은 갖춘 것으로 볼 수 있습니다. 다만 외부에서 직접 파일을 내려받아 가져오는 경우에는 디렉터리 구조와 포맷 지원을 더 신경 써야 합니다.

[표 6-1] GGUF와 MLX 비교.

6.5 첫 번째 로컬 모델 실행하기​

첫 번째 모델은 7B급 Q4 또는 Q5 코딩 모델, 장비가 약하다면 3B 이하 모델로 시작합니다. 모델을 다운로드한 뒤 LM Studio에서 로드합니다. 로딩 중에는 메모리 사용량이 올라갑니다. 로딩이 실패하면 모델이 너무 크거나, 컨텍스트 설정이 과하거나, GPU/RAM 자원이 부족할 수 있습니다.

모델을 로드했다면 먼저 채팅 UI에서 간단히 테스트합니다. “안녕하세요. 지금부터 코드 작업을 도와주세요” 같은 일반 질문보다, 실제 코딩 작업과 가까운 질문이 좋습니다. 예를 들어 “TypeScript에서 Record<string, unknown>과 any의 차이를 짧게 설명해 주세요” 또는 “아래 Python 함수의 edge case를 찾아 주세요”처럼 물어봅니다.

첫 테스트의 목표는 응답이 정상적으로 나오는지, 속도가 감당 가능한지, 코드 설명이 너무 엉뚱하지 않은지 확인하는 것입니다. 이 단계에서 모델이 너무 느리다면 IDE와 연결하기 전에 모델을 바꾸거나 설정을 낮추는 편이 좋습니다.

[실습 화면 6-2] LM Studio에서 모델을 선택하고 로드한 화면.

6.6 채팅으로 모델 품질 테스트하기​

채팅 테스트는 모델 선택의 가장 빠른 필터입니다. 챗지피티 등에서 사용하는 일반 질문보다 실제 업무와 비슷한 테스트 프롬프트를 사용해야 합니다. 프론트엔드 개발자라면 React, TypeScript, 상태 관리, API 호출 관련 질문을 넣습니다. 백엔드 개발자라면 데이터베이스, 인증, 테스트, 예외 처리 질문을 넣습니다. 데이터 엔지니어라면 Python, SQL, 배치 처리, 파일 파싱 질문이 좋습니다.

좋은 테스트는 정답 확인이 가능합니다. 예를 들어 “이 정규식이 무엇을 의미하나요”보다 “아래 정규식이 이메일 검증에 부적절한 이유를 3가지 말하고, 더 안전한 대안을 제시해 주세요”가 좋습니다. 또 “이 코드를 개선해 주세요”보다 “아래 함수에서 입력값이 빈 배열일 때 생길 수 있는 문제를 찾고, 테스트 케이스를 추가해 주세요”가 좋습니다.

모델 답변을 볼 때는 세 가지를 봅니다. 첫째, 요청을 지켰는가. 둘째, 코드가 실행 가능한가. 셋째, 불필요한 변경을 하지 않았는가. 좋은 모델은 모르거나 애매한 부분을 어느 정도 조심스럽게 말합니다. 나쁜 모델은 제약을 무시하고 전체 구조를 마음대로 바꿉니다.

[실습 6-1] 모델 품질 테스트용 프롬프트 5개를 테스트.

6.7 코딩 모델을 테스트하는 간단한 프롬프트​

다음 프롬프트는 첫 테스트에 바로 쓸 수 있습니다.

아래 TypeScript 함수의 문제점을 찾아 주세요.
요구사항은 다음과 같습니다.
1. 함수 이름과 매개변수 이름은 바꾸지 마세요.
2. 외부 라이브러리는 추가하지 마세요.
3. 수정된 코드와 변경 이유만 짧게 출력해 주세요.

function getUserName(user: { name?: string } | null) {
  return user.name.trim();
}

이 프롬프트에서 좋은 모델은 user가 null일 수 있고, name이 undefined일 수 있으며, trim() 호출 전에 안전한 처리가 필요하다는 점을 지적해야 합니다. 또한 함수 시그니처를 무리하게 바꾸지 않고 요구사항 안에서 수정안을 제시해야 합니다.

또 다른 프롬프트입니다.

아래 Python 함수에 대한 pytest 테스트를 작성해 주세요.
정상 케이스 2개, 예외 케이스 2개를 포함해 주세요.
함수 코드는 수정하지 말고 테스트 코드만 출력해 주세요.

def divide(a: float, b: float) -> float:
    if b == 0:
        raise ValueError("b must not be zero")
    return a / b

좋은 모델은 pytest.raises를 사용하고, floating point 비교를 적절히 처리하며, 함수 코드를 다시 쓰지 않습니다. 이런 작은 테스트를 여러 개 해 보면 모델의 성격이 드러납니다. 모델 선택은 감이 아니라 반복 테스트로 해야 합니다.