세션 비용이 6배로 새던 이유: 컨텍스트를 다시 설계한 기록

BigValue에서 운영하는 부동산 상담 Agent는 이전 대화와 상담 조건을 이어 받아야 해요. 그래서 정책, 도구 계약, 장기기억, 현재 상담 조건이 한 번의 요청에 함께 들어가요. 컨텍스트가 길어질수록 비용이 늘어나는 것은 자연스러워 보였어요.

그런데 문제는 길이만으로 설명되지 않았어요. 서울에서 6억 안팎의 전세를 찾던 고객이 “그 조건으로 다른 단지도 볼 수 있을까요?”라고 이어 물으면, 대화는 분명히 이어지는데 비용 관점에서는 그 턴이 새 요청처럼 처리됐어요. 앞선 컨텍스트를 다시 쓴다고 생각했지만 재사용률은 낮았어요. 한 세션이 앞부분을 제대로 재사용했을 때보다 약 6배의 입력 비용을 쓰고 있었습니다.

프롬프트 캐시(prompt cache)는 요청의 앞부분(prefix)이 앞선 요청과 똑같을 때 그 부분을 다시 계산하지 않는 장치예요. 저희가 쓰는 API에서는 캐시로 읽으면 일반 입력의 10분의 1 수준이지만, 캐시에 처음 써 넣을 때는 오히려 일반 입력보다 비쌉니다. 재사용이 실제로 일어나야 이득이 되는 구조라는 뜻이에요.

그래서 런타임이 같은 컨텍스트를 매번 같은 모양으로 만들지 못하면, 대화가 이어지고 있다는 사실만으로 재사용이 보장되지는 않습니다. 저희 사례에서는 이런 것들이 한 요청의 컨텍스트를 바꿀 수 있었어요.

그래서 무엇을 넣느냐만큼 어디에 넣느냐가 중요해집니다. 같은 값이라도 위에 두면 그 아래를 전부 무너뜨리고, 아래로 밀어 두면 그 위는 살아남아요.

처음에는 이 모든 것을 하나의 "긴 프롬프트" 문제로 봤어요. 하지만 길이를 줄이는 일과 컨텍스트를 안정화하는 일은 다릅니다. 전자는 첫 요청에 실리는 입력을 줄이는 선택이고, 후자는 다음 턴에서 같은 앞부분을 다시 쓸 수 있게 만드는 런타임 설계입니다.

저희가 한 일은 컨텍스트를 덜어내는 쪽이 아니었어요. 매 턴 같은 모양으로 다시 쓸 수 있게 만드는 쪽이었습니다. 네 번에 걸쳐 경계를 다시 그었고, 그때마다 비용보다 상담 조건이 유지되는지를 먼저 봤어요.

이 글은 부동산 AI Agent 시리즈에서 실제 운영 사례를 공개 가능한 범위로 일반화한 내용입니다.

상시 주입에도 줄이면 안 되는 선이 있다

가장 눈에 띄는 것부터 손댔어요. 매 요청에 통째로 따라 들어가던 문서입니다.

상시 주입 문서는 시간이 지나면 자연스럽게 길어져요. 새로운 정책이 생기고, 다룰 도구가 늘고, 예외 처리와 운영 규칙이 그때마다 더해지기 때문입니다.

저희는 먼저 상시 주입의 역할을 다시 나눴어요. 매 요청에 남길 것은 목표, 안전·승인 경계, 핵심 도구 계약처럼 빠지면 안 되는 정보예요. 상세 절차와 긴 참고자료, 드문 예외는 필요할 때만 주입하도록 옮겼습니다.

상시 주입
- 목표와 역할
- 안전·승인 경계
- 핵심 도구 계약

필요할 때만 주입
- 상세 절차
- 긴 참고자료
- 드문 예외와 보조 규칙

이렇게 나누면 첫 요청이 그만큼 가벼워집니다. 다만 문서를 짧게 만들었다고 해서 다음 턴의 재사용까지 자동으로 회복되는 것은 아니에요. 짧아진 컨텍스트 안에도 매번 달라지는 값이 남아 있으면, 다음 요청은 여전히 다른 입력이 될 수 있습니다.

또한 문서 축소에는 분명한 트레이드오프가 있어요. 도구를 호출할 단서나 안전 규칙까지 함께 지우면, 비용은 줄어도 상담 품질이 흔들릴 수 있어요. 그래서 대표 상담 유형을 고정하고 단계별로 비교해, 필요한 규칙과 도구 조건이 유지되는지 확인했어요.

작은 동적 값 하나가 프롬프트 캐시를 깬다

문서를 줄이고 나서도 다음 턴은 여전히 새 요청처럼 처리됐어요. 그래서 이번에는 남은 컨텍스트를 한 줄씩 대조해 봤습니다.

원인은 덩치 큰 문서가 아니었어요. 매 호출마다 새로 찍히는 현재 시각처럼, 사람에게는 거의 보이지 않는 값이었습니다.

상시 주입되는 파일에 현재 시각을 적어 넣는 훅이 있었어요. 초 단위까지 들어갔고, 매 턴 다시 쓰였습니다.

대화 화면만 보면 아무 문제가 없습니다. 비용이 새는 자리는 상담을 받는 쪽에서 끝내 보이지 않아요.

캐시가 재사용하는 대상은 "비슷한 대화"가 아니라 글자까지 같은 컨텍스트예요. 현재 시각, 요청 식별값, 누적 실행 로그, 정렬 순서가 달라지는 목록은 모두 앞부분에 섞이면 같은 문제를 만들 수 있습니다.

저희는 현재 시각을 앞부분에서 빼냈어요. 그 한 줄을 빼자 두 번째 턴의 캐시 쓰기가 99.8% 줄었습니다. 고친 분량은 한 줄이지만 판단이 간단하지는 않았어요. 그 값이 날짜와 요일 인식을 떠받치고 있었다면, 비용을 줄이는 대신 상담 기능을 잃었을 테니까요.

그래서 변경 뒤에는 날짜·요일 인식이 유지되는지를 별도로 확인했어요. 고객이 “이번 주에 올라온 실거래 있어요?”라고 물으면 Agent는 오늘이 며칠인지 알아야 조회할 구간을 정할 수 있습니다. 비용 최적화의 결과를 판단할 때 캐시 읽기와 쓰기만 보지 않고, 사용자가 실제로 받는 상담 조건이 유지되는지도 같이 확인해야 한다고 봤습니다.

사용자 대화만 비용을 만들지 않는다

현재 시각을 빼내자 캐시는 다시 적중했어요. 그런데 얼마 지나지 않아 재사용률이 또 내려갔습니다. 이번에는 앞부분이 흔들린 흔적이 없었어요.

처음에는 실제 상담 요청이 비용의 중심이라고 생각했어요. 하지만 상태를 확인하는 heartbeat, 시작 시 규칙을 불러오는 bootstrap, 응답 없이 끝나는 자동 점검도 세션과 컨텍스트를 만들 수 있습니다.

자동 실행이 자주 같은 세션을 열고 컨텍스트를 반복해서 만들면, 실제 상담과 무관한 캐시 쓰기가 쌓일 수 있어요. 이 상태에서는 무엇이 비용을 만들었는지 관측하기도 어려워져요. 사용자 대화의 비용처럼 보이는 일부가 자동 실행 경로에서 나온 것일 수 있기 때문입니다.

그래서 세션을 종류별로 갈라서 봤어요. 상담이 끝난 웹챗 세션, 기록을 남기는 세션, 늘 열려 있는 대기 세션의 재사용률을 따로 재보니 대기 세션 하나만 유독 낮았습니다. 전체 평균만 봤다면 어느 경로가 비용을 만드는지 끝내 몰랐을 거예요.

사용자 상담
→ 필요한 컨텍스트만 주입

상태 점검·반복 자동화
→ Agent 세션이 꼭 필요한지 검토
→ 가능한 경우 별도 실행 경로로 분리

시작 시 상세 규칙
→ 원본에 보존하고 자동 주입에서는 분리

여기서 목표는 자동화를 없애는 일이 아니었어요. 어떤 작업이 정말 전체 상담 컨텍스트를 열어야 하는지, 어떤 작업은 더 가벼운 경로로 옮길 수 있는지를 구분하는 일이었어요.

분리 뒤에는 실제 상담이 필요한 응답을 계속 만들 수 있는지 확인했어요. 운영 점검이 빠졌거나 복구가 늦어졌다면 비용이 줄어도 받아들일 수 없는 변경이에요. 따라서 사용자 대화와 자동 실행은 비용뿐 아니라 기능 검증에서도 따로 관찰해야 합니다.

기억은 지우지 않고, 넣을 것만 고른다

자동 실행까지 정리하고 나니 마지막으로 하나가 남았어요. 상담이 이어질수록 계속 불어나는 쪽입니다.

상담 Agent에는 장기기억이 필요해요. 사용자가 중요하게 보는 조건, 이전 대화에서 정리한 맥락, 이후 다시 확인해야 할 정보가 쌓이기 때문입니다.

하지만 원본 기록을 매 턴 그대로 프롬프트에 넣는 방식에는 한계가 있어요. 메모가 추가될 때마다 컨텍스트의 모양이 달라지고, 현재 질문과 직접 관계없는 과거 정보까지 함께 들어와요. 재사용은 약해지고, 모델이 지금 무엇을 우선해야 하는지도 흐려질 수 있습니다.

그래서 저장용 장기기억과 추론용 컨텍스트를 분리했어요.

네 가지 원인은 서로 달라 보이지만, 컨텍스트의 모양을 바꾼다는 점에서 같은 문제였어요.

도식에서 원본 저장소 아래 놓인 것이 추론에 넣을 안정 조건이고, 이 글에서는 줄여서 core라고 부를게요. 매번 달라져 core 밖으로 밀어낸 값들은 변동 컨텍스트(volatile context)입니다.

core에는 현재 응답에 직접 필요한 조건만 남겨요. 반면 누적 메모처럼 자주 바뀌는 기록은 core에 들어가지 않도록 막아요. 필요한 과거 상세는 원본에 보존하고, 질문이 요구할 때만 다시 접근할 수 있어야 합니다.

예를 들어 서울에서 6억 안팎의 전세를 찾는 고객이라면, 다음 턴의 추론에 필요한 것은 지역과 예산대와 거래유형입니다. 상담을 이어갈 때마다 덧붙는 메모 원문은 저장소에 그대로 두고 core에는 넣지 않아요. 무엇을 기억할지는 기억 설계를 다룬 글에서 정했고, 이 글에서 정한 것은 그 기억을 매 턴 어떤 모양으로 넣을지입니다.

core에 들어갈 항목은 매 턴 판단하지 않고 미리 정해 고정했어요. 지역, 예산대, 거래유형처럼 다음 응답에 필요한 항목만 목록에 올리고, 목록에 없는 값은 아무리 최근에 갱신됐어도 넣지 않습니다. 그렇게 걸러내니 프로필 주입량이 97.3% 줄었어요. 프로필은 요청 앞부분의 한 조각이라, 첫 턴 전체 캐시 쓰기로 보면 38.6% 줄었습니다.

원본을 그대로 넣은 경로는 메모가 갱신될 때마다 캐시가 빗나갔고, core만 골라 넣은 경로는 다음 턴부터 캐시가 적중했어요. 다만 core라고 해서 언제나 안정적인 것은 아닙니다. 최근 상담 요약처럼 매 턴 바뀌는 내용을 core에 넣으면 같은 문제가 다시 생길 수 있어요. core와 변동 컨텍스트의 경계는 한 번 정하고 끝나는 설정이 아니라, 운영 중 계속 점검해야 할 계약입니다.

오래 남긴다고 이득이 되지는 않는다

컨텍스트를 안정화한 뒤에는 캐시 보존 정책도 다시 봐야 했어요. 캐시를 오래 유지하면 언제나 유리할 것 같지만, 보존 기간을 늘리는 선택에는 쓰기 비용이 더 붙습니다. 보존을 길게 잡은 만큼, 그 기간 안에 재사용이 실제로 일어나야 값을 합니다.

운영 기록에서는 장기 재사용보다 새로 시작되는 요청의 쓰기 비중이 큰 구간이 있었어요. 그래서 보존 기간을 짧은 대화 창에 맞추고, 컨텍스트 정리 주기도 함께 조정했습니다.

이것은 장기 캐시를 포기했다는 뜻이 아니에요. 실제 사용 간격과 읽기·쓰기의 비중에 맞춰 재사용 정책을 정한 것이에요. 적용 뒤에는 한동안 쓰지 않던 세션이 끊기거나 시간 초과 없이 이어지는지 확인했고, 필요한 상담 응답 계약도 별도로 검증했습니다.

다만 아직 재보지 않은 것이 있어요. 보존 기간을 줄인 뒤 세션이 정상으로 도는 것은 확인했지만, 그래서 비용이 실제로 얼마나 줄었는지는 며칠치 로그를 이전 설정과 나란히 놓고 봐야 답할 수 있습니다.

Agent 비용은 재사용 가능한 컨텍스트의 설계 문제다

처음에는 긴 프롬프트를 줄이는 일로 시작했어요. 하지만 실제로 재설계해야 했던 것은 프롬프트의 글자 수가 아니라, 다음 턴에도 같은 내용을 같은 모양으로 재사용할 수 있게 만드는 런타임 컨텍스트였습니다.

상시 주입을 줄이고, 동적 값을 앞부분에서 빼고, 자동 실행을 별도 비용 경로로 보며, 장기기억은 그대로 두되 추론에는 안정적인 core만 골라 넣는 동안, 실제로 바뀐 것은 무엇을 지우느냐가 아니라 무엇을 매 턴 같은 모양으로 두느냐였습니다.

네 번 모두 완료 조건을 비용이 아니라 기능과 안전으로 잡았어요. 캐시 히트가 늘어도 필요한 안전 규칙이 빠지거나 날짜를 잘못 이해하면 개선이라고 할 수 없으니까요. 확인한 질문은 매번 같았습니다. 컨텍스트를 덜 넣은 뒤에도 이 상담에 필요한 조건이 그대로 남아 있는지였어요.

이 기준은 프롬프트 캐시에만 적용되는 원칙이 아닙니다. Agent 런타임에서 비용을 줄이는 변경은 대체로 컨텍스트, 상태, 권한, 검증의 경계를 함께 바꾸기 때문이에요.

Agent 비용은 모델의 단가나 프롬프트 길이만으로 결정되지 않아요. 반복할 컨텍스트를 어디까지 안정화할지, 어떤 정보는 저장만 하고 어떤 정보는 추론에 넣을지, 자동 실행이 어떤 상태를 만들지까지 포함한 설계의 결과입니다.

Agent 비용은 프롬프트를 얼마나 줄였는지가 아니라, 다음 턴에 캐시가 적중하도록 설계했는지가 정합니다.