AI 비용 절반 감축, 모델은 안 바꿨습니다

AI 에이전트 비용이 불어난 원인은 제가 질문을 많이 해서가 아니었습니다. 대화 한 번마다 자동으로 따라붙던 설정 파일 하나였습니다. 그것 하나를 걷어내니 턴당 약 26,600토큰이 줄었고, 여기에 나머지 여섯 가지를 합치니 총 28,200토큰 정도가 빠졌습니다. 기본 프롬프트가 절반이 됐습니다. 그리고 이 과정에서 하나를 더 알게 됐습니다. 그전까지 비용 절감이라고 믿고 꼬박꼬박 해왔던 행동 하나는, 절감 효과가 정확히 0이었습니다.

이 글은 도구 설명서가 아닙니다. 회사 일을 돌리면서 쓰는 실무자가 성능을 깎지 않는 선에서 어디까지 줄일 수 있는지, 설정 화면을 직접 열어 항목을 하나씩 눌러보고 그때마다 숫자가 어떻게 움직이는지 재보며 남긴 기록입니다.

턴당 26,600토큰이 매 대화마다 그냥 새고 있었습니다

측정부터 했습니다. 순서가 그렇습니다. 감이 아니라 숫자가 먼저입니다. 설정을 바꾸는 일이 아니라, 지금 얼마가 나가고 있는지 재는 일이 먼저였습니다. 에이전트에게 “지금 매 턴 전송되는 것들의 크기를 항목별로 뽑아라”고 시켰습니다. 이 측정 자체는 파일 크기를 읽어서 더하는 작업이라, 정작 비용은 거의 들지 않습니다.

눈에 띈 것은 순서였습니다. 제가 제일 비쌀 거라 짐작했던 항목은 도구 스키마였는데, 막상 뽑아보니 14.3K 정도로 1위가 아니었습니다. 그보다 두 배 가까운 덩치가 하나 더 있었습니다.

범인은 작업 폴더였습니다. 에이전트 앱의 기본 작업 폴더가 하필 그 앱의 소스코드 폴더로 잡혀 있었고, 그 폴더 안에는 개발자용 지침 파일이 95KB짜리와 11KB짜리로 두 개나 들어앉아 있었습니다. 그리고 작업 폴더에 놓인 지침 파일은 규칙상 매 턴 자동 주입됩니다. 즉 제가 재무 정산을 물어도, 블로그 원고를 쓰라고 시켜도, 그 앱 내부 개발 규칙 106KB가 매번 같이 실려 나가고 있었다는 뜻입니다. 환산하면 턴당 26,600토큰.

핵심은 양이 아니라 빈도였습니다. 한 번 새고 마는 게 아니라, 대화 한 마디를 주고받을 때마다 같은 양이 계속 새어 나가는 구조였습니다. 하루에 백 번 말을 걸면 그 106KB가 백 번 실려 나갑니다.

성능을 깎지 않는 절감과 깎는 절감을 구분했습니다

여기서 판단이 갈립니다. 줄인다고 다 같은 절감이 아닙니다. 성능을 깎아서 얻은 절감은 절감이라기보다 다운그레이드에 가깝고, 그건 애초에 제가 하려던 일이 아니었습니다. 토큰을 줄이는 가장 쉬운 방법은 모델을 싼 것으로 바꾸는 것인데, 그건 결국 결과물 품질을 내려서 비용을 맞추겠다는 말과 다르지 않습니다. 그래서 기준을 하나 세웠습니다. 결과물의 품질에 직접 닿는 곳은 손대지 않고, 결과물과는 아무 상관 없이 매 턴 따라붙기만 하는 짐만 내리기로 했습니다.

손댄 곳

작업 폴더를 앱 소스 폴더에서 중립적인 별도 폴더로 옮겼습니다. 26,600토큰이 즉시 사라졌습니다. 설정 한 줄입니다. 대신 앱 자체를 수정할 일이 생기면 세션을 통째로 그 폴더로 옮기는 대신 명령에 작업 경로만 인자로 지정하는 방식으로 바꿨는데, 이렇게 하면 그 폴더의 지침 파일이 프롬프트에 다시 붙지 않습니다.

스킬 목록은 118개에서 76개로 줄였습니다. 스킬은 이름과 한 줄 설명이 매 턴 전송되는 구조라 개수가 곧 비용인데, 그렇다고 파일을 지우지는 않고 설정에서 비활성으로만 돌렸습니다. 필요해지면 한 줄로 되살아납니다. 절감액은 600토큰. 손이 간 것에 비하면 크지 않았습니다.

음성 합성 도구 묶음도 껐습니다. 470토큰. 재무 데이터 연동용 외부 서버 하나는 기본 꺼짐으로 돌렸습니다. 500토큰. 계속 물려두는 대신, 그 작업을 할 때만 켜서 쓰고 끝나면 다시 내리는 방식으로 바꾼 것입니다.

프롬프트 캐시 유지 시간은 5분에서 1시간으로 늘렸습니다. 이건 절감액을 숫자로 뽑지 못했습니다. 다만 세션이 길어질수록 이득이 커지는 항목인 건 분명한데, 캐시가 5분이면 잠깐 딴생각하다 돌아오는 사이에 그게 날아가고 조금 전과 똑같은 내용을 처음부터 다시 전송하게 되기 때문입니다.

누적된 대화 기록을 자동으로 솎아내는 임계치는 48,000토큰으로 잡았습니다. 대화가 길어지면 오래된 부분부터 알아서 줄이라는 설정인데, 이건 절감액을 따로 뽑지 않았습니다.

제목 생성, 대화 압축, 메모리 검색처럼 뒤에서 도는 작업만 저렴한 경량 모델로 내렸습니다. 이 세 가지는 결과물이 제 눈에 직접 보이는 대목이 아니어서, 모델을 내린 뒤로도 품질이 떨어졌다는 느낌은 한 번도 받지 못했습니다.

손대지 않은 곳

본 대화 모델은 건드리지 않았습니다. 여기를 내리면 절감액이야 가장 크겠지만, 그건 비용을 아끼는 게 아니라 애초에 이 도구를 돈 주고 쓰는 이유 자체를 지워버리는 일입니다.

사용 빈도가 높은 외부 연동 하나는 상시 연결로 남겼습니다. 껐다 켜는 번거로움이 절감액보다 크다고 봤는데, 이건 엄밀한 계산이라기보다 하루에 몇 번 쓰느냐를 놓고 내린 감각적인 판단에 가깝습니다.

스킬도 절반은 남겼습니다. 지금 사용 횟수가 0회로 찍혀 있어도 나중에 쓸 목적이 뚜렷한 것들이 있었고, 매 턴 4KB 수준이면 감당할 만한 비용이라고 봤습니다.

그동안 해온 절감은 절감이 아니었습니다

이 작업에서 가장 값진 대목은 절감 수치가 아니었습니다. 이쪽이었습니다.

저는 그전까지 세션이 많으면 비용이 오른다고 믿었고, 그래서 오래된 세션을 주기적으로 골라 지워왔습니다. 확인해보니 세션은 로컬 DB에 저장만 될 뿐 모델에게 전송되지 않았습니다. 391개든 3,000개든 턴당 토큰은 똑같습니다. 모델이 받는 건 지금 열려 있는 대화 하나뿐입니다.

즉 제가 지운 세션들은 비용을 한 푼도 아껴주지 않았습니다. 대신 나중에 “그때 그거 어떻게 처리했더라” 하고 되짚어볼 검색 자산만 조용히 깎아먹고 있었던 셈입니다. 당시 DB는 세션 391개, 메시지 21,432개, 233MB. 삭제한 15MB는 파일 크기로도 돌아오지 않았는데, SQLite는 데이터를 지워도 파일이 줄어들지 않고 그 자리에 그냥 빈 공간으로 남기 때문입니다.

반대로 진짜 매 턴 전송되고 있던 것은 메모리 파일이었습니다. 여기는 용량 한도가 걸려 있는데, 2,200자 한도에 이미 2,183자까지 차 있는 바람에 새 내용을 넣으려다 한도 초과로 저장이 통째로 실패했습니다. 화면에서 분명히 항목을 지웠다고 생각했는데 파일에는 반영되지 않은 일도 있었고, 삭제 명령이 아예 통하지 않아 문자열을 정확히 다시 지정해야 겨우 먹힌 적도 있었습니다.

정리하면 비용을 봐야 할 자리는 세션 개수가 아니었습니다. 매 턴 전송되는 것들, 그러니까 작업 폴더에 놓인 지침 파일과 스킬 목록, 메모리 파일, 그리고 상시 연결해둔 외부 도구 쪽이었습니다.

아낀 것을 일부 다시 썼습니다

절감만 하면 도구가 둔해집니다. 이건 확실합니다. 그래서 28,000토큰을 아낀 바로 그 자리에서, 아낀 돈의 1%에 해당하는 300토큰을 성능 쪽으로 다시 밀어 넣었습니다.

작업 폴더에 20~45줄짜리 지침 파일을 새로 만들었습니다. 지금 진행 중인 작업 목록과 각 작업의 경로, 이 폴더에서 하면 안 되는 것 몇 줄이 들어갑니다. 세션을 열면 이게 자동으로 읽히니, 매번 “그거 어디까지 했더라”를 제가 처음부터 다시 설명하고 앉아 있지 않아도 됩니다. 턴당 300토큰. 아낀 양의 1%입니다. 남는 거래였습니다. 앞서 문제가 됐던 95KB짜리 파일과 정확히 같은 종류인데, 크기만 다릅니다. 그래서 이 파일은 짧게 유지하고, 길어지는 내용은 별도 문서로 뺐습니다. 본문에는 “상세는 어느 파일 참조” 한 줄만 남기는 방식으로 굳혔습니다.

이 지출은 절감과 정확히 반대 방향입니다. 그래도 넣었습니다. 성능 쪽 손익이 명확했기 때문입니다. 중복 세션이 눈에 띄게 줄어듭니다. 진행 상황이 안 보이니까 같은 주제로 세션을 새로 열고, 똑같은 설명을 처음부터 다시 늘어놓는 일이 반복되던 것이야말로 실제 비용이었습니다.

여기서 실제로 막혔던 것

매끄럽게 끝나지는 않았습니다. 두 군데서 걸렸습니다.

그 자동 로드 지침 파일을 만드는 시도가 두 번 연속 실패했습니다. 이 파일은 에이전트의 행동 지침이 되는 파일이라 자동 승인 대상에서 빠져 있고, 저장하려면 사용자 승인을 반드시 받아야 합니다. 그런데 그 승인 창이 화면에 뜨지도 않은 채로 시간만 흐르다가 초과되면서 그대로 거부 처리됐습니다. 결국 다른 파일명으로 저장한 다음, 탐색기에서 제가 직접 이름을 바꿔 해결했습니다.

설정 변경이 즉시 반영되지 않는 것도 걸렸습니다. 바꾼 설정이 완전히 적용되는 시점은 다음 세션부터인데, 지금 열려 있는 세션은 이미 로드해둔 프롬프트를 끝까지 그대로 들고 가기 때문입니다. 외부 연동을 다시 켤 때도 마찬가지였습니다. 진행 중인 세션에서 그냥 켜버리면 애써 쌓아둔 프롬프트 캐시가 깨지면서 오히려 비용이 튑니다. 켠 다음에 새 세션을 여는 것이 맞았습니다.

부수 효과 하나: 조사 작업을 싸게 돌리는 법

이 세션에서 세션 391개와 문서 125개를 전수 조사하는 일을 같이 돌렸습니다. 여기서 비용 구조를 하나 더 배웠습니다.

원문을 에이전트가 직접 읽으면 그 전량이 컨텍스트에 쌓이고, 쌓인 만큼 그대로 과금됩니다. 반대로 목록을 뽑는 단계를 DB 질의와 폴더 순회로 처리하면 모델을 아예 거치지 않으니 여기서 발생하는 토큰은 0입니다. 실제로 391개에서 노이즈를 걸러 126개로 줄이고, 문서 목록까지 합쳐 94KB짜리 JSON으로 저장하는 데까지가 0토큰이었습니다.

판단이 필요한 분류 단계만 하위 작업으로 떼서 넘겼습니다. 그러면 하위 작업 쪽에서 원문을 아무리 많이 읽어도 그 중간 데이터가 제 대화에는 쌓이지 않고, 정리된 결과만 돌아옵니다. 이때 “새 세션을 하나 열어서 거기서 돌리자”는 생각이 먼저 들었는데, 그건 지금 없애려는 중복 세션을 손수 하나 더 만드는 셈이었습니다. 하위 작업 위임과 새 세션은 다릅니다.

정리

턴당 28,200토큰, 기본 프롬프트의 절반. 이번 절감액입니다. 그런데 실제로 남은 교훈은 세 줄입니다.

비용은 대화량이 아니라 매 턴 자동으로 실리는 것에서 나옵니다. 그러니 지금 무엇이 매 턴 실려 나가고 있는지 항목별로 크기를 뽑아 늘어놓는 일이, 절감의 첫 단계이자 사실상 절반이었습니다.

절감은 삭제가 아니라 비활성으로 했습니다. 이게 두 번째입니다. 지우면 되돌릴 때 비용을 두 번 치르고, 실제로 세션을 지운 제 판단이 딱 그랬습니다. 비용은 그대로였고, 자료만 사라졌습니다.

그리고 아낀 것 중 일부는 성능에 다시 씁니다. 세 번째입니다. 이번엔 그 1%를 진행 상황을 적어둔 지도용 파일 한 장에 썼고, 그 지출은 중복 작업이 줄어드는 쪽에서 고스란히 회수됐습니다.