컨텍스트 엔지니어링이란 2026 — 프롬프트와 차이·에이전트 실무 기법 5가지

컨텍스트 엔지니어링과 프롬프트 엔지니어링의 차이를 표로 구분하고, 컨텍스트가 길어지면 품질이 떨어지는 세 가지 이유를 정리했습니다. 도구 응답 압축·서브에이전트 격리·규칙 파일 등 실무 기법 5가지와 판단 기준을 담았습니다. 3만 자 응답을 96% 줄인 실측 사례 포함.

컨텍스트 엔지니어링은 LLM이 한 번의 추론에서 무엇을 보게 할지를 설계하는 작업입니다. 프롬프트 엔지니어링이 "어떻게 물어볼까"라면, 컨텍스트 엔지니어링은 "무엇을 넣고 무엇을 빼둘까"에 가깝습니다. 에이전트가 여러 턴을 돌며 도구를 호출하는 방식이 표준이 되면서, 실무에서 성능과 비용을 가르는 변수가 프롬프트 문구에서 컨텍스트 관리로 옮겨왔습니다. 이 글은 그 차이가 어디서 생기는지와 실제로 쓸 수 있는 기법을 정리했습니다.

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

단발 질문에서는 두 개념이 거의 겹칩니다. 잘 쓴 프롬프트 하나가 결과를 결정하니까요.

에이전트에서는 달라집니다. 사용자의 지시는 한 번인데 모델은 수십 번 호출됩니다. 매 호출마다 이전 대화, 읽은 파일, 도구가 돌려준 결과가 누적됩니다. 이때 모델이 보는 내용의 대부분은 사람이 쓴 문장이 아니라 시스템이 채워 넣은 데이터입니다.

구분

프롬프트 엔지니어링

컨텍스트 엔지니어링

대상	사람이 쓰는 지시문	모델이 보는 전체 입력
주 변수	표현·예시·역할 부여	무엇을 넣고 뺄지, 언제 버릴지
실패 양상	의도와 다른 답	후반부로 갈수록 품질 저하·비용 폭증
적용 시점	호출 1회	세션 전체

Anthropic도 컨텍스트를 "유한한 자원"으로 다루라고 정리합니다. 넣을 수 있는 만큼 넣는 게 아니라, 지금 판단에 필요한 것만 남기는 게 핵심입니다.

컨텍스트가 길어지면 왜 품질이 떨어지는가

"컨텍스트 윈도우가 20만 토큰이니 다 넣으면 되지 않나"라는 질문이 자주 나옵니다. 실무에서는 그렇게 되지 않습니다.

첫째, 유효 컨텍스트는 윈도우 크기보다 작습니다. 입력이 길어질수록 중간에 묻힌 정보를 놓치는 경향이 관찰됩니다. 윈도우에 들어간다고 해서 모델이 그걸 똑같은 무게로 참조하지는 않습니다.

둘째, 노이즈가 판단을 흐립니다. 관련 없는 파일 내용이나 이미 끝난 작업의 로그가 남아 있으면, 모델이 그걸 현재 맥락으로 오인해 엉뚱한 방향으로 갑니다.

셋째, 비용이 누적됩니다. 대화가 길어질수록 매 호출의 입력 토큰이 늘어납니다. 같은 작업을 하루 수백 번 반복하는 파이프라인에서는 이게 그대로 청구서가 됩니다.

도구 응답이 가장 큰 오염원이다

실무에서 컨텍스트를 가장 빠르게 태우는 건 사람의 지시가 아니라 도구가 돌려주는 값입니다.

나무숲이 겪은 사례가 명확합니다. 브라우저 자동화용 Playwright MCP를 붙였더니 페이지 하나의 접근성 트리가 37,000자를 넘었습니다. 몇 단계만 오가도 컨텍스트가 포화됐습니다. 그래서 응답이 주 모델에 닿기 직전에 가로채 저비용 모델로 요약하는 계층을 만들었고, 실측으로 `browser_snapshot`이 37,897자에서 1,435자로 96% 줄었습니다. 자세한 구조는 Playwright MCP 토큰 최적화에 정리했습니다.

여기서 배운 원칙은 두 가지입니다.

줄이되 참조는 남긴다. 요소 참조값(`ref=`)을 날리면 절감은 되는데 다음 액션이 깨집니다. 무엇을 버려도 되는지는 "다음 판단에 필요한가"로 갈립니다.

도구 설계 단계에서 정한다. Anthropic의 도구 작성 가이드도 같은 지점을 짚습니다. 반환값을 줄이는 건 사후 최적화가 아니라 도구를 만들 때의 설계 결정입니다.

실무에서 쓰는 기법 다섯 가지

기법

무엇을 하나

언제 쓰나

응답 압축	도구 출력을 요약해 전달	출력이 큰 도구(브라우저·DB·검색)
서브에이전트 격리	하위 작업을 별도 컨텍스트에서 처리하고 결과만 회수	탐색·조사처럼 중간 산출물이 많은 작업
규칙 파일	프로젝트 규약을 파일로 두고 에이전트가 읽게 함	같은 지시를 매 세션 반복할 때
시나리오 도구	원자적 호출 여러 개를 하나로 묶음	왕복 횟수가 많을 때
주기적 정리	끝난 작업의 로그·파일을 컨텍스트에서 제거	긴 세션

서브에이전트 격리가 특히 효과가 큽니다. "이 저장소에서 X를 찾아라" 같은 작업은 중간에 파일을 수십 개 읽는데, 그 내용이 전부 주 컨텍스트에 남을 필요가 없습니다. 하위 에이전트가 별도 컨텍스트에서 찾고 결론만 돌려주면 주 컨텍스트는 깨끗하게 유지됩니다. 나무숲이 Anthropic Superpowers 프레임워크의 Subagent 스킬을 개발 루프에 쓰는 이유가 이것입니다.

규칙 파일은 가장 싸게 얻는 개선입니다. 프로젝트 컨벤션·금지사항·배포 절차를 파일 하나에 적어 두면 매 세션 다시 설명할 필요가 없습니다. 같은 지시를 세 번 이상 반복하고 있다면 그게 신호입니다.

어디까지 넣고 어디서 끊을까

정답은 없지만 판단 기준은 단순합니다. 다음 한 번의 판단에 필요한가.

필요하다 → 넣는다
나중에 필요할 수도 있다 → 파일로 두고 참조 경로만 남긴다
이미 끝난 작업의 흔적이다 → 뺀다

"혹시 몰라서" 넣는 것이 가장 흔한 낭비입니다. 모델은 넣어 준 것을 전부 관련 있다고 가정하므로, 관련 없는 내용을 넣으면 정확도와 비용을 동시에 잃습니다.

장시간 도는 에이전트라면 긴 작업용 하네스 설계에서 다루는 상태 관리도 함께 봐야 합니다. 세션을 넘겨 가며 일하는 구조에서는 무엇을 다음 세션으로 넘길지가 곧 컨텍스트 설계입니다.

134~167 단어 자립형 답변: 컨텍스트 엔지니어링이란?

컨텍스트 엔지니어링은 LLM이 한 번의 추론에서 보게 될 입력 전체를 설계하는 작업입니다. 프롬프트 엔지니어링이 사람이 쓰는 지시문의 표현을 다룬다면, 컨텍스트 엔지니어링은 대화 이력·읽은 파일·도구 반환값까지 포함해 무엇을 넣고 무엇을 뺄지를 결정합니다. 에이전트는 한 번의 지시로 수십 번 호출되며 매 호출마다 데이터가 누적되므로, 모델이 보는 내용의 대부분은 사람이 쓴 문장이 아니라 시스템이 채운 값입니다. 컨텍스트가 길어지면 중간 정보가 묻히고 노이즈가 판단을 흐리며 입력 토큰 비용이 누적됩니다. 실무에서 가장 큰 오염원은 도구 반환값이며, 브라우저 자동화 도구는 페이지 한 장에 3만 자를 넘기기도 합니다. 대응 기법은 도구 응답 압축, 서브에이전트로 하위 작업 격리, 프로젝트 규칙 파일화, 원자적 호출을 시나리오 단위로 묶기, 끝난 작업 정리입니다. 판단 기준은 "다음 한 번의 판단에 필요한가"입니다.

자주 묻는 질문

Q. 컨텍스트 윈도우가 크면 컨텍스트 엔지니어링이 필요 없지 않나요?

윈도우가 커도 유효 컨텍스트는 그보다 작습니다. 길어질수록 중간 정보가 묻히고, 무엇보다 입력 토큰 비용이 매 호출마다 붙습니다. 윈도우 크기는 상한이지 목표가 아닙니다.

Q. 프롬프트 엔지니어링은 이제 안 해도 되나요?

아닙니다. 단발 작업에서는 여전히 프롬프트가 결과를 결정합니다. 다만 에이전트로 넘어가면 프롬프트만으로는 통제되지 않는 영역이 생기고, 그 영역이 컨텍스트입니다.

Q. 도구 응답을 요약하면 정확도가 떨어지지 않나요?

버리는 대상이 무엇인지에 달렸습니다. 장식·중복을 버리고 참조값과 상태 변화를 남기면 다음 액션 정확도는 유지됩니다. 반대로 참조를 날리면 절감해도 동작이 깨집니다.

Q. 서브에이전트를 쓰면 오히려 토큰이 늘지 않나요?

하위 에이전트도 토큰을 쓰므로 총량이 늘 수 있습니다. 이득은 주 컨텍스트가 깨끗하게 유지되는 것이고, 긴 세션에서는 그 효과가 총량 증가를 넘어섭니다. 짧은 단발 작업이면 굳이 쓸 이유가 없습니다.

Q. 규칙 파일에는 무엇을 적나요?

매 세션 반복해서 설명하고 있는 것을 적습니다. 프로젝트 컨벤션, 하지 말아야 할 것, 배포 절차 같은 것들입니다. 같은 지시를 세 번 이상 반복했다면 그게 옮길 신호입니다.

Q. 기존에 만든 에이전트에도 적용할 수 있나요?

가능합니다. 가장 먼저 볼 곳은 도구 반환값 크기입니다. 어떤 도구가 얼마나 큰 응답을 주는지 측정하는 것부터 시작하면, 대개 한두 개가 대부분을 차지합니다.

---

*글쓴이: 남대현 | TreeSoop CEO, POSTECH 컴퓨터공학 AI/MR/HCI 석사*