AI 비용이 예측되지 않을 때, 어디에 상한을 겁니까

AI 기능을 붙이고 나서 가장 먼저 곤란해지는 질문은 성능이 아니라 이것입니다. 다음 달에 얼마가 나옵니까. 서버 요금은 대수를 세면 어림이 되는데, AI 호출은 사람이 얼마나 쓰는지에 달려 있어 세어 볼 대상 자체가 잡히지 않습니다.

그래서 많은 팀이 예산 알림을 하나 걸어 두고 대비를 마쳤다고 생각합니다. 그런데 알림은 알려 주는 장치이지 멈추는 장치가 아닙니다. 이 차이를 먼저 정리하지 않으면, 상한을 걸었다고 믿는 상태에서 청구서가 올라갑니다.

무엇이 요금을 만드는지, 즉 과금 항목 자체는 Amazon Bedrock 비용 구조에서 따로 다룹니다. 여기서는 그다음 질문 — 어떻게 막고 어떻게 나누는가 — 만 다룹니다.

「여기까지만 쓰고 멈춰라」는 장치가 없다

출발점이 되는 사실을 먼저 밝혀 두겠습니다. Bedrock에는 지출이 일정 금액에 도달했을 때 호출을 자동으로 차단하는 네이티브 상한이나 토큰 예산이 없습니다.

AWS가 제공하는 것은 사용량 관점의 할당량입니다. 초당 요청 수나 분당 토큰 수처럼 순간적인 처리량을 제한하는 값이며, 서비스가 과부하로 무너지지 않도록 하는 장치이지 한 달 지출을 묶어 두는 장치가 아닙니다. 할당량 안에서도 하루 종일 호출하면 그만큼 비용이 발생합니다.

그래서 이 영역의 계획은 「AWS가 알아서 막아 주겠지」를 지우는 데서 시작합니다. 막는 일은 우리가 설계해야 하고, AWS가 주는 도구 대부분은 그 앞에서 보이게 하는 역할을 맡습니다.

왜 예측이 어려운가

상한 이야기를 하기 전에 왜 예측이 빗나가는지를 짚어 두면, 어디에 장치를 걸어야 하는지가 자연스럽게 보입니다. 원인은 대체로 셋입니다.

• 사용량이 사람 행동에 달려 있습니다. 기능을 열어 두면 누가 얼마나 쓸지는 열어 보기 전에 알 수 없습니다. 사내 도구는 특히 공지 한 번에 사용량이 계단식으로 뜁니다.
• 한 번의 호출이 처리하는 양이 일정하지 않습니다. 질문이 길어지거나 참고 문서를 많이 붙이면 같은 기능이라도 처리량이 크게 달라집니다. 호출 건수는 그대로인데 처리량만 늘어나는 경우가 흔해서, 건수로 세운 예측이 어긋납니다.
• 조용히 배수를 만드는 경로가 있습니다. 실패한 요청의 재시도, 긴 대화 문맥을 매번 다시 보내는 구성, 캐시가 맞지 않아 다시 계산되는 경우가 여기 속합니다. 어느 것도 화면에는 드러나지 않습니다.

세 번째가 특히 위험합니다. 사람이 만든 사용량이 아니라 코드가 만든 사용량이라 사용자 수를 세어서는 잡히지 않고, 대개 청구서를 받고 나서야 발견됩니다.

네 개의 층으로 나눠 세운다

실무에서 세우는 장치를 성격별로 나누면 네 층입니다. 앞의 셋은 보이게 하고, 마지막 하나만 실제로 멈춥니다.

예산 알림 — 실제 지출과 예측은 다른 기준이다

AWS Budgets로 세우는 예산 알림에는 두 가지 기준이 있습니다. 이 둘을 구분하지 않는 것이 흔한 함정입니다.

• 실제 지출 기준 — 이미 발생한 비용이 기준선을 넘으면 알립니다. 확실하지만 늦습니다. 알림이 왔을 때는 이미 그만큼 쓴 뒤입니다.
• 예측 기준 — 지금 추세대로라면 이번 달 끝에 기준선을 넘을 것으로 보일 때 알립니다. 더 일찍 오지만 추세가 바뀌면 빗나갑니다.

권하는 구성은 둘을 함께 거는 것입니다. 예측 기준으로 미리 신호를 받고, 실제 지출 기준으로 사실을 확인합니다. 하나만 걸면 너무 늦게 알거나 너무 자주 놀라게 되며, 자주 놀라는 알림은 결국 꺼집니다.

비용 이상 탐지 — 금액선 아래의 변화를 잡는다

예산 알림은 우리가 정한 선을 기준으로 삼기 때문에, 그 선 아래에서 일어나는 급격한 변화는 놓칩니다. 비용 이상 탐지는 기준이 다릅니다. 평소의 사용 흐름에서 벗어난 변화를 찾아 알립니다.

앞 절에서 말한 재시도 루프나 잘못된 배치 작업은 대개 이 층에서 먼저 걸립니다. 금액이 아직 작을 때 모양이 먼저 이상해지기 때문입니다. 두 층은 대체 관계가 아니라 서로 다른 구멍을 막습니다.

태그와 호출 주체별 배분 — 나누지 못하면 줄이지도 못한다

비용이 한 덩어리로만 보이면 대화가 「AI가 비싸다」에서 멈춥니다. 어느 기능이 어느 팀 때문에 얼마를 쓰는지 갈려야 무엇을 손볼지 정할 수 있습니다.

수단은 두 갈래입니다. 하나는 AWS 전반에서 쓰는 비용 배분 태그이고, 다른 하나는 Bedrock 쪽에서 호출 주체별로 비용을 가르는 수단입니다. Bedrock은 추론 프로파일에 태그를 붙여 호출을 주체 단위로 배분할 수 있게 해 두었습니다. 설정 방법과 지원 범위는 바뀌므로 채택 시점에 공식 문서에서 확인하시는 편이 정확합니다.

중요한 것은 도구 이름이 아니라 시점입니다. 이 구분은 호출하는 순간에 남겨야 하고, 남기지 않은 호출은 나중에 어떤 방법으로도 되짚을 수 없습니다.

애플리케이션 상한 — 실제로 멈추는 유일한 층

앞의 셋을 다 세워도 지출은 멈추지 않습니다. 멈추려면 우리 코드 안에 세는 장치와 끊는 장치가 있어야 합니다.

• 무엇을 세는가 — 호출 건수와 토큰 사용량 둘 다 세는 편이 안전합니다. 건수만 세면 한 번에 큰 양을 처리하는 호출을 놓치고, 토큰만 세면 짧은 호출이 폭주하는 경우를 늦게 봅니다.
• 어느 단위로 끊는가 — 대개 세 겹으로 둡니다. 사용자 한 명당 하루 한도, 기능 단위의 한도, 그리고 전체 한도입니다. 안쪽 한도가 바깥쪽을 지키는 구조입니다.
• 끊은 뒤에 무엇을 보여 주는가 — 상한에 걸렸을 때 화면이 침묵하면 고장으로 읽힙니다. 한도에 도달했다는 사실과 언제 풀리는지를 말해 주어야 문의가 줄어듭니다.
• 끄는 스위치가 있는가 — 무언가 잘못됐을 때 AI 호출만 통째로 끌 수 있는 설정을 하나 두십시오. 코드를 고쳐 배포해야 멈출 수 있는 구조는 사고 시점에 가장 느립니다.

이 네 가지는 대단한 기술이 아니라 설계 시점에 정해 두었는가의 문제입니다. 나중에 붙이려 하면 호출 지점이 여러 곳으로 흩어진 뒤라 손이 훨씬 많이 갑니다.

나누려면 호출 시점에 무엇을 남겨야 하는가

팀별·기능별 배분은 결국 호출할 때 남긴 정보의 품질에 달려 있습니다. 최소한 아래 네 가지는 함께 기록해 두시는 편이 좋습니다.

• 어느 기능인가 — 문서 요약인지, 문의 분류인지, 초안 작성인지를 구분하는 값입니다. 나중에 어떤 기능이 비용의 대부분을 만드는지는 이 값 하나로 갈립니다.
• 어느 팀·부서인가 — 사내 도구라면 배분의 기준이 되고, 고객용 기능이라면 어떤 고객군이 많이 쓰는지가 됩니다.
• 어느 환경인가 — 개발·테스트 환경의 호출이 운영과 섞이면 「사용자가 늘었다」는 잘못된 해석이 나옵니다.
• 얼마를 처리했는가 — 응답에 함께 오는 토큰 사용량을 기록해 두면, 청구서를 기다리지 않고도 그날의 사용량을 볼 수 있습니다.

한 가지 주의할 것이 있습니다. 여기에 고객의 질문 원문이나 개인정보를 함께 남기지 마십시오. 비용을 가르는 데 필요한 것은 분류 값이지 내용이 아닙니다. 원문을 남기면 비용 기록이 곧바로 개인정보 관리 대상이 되고, 목적이 전혀 다른 두 문제가 한 저장소에 묶입니다.

AWS 인프라 전반에서 비용이 갑자기 오르는 원인은 성격이 다르므로 AWS 비용이 갑자기 늘어나는 원인에서 따로 정리했습니다.

정리

• Bedrock에는 지출을 자동으로 멈추는 상한이 없습니다. 할당량은 순간 처리량을 제한하는 값이지 월 지출을 묶는 값이 아닙니다.
• 예산 알림·이상 탐지·비용 배분은 보이게 할 뿐 막지 못합니다. 실제로 멈추는 것은 애플리케이션 안의 상한 하나입니다.
• 예산 알림은 실제 지출 기준과 예측 기준을 함께 거십시오. 하나만 걸면 늦거나 시끄럽습니다.
• 비용을 나누는 값은 호출하는 순간에 남겨야 합니다. 남기지 않은 호출은 나중에 되짚을 수 없습니다.
• 사고 시점에 가장 필요한 것은 AI 호출만 끌 수 있는 스위치입니다. 배포해야 멈추는 구조는 그때 가장 느립니다.

빌드업웍스는 AI 비용을 통제할 때 예산 알림을 보이게 하는 장치로만 두고, 실제로 멈추는 상한은 애플리케이션 안에 함께 설계합니다.

지금 AWS 비용 관리가 어느 단계에 있는지 몇 분 안에 확인하시려면 AWS 비용 자가 진단을 이용하실 수 있고, 연락처를 남기지 않아도 결과를 바로 보실 수 있습니다. AI 기능 안에 상한과 배분을 어떻게 넣을지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS Budgets — 비용 관리
• AWS Cost Anomaly Detection
• AWS — 비용 배분 태그
• Amazon Bedrock — Inference profiles
• Amazon Bedrock — Quotas