왜 원리 설명에 이렇게 많은 시간을 쓰는 걸까요?
도구를 갈아야 작업이 빨라집니다 · 탄탄한 기초가 실제 엔지니어링의 출발점입니다
AI 엔지니어링의 모든 작업은 본질적으로 컨텍스트를 효율적으로 처리하는 것입니다
Prompt Engineering이든 RAG든 Fine-tuning이든 Agent 도구 호출이든, 모든 기법은 결국 이 message list를 처리하는 것을 중심으로 돌아갑니다. 이것을 이해해야 솔루션의 좋고 나쁨과 문제의 원인을 진정으로 판단할 수 있습니다.
Prompt Engineering
messages를 정교하게 구성해 모델이 올바른 컨텍스트를 보도록 합니다. 시스템 지시, 역할 정의, few-shot 예시 모두 message list에 내용을 채워 넣는 작업입니다.
RAG (검색 증강 생성)
외부 지식 베이스에서 관련 문서 조각을 가져와 message list에 추가한 뒤 모델에 전달합니다. 본질은 런타임에 컨텍스트를 확장하는 것입니다.
Agent 도구 호출
모델이 function call 출력 → 도구 실행 → 결과를 message list에 append → 재추론. 매 라운드마다 컨텍스트가 축적됩니다.
Fine-tuning / SFT
이상적인 message list 대량을 모델 가중치에 굽혀 넣어, 모델이 기본적으로 원하는 방식으로 컨텍스트를 처리하게 합니다. 매번 Prompt에 설명하는 비용을 줄일 수 있습니다.
"Prompt를 수정해도 소용없어요"
System Prompt가 잘리거나 대화 기록이 창을 가득 채운 것입니다. 문제의 근본 원인은 컨텍스트 관리에 있으며, Prompt 작성 품질과는 무관합니다.
"RAG 성능이 나쁜데 어느 단계가 문제인지 모르겠어요"
Chunking 단위, Embedding 모델, 유사도 임계값 — 원리를 모르면 어디를 확인해야 할지 알 수 없어 무작정 시도할 수밖에 없습니다.
"모델이 틀렸는데, Prompt를 고쳐야 할까요 아니면 Fine-tune을 해야 할까요?"
컨텍스트가 잘못 제공된 건지, 아니면 가중치에 해당 지식 자체가 없는 건지? 두 경우의 수정 방법은 완전히 다르며, 방향을 잘못 잡으면 엄청난 시간을 낭비합니다.
이 부분은 상당한 분량을 할애해 설명할 예정이며, 건너뛰지 않으시길 강력히 권장합니다.
message list의 처리 로직을 이해하면, 이후의 모든 엔지니어링 솔루션이 무엇을 하고 있는지, 왜 효과적인지, 한계가 어디인지를 한눈에 꿰뚫어볼 수 있습니다.