컨텍스트 엔지니어링
Context Engineering
컨텍스트 엔지니어링이란?
- LLM에 줄 '맥락'을 설계·공급
- 프롬프트를 넘어 무슨 정보를 어떻게
- RAG·에이전트 품질 좌우
컨텍스트 엔지니어링이 들어오면 'AI가 답을 못 한다'는 문제의 수사 대상이 바뀝니다. 예전에는 질문 문장을 다듬었다면, 이제는 모델 앞에 놓인 정보의 흐름 — 어떤 문서가 검색됐고, 어디서 잘렸고, 이전 대화가 무엇을 밀어냈는지 — 를 뜯어봅니다. 틀린 답의 원인은 대개 모델이 아니라 공급된 재료에 있고, 그래서 담당자의 일이 문장 다듬기에서 정보 파이프라인 설계로 옮겨갑니다.
구성 요소는 보통 네 층입니다. 시스템 지침, 검색된 문서(RAG), 대화 이력, 도구·DB 호출 결과. 최근 모델은 12만~20만 토큰까지 받지만 창 중간에 놓인 정보는 앞뒤보다 참조율이 눈에 띄게 떨어져서, 핵심 근거는 맨 앞이나 맨 뒤에 배치하는 것이 실무 관행입니다. 파인튜닝과의 경계도 분명합니다. 말투와 출력 형식이 문제라면 파인튜닝이고, 사실과 최신성이 문제라면 컨텍스트 쪽입니다.
설계의 핵심은 '넣을 것'보다 '안 넣을 것'의 규칙입니다. 문서를 500~1,000자 단위로 쪼개 상위 3~5개만 올리고, 개정일이 지난 문서는 검색 대상에서 빼고, 20턴 넘은 대화는 요약본으로 갈아 끼우는 식입니다. 같은 질문에 같은 모델이라도 이 규칙에서 정답률이 갈립니다. 답변에 출처 파일명과 갱신일을 함께 붙여두면 오답이 났을 때 검색이 틀렸는지 모델이 틀렸는지 바로 갈라낼 수 있습니다.
가장 흔한 오해는 '창이 커졌으니 다 넣으면 된다'는 생각입니다. 규정집 300페이지를 통째로 붙이면 폐지된 조항과 올해 개정안이 나란히 들어가고, 모델은 둘 중 아무거나 골라 답합니다. 근거처럼 보이는 틀린 답이 그렇게 나옵니다. 여기에 토큰 비용과 응답 지연이 몇 배로 붙고, 대화가 길어질수록 초반 지침이 이력에 밀려 희석됩니다. 넣는 설계만큼 버리는 설계가 중요합니다.
프롬프트 엔지니어링과 RAG·에이전트의 발전 속에서 부상한 개념으로, LLM 실무 고도화와 함께 강조되고 있습니다.
가상의 사례로 살펴보겠습니다. 연매출 1,800억 원, 임직원 240명 규모의 건자재 유통사 A사는 사내 규정과 제품 단가표를 묻는 QA 봇을 6개월째 돌리고 있었습니다. 그런데 영업팀이 봇 답변대로 견적을 냈다가 단가가 틀려 재발행한 건이 한 달에 열 건 넘게 나왔습니다. 'GPT를 더 좋은 모델로 바꾸자'는 말이 나왔지만 원인은 다른 데 있었습니다.
- IT팀 김 과장이 오답 80건을 뽑아 분류해 보니 절반 가까이가 2년 전 폐지된 단가표를 근거로 들고 있었습니다. 회의에서 '모델이 아니라 창고가 문제였네요'라는 말이 나왔습니다.
- 먼저 문서 저장소부터 정리했습니다. 3,200개 파일 중 개정일 표기가 아예 없는 1,100개를 걷어내고, 남은 파일에 '유효/폐지' 태그와 갱신일을 붙였습니다.
- 검색 설정을 손봤습니다. 청크를 800자로 자르고 질문당 상위 5개만 올리되, 폐지 태그가 붙은 문서는 검색 대상에서 아예 제외하도록 필터를 걸었습니다.
- 영업본부 이 부장이 '답은 그럴듯한데 어느 문서에서 나온 건지 모르겠다'고 해서, 답변 하단에 출처 파일명과 갱신일이 찍히도록 프롬프트 템플릿을 고쳤습니다.
- 6주 뒤 같은 100문항으로 재측정하니 오답률이 34%에서 9%로 떨어졌고, 호출당 평균 토큰이 1만 8천에서 6천으로 줄어 월 API 비용이 3분의 1 수준이 됐습니다.