크레딧, 평이하게 설명

카드를 등록하기 전에 알아둘 만한 네 가지 숫자:

• 월간 한도는 매 주기마다 남은 잔액 없이 0으로 초기화됩니다.
• 크레딧 팩은 만료일이 전혀 없습니다.
• 사용하지 않은 팩의 환불은 14일 이내에 가능합니다.
• 실패한 생성 작업도 결과물이 마음에 들든 아니든 정확히 크레딧 1회분의 작업량을 소모합니다.

이 중 세 가지는 요금제 페이지에 나올 법한 내용입니다. 흥미로운 것은 실제 지출 순서가 어떻게 정해지는지에 숨어 있으며, 크레딧이 실질적 의미를 갖는 것과 크레딧이 그저 마케팅 숫자에 불과한 것의 차이를 만들기 때문에 짚고 넘어갈 가치가 있습니다.

왜 한도가 먼저 소진되는가

계정에 월간 한도와 구매한 팩이 동시에 있을 때, 팩을 건드리기 전에 한도가 먼저 소진됩니다. 이 사실은 요금제 안내 문구 어디에도 헤드라인으로 등장하지 않지만, 팩이 실제로 지불한 만큼의 가치를 하도록 만드는 메커니즘입니다.

반대 상황을 생각해보세요: 만약 팩이 먼저 소진된다면, 한도는 결제 주기가 바뀌어 사라질 때까지 그냥 사용되지 않은 채 남아 있게 됩니다. 바쁜 한 주를 대비해 3월에 구매한 팩이 실제로는 추가 용량을 더해주는 것이 아니라 구독료를 조용히 보조하게 되는 셈입니다 — 같은 작업 단위에 대해 요금제로 한 번, 팩으로 한 번, 두 번 지불하게 되고, 이미 지불한 것은 배경에서 조용히 증발합니다. 한도 우선 방식은 이를 뒤집습니다: 요금제에 포함된 돈을 먼저 쓰고, 추가 용량을 위해 특별히 지불한 돈은 초기화가 앗아갈 모든 것을 견뎌냅니다. 3월에 구매한 팩은 11월에도 구매한 날과 정확히 같은 가치를 지닙니다.

이 비대칭성이 바로 두 크레딧 유형이 서로 다르게 만료되는 근본적인 이유이기도 합니다. 한도는 결제 중인 주기에 포함된 사용량입니다 — 만약 무기한 이월된다면, 누군가 로그인하지 않는 분기마다 사실상 한 달 요금으로 세 달치 크레딧을 판매하는 셈이 되고, 요금제 페이지에는 이를 설명할 훨씬 더 많은 세부 조항이 필요해질 것입니다. 그래서 한도는 FAQ 속에 묻히지 않고 명확하게 초기화됩니다. 팩은 구독 혜택이 아니라 사용량을 사기 위해 특별히 지출한 돈이므로, 혜택이 아니라 잔액처럼 작동합니다 — 배경에서 카운트다운하는 만료 시계가 없습니다.

유료 충전분이 구독 주기와 함께 조용히 사라지던 도구들을 써본 적이 있습니다. 약관 어딘가에 기술적으로는 명시되어 있었지만, 늘 함정처럼 느껴졌습니다.

지출 순서는 이 제품이 그런 함정이 되지 않도록 막아주는 작지만 기계적인 선택입니다.

실제로 크레딧을 소모하는 것

모델이 당신을 대신해 실제 작업을 수행하는 모든 것:

• 최초 빌드
• 변경 후 재빌드
• 경쟁사 페이지를 읽는 리서치 패스
• 마케팅 초안 작성
• 메타데이터를 다시 작성하는 최적화 패스

이들은 동일한 가격으로 책정되지 않으며 그래서도 안 됩니다 — 전체 빌드는 수십 개 파일을 수 분간의 모델 시간에 걸쳐 다룰 수 있는 반면, 헤드라인 수정은 몇 초의 집중된 편집일 뿐입니다. 작업 유형별 요율은 요금제 페이지에서 확인할 수 있으며, 기반 모델을 재조정함에 따라 변동될 수 있습니다. 저희는 오래된 가격을 지키기 위해 품질을 조용히 제한하기보다 가격을 공개적으로 조정하는 쪽을 택하겠습니다.

아무것도 소모하지 않는 것:

• 게시된 사이트가 계속 운영되는 것 — 하루당 비용이 전혀 들지 않습니다
• 대시보드 확인
• 순위 확인
• 과거 실행 기록 조회
• 어시스턴트에게 단순 질문하기

답변이 실제로 무언가를 수행해야 할 때까지는 모두 무료입니다 — 단순히 알려주는 것이 아니라요. 규칙은 어디서나 일관됩니다: 모델이 무언가를 생성하거나 변형했는가, 아니면 이미 존재하던 것을 그냥 읽었는가.

그리고 마음에 들지 않는 생성 결과도 여전히 크레딧을 소모합니다. 작업이 실제로 일어났기 때문입니다 — 토큰이 소모되고, 연산이 수행되고, 모델이 끝까지 실행되었습니다. 이는 결과물을 만들어내기 전에 저희 측에서 오류가 발생하는 경우와는 다른데, 그런 경우는 저희 책임이며 아래에서 다룹니다. "만족할 때까지 무료 재시도"는 관대해 보이지만, 결국 모두의 세 번째 시도를 첫 번째 시도에서 성공한 모든 사람이 조용히 보조하고 있다는 사실을 알아차리면 이야기가 달라집니다.

어디서 문제가 생기고, 저희는 무엇을 하는가

빌드 도중 크레딧이 바닥나면 실행은 그 자리, 로그에서 바로 멈춥니다 — 세 단계 지나서 미완성 페이지가 남는 것이 아니라요. 조용한 실패도 없고, 잔액이 사라지는 일도 없고, 멈췄는지 추측할 필요도 없습니다. 충전하거나 초기화를 기다린 후, 멈춘 지점에서 이어서 진행하면 됩니다. 저는 클라이언트 데모 도중 이런 일이 실제로 일어나는 것을 지켜봤습니다: 고객이 "한 번만 더"를 요청한 바로 그 순간 한도가 바닥났고, 정지 메시지가 무엇이 필요한지 알려줬으며, 그 자리에서 작은 팩을 구매했고, 실행은 1분도 안 되어 다시 시작됐습니다.

크레딧 환불은 손상된 Search Console 연결을 고쳐주지 않기 때문에, 저희는 이러한 경우를 의도적으로 다르게 다룹니다.

환불은 14일 이내의 미사용 팩과 사용하지 않은 새 주기만을 대상으로 하며, 그게 전부입니다. 이미 소모된 작업은 되돌릴 수 없습니다 — 에이전트가 사이트를 빌드했는데 마음이 바뀌었다면, 그 연산은 이미 일어난 일입니다. 마치 계약자가 마음에 들지 않는 초안이라도 청구된 시간을 환불해주지 않는 것과 같습니다. 전체 환불 정책은 환불 정책을 길게 만드는 예외들이 필요 없도록 노력했기에 짧습니다.