문맥을 줄이는 일이 아니라, 필요한 근거를 남기는 일

한빛교육과 교육장 금액, 토큰 수, 요금은 계산을 보여 주기 위한 가정이다. 실제 견적이나 측정값이 아니다.

신입에게 "행사 장소를 골라 주세요"라고만 말하면 일이 시작되지 않는다. 날짜, 인원, 예산, 들어갈 수 있는 입구, 후보별 견적이 같이 있어야 한다. AI도 마찬가지다. 그 순간 답에 필요한 재료가 있어야 하고, 그 재료를 문맥이라고 부른다.

문맥 최적화는 그 재료를 고르고, 정리하고, 다음에 다시 쓰는 일이다. 자료를 무조건 짧게 만드는 것이 목표는 아니다. 정확한 답에 필요한 조건과 근거를 남기면서, 비용과 기다리는 시간을 줄이는 것이 목표다.

문맥은 지금 펼쳐 둔 서류다

여기서는 문맥을 작업 책상에 펼친 서류로 본다. 사용자의 질문만 올라오는 것이 아니다. 지시문, 지금까지의 대화, 검색 결과, 도구가 가져온 자료도 책상 위에 놓인다. 이미지나 음성도 모델이 받는 방식으로 처리할 수 있지만, 이 글은 글을 다룬다.

학습으로 얻은 일반 지식은 그 직원의 배경지식에 가깝다. 이번 주에 바뀐 행사 예산은 새 서류를 줘야 안다. 대화에서 "기억한다"는 말도, 실제로는 서비스가 이전 내용을 다시 넣거나 다른 저장소에서 찾아 주는 동작일 수 있다. 모든 서비스가 대화를 같은 방식으로 보관하거나 전달하지는 않는다.

모델은 글을 토큰이라는 조각으로 나누어 처리한다. 토큰은 단어와 같지 않다. 짧은 단어 하나가 한 조각일 수도 있고, 한국어 어절이나 숫자, 기호가 여러 조각으로 나뉠 수도 있다. 같은 글도 모델과 나누는 방식에 따라 개수가 달라진다. 글자 수를 어떤 숫자로 나눠 실제 사용량이라고 단정하면 안 된다.

입력 토큰은 AI에 주는 재료의 분량이고, 출력 토큰은 AI가 만드는 답의 분량이다. 서비스에 따라 내부에서 추론하는 분량도 청구된다. 화면에 보이는 답의 길이만으로 전체 요금을 알 수는 없다.

문맥 창은 한 번의 처리에서 다룰 수 있는 토큰 범위다. 모델마다 입력, 출력, 내부 추론이 그 한도에 어떻게 들어가는지 다르므로 해당 문서를 봐야 한다. 책상이 커도 서류를 정확히 집어 내는 능력이 저절로 좋아지지는 않는다. 긴 입력에서 정보가 어느 위치에 놓였는지에 따라 활용이 달라진다는 연구가 있다. 다만 그 연구 결과를 모든 최신 모델의 실패율로 일반화할 수는 없다. Lost in the Middle은 그 위치를 다룬 논문이다.

문맥 최적화는 이 책상 위를 정리하는 일이다. 모델을 다시 학습시키거나, 모델의 크기를 줄이는 기술과는 구분해야 한다.

먼저 세 가지만 기억하면 된다.

• 많이 넣었다고 잘 활용하는 것은 아니다. 적게 넣었다고 효율적인 것도 아니다. 필요한 사실을 빠뜨리면 다시 찾고 다시 답하는 비용이 생긴다.
• 문맥을 고르고 요약하는 일은 보내는 정보량을 바꾼다. 프롬프트 캐싱은 이미 계산한 부분을 다시 쓴다. 입력 토큰이 준 것과 청구액이 준 것은 따로 확인해야 한다.
• 좋은 방법은 업무마다 다르다. 간단한 정리부터 시작하고, 같은 질문에 대한 답의 품질과 전체 비용을 함께 비교하는 편이 안전하다.

한빛교육은 장소를 고르려 한다

가상의 한빛교육은 서울에서 직원 30명을 위한 교육을 준비한다. 담당자가 AI에 계획서, 이메일, 여러 교육장 견적, 지난 대화를 주었다. 전체 입력이 80,000토큰이라고 가정한다. 이 숫자는 계산을 쉽게 하려고 정한 값이고, 페이지 수를 환산한 것이 아니다.

자료 안에 조건이 흩어져 있다.

• 행사는 11월 20일이고, 참석자는 30명이다.
• 처음 예산은 500만 원이었다. 마지막 정정 메시지에서 부가세를 포함해 480만 원으로 낮췄다.
• 계단을 이용하지 않고 입장할 수 있어야 한다. 채식 식사 3인분이 필요하고, 참석자 촬영은 금지한다.
• 담당자는 비교 보고서만 요청했다. 예약이나 결제는 요청하지 않았다.

최종 질문은 "마지막 조건에 맞는 교육장 두 곳을 고르고 이유를 정리해 줘"다. 이때 가장 중요한 정보가 가장 긴 문서에 들어 있는 것은 아니다. "예산을 480만 원으로 수정합니다"라는 짧은 문장이 후보를 바꾼다.

네 후보 모두 해당 날짜에 예약할 수 있는지, 채식 식사를 제공하는지, 촬영 금지 조건을 지키는지 확인했다고 가정한다. 이 사례에서는 다와 라가 조건에 맞는다. 가는 최신 예산을 넘고, 나는 계단 없이 들어갈 수 없다.

자료를 줄여도 성공이려면 세 가지가 유지되어야 한다. 다와 라를 고르고, 가와 나를 뺀 이유를 정확히 말하고, 예약을 진행하지 않아야 한다. 예산 정정이나 접근성 조건을 잃었다면, 토큰을 크게 줄였어도 실패다. 뒤의 방법은 모두 이 기준으로 본다.

실제 업무에서는 "확인했다고 가정한" 내용에도 근거 문서와 시각을 붙여야 한다. 견적과 예약 가능 여부는 시간이 지나면 바뀐다.

창고의 서류를 전부 올리지 않는다

RAG는 검색 증강 생성을 줄인 말이다. 이름을 외울 필요는 없다. 창고의 서류를 매번 전부 책상 위에 올리는 대신, 질문에 필요한 자료를 먼저 찾아 AI에게 주는 방식이다. 검색과 답변 생성을 이어 붙인 구조다. 초기 연구로는 Lewis 등의 논문이 자주 인용된다.

한빛교육에 적용하면 순서는 이렇다. 견적과 행사 조건을 검색할 수 있는 저장소에 넣는다. 질문이 들어오면 날짜, 인원, 최신 예산, 접근성 조건을 확인한 뒤 관련 견적과 조건을 찾는다. AI는 그 결과를 근거로 후보를 비교한다. 80,000토큰 전체가 아니라 필요한 일부만 넣을 수 있다.

검색은 단어를 찾는 일일 수도 있고, 뜻이 비슷한 문장을 찾는 일일 수도 있다. 후자는 문장을 숫자 목록으로 바꿔 가까운 정도를 계산한다. 이 숫자 표현을 임베딩이라고 한다. 다만 "비슷한 내용"과 "정답의 근거"는 같지 않다. "휠체어"라는 단어가 없는 문서의 "엘리베이터 없이 지하 1층"이 이번 질문에는 더 중요한 근거일 수 있다.

같은 장소 이름이 다른 행사 자료에도 나온다. 검색할 때 회사, 프로젝트, 문서 권한, 작성일, 문서 버전을 함께 써야 한다. 이런 부가 정보를 메타데이터라고 부른다. 특히 사용자가 볼 수 없는 자료가 검색 결과로 들어오지 않도록, 접근 권한부터 확인해야 한다. OWASP의 벡터와 임베딩 항목도 이 혼합과 권한 문제를 다룬다.

검색 결과에는 원문 위치를 붙여 둔다. AI가 "다는 470만 원입니다"라고 말하면, 어느 견적의 어느 항목을 근거로 했는지 확인할 수 있어야 한다. 출처가 있다는 사실만으로 답이 맞는 것은 아니다. 인용한 문장이 그 주장을 실제로 받치는지도 봐야 한다.

자료가 많고 질문마다 필요한 부분이 다를 때 RAG가 유리하다. 사내 규정 질의응답, 제품 설명서, 고객 지원이 그런 일이다. 반대로 "모든 견적에서 빠진 항목을 빠짐없이 찾아라" 같은 전수 검토는 일부 검색 결과만으로 답하면 빠뜨리기 쉽다. 전체 문서를 단계적으로 훑거나, 별도의 검증이 필요하다.

찾지 못한 근거를 AI가 상상으로 채우게 두어서는 안 된다. 검색 결과가 부족하면 질문을 바꿔 다시 찾거나, 필요한 문서를 요청하거나, "확인할 수 없다"고 답하는 길을 만든다. RAG는 오류를 없애는 장치가 아니라, 필요한 근거를 전달하는 방법이다.

자르는 위치와 다시 세우는 순서

긴 문서는 보통 작은 단위로 나누어 저장한다. 이를 청킹이라고 하고, 나뉜 단위를 청크라고 부른다. 책을 통째로 꺼내기보다 관련 절을 찾아 꺼내는 방식이다. 문제는 어디서 잘라야 뜻이 유지되는가다.

교육장 견적을 일정한 글자 수마다 자르면 "470만 원"과 "부가세 포함"이 다른 조각으로 갈라질 수 있다. "계단 없는 입장 불가"에서 "불가"만 빠져도 판단이 뒤집힌다. 제목, 문단, 표의 한 행, 조건과 예외는 가능한 한 함께 보관해야 한다.

작게 나누면 관련 부분을 정밀하게 찾기 쉽지만 앞뒤가 끊긴다. 크게 나누면 문맥은 남지만 필요 없는 내용이 따라온다. 경계를 겹쳐 저장하면 잘림은 줄지만 중복과 비용이 늘어난다. 모든 문서에 통하는 크기는 없다. 질문과 문서 형식에 맞춰 시험해야 한다.

검색에서 후보 20개를 찾았다고 하자. 재정렬, 또는 리랭킹은 그 후보를 질문과 다시 비교해, 답에 실제로 도움이 될 가능성이 높은 순서로 줄 세우는 일이다. 처음 찾기는 빠른 후보 수집이고, 재정렬은 더 꼼꼼한 2차 검토에 가깝다. 추가 시간과 비용이 들 수 있다. Anthropic의 Contextual Retrieval은 조각에 맥락을 붙이고 재정렬을 쓰는 사례를 보여 준다.

일반 홍보문은 "편리한 접근성"을 반복해 검색 점수가 높을 수 있다. 이번 질문에 더 중요한 문서는 현재 견적의 "입구 계단 8개, 승강기 없음"일 수 있다. 재정렬은 이런 문서를 앞에 올리는 데 도움을 준다. 다만 처음 검색에서 빠진 문서를 저절로 되살리지는 못한다.

최신 예산 정정, 촬영 금지, 예약 금지는 검색 점수가 낮다고 빠져서는 안 된다. 이런 내용은 현재 작업의 필수 조건으로 따로 두고, 검색된 자료와 함께 전달하는 편이 낫다. 좋아 보이는 문서 몇 개와, 답에 필요한 근거가 갖춰진 상태는 다르다.

• 가격에는 통화, 세금 포함 여부, 적용 날짜를 붙인다.
• 표를 잘랐다면 열 이름과 단위를 각 조각에 남긴다.
• 검색된 문장만으로 판단하기 어려우면 앞뒤 문단이나 원문 전체를 연다.

검색 구조를 이렇게 다듬으면, 더 강한 압축을 들이지 않아도 불필요한 입력이 줄어든다. 문서 정리와 검색 품질을 먼저 보는 이유다.

최근 대화만 남기면 금지가 빠진다

가장 단순한 방법은 최근 대화 몇 개만 남기는 것이다. 짧은 대화 창, 또는 슬라이딩 윈도라고 부른다. 오래된 대화를 버리므로 입력이 빨리 줄고 구현도 비교적 쉽다. 다만 "오래되었다"와 "중요하지 않다"는 같은 뜻이 아니다.

한빛교육에서 "참석자 촬영 금지"가 처음에 나왔고, 최근 대화에는 없다고 하자. 최근 메시지만 남기면 예산은 맞아도 촬영 조건을 놓칠 수 있다. 반대로 최종 예산 정정이 최근 메시지에 있다면, 오래된 계획서의 500만 원을 그대로 쓰는 오류를 막는 데 도움이 된다.

실무에서는 최근 대화와 현재 작업 상태를 나누어 두는 편이 유용하다. 대화는 사람이 주고받은 과정이고, 작업 상태는 지금 지켜야 할 사실과 남은 일의 목록이다. 최근 대화 몇 개를 남기면서 필수 상태를 따로 붙이면, 오래된 중요 조건을 지킬 수 있다. OpenAI의 세션 메모리 예시도 최근 대화를 유지하면서 요약을 곁들이는 쪽을 보여 준다.

이 사례의 작업 상태는 이렇게 적을 수 있다.

• 목표는 교육장 두 곳의 비교 보고서다.
• 최신 조건은 11월 20일, 30명, 부가세 포함 480만 원 이하다.
• 계단 없는 입장, 채식 3인분, 촬영 금지가 필요하다.
• 예약과 결제는 허용되지 않았다.
• 500만 원은 폐기된 이전 예산이다. 480만 원에는 정정 메시지의 시각과 출처를 붙인다.

문맥 편집은 대화 전체를 버리지 않고, 오래된 검색 결과나 도구 실행 기록만 정리하는 일도 포함한다. 이런 원시 기록은 크게 줄일 수 있다. 그래도 아직 필요한 실행 결과와 근거는 먼저 남겨야 한다. Anthropic의 context editing이 오래된 도구 결과를 정리하는 기능이다.

예산의 현재값은 480만 원으로 갱신하되, 변경 이력에는 500만 원에서 바뀌었다는 사실을 남길 수 있다. 현재 판단에 예전 값이 섞이지 않으면서, 나중에 왜 결론이 달라졌는지 설명할 수 있다. 서로 충돌하는 지시의 우선순위는 모델의 추측에만 맡기지 않는다.

대화에서 상태를 뽑는 과정도 틀릴 수 있다. "480만 원으로 할 수 있을까요?"라는 질문과 "480만 원으로 확정합니다"라는 결정은 다르다. 불확실한 값은 확정된 사실처럼 저장하지 말고, 상태부터 표시한다.

짧은 창은 한 번의 질문이나, 앞선 내용이 거의 필요 없는 대화에 맞는다. 긴 협상, 조건이 쌓이는 업무, 예외가 중요한 검토에는 필수 상태나 원문 검색을 함께 쓰는 편이 낫다.

요약은 예쁜 문장보다 항목이다

요약은 여러 문장을 짧은 새 문장으로 다시 쓰는 방법이다. 회의 녹취를 회의록으로 바꾸는 일과 비슷하다. 최근 대화는 그대로 두고 오래된 대화만 요약하면, 진행 상황을 적은 분량으로 이어 갈 수 있다. 공급자가 제공하는 자동 문맥 정리도 이 계열을 포함할 수 있다. OpenAI compaction과 Anthropic compaction이 그렇다. 이름이 같아도 출력 형식, 다른 도구로의 이전, 지원 모델이 다르므로 해당 문서를 확인해야 한다.

사례를 "예산에 맞는 편리한 교육장을 찾고 있다"라고 줄이면 문장은 단정하지만 쓸모가 없다. 숫자, 날짜, 예외, 금지 조건이 빠졌기 때문이다. 업무에 맞춰 남겨야 할 항목을 정해 두는 편이 안전하다.

이 사례의 요약에는 다음이 남아야 한다. "11월 20일 직원 30명 교육. 최종 예산은 부가세 포함 480만 원 이하. 계단 없는 입장, 채식 3인분, 촬영 금지. 후보 비교만 하고 예약과 결제는 하지 않는다. 이전 예산 500만 원은 폐기." 출처와, 아직 확인하지 못한 사항은 따로 붙인다.

요약을 반복하면 작은 누락이 쌓인다. 첫 요약에서 "부가세 포함"이 빠졌는데 다음 요약이 그 요약만 읽으면, 원래 조건을 되돌릴 길이 없다. 요약본을 다시 요약할수록 이런 손실이 굳을 수 있다. 중요한 항목은 항목으로 따로 보존하고, 필요할 때 원문으로 돌아갈 수 있어야 한다.

요약은 새 문장을 만들므로 없던 뜻을 더할 위험도 있다. "채식 식사를 선호한다"가 "채식주의자다"로 바뀌면 범위가 넓어진다. 이 행사에 필요한 식사 조건을, 그 사람의 지속되는 특성으로 저장해서는 안 된다.

언제 요약하고 무엇을 남길지도 정해 둔다.

• 문맥이 한도에 닿기 전에 여유를 두고 오래된 부분을 요약한다. 출력과 새 검색 결과가 들어올 자리도 남긴다.
• 결정, 숫자, 예외, 최신 정정, 권한, 끝나지 않은 작업을 요약 양식에 넣는다.
• 직접 인용이 필요한 문구나 계약 조항은 원문을 유지한다. 요약은 원문을 대신하는 증거가 아니다.
• 요약을 만드는 데 든 모델 비용과 시간을 따로 적는다. 매번 요약하면 아낀 돈보다 추가 비용이 커질 수 있다.

OpenAI 문서는 compaction이 입력의 앞부분을 바꾸어, 이전에 계산해 둔 캐시를 덜 쓰게 될 수 있다고 설명한다. 요약으로 토큰을 줄이는 일과 캐시를 재사용하는 일이 같은 방향으로 움직이지 않을 수 있다는 뜻이다.

짧은 단어 하나가 결론을 뒤집는다

문맥 압축은 필요한 정보를 더 적은 입력으로 전달하려는 방법을 넓게 부르는 말이다. 요약을 포함해 쓰기도 하지만, 여기서는 고른 자료에서 덜 중요한 문장이나 토큰을 줄이는 처리까지 나누어 본다. "압축"이라는 이름이 ZIP 파일처럼 원문을 그대로 되돌릴 수 있다는 뜻은 아니다.

세 가지로 나누면 역할이 보인다.

첫째, 중복과 필요 없는 형식을 정리한다. 같은 견적이 이메일 아래에 여러 번 붙어 있다면 반복 구간을 뺄 수 있다. 두 견적이 거의 같아 보여도 날짜나 가격이 바뀌었다면 다른 버전이다. 겉모양이 비슷하다는 이유만으로 지우면 안 된다.

둘째, 문장이나 구절을 골라 남긴다. 교육장의 홍보 문구는 빼고 가격, 정원, 이동 조건, 날짜를 남기는 식이다. 원문에서 고르므로 근거를 따라가기 쉬운 편이지만, 잘린 문장의 조건이나 주체가 바뀌지 않도록 해야 한다.

셋째, 모델로 중요도가 낮다고 본 토큰을 빼거나 내용을 다시 쓴다. LLMLingua는 이런 문맥 압축을 연구하고 구현한 사례다. 압축 뒤의 문장이 사람에게 다소 어색해도, 목표 모델이 활용할 수 있도록 설계하는 방식이 있다. 논문이나 제품이 말한 압축률을 모든 업무에 그대로 적용할 수는 없다.

견적의 "부가세 별도"에서 "별도"가 사라지거나, "계단 없는 입장 불가"에서 "불가"가 사라지면 뜻이 바뀐다. 전체 글자 가운데 손실은 작아 보여도, 결정에서의 손실은 크다. 숫자, 부정 표현, 날짜, 조건, 예외, 인용문을 보호할 수 있는지 확인해야 한다.

지금 질문에 맞춘 압축도 가능하다. 가격 비교라면 가격을 우선 남기고, 접근성 검토라면 이동 조건을 우선 남긴다. 질문이 바뀌면 이전 압축 결과는 더 이상 충분하지 않을 수 있다. 원문과 출처를 보관해야 하는 이유다.

입력을 70% 줄였다는 숫자는, 남긴 정보로 일을 끝냈는지를 말해 주지 않는다. 압축 모델을 한 번 더 호출하는 비용, 오가는 시간, 기존 캐시를 덜 쓰게 되는 손실도 생긴다. 이미 짧은 질문에는 압축하지 않는 편이 나을 수 있다.

처음에는 중복을 빼고 필요한 문서를 고른다. 그래도 입력이 크거나 비용이 높을 때 압축을 비교하는 것이 합리적이다. 세게 줄인 버전이 실패하면, 원문이나 더 넓은 문맥으로 다시 답하는 길도 준비한다.

장기기억은 다른 서랍이다

장기기억은 지금 책상에 펼친 문맥과 다르다. 나중에 다시 쓸 사실이나 선호, 프로젝트 상태를 다른 곳에 두고, 필요할 때 꺼내 문맥에 넣는 방식이다. 저장한 내용이 모두 매번 모델에 전달되는 것은 아니다. 저장과 검색은 별개의 단계다. LangMem은 기억을 뽑고, 찾고, 요약하는 구현의 한 예다.

기억에도 종류가 있다. "11월 20일 행사 예산 480만 원"은 특정 프로젝트의 상태다. "보고서는 요약을 먼저 보여 달라"는 사용자의 선호일 수 있다. "지난 검토에서 나 후보는 계단 때문에 제외했다"는 작업 이력이다. 이 셋을 한 덩어리로 저장하면, 다른 행사에 지난 예산이 적용되는 오류가 생긴다.

그래서 기억에는 누구에 관한 것인지, 어느 프로젝트에 적용되는지, 언제 확인했는지, 원문 출처가 어디인지, 확정인지 추정인지를 붙인다. 행사가 끝난 뒤 현재 조건에서 뺄지, 이력으로만 남길지도 정한다.

저장보다 수정과 삭제가 더 어려울 수 있다. 예산이 480만 원으로 바뀌면, 오래된 500만 원을 현재 사실처럼 검색하지 않아야 한다. 잘못 저장한 내용을 사용자가 고칠 수 있어야 하고, 삭제를 요청하면 원본뿐 아니라 검색용 사본과 거기서 나온 요약까지 범위를 확인해야 한다. 검색에 안 나오게 한 것과, 보관 중인 사본을 모두 지운 것은 다르다.

추정한 선호를 확정된 사실처럼 저장하지 않는 일도 중요하다. 한 번 채식 메뉴를 요청했다고 그 사람의 식습관으로 단정하지 않는다. 사람별, 회사별 저장 범위를 나누지 않으면 다른 사용자의 기억이 섞인다.

RAG와 장기기억은 겹칠 수 있다. RAG는 필요한 외부 자료를 찾는 처리 방식이다. 장기기억은 오래 보관할 상태나 정보를 관리하는 기능이다. 기억 저장소를 RAG처럼 검색할 수도 있고, 핵심 프로필 몇 줄은 검색 없이 항상 넣을 수도 있다. 둘을 경쟁 기술로만 볼 필요는 없다.

여러 대화와 날짜에 걸쳐 일을 이어 갈 때 장기기억이 유용하다. 한 번 읽고 끝나는 문서 요약에는 저장과 갱신 체계가 과할 수 있다. 뽑고, 저장하고, 찾고, 정리할 때마다 비용이 들 수 있으므로, 기억을 많이 쌓는 것 자체를 목표로 삼지 않는다.

개인정보가 들어가면 필요한 범위만 저장하고, 보존 기간과 접근 권한을 정한다. 서비스마다 저장 위치, 학습에의 이용, 삭제, 보안 설정이 다르다. "AI 기억"이라는 말 하나로 같게 취급하면 안 된다.

캐시는 서류를 줄이는 일이 아니다

프롬프트 캐싱은 같은 입력의 앞부분을 다시 처리할 때, 이전에 계산한 결과를 재사용하는 기능이다. 읽을 서류를 버리는 대신, 이미 읽어 둔 공통 부분의 계산을 다시 활용하는 일에 가깝다. 입력 내용이 짧아졌다는 뜻은 아니고, 문맥 창의 한도가 저절로 늘어나는 것도 아니다. OpenAI의 프롬프트 캐싱과 Anthropic의 프롬프트 캐싱은 모델별 조건과 요금이 다르다.

많은 구현은 입력의 앞부분, 곧 접두부가 같은지를 본다. 고정된 지침과 자주 쓰는 자료를 앞에 두고, 매번 달라지는 질문을 뒤에 두면 재사용에 도움이 될 수 있다. 공급자마다 최소 길이, 유지 시간, 지원 모델과 설정이 다르다. 뜻만 비슷한 문장으로 바뀌어도 같은 캐시로 처리된다고 가정하면 안 된다.

교육장 비교 기준 20쪽을 매번 그대로 넣는다면 캐싱의 이점이 있을 수 있다. 요청마다 자료를 요약해 순서와 표현을 바꾸면, 입력은 줄어도 이전 캐시를 덜 쓸 수 있다.

캐시를 만드는 비용과 읽는 비용이 다를 수 있고, 보관 시간에 따른 요금도 있을 수 있다. "캐싱은 언제나 공짜 저장이고 읽기만 싸다"라고 가정하지 않는다. 지금 쓰는 모델의 사용량 항목과 청구서를 확인한다.

이 기능은, 비슷한 질문에 예전 답을 그대로 돌려주는 답변 캐시와도 다르다. 예전 답을 재사용하면 계산은 더 줄일 수 있지만, 예산이나 견적이 바뀌었는데 오래된 답이 나갈 위험이 있다. 이 글에서 캐시라고 하면, 주로 공급자가 입력 계산을 재사용하는 기능을 뜻한다.

한빛교육이라면 이렇게 겹쳐 볼 수 있다. 촬영 금지와 예약 금지 같은 작업 조건은 유지한다. 오래된 대화는 현재 상태와 근거를 남겨 요약한다. 후보 견적은 검색으로 찾아 가격과 접근성 근거를 넣는다. 반복되는 지침은 가능한 한 같은 자리에 두어 캐시를 쓴다. 그 상태에서도 입력이 크면 문장 단위 압축을 시험한다.

질문은 작업 상태와 검색된 근거를 거쳐 모델에 간다. 장기기억은 필요할 때 더하고, 반복되는 지침은 앞부분이 같을 때 계산만 재사용한다. 조건이 빠지거나 근거가 부족하면 더 넓은 문맥으로 다시 처리한다.

순서는 고정된 법칙이 아니다. 캐시를 잘 쓰는 업무라면 압축을 하지 않는 편이 더 쌀 수 있다. 각 방법이 어느 비용을 줄이고, 어떤 정보를 잃게 할 수 있는지 나누어 재야 한다. Anthropic의 문맥 엔지니어링 글도 한 가지 기술보다 방법의 조합을 말한다.

어디가 낭비인지부터 고른다

"가장 좋은 최적화 기술"보다 "지금 생기는 낭비가 무엇인가"를 먼저 묻는 편이 유용하다. 아래 표는 시작점을 정하는 기준이다. 어느 방법이 언제나 이긴다는 순위가 아니다.

바로 해볼 수 있는 일도 있다. 긴 대화의 중간에 목표, 최신 결정, 금지 사항, 아직 확인하지 못한 항목을 정리해 달라고 요청한다. 그 요약에서 숫자와 조건을 직접 확인하고, 새 대화를 시작한다면 필요한 원문과 함께 전달한다. 중요한 문구는 요약으로 대신하지 않는다.

이 습관이 모든 서비스의 요금을 직접 낮추는 것은 아니다. 정액제 앱에서는 토큰별 비용이 사용자에게 보이지 않을 수 있다. 그래도 조건을 분명히 정리하면 대화를 이어 가거나 오류를 찾는 데 도움이 된다. 내부 캐싱이나 검색 구조를 사용자가 직접 설정할 수 있는지는 제품마다 다르다.

서비스를 만드는 쪽이라면, 입력 구성과 도구 결과를 측정할 수 있는 기록부터 만든다. 그다음 비중이 큰 항목부터 손본다. 개발을 하지 않는 사람도 정답 기준, 필수 조건, 실패 사례를 정하고 결과를 검토할 수 있다. 검색 구현과 권한, 과금 기록은 개발과 보안을 맡은 사람과 함께 설계하는 것이 현실적이다.

최적화를 위해 더 큰 시스템을 만들기 전에, 지금 모델의 기본 기능과 단순한 중복 제거만으로 어디쯤 해결되는지 비교한다. 관리할 부품이 많아질수록 장애와 운영 비용도 늘어난다.

토큰이 줄어도 청구서는 따로다

다음 가격은 계산 방법을 보여 주기 위한 가상 가격이다. 특정 모델의 현재 요금이 아니다. 한 번에 입력 80,000토큰, 출력 2,000토큰을 쓰고, 일반 입력은 100만 토큰당 2달러, 출력은 100만 토큰당 8달러라고 가정한다.

캐시가 없다면 기존 1회 비용은 입력 0.160달러와 출력 0.016달러를 더한 0.176달러다. 최적화로 입력을 20,000토큰으로 줄이면 입력은 0.040달러다. 여기에 출력 0.016달러와 최적화 처리비 0.010달러를 더하면 0.066달러가 된다.

입력 토큰은 75% 줄었지만, 총비용은 62.5% 준다. 출력 비용과 최적화 비용은 남기 때문이다. 같은 조건의 작업 10,000건이면 1,760달러에서 660달러가 된다. 이 계산은 출력량과 성공률이 같고, 다시 시도하지 않는다는 가정에 따른다.

이미 캐시를 잘 쓰고 있다면 이야기가 달라진다. 기존 입력 80,000토큰 중 60,000토큰이 캐시에서 읽히고, 캐시 읽기는 100만 토큰당 0.20달러라고 하자. 이미 만들어진 캐시를 읽는 상황만 비교하고, 캐시를 처음 만드는 비용은 여기서 빼 둔다.

이 경우 입력 토큰 75% 감소는 비용으로 보면 약 2.9% 감소다. 0.068달러에서 0.066달러로 줄었기 때문이다. 작업 10,000건의 절감액도 20달러다.

압축 뒤 5%의 작업에서, 0.176달러짜리 원문 처리가 한 번씩 더 붙는다고 하자. 압축된 호출 0.066달러는 그대로 있고 원문 호출이 추가되는 계산이다. 평균은 0.066달러에 0.0088달러를 더한 0.0748달러가 되어, 기존 0.068달러보다 10% 비싸진다. 토큰을 크게 줄여도, 실패 뒤의 재처리가 그 이득을 지울 수 있다.

실제 계산에는 캐시를 만들고 갱신하는 비용, 검색, 요약, 기억 저장, 재시도, 공급업체 요금, 연결과 운영 비용을 모두 넣는다. 성공률이 다르면 "요청 한 번당 비용"과 함께 "성공적으로 끝낸 업무 한 건당 총비용"을 비교해야 한다. 실패한 답을 싸게 많이 만드는 것은 절감이 아니다.

줄인 문장이 그럴듯한지로는 부족하다

평가는 줄인 문서가 그럴듯한지 읽는 데서 끝나면 안 된다. 같은 질문에 대해, 원래 방식과 최적화한 방식이 실제 업무를 얼마나 해내는지 비교해야 한다. 교육장 사례의 정답 기준은 분명하다. 다와 라를 고르는가. 가와 나를 뺀 이유를 맞히는가. 예약을 하지 않는가.

시험 문제에는 불편한 사례도 넣는다.

• 마지막 메시지에서 예산이 바뀌는 경우와, 처음에 정한 금지 조건이 끝까지 유효한 경우를 모두 넣는다.
• 비슷한 이름의 다른 행사, 오래된 견적, 부가세 별도 가격, 표 아래의 예외 조항을 넣는다.
• 답에 필요한 자료가 없는 질문도 넣어, 없는 근거를 지어내지 않는지 확인한다.
• 한국어 부정 표현, 숫자와 날짜와 단위, 대명사, 긴 문서의 한가운데에만 나오는 조건을 따로 본다.

무엇을 잴지도 미리 정한다.

기다리는 시간은 두 가지로 나눈다. 첫 글자가 나올 때까지, 그리고 답이 끝날 때까지다. p95는 요청 100개를 빠른 순서로 놓았을 때 대략 95번째에 해당하는 시간이다. 평균이 빨라도 일부 요청이 지나치게 느리면 쓰는 경험은 나빠진다.

비교가 공정하려면 모델 버전, 질문, 자료, 출력 조건을 맞추고, 캐시를 처음 만드는 실행과 다시 쓰는 실행을 구분한다. 방법을 고치는 데 쓴 질문과, 마지막으로 평가하는 질문도 나눈다. 소규모 예비 시험은 결함을 찾는 데 유용하지만, 운영이 안정적이라는 입증으로는 부족하다.

"핵심 조건 위반은 허용하지 않는다" 같은 기준을 먼저 정한다. 표본에서 위반이 0건이어도, 실제 오류가 영원히 0이라는 뜻은 아니다. 결과에는 표본 수와 실패 사례를 함께 적고, 중요한 판단은 사람이 검토한다. OpenAI의 평가 가이드도 실제 업무에 맞춘 평가와 지속적인 점검을 말한다.

측정하고, 단순하게 바꾸고, 실패하면 돌아간다

문맥 최적화는 AI 호출 앞에 부품 하나를 넣고 끝나는 일이 아닐 수 있다. 자료의 권한, 버전, 원문 복구, 비용 기록까지 이어져야 실제 서비스에서 판단할 수 있다. 작은 검증을 시작한다면 순서는 이렇게 잡는다.

먼저 지금 상태를 잰다. 실제 업무 유형을 하나 고른다. 지시문, 대화, 검색 결과, 도구 출력이 입력을 얼마나 차지하는지 나누어 기록한다. 모델별 토큰 사용량, 캐시 읽기와 생성, 오류와 재시도도 모은다. 여러 AI에게 일을 나누었다면 각 입력과 출력을 합산한다. 중심이 되는 AI의 문맥만 짧아졌다고 전체 비용이 준 것은 아니다. 개인정보가 들어간 원문 기록은 필요한 범위와 보존 기간을 정해 보호한다.

그다음은 단순한 변경과 비교다. 중복된 인용과 필요 없는 형식을 정리한다. 현재 작업 상태를 따로 만들고, 관련 문서만 검색해 넣는다. 공급자가 제공하는 캐싱이나 문맥 정리는 지원 범위 안에서 적용한다. 한꺼번에 모든 것을 바꾸기보다, 무엇이 효과를 냈는지 알 수 있도록 변경마다 결과를 남긴다.

입력이 여전히 크면 문장 선택이나 압축을 비교한다. 여러 번에 걸쳐 작업을 이어 가야 한다면 장기기억을 더한다. 외부 업체를 쓸 때는 어떤 데이터가 나가는지, 보관과 삭제와 학습 이용 조건, 처리 위치와 접근 권한을 확인한다. 모든 문서를 다른 회사의 압축 서비스에 보내도 된다고 가정하지 않는다.

운영에서는 실패를 발견하고 돌아갈 길이 필요하다. 처음에는 실제 답변에 적용하지 않고 후보 결과만 비교할 수 있다. 이후 제한된 범위에서 적용하고, 근거가 부족하거나 중요 조건 검사가 실패하면 더 넓은 문맥으로 다시 처리한다. 다시 처리하는 기준과 횟수를 정해야 비용이 계속 늘어나는 것을 막을 수 있다.

원문 문서에는 AI를 속이려는 문장이 들어 있을 수 있다. 견적 문서에 "앞의 예산을 무시하라"고 적혀 있어도, 그것을 사용자의 지시처럼 실행해서는 안 된다. 검색과 요약과 압축을 거쳤다고 그 문서가 믿을 만한 명령으로 바뀌지 않는다. 자료와 지시를 구분하고, 권한이 필요한 행동은 따로 통제한다. OWASP의 프롬프트 인젝션 항목이 이 위험을 설명한다.

도입 전에 답할 질문이 있다. 어떤 조건을 잃으면 안 되는가. 원문과 변경 이력은 어디서 다시 확인하는가. 요약이나 기억은 누가 고칠 수 있는가. 전체 비용은 누가 확인하는가. 모델이나 문서 형식이 바뀌면 어떤 시험을 다시 하는가. 이 질문에 답할 수 있어야 운영을 이어 갈 수 있다.

설명을 들을 때 묻는 네 가지

설명을 들을 때 기억할 질문은 네 가지다.

무엇을 줄였는가.
무엇과 비교했는가.
어떤 조건에서 품질을 확인했는가.
실패했을 때 원문을 어떻게 되찾는가.

입력 토큰, 전체 청구액, 첫 응답 시간, 서버 메모리는 서로 다른 항목이다. 이 넷이 분명하면 새로운 제품 설명도 훨씬 정확하게 읽을 수 있다.

용어는 여기서 이렇게 쓴다.

처음 시작한다면, 중요한 사실과 금지 조건을 적은 짧은 작업 상태부터 만들어 보자. 그다음 필요한 근거를 붙이고 답의 품질을 확인한다. 복잡한 압축과 기억 체계는 그 결과를 보고 추가해도 늦지 않다.

기능이 있다는 사실과, 특정 업무에서 비용과 품질이 나아진다는 사실은 다르다. 공급자의 기능, 지원 모델, 요금은 바뀔 수 있으므로 도입할 때는 해당 문서를 다시 확인해야 한다. 이 글의 경제성 예시는 비교하는 구조를 보여 주기 위한 가정이며, 투자나 구매의 수익을 예측한 값이 아니다. 고객 데이터로 유료 API를 실행하거나 공급업체의 청구서를 검증하지는 않았다.