개발수양록

LLM에 정보를 전달하는 계층 — 분류와 회색지대

LLM에 정보를 주입하는 방법을 모델 레이어와 프롬프트 레이어로 나누어 보고, 그 사이의 회색지대와 RAG도 이 분류에서 어디에 놓이는지 정리해봅니다.

LLM에 정보를 전달하는 방법을 정리할 때 저는 보통 모델 가중치 vs. 프롬프트라는 2계층으로 나눠서 생각해 왔습니다. "파라미터에 정보를 새기는가, 컨텍스트에 정보를 띄우는가"라는 구분입니다. 최근 몇 년 사이에 그 사이를 비집고 들어온 기법들도 많아졌습니다.

1. 모델 레이어 — 파라미터에 정보를 새기는 방법

가중치 자체를 변경하거나, 가중치에 준하는 영구적 상태를 만드는 방식입니다.

  • Pre-training: 가장 근본적인 정보 주입. 코퍼스의 분포 자체가 모델의 세계관이 됩니다.

  • Continued pre-training (도메인 적응): 의료/법률/코드처럼 특정 도메인 코퍼스로 추가 학습. 파인튜닝보다 더 광범위한 분포 이동을 노립니다.

  • Supervised fine-tuning (SFT): 입출력 페어로 행동을 맞춥니다. 지식 주입보다는 형식/스타일/태스크 수행 능력에 더 효과적입니다.

  • 선호 학습 (RLHF, DPO, KTO, IPO 등): "어떤 응답이 더 나은가"라는 정보를 가중치에 새깁니다. 사실 지식이 아니라 가치/취향을 주입한다는 점에서 결이 다릅니다.

  • Model editing (ROME, MEMIT, MEND 등): 특정 사실 하나를 가중치 차원에서 직접 수정. "에펠탑은 로마에 있다"로 바꾸는 수술 같은 기법입니다. 본격적인 학습이 아니어서 회색지대로 보는 시각도 있습니다.

  • Knowledge distillation: 큰 모델의 지식을 작은 모델의 가중치로 압축.

  • Merging (TIES, DARE, SLERP 등): 여러 파인튜닝 결과의 가중치를 평균/합성. 학습 없이 "정보를 섞는다"는 점에서 새로운 결입니다.

2. 프롬프트 레이어 — 컨텍스트에 정보를 띄우는 방법

추론 시점에 컨텍스트 윈도우로 들어가는 모든 것. 가중치는 손대지 않습니다.

  • 시스템 프롬프트 / 페르소나 지시

  • Few-shot 예시 (in-context learning)

  • Chain-of-Thought, ReAct, self-consistency 같은 reasoning 패턴 유도

  • Tool use / function calling의 결과를 컨텍스트로 되먹임

  • RAG로 검색해 온 문서 청크

  • 외부 메모리 시스템에서 불러온 과거 대화 (Claude의 memory 같은 것)

  • 구조화된 출력 강제 (스키마, XML 태그)

  • MCP/connector를 통해 들어오는 외부 데이터

이 모두의 공통점은 inference time에 토큰으로 입력된다는 것입니다. 모델 입장에서 보면 출처를 구분할 방법이 없습니다.

3. 회색지대

PEFT 계열 (LoRA, QLoRA, adapters, prefix tuning, prompt tuning, P-tuning): 형식상 가중치를 학습시키니 모델 레이어 같지만, 베이스 모델은 그대로 두고 작은 어댑터만 붙였다 뗐다 합니다. 특히 prefix tuning / prompt tuning은 학습 가능한 "가상 토큰"을 컨텍스트 앞에 붙이는 방식이라, 소프트 프롬프트(soft prompt)라는 이름이 붙을 정도로 프롬프트 레이어의 사촌에 가깝습니다.

KV cache 주입 / cache steering: 특정 컨텍스트로 만든 KV cache를 저장해 두고 추론 시 재사용. 매번 프롬프트로 넣지 않지만, 효과는 프롬프트와 동일합니다. 캐싱은 비용 최적화이지만, "캐시된 페르소나"처럼 쓰기 시작하면 준영구적 상태가 됩니다.

Activation steering / representation engineering: 추론 중 특정 레이어의 활성값에 벡터를 더해 행동을 바꾸는 기법. 가중치도 안 바꾸고 프롬프트도 안 바꿉니다. 완전히 새로운 결입니다.

Decoding 제어 (constrained decoding, logit bias, guided generation, speculative decoding): 출력 확률 분포를 직접 조작. 정보를 "주입"한다기보다 출력을 제한하지만, 도메인 지식을 grammar 형태로 강제하면 사실상 정보 주입이 됩니다.

Tool use의 양면성: 도구 호출 자체는 프롬프트 레이어지만, 도구가 외부 세계의 상태를 바꾼다면 "정보를 LLM에 주는 것"이 아니라 "LLM이 정보를 만들어내는 것"입니다. 이 경계도 모호합니다.

4. 두 레이어 외에 추가로 생각해볼 만한 축

위의 2계층 분류는 정보가 어디에 저장되는가를 기준으로 한 것입니다. 다른 축으로도 분류할 수 있습니다.

아키텍처 레이어: 모델 구조 자체. MoE로 전문가를 분리하거나, retrieval head를 내장하거나(REALM, RETRO), 메모리 토큰 슬롯을 두는 식. 가중치 학습 이전에 "어떤 형태로 정보를 담을 것인가"를 결정합니다.

표현 / 활성값 레이어: 앞에서 언급한 activation steering, probing, representation engineering. 가중치도 컨텍스트도 아닌, forward pass 중간 상태에 개입합니다.

디코딩 / 샘플링 레이어: temperature, top-p, constrained decoding, beam search. 정보 주입보다는 정보 추출 방식의 제어지만, 모델이 "무엇을 말할 수 있는가"를 좌우합니다.

오케스트레이션 / 에이전트 레이어: 여러 LLM 호출을 엮는 외부 통제 흐름. 단일 추론 안에서는 안 보이지만 시스템 전체 동작을 결정합니다. 멀티 에이전트, 워크플로우, planner-executor 패턴 등.

5. RAG는 어느 레이어인가

RAG는 결국 프롬프트 레이어에 데이터를 공급하는 장치입니다. 검색해 온 청크는 결국 컨텍스트에 토큰으로 들어갑니다. 그리고 이 관점이 실용적으로도 가치가 있는 이유는, RAG의 한계가 곧 프롬프트 레이어의 한계(컨텍스트 윈도우, 어텐션의 long-range 약점, 토큰 비용, "lost in the middle")로 환원되기 때문입니다.

다만 RAG를 별개의 레이어로 분리하는 시각에도 일리가 있습니다. 이유는 두 가지입니다.

  1. 시스템 구성요소가 훨씬 많음. 임베딩 모델, 벡터 DB, 청킹 전략, 재순위 모델, 쿼리 재작성. 이것은 프롬프트 엔지니어링의 디테일과는 결이 다른, 검색 시스템 설계의 영역입니다.

  2. 모델과 무관하게 진화함. 베이스 LLM이 그대로여도 RAG 파이프라인만 개선해 성능을 끌어올릴 수 있습니다. 독립적인 최적화 표면이 있다는 뜻이고, 별도 레이어로 다룰 실용적 이유가 됩니다.

RAG는 개념적으로는 프롬프트 레이어의 하위 범주이지만 실무적으로는 독립된 서브시스템으로 볼 수 있습니다. 즉 "LLM에 정보가 들어가는 경로"를 논할 때는 프롬프트 레이어로 묶고, "이 RAG 파이프라인을 어떻게 개선할까"를 논할 때는 별도 레이어로 다루는 식입니다. 세상에 있는 데이터 → 검색/필터링 → 프롬프트 윈도우라는 흐름에서, 앞단(검색/필터링)이 충분히 복잡해서 별도의 시스템으로 구성됩니다.

같은 논리로, memory 시스템, MCP, tool use 결과 통합도 모두 "프롬프트 레이어로 흘러드는 데이터 파이프라인"이라는 같은 범주에 속합니다. 이들을 묶어서 컨텍스트 공급 레이어(context provisioning layer) 같은 이름을 붙이면, 처음의 2계층이 자연스럽게 3계층으로 확장됩니다.

  1. 모델 레이어 (파라미터)

  2. 컨텍스트 공급 레이어 (RAG, 메모리, 도구, 커넥터)

  3. 프롬프트 레이어 (실제로 컨텍스트에 들어간 토큰들의 구성과 배치)

여기에 회색지대(PEFT, activation steering)와 아키텍처/디코딩 축까지 보태면, 처음의 단순한 2계층 지도가 더 풍부하게 세분화됩니다.

이 포스트는 Claude(claude.ai)와 정상혁이 함께 작성했습니다.

Hermes와 Modal로 AI agent 챗봇을 0원에 운영하기