프롬프트를 늘렸는데 AI는 더 틀린다: AI 에이전트 컨텍스트 엔지니어링 실전

먼저 알아둘 핵심

 

컨텍스트 엔지니어링은 AI 에이전트가 매 순간 읽을 지시문, 검색 자료, 도구 설명, 대화 기록과 작업 상태를 골라 구성하는 기술이다. 프롬프트를 정교하게 쓰는 일도 여기에 포함되지만, 핵심은 필요한 정보가 필요한 시점에 도착하도록 만드는 데 있다. 긴 문서를 더 많이 넣는다고 답변의 정확도가 자동으로 높아지는 것은 아니다.

 

이 글은 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이, RAG와 장기 메모리의 역할, 대화 압축과 도구 응답 설계, 운영 평가 방법을 하나의 흐름으로 설명한다. AI 에이전트를 처음 서비스에 붙이는 개발자와, 데모는 잘 되는데 운영에서는 자꾸 실패하는 팀을 위한 실전 가이드다.

 

제목의 “더 틀린다”는 모든 긴 입력이 반드시 성능을 떨어뜨린다는 뜻이 아니다. 관련 없는 정보와 서로 충돌하는 지침이 누적되면 더 긴 입력이 오히려 판단을 방해할 수 있다는 의미다. 모델과 과제에 따라 결과는 달라지므로, 길이가 아니라 실제 업무 성공률로 검증해야 한다.

 

읽을 순서

 

1. 프롬프트와 컨텍스트의 차이

2. 긴 컨텍스트가 실패하는 이유

3. 국내외 기술 블로그에서 확인한 설계 원칙

4. RAG·메모리·작업 상태를 나누는 방법

5. 필요한 시점에 검색하고 압축하는 방법

6. 고객 지원 에이전트 설계 예시

7. 평가 지표와 도입 체크리스트

8. 자주 묻는 질문과 참고 자료

 

1. 프롬프트 엔지니어링은 끝났을까

 

끝났다고 단정하기 어렵다. 시스템 프롬프트가 목표와 행동 기준을 명확하게 전달하지 못하면 좋은 검색 결과를 붙여도 에이전트는 흔들린다. 사용자의 요청을 어떤 범위에서 수행할지, 근거가 부족하면 어떻게 답할지, 결과를 어떤 형식으로 반환할지를 정의하는 일은 여전히 중요하다.

 

다만 여러 단계로 움직이는 AI 에이전트에서는 지시문만 고쳐서 해결할 수 없는 문제가 생긴다. 첫 검색에서는 정책을 찾고, 다음 단계에서는 주문 내역을 조회하며, 마지막에는 처리 결과를 확인해야 한다. 단계마다 필요한 정보가 다른데도 동일한 대화 기록과 자료 전체를 반복해서 전달하면 비용과 판단 부담이 함께 늘어난다.

 

Anthropic은 2025년 9월 공개한 엔지니어링 글에서 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 발전으로 설명한다. 프롬프트가 지시문을 작성하고 조직하는 방법에 초점을 둔다면, 컨텍스트는 도구와 외부 데이터, 메시지 이력까지 포함한 전체 입력 상태를 다룬다. 따라서 둘은 교체 관계보다 포함 관계에 가깝다.

 

실무에서는 문장을 고치기 전에 실패한 호출에 무엇이 실제로 들어갔는지 살펴보는 편이 유용하다. 최신 정책이 없었다면 표현 문제가 아니라 검색 문제다. 서로 다른 고객의 주문이 섞였다면 데이터 범위 문제다. 완료된 작업을 계속 반복한다면 진행 상태가 전달되지 않은 문제다. 원인을 나누면 개선할 계층도 분명해진다.

 

2. 긴 컨텍스트 윈도우가 정확성을 보장하지 않는 이유

 

컨텍스트 윈도우는 모델이 한 번의 호출에서 다룰 수 있는 입력과 출력 범위에 관한 제한이다. 그 안에 넣을 수 있다는 사실과 그 안의 모든 정보를 같은 정확도로 활용한다는 사실은 다르다. 제품이 지원하는 최대 길이를 곧바로 업무 품질 보증으로 읽으면 안 된다.

 

Anthropic은 입력 토큰이 늘어날 때 정보 회상 정확도가 떨어질 수 있는 현상을 context rot라는 관점으로 설명한다. 긴 입력에서도 높은 성능을 유지하는 모델이 있지만, 관련 없는 문장과 먼 위치의 근거를 함께 다루는 작업은 여전히 평가가 필요하다. 특정 토큰 수를 넘으면 모든 모델이 동일하게 실패한다는 보편적인 경계선은 없다.

 

예를 들어 반품 기한을 찾는 에이전트에 구버전 정책, 현재 정책, 이벤트 예외 조항, 다른 국가의 규정과 고객 대화 전체를 한꺼번에 넣었다고 하자. 정답 문장이 포함되어 있어도 적용 국가와 시행일을 구분하지 못하면 결론은 틀린다. 정보량이 부족한 문제가 아니라 선택 기준이 모호한 문제다.

 

반대로 원문을 과도하게 줄여도 실패한다. “반품 가능”이라는 요약만 남기고 “미개봉 상품, 수령 후 일정 기간 이내”라는 조건을 버리면 다음 단계에서 예외를 복원할 수 없다. 목표는 짧은 입력 자체가 아니라, 현재 판단에 필요한 조건과 근거가 살아 있는 입력이다.

 

한글 글자 수와 모델 토큰 수도 구분해야 한다. 같은 분량의 문장이라도 언어, 기호, 코드와 모델의 토크나이저에 따라 토큰 수가 달라진다. 예산을 설정할 때는 글자 수를 임의로 환산하기보다 실제 API 사용량과 해당 모델의 제한을 확인해야 한다.

 

3. 다른 기술 블로그에서 확인한 실전의 공통점

 

AWS 한국어 기술 블로그의 Deep Insight 사례는 문제를 아키텍처, 프롬프트, 도구, 검증의 네 계층으로 나누어 설명한다. 독립적인 에이전트 컨텍스트, 간결한 결과 전달, 파일에 남기는 분석 산출물, 별도의 검증과 진행 추적이 함께 등장한다. 한 가지 프롬프트 요령으로 전체 운영 문제를 해결하려 하지 않는다는 점이 핵심이다.

 

특히 실제 데이터와 산출물은 외부 저장소에 두고, 현재 대화에는 위치와 핵심 상태를 전달하는 패턴이 유용하다. 다만 파일을 만들었다는 사실만으로 이미 입력된 토큰이 사라지지는 않는다. 도구 호출의 인자와 결과가 어떤 방식으로 메시지 이력에 남는지, 이후 호출에서 무엇을 제거하는지까지 확인해야 절감 효과를 설명할 수 있다.

 

루닥스 블로그의 “[LangChain v1.0] Context Engineering”은 모델에 보이는 정보, 도구가 접근하는 정보, 호출 사이에서 실행되는 처리라는 관점으로 문제를 정리한다. 상태와 장기 저장소, 런타임 구성을 구분하고 미들웨어로 호출별 입력을 조정하는 예시를 제공한다. 이는 컨텍스트 관리가 단순 요약 기능보다 넓은 개발 과제라는 점을 보여 준다.

 

이 글에서는 국내 기술 블로그에서 읽기 쉬운 문제 제기 → 개념 설명 → 구체적인 예시 → 운영 점검의 흐름을 참고했다. 특정 사례의 토큰 절감 비율이나 성공률을 다른 시스템의 예상 성과로 가져오지는 않았다. 모델, 도구 응답과 업무 구성이 달라지면 같은 구조도 다른 결과를 낼 수 있기 때문이다.

 

공식 자료인 Anthropic의 글은 필요한 시점에 자료를 불러오는 방식, 대화 압축, 구조화된 메모와 하위 에이전트 구조를 함께 다룬다. 세 자료의 접점은 분명하다. 현재 판단에 도움이 되는 정보를 선별하고, 상세 기록은 다시 찾을 수 있게 남기며, 실제로 완료되었는지를 확인하는 설계가 필요하다.

 

4. 에이전트 입력을 다섯 묶음으로 분리하자

 

첫째는 변하지 않는 행동 기준이다. 서비스의 목적, 수행 범위, 근거 부족 시 처리와 출력 규칙을 여기에 둔다. 여러 작업에서 반복되는 기준을 한곳에서 관리하면 서로 다른 프롬프트에 같은 규칙을 복사하다가 내용이 어긋나는 문제를 줄일 수 있다.

 

둘째는 현재 사용자의 목표와 제약이다. “지난달 주문을 확인해 달라”와 “이번 주문을 취소해 달라”는 다른 업무다. 사용자가 방금 수정한 날짜나 요청 범위는 오래된 대화 요약보다 우선해서 반영해야 한다. 요청을 한 문장으로 요약하더라도 예산, 마감, 제외 조건처럼 결과를 바꾸는 요소는 함께 남긴다.

 

셋째는 확인된 작업 상태다. 조회 완료, 추가 확인 필요, 실행 대기, 실행 결과 확인처럼 다음 행동을 결정하는 사실을 기록한다. 모델이 “이제 처리하겠다”고 말한 것은 완료 증거가 아니다. 외부 시스템의 응답과 상태 조회 결과를 근거로 완료 여부를 갱신해야 한다.

 

넷째는 검색 자료와 도구 결과다. 정책 문서, 주문 내역, 코드와 로그가 포함된다. 이 자료에는 출처, 적용 범위, 확인 시점과 버전을 붙이는 편이 좋다. 현재 요청과 관련이 적은 필드는 제외하되, 원문으로 돌아갈 식별자는 남긴다.

 

다섯째는 장기 메모리다. 사용자가 선호하는 답변 언어처럼 여러 대화에 걸쳐 유효한 정보를 보관할 수 있다. 하지만 일회성 요청이나 모델의 추측을 영구 선호도로 저장하면 오염이 누적된다. 이 다섯 묶음을 구분해 두면 무엇을 항상 넣고 무엇을 선택적으로 불러올지 결정하기 쉽다.

 

5. RAG와 메모리는 같은 기능이 아니다

 

RAG는 일반적으로 외부 자료를 검색해 관련 내용을 생성 단계에 제공하는 접근이다. 사내 문서와 제품 설명처럼 바뀌는 지식을 다룰 때 유용하다. 장기 메모리는 사용자 선호나 이전 작업에서 유지할 사실을 대화 사이에 저장하는 역할에 가깝다. 둘 다 저장소를 사용할 수 있지만 선택 기준과 갱신 주기는 다르다.

 

정책을 찾을 때는 질문과 의미가 비슷한 문서만 고르면 부족하다. 해당 상품군, 국가, 시행일과 계약 종류가 일치하는지 확인해야 한다. 검색 결과에 현재 정책보다 오래된 문서가 높은 순위로 올라올 수 있으므로, 벡터 유사도와 함께 메타데이터 필터와 버전 관리가 필요하다.

 

메모리에서는 “사용자가 언제, 어떤 범위에서 말했는가”가 중요하다. 오늘 작성하는 글만 짧게 써 달라는 요청을 모든 답변의 영구 규칙으로 저장하면 다음 작업이 불편해진다. 일회성 제약, 세션 선호와 장기 선호를 구분하고 사용자가 정정하면 이전 기록을 갱신할 수 있어야 한다.

 

또한 정책의 사실과 사용자의 희망을 섞지 말아야 한다. “무료 환불을 원한다”는 고객 요청이지 회사 정책이 아니다. 이를 메모리에 “이 고객은 무료 환불 대상”으로 저장하면 다음 상담에서 잘못된 근거가 된다. 요청, 관찰, 검증된 사실과 시스템 결과를 서로 다른 상태로 다루는 것이 안전하다.

 

검색이나 메모리를 도입했다고 환각이 사라지는 것도 아니다. 검색된 문서를 잘못 해석하거나, 필요한 근거를 찾지 못했는데도 답을 완성할 수 있다. 근거가 없는 경우를 정상적인 결과로 표현하고, 추가 조회와 사용자 확인으로 이어지는 경로를 설계해야 한다.

 

6. 필요한 시점에 필요한 자료만 불러오기

 

Just-in-time 컨텍스트는 업무와 관련된 모든 자료를 시작부터 펼쳐 놓는 대신, 가벼운 식별자와 목록을 유지하고 필요할 때 상세 내용을 읽는 방식이다. 대규모 저장소의 모든 파일을 매번 읽기보다 파일 목록과 검색 결과로 범위를 좁히는 개발자의 작업과 비슷하다.

 

고객 지원 에이전트라면 처음에는 요청의 종류를 파악하고, 주문 조회가 필요할 때 주문 목록을 가져온다. 대상 주문이 정해지면 상세 내역을 조회하고, 취소 가능성을 판단할 때 해당 상품과 상태에 맞는 정책을 읽는다. 이렇게 단계별로 필요한 정보가 달라지는 흐름을 도구 설계에 반영할 수 있다.

 

단, 동적으로 찾는 방식에도 비용이 있다. 검색과 상세 조회가 늘면 응답 시간이 길어지고, 에이전트가 잘못된 검색어를 반복할 수 있다. 모든 자료를 사전 로딩하지 않는다고 언제나 더 저렴하고 빠른 것은 아니다. 자주 쓰는 작은 정책은 미리 제공하고, 큰 원문은 필요할 때 읽는 혼합 방식도 합리적이다.

 

검색 결과는 제목과 단순 요약만으로 끝내지 않는 편이 좋다. 문서 식별자, 버전, 적용 기간, 관련 구간과 상세 조회 방법을 함께 제공하면 다음 도구 호출을 결정하기 쉽다. 현재 페이지가 전체 결과인지 일부인지도 표시해야 한다. 일부 목록을 전체로 착각하는 오류는 검색 품질과 별개로 발생한다.

 

결국 자료를 나눌 기준은 문서의 물리적 크기만이 아니다. 하나의 판단에 필요한 조건이 서로 떨어지지 않도록 의미 단위를 유지해야 한다. 환불 기본 규정과 예외 조항을 분리했다면, 예외가 존재한다는 연결 정보가 기본 규정의 검색 결과에도 나타나도록 설계할 필요가 있다.

 

7. 도구 응답이 길면 프롬프트보다 도구부터 고친다

 

에이전트가 주문 한 건을 확인하는데 전체 고객 데이터와 수천 줄의 원시 응답을 받는다면 “짧게 생각하라”는 지시보다 API 응답을 바꾸는 편이 효과적일 수 있다. 현재 질문에 필요한 필드를 서버에서 선택하고, 개수 제한과 페이지 이동을 제공하면 입력의 불필요한 증가를 줄일 수 있다.

 

좋은 조회 도구는 반환한 범위와 누락 가능성을 설명한다. 결과가 없을 때는 조회 성공 후 일치 항목이 없는지, 권한이 없어 보지 못했는지, 연결 오류로 검색 자체가 실패했는지를 구분한다. 이 상태를 모두 빈 배열로 반환하면 에이전트는 “없다”는 잘못된 결론을 내리기 쉽다.

 

목록 조회와 상세 조회를 분리하는 방법도 있다. 목록에서는 식별자, 제목, 상태와 수정 시각을 주고, 상세 조회에서는 판단에 필요한 원문과 근거를 돌려준다. 다만 너무 잘게 쪼개면 호출 왕복이 증가하므로 실제 업무의 조회 패턴으로 결정해야 한다.

 

도구의 이름과 인자도 컨텍스트다. 이름이 비슷한 도구가 여러 개 있고 사용 조건이 모호하면 모델이 선택하기 어렵다. 조회와 변경을 구분하고, 입력 날짜의 시간대와 상태 값의 의미를 명확히 적어야 한다. 사람 개발자도 설명만 보고 선택할 수 없는 도구를 모델이 안정적으로 고르리라 기대하기 어렵다.

 

중요한 권한 검사는 응답 문장에만 맡길 수 없다. 읽기 전용 사용자에게 변경 도구를 덜 보여 주는 것은 혼동을 줄이지만, 실제 접근 허용 여부는 서버와 실행 계층에서 확인해야 한다. 컨텍스트를 정리하는 일과 실행 권한을 보장하는 일은 함께 설계하되 서로 다른 책임으로 관리해야 한다.

 

8. 대화 압축에서는 문장보다 조건을 보존한다

 

대화가 길어지면 압축이 필요해진다. 그러나 “고객이 환불을 문의했다”처럼 이야기만 남기는 요약은 재시작에 부족하다. 대상 주문, 사용자가 바꾼 요청, 확인한 정책 버전, 아직 확인하지 못한 조건과 이미 실행된 작업이 무엇인지가 있어야 다음 단계가 이어진다.

 

보존할 항목을 먼저 정의하자. 목표, 제약, 결정, 근거 위치, 진행 상태, 미해결 질문과 다음 행동은 실용적인 출발점이다. 숫자와 식별자, 취소 조건처럼 잘못 바뀌면 결과를 뒤집는 항목은 요약 모델의 표현에만 의존하지 않고 별도 구조 필드에 저장하는 편이 낫다.

 

예를 들어 “금요일까지 보고서 작성”이라는 요약은 기준 날짜와 시간대가 빠져 있다. 장기 작업이라면 절대 날짜와 시간대를 함께 남겨야 다음 세션에서도 마감을 해석할 수 있다. “파일 저장 완료”도 위치와 버전이 없으면 다른 파일을 덮어쓰거나 이전 결과를 참조할 수 있다.

 

원시 도구 응답을 제거할 때는 다시 읽을 수 있는지 확인해야 한다. 나중에 조회하면 값이 바뀌는 재고나 가격이라면, 의사결정 당시의 스냅샷과 확인 시각이 필요할 수 있다. 단순히 URL을 남기는 방식만으로 과거 판단의 근거가 항상 복구되지는 않는다.

 

압축 품질은 요약문이 자연스러운지보다 작업을 정확히 재개하는지로 평가해야 한다. 대화 중간에 압축을 수행한 뒤 대상과 제약을 유지하는지, 완료 작업을 중복하지 않는지, 남은 질문을 다시 찾는지 확인한다. 요약 길이를 줄였다는 사실만으로 성공이라고 판단하지 않는다.

 

9. 장기 메모리는 저장보다 정정과 삭제가 중요하다

 

메모리는 한 번 넣으면 계속 맞는 지식 창고가 아니다. 사용자의 직무와 선호는 변하고, 프로젝트의 기술 스택과 정책도 바뀐다. 오래된 기록을 현재 사실처럼 넣는 순간 컨텍스트는 과거의 조건으로 현재 요청을 해석하게 된다.

 

각 기록에는 적어도 내용, 출처, 기록 시점, 적용 범위와 갱신 상태를 두는 편이 좋다. 무엇이 사용자의 직접 진술이고 무엇이 시스템 관찰인지도 구분한다. 추측에서 출발한 내용은 확정 사실과 같은 우선순위로 취급하지 않는다.

 

충돌하는 기록이 생겼을 때 최신 항목을 무조건 덮어쓰는 방식도 부족할 수 있다. 개인 프로젝트에서는 Python을 쓰고 회사 업무에서는 Java를 쓸 수 있기 때문이다. 날짜뿐 아니라 프로젝트와 업무 범위를 함께 비교해야 잘못된 일반화를 줄일 수 있다.

 

다른 사용자나 조직의 메모리가 섞이지 않도록 저장소의 범위도 분리해야 한다. 검색 프롬프트에 “내 고객 것만 찾아라”라고 쓰는 것으로는 충분하지 않다. 데이터 조회 단계에서 사용자와 조직 범위를 강제하고, 모델에 전달하기 전에 접근 가능한 항목만 선택해야 한다.

 

삭제 요청이나 정책 변경이 들어오면 원본 기록뿐 아니라 요약, 검색 색인과 캐시에도 어떤 영향이 있는지 검토해야 한다. 컨텍스트를 재구성하는 여러 경로 중 하나에 오래된 정보가 남으면 사용자는 이미 고친 내용을 계속 보게 된다. 메모리 운영에는 기록의 수명 관리가 포함된다.

 

10. 고객 지원 AI 에이전트에 적용한 가상 설계

 

다음은 개념을 설명하기 위한 가상 시나리오이며, 실제 운영 실험 결과가 아니다. 사용자는 “최근 구매한 무선 이어폰을 취소하고 싶다”고 요청한다. 목표는 취소 가능 여부를 정확히 확인하고, 필요한 절차를 거쳐 실제 처리 결과까지 사용자에게 전달하는 것이다.

 

첫 단계에서는 사용자 요청과 조회에 필요한 범위만 유지한다. 에이전트가 인증된 사용자의 최근 주문 목록을 조회하면 도구는 주문 식별자, 상품명, 주문 시각과 배송 상태를 반환한다. 이어폰 주문이 두 건이라면 모델이 임의로 고르지 않고 사용자가 어느 건을 뜻하는지 확인한다.

 

대상이 확정되면 해당 주문의 상세 상태와 적용 정책을 조회한다. 정책에는 시행일과 적용 상품 조건이 붙어 있고, 주문 결과에는 확인 시각이 포함된다. 판단에 필요한 예외가 별도 문서에 있다면 그 구간까지 읽는다. 이 단계에서는 전체 구매 이력이나 관련 없는 상품 정책을 계속 들고 있을 필요가 없다.

 

실행 전 작업 상태에는 “대상 확인 완료, 취소 가능성 확인, 실제 실행은 아직 하지 않음”을 남긴다. 사용자에게 안내한 문장과 외부 시스템의 실제 처리 여부를 혼동하지 않도록 한다. 취소 요청을 전송한 뒤에는 접수 결과와 최종 상태를 구분하고, 결과가 불명확하면 완료로 단정하지 않는다.

 

마지막 답변은 “가능할 것 같다”는 추론보다 확인된 상태를 기준으로 작성한다. 취소가 완료되었다면 대상과 결과를, 추가 확인이 필요하다면 남은 조건을 명확히 설명한다. 이 흐름에서 컨텍스트 엔지니어링은 모델을 더 많이 말하게 하는 기술보다, 단계별 판단에 필요한 증거를 제때 전달하는 기술로 작동한다.

 

11. 멀티 에이전트는 컨텍스트를 나누지만 비용도 만든다

 

서로 독립적인 조사 과제를 여러 에이전트에 맡기면 각자가 짧고 집중된 컨텍스트를 사용할 수 있다. 큰 작업의 세부 탐색 기록을 모두 주 에이전트에게 전달하는 대신, 결론과 근거 위치를 전달하면 전체 흐름을 관리하기 쉬워진다.

 

그러나 에이전트를 늘리면 호출 수, 중복 검색, 결과 조정과 검증 비용이 늘어난다. 같은 정책을 여러 에이전트가 반복해서 찾거나, 서로 다른 버전을 보고 결론을 내릴 수도 있다. 독립적으로 나눌 수 없는 순차 작업을 무리하게 분해하면 통신 과정이 더 복잡해진다.

 

하위 에이전트가 반환하는 결과에는 결론만 넣기보다 근거 식별자, 적용 조건과 불확실성을 함께 포함하는 편이 좋다. “취소 가능”이라는 두 글자짜리 결론만 받으면 주 에이전트는 조건이 충족되었는지 확인하기 어렵다. 요약은 짧아도 검증에 필요한 연결 고리는 남아야 한다.

 

AWS 사례처럼 역할별 컨텍스트와 산출물을 분리하는 구조는 참고할 수 있다. 다만 특정 서비스의 역할 수를 그대로 복제할 필요는 없다. 단일 에이전트와 명확한 도구만으로 충분한 업무라면 먼저 그 구조를 평가하고, 실제로 병렬 탐색이나 전문화가 필요한 구간에 한해 확장하는 편이 낫다.

 

선택 기준은 에이전트 수가 아니라 업무 성공률과 총비용이다. 단일 구조와 분산 구조를 같은 요청 묶음으로 비교하고, 결과의 정확성뿐 아니라 누락, 지연과 운영 복잡성까지 살펴보아야 한다.

 

12. 컨텍스트 품질을 측정하는 평가 지표

 

첫 번째 지표는 최종 업무 성공률이다. 답변의 말투가 자연스러워도 잘못된 주문을 선택하거나 예외 조건을 놓쳤다면 실패다. 성공 조건을 작업 시작 전에 정의하고, 근거 부족 때문에 적절히 보류한 경우와 잘못 완료한 경우를 구분해야 한다.

 

두 번째는 근거 품질이다. 최종 주장에 맞는 출처가 붙어 있는지, 출처의 내용이 실제로 그 주장을 뒷받침하는지, 적용 기간과 고객 범위가 맞는지 확인한다. 링크가 존재한다는 사실만으로 인용이 정확한 것은 아니다. 검색 실패와 해석 실패를 나누면 개선 방향도 달라진다.

 

세 번째는 제약 보존율이다. 대화가 길어지고 중간에 압축된 뒤에도 사용자의 제외 조건과 변경 요청을 지키는지 평가한다. 처음에는 A 상품을 요청했다가 B 상품으로 바꾸는 시나리오처럼, 오래된 지시를 버려야 정답이 되는 과제를 포함하는 것이 좋다.

 

네 번째는 성공 한 건당 비용과 지연이다. 입력 토큰이 줄어도 검색 호출과 재시도가 늘면 총비용은 오를 수 있다. 모델 비용뿐 아니라 도구 사용료, 처리 시간과 사람이 다시 확인하는 비용까지 포함해 비교해야 한다. 캐시 적중 여부도 함께 기록하면 원인을 해석하기 쉽다.

 

다섯 번째는 중단 후 재개 품질이다. 저장한 상태만으로 다음 세션이 올바른 대상을 찾아 이어지는지, 이미 완료된 작업을 반복하지 않는지 확인한다. 장기 실행 에이전트에서는 정상 흐름의 정답률만큼 중요한 평가다.

 

실험할 때는 모델과 온도, 도구 버전과 과제 묶음을 가능한 한 고정하고 한 번에 바꾸는 요소를 줄인다. 검색 결과 수를 줄이는 실험과 압축 방식을 바꾸는 실험을 동시에 하면 무엇이 개선을 만들었는지 알기 어렵다. 특정 개선 폭을 미리 약속하기보다 반복 실행 결과와 실패 사례를 함께 기록한다.

 

13. 바로 적용할 수 있는 도입 순서

 

먼저 최근 실패 사례를 모아 실제 입력을 확인한다. 정답 근거가 애초에 없었는지, 있었지만 예외를 놓쳤는지, 오래된 정보와 충돌했는지, 실행 결과를 잘못 해석했는지 분류한다. 모든 실패를 “프롬프트가 약하다”는 한 가지 문제로 묶지 않는 것이 출발점이다.

 

다음으로 시스템 지침과 작업 상태, 외부 자료와 장기 메모리를 나눈다. 사용자가 방금 바꾼 요청이 어느 필드에 반영되는지, 완료된 작업은 무엇을 근거로 기록하는지 정한다. 이 단계만으로도 어떤 정보가 계속 중복되는지 보이기 시작한다.

 

그다음 가장 큰 도구 응답부터 줄인다. 목록과 상세를 분리하거나 필요한 필드만 반환하고, 일부 결과인지 전체 결과인지 표시한다. 검색에 적용 범위와 버전 조건을 추가하고, 요약에서 빠지면 안 되는 조건을 정의한다.

 

이후 긴 대화의 압축과 재개를 시험한다. 상태가 복구되는지 확인하기 전에 복잡한 장기 메모리나 여러 에이전트를 추가하면 문제의 원인이 늘어난다. 단순한 구조에서 효과를 확인한 후 검색과 저장, 분업 범위를 단계적으로 확장한다.

 

운영 점검에서는 현재 목표가 명확한지, 근거의 시점과 범위가 맞는지, 원문에 다시 접근할 수 있는지, 미해결 조건이 남아 있는지, 완료를 증명할 도구 결과가 있는지 확인한다. 체크 항목은 문서로만 남기지 말고 로그와 평가 데이터에서 관찰할 수 있도록 연결해야 한다.

 

14. 자주 묻는 질문

 

Q. 컨텍스트 엔지니어링을 도입하면 프롬프트를 짧게 써야 하나요?

반드시 그렇지는 않다. 행동 기준과 중요한 예외를 설명하는 데 필요한 길이는 유지해야 한다. 중복 지시와 관련 없는 정보는 줄이되, 결과를 바꾸는 조건을 삭제하지 않는 것이 중요하다.

 

Q. 큰 컨텍스트 윈도우 모델을 쓰면 RAG가 필요 없나요?

자료의 양과 변경 빈도, 접근 범위와 지연 요구에 따라 달라진다. 전체 자료를 넣을 수 있어도 최신 버전 선택과 접근 제어는 남는다. 반대로 작은 고정 문서라면 단순히 전체를 제공하는 구성이 더 쉬울 수도 있다.

 

Q. 메모리를 많이 저장할수록 개인화가 좋아지나요?

유효하고 관련 있는 정보가 선택될 때 도움이 된다. 오래된 추측과 일회성 요청이 누적되면 오히려 잘못된 개인화가 발생한다. 저장량보다 정정, 범위 지정과 검색 품질이 중요하다.

 

Q. 대화 요약만 잘하면 충분한가요?

요약은 중요한 수단이지만 검색 누락, 잘못된 권한 범위와 모호한 도구 설명을 해결하지는 못한다. 작업 상태와 근거를 구조적으로 관리하고 실행 결과를 확인하는 흐름이 함께 필요하다.

 

Q. 어떤 프레임워크가 필수인가요?

특정 프레임워크가 필수인 것은 아니다. LangChain의 미들웨어와 상태 관리처럼 구현을 돕는 기능은 있지만, 핵심은 호출별 입력을 조정하고 작업 상태와 근거를 추적할 수 있는 구조다. 팀이 운영할 수 있는 단순한 방식부터 시작할 수 있다.

 

Q. 가장 먼저 해야 할 실험은 무엇인가요?

자주 실패하는 실제 과제를 골라 현재 방식과 관련 자료만 선별한 방식을 비교하는 것이다. 성공 여부, 근거 정확도, 토큰과 도구 비용, 응답 시간을 함께 기록하면 길이 감소가 실제 개선인지 판단할 수 있다.

 

15. AI 에이전트의 성능은 무엇을 읽히느냐에서 갈린다

 

프롬프트 엔지니어링의 가치는 사라지지 않았다. 다만 에이전트가 긴 시간 동안 여러 도구를 사용하게 되면서, 좋은 지시문을 쓰는 능력만으로 전체 신뢰성을 설명하기 어려워졌다. 검색과 상태, 메모리와 실행 결과를 하나의 흐름으로 다루는 능력이 더 중요해지고 있다.

 

컨텍스트 엔지니어링의 목표는 모델에 모든 것을 기억시키는 일이 아니다. 현재 판단에 필요한 정보를 제때 전달하고, 필요가 끝난 상세 기록은 다시 찾을 수 있게 보존하며, 다음 단계로 넘어갈 근거를 명확히 남기는 일이다.

 

긴 프롬프트를 보고 안심하기 전에 실제 호출 한 번을 살펴보자. 최신 조건이 있는가, 관련 없는 기록이 판단을 가리지 않는가, 출처로 돌아갈 수 있는가, 완료 상태를 확인했는가. 이 질문에 답할 수 있는 구조가 데모를 운영 가능한 AI 에이전트로 바꾸는 출발점이다.

 

참고 자료와 확인 범위

 

작성 기준: 2026년 10월 18일. 아래 자료의 본문을 직접 확인해 개념과 설계 원칙을 정리했다. 제품의 현재 모델 목록이나 가격을 비교하는 글은 아니며, 자료 속 개별 서비스의 수치가 다른 시스템에도 재현된다고 가정하지 않았다. 고객 지원 예시는 설명을 위한 가상 시나리오다.

 

[1] Anthropic, Effective context engineering for AI agents, 2025년 9월 29일.

프롬프트와 컨텍스트의 구분, 필요한 시점의 검색, 압축, 구조화된 메모와 하위 에이전트 구조를 설명한다.

https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Effective context engineering for AI agents

 

[2] AWS 기술 블로그, Context Window 한계를 넘어서 – Deep Insight 개발 여정으로 배우는 Context Engineering 실전 기법, 2026년 4월 8일.

아키텍처·프롬프트·도구·검증으로 나눈 한국어 구현 사례를 확인했다. 소개된 개별 절감 수치는 이 글의 성능 예측에 사용하지 않았다.

https://aws.amazon.com/ko/blogs/tech/context-engineering-from-deep-insight/

 

[3] 루닥스 블로그, [LangChain v1.0] Context Engineering, 2025년 11월 8일.

모델 컨텍스트와 도구, 상태와 저장소를 구분하는 한국어 설명 및 호출별 입력 조정 예시를 참고했다. 글에서 연결한 LangChain 문서는 추가 학습용이며 이 글에서는 해당 블로그 본문을 확인했다.

https://rudaks.tistory.com/entry/LangChain-v10-Context-Engineering

[LangChain v1.0] Context Engineering

 

함께 읽기: 이 블로그의 「JSON이 맞아도 AI는 틀릴 수 있다: 구조화된 출력과 에이전트 검증의 함정」은 출력 형식을 검증한 뒤에도 값과 근거, 실행 조건을 별도로 확인해야 하는 이유를 다룬다. 컨텍스트를 구성하는 단계와 출력 이후의 검증을 연결해 읽으면 전체 흐름을 이해하는 데 도움이 된다.