AI 도구의 요금표를 읽다 보면 단위가 자주 바뀐다. 월 구독료 옆에는 토큰이 있고, 다른 화면에는 크레딧이나 사용 비율이 있다. 숫자가 많아도 내가 끝내려는 일에 얼마나 쓰이는지는 바로 보이지 않는다. 제공량을 비교하기 전에 완료라고 부를 작업을 하나 정해볼 수 있다.
Elena Verna의 AI 가격과 패키징에 관한 글은 2026년 10월 16일의 논평이다. 여기서는 그 시점의 가격을 현재 가격표로 옮기지 않는다. 특정 상품의 구매를 권하거나 새로운 지출을 실행한 글도 아니다. 요금 단위와 실제 작업을 연결하기 위한 가상 장부를 생각해보려 한다.
무엇을 끝내야 한 번인가
가령 짧은 안내문을 준비하는 작업을 정했다고 하자. 처음 생성한 문장이 아니라, 사실과 표현을 확인해 실제로 쓸 수 있게 된 문서를 완료 한 건으로 센다. 초안 다섯 번을 만들고 세 건을 채택했다면 생성 횟수는 다섯이고 완료 작업은 세 건이다. 둘을 같은 숫자로 놓으면 비용의 의미가 달라진다.
완료 기준은 작업에 맞게 정해야 한다. 코드라면 파일이 생겼다는 사실보다 필요한 동작과 검사가 포함될 수 있고, 이미지라면 원하는 비율과 권리·관련성 확인이 필요할 수 있다. 품질이 다른 결과를 같은 한 건으로 세면 저렴해 보이는 도구가 실제 업무에는 더 많은 확인을 요구할 수도 있다.
검토 시간을 모두 돈으로 환산해야 하는 것은 아니다. 다만 생성 후 수정과 확인에 걸린 시간을 별도 열로 두면 대기와 작업을 구분할 수 있다. 자동으로 처리되는 동안 다른 일을 한 시간과 사람이 직접 읽고 고친 시간을 합쳐 절약 시간이라고 부르지 않는다. 이 글에는 실제 계정 사용 기록이나 절약 성과가 없다.
구독료를 나누는 가상 계산
숫자를 단순하게 가정해보자. 가상의 A 도구에 한 달 30달러를 내고 해당 기간에 채택 가능한 작업 세 건을 끝냈다면, 이 구독료만 나눈 값은 건당 10달러다. 다른 가상의 B 도구는 50달러이고 같은 기준의 작업 여덟 건을 끝냈다면 건당 6.25달러다. 실제 상품이나 현재 판매 가격을 나타내는 값은 아니다.
이 계산만으로 B가 더 좋은 선택이라는 결론은 나오지 않는다. 필요한 작업이 세 건뿐이라면 여덟 건을 완료한다는 가정부터 성립하지 않을 수 있다. 두 도구에서 끝낸 작업의 난도나 검토 부담이 다르면 직접 비교도 어렵다. 가정한 분모를 현실에서 확인하지 않고 요금만 나누면 또 다른 착시가 생긴다.
월 구독료에 포함된 여러 기능을 썼다면 그 전부를 한 종류의 결과에 배분하는 것도 하나의 회계적 가정이다. 실제 결제액과 내부적으로 나눈 비용은 구분해서 적을 수 있다. 남은 크레딧이 현금으로 환급되지 않는 상품이라면 사용하지 않은 크레딧을 현금 자산처럼 계산해서도 안 된다. 구체적인 조건은 실제 약관과 계정 화면에서 확인해야 한다.
재시도도 별도로 보자. 채택한 결과 하나를 얻기 위해 여러 번 생성했다면 포함 사용량은 그 과정에서 소모될 수 있다. 다만 모든 서비스가 같은 방식으로 차감한다고 가정할 수는 없다. 실패 요청이나 다른 모델의 사용량을 어떻게 계산하는지 확인하지 못했다면 모름으로 남기는 편이 정확하다.
한도는 남은 양과 기다릴 시간을 함께 보기
한도가 일정 비율 남아 있다는 화면만으로 오늘 몇 작업을 더 할 수 있는지 계산하기 어려울 수 있다. 요청마다 사용량이 다르고, 시간 단위와 주간 단위 한도가 함께 작동할 수도 있다. 초기화 시각과 적용되는 시간대, 실제 사용하려는 기능의 별도 제한을 확인해야 한다.
같은 회사의 구독이 특정 API 이용료까지 포함한다고 추정하는 것도 피해야 한다. 웹 앱에서 사용 가능한 기능과 개발자 API의 과금은 따로 정해질 수 있다. 계획을 세울 때에는 어떤 경로로 어떤 기능을 쓸지 함께 적는다. 서비스 이름이 같다는 사실만으로 비용 경계가 같지는 않다.
작은 장부라면 작업 이름, 완료 기준, 생성 시도 수, 채택 수, 직접 검토 시간, 확인한 결제·한도 조건을 남길 수 있다. 측정하지 못한 값은 빈칸으로 두어도 된다. 정밀해 보이는 추정값으로 모두 채우는 것보다 무엇을 아직 모르는지 보이는 기록이 다음 비교에 도움이 된다.
일주일 동안 작업 종류가 달랐다면 합계를 먼저 비교하지 않는 편이 좋다. 쉬운 초안이 많았던 주와 복잡한 코드 검토가 많았던 주를 같은 생산성으로 읽을 수 없기 때문이다. 같은 종류의 작업과 같은 완료 기준을 묶어보아야 차이를 해석할 근거가 생긴다.
표시된 숫자의 시점과 범위를 확인하는 일은 요금 화면에도 필요하다. 지금 보이는 잔량인지, 어느 기간의 사용인지가 다르면 어제의 기록과 바로 빼기 어렵다. 데이터가 없을 때 0으로 채우지 않는 습관도 같다.
새로운 요금표를 볼 때 토큰 단가만 적는 대신, 내가 끝내고 싶은 작업의 이름을 옆에 써보면 좋겠다. 그 일을 같은 품질로 마치기까지 무엇을 쓰고 무엇을 확인해야 하는가. 결제 여부를 판단하기 전에 그 질문에 답할 수 있으면, 많은 숫자 가운데 내게 필요한 숫자가 조금 더 분명해질 것이다.
공개 원문을 참고해 AI의 도움으로 구성·작성한 글입니다. 가상 예시는 실제 수행 결과와 구분했으며, 표지는 Google Gemini로 만든 개념 일러스트입니다.
