11. 실전 적용: 모델 선택부터 파이프라인까지
LLM을 실무에 적용하는 전략. 프롬프트 설계, RAG vs 파인튜닝 선택 기준, 계층형 파이프라인, 컨텍스트 윈도우 관리.
10편까지 LLM의 내부 동작을 전부 다뤘다. 토크나이저부터 어텐션, FFN, KV 캐시, 학습, 하드웨어, 양자화까지. 이번 편에서는 이걸 실무에 어떻게 적용하는지 다룬다.
하드웨어별 모델 선택
일단 내 GPU에서 뭘 돌릴 수 있는지부터 정리한다.
GPU VRAM 쾌적 범위 추천 모델
---------------- ----- --------------- ---------------------
GTX 1060 6GB 6GB ~3B (7B Q4 빠듯) Qwen2.5:3b, Llama 3.2 3B
Mac Mini M4 16GB 16GB ~14B Qwen2.5:14b, Llama 3.1 8B
Mac Mini M4 Pro 24GB ~32B Q4 Qwen2.5:32b
RTX 4090 24GB ~32B Q4 Qwen2.5:32b9편에서 VRAM 계산법을 배웠으니 직접 판단할 수 있다. 파라미터 크기 + KV 캐시 + 오버헤드가 VRAM 안에 들어오면 된다.
컨텍스트 윈도우 vs 실효 이해 범위
스펙상 128K 토큰을 지원한다고 해도, 진짜 128K를 "이해"하는 건 아니다.
스펙상 실효 이해 범위 직관적으로
모델 크기 컨텍스트 (복합 추론 기준)
-------------- -------- -------------- ----------
~3B 128K ~2K~4K 토큰 30~50줄
~7B 128K ~4K~8K 토큰 80~150줄
~14B 128K ~8K~16K 토큰 200~400줄
~32B 128K ~16K~32K 토큰 A4 10~20장
입력 최적화가 모델 크기를 키우는 것보다 효과적일 때가 많음.
10만 줄 로그 통째로 < grep으로 관련 로그만 추출해서 실효 범위 안에 넣기.이건 직접 돌려보면 체감된다. 3B 모델에 로그 500줄을 넣으면 앞부분만 분석하고 뒷부분은 무시하거나 횡설수설한다. grep으로 관련 로그 50줄만 추출해서 넣으면 훨씬 정확하다.
프롬프트 설계 — 어텐션 구조를 알면 보이는 것들
어텐션의 동작 원리를 알면 프롬프트를 어떻게 써야 효과적인지가 보인다.
-- 정보 배치 --
X 나쁜 예:
"[5000줄 로그]. 특히 OOM 관련 에러를 찾아줘."
-> 핵심 지시가 맨 뒤. 작은 모델은 지시를 약하게 받아들임.
O 좋은 예:
"다음 로그에서 OOM 관련 에러를 찾아서 원인과 조치를 알려줘.
[로그]"
-> 지시 앞, 데이터 뒤. 모든 로그 토큰이 지시를 어텐션으로 참조 가능.
-- Lost in the Middle --
긴 입력의 앞과 뒤는 잘 기억, 중간은 약해지는 경향.
-> 가장 중요한 정보는 앞이나 뒤에 배치.
-- Few-shot --
예시를 주면 FFN이 "이 형식으로 답해야 하는구나"를 더 잘 활성화.
"로그를 분석해서 아래 형식으로 답해줘:
원인: ...
영향: ...
조치: ...
예시:
로그: [WARN] disk usage 95%
원인: 디스크 용량 부족
영향: 신규 로그 기록 불가
조치: 오래된 로그 정리, 디스크 증설
분석할 로그:
[ERROR] OOM killer invoked, process nginx killed"지시를 앞에, 데이터를 뒤에 배치하는 건 어텐션의 인과적 마스킹 때문이다. 뒤에 있는 토큰이 앞의 지시를 참조할 수 있어야 하니까. 반대로 하면 지시 토큰이 로그 데이터를 참조할 수 없다.
파인튜닝 vs RAG — 어떤 걸 먼저 시도해야 하는가
-- 파인튜닝 (W 자체를 수정) --
기존 W -> 우리 데이터로 추가 학습 -> 수정된 W
LoRA: 전체 W를 건드리지 않고 작은 행렬(rank 4~64)만 추가 학습.
원래 W (고정) + deltaW (학습) = 최종 출력
deltaW 크기: 전체 파라미터의 0.1~1%
-> 로컬에서도 학습 가능.
적합: 출력 형식/스타일 변경, 특정 태스크 특화.
한계: 학습 데이터 준비 필요, 지식 업데이트 어려움.
-- RAG (Retrieval-Augmented Generation) --
질문 -> 벡터 DB에서 관련 문서 검색 -> 프롬프트에 삽입 -> 모델 추론
[1] 사전 준비: 회사 런북/SOP를 임베딩해서 벡터 DB에 저장
[2] 질문이 오면: 질문을 벡터화 -> 유사 문서 검색
[3] 검색된 문서를 프롬프트에 삽입:
"다음 문서를 참고해서 답해줘: [런북]. 질문: OOM 발생 시..."
[4] 모델이 문서를 참조해서 답변 생성
적합: 내부 문서 기반 Q&A, 최신 정보, 출처 추적.
한계: 검색 품질 의존, 컨텍스트 길이 제한.비교하면 이렇다.
파인튜닝 RAG
--------------- -------------- --------------
지식 위치 W에 인코딩 프롬프트에 삽입
업데이트 재학습 필요 문서만 교체
할루시네이션 여전히 가능 출처 있어서 감소
준비 비용 학습 데이터+GPU 벡터 DB 구축
추론 비용 동일 검색 + 긴 프롬프트대부분의 실무 시나리오에서는 RAG를 먼저 시도하는 게 맞다. 모델의 W를 건드리는 파인튜닝은 준비 비용이 크고, 잘못하면 기존 능력을 망가뜨릴 수 있다. 그런데 RAG가 만능일까? 검색 품질이 나쁘면 엉뚱한 문서를 참조해서 오히려 더 틀린 답을 낼 수도 있다. RAG의 성능은 결국 검색 품질에 달려 있다. 회사 런북이나 장애 대응 매뉴얼을 벡터 DB에 넣고, 질문이 올 때 관련 문서를 검색해서 프롬프트에 삽입하는 방식이다. RAG로 부족할 때 파인튜닝을 추가한다.
대화가 길어지면 — 컨텍스트 윈도우 관리
시스템 프롬프트: 500 토큰
대화 1턴: 200 토큰
대화 2턴: 300 토큰
...
대화 50턴: 총 15,000 토큰 <- 아직 괜찮음
대화 500턴: 총 150,000 토큰 <- 128K 초과!
-- 해결 방법 --
[1] 슬라이딩 윈도우: 오래된 대화를 잘라냄.
-> 앞부분 맥락 유실.
[2] 요약 후 삽입: 이전 대화를 요약해서 시스템 프롬프트에.
"이전 대화 요약: 사용자가 OOM 로그 분석을 요청했고..."
-> 맥락 보존 + 토큰 절약.
[3] RAG와 결합: 이전 대화를 벡터 DB에 저장, 필요한 것만 검색.슬라이딩 윈도우가 가장 단순하지만 앞부분 맥락이 유실된다. 요약 후 삽입이 실무에서 가장 효과적이다. 이전 대화를 작은 모델로 요약하고, 그 요약을 시스템 프롬프트에 넣는 방식이다.
계층형 파이프라인
모델 하나로 모든 걸 해결하려고 하지 말자. 작은 모델로 1차 필터링하고 큰 모델로 2차 분석하는 구조가 비용 대비 효과적이다. 이건 한번 구성해보면 "왜 진작 이렇게 안 했지?" 싶을 거다.
+---------------------------------------------------+
| 로그 스트림 |
+-------------------------+-------------------------+
|
v
+-----------------+
| 3B 모델 | 빠르고 가벼움
| 비정상 패턴 감지 | 초당 ~30토큰
| (단순 분류) |
+--------+--------+
| 이상 감지된 로그만 전달
v
+-----------------+
| 14B 모델 | 느리지만 깊이 있음
| 원인 분석 | 초당 ~10토큰
| 조치 제안 |
+-----------------+전체 로그를 14B에 넣으면 느리고 비싸다. 3B로 1차 필터링해서 이상 로그만 추출하고, 그것만 14B에 넣으면 된다.
모델 내부를 아는 것의 실무적 가치
지금까지 시리즈에서 배운 것들이 실무에서 어떤 판단을 가능하게 하는지 정리한다.
알게 된 것 실무에서 할 수 있는 판단
-------------------------- ------------------------------
어텐션의 인과적 마스킹 -> 프롬프트에서 지시를 어디에 배치할지
FFN이 지식 저장소 -> 도메인 지식이 필요하면 큰 모델 or RAG
KV 캐시가 누적 -> 입력 길이와 VRAM 사용량 예측 가능
메모리 바운드 -> GPU 선택 시 코어 수보다 대역폭이 중요
양자화의 원리 -> Q4_K_M이면 충분한지 판단 가능
실효 이해 범위 != 컨텍스트 윈도우 -> 입력 최적화가 모델 업그레이드보다 효과적"OOM killer가 nginx를 종료시켰다."
이 한 문장이 토크나이저에서 5개의 정수가 되고, 임베딩 테이블에서 5개의 벡터가 되고, 36개 레이어의 어텐션과 FFN을 통과하면서 문맥과 의미를 얻고, 출력 행렬을 거쳐 "종료시켰다"라는 다음 토큰이 선택되는 전체 과정을 11편에 걸쳐 다뤘다.
LLM은 마법이 아니라 행렬곱이다. 구조를 알면 한계도 보이고, 한계를 알면 더 잘 쓸 수 있다.
이 글이 어떠셨나요?
관련 포스트
1. LLM은 텍스트를 어떻게 처리하는가
LLM이 텍스트 한 줄을 받아서 다음 토큰을 예측하기까지의 전체 과정을 4단계로 따라간다. 토크나이저, 임베딩, 트랜스포머 레이어, 출력까지 "OOM killer가 nginx를" 한 문장이 모델 안에서 겪는 여행.
2026. 03. 03. PM 10:00DevOps8. 학습: 30억 개의 숫자가 조정되는 과정
LLM의 30억 개 파라미터가 만들어지는 과정. 자기지도 학습으로 학습 데이터를 자동 생성하고, 역전파로 gradient를 구하고, 극도로 미세한 업데이트를 수조 번 반복하는 과정.
2026. 04. 21. PM 10:00DevOps7. 출력 제어: 확률에서 토큰을 고르는 방법
LLM이 확률 분포에서 토큰을 고르는 방법. temperature, top_p, top_k가 각각 뭐고 언제 쓰는지.
2026. 04. 14. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.