모델 커스터마이징 개요

방금 보신 것처럼 LLM은 확률적으로 토큰을 고르는 기계라서, 태생적인 한계가 있습니다. 다행인 건 환각, 지식 단절, 비용, 보안 네 가지 모두 검증된 대응 패턴이 있다는 겁니다. 그리고 그 대응의 대부분은 모델 가중치를 건드리지 않습니다. 프롬프트, 컨텍스트, RAG, 그리고 에이전트까지 — 가중치를 바꾸지 않는 네 단계에서 대부분의 사용 사례가 해결됩니다.

왼쪽이 문제, 오른쪽이 처방입니다. 환각은 버그가 아니라 확률적 토큰 생성이라는 동작 방식 자체에서 나오고, 그래서 근거를 주입하는 RAG와 응답을 검증하는 Guardrails로 대응합니다. 지식 단절에는 RAG에 실시간 웹 검색을 더하고, 비용에는 캐싱·라우팅·배치 — 앞에서 본 KV Cache 원리가 Prompt Caching의 90% 할인으로 이어지는 거고요. 보안과 편향은 Guardrails 필터군입니다. 네 가지 모두 원인이 모델 안에 있어서 재학습으로 고치는 게 아니라 모델 밖 아키텍처로 풉니다. 새 요구사항이 나오면 어느 한계인지부터 분류해 보세요. 서비스 조합은 따라옵니다.

커스터마이징은 이 계단 순서대로 올라가시면 됩니다. 프롬프트를 다듬고, 컨텍스트를 설계하고, RAG로 외부 지식을 주입하고, 에이전트로 도구와 루프를 붙이는 4단계까지는 모델 가중치를 전혀 건드리지 않습니다. 주석에 있듯 대부분 여기까지로 충분하고, 2026년 기준으로는 에이전트까지가 표준 구간이 됐죠. 파인튜닝과 멀티턴 강화학습부터가 가중치를 바꾸는 진짜 투자 구간입니다. 아래 단계로 안 되는 걸 확인한 뒤에 올라가는 게 비용을 아끼는 순서입니다.

갈림길에서 던질 질문은 하나입니다. 모델 자체를 바꿔야 하는가. 응답 포맷이나 정확도 문제라면 왼쪽, 프롬프트와 RAG로 충분합니다. 도메인 말투나 전문성을 모델에 내재화해야 하거나 에이전트의 멀티스텝 판단력 자체를 키워야 할 때만 오른쪽 가중치 변경으로 갑니다. 오른쪽은 데이터와 비용과 시간이 전부 들어가는 길이니까, 왼쪽으로 안 된다는 증거를 먼저 확보하시길 권합니다.