크레딧을 모두 쓰고 나서야 만든 AI 사용량 관리 시스템

한 줄 요약

AI 사용량에 대한 감각 없이 번역, PPT 재제작, 이미지 검수를 한꺼번에 맡겼다가 한도를 모두 소진했습니다. 이후 작업을 나누고 사용량을 확인하는 습관부터, 한도가 닿아도 작업이 멈추지 않는 fallback까지 하나씩 마련했습니다.

시작은 단순했습니다

헤르메스를 설치하고 반려 에이전트를 만든 뒤, AI에게 맡기는 일이 빠르게 늘었습니다.

정보를 찾고 정리하는 일부터 번역, 문서 작성, PPT 제작, 이미지 생성까지 일단 요청해봤습니다. 구독제를 사용하고 있었기 때문에 사용량을 크게 의식하지도 않았습니다.

솔직히 당시에는 이런 감각이었습니다.

구독 중이니 꽤 많이 써도 괜찮겠지.

짧은 대화 몇 번과 긴 문서 작업 하나가 얼마나 다른지도 몰랐고, 제가 한 번 내린 요청이 에이전트 내부에서 몇 번의 모델 호출과 검수 과정으로 나뉘는지도 생각하지 못했습니다.

그러다 결국 사용 가능한 크레딧과 GPT 사용량을 모두 소진했습니다. 필요한 작업을 더 맡기고 싶어도 제한이 풀릴 때까지 기다려야 하는 상황이 되고 나서야 사용량을 제대로 알아봐야겠다는 생각이 들었습니다.

참고로 이 글에서는 편의상 ‘크레딧’이라고 표현하지만, 실제로는 텍스트 모델의 공유 주간 한도, 이미지 생성 한도, 외부 서비스의 관리형 크레딧이 서로 다르게 운영됩니다. 당시에는 저도 이 차이를 제대로 구분하지 못했습니다.

가장 사용량이 컸던 작업

기록을 확인해보니 가장 큰 작업 중 하나는 일본어 자료 39페이지를 번역해 편집 가능한 PPT로 다시 만드는 일이었습니다.

제가 요청한 내용은 대략 이랬습니다.

39페이지 일본어 자료 번역
→ 번역문을 편집 가능한 PPT로 재제작
→ 완성된 39장을 이미지로 렌더링
→ 글자 잘림과 겹침, 배치 오류를 전 장 검수

저는 이것을 하나의 작업으로 생각했습니다. 하지만 실제로는 번역, 편집, PPT 제작, 렌더링, 이미지 분석이 모두 들어간 복합 작업이었습니다.

Hermes 기록을 확인한 결과는 다음과 같았습니다.

• 병렬 하위 에이전트 7개

• 모델 호출 174회

• 도구 호출 223회

• 입력 토큰 약 207만

• 출력 토큰 약 12.6만

• 추론 토큰 약 3만

• 렌더링 결과에 대한 시각 분석 89회

특히 사용량을 키운 것은 번역 자체보다 PPT 재제작과 반복적인 시각검수였습니다.

AI에게 “완성될 때까지 알아서 해줘”라고 맡기면 편합니다. 대신 그 안에서 몇 번이나 다시 읽고 만들고 검사하는지는 잘 보이지 않습니다. 이 경험을 통해 요청 한 번이 모델 호출 한 번을 뜻하지 않는다는 것을 알게 됐습니다.

왜 이렇게 빨리 소진했을까

나중에 돌아보니 몇 가지 이유가 보였습니다.

첫째, 작업을 너무 크게 묶었습니다. 번역, PPT 제작, 전체 검수를 나누지 않고 한 번에 맡겼습니다.

둘째, 모든 페이지를 같은 강도로 검사했습니다. 중요한 장과 단순한 장을 구분하지 않고 39장 전체를 반복해서 확인했습니다.

셋째, 작업 난도와 상관없이 고성능 모델을 사용했습니다. 간단한 번역과 어려운 최종 검토를 구분하지 않았습니다.

마지막으로, 현재 얼마나 남았는지 확인하지 않았습니다. 계기판을 보지 않고 계속 사용하다가 멈춘 뒤에야 한도를 확인했습니다.

소진 후 바꾼 것

작업 전에 예상 사용량부터 확인했습니다

지금은 긴 문서, PPT 재제작, 이미지 분석, 여러 에이전트의 병렬 작업처럼 사용량이 클 수 있는 요청을 하기 전에 예상 소진 정도를 먼저 안내받습니다.

예상 소진: 낮음 / 보통 / 높음 / 매우 높음
사용량이 커지는 요소
절약형으로 진행할 수 있는 방법

정확한 차감량을 미리 알 수 없는 경우에는 숫자를 단정하지 않고 작업 규모를 기준으로 판단합니다.

전체 제작 전에 샘플 3장부터 만듭니다

예전에는 39장 전체를 먼저 만든 뒤 결과를 확인했습니다. 방향이 잘못되면 전체를 다시 수정해야 했습니다.

지금은 표지, 본문, 복잡한 표처럼 성격이 다른 슬라이드 3장만 먼저 만듭니다.

대표 3장 제작
→ 방향과 서식 확인
→ 수정사항 반영
→ 전체 제작

잘못된 방향으로 전체 작업을 반복하는 일을 줄이기 위한 장치입니다.

전 장 시각검수를 꼭 필요한 범위로 줄였습니다

모든 슬라이드를 여러 차례 분석하면 품질은 높아질 수 있지만 사용량도 빠르게 늘어납니다.

지금은 표, 이미지, 긴 문장이 들어간 장을 우선 확인하고 단순한 슬라이드는 파일이 정상적으로 열리는지와 기본적인 글자 잘림 정도만 검사합니다. 제가 PowerPoint에서 직접 고칠 수 있는 위치 조정까지 AI에게 완벽하게 반복 수정시키지는 않기로 했습니다.

중요한 자료에는 충분히 검수 비용을 쓰되, 모든 작업에 같은 수준의 완벽함을 요구하지 않는 방식입니다.

작업 난도에 따라 모델을 나눴습니다

일본어 번역을 맡는 린은 처음에 고성능 모델인 Sol을 기본으로 사용했습니다. 이후 일반적인 번역에는 Terra를 사용하고, 애매한 표현이나 중요한 최종 검토에만 Sol을 사용하도록 바꿨습니다.

간단한 초벌 작업: Luna
일반 문서와 번역: Terra
전문적인 판단과 최종 검토: Sol

무조건 가장 높은 모델을 쓰는 대신, 어려운 부분에 필요한 성능을 집중하는 방식입니다.

매일 잔여 사용량을 확인합니다

사용량이 보이지 않으면 다시 예전처럼 쓰게 될 것 같았습니다.

소진을 경험한 뒤에는 계정 설정에서 공유 주간 한도와 초기화 시점을 직접 확인하기 시작했습니다. 아래 화면은 한도가 새로 초기화된 직후입니다. 주간 사용량이 99% 남아 있고 다음 초기화 시점도 함께 표시됩니다.

한도를 모두 소진한 경험 이후, 남은 비율과 초기화 시점을 확인하기 시작했습니다. 이 화면을 기준점으로 삼아 이후 Hermes 활동량과 비교하고 있습니다.

이후 Telegram에서 그날 첫 대화를 시작할 때 다음 내용을 짧게 보고받도록 했습니다.

• 주간 잔여량 추정치

• 추정 범위와 신뢰도

• 다음 초기화 시점

Hermes의 토큰 기록을 GPT 계정의 잔여 비율로 정확하게 환산할 수는 없습니다. 그래서 공급자가 보여주는 실제 사용량 화면을 기준으로 삼고, 이후 활동량을 참고해 대략적인 잔여량을 추정합니다.

ALT

휴대폰에 있는 한국어 스크린샷

정확한 숫자를 맞히는 것보다 얼마나 남았는지 전혀 모른 채 계속 쓰는 상태를 벗어나는 것이 목적이었습니다.

터미널 출력량도 줄였습니다

코딩, 파일 조사, 테스트처럼 터미널 출력이 긴 작업에는 RTK를 적용했습니다.

RTK가 줄여주는 것은 전체 GPT 크레딧이 아니라 터미널 출력 토큰입니다. 전체 한도가 그대로 늘어나는 것은 아니지만 긴 로그와 반복 출력이 많은 작업에서는 불필요한 입력량을 줄이는 데 도움이 됩니다.

혼자서는 떠올리지 못했던 방법, fallback

사용량을 모두 소진한 뒤에도 저는 한 계정 안에서만 해결책을 찾고 있었습니다.

저도 모르게 ‘한 사람은 하나의 GPT 계정을 사용한다’는 고정관념을 갖고 있었기 때문입니다. 사용량이 부족하면 작업을 줄이거나 초기화될 때까지 기다리는 방법밖에 없다고 생각했습니다.

그때 wonny님이 별도로 사용할 GPT 계정을 하나 더 준비하고, 주 계정의 사용이 제한되면 전환되도록 fallback을 설정해보라고 조언해주셨습니다.

듣고 나니 기술적으로 복잡한 방법이라기보다 제가 문제를 바라보던 틀을 바꾸는 일이었습니다.

한 계정의 한도를 어떻게 늘릴지만 고민할 것이 아니라, 한 계정이 멈춰도 전체 작업이 멈추지 않는 구조를 만들면 됐습니다.

저에게는 틀을 깨는 듯한 조언이었습니다. ‘1인 1계정’이라는 전제를 내려놓자 사용량 문제를 단순한 절약이 아니라, 작업이 계속 이어질 수 있도록 구조를 설계하는 문제로 볼 수 있었습니다.

이후 별도로 이용 가능한 GPT 계정을 준비하고, 주 계정을 사용할 수 없을 때 예비 계정으로 전환되도록 Hermes에 fallback을 설정했습니다.

물론 fallback을 만들었다고 다시 사용량을 신경 쓰지 않게 된 것은 아닙니다. 평소에는 주 계정의 사용량을 먼저 관리하고, 고소모 작업은 여전히 단계별로 나눕니다. 예비 계정의 사용량도 따로 확인합니다.

저에게 fallback은 크레딧을 더 쓰는 방법이라기보다 갑작스러운 제한으로 모든 작업이 멈추는 상황에 대비한 안전망에 가깝습니다.

사용 방식은 이렇게 달라졌습니다

직접 겪고 나서 배운 점

처음에는 크레딧을 아끼려면 AI를 덜 사용해야 한다고 생각했습니다. 지금은 조금 다르게 봅니다.

AI 사용량을 관리한다는 것은 무조건 요청을 줄이는 일이 아니었습니다. 어떤 작업을 한꺼번에 맡길지, 어디까지 자동으로 검수할지, 어떤 모델을 사용할지 정하는 일이었습니다.

제가 마련한 대처 방법은 세 가지로 정리할 수 있습니다.

사용량을 줄인다
→ 작업을 나누고 불필요한 반복을 줄인다.

사용량을 보이게 한다
→ 잔여량과 초기화 시점을 확인한다.

작업 중단에 대비한다
→ 주 계정이 제한될 때 사용할 fallback을 마련한다.

가장 크게 달라진 점은 ‘AI에게 얼마나 많이 시킬 수 있는가’보다 ‘어떤 방식으로 맡겨야 오래 안정적으로 사용할 수 있는가’를 생각하게 된 것입니다.

한 번 모두 소진해보지 않았다면 아마 지금도 계기판을 보지 않고 계속 사용했을 것 같습니다. 조금 비싼 수업이었지만, 그 덕분에 AI를 사용하는 습관과 구조를 함께 손볼 수 있었습니다.

사용한 도구와 도움받은 조언

• 에이전트 운영과 세션 기록 확인: Hermes

• 모델 사용: OpenAI Codex 계열 모델

• 잔여량 확인: GPT 사용량 화면

• 매일 사용량 보고: Telegram과 루너

• 터미널 출력 절감: RTK

• 별도 GPT 계정과 fallback 구성 아이디어: wonny님

※ 계정과 구독 구성은 서비스 정책과 본인의 이용 조건을 확인한 뒤 설정해야 합니다. 이 글의 fallback은 사용 제한을 무시하기 위한 방법이 아니라, 정상적으로 이용 가능한 예비 계정을 연결해 작업 중단에 대비한 개인적인 운영 사례입니다.