2. 온디바이스 환경의 제약부터 이해하기

온디바이스 LLM을 처음 시도할 때 가장 많이 생기는 오해가 있습니다. 모델만 잘 고르면 곧바로 멋지게 돌아갈 거라는 기대입니다. 하지만 현실은 조금 다릅니다. 로컬 LLM 프로젝트는 대개 모델 자체보다 하드웨어 제약을 얼마나 정확히 이해했는가에서 성패가 갈립니다.

쉽게 말해 보겠습니다. 클라우드 LLM은 대형 주방에서 요리하는 느낌이고, 온디바이스 LLM은 원룸 주방에서 요리하는 느낌입니다. 요리 실력이 나쁘지 않아도, 냉장고 크기와 가스 화력, 환기 상태를 무시하면 금방 한계에 부딪힙니다. 온디바이스도 똑같습니다. 성능 좋은 모델을 무작정 들여오면, 메모리가 부족하고, 저장공간이 차고, 발열이 오르고, 배터리가 녹아내립니다.

이 장의 목표는 단순합니다. 실패 없는 구축은 하드웨어 제약을 인정하는 데서 시작된다는 감각을 몸에 익히는 것입니다. 다음 장들에서 llama.cpp와 GGUF를 다룰 때도, 이 감각이 있으면 훨씬 덜 헤맵니다.

먼저 관점을 바꾸자: "돌아간다"와 "쓸 만하다"는 다르다

초보자는 보통 이렇게 생각합니다.

"모델이 실행만 되면 된 거 아닌가요?"

아쉽지만 아닙니다. 온디바이스에서는 실행 성공이 출발점일 뿐입니다. 실제로는 그다음 질문이 더 중요합니다.

이 모델이 내 기기에서 안정적으로 돌아가는가? 질문을 넣었을 때 기다릴 만한 속도로 답하는가? 다른 프로그램을 켜 둔 상태에서도 버티는가? 배터리와 발열을 감수할 만큼 실용적인가?

예를 들어 어떤 모델이 내 노트북에서 겨우 실행되었다고 해 봅시다. 그런데 첫 답변이 시작되기까지 20초가 걸리고, 한 문단 생성에 또 한참이 걸리며, 팬이 비행기 이륙 소리를 내기 시작한다면 어떨까요? 기술적으로는 "성공"이지만, 사용자 입장에서는 거의 실패입니다.

그래서 온디바이스 구축의 첫 번째 원칙은 이것입니다.

최대 성능을 꿈꾸기 전에, 내 기기의 현실을 먼저 계산하자.

1단계: 가장 먼저 메모리를 본다

온디바이스 LLM에서 가장 먼저 막히는 벽은 거의 항상 메모리입니다. 여기서 메모리는 단순히 "모델 파일 크기"만 뜻하지 않습니다. 실제 실행 중에는 생각보다 더 많은 공간이 필요합니다.

모델이 동작할 때 메모리는 대체로 네 군데에서 사용됩니다.

• 모델 가중치 자체를 올려 두는 공간

• 계산 중 잠깐 쓰는 작업 공간

• 대화 문맥을 유지하기 위한 KV 캐시 공간

• 운영체제와 다른 앱이 이미 쓰고 있는 기본 메모리

이 네 가지를 같이 봐야 합니다. 초보자는 종종 "모델 파일이 4GB니까 RAM 4GB면 되겠네?"라고 생각하는데, 실제로는 그렇게 단순하지 않습니다. 운영체제도 메모리를 먹고, 브라우저도 메모리를 먹고, 실행 엔진도 메모리를 쓰고, 대화가 길어질수록 KV 캐시도 커집니다.

여기서 KV 캐시는 조금 낯선 말일 수 있습니다. 지금은 이렇게만 이해해도 충분합니다. 모델이 앞에서 읽은 내용을 잊지 않도록 붙잡아 두는 메모장입니다. 대화가 길어질수록 메모장이 두꺼워진다고 생각하면 됩니다.

초보자를 위한 가장 쉬운 판단법은 이렇습니다.

1. 내 기기의 전체 RAM이 얼마인지 확인합니다.

2. 운영체제와 평소 켜 두는 프로그램이 얼마나 쓰는지 생각합니다.

3. 남는 메모리 안에서 모델과 실행 여유분이 버틸 수 있는지 봅니다.

4. 딱 맞는 수준이 아니라, 항상 안전 여유를 남깁니다.

여기서 "안전 여유"가 특히 중요합니다. 메모리를 꽉 채운 상태는 언뜻 효율적이지만, 실제 사용에서는 가장 불안정한 상태입니다. 브라우저 탭 몇 개 더 열고, 파일 탐색기를 띄우고, 백그라운드 작업이 겹치면 바로 버벅이거나 종료될 수 있습니다.

온디바이스 구축을 오래 해 본 사람일수록 큰 모델보다 먼저 메모리 예산표를 떠올립니다. 이 습관이 프로젝트를 살립니다.

2단계: 저장공간은 "한 번만 받으면 끝"이 아니다

메모리 다음으로 자주 과소평가되는 것이 저장공간입니다. 많은 사람이 모델 파일 하나만 내려받으면 끝날 거라고 생각합니다. 하지만 실제 작업을 시작하면 저장공간은 꽤 빨리 줄어듭니다.

이유는 간단합니다. 모델 하나만 있는 게 아니기 때문입니다. 보통은 같은 모델의 여러 버전을 시험합니다. 양자화 수준이 다른 파일도 써 보고, 속도와 품질을 비교하려고 다른 크기의 모델도 내려받습니다. 그러다 보면 폴더 안이 금방 복잡해집니다.

예를 들어 이런 식입니다. 처음에는 "입문용 모델 하나만 받아 보자"로 시작합니다. 그런데 막상 써 보면 느립니다. 그래서 더 작은 버전을 받습니다. 이번엔 빠른데 답변이 아쉽습니다. 그래서 다른 계열 모델도 받습니다. 며칠 지나면 모델 파일이 서너 개가 아니라 여럿 쌓여 있습니다.

여기에 추가로 생기는 것들도 있습니다.

• 변환하거나 복사하는 중간 파일

• 로그 파일과 캐시 파일

• 임베딩 파일이나 색인 데이터

• 실험 결과를 저장한 출력물

저장공간은 단순히 "용량이 충분한가"만 볼 문제가 아닙니다. 속도도 중요합니다. SSD에 있는 모델과 느린 저장장치에 있는 모델은 체감이 다를 수 있습니다. 모델을 읽어 들이는 시간, 초기 로딩 속도, 파일 복사 시간에서 차이가 납니다.

그래서 초보자에게는 이런 기준을 권합니다. 모델 하나가 들어갈 공간만 볼 것이 아니라, 실험용 여유 공간까지 포함해서 생각하세요. 온디바이스 LLM은 의외로 "정리 안 된 다운로드 폴더"와 금세 친해지는 분야입니다.

3단계: 연산 속도는 결국 체감 속도다

온디바이스에서 세 번째 제약은 연산 속도입니다. 이 부분은 사양표만 봐서는 감이 잘 안 옵니다. 사용자는 보통 TFLOPS 같은 수치보다 더 단순하게 느낍니다.

"질문 넣고 얼마나 빨리 첫 글자가 나오지?"

"답변이 자연스럽게 이어지나?"

"한 번 물어볼 때마다 답답한가?"

즉, 중요한 것은 체감 속도입니다.

여기서 기억할 점은 하나입니다. 온디바이스 LLM은 보통 두 구간에서 시간을 씁니다. 먼저 입력한 문장을 읽고 이해하는 구간이 있고, 그다음 한 토큰씩 답을 생성하는 구간이 있습니다. 초보자는 보통 두 번째만 생각하지만, 실제로는 첫 번째도 꽤 중요합니다. 프롬프트가 길어질수록 시작이 늦어질 수 있기 때문입니다.

같은 기기에서도 속도는 여러 요소에 따라 크게 달라집니다.

• 모델이 클수록 대체로 느려집니다.

• 프롬프트가 길수록 시작 시간이 늘어납니다.

• 대화가 길어질수록 메모리 부담이 커집니다.

• CPU만 쓸 때와 GPU나 NPU를 일부 활용할 때 체감이 달라집니다.

• 같은 모델이라도 양자화 방식에 따라 속도와 품질이 바뀝니다.

이쯤 되면 초보자는 살짝 억울해집니다. "그럼 뭘 믿고 골라야 하죠?"

정답은 의외로 소박합니다. 처음부터 최고 품질 모델을 고르지 말고, 내가 참을 수 있는 속도를 먼저 정해야 합니다.

예를 들어 메신저 보조 기능이라면 답이 빨리 시작되어야 합니다. 반면 문서 요약 도구라면 몇 초 기다려도 괜찮을 수 있습니다. 즉, 속도는 절대적인 숫자가 아니라 사용 시나리오와의 궁합으로 봐야 합니다.

온디바이스에서 좋은 모델이란, 벤치마크 1등 모델이 아니라 내 작업 흐름을 끊지 않는 모델입니다.

4단계: 배터리는 조용히 사라지고, 발열은 시끄럽게 나타난다

데스크톱만 생각하면 놓치기 쉬운 제약이 있습니다. 바로 배터리와 발열입니다. 노트북, 태블릿, 스마트폰, 엣지 디바이스에서는 이 둘이 성능만큼 중요합니다.

LLM 추론은 생각보다 기기를 오래 붙잡아 둡니다. CPU나 GPU가 계속 바쁘게 움직이고, 메모리 접근도 많이 일어납니다. 그러면 배터리는 빠르게 줄고, 내부 온도는 올라갑니다. 온도가 높아지면 기기는 스스로 속도를 낮춰 버립니다. 이것을 흔히 쓰로틀링이라고 부릅니다. 쉽게 말해, 너무 뜨거워져서 기기가 "나 좀 살자" 하며 성능을 줄이는 것입니다.

여기서 재미있는 함정이 있습니다. 처음 1~2번 실행할 때는 꽤 괜찮아 보일 수 있습니다. 그런데 10분, 20분 계속 쓰면 속도가 서서히 떨어집니다. 팬은 더 크게 돌고, 배터리는 눈에 띄게 줄고, 손바닥 받침대는 미지근함을 넘어 뜨끈해집니다. 즉, 순간 성능과 지속 성능은 다르다는 뜻입니다.

온디바이스 실전에서는 오히려 지속 성능이 더 중요합니다. 제품은 데모 한 번 멋지게 돌리는 것이 아니라, 사용자가 반복해서 써도 버텨야 하기 때문입니다.

그래서 초보자일수록 이런 질문을 해 봐야 합니다.

이 기능은 전원 연결 상태에서만 쓸 것인가? 이동 중 배터리로도 자주 쓸 것인가? 여름철이나 밀폐된 공간에서도 안정적이어야 하는가?

만약 답이 "그렇다"라면, 큰 모델보다 작은 모델이 더 좋은 제품 선택일 수 있습니다. 덜 화려해 보여도, 꾸준히 돌아가는 쪽이 결국 이깁니다.

5단계: 프라이버시는 장점이지만, 동시에 설계 과제다

온디바이스 LLM의 큰 매력 중 하나는 프라이버시입니다. 데이터를 외부 서버로 보내지 않고 처리할 수 있으니 마음이 놓입니다. 그런데 여기서 한 가지를 꼭 짚고 넘어가야 합니다.

로컬 실행은 프라이버시의 시작이지, 완성은 아닙니다.

내 기기 안에서 처리한다고 해서 모든 문제가 자동으로 해결되지는 않습니다. 실제로는 이런 질문이 따라옵니다.

채팅 기록은 어디에 저장되는가? 로그 파일은 남는가? 모델 파일은 누구나 복사할 수 있는가? 기기 분실 시 데이터는 안전한가? 화면 캡처나 백업 동기화는 어떻게 되는가?

예를 들어 사내용 문서 요약 도구를 만든다고 해 봅시다. 문서를 외부 API로 보내지 않는 것만으로도 큰 장점이 있습니다. 하지만 요약 결과가 평문 로그로 남거나, 임시 파일이 정리되지 않거나, 공유 PC에서 아무나 이전 대화를 열람할 수 있다면 프라이버시 이점이 크게 줄어듭니다.

그래서 온디바이스에서는 프라이버시를 이렇게 이해하는 편이 좋습니다.

첫째, 데이터 외부 전송을 줄이는 구조적 이점이 있다. 둘째, 그 이점을 실제 보안으로 연결하려면 저장·접근·삭제 정책을 같이 설계해야 한다.

초보자일수록 이 차이를 일찍 이해해야 합니다. 그래야 "로컬이니까 안전하겠지"라는 막연한 안심 대신, 실제로 안전한 도구를 만들 수 있습니다.

6단계: 같은 온디바이스라도 기기마다 전혀 다르다

온디바이스라는 말을 들으면 하나의 통일된 환경처럼 느껴질 수 있습니다. 하지만 실제로는 전혀 그렇지 않습니다. 데스크톱 PC, 게이밍 노트북, 사무용 노트북, 맥북, 안드로이드 폰, 산업용 보드 장치는 모두 다른 세계입니다.

같은 7B 모델을 예로 들어도 결과가 크게 다를 수 있습니다. 어떤 기기에서는 꽤 쓸 만하게 돌아가고, 어떤 기기에서는 느려서 답답하며, 또 어떤 기기에서는 아예 메모리 여유가 부족할 수 있습니다.

차이가 생기는 이유는 많습니다.

• CPU 성능과 명령어 지원 차이

• GPU나 NPU 사용 가능 여부

• 메모리 대역폭 차이

• 운영체제와 드라이버 차이

• 발열 설계와 전력 제한 차이

여기서 중요한 교훈은 하나입니다.

온디바이스 구축은 모델 중심이 아니라, 기기 중심으로 생각해야 한다.

즉, "이 모델이 유명하니까 써야지"보다 "우리 기기군에서 이 모델이 감당되나?"가 먼저입니다. 서비스나 제품을 만들 때 이 순서를 거꾸로 잡으면, 뒤늦게 최적화 지옥에 빠지기 쉽습니다.

7단계: 초보자가 특히 많이 놓치는 현실적인 함정

이제 실전에서 자주 부딪히는 함정을 몇 가지 짚어 보겠습니다. 이 부분은 앞으로 llama.cpp를 사용할 때도 계속 도움이 됩니다.

첫 번째 함정은 운영체제와 다른 앱의 존재를 잊는 것입니다. 내 노트북의 RAM이 16GB라고 해서, LLM에 16GB를 다 줄 수는 없습니다. 이미 운영체제와 백그라운드 프로세스가 자리를 차지하고 있습니다.

두 번째 함정은 짧은 데모 성능만 보는 것입니다. 한 번 질문했을 때 잘 돌아간다고 끝이 아닙니다. 문맥이 길어질 때도 괜찮은지, 여러 번 반복해도 안정적인지 봐야 합니다.

세 번째 함정은 가장 큰 모델이 항상 가장 좋은 선택이라고 믿는 것입니다. 현실에서는 한 단계 작은 모델이 훨씬 빠르고, 발열이 적고, 결과적으로 더 자주 쓰이기도 합니다.

네 번째 함정은 저장공간을 너무 빡빡하게 잡는 것입니다. 실험을 시작하면 모델 파일이 늘어나고, 정리하지 않으면 금세 공간이 부족해집니다.

다섯 번째 함정은 프라이버시를 네트워크 전송 여부로만 판단하는 것입니다. 로컬 저장, 로그, 임시 파일, 사용자 계정 관리까지 같이 봐야 비로소 의미가 생깁니다.

이 함정들은 화려하지 않지만, 프로젝트를 망치는 힘은 아주 셉니다. 종종 가장 어려운 문제는 모델이 아니라 이런 기본기 부족에서 생깁니다.

8단계: 제약을 인정하면 오히려 설계가 쉬워진다

여기까지 읽으면 온디바이스가 너무 불리하게 느껴질 수도 있습니다. 하지만 오히려 반대입니다. 제약을 일찍 인정하면 설계가 더 쉬워집니다.

예를 들어 메모리가 넉넉하지 않다는 사실을 처음부터 받아들이면, 애초에 작은 모델과 짧은 컨텍스트로 목표를 재설정하게 됩니다. 그러면 실험 범위가 줄어들고, 실패 비용도 줄어듭니다.

발열과 배터리가 문제라는 걸 알면, "항상 최대 성능" 대신 "지속 가능한 성능"을 목표로 잡게 됩니다. 그러면 사용 시나리오도 더 현실적으로 설계할 수 있습니다.

프라이버시가 중요하다는 걸 제대로 이해하면, 단순한 로컬 실행을 넘어 저장 정책과 접근 통제를 함께 고민하게 됩니다. 그 결과 실제 현업에 더 가까운 도구가 나옵니다.

즉, 제약은 발목을 잡는 장애물이 아니라 설계를 똑똑하게 만드는 기준선입니다.

초보자를 위한 최소 판단 순서

이제 정말 실전적으로, 어떤 순서로 판단하면 좋은지 정리해 보겠습니다. 앞으로 llama.cpp로 구현할 때도 이 순서를 기본 틀로 삼으면 됩니다.

1. 먼저 사용 목적을 한 문장으로 적습니다. 예를 들어 "사내 문서를 요약하는 로컬 도구"처럼 분명하게 적습니다.

2. 그다음 허용 가능한 속도를 정합니다. 답이 1초 안에 시작되어야 하는지, 몇 초 기다려도 되는지 먼저 정합니다.

3. 내 기기의 RAM과 저장공간, 전원 환경을 확인합니다. 특히 노트북과 모바일은 배터리 사용 조건을 따로 생각해야 합니다.

4. 모델은 욕심보다 예산에 맞춰 고릅니다. 여기서 예산은 돈이 아니라 메모리, 발열, 속도 예산입니다.

5. 가장 작은 실용 모델부터 시험합니다. 처음부터 큰 모델로 시작하면 실패 원인을 파악하기 어렵습니다.

6. 짧은 테스트가 아니라 실제 사용 흐름으로 점검합니다. 긴 문서, 반복 질의, 여러 차례 실행 상황까지 봐야 합니다.

7. 마지막으로 프라이버시와 저장 정책을 확인합니다. 채팅 기록, 로그, 임시 파일 처리 방식까지 같이 봅니다.

이 순서대로 가면 적어도 "왜 안 되는지 모르는 실패"는 크게 줄일 수 있습니다.

정리: 온디바이스 구축은 하드웨어와 협상하는 일이다

온디바이스 LLM은 멋집니다. 내 기기에서 직접 돌아가고, 네트워크에 덜 의존하며, 프라이버시 측면에서도 유리한 선택지가 될 수 있습니다. 하지만 그 출발점은 낭만이 아니라 현실입니다.

메모리는 항상 넉넉하지 않습니다. 저장공간은 생각보다 빨리 줄어듭니다. 속도는 모델 크기와 함께 쉽게 느려집니다. 배터리와 발열은 성능을 다시 깎아먹습니다. 프라이버시는 자동 완성이 아니라 별도 설계 과제입니다.

그래서 실패 없는 구축의 핵심은 단순합니다.

좋은 온디바이스 프로젝트는 큰 모델을 고르는 데서 시작하지 않는다. 내 기기의 한계를 정확히 인정하는 데서 시작한다.

다음 장에서는 이 현실 위에서, 왜 많은 실전 프로젝트가 llama.cpp와 GGUF를 중심으로 움직이는지 한눈에 정리해 보겠습니다. 제약을 이해하고 나면, 그 생태계가 왜 그렇게 사랑받는지도 훨씬 또렷하게 보이기 시작합니다.