컨텍스트 엔지니어링은 언어 모델이 작업할 때 볼 정보를 목적에 맞게 고르고 배치하는 설계입니다. 지침, 대화 기록, 검색 자료, 메모리, 도구와 현재 상태처럼 모델 입력에 들어가는 자료를 고르고 배치하고, 필요하면 다시 갱신합니다. 한 문장의 표현을 다듬는 프롬프트 엔지니어링보다 범위가 넓습니다.
컨텍스트는 모델이 답을 만들 때 실제로 볼 수 있는 정보 전체입니다. 많이 넣는 것이 목적이 아닙니다. 지금 작업에 필요한 정보를 맞는 시점에 넣고, 오래되거나 충돌하는 정보는 빼야 합니다.
프롬프트 밖의 정보까지 다룹니다
고객 지원 AI가 환불 문의에 답한다고 해보겠습니다. 사용자 질문만 잘 쓰는 것으로는 부족합니다.
- 회사의 환불 정책 중 관련된 절
- 고객의 현재 주문 상태와 결제일
- 환불을 실행할 수 있는 도구와 권한
- 앞선 대화에서 확인한 주문번호
- 오래된 정책보다 최신 정책을 우선하는 규칙
이 정보가 한 번의 모델 호출에 어떻게 들어가는지, 다음 대화에서 무엇을 남길지, 도구 결과가 틀렸을 때 어떻게 멈출지까지 정하는 일이 컨텍스트 엔지니어링입니다.
프롬프트 엔지니어링과 RAG가 맡는 부분
프롬프트 엔지니어링은 모델에게 무엇을 어떻게 하라고 말할지 다룹니다. 역할, 목표, 제약, 출력 형식과 예시를 지시문에 적습니다.
RAG는 외부 문서에서 질문과 관련된 자료를 찾아 모델 입력에 더합니다. 검색어를 만들고 문서를 나누고 재정렬하는 과정이 들어갈 수 있습니다.
컨텍스트 엔지니어링은 두 작업을 포함하면서 더 넓게 봅니다. 어떤 도구를 보여 줄지, 과거 대화를 언제 요약할지, 메모리를 언제 불러올지, 여러 에이전트 사이에서 어떤 정보를 공유하거나 감출지도 다룹니다.
파인튜닝은 다른 작업입니다. 파인튜닝은 학습으로 모델 가중치를 바꾸고, 컨텍스트 엔지니어링은 추론할 때 넣는 정보를 바꿉니다.
긴 작업에서는 넣기보다 버리기가 중요합니다
컨텍스트 윈도우는 한도가 있습니다. 대화와 로그, 도구 결과를 계속 쌓으면 중요한 정보가 중간에 묻히거나 오래된 지시가 최신 상태와 충돌할 수 있습니다.
긴 작업을 맡긴 에이전트라면 다음 조치가 필요합니다.
- 끝난 단계의 세부 로그를 짧게 요약합니다.
- 다시 구할 수 있는 자료는 필요할 때 재검색합니다.
- 현재 목표와 결정 사항은 남기고 오래된 가설은 지웁니다.
- 상충하는 자료에는 날짜와 우선순위를 붙입니다.
- 도구 목록을 지금 단계에 필요한 것만 보여 줍니다.
모든 문서를 컨텍스트 창 끝까지 넣는 방식은 정보 선택을 포기한 것입니다. 관련 없는 자료가 많으면 비용이 늘고 모델이 중요한 근거를 놓칠 수 있습니다.
오류가 난 지점을 찾는 순서
AI가 틀린 답을 했을 때 프롬프트부터 고치면 원인을 놓칠 수 있습니다. 실제 입력과 도구 기록을 보며 순서대로 확인하세요.
- 정답에 필요한 사실이 컨텍스트에 있었는지 봅니다.
- 검색기가 맞는 문서와 문단을 찾았는지 확인합니다.
- 오래됐거나 상충하는 자료가 함께 들어갔는지 봅니다.
- 어떤 자료를 우선할지 지시가 있었는지 확인합니다.
- 도구 설명과 반환 값이 모델이 읽을 수 있는 형태였는지 봅니다.
- 긴 기록을 요약하면서 핵심 조건이 빠졌는지 확인합니다.
- 같은 입력으로 다시 실행해 오류가 반복되는지 봅니다.
자료가 없었다면 검색과 데이터 연결을 고칩니다. 자료는 있었지만 우선순위를 몰랐다면 지시와 구조를 고칩니다. 도구가 틀린 값을 줬다면 프롬프트가 아니라 도구와 검증 절차를 손봐야 합니다.
검색과 콘텐츠 실무에 닿는 범위
컨텍스트 엔지니어링은 웹페이지 순위를 높이는 SEO 기법이 아닙니다. 자체 검색형 챗봇이나 사내 RAG, AI 에이전트를 만들 때 직접 쓰는 개발 실무입니다.
다만 공개 AI 검색을 이해할 때도 도움이 됩니다. AI가 답변할 때 학습 지식만 쓰는지, 웹을 검색했는지, 연결 문서를 썼는지에 따라 답의 근거가 달라집니다. 웹 운영자는 컨텍스트 내부를 볼 수 없으므로 특정 문단 배치가 인용을 보장한다고 주장하면 안 됩니다. 실제 답변의 출처와 추천 방문을 따로 확인하세요.
자주 묻는 질문
프롬프트 엔지니어링이 끝난 용어인가요?
아닙니다. 지시문을 설계하는 일은 여전히 필요합니다. 컨텍스트 엔지니어링이 검색 자료, 메모리와 도구까지 범위를 넓힌 것입니다.
RAG를 만들면 컨텍스트 엔지니어링도 끝난 건가요?
아닙니다. RAG가 어떤 자료를 찾는지, 얼마나 넣는지, 상충하는 문서를 어떻게 다루는지와 대화 기록을 어떻게 줄이는지까지 설계해야 합니다.
MCP를 연결하면 컨텍스트 엔지니어링인가요?
연결만으로는 부족합니다. 어떤 작업에서 어떤 도구를 보여 줄지, 권한과 결과 형식, 실패 시 처리까지 정해야 실제 설계가 됩니다.
함께 알아두면 좋은 용어
- 프롬프트 엔지니어링: 모델 지시문과 예시를 설계하는 작업
- RAG: 외부 자료를 검색해 모델 입력에 더하는 방식
- 컨텍스트 윈도우: 모델이 한 요청에서 다룰 수 있는 토큰 범위
- MCP: AI와 도구, 데이터 소스를 연결하는 규격