3부 15장. 컨텍스트 엔지니어링: 무엇을 언제 넣을 것인가

에이전트를 처음 만들면 누구나 한 번쯤 같은 실수를 한다. 혹시 중요한 정보를 놓칠까 봐, 있는 자료를 전부 한꺼번에 넣어 버리는 것이다. 사용자와의 긴 대화 기록, 사내 문서 여러 개, 이전 도구 호출 결과, 시스템 규칙, 작업 계획, 참고 메모까지 전부 모델 앞에 쏟아 놓는다. 마치 책상 위에 필요한 서류를 찾기 쉽게 하겠다며, 서랍 전체를 뒤집어 엎는 것과 비슷하다.

그런데 이상하게도 결과는 더 좋아지지 않는다. 오히려 느려지고, 비싸지고, 엉뚱해진다. 분명 필요한 정보는 다 줬는데, 에이전트는 핵심을 놓친다. 왜 그럴까. 이유는 단순하다. 많이 넣는 것과 적절하게 넣는 것은 전혀 다른 일이기 때문이다.

좋은 에이전트는 더 많이 아는 시스템이 아니다. 더 적절하게 기억하는 시스템이다. 그리고 그 적절함을 만드는 설계가 바로 컨텍스트 엔지니어링이다.

컨텍스트 엔지니어링은 프롬프트 꾸미기가 아니다

많은 사람이 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 조금 더 어려운 버전쯤으로 생각한다. 지시문을 더 길게 쓰고, 역할을 더 정교하게 설정하고, 예시를 더 붙이면 된다고 여긴다. 물론 지시문은 중요하다. 하지만 그건 전체의 일부일 뿐이다.

컨텍스트 엔지니어링은 한 문장으로 말하면, 지금 이 순간의 판단과 행동에 필요한 정보만 골라, 알맞은 형태로, 알맞은 시점에 전달하는 일이다. 여기에는 시스템 지시문만 들어가지 않는다. 현재 작업 상태도 들어가고, 방금 도구에서 얻은 관찰 결과도 들어가고, 필요한 문서 조각도 들어가고, 사용자 선호도나 정책 제약도 들어간다.

즉, 프롬프트가 "무슨 태도로 일할 것인가"를 정한다면, 컨텍스트 엔지니어링은 "지금 무엇을 보고 판단할 것인가"를 정한다. 둘은 가깝지만 다르다. 좋은 지시문이 있어도 잘못된 정보를 들이밀면 에이전트는 흔들린다. 반대로 지시문이 아주 화려하지 않아도, 필요한 맥락이 정확히 들어가면 surprisingly 안정적으로 움직인다.

왜 모든 정보를 다 넣으면 오히려 나빠질까

직관에 반하는 이야기처럼 들릴 수 있다. 정보가 많을수록 좋지 않나. 시험 볼 때도 자료가 많으면 유리하고, 회의할 때도 배경 설명이 많으면 좋지 않나. 그런데 모델에게는 이야기가 조금 다르다.

첫째, 너무 많은 정보는 주의를 분산시킨다. 모델은 주어진 텍스트 안에서 다음 판단에 쓸 단서를 찾아야 하는데, 관련 없는 정보가 많아질수록 중요한 신호가 묻힌다. 중요한 서류 한 장을 찾으려고 서류 상자 열 개를 뒤지는 상황을 떠올리면 쉽다.

둘째, 오래된 정보와 새로운 정보가 섞이면 충돌이 생긴다. 이전 상태에는 "환불 승인 대기"라고 적혀 있고, 방금 들어온 도구 결과에는 "이미 승인 완료"라고 적혀 있다면 어떻게 될까. 사람이야 문맥을 보고 최신 정보를 우선할 수 있지만, 모델은 종종 둘을 어설프게 섞어 버린다.

셋째, 원문 그대로 밀어 넣는 방식은 비용과 지연을 크게 키운다. 에이전트는 한 번만 생각하고 끝나는 시스템이 아니다. 여러 번 판단하고, 도구를 쓰고, 다시 판단한다. 그때마다 긴 맥락을 계속 실어 나르면, 점점 속도가 느려지고 비용도 불어난다.

넷째, 모든 정보를 매번 동일하게 넣는 습관은 설계를 게으르게 만든다. 어떤 정보가 정말 필요한지 고민하지 않아도 되기 때문이다. 하지만 에이전트가 커질수록 이 게으름은 반드시 문제로 돌아온다.

그래서 컨텍스트 엔지니어링의 첫 원칙은 의외로 소박하다. 모든 것을 넣지 말라. 지금 필요한 것만 넣어라.

컨텍스트는 저장소가 아니라, 현재 장면의 무대다

여기서 중요한 구분이 하나 있다. 저장된 정보가 많다는 사실과, 지금 모델이 보고 있는 정보가 많다는 사실은 다르다. 이 둘을 헷갈리면 설계가 금방 엉킨다.

에이전트 시스템 안에는 여러 종류의 정보가 있을 수 있다. 장기적으로 보관되는 사용자 선호도, 세션 동안 유지되는 작업 상태, 검색으로 가져온 문서 조각, 방금 실행한 도구의 결과, 시스템 정책, 승인 기록, 실패 로그까지 다양하다. 하지만 이 모든 것이 매 순간 모델 앞에 올라와야 하는 것은 아니다.

컨텍스트는 창고가 아니다. 창고에 있는 모든 물건을 회의실로 가져오지는 않는다. 그때그때 안건에 필요한 자료만 테이블 위에 펼쳐 둔다. 컨텍스트 엔지니어링은 바로 그 테이블 세팅에 가깝다.

이 감각이 중요하다. 좋은 에이전트는 기억을 많이 저장하는 시스템이 아니라, 필요한 순간에 필요한 조각만 꺼내 무대 위에 올리는 시스템이다.

어떤 정보가 컨텍스트 후보가 되는가

실무에서 모델에게 넘길 수 있는 정보는 대개 몇 가지 부류로 나뉜다.

• 바뀌지 않는 운영 규칙과 역할 설명

• 현재 세션과 작업의 상태 요약

• 검색이나 파일 조회로 얻은 근거 자료

• 최근 도구 실행에서 관찰한 결과

• 사용자별 선호도와 제약 조건

• 중간 계획, 체크리스트, 임시 메모 같은 작업용 요약

중요한 것은 이 항목들을 전부 넣는 것이 아니라, 어떤 판단을 시키려는지에 따라 조합을 바꾸는 일이다.

예를 들어 검색어를 만들게 할 때는 긴 문서 원문보다 현재 질문의 핵심과 부족한 정보가 더 중요하다. 반대로 최종 답변을 쓰게 할 때는 짧은 검색어보다는 검증된 근거와 사용자에게 보여 줄 말투 지침이 중요하다. 브라우저로 버튼을 누르게 할 때는 대화 전체보다 현재 목표와 허용된 도메인, 금지된 행동이 더 중요하다.

즉, 컨텍스트는 "많으냐 적으냐"보다 "누구에게, 어떤 일을 시키기 위해, 무엇을 보여 주느냐"의 문제다.

좋은 컨텍스트를 고르는 네 가지 기준

그렇다면 무엇을 넣고, 무엇을 빼야 할까. 실무에서는 네 가지 기준으로 보면 판단이 쉬워진다.

첫째는 관련성이다. 지금 하려는 행동과 직접 관계가 있는가. 매출 하락 원인을 분석하는 단계라면 어제 회의 잡담은 아무리 길어도 필요 없다.

둘째는 최신성이다. 이 정보가 지금도 유효한가. 에이전트는 종종 오래된 상태를 진실처럼 붙들고 있다가 실수한다. 최신 도구 결과가 있다면 이전 추정보다 우선해야 한다.

셋째는 신뢰도다. 확정된 사실인가, 추정인가, 사용자가 말한 가정인가, 외부 문서에서 검색한 근거인가. 컨텍스트 안에서 이 구분이 흐리면 모델도 쉽게 섞어 버린다.

넷째는 행동 가능성이다. 이 정보가 다음 행동을 바꾸는가. 그냥 흥미로운 배경지식일 뿐이라면, 지금 턴에서는 빼는 편이 낫다.

이 네 가지를 기준으로 보면 많은 정보가 자연스럽게 탈락한다. 중요한 것처럼 보였지만 실제로는 지금 행동에 영향을 주지 않는 정보가 생각보다 많기 때문이다.

언제 무엇을 넣어야 하는가

컨텍스트 엔지니어링에서 더 어려운 문제는 "무엇을 넣을까"보다 "언제 넣을까"다. 같은 정보도 시점이 다르면 가치가 달라진다.

작업을 시작할 때는 전체 목표와 제약이 중요하다. 사용자가 무엇을 원하고, 어떤 형식으로 결과를 받아야 하며, 어떤 행동은 금지되는지가 우선이다. 이 시점에는 넓은 방향이 필요하다.

도구를 고를 때는 상황이 달라진다. 이제 필요한 것은 장문의 배경 설명이 아니라, 현재 모르는 것이 무엇인지와 어떤 도구가 그 빈칸을 메울 수 있는지다. 예를 들어 "최신 가격이 필요한가", "사내 문서를 확인해야 하는가", "코드로 계산해야 하는가" 같은 판단에 필요한 짧은 상태가 더 중요하다.

도구를 실행한 직후에는 또 바뀐다. 이때는 긴 과거보다 방금 얻은 관찰 결과와 그것이 기존 상태를 어떻게 바꾸는지가 핵심이다. 예를 들어 "검색 결과 5건 중 3건은 중복, 1건은 오래됨, 1건만 유효" 같은 요약이 있으면 다음 판단이 쉬워진다.

최종 답을 작성할 때는 판단용 컨텍스트와 설명용 컨텍스트를 분리하는 편이 좋다. 여기서는 모든 로그가 아니라, 확정된 결론과 근거, 사용자 말투 선호, 출력 형식이 중요하다.

즉, 에이전트는 매 턴 똑같은 문서가방을 들고 다니면 안 된다. 단계마다 필요한 자료 가방이 달라야 한다.

한 번에 넣지 말고, 흐르듯이 넣어라

초보 설계에서 자주 보이는 패턴은 거대한 단일 프롬프트다. 시스템 지침, 상태, 과거 대화, 검색 결과, 정책 문서, 예시 출력, 형식 제한을 전부 한 덩어리로 묶어 매번 모델에게 보낸다. 처음에는 단순해 보여도 금방 유지보수가 어려워진다.

더 나은 방식은 컨텍스트를 흐름으로 다루는 것이다. 현재 단계에서 필요한 정보를 모으고, 짧게 정리하고, 다음 단계로 넘긴다. 그러면 매번 전체를 다시 읽게 하지 않아도 된다.

예를 들어 리서치 에이전트라면 이런 식이다. 처음에는 목표와 범위를 넣어 질문을 정리한다. 검색 단계에서는 검색 질의와 필요한 최신성 조건만 넣는다. 검색 결과가 나오면 원문 대신 짧은 결과 요약을 작업 상태에 남긴다. 그다음 상세 검토가 필요할 때만 특정 문서 조각을 가져온다. 마지막에는 결론과 근거 목록만 모아 보고서를 쓴다.

이 방식의 장점은 단순하다. 컨텍스트가 점점 다듬어진다는 점이다. 에이전트는 매번 원자료의 바다에 빠지는 대신, 이전 단계가 정리해 둔 발판 위에서 다음 판단을 한다.

좋은 요약은 줄이는 것이 아니라 구조화하는 것이다

컨텍스트를 줄인다고 하면, 많은 사람이 문장을 짧게 자르는 일만 떠올린다. 하지만 진짜 요약은 단순 압축이 아니다. 다음 행동에 필요한 구조를 남기는 일이다.

예를 들어 긴 고객 상담 기록을 그대로 20줄로 줄여도, 실제 업무에 필요한 정보가 빠져 있으면 아무 소용이 없다. 반대로 다음과 같이 구조화하면 훨씬 쓸모가 생긴다.

• 고객 ID와 현재 티켓 번호

• 문제 유형과 심각도

• 이미 시도한 조치

• 아직 확인되지 않은 쟁점

• 다음 허용 행동

문장 수는 오히려 더 적을 수 있다. 하지만 행동에 필요한 정보는 더 선명해진다.

리서치 작업도 마찬가지다. 문서 원문을 짧게 줄이는 것보다, "핵심 주장", "근거 데이터", "출처 신뢰도", "반박 가능성" 같은 칸으로 나누는 편이 다음 판단에 더 유리하다. 즉, 좋은 컨텍스트 요약은 산만한 텍스트를 압축하는 일이 아니라, 판단 가능한 상태로 바꾸는 일이다.

도구마다 필요한 컨텍스트가 다르다

여기서 한 가지 매우 실용적인 사실을 기억해야 한다. 같은 에이전트 안에서도, 모든 소비자가 같은 컨텍스트를 원하지는 않는다. 모델, 검색 도구, 브라우저 도구, 코드 실행기, 최종 응답 생성기는 서로 다른 입력을 좋아한다.

모델이 다음 행동을 고를 때는 짧고 구조화된 상태가 좋다. 검색 도구는 대화 전체가 아니라 정제된 질의와 필터 조건이 필요하다. 파일 검색은 질문, 도메인, 문서 범위가 중요하다. 브라우저 도구는 현재 목표, 허용된 사이트, 행동 예산이 핵심이다. 코드 실행은 계산에 필요한 데이터와 기대 출력 형식이 중요하지, 사용자가 처음 농담처럼 던진 말은 대개 필요 없다.

많은 팀이 에이전트를 불안정하게 만드는 이유도 여기 있다. 모든 단계에 같은 거대한 컨텍스트를 집어넣기 때문이다. 하지만 실제로는 각 단계에 맞는 작은 입력 계약이 필요하다.

좋은 시스템은 "모든 것을 모델에게 준다"가 아니라, "각 구성요소가 자기 일에 필요한 정보만 받는다"에 가깝다.

작업 상태 요약은 살아 있는 문서여야 한다

컨텍스트 엔지니어링에서 아주 유용한 도구가 하나 있다. 바로 작업 상태 요약이다. 이것은 전체 대화의 축약본이 아니다. 현재 일을 진행하기 위해 필요한 핵심 사실만 담는 살아 있는 메모다.

좋은 작업 상태 요약은 보통 이런 성격을 가진다. 목표가 한 줄로 적혀 있고, 지금까지 확정된 사실과 아직 모르는 사실이 구분되어 있으며, 최근 도구 결과가 반영되어 있고, 다음에 시도할 행동이 보인다. 길이는 길지 않아야 하지만, 행동에는 충분해야 한다.

예를 들어 "출장비 정산 도와줘"라는 요청이 들어왔다고 해 보자. 처음 상태 요약은 단순할 수 있다. 목적은 출장비 정산 완료, 미확인 항목은 영수증 누락 여부와 환율 기준, 필요한 도구는 파일 조회와 사내 정책 검색. 그다음 영수증 파일을 읽고 나면 상태가 바뀐다. 숙박비 영수증 확인됨, 식비 영수증 2건 누락, 일본 엔화 환율 기준일 미확정. 정책 문서를 읽고 나면 또 바뀐다. 환율은 결제일 기준, 식비는 1일 한도 존재, 누락 영수증은 사용자 확인 필요.

이렇게 상태 요약이 살아 움직이면, 에이전트는 긴 대화 전체를 다시 읽지 않아도 된다. 지금 어디까지 왔는지만 보면 된다.

컨텍스트를 다룰 때 자주 생기는 나쁜 습관

컨텍스트 엔지니어링은 개념은 단순해 보여도, 실전에서는 쉽게 망가진다. 특히 다음과 같은 습관이 자주 문제를 만든다.

• 대화 기록을 한 줄도 버리지 못하고 매번 전부 넣는다.

• 확정 사실과 추정, 정책과 예시, 현재 상태와 과거 상태를 한데 섞어 둔다.

• 도구 결과를 원문 그대로 넣고 아무도 요약하지 않는다.

• 서로 충돌하는 버전이 남아 있는데 최신 상태를 명시하지 않는다.

• 모든 작업을 처리하려는 거대한 만능 프롬프트 하나에 의존한다.

이런 구조에서는 모델이 실수해도 이상할 것이 없다. 정확히 말하면, 모델이 실수한 것이 아니라 시스템이 모델을 헷갈리게 만든 것이다.

작은 예제로 보는 컨텍스트의 흐름

조금 더 생생하게 보기 위해, 시장 조사 에이전트를 떠올려 보자. 사용자는 이렇게 요청한다.

"국내 협업 툴 시장에서 우리와 가장 가까운 경쟁 제품 세 개를 찾아서, 가격 정책과 주요 차이를 요약해 줘."

처음부터 모든 자료를 집어넣는 대신, 에이전트는 먼저 시작용 컨텍스트만 만든다. 목표는 경쟁 제품 세 개 선정, 비교 항목은 가격 정책과 주요 기능 차이, 출력 형식은 표와 짧은 요약. 아직 비어 있는 것은 경쟁 제품 후보와 최신 가격 정보다.

이 상태에서 모델은 검색이 필요하다고 판단한다. 검색 단계에 넘기는 컨텍스트는 짧다. 제품 카테고리, 대상 시장, 후보 선정 기준 정도면 된다. 검색 결과가 돌아오면 원문 전체를 넣지 않고 후보 목록과 간단한 이유만 상태에 남긴다.

그다음 상세 확인 단계에서는 세 제품의 공식 페이지와 가격 페이지를 읽는다. 이때 필요한 컨텍스트는 각 제품의 이름, 확인할 항목, 최신성 요구 정도다. 페이지를 읽고 나면 결과를 다시 구조화한다. 무료 플랜 여부, 사용자당 가격, 엔터프라이즈 문의형인지, 주요 기능 차이, 불확실한 항목.

마지막으로 보고서를 쓸 때는 더 이상 검색 로그가 필요 없다. 여기서는 정리된 비교표, 불확실성 표시, 사용자에게 보여 줄 어조만 있으면 된다.

같은 작업인데도 각 단계의 컨텍스트가 완전히 다르다. 이것이 바로 컨텍스트 엔지니어링이다. 한 덩어리 문서를 계속 들고 다니는 것이 아니라, 일의 진행에 맞춰 맥락의 모양을 바꾸는 것이다.

컨텍스트 예산을 설계하라

에이전트를 운영 가능한 시스템으로 만들고 싶다면, 컨텍스트에도 예산 개념을 붙이는 것이 좋다. 돈 예산, 시간 예산이 있듯이 맥락에도 예산이 있다.

무엇이든 다 넣을 수 있다고 생각하는 순간 설계는 흐려진다. 대신 이렇게 정하는 편이 낫다. 현재 작업 상태 요약은 짧게 유지한다. 검색 결과는 원문이 아니라 항목별 요약으로 저장한다. 긴 문서는 필요한 조각만 가져온다. 로그는 전체가 아니라 마지막 실패 이유와 핵심 관찰만 남긴다. 최종 응답 직전에는 증거와 결론만 모은다.

이런 예산이 있으면 시스템이 자연스럽게 좋은 습관을 갖게 된다. 무엇을 버릴지 고민하게 되고, 무엇을 구조화할지 결정하게 된다. 에이전트의 품질은 종종 "얼마나 많이 기억하는가"가 아니라 "얼마나 잘 버리는가"에서 갈린다.

결국 중요한 것은 기억의 양이 아니라 기억의 타이밍이다

컨텍스트 엔지니어링을 이해하면 에이전트를 보는 눈이 달라진다. 문제는 모델이 덜 똑똑해서가 아닐 때가 많다. 오히려 시스템이 지금 필요한 것과 나중에 필요한 것을 구분하지 못해서 생긴다.

정리해 보자. 좋은 컨텍스트는 관련 있어야 하고, 최신이어야 하고, 신뢰도 구분이 되어 있어야 하며, 다음 행동에 실제로 도움이 되어야 한다. 또한 모든 단계에 같은 정보를 반복해서 넣지 말고, 작업의 흐름에 따라 필요한 맥락을 새로 조합해야 한다. 긴 원문보다 구조화된 상태가 중요하고, 기억의 총량보다 현재 무대 위에 올려놓는 정보의 품질이 더 중요하다.

이 장의 핵심은 하나다. 좋은 에이전트는 더 많이 아는 시스템이 아니라, 더 적절히 기억하는 시스템이다. 그리고 그 적절함은 우연히 생기지 않는다. 어떤 정보를 저장할지보다, 어떤 순간에 무엇을 꺼내 어떤 형태로 보여 줄지를 설계할 때 비로소 만들어진다.

다음부터 에이전트가 엉뚱한 답을 했을 때는 이렇게 물어보면 된다. "모델이 멍청했나?"보다 먼저, "지금 이 단계에 필요한 컨텍스트가 정말 제대로 들어갔나?"라고. 많은 경우, 진짜 원인은 그쪽에 있다.