AI 에이전트 시대, 인터넷 인프라의 대변환

왜 이 뉴스가 결제·정산 현장의 경보인가

TechCrunch가 보도한 AWS·Cloudflare의 인프라 재설계 기사를 처음 읽었을 때, 우리 팀 내 첫 반응은 "인프라 팀 얘기 아니야?"였다. 하지만 조금만 파고들면 이 변화의 1차 충격 흡수자는 인프라팀이 아니라 결제·정산·자동화 파이프라인이라는 걸 알게 된다. 이유는 단순하다. 인터넷이 머신을 위해 재설계된다는 말은, 트래픽의 생산자와 소비자 모두 인간이 아닌 에이전트로 바뀐다는 뜻이고, 그 에이전트들이 주고받는 모든 값의 정산을 누군가는 처리해야 하기 때문이다.

우리가 직접 운영하는 결제·정산 파이프라인은 지금까지 하나의 암묵적 전제 위에서 돌아왔다. "요청을 보내는 쪽은 결국 사람이고, 사람은 초당 몇 번 이상 클릭하지 않는다." 이 전제가 무너지면 rate limit 정책, 정산 주기, 이상 거래 탐지 기준, 웹훅 재시도 로직이 동시에 흔들린다. 그것도 점진적으로가 아니라 어느 날 갑자기, 고객사 하나가 AI 에이전트를 프로덕션에 올리는 순간부터.

머신 트래픽은 인간 트래픽과 무엇이 다른가: 수치로 보기

인간이 만드는 트래픽에는 구조적 특성이 있다. 업무 시간인 오전 9시~~오후 6시에 전체 일일 API 호출의 65~~70%가 집중되고, 주말에는 뚝 떨어진다. 이 패턴 덕분에 오토스케일링, 캐시 워밍, T+1 정산 배치가 모두 "예측 가능한 피크"를 전제로 설계되어 왔다.

AI 에이전트는 다르다. 에이전트는 자정에도, 일요일 새벽 3시에도 동일한 throughput으로 API를 호출한다. Stripe의 공개 사례에 따르면, AI 코딩 에이전트를 연동한 B2B SaaS 고객 한 곳이 기존 월간 API 호출량의 40배를 단 72시간 만에 소진한 일이 있었다. 에이전트가 코드 리뷰 루프를 자동으로 돌리면서 결제 API를 반복 테스트했기 때문이다. 이 경우 해당 고객의 월정액 플랜 한도가 터졌고, 정산 시스템은 초과 요금을 실시간으로 계산하지 못해 48시간 뒤에야 청구서를 발행했다. 작은 지연처럼 보이지만, 에이전트 스택 위에서 돌아가는 서비스라면 이 48시간 공백은 현금 흐름 예측 오류로 직결된다.

또 하나 간과하기 쉬운 수치가 있다. 에이전트는 실패한 요청을 공격적으로 재시도한다. 인간 사용자라면 오류 메시지를 보고 잠시 멈추거나 고객센터에 연락하지만, 에이전트는 지수 백오프(exponential backoff) 로직을 타고 500ms, 1s, 2s 간격으로 계속 재시도한다. 결제 API에 멱등성 키(idempotency key)가 없다면, 이 재시도 폭격은 중복 결제로 이어진다. 실제로 우리가 점검한 파이프라인 중 하나에서 에이전트 테스트 중 동일 트랜잭션이 3회 생성된 케이스를 발견했다. 멱등성 키가 HTTP 헤더가 아닌 바디 파라미터로 구현되어 있었고, 에이전트가 바디를 다르게 직렬화(serialize)하면서 서버가 다른 요청으로 인식한 것이다.

AWS·Cloudflare가 실제로 재설계하는 것

AWS와 Cloudflare의 공식 발표와 개발자 블로그를 종합하면, 이들이 손대는 레이어는 크게 세 가지다.

첫째, 연결 유지 방식. 인간 중심 웹은 요청-응답-종료(stateless HTTP)가 기본이었다. 머신 트래픽은 세션을 길게 유지하고, 스트리밍 응답을 선호하며, gRPC나 HTTP/2 멀티플렉싱을 활용해 단일 연결에서 수백 개의 병렬 스트림을 처리한다. Cloudflare는 이미 AI Gateway 제품에서 모델 호출의 스트리밍 응답 캐싱과 요청 병합(request coalescing)을 지원하기 시작했다. 같은 프롬프트를 서로 다른 에이전트 인스턴스가 동시에 보낼 때 하나의 요청으로 합쳐 응답을 공유하는 구조다.

둘째, 인증 레이어. OAuth 2.0의 브라우저 리다이렉트 플로우는 사람이 화면을 보는 걸 전제로 한다. 에이전트는 브라우저가 없다. MCP(Model Context Protocol)를 비롯한 에이전트 간 통신 표준들이 machine-to-machine JWT, API 키 순환(rotation) 자동화, 권한 범위(scope) 세분화를 요구하며 인증 인프라를 빠르게 바꾸고 있다.

셋째, 과금 단위의 세분화. AWS Bedrock은 이미 토큰 단위, 요청 단위, 시간 단위를 혼합한 과금 모델을 실험 중이다. 이는 우리 같은 결제 플랫폼이 고객사를 위해 동일한 수준의 세분화된 정산 로직을 제공해야 한다는 압력으로 돌아온다.

우리 팀이 직면한 가장 현실적인 문제: 정산 단위의 붕괴

결제·정산 팀 입장에서 이 모든 변화를 하나의 문장으로 압축하면 이렇다. "배치 정산은 이제 에이전트 경제와 호환되지 않는다."

현재 우리가 운영하는 정산 파이프라인의 기본 단위는 '일(day)'이다. 하루치 거래를 모아서 T+1에 집계하고, 수수료를 뗀 뒤 다음날 새벽 배치로 지급한다. 이 구조가 작동하는 건 "충분히 긴 시간 단위 안에서 오류가 상쇄된다"는 통계적 전제 때문이다.

에이전트 트래픽이 지배하는 환경에서는 이 전제가 두 방향에서 무너진다. 첫 번째, 처리 속도의 불일치: 에이전트는 초 단위로 API 호출을 발생시키는데 정산은 24시간 뒤에 이루어지면, 에이전트 스택을 운영하는 고객사 입장에서는 "지금 내가 얼마를 쓰고 있는지" 실시간으로 알 방법이 없다. 예산 통제가 불가능해지고, 이는 곧 분쟁(dispute)으로 이어진다. 두 번째, 중복·누락 탐지 타이밍: 중복 결제나 누락 정산은 보통 배치 실행 직후에 발견된다. 에이전트가 새벽에도 동일 속도로 트랜잭션을 생성한다면, 발견 시점과 발생 시점 사이의 간격이 길어질수록 복구 비용이 기하급수적으로 커진다.

트레이드오프도 명확하다. 실시간 정산(real-time settlement)으로 전환하면 정확성과 투명성은 올라가지만, 시스템 복잡도와 인프라 비용이 올라간다. 배치를 유지하면 비용은 낮지만 에이전트 고객사의 요구를 충족하지 못한다. 우리 같은 작은 팀에게 이 둘을 동시에 잡는 현실적인 방법은 점진적 실시간화다. 즉, 전체 정산을 한 번에 실시간으로 바꾸는 게 아니라, 에이전트 트래픽이 감지된 고객사 계정부터 실시간 잔액 추적 레이어를 먼저 씌우는 것이다.

HEDVION 팀 시나리오: 에이전트 트래픽을 정산 파이프라인에 태운다면

구체적인 시나리오를 하나 상정해 보자. HEDVION의 정산 파이프라인을 사용하는 고객사 A가 내달부터 자사 서비스에 AI 에이전트를 붙인다고 통보했다. 해당 에이전트는 사용자 요청을 처리할 때마다 외부 데이터 API를 평균 15회 호출하고, 고객사 A의 예상 DAU(일간 활성 사용자)는 5,000명이다. 에이전트가 하루 24시간 균등하게 동작한다고 가정하면, 하루 API 호출 수는 5,000 × 15 = 75,000건으로 현재의 약 8배다.

우리 팀이 지금 당장 해야 할 일은 세 가지다.

1. 멱등성 키 검증 강화. 고객사 A의 에이전트가 어떤 직렬화 라이브러리를 쓰는지 확인하고, 우리 API의 멱등성 키가 헤더 기반인지 바디 기반인지 명세를 재정비한다. 불일치가 있다면 마이그레이션 가이드를 먼저 제공해야 한다.

2. 실시간 잔액 추적 레이어 파일럿. 전체 정산 시스템을 건드리지 않고, 고객사 A 계정에 한해 Redis 기반의 실시간 사용량 카운터를 붙인다. 배치 정산은 그대로 유지하되, 고객사 A가 언제든지 "현재까지 발생한 금액"을 API로 조회할 수 있게 한다. 개발 공수는 2~~3스프린트, 인프라 비용 증가는 월 5~~10만 원 수준으로 통제 가능하다.

3. 이상 탐지 기준 재보정. 현재 이상 거래 탐지는 "분당 X건 초과 시 알림" 기준이 인간 트래픽 기준으로 세팅되어 있다. 에이전트 트래픽이 붙으면 정상 트래픽이 이 기준을 넘을 수밖에 없다. 고객사별로 에이전트/비에이전트 트래픽을 구분하는 태깅 레이어를 추가하고, 탐지 기준을 계정 유형별로 분리해야 한다.

이 세 가지는 이미 존재하는 기술로 구현 가능하다. 문제는 기술이 없어서가 아니라, 우리가 먼저 고객사에 묻지 않으면 아무도 이걸 알려주지 않는다는 점이다.

지금 당장 쓸 수 있는 시사점

이 글을 읽고 바로 할 수 있는 것들을 우선순위 순으로 정리한다.

이번 주 안에: 현재 운영 중인 결제·정산 API의 멱등성 키 구현 방식을 확인하라. 헤더(Idempotency-Key)로 받는지, 바디 파라미터로 받는지, 아니면 없는지. 없다면 최우선 기술 부채다.

이번 달 안에: 주요 고객사 5곳에 "AI 에이전트 도입 계획이 있는가"를 직접 물어라. 있다면 예상 호출 규모와 재시도 정책을 수집하고, 그 숫자를 현재 파이프라인의 처리 한계치와 비교하라.

다음 분기 안에: 배치 정산과 별도로 실시간 사용량 조회 엔드포인트를 파일럿으로 구축하라. 전체 정산 로직을 바꾸는 게 아니라 "읽기 전용 실시간 집계"만 먼저 붙이는 것이다. 이 엔드포인트 하나가 에이전트 트래픽을 다루는 고객사에게 결정적인 신뢰 신호가 된다.

구조적으로: 이상 거래 탐지 임계값을 고객 계정 유형(에이전트/비에이전트)별로 분리하는 태깅 시스템을 설계하라. 에이전트 트래픽이 섞이는 순간 기존 알림이 모두 노이즈가 되거나, 반대로 진짜 이상을 놓치게 된다.

인터넷이 머신을 위해 재설계되는 속도는 우리가 예상하는 것보다 빠를 것이다. 하지만 대응의 시작은 거창한 아키텍처 변환이 아니다. 지금 운영 중인 파이프라인의 어느 가정이 "사람이 보낸 요청"을 전제로 하는지 하나씩 짚어내는 것에서 시작된다.