AI가 제안하고 사람이 결정합니다: AI LB의 승인 게이트로 본 Multi-CDN 운영 자동화

Multi-CDN 운영의 세 장면

Multi-CDN을 운영해 본 팀이라면 익숙할 장면들이 있습니다. AI LB 소개 페이지가 그리는 세 장면도 정확히 이것입니다.

• "트래픽 비율 5%만 바꾸려고 콘솔 3개를 열어야 합니다." 벤더별 콘솔이 따로, UI도 다르고, 변경 이력은 흩어져 있습니다. 같은 작업을 반복할수록 휴먼 에러가 쌓입니다.

• "새벽에 CDN 장애가 나면 그 시간이 매출입니다." 알림 수신, 원인 파악, DNS 수동 변경, 전파 대기. 그 사이 서비스는 멈춰 있습니다.

• "가중치 하나 바꾸려고 엔지니어 일정을 또 잡습니다." DNS 레코드는 전문 영역이라 마케팅·운영팀이 직접 만질 수 없고, 작은 변경마다 요청과 대기가 하루를 채웁니다.

공통점은 하나입니다. 트래픽을 어디로 보낼지 결정하는 일이 너무 여러 곳에, 너무 수동으로 흩어져 있다는 것. 자동화가 답인 것은 분명한데, 문제는 자동화의 방식입니다.

자율 자동화가 아니라 승인 게이트

라우팅 자동화 이야기가 나오면 반드시 따라오는 질문이 있습니다. "LLM이 잘못된 라우팅 규칙을 만들면 어떻게 되나요?" AI LB의 설계 원칙이 이 질문에 대한 답입니다. 공식 소개 문구 그대로, "AI가 제안하고, 사람이 결정합니다." 자율 자동화가 아니라, 모든 라우팅 변경이 4단계를 거치며 그중 절반은 사람이 직접 결정하는 구조입니다.

• ① Describe (AI 영역): 원하는 라우팅 정책을 LLM과 한국어로 주고받으며 구성합니다. "한국은 Speedy 70%, 일본은 Failover" 같은 의도에서 시작해 세부 조건까지 대화로 좁혀 갑니다.

• ② Preview (AI 영역): LLM이 Route53 레코드 plan을 생성합니다. 어떤 레코드가 만들어지고 어떤 가중치가 적용되는지 표 형태로 미리 확인합니다.

• ③ Approve (사람 영역): plan을 검토하고 승인 버튼을 누릅니다. 의심스러우면 취소하고, 수정하고 싶으면 한국어로 추가 지시합니다.

• ④ Apply / Revert (사람 영역): 승인 시 Route53에 즉시 반영됩니다. 변경 이력이 보존되어 이전 정책으로 복원할 수 있습니다.

핵심은 LLM의 역할 범위입니다. LLM은 plan을 생성하는 데까지만 관여하고, 실제 반영은 운영자의 검토·승인 뒤에만 일어납니다. 잘못된 제안은 승인 단계에서 걸러지고, 승인 후 문제가 보이면 이력에서 복원하면 됩니다. 무중단 배포 글에서 다뤘던 원칙, 이전 상태를 살려 두고 되돌릴 길을 확보한다는 접근이 라우팅 운영에도 그대로 적용된 셈입니다.

운영을 하나로 묶는 조각들

승인 게이트가 뼈대라면, 흩어진 운영을 한곳으로 모으는 조각들이 살입니다. 먼저 통합 Purge. 대규모 콘텐츠 갱신 때 벤더별 Purge API를 따로 호출할 필요 없이, "API 한 번 호출로, 연동된 CDN의 캐시가 동시에 비워집니다." 요청은 202 응답으로 비동기 접수되고, 도메인 전체(all)와 URL 단위(item) 두 범위를 지원하며, 그룹 ID로 벤더별 처리 상태를 조회할 수 있습니다.

연동 범위도 실무 기준입니다. 현재 9종의 CDN이 연동되어 있습니다. 국내는 Speedy(S-CDN)·효성ITX·Solbox KT·Solbox LG, 글로벌은 Akamai·CDNetworks·AWS CloudFront·Fastly, 중화권은 Tencent EdgeOne. API를 제공하는 CDN이라면 협의를 통해 추가할 수 있습니다. 중요한 전제는 이것입니다. "기존 CDN 계약은 그대로 유지하세요." AI LB는 그 위에서 트래픽 분배·전환·통계만 통합하는 컨트롤 플레인이고, 사용을 중단하면 트래픽은 단일 CDN으로 정상 복귀합니다. 종속이 아니라 통합입니다.

트래픽을 실제로 나누는 방식, 즉 가중치·장애조치·지리·스케줄링·LLM의 라우팅 정책 5가지는 멀티 CDN 라우팅 정책 5가지 비교 글에서 따로 다뤘으므로, 이 글에서는 반복하지 않습니다.

신뢰 설계: Access Key를 받지 않습니다

DNS 컨트롤 플레인을 외부 서비스에 맡길 때 마지막 관문은 보안입니다. AWS 계정 위임이 부담스럽다는 우려에 대한 AI LB의 답은 접근 범위의 공개입니다. "Access Key는 일절 받지 않습니다." AWS Assume Role 방식의 STS 임시 보안 토큰만 사용하고, 지정된 Route53 호스팅 존에 대한 최소 권한만 부여받습니다.

보는 영역과 보지 않는 영역이 명시되어 있습니다. 보는 것은 지정된 호스팅 존의 레코드, 요청 통계용 Query Log, 등록된 CDN 계정 정보, 라우팅 변경 이력입니다. 보지 않는 것은 EC2·S3·RDS 같은 다른 AWS 리소스 일체, 루트 계정·IAM 사용자 정보, Access Key와 Secret Key, 지정 외 Route53 자원입니다. 시크릿 관리에서 강조되는 원칙, 최소 권한과 임시 크리덴셜이 제품 설계에 그대로 들어가 있는 형태입니다. 한 가지 전제도 명확히 해 둡니다. AI LB는 현재 AWS Route53 기반으로만 동작하며, 다른 DNS 서비스 연동은 협의 가능합니다.

도입은 4영업일, 검증은 30일

도입 절차도 승인 게이트와 같은 철학입니다. 통째로 맡기라고 하지 않고, 검증부터 시작합니다. 컨설팅 3영업일 동안 현재 CDN 구성을 분석하고 Multi-CDN 아키텍처 설계를 제안하며, PoC 범위를 합의합니다(도입 의무 없음). 셋업 1영업일에 CloudFormation 스택 1회 실행으로 AWS를 연동하고 CDN API 계정과 CNAME을 등록합니다. 그다음 실제 트래픽 일부로 30일 PoC를 운영합니다. PoC 라이선스 비용은 무료입니다. 정식 도입 가격은 CDN 벤더 수·SLA 등급·월 트래픽 규모 세 변수로 산정되고, 기존 CDN 벤더 직계약과 분리 청구되어 계약 종속이 생기지 않습니다(PoC 진행 시 견적은 28일차에 자동 발송). 다만 트래픽 규모가 작은 환경에서는 PoC로 적합도부터 확인하기를 권합니다. 정확한 진입 기준은 컨설팅 단계에서 확정합니다.

스피디는 AI LB를 한국 CDN 운영 노하우를 기반으로 자체 개발했고, 도입 후에도 엔지니어가 기술 지원과 고객 케어로 함께합니다. Multi-CDN 운영의 승인 권한은 그대로 두고, 반복 작업과 새벽의 수동 전환만 덜어내는 것. 그것이 AI LB가 자동화를 설계한 방식입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)