컨텍스트 엔지니어링이란? AI 답을 가르는 '진짜 변수'
"프롬프트만 잘 쓰면 된다"는 말, 이제는 절반만 맞습니다. AI 모델이 똑똑해질수록 결과를 가르는 건 질문을 어떻게 다듬느냐 보다 '어떤 정보를 손에 쥐여주느냐' 로 옮겨가고 있거든요. 이걸 다루는 기술이 컨텍스트 엔지니어링(Context Engineering) 입니다.
이 글에서 컨텍스트 엔지니어링이 무엇이고, 프롬프트 엔지니어링과 어떻게 다르며, 컨텍스트가 어떻게 채워지고 또 어떻게 망가지는지, 그리고 많은 글이 놓치는 '진짜 출발점' 까지 풀어봅니다.
💡 이런 고민이라면 도움이 됩니다
"프롬프트를 아무리 다듬어도 AI 답이 2% 부족 하다"
"RAG·에이전트를 붙였는데 정확도가 기대만 못하다"
"프롬프트 엔지니어링 다음에 뭘 공부해야 하지?"
컨텍스트 엔지니어링이란?
컨텍스트 엔지니어링 은 LLM이 작업을 수행하는 데 필요한 '정보 환경' 전체를 설계 하는 기술입니다. 프롬프트(지시문) 한 줄이 아니라, 모델이 답을 만들기 직전 컨텍스트 윈도우에 무엇을, 어떤 형식으로, 어떤 타이밍에 넣을지 를 다루죠.
정리해보겠습니다. 프롬프트 엔지니어링이 '무엇을 물어볼까' 라면, 컨텍스트 엔지니어링은 'AI가 어떤 정보 속에서 그 질문을 받게 할까' 입니다.
프롬프트 엔지니어링 vs 컨텍스트 엔지니어링
구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
다루는 대상 | 질문(지시문) 자체 | 모델에 들어가는 정보 환경 전체 |
핵심 질문 | "어떻게 물어볼까" | "무엇을 쥐여줄까" |
범위 | 한 번의 프롬프트 | 검색·메모리·도구·문서까지 통합 |
형태 | 정적(문장 다듬기) | 동적(상황에 맞게 실시간 구성) |
주로 쓰는 곳 | 단발성 질의응답 | RAG·AI 에이전트·업무 자동화 |
둘은 대체 관계가 아닙니다. 프롬프트 엔지니어링은 컨텍스트 엔지니어링의 일부 예요. 좋은 지시문 위에, 좋은 정보 환경을 얹는 것이죠.
컨텍스트는 무엇으로 채워지나 — 5가지 재료
LLM이 보는 컨텍스트 윈도우는 보통 이 다섯 가지로 채워집니다.
시스템 지시 : 역할·규칙·말투·출력 형식 같은 기본 설정
검색된 지식(RAG) : 사내 문서·매뉴얼·약관에서 질문에 맞는 부분만 찾아 넣은 근거
메모리·대화 이력 : 이전 대화, 사용자 프로필, 앞선 단계의 결과
도구 결과 : API·함수 호출로 가져온 실시간 값(주문 상태, 재고 등)
구조화된 문서 데이터 : 표·항목·계층이 기계가 읽을 수 있게 정리된 원본 문서
컨텍스트 엔지니어링은 이 재료들을 상황에 맞게 골라, 알맞은 형식으로, 적시에 조합하는 일입니다. RAG·도구 호출(Function Calling)·MCP·오케스트레이션 같은 기술이 모두 여기에 동원되죠.
왜 지금 컨텍스트 엔지니어링인가
모델이 똑똑해졌다: 추론 능력이 올라오면서 AI의 일이 '문장 생성'에서 '다단계 업무 수행' 으로 넓어졌습니다. 그만큼 더 많은 맥락이 필요해졌죠.
에이전트의 부상: AI 에이전트는 스스로 계획하고 도구를 쓰며 여러 단계를 밟습니다. 각 단계마다 어떤 정보를 넘겨줄지 가 성패를 가릅니다.
긴 컨텍스트의 함정: 컨텍스트 창이 길어졌다고 다 넣으면 오히려 성능이 떨어집니다. 많이가 아니라 '맞게' 넣는 설계가 핵심이 됐습니다.
컨텍스트가 망가지는 4가지 방식
컨텍스트는 '많이 넣을수록 좋은' 게 아닙니다. 잘못 채우면 오히려 답이 무너집니다.
실패 방식 | 무슨 일이 벌어지나 |
|---|---|
오염(Poisoning) | 틀린 정보·환각이 컨텍스트에 한번 들어가 계속 참조 됨 |
산만(Distraction) | 관련 없는 내용이 너무 많아 핵심 근거가 묻힘 |
혼동(Confusion) | 비슷하지만 다른 문서가 섞여 엉뚱한 값 을 끌어옴 |
충돌(Clash) | 서로 모순되는 정보가 함께 들어가 답이 흔들림 |
흥미로운 건, 이 네 가지가 대부분 '컨텍스트에 들어간 원본 데이터가 지저분할 때' 생긴다는 점입니다. 그래서 많은 글이 RAG·도구 호출을 말하지만, 정작 더 앞단을 놓칩니다.
놓치기 쉬운 출발점, 좋은 컨텍스트는 '문서 구조화'에서 시작한다
컨텍스트 엔지니어링은 흔히 RAG 검색 방식이나 도구 연동 방식의 문제로 이야기됩니다. 하지만 “무엇을 검색할 것인가”를 거슬러 올라가면, 결국 답은 기업 내부 문서에 있습니다. 계약서, 약관, 매뉴얼, 보고서, 표가 가득한 PDF와 HWP처럼 실제 업무가 쌓여 있는 문서들 말입니다.
문제는 이 문서들이 LLM이 바로 쓸 수 있는 형태가 아니라는 점입니다. PDF의 표가 한 줄로 뭉개지거나, 항목과 값의 관계가 끊기거나, 도장·서명이 텍스트로만 추출되면 — 검색은 엉뚱한 조각을 가져오고, 그 조각이 컨텍스트를 오염 시킵니다. 앞서 짚은 '혼동·오염'이 바로 여기서 출발하죠.
그래서 컨텍스트 엔지니어링의 보이지 않는 첫 단추는 '문서를 기계가 이해할 구조로 바꾸는 것' 입니다. 표는 표로, 항목은 항목-값으로, 문서의 계층은 계층대로 살려서 정리해야 검색도 정확해지고, 컨텍스트도 깨끗 해집니다.
💡이어서 읽기 좋은 글
Parser 설계가 RAG 정확도를 좌우하는 이유
RAG가 '진짜 정보'를 찾아오는 원리
컨텍스트가 더러우면 생기는 일
한국딥러닝의 관점
한국딥러닝은 컨텍스트 엔지니어링의 가장 앞단 인 '문서를 LLM이 쓸 수 있는 데이터로 만드는' 단계를 다룹니다. 문서를 읽는 DEEP OCR 과 구조를 해석하는 DEEP Parser, 그리고 이를 분류·추출·검증·연계까지 한 흐름으로 묶은 통합 플랫폼 DEEP Agent 가 그것이죠. 세 가지는 모두 DEEP Agent 안에서 함께 동작합니다.
특히 한국 기업 문서는 표가 복잡하고 HWP·세금계산서·손글씨가 섞여 있어, 구조를 살린 파싱 이 컨텍스트 품질을 크게 좌우합니다. 한국딥러닝의 문서 특화 VLM이 글로벌 문서 파싱 벤치마크(ParseBench)에서 VLM 부문 1위를 기록한 것도, 결국 '컨텍스트에 들어갈 재료를 얼마나 깨끗하게 만드느냐' 의 문제와 맞닿아 있습니다.
자주 묻는 질문 (FAQ)
Q. 컨텍스트 엔지니어링과 프롬프트 엔지니어링은 뭐가 다른가요?
A. 프롬프트 엔지니어링은 '질문(지시문)을 다듬는' 기술이고, 컨텍스트 엔지니어링은 그 질문이 놓이는 '정보 환경 전체(검색·메모리·도구·문서)를 설계하는' 더 넓은 기술입니다. 프롬프트는 그 일부예요.
Q. 컨텍스트 엔지니어링은 RAG와 같은 건가요?
A. 아닙니다. RAG는 컨텍스트를 채우는 한 가지 방법 (검색으로 근거를 가져오기)입니다. 컨텍스트 엔지니어링은 RAG·도구 호출·메모리·문서 구조화까지 아우르는 상위 개념입니다.
Q. 컨텍스트는 많이 넣을수록 좋은가요?
A. 아닙니다. 관련 없는 정보가 많으면 핵심이 묻히고(산만), 틀린 정보가 섞이면 답이 흔들립니다(오염·충돌). 많이가 아니라 맞게 넣는 게 핵심입니다.
Q. 왜 문서 구조화가 컨텍스트 엔지니어링의 출발점인가요?
A. 검색·도구가 가져오는 근거의 원천이 결국 기업 문서이기 때문입니다. 원본 문서의 표·항목이 깨진 채 들어가면 검색도 엉키고 컨텍스트도 오염됩니다. 구조를 살린 파싱이 그 앞단을 막아줍니다.
Q. 개발자가 아니어도 알아야 하나요?
A. AI 도입·기획을 한다면 알아두면 좋습니다. "왜 우리 AI는 답이 부정확할까"의 답이 모델이 아니라 컨텍스트 설계 에 있는 경우가 많기 때문입니다.
결론
컨텍스트 엔지니어링은 프롬프트 엔지니어링을 대체하는 게 아니라 감싸 안는 더 큰 기술입니다. AI가 똑똑해질수록, 결과를 가르는 건 질문 솜씨가 아니라 '어떤 정보를 어떻게 쥐여주느냐' 가 됩니다. 그리고 그 정보의 출발점에는 잘 구조화된 문서 가 있습니다.
