p99 수준에서 3개 지역에 Airtable AI를 운영하며 배운 점

엔지니어링 부사장(VP of Engineering)이 제 속을 철렁하게 만든 질문을 던졌던 Slack 스레드가 아직도 기억납니다. "새로운 AI 워크플로우(workflow)에서 99.9%를 달성할 수 있습니까, 아니면 아키텍처(architecture)를 다시 검토해야 합니까?" 그 순간 저는 Airtable AI를 단순한 영리한 데모가 아닌, 프로덕션급(production-grade) 워크로드(workload)로서 진지하게 다루기 시작했습니다. 6개월 후, 우리는 3개 지역에서 이를 원활하게 운영하고 있으며, p99 지연 시간(latency)은 예산 범위 내에 있고, CFO가 실제로 미소 지을 만한 청구서를 받고 있습니다. 제가 무엇을 배웠는지 설명해 드리겠습니다.

배포(deployment) 모델링을 시작했을 때 저를 놀라게 했던 첫 번째 사실은 모델 옵션이 얼마나 많은가 하는 점이었습니다. Global API는 현재 100만 토큰(token)당 0.01달러에서 3.50달러 사이의 가격대로 184개의 AI 모델을 노출하고 있습니다. 그 범위는 엄청납니다. 만약 AI를 모놀리스(monolith)처럼 취급하여 — 모델 하나를 골라 모든 곳에서 실행한다면 — 돈을 낭비하게 되거나, 더 나쁘게는 필요하지 않은 성능에 대해 과도한 비용을 지불하게 될 것입니다. 아키텍처 측면에서 게임의 핵심은 적절한 쿼리(query)를 적절한 모델로 라우팅(routing)하는 것입니다.

2026년의 Airtable AI는 단일 API가 아닙니다. 그것은 라우팅(routing) 문제입니다. 솔직히 말해서, 프로덕션에서 운영해 본 결과, 팀들이 범용 솔루션에 비해 비용을 40~65% 절감하면서도 대등하거나 더 나은 품질을 유지하고 있다고 확신합니다. 이 수치는 마케팅용 미사여구가 아닙니다. 매달 저희 내부 대시보드(dashboard)에서 확인하는 실제 수치입니다.

가격표가 아키텍트에게 실제로 의미하는 것

가격표는 대규모(scale)로 투영해 보기 전까지는 지루해 보입니다. 제가 모니터에 붙여놓고 계속 확인하는 내용을 살펴보겠습니다:

DeepSeek V4 Flash: 입력(input) $0.27 / 출력(output) $1.10, 128K 컨텍스트(context)
DeepSeek V4 Pro: 입력(input) $0.55 / 출력(output) $2.20, 200K 컨텍스트(context)
Qwen3-32B: 입력(input) $0.30 / 출력(output) $1.20, 32K 컨텍스트(context)
GLM-4 Plus: 입력(input) $0.20 / 출력(output) $0.80, 128K 컨텍스트(context)
GPT-4o: 입력(input) $2.50 / 출력(output) $10.00, 128K 컨텍스트(context)

이 차이가 자릿수(order of magnitude) 단위로 다르다는 점에 주목하십시오. GPT-4o는 GLM-4 Plus와 비교했을 때 입력(input)은 약 9배, 출력(output)은 약 12배 더 비쌉니다. 이 비율은 수백만 개의 토큰(token)에 걸쳐 일관되게 유지되며, 이는 하루에 1억 개의 토큰을 사용할 경우 라우팅 로직(routing logic)에 따라 월간 비용이 5만 달러 중반에서 6만 달러 중반 사이로 요동칠 수 있음을 의미합니다. 품질에 대해 부사장(VP)이 무엇이라 말하든 상관없습니다. 이것은 아키텍처(architectural) 결정이지, 느낌(vibes)에 따른 결정이 아닙니다.

우리의 설정에서 GPT-4o는 트래픽의 약 5%를 위해 예약되어 있습니다. 즉, 정말로 더 큰 두뇌가 필요한 진정으로 복잡한 추론(reasoning) 작업들입니다. 그 외의 모든 것은 p99에 민감한 핫 패스(hot path)를 위해 DeepSeek V4 Flash로 라우팅되며, 중간 난이도의 추출(extraction) 작업은 Qwen3-32B로 라우팅됩니다. GLM-4 Plus는 탁월함보다는 신뢰성이 더 필요한 대량의 단순 쿼리(query)를 처리하기 위한 저의 비밀 병기가 되었습니다.

나의 멀티 리전 토폴로지 (Multi-Region Topology)

우리는 회복 탄력성(resilience)을 위해 us-east, eu-west, ap-southeast 세 개의 리전(region)을 선택했습니다. 각 리전은 지리적 라우팅(geo-routing)을 수행하는 글로벌 로드 밸런서(global load balancer)를 전면에 두고 동일한 Airtable AI 파이프라인(pipeline)을 실행합니다. 우리가 내부적으로 약속하는 SLA(Service Level Agreement)는 99.9%입니다. 이는 한 달에 약 43분의 다운타임(downtime)을 허용한다는 의미인데, 새벽 3시에 호출(page)을 받는 당사자가 되기 전까지는 관대하게 들릴 것입니다.

지난 90일 동안 실제로 측정된 업타임(uptime)은 99.94%이며, 저는 이에 대해 조용히 자부심을 느낍니다. 우리가 이 수치에 도달한 방법은 단일 리전 최적화보다는 주로 중복성(redundancy)을 통한 것이었습니다. 만약 us-east에 문제가 생기면, 트래픽은 1초 미만의 DNS 페일오버(failover)와 함께 eu-west로 전환됩니다. 잠시 후에 설명할 캐시 레이어(cache layer)는 새로운 연결이 예열(warm up)되는 동안 스파이크(spike)를 흡수합니다.

p99 지연 시간(latency)은 저를 밤잠 설치게 만드는 숫자입니다. 우리의 목표는 엔드 투 엔드(end-to-end) 전체 요청 라이프사이클(request lifecycle)에 대해 1.8초입니다. AI 추론(inference) 부분은 초당 약 320 토큰(token)의 처리량(throughput)으로 평균 약 1.2초에 실행됩니다. 그러면 TLS, 인증(auth), 큐잉(queueing), 응답 직렬화(response serialization) 등 나머지 모든 작업을 위해 600ms가 남습니다. 빠듯하지만, 기반이 되는 모델이 제대로 작동한다면 달성 가능한 수치입니다.

기본값이 아닌 의도(Intent)에 따른 라우팅

여기서부터 Airtable AI가 제값을 하기 시작합니다. 제가 정착한 패턴은 엣지(edge)에서의 의도 기반 라우팅(intent-based routing)입니다. 작은 분류기(tiny prompt로 실행되는 GLM-4 Plus와 같이 저렴하고 빠른 것)가 이 쿼리가 어떤 종류인지 결정합니다. 그런 다음 그에 따라 라우팅합니다:

사소한 쿼리 (yes/no, 단순 조회) → GLM-4 Plus
중간 복잡도 (요약, 구조화된 추출) → Qwen3-32B 또는 DeepSeek V4 Flash
고도의 추론 (다단계 분석, 코드 생성) → DeepSeek V4 Pro
프리미엄 티어 (고객 대상 플래그십 기능) → GPT-4o

이것이 40-65%의 비용 절감을 이끌어낸 패턴입니다. 우리는 "이 단락을 요약해줘"와 같은 요청에 GPT-4o 가격을 지불하지 않습니다. 대신 해당 요청들에 대해 백만 토큰당 몇 센트 수준의 비용을 지불합니다.

온콜(On-Call) 교대 근무를 견뎌내는 코드

실제 운영 환경에 바로 적용 가능한 설정을 보여드리겠습니다. 내부 관측성(observability) 훅은 제거했지만, 뼈대는 우리가 실제로 실행하는 것과 동일합니다:

import openai
import os
import time
...

저 타임아웃 폴백(timeout-fallback) 패턴이 99.9% SLA와 99.5% SLA의 차이를 만듭니다. 모델이 컨디션이 좋지 않을 때 — 모델들도 가끔 그럴 때가 있습니다 — 클라이언트는 사용자에게 500 에러를 반환하는 대신 다음 티어로 격상됩니다. 고객의 관점에서는 응답이 약간 더 느려질 뿐입니다. 저의 관점에서는 페이저(pager)가 조용하게 유지됩니다.

진짜 비용 절감은 캐싱(Caching)에서 일어납니다

솔직히 말씀드리면, 처음에는 AI 응답을 캐싱하는 것에 대해 회의적이었습니다. 모든 프롬프트가 고유하기 때문에 캐시 히트율(cache hit rates)이 매우 낮을 것이라고 가정했기 때문입니다. 하지만 제대로 계측(instrument)해 보니 수치가 올라가는 것을 확인할 수 있었습니다.

우리는 운영 트래픽에서 40%의 캐시 히트율 (cache hit rate)을 달성하고 있으며, 이 단일 지표가 하룻밤 사이에 우리의 단위 경제성 (unit economics)을 변화시켰습니다. 40%의 히트율은 추론 비용 (inference bill)의 40%가 즉시 사라진다는 것을 의미합니다. 핵심은 정확히 일치하는 방식의 캐싱 (exact-match caching)이 아니라 의미론적 캐싱 (semantic caching)입니다. 우리는 들어오는 쿼리를 임베딩 (embed)하고, 벡터 저장소 (vector store)에서 가장 가까운 이웃 (nearest neighbor)을 검색하며, 코사인 유사도 (cosine similarity)가 0.92 이상이면 캐시된 응답을 제공합니다. 이는 신뢰할 수 있을 만큼 충분히 높으면서도, 실제로 작동을 유발할 수 있을 만큼 충분히 낮습니다.

체감 성능을 위한 스트리밍 (Streaming for Perceived Performance)

p99 지연 시간 (latency)도 중요하지만, 체감 지연 시간 (perceived latency)이 더 중요합니다. 제 테스트 결과에 따르면 스트리밍 응답은 체감 지연 시간을 60-70% 단축시킵니다. 느린 모델에서도 첫 번째 토큰 (first token)이 200-300ms 내에 도착하며, 사용자는 즉시 진행 상황을 볼 수 있습니다. 전체 실제 소요 시간 (wall-clock time)은 동일하지만, 인간은 작업이 진행되는 것을 볼 수 있을 때 놀라울 정도로 인내심을 가집니다.

Global API는 184개 모든 모델에서 스트리밍을 지원하므로, 사용하지 않을 이유가 없습니다. 다음은 동일한 호출의 스트리밍 변형입니다:

def stream_completion(self, prompt: str, model: str = "deepseek-ai/DeepSeek-V4-Flash"):
    stream = self.client.chat.completions.create(
        model=model,
...

문제없이 수행하는 오토스케일링 (Auto-Scaling Without the Drama)

AI 워크로드의 오토스케일링 (Auto-scaling)은 그 자체로 매우 까다로운 문제입니다. 추론은 메모리 제한적 (memory-bound)이기 때문에 단순히 CPU를 기준으로 스케일링할 수 없습니다. 또한 요청당 토큰 수가 크게 달라지기 때문에 요청 수 (request count)를 기준으로 스케일링할 수도 없습니다. 우리는 결국 커스텀 지표 (custom metric)인 '레플리카당 처리 중인 토큰 수 (tokens-in-flight per replica)'를 사용하게 되었습니다. 이 수치가 용량의 80%를 초과하면 스케일 아웃 (scale out)을 수행하고, 5분 동안 30% 미만으로 떨어지면 스케일 인 (scale in)을 수행합니다.

리전 간 (Cross-region) 오토스케일링은 상황이 더욱 복잡해지는 지점입니다. 우리는 "핫 스페어 (hot spare)" 패턴을 실행합니다. us-east가 기본 트래픽을 처리하고, eu-west는 5% 용량의 합성 트래픽 (synthetic traffic)으로 웜 상태 (warm)를 유지하며, ap-southeast는 us-east와 eu-west가 모두 70% 이상의 사용률을 보일 때만 레플리카 (replicas)를 생성합니다. 이를 통해 24시간 내내 비용을 지불하지 않고도 급증하는 트래픽에 대응할 수 있는 버스트 용량 (burst capacity)을 확보할 수 있습니다.

고객에게 약속하는 것 (그리고 그 방법)

SLA (Service Level Agreement)에 대한 논의는 아키텍트가 자신의 가치를 증명하는 지점입니다. 우리는 99.9%의 가용성을 약속하며, 이는 "당신의 AI 워크플로우가 1,000번 중 최소 999번은 성공적으로 응답할 것"임을 의미합니다. 우리는 p95 응답 시간을 2.5초 미만으로 약속합니다. 하지만 SLA에 p99를 포함하지는 않는데, 그 이유는 p99가 기이한 엣지 케이스 (edge cases)들이 발생하는 지점이며, 이를 약속한다는 것은 장애 검토 (incident review)의 지옥 속에서 살아야 함을 의미하기 때문입니다.

제가 내부적으로 약속하는 것은 p99를 3.0초 미만으로 유지하는 것입니다. 현재 우리는 2.7초를 유지하고 있으며, 이는 작지만 실질적인 버퍼 (buffer)를 제공합니다. 그 버퍼가 사라지면, 용량을 추가하거나 라우팅 로직 (routing logic)을 강화해야 할 시점임을 알 수 있습니다. 이를 모니터링하는 대시보드는 제 화면에서 가장 중요한 요소입니다.

솔직한 평가

운영 환경에서 6개월을 보낸 후, 2026년 플랫폼 선택지로서 Airtable AI에 대한 저의 솔직한 견해는 다음과 같습니다. 신뢰성, 비용 규율, 그리고 기술 지형이 변화함에 따라 모델을 교체할 수 있는 유연성이 필요한 플랫폼 워크로드 (platform workloads)에 있어 최적의 선택입니다. 수치들이 이를 뒷받침합니다. 대안들보다 40~65% 저렴하며, 평균 지연 시간 (latency) 1.2초, 초당 320 토큰의 처리량 (throughput), 테스트 스위트 전반에 걸친 평균 벤치마크 점수 84.6%, 그리고 라우팅 패턴을 이해한 후 10분 이내의 설정 시간을 기록했습니다.

아키텍처 측면에서 제가 가장 높게 평가하는 점은 통합된 SDK 인터페이스입니다. 184개의 모델을 위해 서로 다른 클라이언트 코드를 작성할 필요가 없습니다. 하나의 클라이언트, 하나의 베이스 URL (https://global-apis.com/v1), 하나의 인증 체계 (auth scheme)만 있으면 무엇으로든 라우팅할 수 있습니다. 이러한 추상화 (abstraction) 덕분에 저는 밤에 편히 잠들 수 있습니다. 모델 지형이 밑바닥에서 변하더라도 제 코드베이스가 부식되지 않는다는 것을 의미하기 때문입니다.

만약 여러분의 스택을 위해 이를 검토하고 있다면, 저의 조언은 이렇습니다. 모델 선택이 아니라 라우팅 로직부터 시작하십시오. 저렴한 기본 모델을 선택하고, 폴백 체인 (fallback chain)을 설정하며, 철저하게 계측 (instrument)한 뒤, 데이터가 어디에 비용을 써야 할지 말하게 하십시오. 실제 트래픽이 어떤 모습인지 확인하고 나면, 비싼 모델이 실제로 필요한 경우가 얼마나 드문지 깨닫고 놀라게 될 것입니다.

직접 자세히 알아보고 싶다면, Global API는 명확한 가격 페이지와 실험해 볼 수 있는 184개 모델 전체 목록을 제공합니다. 저는 그들의 무료 크레딧 (free credits) 티어로 시작했습니다.