토큰과 비용 관리 | Aside 고급 활용 3

청구 화면에는 57번의 요청이 찍혀 있었다.

9월 18일, 여러 모델에게 역할을 나누려고 사용량 과금 API 모델을 Aside에 연결했다. 역할 나누기는 고급편 2편에서 다뤘다. 연결 뒤 아주 작은 시험을 두 번 했고 응답은 정상이었다. 그런데 그 제공자의 청구 화면에는 요청 57번, 약 3,156만 토큰, 약 0.69달러가 찍혔다. Aside 쪽 기록은 모델 호출 3번, 약 5만 4천 토큰, 약 0.01달러였다. 약 67배 차이다. 이 글은 AI 요금이 어디서 새는지 모르는 사람을 위해 쓴다. 비용은 “좋은 모델이 비싸다”는 한 줄보다 호출 횟수, 같은 내용 다시 읽기, 보이지 않는 재시도, 비싼 기본값에서 샌다. 고급편의 세 번째 글이다.

3.1 토큰과 크레딧은 무엇이 다른가?

토큰은 모델이 읽고 쓰는 글 조각이고, 크레딧은 Aside 요금제 안에서 쓰는 사용량 단위다.

토큰은 대략 글자 몇 개를 묶은 조각이다. 모델은 요청을 받을 때 읽은 양과 답할 때 쓴 양을 모두 토큰으로 센다. 사용량 과금 API는 이 토큰 수에 따라 요금을 매긴다. API는 프로그램끼리 요청을 주고받는 창구이고, 사용량 과금은 쓴 만큼 요금이 붙는 방식이다. 크레딧은 Aside 요금제 안에서만 쓰는 단위로, 내 Pro 요금제는 갱신 때마다 1,800크레딧으로 채워진다. 여기에 월정액 채팅 구독이 하나 더 있다. 구독은 정해진 사용 한도 안에서 쓰고, 한도를 넘기 전까지는 추가 요금이 없다. 세 방식은 청구하는 곳도, 확인하는 화면도 다르다. 그래서 가장 먼저 정한 원칙은 하나다. 청구의 기준은 돈을 받는 쪽, 곧 제공자의 청구 화면이다.

그림 3-1은 이 글에서 다룰 새는 자리 다섯 곳과 그 옆에 둔 장치를 짝지은 것이다. 호출 횟수는 호출을 줄이는 절차로, 같은 내용 다시 읽기는 읽는 양과 간격을 줄이는 설정으로 막는다. 보이지 않는 재시도는 청구 화면 대조로, 비싼 기본값은 실행 전 비용 확인으로, 이중 실행은 오류가 떠도 바로 다시 누르지 않는 습관으로 막는다.

3.2 Plan & Usage 화면에서 무엇을 봐야 하나?

Aside 요금제 쪽 사용량은 Settings > Plan & Usage에서 본다. 9월 27일 내 화면 위쪽에는 Aside Pro 요금제와 2026년 10월 1일 자동 갱신이 적혀 있었다. Credits 칸은 “0% remaining”이었고, 그 아래에 10월 1일 1,800크레딧으로 다시 채워진다는 안내가 있었다. 잔액은 0크레딧이었다. 옆에는 추가 크레딧을 사는 Buy credits와, 잔액이 적을 때 자동으로 사는 Auto-reload(Configure)가 있다. 둘 다 누르면 돈이 나가는 버튼이다. 요금제별 가격과 크레딧, 연결 경로는 1권 3장에서 다뤘다.

크레딧 0%가 곧 작업 중단을 뜻하지는 않았다. 9월 26일 밤 크레딧 표시가 0%였지만 이 연재, 곧 1권 후반과 고급편은 계속 쓸 수 있었다. 연재 작업을 Aside 요금제 모델로 돌리지 않고, 내가 연결한 채팅 구독으로 돌렸기 때문이다. Settings > Models의 Providers에서 Subscription으로 표시된 연결이다. 반대로 Aside 요금제 모델을 쓰는 루틴이나 작업은 크레딧이 없으면 막힐 수 있다. 그래서 어떤 작업이 어느 연결의 모델을 쓰는지 따로 기억해 두었다. 크레딧 화면이 보여 주는 것은 Aside 요금제 안의 사용량뿐이다. 구독이나 사용량 과금 API의 사용량은 각 제공자 쪽 화면에서 따로 봐야 한다. 모델 칸 배정은 고급편 2편에 정리해 두었다.

3.3 한 작업은 왜 여러 번의 호출이 되나?

같은 화면 아래 Aside credits usage에는 사용 기록이 있다. 월과 연도 버튼(내 화면은 September, 2026)으로 기간을 고르면 작업 이름, 모델, 시각, 크레딧 순으로 줄이 나온다. 내 화면에 보인 기록은 모두 9월 9일 오후 4시 23분에서 28분 사이, 한 작업에서 나온 15건이었다. 모델은 모두 같았고 한 줄마다 9~12크레딧, 합계 153크레딧이었다. 5분 남짓한 작업 하나가 한 번의 요청으로 끝나지 않고 여러 번의 모델 호출로 나뉘어, 호출마다 크레딧을 쓴 것이다. 화면을 읽고, 다음 행동을 정하고, 결과를 확인할 때마다 모델이 다시 불린다고 보면 이 기록이 이해된다.

호출 수가 비용과 시간을 함께 정한다는 것은 다른 측정에서도 드러났다. 반복하는 등록 작업 하나를 재 보니 전체 73.3분 가운데 모델이 생각한 시간은 7.4분(10%)이었고, 도구를 실행하고 결과를 주고받는 왕복이 66분(90%)이었다. 느리다고 모델을 바꿔 봐야 줄어드는 몫은 10% 안쪽이다. 실제로 움직일 수 있는 것은 호출 수였다. 이미 검증된 절차를 스킬, 곧 정해진 순서를 묶어 둔 작업 설명서로 만들자 같은 검증 수준에서 76회·73분이 15회·15.2분으로 줄었다. 확인 단계를 빼서 줄인 것은 없다. 같은 확인을 더 적은 왕복으로 끝냈다. 크레딧 기록에서 한 작업 이름 아래 줄이 길게 늘어서 있다면, 모델 등급보다 그 줄 수를 먼저 볼 만하다.

3.4 청구 불일치를 좁혀 간 과정

도입의 57번 요청으로 돌아가 보자. 원인을 좁히려고 같은 키로 제공자 API에 직접 한 번 요청해 보았다. 그러자 요청 1건, 15토큰으로 정확히 찍혔다. 키도 집계도 정상이었다. 다음으로 제공자의 사용량 내보내기 파일을 받아 보았다. Aside를 거친 두 시험에서 싼 모델 45건과 비싼 모델 12건이 나왔고, 토큰 대부분은 캐시 적중 토큰이었다. 캐시 적중은 이미 읽은 내용을 다시 읽은 것이다. 새 글을 많이 쓴 것보다 같은 내용을 여러 번 되읽은 흔적에 가까웠다. 내 눈에는 시험 두 번이었지만, 제공자 쪽에서는 57번의 요청이었다.

원인은 확정하지 못했다. 내보내기 파일이 하루 단위 합계여서 어느 요청이 어디서 왔는지 한 건씩 가를 수 없었다. 유력한 후보는 두 가지였다. 하나는 모델 칸의 Fast를 그 모델로 바꿔 두었더니 Aside의 백그라운드 작업까지 그 모델로 흘러갔을 가능성이다. 다른 하나는 연결 어댑터가 보이지 않는 재시도를 했을 가능성이다. 나중에는 같은 시간에 돌던 다른 루틴이 칸 설정을 탔을 가능성도 드러났다. 조치는 단순했다. 그 모델을 모델 칸에서 빼고 원래 배정으로 되돌렸다. 원고 규모 작업은 보류했다. 이 모델을 쓴다면 요청과 토큰 기록이 분명한 별도 스크립트로 직접 호출하는 구조가 더 안전하다고 판단했다.

재현 절차, 두 가설, 직접 호출 대조 결과를 정리해 내가 승인한 뒤 Aside에 앱 안 피드백으로 보고했다. 키는 넣지 않았다. 이 일에서 얻은 교훈은 모델이 정상 응답했다는 것과 청구가 정상이라는 것은 따로 확인해야 한다는 점이다. 새 모델을 붙이면 아주 작은 시험 한 번 뒤 청구 화면부터 본다. 시험이 작으면 무엇이 잘못돼도 금액이 작다. 이번 차이도 Aside 쪽 기록만 봤다면 드러나지 않았다. 제공자의 청구 화면을 따로 열었기 때문에 찾았다. 그리고 요청 1건, 15토큰이 정확히 찍힌 직접 호출처럼 기록이 분명한 경로와 나란히 놓아야 어느 쪽이 이상한지 가릴 수 있었다.

3.5 비용의 병목은 어디였나?

긴 작업의 진행을 하트비트로 확인할 때, Aside 쪽 비용의 병목은 작업 본문이 아니었다. 하트비트가 대화 기록을 다시 읽는 비용이었다. 하트비트는 정해진 간격으로 같은 대화를 깨워 상태를 확인하는 루틴이다. 깨울 때마다 쌓인 대화를 다시 읽으니, 자주 깨울수록 같은 내용을 여러 번 읽게 된다. 비교해 보니 진행 확인은 싼 모델에 6분 간격 하트비트를 붙인 조합이 비용상 가장 나았다. 확인하는 쪽은 작업 본문 전체를 읽지 않고 필요한 상태 표시만 봤다. 일을 하는 모델의 등급은 낮추지 않았다. 품질을 정하는 자리는 그대로 두고, 되읽기가 많은 확인 자리만 가볍게 했다.

작은 수정에서도 비슷한 누수가 있었다. 판단이 끝난 기계적 수정, 예를 들어 정확한 단어 치환이나 표기 교정을 모델에게 맡기면서 파일 전체를 다시 쓰게 하면, 고칠 곳 말고 엉뚱한 곳까지 바뀌었다. 그러면 원고 전체를 다시 검수해야 하고 사용 한도도 그만큼 줄어든다. 지금은 정확한 위치만 고친다. 긴 지침에서도 같은 원리가 보였다. 장문 집필 지침 묶음을 재 보니 전체가 근사치로 약 4만 6천 토큰이었다. 모든 참고 자료를 매 호출에 싣지 않고, 바뀌지 않는 지침을 앞에 두고 단계별 자료와 현재 작업을 뒤에 붙이는 순서를 지키기로 했다. 앞부분이 매번 같으면 캐시, 곧 이미 읽은 내용을 재활용하는 장치를 쓰기 좋다.

3.6 구독과 사용량 과금, 역할에 맞게 나누기

월정액 채팅 구독의 한도 안에서 원고를 쓴다면, 한 권을 더 쓰는 현금 비용은 0일 수 있다. 그래서 사용량 과금 API를 쓰는 이유를 구독료 절감에서 찾지 않는다. 장점은 자동화 처리량과 실행 제어다. 요청 하나하나를 프로그램이 보내고, 응답의 사용량 필드로 토큰을 정확히 셀 수 있다. 견적도 내 봤다. 실측은 아니다. 13만 자 한 권을 단계형으로 돌린다고 가정하고 입력 약 250만, 출력 약 57만 토큰으로 잡으면, 싼 모델은 약 0.72~1.43달러, 비싼 설정은 약 2.78~5.56달러가 나왔다. 글자를 토큰으로 바꾸는 비율 0.7~1.3은 가정이다. 믿을 값은 API 응답의 사용량 필드이고, 한 장짜리 시험으로만 보정한다.

구독에도 한도가 있다. 연재 도중 쓰던 모델의 사용 한도가 거의 차서, 대화에서 말로 요청해 다른 모델로 바꾼 적이 있다. 표 3-1은 세 방식을 누가 청구하고 어디서 확인하는지로 나눠 본 것이다.

구분	누가 청구	어디서 확인	장점	주의
월정액 채팅 구독	구독한 채팅 서비스	그 서비스의 구독과 사용 한도 안내	한도 안에서는 한 권을 더 써도 현금 비용이 0일 수 있다	사용 한도가 있다. 차면 다른 모델로 바꿔야 했다
사용량 과금 API	모델 제공자	제공자의 청구 화면, 사용량 내보내기, 응답의 사용량 필드	자동화 처리량과 실행 제어. 토큰을 정확히 셀 수 있다	쓴 만큼 붙는다. Aside 기록과 청구가 다를 수 있어 청구 화면이 기준이다
Aside 요금제 크레딧	Aside	Settings > Plan & Usage, Aside credits usage	따로 연결하지 않고 요금제 모델을 쓴다. 작업별 기록이 남는다	0%면 요금제 모델을 쓰는 작업과 루틴이 막힐 수 있다. Buy credits와 Auto-reload는 추가 결제다

표를 역할로 읽으면 이렇다. 사람이 대화하며 원고를 쓰는 일은 구독 한도 안에 둔다. 요청 수와 토큰을 기록해야 하는 대량 자동화는 사용량 과금 API로, 그것도 기록이 분명한 직접 호출로 돌린다. Aside 요금제 크레딧은 요금제 모델을 쓰는 작업에 쓰되, 0%가 되면 무엇이 멈추는지 미리 알아 둔다.

3.7 돈이 새는 자리와 막는 장치

9월 23일, 한 AI 모델 호출 서비스는 모델 가격이 무료인데도 카드 등록을 요구했다. 카드는 내가 직접 넣었다. Aside는 지출 한도를 7달러로 걸었다. 계획서에 적어 둔 비용 상한 1만 원에 맞춘 값이다. 한도가 자동으로 다시 채워지지 않게 하고, 한도의 100%에 닿으면 메일로 알리게 했다. 무료 모델이라도 카드가 걸려 있으면 한도가 마지막 방어선이 된다. 무료라는 표시와 카드가 청구될 가능성은 따로 봐야 한다. 한도, 한도 자동 갱신 여부, 알림 세 가지를 카드 등록과 같은 자리에서 한 번에 정해 두면 나중에 따로 챙길 일이 줄어든다. 그 과정은 1권 14장에 있다.

기본값이 비싸게 잡히는 일도 있었다. 9월 24일에 쓴 한 AI 영상 생성 도구는 설정 화면에서 모델을 바꿔도 무시했다. 프롬프트 첫 줄에 모델 이름을 적지 않으면 한 편에 100크레딧인 상위 모델로 잡혔다. 기본 모델은 15크레딧이니 6.7배다. 새 모드는 안내에 적힌 비용과 승인 화면의 비용이 달랐다(15와 20). 생성을 승인한 직후 오류 문구가 떴지만 실제로는 접수돼 있었다. 그때 다시 눌렀다면 이중 과금될 뻔했다. 그래서 크레딧이 드는 시도는 매번 실행 전에 나에게 비용을 확인받게 했다. 자세한 기록은 1권 13장에 있다.

재시도도 가려서 해야 한다. 사용량 한도나 요청 한도를 넘은 실패와, 제공자 쪽의 일시적 용량 부족(503 No capacity)은 다른 실패다. 번역 배치에서는 둘을 나눠, 한도 초과는 길게 기다리고 용량 부족은 짧게 기다렸다가 다시 시도하게 했다. 이미 끝난 조각은 건너뛰게 해서 쓸데없는 재실행 비용이 붙지 않게 했다. 모든 실패를 똑같이 곧바로 다시 시도하면 한도가 풀리지 않은 상태에서 요청만 쌓이고, 이미 성공한 조각까지 다시 돌리면 같은 비용을 두 번 낸다. 실패의 종류를 먼저 가르는 것이 재시도 비용을 줄이는 첫 단계였다. 표 3-2는 이 글의 사례를 새는 자리별로 모은 것이다.

새는 자리	내가 겪은 예	막는 장치
호출 횟수	5분 남짓한 작업 하나가 15건, 153크레딧. 반복 등록 작업 76회	검증된 절차를 스킬로 묶어 호출 수를 줄이고(15회), 사용 기록에서 줄 수를 본다
같은 내용 다시 읽기	하트비트가 대화 기록을 되읽음. 청구 토큰 대부분이 캐시 적중. 지침 묶음 약 4만 6천 토큰	싼 모델과 6분 간격 하트비트, 본문 대신 필요한 상태 표시만 읽기, 바뀌지 않는 지침을 앞에 두기
보이지 않는 재시도	시험 두 번이 청구 화면에서 57번 요청(원인 미확정)	작은 시험 뒤 청구 화면 대조, 기록이 분명한 직접 호출
비싼 기본값	영상 도구가 100크레딧 모델로 잡힘. 모델 칸 변경이 백그라운드 작업까지 번졌을 가능성	첫 줄에 모델 명시, 실행 전 비용 확인, 칸 배정 되돌리기
이중 실행	오류 문구가 떴지만 실제로는 접수된 생성 요청	다시 누르기 전에 접수 여부 확인, 끝난 조각 건너뛰기
전체 다시 쓰기	작은 수정에 파일 전체를 재생성해 엉뚱한 곳까지 바뀜	정확한 위치만 고치기
한도 없는 결제 수단	무료 모델인데 카드 등록 요구	지출 한도 7달러, 한도 자동 갱신 없음, 100% 도달 메일 알림
크레딧 소진	Aside 크레딧 0%	작업마다 어느 연결의 모델을 쓰는지 구분해 두기

3.8 비용 조건을 적은 요청 예시

비용을 막는 장치는 요청에 미리 적어 둘 수 있다. 새 모델을 연결할 때 담을 것은 네 가지다. 시험의 크기, 시험 뒤 확인할 화면, 걸어 둘 한도, 보고받을 숫자다. 아래는 설명을 위해 만든 가상의 요청이다.

[가상 설정]
새로 연결한 사용량 과금 API 모델을 시험해 줘. 원고 작업은 아직 하지 마.

1. 한 문장짜리 요청을 딱 한 번만 보내. 모델 칸 배정은 바꾸지 마.
2. 응답을 받으면 멈추고, 제공자의 청구 화면에서
   그 시각의 요청 수와 토큰 수를 확인해 줘.
3. Aside 쪽 기록의 호출 수, 토큰 수와 나란히 비교해 줘.
   차이가 나면 다음 단계로 넘어가지 말고 나에게 먼저 알려 줘.
4. 결제 화면에서 지출 한도를 5달러로, 자동 충전은 끔으로,
   한도 도달 시 메일 알림은 켬으로 설정할 준비만 해 줘.
   저장 버튼은 내가 확인한 뒤에 눌러.
5. 마지막에 아래 표로 보고해 줘.
   | 항목 | Aside 기록 | 청구 화면 | 차이 |
   | 요청(호출) 수 | | | |
   | 입력 토큰 | | | |
   | 출력 토큰 | | | |
   | 금액 | | | |

2번과 3번이 이 요청의 중심이다. 응답이 정상이라는 것만 보고 넘어가면 57번 요청 같은 차이를 원고 규모에서 처음 보게 된다. 1번에서 모델 칸을 바꾸지 말라고 적은 것도 같은 이유다. 시험이 작고 경로가 하나여야 차이가 생겼을 때 어디서 왔는지 좁힐 수 있다.

3.9 다음 편: 허용된 길로 자동화하기

다음 편에서는 AI 서비스를 자동으로 돌리기 전에 약관에서 무엇을 확인해야 하는지, 그리고 제공자가 자동화용으로 열어 둔 API와 공식 명령줄 도구, 허용된 연결 가운데 어떤 길을 고를지 다룬다.

이 글의 확인 범위

기준일은 2026년 9월 27일이다. Plan & Usage 화면은 같은 날 내 화면을 기준으로 했고, 이후 화면 이름이나 동작은 바뀔 수 있다.

• 3.4절의 청구 불일치는 원인을 확정하지 못했다. 사용량 내보내기가 하루 단위 합계여서 요청을 한 건씩 가를 수 없었다. 모델 칸 설정이 백그라운드 작업으로 번졌을 가능성, 연결 어댑터의 보이지 않는 재시도, 같은 시간에 돌던 다른 루틴은 모두 후보일 뿐이다.
• 9월 18일 시험의 요청 수, 토큰, 금액은 제공자 청구 화면과 Aside 기록에 찍힌 근삿값이다. 한 번의 시험에서 나온 수치이고 일반적인 비율로 읽을 수 없다.
• 3.3절의 크레딧 기록(15건, 153크레딧)은 내 화면에 보인 한 작업의 기록이다. 작업마다 호출 수와 크레딧은 다르다. Aside가 한 작업을 어떤 단위로 나눠 호출하는지는 확인하지 않았다.
• 3.6절의 한 권 비용은 견적이며 실측이 아니다. 글자를 토큰으로 바꾸는 비율 0.7~1.3은 가정이고, 제공자의 토큰 계산기는 내 작업 공간에서 실행되지 않았다. 구독 한도 안의 현금 비용 0도 견적 판단이다.
• 하트비트 6분 간격과 싼 모델 조합은 내 진행 확인 작업에서 비교한 결과다. 다른 작업에서도 같은 결과가 나온다는 뜻은 아니다. 지침 묶음의 약 4만 6천 토큰은 근사치다.
• 73.3분, 76회를 15.2분, 15회로 줄인 측정은 반복 등록 작업 한 종류에서 잰 것이다.
• 영상 생성 도구와 모델 호출 서비스의 동작은 9월 23~24일 내가 쓴 시점의 것이다. 제공자, 서비스, 도구 이름은 Aside 화면 설명 밖에서는 적지 않았다.
• 그림 3-1은 설명용 도식이다. 그림 3-2와 3-3은 실제 화면이며 카드 번호 끝자리와 만료일, 작업 이름만 가상 값으로 바꿨다. 3.8절의 요청과 그 안의 한도 금액은 가상이다.

참고한 자료

2026년 9월 27일 확인. 모델과 AI 도움말

다음 글: 고급 활용 4 · 허용된 길로 자동화하기
이전 글: 고급 활용 2 · 여러 AI 모델에게 역할 나누기
1권: 『Aside 브라우저 사용설명서』 연재 목록
『Aside 고급 활용』 연재 목록

저자의 실제 사용 경험과 Aside 도움말을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 초판 선공개 원고 v1.0.