첫 메시지들은 밤사이에 도착했습니다. 나는 아침 식사를 할 때까지 그것들을 읽지 않았습니다.

그때쯤이면 메시지가 끊임없이 이어지고 있었고, 내가 직접 연결해 둔 자동화(automation) 시스템에서 동일한 에러 텍스트가 반복되고 있었습니다. 내가 잠든 사이 밤새도록 그것은 스스로와 대화를 나누고 있었습니다.

그 메시지 하나하나가 나의 코딩 에이전트(coding agent)를 호출하는 백그라운드 호출(background call)이었습니다. 자동화 시스템은 알림을 읽고, 응답하고, 새로운 알림을 생성한 뒤, 다시 그 알림에 응답했습니다. 이는 사용량 제한(usage gate)에 걸릴 때까지 스스로에게 계속 입력을 제공했고, 아침이 될 때까지 나에게 실패 메시지를 반복해서 보내기 시작했습니다.

내가 그것을 만들었습니다. 아무도 나에게 고장 난 시스템을 건네준 것이 아닙니다. 나는 작은 도우미를 연결해 두고 자리를 떠났고, 그것은 새벽 2시에 오직 요란하고 반복적으로 실패하는 것만을 유일한 업무로 삼는 기계로 변해버렸습니다.

만약 당신이 cron job, webhook, 또는 백그라운드 워커(background worker)를 AI CLI로 지정해 본 적이 있다면, 이것은 당신의 이야기이기도 합니다. 당신은 그것이 다가오는 것을 보지 못할 것입니다. 왜냐하면 비용을 발생시키는 것은 당신이 지켜보고 있는 것이 결코 아니기 때문입니다. 당신은 화면 속의 데모를 보고 있습니다. 청구서는 당신이 잊어버린 프로세스에 의해 작성되고 있습니다.

모든 것을 바꾼 부분

정말 뼈아픈 지점은 여기입니다. 내가 처음 이 루프(loop)를 경험했을 때는 비용이 발생하지 않았습니다. 그냥 벽에 부딪혀 멈췄을 뿐입니다. 짜증 나고 창피했지만, 무료였습니다.

그러다 6월 15일, 우리 모두의 기반이 흔들렸습니다. Anthropic은 백그라운드 및 헤드리스 사용량(headless usage)을 정액제 구독(flat subscription) 외부에 있는 별도의 종량제 풀(metered pool)로 분리했습니다. 내가 이미 한 번 겪었던 바로 그 패턴, 즉 헤드리스 모드(headless mode)를 호출하는 백그라운드 작업이 내가 지불하는 플랜의 범위를 벗어나 실제 종량제 비용을 발생시키기 시작한 것입니다.

따라서 내가 해결했다고 생각했던 실패가 가격표를 달고 돌아왔습니다. 바로 이 지점이 깊이 생각해 볼 가치가 있습니다. 패턴은 변하지 않았습니다. 그 밑의 경제 구조가 변했을 뿐입니다.

내가 옹호할 주장

Pro 또는 Max 구독은 백그라운드 프로세스가 헤드리스 모드(headless mode)를 호출하는 순간 당신을 보호해주지 않습니다.

정액제 가격은 당신이 키보드 앞에 앉아 프롬프트를 입력하고, 읽고, 수정하는 과정을 보장합니다. 이 서비스는 인간이 개입하지 않은 채 풀 스피드(full speed)로 돌아가는 루프(loop)를 감당하도록 설계된 것이 결코 아닙니다. 대부분의 사람들은 요금제 이름을 보고 한도(cap)가 있다고 가정합니다. 대화형(interactive) 부분에는 한도가 있습니다. 하지만 백그라운드(background) 부분은 사용량에 따라 과금(metered)됩니다.

비용을 발생시키는 다섯 가지 형태

제 사례를 추적한 후, 저는 AI 비용을 조용히 끌어올리는 형태들을 찾아 나섰습니다. 다섯 가지가 반복해서 나타났으며, 이들 모두는 개별적으로 보면 무해해 보이기 때문에 검토 과정에서 그냥 통과시키기 쉬운 것들입니다.

자기 트리거 루프 (The self-triggering loop). 백그라운드 작업(background job)이 이벤트를 읽고, 그에 따라 동작하며, 그 동작 자체가 다시 읽어야 할 새로운 이벤트를 생성합니다. 그대로 두면 스스로를 먹여 살리는 구조가 됩니다. 저의 경우는 자신의 에러 알림(error notifications)에 답변을 하다가, 그 답변이 더 많은 에러를 생성하여 다시 답변하게 만드는 상황이었습니다.

재시도 폭풍 (The retry storm). 일시적인 장애, 401 에러, 타임아웃(timeout), 속도 제한(rate cap) 등이 제한 없이 재시도됩니다. 한 번은 무료로 실패했던 호출이라도, 타이트한 루프(tight loop) 내에서 실행되면 더 이상 무료가 아닙니다. 백오프(backoff)는 모두가 동의하지만, 실제로 문제가 터지기 전까지는 아무도 구현하지 않는 것 중 하나입니다.

병렬 팬아웃 (The parallel fan-out). 배치(batch) 작업을 요청하면, 워커(worker)가 항목당 하나의 AI 호출을 생성합니다. 이로 인해 작다고 생각했던 리스트가 당신이 가격을 책정하지 않았던 지출 승수(spend multiplier)로 변합니다. 10개 항목은 오차 범위 내의 금액이지만, 1만 개 항목은 깜짝 송장(surprise invoice)이 됩니다.

잊혀진 크론 (The forgotten cron). 요금 체계가 바뀌기 전, 몇 달 전에 설정해둔 자동화 작업이 호출 비용이 포함되어 있다는 과거의 가정을 유지한 채 계속 실행됩니다. 가정은 만료되었지만, 크론(cron)은 만료되지 않았습니다. 규칙이 바뀌었다는 사실을 아무도 알려주지 않았기 때문입니다.

작은 작업의 사각지대 (The small-job blind spot). 단 한 줄의 코드입니다. 몇 분마다 실행됩니다. 너무 미미해서 중요하지 않게 느껴집니다. 하지만 아주 작은 작업이 하루에 천 번 실행되고, 그것이 사용량 기반(metered) 풀(pool)과 결합되면 더 이상 작지 않게 됩니다.

이 중 어느 것도 생소한 것이 아닙니다. 바로 그 점 때문에 이들이 몰래 빠져나갑니다. 각각은 그 자체로 합리적으로 보이지만, 위험은 관리되지 않은 채 빠른 속도로 과금 체계를 향해 실행될 때만 나타납니다.

실제로 이를 해결하는 방법

해결책은 더 똑똑한 프롬프트 (prompt)가 아닙니다. 프롬프트는 애초에 문제가 아니었습니다. 해결책은 프로세스 경계 (process boundary)에 위치한 가드 (guard)입니다. 즉, 백그라운드 작업 (background job)이 유료 모드 (paid mode)에 접근하려는 바로 그 지점에 가드를 두는 것입니다.

제가 이를 아는 이유는 이미 그 가드를 작성했고, 테스트했으며, 다른 사람들에게 사용하라고 말했기 때문입니다. 그리고 제가 그 가드 아래로 가져오는 것을 잊어버렸던 저의 이전 자동화 (automation)는 아침이 올 때까지 모든 것을 지나쳐 실행되었습니다. 실패 모드 (failure mode)를 알고 있는 것만으로는 저를 구하지 못했습니다. 제가 잊어버린 단 한 곳에 가드를 연결하는 것만이 저를 구했습니다.

그래서 제 머릿속에 남은 재정의 (reframe)는 다음과 같습니다. 당신은 이미 코드의 정확성을 검토합니다. 디프 (diff)를 읽으며 이것이 시스템을 망가뜨릴지 질문합니다. 당신의 자동화 (automations)도 같은 방식으로 읽기 시작하되, 다른 질문을 던지십시오. "내가 지켜보지 않는 동안 이것이 천 번 실행된다면 비용이 얼마나 들 것인가?"

그 질문이 저의 밤을 구했을 것입니다. 이제 저는 어떤 백그라운드 작업 (background job)이라도 유료 호출 (paid call) 근처에 접근하도록 허용하기 전에 반드시 이 질문을 던집니다.

당신의 차례

과금 체계가 변경된 이후로 한 번도 들여다보지 않은, 현재 실행 중인 백그라운드 작업 (background job)은 무엇인가요?

이 내용이 유용했다면

저는 성공과 정체기를 모두 포함하여 이 과정을 공개적으로 진행하고 있으며, 주로 LinkedIn과 YouTube에서 활동합니다. 공개적으로 빌드하는 (building in the open) 실제 과정이 당신에게 유용하다면, 그곳에서 확인하실 수 있습니다. X, GitHub에서 저를 찾으시거나 next8n.com에서 작업물을 확인해 보세요.