DEVOCEAN

Anthropic의 2026년 3분기 매출 증가액은 2분기 68억 달러에서 52억 달러로 줄었습니다. 반면 같은 시기 Cloudflare는 DNS 레코드 수천만 개를 매번 다시 빌드하던 파이프라인에 변경 범위 추적 플래너를 붙여 전체 빌드 횟수를 약 40% 줄였습니다.

두 소식은 서로 다른 영역처럼 보이지만, 운영 현장이 맞닥뜨린 현실을 보여줍니다. 모델 파라미터를 키우고 전체 데이터를 매번 처음부터 다시 밀어 넣는 방식은 한계에 부딪혔습니다. 전사로 퍼지는 AI 호출을 단일 관문에서 묶어 비용과 권한을 통제하는 아키텍처, 그리고 인프라에서 바뀐 부분만 골라내 최소 단위로 처리하는 결정론적 스케줄링이 실무의 기준으로 올라서고 있습니다.

지출 둔화 신호와 중앙 통제: 흩어진 엔드포인트의 단일화

Anthropic의 성장세 정체 추정에 따르면 3분기 매출은 168억 달러로 전 분기보다 45% 늘어났으나, 분기 실적과 7월 매출(연환산 650억 달러, 월 약 54억 달러)을 결합해 분석한 결과 8월과 9월의 성장은 소폭에 그쳤습니다. 2분기에 68억 달러였던 분기 매출 증가액이 3분기에는 52억 달러로 꺾였습니다.

이 수치는 기업 고객들이 AI API를 무조건 열어두고 호출하던 실험 단계를 지나, 실질적인 비용 타당성을 검증하고 지출을 통제하기 시작했음을 시사합니다. 계절적 요인이나 인프라 공급 능력 부족일 수도 있지만, 현업 개발팀이 체감하는 분위기도 크게 다르지 않습니다. 각 부서가 임의로 외부 API 키를 발급받아 쓰던 방식은 재무적, 보안적 한계에 부딪혔습니다.

현업에서 이 문제를 푸는 구체적인 방식이 바로 게이트웨이를 통한 단일 창구 구축입니다. CJ올리브네트웍스의 LLM Gateway 구축 사례는 전사 AX(AI 전환) 추진 과정에서 파편화된 모델 접근 경로를 하나로 모은 과정을 상세히 설명합니다. 일부 개발자의 실험적 사용을 넘어 전사 도구로 자리 잡는 과정에서, 거버넌스가 기술 도입 속도를 따라가지 못하는 병목이 드러났기 때문입니다.

CJ올리브네트웍스는 Amazon Bedrock, Claude Platform on AWS, 사내 오픈 소스 모델까지 모든 LLM 호출을 단일 엔드포인트로 연결하는 중앙 게이트웨이(AWSome AI Gateway 기반)를 구성했습니다. 이를 통해 누가 어떤 모델을 쓰는지, 비용이 어디서 발생하는지, 회사 데이터가 어떤 경로로 흘러가는지를 한곳에서 통제합니다.

여기서 핵심은 모델을 바꾸는 것이 아니라 모델로 향하는 네트워크와 인증 경로를 통제하는 일입니다. 클라이언트는 뒷단의 실제 모델 주소를 알 필요 없이 표준화된 규격으로 요청을 보내고, 게이트웨이가 토큰 제한, 로깅, 접근 인가, 라우팅을 대행합니다.

판단: LLM 게이트웨이는 전사 규모로 사내 AI를 배포하려는 팀이라면 지금 써볼 만합니다. 개별 프로젝트마다 API 키를 배포하고 클라이언트 단에서 속도 제한(Rate Limiting)과 토큰 추적을 구현하는 방식은 파편화를 부르고 비용 누수를 막지 못합니다. 단일 진입로에서 정책을 강제해야 운영 거버넌스를 확보할 수 있습니다.

최소 작업만 골라내는 플래너: DNS 전체 빌드의 비효율 제거

대규모 인프라에서도 자원의 낭비를 줄이고 변경점만 처리하려는 시도가 이어지고 있습니다. Cloudflare의 DNS 빌드 파이프라인 개선 사례는 데이터 규모가 커졌을 때 단순 파이프라인이 겪는 병목을 어떻게 걷어냈는지 보여줍니다.

기존 Cloudflare의 시스템에서는 특정 영역의 사소한 설정 변경이 발생해도 수천만 개에 달하는 DNS 레코드 전체를 다시 처리해야 했습니다. 변경 빈도가 높아질수록 빌드 대기열이 밀리고 메모리가 고갈되는 구조적 결함이 있었습니다.

Cloudflare는 변경 범위만 재빌드하는 플래너와 통합 스케줄러를 도입해 이 문제를 해결했습니다. 플래너는 이벤트 자체뿐 아니라 실행 직전의 데이터베이스 상태를 대조하여, 안전성을 엄밀히 입증할 수 있는 최소 작업만 선택합니다. 만약 변경 범위를 특정할 수 없거나 모호한 상황이 발생하면 원칙적으로 전체 빌드를 수행하도록 안전장치를 두었습니다.

또한 Kafka 메시지 처리 방식도 개선했습니다. 같은 DNS 영역에 쌓인 여러 변경 요청을 하나로 병합하여 연산 낭비를 없애되, 각 메시지의 완료 상태 추적은 개별적으로 유지했습니다. 이를 통해 네트워크 재시도나 작업 병합 과정에서 특정 업데이트가 유실되는 위험을 원천 차단했습니다.

결과는 수치로 입증되었습니다. 전체 빌드 횟수가 약 40% 감소했고, 79GiB에 달하던 피크 메모리 사용량이 큰 폭으로 절감되었습니다. 모든 것을 다시 계산하는 단순한 파이프라인 대신, 데이터 상태를 판별하여 '안전성이 입증된 최소한의 델타(Delta)'만 흘려보내는 스케줄러가 대규모 시스템의 안정성을 보장한 셈입니다.

판단: 상태 대조 기반의 작업 분할 플래너는 조건부로 유효합니다. 데이터 변경 빈도가 매우 높고 전체 연산 비용이 큰 파이프라인을 운영 중인 팀에게 적합합니다. 변경 범위를 계산하고 안전성을 검증하는 플래너 자체의 연산 오버헤드와 분기 복잡도가 추가되므로, 데이터 규모가 작거나 단순 CRUD 중심인 환경에서는 오히려 관리 비용만 늘어날 수 있습니다.

실무 구현: 중앙 게이트웨이와 상태 기반 캐싱 라우팅

실무에서 LLM 게이트웨이와 최소 작업 분기 설계를 접목할 때 가장 먼저 맞닥뜨리는 과제는 표준화된 엔드포인트 제공과 불필요한 LLM 호출의 차단입니다.

아래 예시는 Fastify를 기반으로 작성한 LLM 프록시 게이트웨이의 핵심 라우팅 로직입니다. 클라이언트 요청의 본문 해시를 계산하여 직전 요청과 동일한 프롬프트 상태인 경우 실제 LLM 호출을 건너뛰고 캐시된 결과를 즉시 반환하며, 모델 호출 시 사용자 식별자와 토큰 정책을 중앙에서 검증합니다.

import fastify, { FastifyInstance, FastifyRequest, FastifyReply } from 'fastify';
import crypto from 'node:crypto';

interface ChatCompletionBody {
  model: string;
  messages: Array<{ role: string; content: string }>;
  user: string;
}

const server: FastifyInstance = fastify({ logger: true });

// 메모리 기반 단순 캐시 및 토큰 추적 저장소 (실무에서는 Redis 등으로 대체)
const responseCache = new Map<string, { response: string; expiresAt: number }>();
const userDailyTokens = new Map<string, number>();
const DAILY_TOKEN_LIMIT = 50000;

function calculatePromptHash(model: string, messages: Array<{ role: string; content: string }>): string {
  const content = `${model}:${JSON.stringify(messages)}`;
  return crypto.createHash('sha256').update(content).digest('hex');
}

server.post('/v1/chat/completions', async (request: FastifyRequest, reply: FastifyReply) => {
  const body = request.body as ChatCompletionBody;
  const { model, messages, user } = body;

  if (!user || !model || !Array.isArray(messages)) {
    return reply.status(400).send({ error: '필수 필드가 누락되었습니다 (user, model, messages).' });
  }

  // 1. 사용자 일일 할당량 검증
  const currentTokens = userDailyTokens.get(user) ?? 0;
  if (currentTokens >= DAILY_TOKEN_LIMIT) {
    return reply.status(429).send({ error: '일일 토큰 사용 한도를 초과했습니다.' });
  }

  // 2. 상태 대조를 통한 변경 없는 중복 요청 최소화
  const promptHash = calculatePromptHash(model, messages);
  const cached = responseCache.get(promptHash);

  if (cached && cached.expiresAt > Date.now()) {
    server.log.info({ user, promptHash }, '캐시된 LLM 응답을 반환합니다.');
    return reply.send({
      id: `cached-${promptHash.slice(0, 8)}`,
      cached: true,
      result: cached.response,
    });
  }

  // 3. 중앙 통제 엔드포인트로 실제 모델 요청 분기
  server.log.info({ user, model }, '업스트림 LLM으로 요청을 전달합니다.');
  
  // 실제 외부 API 호출 시뮬레이션
  const simulatedResponse = `[${model}] 처리 완료: ${messages[messages.length - 1].content}`;
  const estimatedTokens = 120; // 실제 환경에서는 토크나이저 계산값 사용

  // 사용량 갱신 및 캐시 저장 (TTL 10분)
  userDailyTokens.set(user, currentTokens + estimatedTokens);
  responseCache.set(promptHash, {
    response: simulatedResponse,
    expiresAt: Date.now() + 10 * 60 * 1000,
  });

  return reply.send({
    id: `live-${Date.now()}`,
    cached: false,
    result: simulatedResponse,
    tokensUsed: estimatedTokens,
  });
});

async function start() {
  try {
    await server.listen({ port: 3000, host: '0.0.0.0' });
    console.log('LLM Gateway가 3000번 포트에서 실행 중입니다.');
  } catch (err) {
    server.log.error(err);
    process.exit(1);
  }
}

start();

이 구현처럼 호출 관문을 통일해 두면, Cloudflare가 데이터베이스 상태를 확인해 최소 작업만 실행했던 것처럼 게이트웨이 계층에서 해시 기반 캐싱이나 의미론적 유사도 검사를 통해 업스트림 모델 호출을 선제적으로 차단할 수 있습니다. 각 개발 조직이 독자적으로 엔드포인트를 호출하는 환경에서는 이런 계층적 방어선을 구축하기 어렵습니다.

인프라와 AI 파이프라인의 공통 분모: 결정론적 통제

여기서 한 걸음 물러서서 두 엔지니어링 사례의 본질을 짚어볼 필요가 있습니다.

하나는 확률적으로 텍스트를 생성하는 LLM을 기업 시스템에 안착시키는 과정이고, 다른 하나는 인터넷 트래픽의 밑단을 지탱하는 결정론적 DNS 레코드 엔진의 최적화입니다. 겉보기에는 상반된 성격이지만, 인프라 운영자가 내린 해결책은 정확히 일치합니다.

1. 상태 기반의 선별적 실행: 들어오는 요청을 있는 그대로 전부 처리하지 않습니다. DNS 플래너가 데이터베이스 상태를 대조해 변경 안전성이 입증된 레코드만 골라내듯, AI 게이트웨이는 요청자의 인가 상태와 캐시 상태를 대조해 실제 토큰 연산이 필요한 요청만 백엔드로 보냅니다.
2. 단일 실패점(SPOF) 방지와 개별 추적의 분리: Cloudflare가 Kafka 메시지를 병합하면서도 개별 완료 추적을 유지해 유실을 막았듯, LLM 게이트웨이 역시 중앙에서 정책을 일괄 적용하되 사용자별·팀별 사용량과 에러 추적은 독립된 단위로 유지해야 장애 발생 시 영향도를 국소화할 수 있습니다.

AI 시장의 둔화 조짐은 기술의 퇴보가 아니라, 효율성에 대한 엄격한 검증 단계로의 진입을 의미합니다. 무조건적인 확장과 전면 재빌드의 시대는 끝났습니다. 변경점만 골라내어 처리하고, 모든 외부 지출과 연산을 통제된 단일 지점에서 감시하는 아키텍처가 시스템의 지속 가능성을 결정합니다.

도입 전 확인할 것

중앙화된 게이트웨이나 상태 기반 작업 분할 플래너를 프로젝트에 도입하기 전, 다음 항목들을 검토해야 합니다.

1. 지연 시간(Latency) 허용 폭 점검: 중앙 게이트웨이나 스케줄러 플래너가 추가되면 네트워크 홉(Hop)과 상태 검증 연산으로 인해 수 밀리초에서 수십 밀리초의 지연 시간이 추가됩니다. 내부 DNS나 초저지연 API 통신에서 이 오버헤드가 비즈니스 요구사항에 부합하는지 측정해야 합니다.
2. 모호한 변경에 대한 안전 실패(Fail-safe) 정책 정의: Cloudflare가 변경 내용을 명확히 알 수 없을 때 전체 빌드로 폴백(Fallback)했던 것처럼, 게이트웨이나 플래너가 정책 검증에 실패했을 때의 동작 원칙(차단할 것인가, 기본 모델로 우회할 것인가)을 사전에 정의해야 합니다.
3. 단일 관문의 고가용성 확보: 모든 호출이 한곳으로 모이면 게이트웨이 자체가 시스템 전체를 마비시키는 병목이자 단일 실패 지점이 됩니다. 무중단 배포 전략과 다중화 인프라 구성이 사전에 갖춰져 있는지 확인해야 합니다.

그 밖의 소식

PHP 요청 수명주기 취약점 패치: PHP 보안 공지를 읽었다 — index.php가 실행되기 전에도 RCE가 가능했다
BYD의 월간 전기차 판매 최고 기록 경신: BYD, 지난달 미국의 한 분기 전체보다 많은 전기차 판매
컨테이너와 가상머신 격리 기술의 결합: 컨테이너처럼 쓰고, VM처럼 격리하기: kata-containers with GPU