AI 에이전트가 똑똑해 보이지 않을 때, 우리는 종종 모델 성능부터 의심한다. 하지만 실무에서는 전혀 다른 곳에서 문제가 생기는 일이 많다. 모델이 틀려서가 아니라, 잘못된 재료를 받아서 어긋나는 경우다. 오래된 문서를 읽고 답하거나, 지금 작업과 상관없는 대화 조각에 끌려가거나, 필요한 파일은 놓치고 비슷한 이름의 다른 파일을 집어드는 식이다.
여기서 중요한 것이 컨텍스트 전달 설계다. 컨텍스트는 단순히 "모델에게 많이 보여주는 정보"가 아니다. 지금 이 작업을 위해 필요한 정보만, 적절한 형태로, 적절한 타이밍에 전달하는 것이 핵심이다. 프롬프트가 명령이라면, 컨텍스트는 재료다. 그리고 하네스 설계의 관점에서 보면, 컨텍스트는 창고에 쌓여 있는 정보가 아니라 작업대 위에 올려지는 정보다.
이번 장에서는 RAG, 파일 검색, 작업별 컨텍스트 패키징, 긴 작업에서의 압축, 최신성 관리, 충돌 해결까지 다룬다. 핵심 원칙은 하나다. 좋은 컨텍스트는 많이 주는 것이 아니라, 지금 필요한 것만 정확히 주는 것이다.
메모리와 컨텍스트는 닮았지만 다르다
앞 장에서 메모리와 상태를 다뤘다면, 이번 장은 그 저장된 것들이 실제 실행 순간에 어떻게 꺼내져 전달되는지를 다룬다. 이 둘은 자주 섞이지만 역할이 다르다.
메모리가 창고라면, 컨텍스트는 작업대다. 창고에 있는 모든 공구를 한꺼번에 책상 위에 쏟아놓는다고 해서 일이 잘되지는 않는다. 오히려 망치가 필요한 순간에 드라이버만 잔뜩 보여주면 손이 꼬인다. 에이전트도 마찬가지다. 많이 저장하는 것보다, 무엇을 지금 꺼내 보여줄지 고르는 일이 더 중요할 때가 많다.
같은 사용자 정보라도 메모리에서는 오래 보관될 수 있지만, 컨텍스트에서는 매번 필요하지 않을 수 있다. 예를 들어 사용자의 말투 선호는 장기 기억으로 저장해둘 수 있지만, 데이터베이스 마이그레이션 작업을 수행하는 순간에는 거의 쓸모가 없을 수도 있다. 반대로 특정 오류 로그는 평소엔 저장 대상이 아닐 수 있어도, 지금 장애를 분석하는 순간에는 가장 중요한 컨텍스트가 된다.
즉, 메모리는 "무엇을 알고 있는가"에 가깝고, 컨텍스트는 "지금 무엇을 보여줄 것인가"에 가깝다. 이 차이를 구분해야 에이전트가 덜 산만해진다.
하네스 안에서 컨텍스트는 흐른다
많은 팀이 컨텍스트를 정적인 입력처럼 생각한다. 사용자의 질문과 몇 개의 문서를 붙여 모델에 넣으면 끝이라고 여기는 것이다. 하지만 실제 에이전트의 컨텍스트는 한 번에 완성되지 않는다. 작업이 진행되면서 계속 수집되고, 걸러지고, 다시 패키징된다.
보통 컨텍스트의 흐름은 다음 순서를 따른다.
사용자의 요청과 현재 작업 상태를 읽는다.
관련 메모리, 문서, 파일, 검색 결과 후보를 모은다.
그중 지금 단계에 필요한 것만 압축해 패키징한다.
실행 결과를 바탕으로 다음 단계의 컨텍스트를 다시 구성한다.
이 흐름을 설계하지 않으면 에이전트는 매 단계마다 비슷한 문서를 반복해서 읽거나, 이미 끝난 하위 작업의 잔여 정보를 계속 들고 다니게 된다. 그러면 토큰 비용만 늘어나는 것이 아니라, 목표 이탈도 쉬워진다. 마치 회의가 끝났는데도 지난 회의 안건이 화이트보드에 그대로 남아 있어서 다음 회의를 방해하는 상황과 비슷하다.
좋은 하네스는 컨텍스트를 "모아두는 시스템"이 아니라 "흐르게 하는 시스템"이다. 어떤 정보가 언제 들어오고, 언제 빠지고, 어떤 단계에서 다시 요약되는지까지 설계해야 한다.
RAG는 많이 찾는 기술이 아니라, 제대로 고르는 기술이다
RAG는 흔히 "문서를 검색해서 모델에게 붙여주는 방식"으로 설명된다. 틀린 말은 아니지만, 실전에서는 이 설명만으로는 부족하다. 진짜 핵심은 검색 그 자체보다 검색 결과를 작업 맥락에 맞게 골라주는 일이다.
RAG가 실패하는 가장 흔한 이유는 두 가지다. 하나는 못 찾는 것이고, 다른 하나는 너무 많이 찾는 것이다. 첫 번째는 당연히 문제다. 그런데 두 번째도 만만치 않게 위험하다. 관련 문서를 열 개, 스무 개씩 한꺼번에 붙여 넣으면 모델은 중요한 조항보다 주변 설명에 더 끌릴 수 있다. 질문은 출장비 규정인데, 문서 서론의 회사 문화 설명에 주목하는 식이다.
좋은 RAG는 검색 정확도만이 아니라 선별 정확도가 높아야 한다. 이를 위해서는 최소한 세 가지 질문이 필요하다.
이 정보가 현재 질문과 직접 관련이 있는가
이 정보가 최신인가, 아니면 과거 기록인가
이 정보가 원문으로 필요한가, 아니면 요약만으로 충분한가
이 질문 없이 검색 점수만 믿고 문서를 밀어 넣으면, 에이전트는 많이 읽고도 엉뚱한 결론을 낼 수 있다. RAG는 도서관에 가는 기술이 아니라, 사서처럼 책을 골라주는 기술에 가깝다.
파일 검색은 검색 기능이 아니라 작업 경로 설계다
에이전트가 실제 업무를 하려면 문서, 코드, 스프레드시트, 메모, 로그 파일을 읽어야 한다. 이때 많은 팀이 파일 검색을 단순한 편의 기능으로 생각한다. 하지만 파일 검색은 에이전트의 판단 경로를 결정하는 핵심 장치다.
예를 들어 코딩 에이전트가 버그를 수정한다고 해보자. 이 에이전트가 프로젝트 전체를 통째로 읽는다고 해서 좋은 결과가 나오지는 않는다. 오히려 다음 순서가 더 중요하다. 에러가 난 파일, 관련 테스트, 설정 파일, 최근 변경 이력, 팀 규칙 문서를 어떤 우선순위로 읽게 할 것인가가 성패를 가른다.
파일 검색 설계에서 중요한 것은 "읽을 수 있느냐"보다 "어떤 기준으로 읽게 할 것이냐"다. 파일명 일치, 경로 우선순위, 태그, 최근 수정 시각, 프로젝트 범위, 사용자의 명시적 선택 같은 기준이 필요하다. 그렇지 않으면 에이전트는 final_report_v2_really_final 같은 이름의 파일들 사이에서 길을 잃기 쉽다.
특히 실무에서는 비슷한 파일이 많다. 초안, 복사본, 예전 버전, 개인 메모, 공식 문서가 한 폴더에 섞여 있다. 사람은 제목과 맥락으로 어느 정도 구분하지만, 에이전트는 그렇지 않다. 따라서 파일 검색 하네스는 파일 자체만이 아니라 파일의 신뢰도와 역할도 함께 전달해야 한다. 예를 들어 "공식 정책 문서", "개인 메모", "임시 초안", "지난 분기 보고서" 같은 구분이 있으면 판단이 훨씬 안정된다.
작업별 컨텍스트 패키징이 필요한 이유
같은 정보라도 어떤 작업을 하느냐에 따라 보여주는 방식이 달라져야 한다. 컨텍스트 전달 설계에서 가장 자주 놓치는 부분이 바로 이것이다. 문서를 잘 찾았다고 해서 끝난 것이 아니다. 찾은 정보를 지금 할 일에 맞게 재구성해야 한다.
예를 들어 같은 제품 문서라도 다음처럼 패키징이 달라져야 한다.
고객 응대 에이전트에게는 자주 묻는 질문과 최신 정책 요약이 중요하다.
영업 제안서 에이전트에게는 제품 차별점, 가격 정책, 성공 사례가 중요하다.
온보딩 문서 작성 에이전트에게는 용어 설명, 설정 절차, 주의사항이 중요하다.
원문은 같아도 필요한 컨텍스트의 모양은 다르다. 이 차이를 무시하면 에이전트는 늘 같은 자료 묶음을 들고 다니며, 작업마다 불필요한 부분까지 함께 처리하게 된다.
좋은 하네스는 작업 단위로 컨텍스트 패키지를 만든다. 여기에는 보통 네 가지가 들어간다. 현재 목표, 참고해야 할 자료, 피해야 할 행동, 출력 형식이다. 이 네 가지가 정리되면 에이전트는 "무엇을 읽을지"뿐 아니라 "읽은 뒤 무엇을 할지"까지 훨씬 선명하게 이해한다.
컨텍스트는 원문, 요약, 구조화 데이터로 나눠 다뤄야 한다
모든 정보를 같은 형태로 전달하면 비효율이 커진다. 어떤 정보는 원문이 필요하고, 어떤 정보는 요약이면 충분하며, 어떤 정보는 아예 구조화된 필드로 주는 편이 낫다.
예를 들어 법적 조항이나 계약 문구처럼 한 단어 차이가 중요한 정보는 원문이 필요하다. 반면 회의록 전체를 매번 붙일 필요는 없고, 결정 사항과 남은 액션만 요약하면 충분한 경우가 많다. 또 작업 상태, 승인 여부, 마감일 같은 정보는 산문보다 구조화된 필드로 주는 편이 훨씬 안정적이다.
이 차이를 무시하면 두 가지 문제가 생긴다. 하나는 불필요하게 길어진다는 점이고, 다른 하나는 정확도가 떨어진다는 점이다. 원문이 필요한 정보를 요약만 보여주면 중요한 단서가 사라질 수 있다. 반대로 요약으로 충분한 정보를 원문째 넣으면 핵심이 묻힌다.
실전에서는 다음처럼 나누어 생각하는 편이 좋다.
| 형태 | 언제 적합한가 | 예시 |
|---|---|---|
| 원문 | 문구 자체가 중요할 때 | 정책 조항, 계약 문서, 오류 메시지 |
| 요약 | 전체 맥락은 필요하지만 세부는 덜 중요할 때 | 회의록, 긴 리서치 문서, 과거 대화 |
| 구조화 데이터 | 필드 단위 판단이 필요할 때 | 마감일, 상태, 승인 여부, 고객 등급 |
좋은 컨텍스트 전달은 많이 붙이는 기술이 아니라, 형태를 바꿔 전달하는 기술이기도 하다.
긴 작업에서는 압축이 성능이다
에이전트가 한두 번 답하고 끝나는 것이 아니라, 여러 단계를 거쳐 일할수록 컨텍스트는 점점 길어진다. 처음에는 선명했던 목표가 열 번의 도구 호출 뒤에는 묻혀버리기 쉽다. 이때 필요한 것이 압축이다.
압축은 단순한 요약이 아니다. 그냥 짧게 줄이는 것만으로는 부족하다. 다음 단계 판단에 필요한 정보만 남기고, 나머지는 뒤로 보내는 편집 작업이어야 한다. 좋은 압축은 내용을 줄이면서도 의사결정에 필요한 좌표를 잃지 않는다.
예를 들어 리서치 에이전트가 다섯 개의 문서를 읽고 보고서를 준비한다고 하자. 이때 매 단계마다 문서 전문을 들고 다니면 곧 한계가 온다. 대신 다음과 같이 압축할 수 있다.
질문과 직접 관련된 핵심 주장
출처별로 합의되는 부분과 충돌하는 부분
아직 검증되지 않은 쟁점
최종 보고서에 반드시 포함해야 할 근거
이렇게 압축하면 문서 길이는 줄어들지만 판단력은 유지된다. 반대로 "A 문서는 이런 내용이고, B 문서도 비슷하고…" 식의 뭉뚱그린 요약은 길이만 줄어들 뿐 실제 작업에는 도움이 되지 않는 경우가 많다.
압축의 질은 에이전트의 집중력과 거의 같다. 잘 압축된 컨텍스트는 긴 작업을 짧은 작업처럼 다루게 해준다.
압축하다가 왜곡하지 않으려면
압축은 강력하지만 위험하다. 요약이 반복될수록 정보가 손실되거나 비틀어질 수 있기 때문이다. 특히 "요약의 요약의 요약" 구조는 에이전트에게 매우 위험하다. 처음 문서의 미묘한 단서가 사라지고, 나중에는 확정되지 않은 해석만 남을 수 있다.
이 문제를 줄이려면 압축된 컨텍스트에도 원문으로 돌아갈 길이 남아 있어야 한다. 즉, 요약만 있으면 안 되고 원문 참조점이 함께 있어야 한다. "어느 문서의 어느 부분을 바탕으로 요약했는가"가 추적 가능해야 한다는 뜻이다.
또 하나 중요한 것은 압축 대상의 분리다. 사실, 해석, 추정, 미해결 쟁점을 한 문단에 섞어 줄이면 나중에 무엇이 확정 정보였는지 구분하기 어렵다. 압축은 짧게 만드는 작업이면서 동시에 구분을 선명하게 만드는 작업이어야 한다.
좋은 압축은 줄였는데도 정직하다. 자신이 생략한 것이 무엇인지, 아직 불확실한 것이 무엇인지 드러낸다. 그런 압축이 장기 작업에서 에이전트를 덜 위험하게 만든다.
최신성 관리는 선택이 아니라 기본값이다
컨텍스트 설계에서 자주 과소평가되는 것이 최신성이다. 문서가 검색되었다고 해서, 그 문서가 지금도 맞는 정보라는 뜻은 아니다. 특히 정책, 가격, 일정, 제품 사양, 운영 절차처럼 자주 바뀌는 정보는 오래된 문서가 오히려 더 위험할 수 있다.
최신성 문제는 단순히 날짜 하나 붙인다고 해결되지 않는다. 실전에서는 같은 주제에 대해 여러 버전의 문서가 공존하기 때문이다. 초안이 있고, 승인본이 있고, 개정본이 있고, 팀별 로컬 사본도 있다. 에이전트가 이 차이를 모르면 "읽을 수 있는 문서"를 "써도 되는 문서"로 착각하게 된다.
그래서 하네스는 컨텍스트에 최신성 신호를 함께 실어야 한다. 예를 들면 작성 시점, 최종 수정 시점, 공식 문서 여부, 유효 기간, 대체 문서 존재 여부 같은 정보다. 이런 신호가 있으면 에이전트는 단순한 내용 유사도만이 아니라 정보의 현재 유효성까지 고려할 수 있다.
최신성 관리가 특히 중요한 경우는 세 가지다.
외부 세계와 연결된 정보: 가격, 뉴스, 규제, 일정
조직 내부 운영 정보: 정책, 승인 절차, 담당자 체계
살아 있는 산출물: 코드베이스, 제품 문서, 데이터 스키마
이 영역에서는 "비슷한 문서"보다 "현재 유효한 문서"가 우선이다. 내용이 조금 덜 자세해도 최신 문서가 낫다. 오래된 완벽함보다, 현재의 충분함이 더 안전할 때가 많다.
최신 정보와 오래된 정보를 함께 보여줘야 할 때도 있다
언제나 최신 정보만 보여주는 것이 정답은 아니다. 어떤 작업은 변화의 흐름 자체가 중요하기 때문이다. 예를 들어 정책 변경 분석, 계약 비교, 코드 회귀 원인 추적, 고객 요구사항 변천 파악 같은 일은 이전 정보와 최신 정보를 함께 봐야 한다.
이때 중요한 것은 두 정보를 섞지 않는 것이다. "예전에는 이랬고, 지금은 이렇다"가 분리되어 전달되어야 한다. 시간축이 섞이면 에이전트는 과거 규칙을 현재 규칙처럼 말하거나, 최신 정책을 과거의 배경 설명으로 오해할 수 있다.
좋은 컨텍스트 패키지는 버전 차이를 숨기지 않는다. 오히려 버전 관계를 드러낸다. 어떤 문서가 이전 버전인지, 무엇이 바뀌었는지, 현재 기준으로 무엇을 따라야 하는지를 명시해야 한다. 변화 분석 작업에서는 정보의 양보다 버전 간 관계 설명이 더 중요하다.
컨텍스트 충돌은 예외가 아니라 일상이다
현실의 문서는 늘 깔끔하게 정리되어 있지 않다. 서로 다른 팀이 쓴 문서가 충돌하고, 회의록과 공식 정책이 어긋나고, 최신 코드와 위키 설명이 다를 수 있다. 따라서 컨텍스트 전달 설계는 "충돌 없는 정보가 들어온다"는 가정 위에 세우면 안 된다.
에이전트가 충돌을 만났을 때 가장 위험한 반응은 조용히 하나를 골라버리는 것이다. 그럴듯하게 말하지만 근거는 흔들리는 답이 나오기 쉽다. 좋은 하네스는 충돌을 감추지 않고 드러내게 해야 한다.
컨텍스트 충돌이 있을 때는 보통 다음 순서가 안전하다.
충돌하는 정보들을 출처와 함께 분리한다.
각각의 최신성, 공식성, 범위를 비교한다.
그래도 해결되지 않으면 사람 승인이나 추가 검증으로 넘긴다.
이 설계가 있으면 에이전트는 "정답을 모르는 상태"를 정직하게 표현할 수 있다. 반대로 이 구조가 없으면, 자신감 있는 오답이 만들어진다. 실무에서는 후자가 훨씬 더 비싸다.
컨텍스트의 양보다 밀도가 중요하다
모델의 컨텍스트 창이 커질수록, 많은 팀이 문제를 힘으로 밀어붙이려 한다. "그냥 다 넣자"는 유혹이다. 하지만 큰 창은 큰 방일 뿐, 정리된 방을 보장하지는 않는다. 방이 넓다고 바닥에 모든 서류를 펼쳐놓으면 오히려 더 찾기 어려워진다.
좋은 컨텍스트는 양이 아니라 밀도가 높다. 밀도가 높다는 말은, 지금 해야 할 판단과 직접 연결된 정보 비율이 높다는 뜻이다. 쓸모 있는 문장이 열 개 있는 컨텍스트가, 관련 없는 문장 천 개보다 훨씬 낫다.
밀도를 높이려면 세 가지를 계속 점검해야 한다.
지금 단계와 상관없는 배경 설명은 과감히 뒤로 보낸다.
이미 실행에 반영된 정보는 반복해서 싣지 않는다.
같은 사실을 여러 형태로 중복 전달하지 않는다.
에이전트가 산만해지는 이유는 정보가 부족해서가 아니라, 관련 없는 정보가 너무 많아서인 경우가 많다. 사람도 회의 자료가 두꺼울수록 안심하지만, 정작 중요한 한 문장을 놓치기 쉽다. 에이전트도 비슷하다.
컨텍스트 전달 설계의 실전 패턴
실무에서 자주 쓰는 패턴을 몇 가지로 정리해보면 감을 잡기 쉽다.
첫째, 질문 중심 패키징이다. 사용자의 요청을 기준으로 관련 자료만 모아 짧게 묶는다. FAQ 응답이나 리서치 질의응답에 잘 맞는다.
둘째, 작업 단계 중심 패키징이다. 현재 단계에서 필요한 입력만 제공한다. 계획 단계에서는 목표와 제약을, 실행 단계에서는 도구 결과와 상태를, 검토 단계에서는 산출물과 기준을 넣는 식이다. 긴 워크플로에 특히 유용하다.
셋째, 역할 중심 패키징이다. 같은 자료라도 작성자, 검토자, 승인자에게 다른 모양으로 전달한다. 멀티에이전트 구조에서 효과적이다.
넷째, 예외 중심 패키징이다. 평소에는 기본 규칙만 주고, 충돌이나 위험 작업이 감지될 때만 추가 정책과 승인 기준을 붙인다. 권한이 중요한 자동화에 적합하다.
이 패턴들의 공통점은 하나다. 컨텍스트를 문서 덩어리로 취급하지 않고, 행동을 돕는 입력 세트로 본다는 점이다.
좋은 컨텍스트 하네스는 질문을 잘 만든다
컨텍스트 전달 설계의 목적은 결국 에이전트가 더 좋은 질문을 하게 만드는 데 있다. 여기서 질문이란 사용자의 질문만 뜻하지 않는다. 모델이 속으로 하게 되는 질문까지 포함한다. "지금 가장 중요한 정보는 무엇이지?", "이 문서는 공식 문서인가?", "이전 버전과 무엇이 다르지?", "다음 단계로 넘어가도 되나?" 같은 질문 말이다.
좋은 컨텍스트는 이 질문들에 미리 답할 수 있게 설계되어 있다. 반대로 나쁜 컨텍스트는 에이전트가 알아서 추측하게 만든다. 추측이 많아질수록 환각만 늘어나는 것이 아니다. 도구 선택 실수, 잘못된 파일 참조, 최신성 오판, 목표 이탈도 함께 늘어난다.
그래서 컨텍스트 전달 설계는 단순한 정보 주입이 아니다. 판단 비용을 줄이는 설계다. 필요한 정보가 제때, 적절한 형태로 들어오면 모델은 더 적게 헤매고 더 안정적으로 일한다.
정리: 컨텍스트는 재료가 아니라 배치다
컨텍스트 설계를 잘한다는 것은 더 많이 모으는 것이 아니라, 더 잘 배치하는 것이다. RAG는 검색된 문서의 양으로 평가할 일이 아니라 지금 필요한 근거를 정확히 건네는지로 평가해야 한다. 파일 검색은 접근 기능이 아니라 작업 경로 설계로 봐야 한다. 긴 작업에서는 압축이 필요하고, 압축은 단순 축약이 아니라 판단에 필요한 좌표를 남기는 편집이어야 한다. 최신성 관리는 기본값이어야 하며, 충돌은 숨기지 말고 드러내야 한다.
결국 좋은 컨텍스트 하네스는 에이전트에게 이렇게 말하는 환경이다. "세상 모든 것을 다 보려고 하지 말고, 지금 이 일을 끝내는 데 필요한 것부터 보자."
이 단순한 원칙이 의외로 많은 문제를 줄여준다. 정보가 많을수록 똑똑해질 것 같지만, 실제로는 정확하게 고른 정보가 에이전트를 더 유능하게 만든다. 다음 장에서는 이렇게 전달된 컨텍스트 위에서 에이전트가 어떤 순서와 반복 구조로 일해야 하는지, 즉 워크플로와 루프 설계를 살펴보겠다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.