왜 이런 시도를 할까요
요즘 LLM API 비용이 만만치 않죠. 특히 시스템 프롬프트가 큰 서비스는 더 그래요. 시스템 프롬프트(preprompt)가 뭐냐면, 사용자 질문 앞에 매번 붙여서 보내는 '지시사항 덩어리'예요. '너는 이런 역할이고, 이런 규칙을 지키고, 이런 형식으로 답해'를 적어둔 거죠. 이게 35KB면 대략 9천에서 1만 토큰 정도 되는데, 요청 한 번마다 이만큼을 API로 보내야 해요. 하루 수만 건이면 비용이 꽤 나오죠.
그래서 '이걸 자체 서버에서 오픈 모델로 돌리면 어떨까?'라는 생각을 하게 되는데요. Patrick McCanna라는 개발자가 실제로 Claude Opus에서 쓰던 35KB짜리 프롬프트를 Ollama로 옮기면서 겪은 함정들을 정리했어요. Ollama가 뭐냐면, Llama, Qwen, Gemma 같은 오픈 모델을 내 컴퓨터나 서버에서 명령어 한 줄로 돌릴 수 있게 해주는 도구예요. 결론부터 말하면 '되긴 되는데, 그냥 되진 않는다'예요.
함정 1: 프롬프트가 조용히 잘려나가요
가장 큰 함정이자, 많은 사람이 모르고 넘어가는 문제예요. Ollama는 기본 컨텍스트 길이(num_ctx)가 짧게 설정돼 있어요. 컨텍스트 길이가 뭐냐면, 모델이 한 번에 '볼 수 있는' 토큰의 최대 개수예요. 버전에 따라 2048이나 4096 토큰이 기본값인데, 35KB 프롬프트는 이걸 훌쩍 넘어요.
문제는 넘쳤을 때 에러가 나는 게 아니라, 앞부분을 조용히 잘라버린다는 거예요. 그러니까 시스템 프롬프트의 핵심 지시가 통째로 사라진 채로 모델이 답을 하는데, 서버 로그엔 아무 경고도 안 떠요. '왜 모델이 규칙을 하나도 안 지키지?' 하고 한참 헤매다가 겨우 원인을 찾게 되는 유형의 버그예요.
해결법은 요청할 때 옵션으로 num_ctx를 충분히 크게 주거나, Modelfile에 PARAMETER num_ctx 32768처럼 명시하거나, OLLAMA_CONTEXT_LENGTH 환경변수를 설정하는 거예요. 그런데 이걸 올리면 다음 함정이 기다려요.
함정 2: 메모리가 폭발해요
컨텍스트를 늘리면 KV 캐시라는 게 커져요. KV 캐시가 뭐냐면, 모델이 앞에서 읽은 토큰들을 다시 계산하지 않으려고 저장해두는 작업 메모리예요. 이게 컨텍스트 길이에 비례해서 커지거든요. 8B 모델에서 32K 컨텍스트로 올리면 모델 가중치 외에 수 GB의 VRAM이 추가로 필요해요. 70B급 모델이면 GPU 한 장으로는 어림도 없죠.
그리고 동시 요청 수(num_parallel)를 늘리면 이 KV 캐시가 요청 수만큼 곱해져요. Opus API 쓸 땐 '동시 접속 몇 명까지 되나' 고민할 필요가 없었는데, 자체 호스팅에선 이게 곧바로 하드웨어 예산 문제가 돼요.
함정 3: 프롬프트 캐싱이 없어요
Anthropic API에는 프롬프트 캐싱 기능이 있어요. 매번 똑같이 붙는 35KB 시스템 프롬프트를 서버 쪽에서 캐시해두고, 다음 요청부터는 그 부분 처리 비용을 대폭 깎아주는 거예요. 자체 호스팅으로 오면 이걸 직접 챙겨야 해요. Ollama가 직전 요청과 앞부분이 같으면 KV 캐시를 재활용하긴 하지만, 여러 사용자가 다른 대화를 섞어서 보내면 금방 무효화돼요. 결과적으로 요청마다 1만 토큰을 새로 읽는(prefill) 시간이 붙고, 이게 첫 글자가 나올 때까지의 지연으로 사용자에게 그대로 느껴져요.
함정 4: 작은 모델은 긴 지시를 잘 못 따라요
이건 설정이 아니라 모델 자체의 한계예요. Opus 같은 최상위 모델은 규칙 50개짜리 프롬프트를 주면 대부분 지켜요. 그런데 8B, 14B급 오픈 모델은 긴 프롬프트 중간에 있는 지시를 흘려버리는 경향이 있어요. 소위 '중간에서 길을 잃는(lost in the middle)' 현상이에요.
그래서 프롬프트를 그대로 옮기는 게 아니라 다시 설계해야 해요. 정말 중요한 규칙은 프롬프트 맨 끝, 사용자 입력 직전으로 옮기고, 한 번에 다 시키지 말고 여러 단계로 쪼개고, 예시를 줄여서 전체 길이를 압축하는 식으로요. 여기에 양자화(quantization) 문제도 있어요. 양자화가 뭐냐면, 모델을 작은 메모리에 넣으려고 숫자 정밀도를 낮추는 건데, Q4 같은 강한 양자화는 복잡한 지시를 따르는 능력을 눈에 띄게 떨어뜨려요. 메모리가 허락한다면 Q8이나 FP16으로 먼저 테스트해보는 게 좋아요.
함정 5: 채팅 템플릿과 출력 형식
모델마다 시스템 프롬프트를 다루는 방식이 달라요. 어떤 모델은 system 역할을 제대로 지원하고, 어떤 모델은 그냥 사용자 메시지 앞에 붙여버려요. Ollama가 모델별 템플릿을 알아서 적용해주긴 하지만, 그 결과가 Claude에서 보던 것과 같을 거라고 기대하면 안 돼요. JSON 출력도 마찬가지예요. Claude는 '반드시 JSON으로만 답해'라고 하면 잘 지키는데, 오픈 모델은 앞뒤에 설명을 붙이거나 코드블록으로 감싸는 경우가 많아요. Ollama의 format 옵션으로 JSON 스키마를 강제하는 게 훨씬 안전해요.
한국 개발자에게 주는 시사점
API 비용 절감이나 데이터를 외부로 보낼 수 없는 규제 환경(금융, 의료, 공공) 때문에 자체 호스팅을 검토하는 팀이 한국에도 많아요. 이 글이 주는 교훈은, 마이그레이션이 '엔드포인트 URL만 바꾸기'가 절대 아니라는 거예요. 프롬프트 재설계, 하드웨어 산정, 평가 셋 구축까지 하나의 프로젝트로 봐야 해요.
특히 옮기기 전에 평가 셋(eval set) 부터 만들어두세요. Opus로 나온 결과물 수백 건을 정답 기준으로 저장해두고, 오픈 모델 결과와 자동으로 비교하는 스크립트를 짜두면 어떤 규칙이 깨졌는지 바로 보여요. 이게 없으면 '느낌상 좀 이상한데' 수준에서 헤매게 돼요.
마무리
한 줄로 정리하면, 자체 호스팅 전환의 진짜 비용은 GPU가 아니라 조용히 잘리는 컨텍스트, 사라진 캐싱, 그리고 프롬프트 재설계에 들어가는 시간이에요. 여러분은 자체 호스팅 LLM을 실무에 써보셨나요? 어느 정도 크기의 모델부터 상용 API를 대체할 만하다고 느끼셨는지 궁금해요.
🔗 출처: Hacker News