본문 바로가기
AI2026년 7월 23일5분 읽기

컨텍스트 엔지니어링 — 프롬프트 엔지니어링 다음의 진짜 승부처

YS
김영삼
조회 4
컨텍스트 엔지니어링 — 프롬프트 엔지니어링 다음의 진짜 승부처

컨텍스트 엔지니어링(context engineering)은 모델에게 던지는 한 줄의 프롬프트를 다듬는 일이 아니라, 그 한 줄이 도착하기 직전까지 어떤 정보가, 어떤 순서로, 얼마만큼 모델의 입력에 담기는지를 설계하는 일이다. 요즘 실무에서 "프롬프트 엔지니어링은 끝났고 컨텍스트 엔지니어링이 시작됐다"는 말이 도는 이유가 여기 있다.

나는 이 표현을 처음 들었을 때 그저 유행어를 바꿔 부르는 줄 알았다. 그런데 에이전트를 몇 달 굴려보니 관점이 완전히 달라졌다. 실제로 답의 품질을 좌우한 건 프롬프트 문장의 우아함이 아니라, 그 순간 모델의 컨텍스트 창에 무엇이 들어가 있었느냐였다. 좋은 프롬프트에 엉뚱한 자료를 붙이면 엉뚱한 답이 나오고, 평범한 프롬프트라도 딱 맞는 자료가 붙으면 정확해진다.

프롬프트는 한 문장, 컨텍스트는
그 문장을 둘러싼 세계 전부다.

모델은 자기가 받은 토큰만 안다. 그래서 승부는 무엇을 넣고 무엇을 뺄지를 정하는 검색·요약·조립 단계에서 이미 갈린다.

4요소
지시·자료
기억·도구
유한토큰
컨텍스트 창은
공짜가 아니다
순서
앞·뒤 배치가
주목도를 바꾼다
동적
요청마다
새로 조립

프롬프트 엔지니어링과 무엇이 다른가

프롬프트 엔지니어링은 고정된 텍스트를 잘 쓰는 기술이다. "당신은 전문가입니다, 단계적으로 생각하세요" 같은 문장을 다듬는 일. 이건 여전히 유효하다. 다만 그건 정적이다. 반면 컨텍스트 엔지니어링은 매 요청마다 달라지는 동적인 조립이다. 사용자가 방금 뭘 물었는지, 이전 대화에서 무슨 결정을 내렸는지, 어떤 문서가 지금 질문과 관련 있는지, 어떤 도구의 결과가 방금 돌아왔는지 — 이 모든 걸 실시간으로 골라 담는다.

한 번은 챗봇이 사용자의 이전 답변을 계속 무시하는 문제로 며칠을 헤맸다. 프롬프트를 아무리 고쳐도 소용없었다. 원인은 단순했다. 대화가 길어지자 초반 맥락이 컨텍스트 창 밖으로 밀려나 있었던 것이다. 프롬프트의 문제가 아니라 컨텍스트 관리의 문제였다.

컨텍스트를 구성하는 것들

실무에서 모델 입력은 대략 이런 조각들의 조립이다.

  • 시스템 지시 — 역할, 규칙, 출력 형식. 비교적 고정적이다.
  • 검색된 자료(RAG) — 지금 질문과 관련해 벡터/키워드 검색으로 끌어온 문서 조각.
  • 대화 기억 — 이전 턴의 요약, 사용자 선호, 진행 중인 작업 상태.
  • 도구 정의와 결과 — 쓸 수 있는 함수 설명과, 방금 호출해서 받은 값.
  • 사용자의 실제 질문 — 정작 이건 전체의 작은 일부다.

이걸 다 합치면 금세 컨텍스트 창을 넘친다. 그래서 핵심 기술은 넣는 게 아니라 빼는 것이다. 무엇을 버려도 답이 안 흔들리는지 판단하는 감각. 자료를 통째로 붙이는 대신 요약해서 붙이고, 오래된 대화는 압축하고, 관련 없는 검색 결과는 재순위화로 걸러낸다.

왜 지금 이 말이 뜨나

이유는 에이전트다. 단발 질의응답이던 시절엔 프롬프트 한 줄이면 됐다. 그런데 여러 단계를 스스로 도는 에이전트가 등장하면서, 매 스텝마다 컨텍스트가 불어난다. 도구를 부르고, 결과를 받고, 그걸 다음 판단에 넣고… 이 과정에서 컨텍스트를 방치하면 토큰은 폭발하고 모델은 길을 잃는다. 긴 컨텍스트일수록 중간에 있는 정보를 놓치는 현상도 잘 알려져 있다. 그래서 "무엇을 언제 넣고 빼느냐"가 에이전트 설계의 중심 문제로 올라온 것이다.

관점컨텍스트 엔지니어링프롬프트 엔지니어링
대상입력 전체 조립지시 문장
성격동적·요청마다 변함정적·고정
핵심 기술검색·요약·선별문장 설계

현실적인 감각

내가 얻은 교훈은 이렇다. 답이 이상할 때 프롬프트부터 만지지 마라. 먼저 "이 순간 모델이 실제로 뭘 봤는가"를 그대로 찍어보라. 컨텍스트를 로그로 남겨 눈으로 확인하면, 열에 아홉은 엉뚱한 자료가 섞여 있거나 정작 필요한 정보가 빠져 있다. 프롬프트는 마지막에 다듬는 것이고, 그전에 컨텍스트가 깨끗해야 한다.

자주 묻는 질문

프롬프트 엔지니어링은 이제 필요 없나요?

아니다. 시스템 지시와 출력 형식을 명확히 쓰는 일은 여전히 중요하다. 다만 그것만으로는 부족하다는 게 요점이다. 잘 쓴 프롬프트에 엉뚱한 컨텍스트가 붙으면 결과가 무너진다. 둘은 대체 관계가 아니라 층위가 다른 작업이며, 실무에선 컨텍스트 조립이 먼저고 프롬프트 다듬기가 그 위에 얹힌다.

컨텍스트 창이 커지면 이 고민은 사라지지 않나요?

줄어들긴 하지만 사라지진 않는다. 창이 커져도 토큰 비용과 지연이 늘고, 길수록 중간 정보를 놓치는 경향이 있다. 무엇보다 관련 없는 정보를 잔뜩 넣으면 모델이 헷갈린다. 창이 크다고 다 채우는 게 아니라, 오히려 덜 넣되 더 관련 있게 넣는 절제가 더 중요해진다.

어디서부터 손대야 하나요?

가장 먼저 할 일은 모델에 들어가는 최종 입력을 통째로 로그로 남기는 것이다. 무엇이 들어갔는지 눈으로 봐야 무엇을 뺄지 정할 수 있다. 그다음 검색 결과 재순위화, 대화 요약, 오래된 맥락 압축을 차례로 붙인다. 화려한 기법보다 "입력을 눈으로 확인한다"는 이 습관 하나가 대부분의 문제를 잡아준다.

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록