AI는 일단 막으려 한다 — 권한은 주고, 압력은 가격으로

AI 페어 프로그래밍

AI는 일단 막으려 한다

자원·과금 설계 — 권한은 주고, 압력은 가격으로

핵심 요약

• 컴퓨팅이 많이 드는 작업을 사용자가 직접 돌리는 SaaS에서 "자원 통제 어떻게 하지?"를 AI에게 물으면, 답은 거의 항상 제한이다.
• AI의 기본값은 "막을 수 있으면 막는다"인데, 인위적 제한은 오토스케일 아키텍처와 싸우고, 심지어 돈 내고 더 쓰려는 사용자(=매출)까지 거절한다.
• 유효한 제한은 셋뿐이다 — 단일 작업 크기 상한(sanity) · 잔액 · 클러스터 한계. 쿨다운·동시성 캡·횟수 quota는 군더더기다.
• 막는 대신 제출 시점에 비용을 잔액에서 예약(hold)하면, 동시성은 인위적 숫자가 아니라 잔액이 정한다. 권한은 주고, 압력은 가격으로.

1.AI에게 자원 설계를 맡기면 일단 막는다

컴퓨팅이 많이 드는 작업(백테스트, 모델 학습, 대용량 처리)을 사용자가 직접 돌리는 SaaS를 만들다 보면, "자원을 어떻게 통제하지?"라는 질문에 도달한다. 이걸 AI에게 물으면 답은 매끄럽고 그럴듯한데 — 거의 항상 '제한'이다.

그리고 한 번 막고 끝나지 않는다. 같은 본능이 대화 내내 반복해서 튀어나온다(실제로 한 대화에서 같은 패턴이 네 번 나온 적도 있다). 문제는 그 제한들이 대부분 틀렸다는 것이다. 왜 틀렸고, 대신 무엇을 해야 하는지 보자.

2.네 가지 얼굴, 같은 본능

AI가 자원 통제로 제안하는 것들을 모아보면 대개 이렇다.

• 쿨다운 — "너무 자주 못 하게 N시간 잠그자."
• 사용자당 동시 실행 캡 — "한 사용자가 동시에 3개까지만."
• 크레딧과 별개의 횟수 quota — "크레딧이 있어도 월 N회로 제한하자."
• 유료(종량) 결제 차단 — "무료 등급은 충전해서 더 쓰는 걸 막자."

공통점이 보인다. 전부 사용자가 하려는 것을 막는다. 그리고 마지막 항목은 돈을 내고 하려는 것까지 막는다. 각각은 그럴듯해 보이지만, 한 발 물러서면 방향이 일관되게 틀려 있다 — "안전"이라는 이름으로 사용자와 매출을 동시에 깎고 있다.

3.왜 틀렸나 — 인위적 제한은 아키텍처와 싸운다

요즘 이런 시스템은 오토스케일(autoscaling) 위에 선다 — 부하가 늘면 처리 인스턴스(워커)가 자동으로 더 뜬다. 이 구조에서 부하의 올바른 답은 "사용자를 막기"가 아니라 "워커를 띄우고, 그 비용을 과금으로 회수하기"다.

그 관점에서 보면 "사용자당 동시 실행 캡"은 아무것도 보호하지 않는다.

• 시스템 폭주가 걱정? 그건 클러스터 한계(전체 워커 상한·DB 연결 수)가 막는다 — 사용자 단위가 아니라 시스템 단위로.
• 한 사용자가 자원을 독식? 돌리는 만큼 과금된다. 50개를 돌리면 워커 50개 띄워 처리하고 50개분을 받으면 된다.
• 그러니 per-user 캡이 추가로 막는 건 없다. 돈 내고 더 쓰려는 사용자를 frustrate시키는 것, 딱 그거다.

⚠ 매출을 거절하는 제한

네 번째 항목 — "유료 결제 차단" — 은 더 노골적이다. 사용자가 돈을 내겠다는데 막는다. 전환(conversion)을 강제하려는 의도지만, 결과는 그냥 매출 거절이다. 비합리적인데도 "등급을 나눠야 한다"는 직관에 묻혀 그럴듯하게 들린다.

4.유효한 제한은 셋뿐

제한을 다 없애자는 게 아니다. 진짜로 필요한 제한은 셋뿐이고, 나머지는 이 셋이 이미 하는 일을 중복한다.

제한	유효?	무엇을 보호하나
단일 작업 크기 상한	✅ 항상	"천억 × 천억 계산해줘" 같은 비상식 입력 차단(sanity). 작업 하나는 워커를 늘려도 쪼개지지 않으니 크기 자체에 상한이 필요
잔액	✅ 항상	사용자별 진짜 한계 — 충전(funding)한 만큼 쓴다
클러스터 한계	✅ 항상	시스템 전체의 물리·재정 천장. 모든 사용자가 공유, 한 사람 사용량과 무관
쿨다운 · 동시성 캡 · 횟수 quota	❌ 인위적	위 셋이 이미 보호. 사용자 행동을 "shape"하려는 군더더기

5.막는 대신 값을 매긴다 — credit hold

그래서 사용자당 동시성 캡을 제거하고, 대신 작업을 제출하는 순간 예상 비용을 잔액에서 잡아둔다 (hold). 완료되면 정산하고, 취소·실패하면 환불한다. 그러면 동시 실행 수는 인위적 숫자가 아니라 잔액이 자연스럽게 정한다 — 잔액이 받쳐주는 만큼만 동시에 돌아간다.

제출 경로 — 캡 대신 holdPython

# ❌ AI가 처음 제안한 것 — 인위적 동시성 캡
MAX_CONCURRENT_JOBS_PER_USER = 3
if active_job_count(user) >= MAX_CONCURRENT_JOBS_PER_USER:
    raise TooManyJobs()          # 돈 내고 더 돌리려는 사용자도 막힌다

# ✅ 바꾼 것 — 제출 시점에 예상 비용을 잔액에서 hold
hold = estimate_cost(job)
wallet.reserve(hold)             # 잔액이 부족할 때만 거절
# 완료 → 정산 / 취소·실패 → 환불.
# 동시성은 "캡"이 아니라 "잔액"이 정한다 — 인위적 숫자 0.

제한의 종류를 구분하라

rate limit(초당 요청 수)은 폭주·남용 방어용, quota(월 N회)는 사용량 상한, credit hold(제출 시 비용 예약)는 계량 과금이다. 동시성 압력에는 hold가 맞다 — 게이트(막대기)가 아니라 미터기로 풀면, 사용자를 막지 않고도 시스템이 비용을 회수한다.

6.왜 AI의 기본값은 "통제"인가

되짚어보면 이건 한 번의 실수가 아니라 일관된 기울기다. 왜 그럴까.

• 학습 데이터의 관성 — "rate limit / quota / throttle"은 엔지니어링 글에서 책임감 있는 기본 답으로 등장한다. 모델은 "자원 + 다수 사용자 → 제한"을 패턴 매칭한다.
• 제한은 안전해 보인다 — 막는 쪽이 신중해 보이고, 모델은 신중해 보이는 답으로 기운다. 하지만 그건 사업적 결과(매출 거절)도, 아키텍처(오토스케일이 흡수)도 따지지 않은 반사다.

좋은 SaaS는 정반대로 큰다. Stripe·Vercel·각종 API는 사용자를 막아서가 아니라 가격 차등과 계량 과금으로 성장한다. 이건 도구가 스스로 도달하지 못하는 판단이라, 원칙으로 박아두지 않으면 같은 제한이 계속 기어 나온다.

7.제한을 제안하기 전, 한 가지를 물어라

자가 점검

"이게 fairness·UX·시스템을 보호하는가, 아니면 그냥 결제를 강제(conversion)하는가?" — 후자면 버린다. 전환 압력은 제한이 아니라 가격 차등으로 만든다(예: 종량 단가 > 구독 단가).

AI에게 자원·과금 설계를 맡길 때도 이 질문을 함께 시키면, 반사적으로 튀어나오는 제한을 한 겹 걸러낼 수 있다.

오해는 말자 — 모든 제한이 나쁜 건 아니다. 위 질문의 답이 "보호"인 제한은 당연히 둔다. 남용·보안(초당 요청 폭주, 크리덴셜 스터핑)을 막는 rate limit이나 안전·규제 한도는 통제가 아니라 보호다. 특히 과금이 안 걸린 무료·미인증 경로는 "잔액이 압력"이 성립하지 않으니 거기선 hard cap이 정당하다 — 돈을 안 내는 사용자에게 비싼 연산을 무한히 내줄 순 없다. 요점은 "제한을 없애라"가 아니라, "통제하려는 제한"과 "보호·비용 회수하는 제한"을 구분하라는 것이다.

8.정리

AI는 막는 답을 자신감 있게 내놓지만, 막는 게 늘 안전한 건 아니다. 때로 가장 안전해 보이는 제한이 아키텍처와 싸우고, 사용자를 쫓고, 매출을 거절한다. 그래서 자원·과금을 설계할 땐 한 줄만 기억하면 된다 — 권한은 주고, 압력은 가격으로. 그 둘을 헷갈리지 않는 건, 적어도 아직은 사람의 몫이다.

바이브코딩 · AI와 더 잘 일하는 법