AI는 어디에서 생각할까?

GPT·Claude 시대, 글로벌 AI 서비스의 인프라는 어떻게 구성될까
AI INFRASTRUCTURE · 아키텍처 노트
주제: 분산 인프라 · GPU 클러스터 · 라우팅 | 분량: 약 9분
질문을 던지면 몇 초 안에 답이 돌아온다. 화면만 보면 단순하다. 그러나 그 몇 초 안에서는 생각보다 훨씬 복잡한 인프라가 움직인다. 사용자는 서울에 있어도, AI가 계산하는 곳은 서울이 아닐 수 있다.
$$\text{서울 사용자 (여기에서 받는다)} \quad \xrightarrow{\text{signal · low latency}} \quad \text{AI 연산 · 어딘가 (가장 효율적인 곳)}$$
가까운 곳에서 받고, 계산은 가장 효율적인 곳에서 처리한다
앞으로의 글로벌 AI 서비스를 이해하는 핵심 관점은 여기에 있다. 사용자 접점은 넓게 분산하고, 무거운 계산은 전략적인 거점에 집중한다. 이 글에서는 그 구조를 단계별로 따라가 본다.
AI 서비스는 하나의 서버가 아니다
과거의 웹 서비스는 비교적 단순했다. 사용자가 웹 서버에 접속하고, 서버가 데이터베이스를 조회해 응답하면 충분했다.
생성형 AI 서비스는 다르다. 수십억에서 수천억 개 이상의 파라미터를 가진 모델을 서비스하면서 수많은 요청을 동시에 처리하려면 막대한 GPU 자원과 고속 네트워크가 필요하다. 그래서 글로벌 AI 서비스는 하나의 서버가 아니라 여러 계층으로 구성된 거대한 분산 시스템으로 보는 편이 적절하다.
[전통 웹 서비스]
사용자 ---> 웹 서버 ---> 데이터베이스
[생성형 AI 서비스]
사용자(전 세계) ---> Edge · Router ---> GPU 클러스터 ---> Model Runtime
계층형 아키텍처
개념적으로 그리면 다음과 같다. 여기서 가장 중요한 원칙은 사용자와 만나는 Edge와, 실제 계산이 이뤄지는 AI Compute를 분리한다는 것이다.
+-----------------------------------------------------------------------+
| 사용자 |
| 한국 · 일본 · 동남아 · 미국 |
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+ [ EDGE ]
| Global Edge |
| 인증 / 보안 · DDoS / Gateway · 연결 관리 · 실시간 스트리밍 |
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+
| AI Traffic Router |
| Latency · GPU Capacity · Model Availability · Policy |
+-----------------------------------------------------------------------+
|
+-------------------------+-------------------------+
| | |
v v v
+-----------------+ +-----------------+ +-----------------+ [ AI COMPUTE ]
| Asia AI Cluster| | Japan AI Cluster| | USA AI Cluster |
+-----------------+ +-----------------+ +-----------------+
| | |
+-------------------------+-------------------------+
|
v
+-----------------------------------------------------------------------+
| AI Inference |
| GPU · Model Runtime · KV Cache · Scheduler |
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+
| Token Streaming |
+-----------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------+
| 사용자 |
+-----------------------------------------------------------------------+
01 — GATEWAY : 사용자가 만나는 곳, Edge
서울에서 AI 서비스를 이용한다고 해서, 거대한 AI 모델이 반드시 서울에서 실행될 필요는 없다. 사용자가 처음 만나는 서버는 오히려 비교적 가벼운 역할을 맡을 수 있다. 이를 Edge라고 생각하면 이해하기 쉽다.
Edge는 AI의 두뇌라기보다 AI 서비스의 관문에 가깝다. 사용자와 가까운 곳에서 네트워크와 요청을 먼저 처리하고, 무거운 계산은 적절한 AI 컴퓨팅 센터로 넘긴다.
EDGE가 담당하는 일
- 사용자 인증
- TLS 연결 처리
- API Gateway
- Rate Limiting
- DDoS 방어
- 요청 검증
- 정책 적용
- 연결 상태 관리
- 클러스터 라우팅
- 스트리밍 연결 유지
02 — WHY NOT EDGE : 모든 것을 Edge에서 처리하지 않는 이유
"AI 모델도 Edge에서 돌리면 더 빠르지 않을까?"라는 질문이 생긴다. 일부 기능은 실제로 Edge나 사용자 가까운 환경에서 처리할 수 있다. 하지만 초대형 모델은 이야기가 다르다.
대규모 모델을 실행하려면 수많은 GPU와 고속 인터커넥트가 필요하다. 특히 하나의 추론을 여러 GPU가 함께 수행할 때는 GPU 사이의 통신 성능까지 중요해진다. 그래서 모든 지역에 동일한 규모의 초대형 클러스터를 두기보다는, 다음 설계가 더 효율적일 수 있다.
사용자 접점은 넓게 분산하고, 초대형 AI 컴퓨팅 자원은 전략적 거점에 집중한다.
03 — THE CORE : 진짜 중요한 것은 AI Traffic Router
Edge가 요청을 받았다고 해서 무조건 가장 가까운 GPU 센터로 보내는 것은 아니다. 여기서 등장하는 것이 AI Traffic Router다. 서울에서 요청이 들어온 상황을 생각해 보자.
+---> [ 한국 Cluster ] (사용률 95%) - 포화
|
[서울 요청] -> AI Traffic +---> [ 일본 Cluster ] (사용률 45%) - 라우팅 선택!
(via Edge) Router |
+---> [ 미국 Cluster ] (사용률 50%)
가장 가까운 곳은 한국이다. 하지만 한국 클러스터가 이미 포화 상태라면, 일본이나 다른 리전으로 보내는 편이 전체 서비스 품질 측면에서 유리할 수 있다. 즉 AI 라우터는 단순히 거리를 계산하는 시스템이 아니라 여러 신호를 종합해 요청을 배치한다.
ROUTER가 종합하는 신호
- 사용자 위치 / 네트워크 지연시간 / Packet Loss
- GPU 사용률 / Queue Length / 현재 처리량
- 모델 로딩 상태 / 장애 상태
- 지역 정책 / 서비스 우선순위
결국 핵심 질문은 *"가장 가까운 GPU가 어디인가?"*가 아니라, "지금 이 요청을 가장 효율적으로 처리할 수 있는 곳은 어디인가?"가 된다.
04 — COMPUTE HUB : 그 뒤에는 초대형 AI Compute Hub가 있다
가장 무거운 연산은 초대형 컴퓨팅 센터에서 수행된다. 이곳에는 수천 개 이상의 GPU 또는 AI 가속기가 고속 네트워크로 촘촘히 연결된 거대한 클러스터가 자리한다.
$$\begin{matrix} \text{GPU} & \text{---} & \text{GPU} & \text{---} & \text{GPU} \\ \mid & \searrow \swarrow & \mid & \searrow \swarrow & \mid \\ \text{GPU} & \text{---} & \text{GPU} & \text{---} & \text{GPU} \end{matrix}$$
AI Compute Hub — GPU 창고가 아니라 하나의 거대한 컴퓨터
AI 인프라는 단순히 GPU 숫자만 많다고 좋은 것이 아니다. GPU가 서로 얼마나 빠르게 데이터를 주고받는지, 메모리 구조, 네트워크 구성, 스케줄러의 효율이 모두 중요하다. 그래서 초대형 AI 인프는 "GPU 창고"라기보다 하나의 거대한 컴퓨터에 가깝다.
05 — INTERCONNECT : GPU보다 더 중요한 것?
흔히 "GPU 몇 장 있어?"라고 묻는다. 물론 중요한 숫자다. 하지만 대규모 시스템에서는 또 하나의 질문이 필요하다. "그 GPU들이 어떻게 연결되어 있어?"
대규모 모델을 여러 GPU에서 실행하면 GPU 간 데이터 교환이 끊임없이 발생한다. 따라서 초대형 AI 클러스터는 다음 요소가 하나의 시스템처럼 맞물려 움직여야 한다.
$$\text{GPU} \quad + \quad \text{메모리} \quad + \quad \text{고속 인터커넥트} \quad + \quad \text{네트워크} \quad + \quad \text{스케줄러}$$
결국 AI 인프라 경쟁은 단순한 GPU 확보 경쟁에서 끝나지 않는다. GPU를 얼마나 효율적으로 연결하고 사용할 수 있는가가 진짜 문제다.
06 — INFERENCE : AI가 답변을 생성하는 순간
사용자의 질문이 GPU 클러스터에 도착하면 실제 추론이 시작된다. 개념적으로는 다음과 같은 흐름이다.
$$\text{User Prompt (질문 입력)} \rightarrow \text{Scheduler (순서 배분)} \rightarrow \text{Tokenizer (토큰 변환)} \rightarrow \left[ \begin{matrix} \text{Model Runtime} \\ \text{- GPU Compute} \\ \text{- KV Cache} \\ \text{- Batch Sched.} \\ \text{- Token Gen.} \end{matrix} \right] \rightarrow \text{Tokens}$$
특히 LLM에서는 KV Cache와 효율적인 스케줄링이 중요하다. 긴 대화를 이어가거나 수많은 사용자가 동시에 요청을 보내는 상황에서는, GPU 자원을 어떻게 배분하고 어떤 요청을 어떤 순서로 처리할지가 전체 성능을 좌우한다. 그래서 AI 추론 시스템은 단순한 GPU 서버가 아니라, 값비싼 GPU 자원을 최대한 효율적으로 굴리는 거대한 스케줄링 시스템으로 보는 편이 낫다.
07 — STREAMING : 답변은 왜 한 글자씩 나타날까?
ChatGPT나 Claude를 쓰다 보면, 답변이 완성된 뒤 한꺼번에 나타나는 것이 아니라 토큰이 생성되는 대로 실시간으로 화면에 흘러나오는 것을 볼 수 있다. 이를 Streaming Response라고 한다.
$$\text{AI Model} \quad \xrightarrow{\quad \text{Token 1, Token 2, Token 3 ... Token N} \quad} \quad \text{사용자}$$
생성되는 즉시 전달 — 그래서 네트워크와 연결 관리도 성능이다
이 때문에 AI 서비스에서는 GPU 성능뿐 아니라 네트워크와 연결 관리도 매우 중요하다. AI가 아무리 빠르게 답을 생성해도, 사용자에게 전달되는 과정이 느리면 체감 성능은 떨어질 수밖에 없다.
08 — DATA PLACEMENT : Edge에는 무엇을 저장할까?
"사용자 데이터를 전부 Edge에 저장하면 되지 않나?" 그렇지는 않다. 개인정보, 보안, 데이터 거주성(residency), 접근 정책을 함께 고려해야 한다. 따라서 Edge에서 다루는 정보와 중앙에서 관리하는 정보를 구분하는 것이 중요하다.
EDGE 계층에서 주로 다루는 정보
- 인증 상태 / 연결 상태
- Rate Limit 상태 / 서비스 정책
- 라우팅 메타데이터 / 정적 콘텐츠
- 일부 비민감 캐시
반면 모델 자체와 대규모 추론 상태, 장기 데이터 저장 등은 별도의 AI Compute·Storage 계층에서 관리한다. 핵심은 "무엇을 어디에 둘 것인가"다.
09 — ROLE SEPARATION : 핵심은 '분산'이 아니라 '역할 분리'
글로벌 AI 인프라는 모든 것을 전 세계에 똑같이 복제하는 구조가 아니다. 오히려 각 역할에 맞는 위치에 자원을 배치한다.
계층 | 역할 |
|---|---|
Global Edge | 사용자 접속 및 네트워크 처리 |
Security Layer | 인증, DDoS, 정책 |
AI Traffic Router | AI 요청 경로 결정 |
Regional AI Cluster | 지역 단위 추론 |
Mega AI Hub | 초대형 AI 연산 |
Model Runtime | 모델 실행 |
Storage | 데이터 및 모델 저장 |
Control Plane | 배포 · 정책 · 자원 관리 |
Observability | 모니터링 · 로그 · 장애 분석 |
이렇게 보면 AI 서비스는 하나의 서버가 아니라, 여러 계층이 유기적으로 연결된 하나의 거대한 시스템이라는 것을 알 수 있다.
10 — REALITY CHECK : GPT와 Claude는 실제로 이렇게 동작할까?
선을 하나 그어 둔다. OpenAI의 GPT나 Anthropic의 Claude가 내부적으로 위와 정확히 동일한 구조를 쓴다고 단정할 수는 없다. 실제 서비스의 네트워크 토폴로지, GPU 배치, 라우팅 알고리즘, 캐시 구조와 장애 대응 방식은 대부분 공개되지 않는다. 따라서 위 구조를 특정 기업의 실제 내부 아키텍처로 보는 것은 적절하지 않다.
대신 이것은 글로벌 생성형 AI 서비스를 설계할 때 생각해 볼 수 있는 대표적인 아키텍처 패턴이다. 대규모 AI 서비스가 공통적으로 풀어야 하는 문제들이 비슷하기 때문이다.
- 수많은 동시 요청과 GPU 자원 효율화
- 낮은 네트워크 지연시간과 모델별 자원 배분
- 장애 발생 시 트래픽 우회
- 보안·인증과 데이터 정책
- 실시간 스트리밍, 모델 배포·버전 관리, 비용 최적화
11 — TWO FACES : 미래의 AI 인프라는 두 개의 얼굴을 갖는다
앞으로 가장 흥미로운 부분은 Edge와 AI Compute의 역할이 더욱 뚜렷하게 분리될 가능성이다. 그리고 그 사이를 초고속 글로벌 네트워크가 연결한다.
Edge — 사용자와 가까운 곳 | AI Compute Hub — 대규모 연산이 가능한 곳 |
|---|---|
• Low Latency | • GPU · AI Accelerator |
• Security · Authentication | • High-Speed Network |
• Gateway · Routing | • Model Runtime · KV Cache |
• Streaming | • Distributed Inference · Training |
$$\text{Global Edge} \rightarrow \text{Intelligent AI Routing} \rightarrow \text{Regional GPU Cluster} \rightarrow \text{Mega AI Compute Hub}$$
사용자는 서울에 있어도, AI가 계산하는 곳은 서울이 아닐 수 있다. 중요한 것은 "어디에 있느냐"가 아니라, 지금 이 요청을 어디에서 가장 빠르고 안정적이며 효율적으로 처리할 수 있느냐다. AI가 똑똑해질수록, 그 AI를 움직이는 ‘길’을 어떻게 설계하느냐가 함께 중요해진다.
$$\text{Edge} \quad \longrightarrow \quad \text{Network} \quad \longrightarrow \quad \text{Router} \quad \longrightarrow \quad \text{GPU Cluster} \quad \longrightarrow \quad \text{Model Runtime} \quad \longrightarrow \quad \text{Streaming}$$