AI 에이전트 메모리 패턴: 컨텍스트 엔지니어링의 실체

에이전트가 '멍청해지는' 순간, 사실은 메모리 문제다

고객 상담 챗봇이 몇 번 대화하더니 갑자기 처음에 했던 말을 다시 물을 때, 많은 사람이 "이 AI 수준 낮네"라고 느낍니다. 그런데 이 현상은 모델 지능이 부족해서라기보다, 한정된 컨텍스트 창과 엉성한 메모리 전략 때문에 생기는 경우가 더 많습니다.

대규모 언어 모델은 대화 내용과 지식, 도구 호출 결과를 모두 토큰이라는 예산 안에 끼워 넣어야 합니다. 여기에 시스템 프롬프트와 여러 개의 툴 정의까지 더해지면 금방 한계를 넘습니다. 그 순간부터는 이전에 했던 말을 잘라내거나, 요약하거나, 엉뚱한 정보와 섞기 시작합니다. 그 결과가 바로 반복 질문, 모순된 답변, 잘못된 정책 안내 같은 형태로 드러납니다.

제 기준에서는 지금 시점의 에이전트 개발에서 가장 과소평가된 영역이 바로 이 컨텍스트 관리, 즉 컨텍스트 엔지니어링입니다. 모델을 바꾸는 것보다, 무엇을 보여주고 무엇을 버릴지 설계하는 일이 결과에 더 큰 영향을 주는 상황이 이미 오고 있습니다.

네 가지 실패 패턴이 반복된다

현장에서 자주 보이는 실패는 크게 네 가지 흐름으로 요약할 수 있습니다. 갑자기 토큰 양이 폭발하는 컨텍스트 버스트, 앞뒤 지시가 엇갈리는 컨텍스트 컨플릭트, 잘못된 정보가 요약과 메모리를 타고 번지는 컨텍스트 포이즈닝, 필요 이상으로 많은 도구와 정의가 섞여 생기는 컨텍스트 노이즈가 그것입니다.

특히 한국 기업 환경에서는 기존 시스템이 쏟아내는 로그와 정책 문서가 워낙 방대하다 보니, "일단 다 넣고 보자"는 방식이 흔합니다. 이때 컨텍스트 버스트와 노이즈가 동시에 터지기 쉽습니다. 저라면 모델 성능을 탓하기 전에, 지금 에이전트가 한 턴에서 실제로 몇 토큰을 보고 있는지부터 수치로 확인하겠습니다.

단순한 '프롬프트 잘 쓰기'를 넘어선다

프롬프트 엔지니어링이 한때 유행했지만, 오늘 이야기하는 컨텍스트 엔지니어링은 범위가 더 넓습니다. 시스템 프롬프트뿐 아니라, 대화 기록, 도구 정의와 결과, 요약, 장기 메모리까지 전부를 하나의 설계 대상으로 봅니다.

한국어 서비스에서 특히 주의할 점은 프롬프트를 아무리 공들여 써도, 그 옆에 붙는 번역된 정책 문서나 긴 에러 로그가 대부분의 토큰을 차지하는 경우가 많다는 점입니다. 이 구조를 바꾸지 않으면, 프롬프트 장인 솜씨가 실제 답변 품질에 제대로 반영되지 않습니다.

컨텍스트 엔지니어링의 세 가지 축: 리셰이프, 격리, 추출

많은 팀이 "대화 전체를 다 기억하는 AI"를 꿈꾸지만, 현실적으로는 선택과 집중이 필수입니다. 이때 유용한 틀을 세 가지로 나눌 수 있습니다. 리셰이프 앤 핏, 아이솔레이트 앤 라우트, 익스트랙트 앤 리트리브입니다.

리셰이프 앤 핏: 자르거나 압축하거나

첫 번째 축은 지금 이 턴에서 꼭 필요한 정보만 남기도록 컨텍스트를 재구성하는 작업입니다. 가장 단순한 방식은 오래된 대화 턴을 잘라내는 트리밍입니다. 최근 N개 턴만 남기고 앞부분은 버리면 토큰은 빠르게 줄어듭니다. 도구 호출이 많고 업무 프로세스가 짧게 끝나는 에이전트라면 이 방식만으로도 꽤 좋은 균형을 만들 수 있습니다.

문제는 한 세션 안에서 여러 작업이 얽히는 경우입니다. 이때는 앞부분을 버리는 대신, 요약으로 압축하는 컨텍스트 서머리 방식이 필요합니다. 요약은 latency와 비용을 조금 올리지만, 사건의 시간 순서, 사용자 선택, 이미 시도했던 해결책 같은 핵심 정보는 유지합니다. 요약 프롬프트 안에 "무엇이 언제 일어났는지", "무엇이 성공했고 실패했는지"를 구조적으로 적게 하면 장기적으로 큰 자산이 됩니다.

아이솔레이트 앤 라우트: 에이전트를 쪼개서 충돌을 줄인다

두 번째 축은 모든 일을 한 에이전트에 몰아넣지 않고, 역할이 다른 서브 에이전트로 분산하는 접근입니다. 환불 정책만 보는 에이전트, 기술 진단만 하는 에이전트, 계정 정보를 다루는 에이전트를 나누고, 상위 오케스트레이터가 필요할 때만 호출하는 방식입니다.

이렇게 설계하면 각 에이전트가 들고 있는 도구 정의와 시스템 지시가 적어져서 컨텍스트 노이즈와 컨플릭트가 줄어듭니다. 국내처럼 복잡한 약관과 예외 규정이 많은 서비스일수록, 단일 에이전트에 모든 정책을 우겨넣는 방식은 위험합니다. 제 기준에서는 "도구 정의 문서가 두 페이지를 넘기 시작하는 순간"이 에이전트를 쪼갤지 고민해야 할 시점입니다.

익스트랙트 앤 리트리브: 메모리는 데이터, 호출은 도구

마지막 축은 장기 메모리입니다. 매 세션이 끝날 때마다 중요한 사실을 한두 문장으로 뽑아 구조화된 JSON 같은 형태로 저장하고, 다음 세션에서 검색해서 가져오는 흐름입니다. 이때 메모리를 저장하는 역할도 일종의 도구 호출로 보면 편합니다.

여기서 많이 놓치는 부분이 메모리의 스코프입니다. 한 세션 안에서만 유효한 일시적 사실과, 사용자 전체 생애 동안 유지해야 할 선호도는 분리해야 합니다. 창가 자리 선호처럼 오랫동안 유지되는 패턴은 전역 메모리로, 특정 오류를 처리하던 중에만 의미가 있는 정보는 세션 범위 메모리로 두는 편이 훨씬 안전합니다.

장기 요약과 메모리가 바꾸는 사용자 경험

한국 사용자 입장에서 체감되는 AI의 "똑똑함"은 사실상 장기 메모리에서 갈립니다. 같은 문제로 다시 연락했을 때, 이전 상황을 기억하는지 여부가 신뢰도에 결정적인 영향을 줍니다.

요약을 곧바로 시스템 프롬프트로 쓰는 전략

앞서 본 것처럼 긴 대화가 끝난 시점에 전체를 요약한 뒤, 다음 세션의 시스템 프롬프트에 이 요약을 삽입하는 방식이 있습니다. 이때 중요한 것은 요약을 "절대적 진실"이 아니라 "잠재적으로 오래된 정보"로 취급하라는 점입니다. 시스템 메시지 안에 "메모리가 현재 입력과 충돌하면 항상 현재 입력을 우선하라"는 식의 규칙을 넣어두면, 예전 정보가 새 정보를 덮어쓰는 위험을 줄일 수 있습니다.

국내 환경에서는 또 하나의 고려 요소가 있습니다. 개인정보와 보안입니다. 메모리 도구의 지침에 "주민등록번호, 카드번호, 구체적 주소는 저장하지 않는다"처럼 명시적인 금지 규칙을 두지 않으면, 에이전트가 너무 잘 기억하는 것이 오히려 리스크가 됩니다. 장기 메모리 설계는 개인정보보호법과도 맞물리는 영역이라 가벼운 선택이 아닙니다.

어떤 서비스가 장기 메모리에 가장 잘 어울리는가

여행 컨시어지처럼 선호가 비교적 단순하고 반복되는 서비스는 적은 양의 메모리로도 큰 체감 차이를 줍니다. 좌석 타입, 호텔 선호, 예산대 같은 몇 가지 패턴만 잘 기억해도 "나를 이해하는 서비스"처럼 느껴집니다. 반대로 라이프 코치나 멘탈 케어 같은 서비스는 메모리의 폭과 깊이가 끝없이 넓어집니다. 관계, 감정, 목표, 실패 경험까지 모두 맥락을 타고 이어지기 때문입니다.

이 두 유형을 구분하지 않고 같은 메모리 전략을 적용하면 곤란합니다. 저라면 여행이나 쇼핑 추천처럼 구조가 단순한 도메인에서부터 장기 메모리를 실험하고, 회복 탄력성이나 관계 상담 같은 민감한 영역은 훨씬 보수적인 정책과 함께 천천히 확장하겠습니다.

이 전략이 맞는 사람, 시작 전 반드시 체크할 것

모든 팀이 복잡한 메모리 시스템을 당장 구축할 필요는 없습니다. 일부 서비스에는 오히려 과도한 설계가 독이 될 수 있습니다.

누가 먼저 투자해야 하는가, 그리고 함정

복잡한 정책과 예외 규정이 쌓인 금융, 통신, 커머스 고객센터는 컨텍스트 엔지니어링의 효과를 빠르게 체감할 수 있습니다. 대화 길이가 길고, 도구 호출이 잦고, 사용자가 "아까도 말했는데요"라는 말을 자주 하는 영역이라면 투자 우선순위를 높게 잡는 편이 좋습니다. 반면 단발성 검색, 간단한 FAQ 중심 서비스는 트리밍 정도만 해도 충분한 경우가 많습니다.

현실적인 함정도 있습니다. 첫째, 팀 내부에서 메모리 품질을 평가할 기준이 없는 상태에서 무작정 요약과 저장 기능만 추가하는 경우입니다. 이때는 모델이 꾸준히 틀린 기억을 쌓다가 어느 날 한꺼번에 폭발하는 경험을 하게 됩니다. 둘째, 인프라 관점의 비용과 성능을 가볍게 보는 경우입니다. 세션 수가 늘면 요약 호출, 임베딩, 벡터 검색 비용이 함께 올라갑니다. 예산과 트래픽 전망을 먼저 계산하는 편이 안전합니다.

지금 할 수 있는 첫 번째 행동

메모리 시스템을 바로 짓지 않더라도, 당장 시작할 수 있는 일은 분명합니다. 우선 실제 사용자 세션 몇 백 개를 뽑아서 턴별 토큰 사용량을 눈으로 보는 일입니다. 어디에서 버스트가 일어나는지, 도구 결과가 얼마나 장황한지, 시스템 프롬프트가 전체의 몇 퍼센트를 차지하는지 수치로 확인하는 것만으로도 개선 방향이 또렷해집니다.

그다음 단계로는 한 가지 기법만 선택해 실험하는 편이 좋습니다. 예를 들어 "최근 5턴만 유지" 같은 단순 트리밍과, "10턴마다 요약 추가" 같은 서머리 중 하나를 골라 A/B 테스트를 해볼 수 있습니다. 초기에는 거창한 아키텍처보다, 작은 변화가 사용자 만족도와 비용에 어떤 영향을 주는지 체감하는 것이 더 중요합니다. 컨텍스트 엔지니어링과 에이전트 메모리는 아직 빠르게 진화하는 영역입니다. 섣부른 완성형 설계보다, 작은 가설을 세우고 빠르게 검증하는 팀이 한국 시장에서도 결국 앞서갈 가능성이 큽니다.

출처 및 참고 :