---
title: "Cortex 내부: 응답 속도 50ms 이하, 가동률 99.995%를 구현하는 엔지니어링"
description: "안정적인 블록체인 연결성은 타협할 수 없는 요소입니다. Cortex는 베어메탈 하드웨어부터 AI가 관리하는 노드 플릿까지, 목적에 맞게 설계된 아키텍처를 통해 대규모 환경에서도 응답 속도 50ms 이하, 가동률 99.995%를 달성합니다."
---

# Cortex 내부: 응답 속도 50ms 이하, 가동률 99.995%를 구현하는 엔지니어링

<ImageBlock
  src="https://media.alchemy.com/blog/inside-cortex-engineering-blockchain-infrastructure-2026-03-10.jpg"
  alt="50ms 이하 블록체인 인프라를 위한 Cortex 엔지니어링 히어로 배너"
  width={1260}
  height={630}
  priority
/>

안정적인 블록체인 연결성은 타협할 수 없는 요소입니다. [Cortex](https://www.alchemy.com/cortex)는 Alchemy 플랫폼을 구동하는 지능형 블록체인 엔진으로, [RPC API](https://www.alchemy.com/docs/reference/node-api-overview), [데이터 API](https://www.alchemy.com/docs/reference/data-overview), [rollup](https://www.alchemy.com/docs/reference/rollups-quickstart), 그리고 개발자 플랫폼 나머지를 지탱하는 인프라를 담당합니다.

Cortex는 근본 원리부터 설계되었으며, 수조 건의 요청과 7년 이상의 데이터를 학습했습니다. 목표는 단 하나, 어떤 규모에서도 안정적으로 동작하는 인프라를 제공하는 것입니다.

그 결과 평균 응답 시간 50ms 미만, 99.995%의 가동 시간, 그리고 마이그레이션이나 새로운 툴링, 설정 변경 없이도 수천만 사용자까지 확장 가능한 처리량을 달성했습니다.

공급자 간 비교를 위한 공개 데이터는 지연 시간, 성공률, 실패한 요청에 대한 Alchemy의 [RPC 성능 벤치마크](https://www.alchemy.com/benchmarks)를 참고하세요.

이 글에서는 Cortex를 뒷받침하는 엔지니어링 결정을 자세히 살펴봅니다. 지연 시간, 처리량, 안정성 전반에 걸친 시스템 수준의 작업이 이 수치를 가능하게 합니다.

## Cortex는 지연 시간을 어떻게 줄이는가?

### Kubernetes affinity를 통한 Pod colocation

앱이 요청을 보내면, 그 요청은 응답을 받기까지 여러 내부 서비스를 거쳐 이동합니다. 한 서버에서 다른 서버로 이동할 때마다 지연 시간 비용이 발생합니다.

Pod colocation은 가장 자주 통신하는 서비스들을 같은 물리 머신에 배치하는 것을 의미합니다. Kubernetes는 이를 가능하게 하는 affinity 규칙을 지원하며, 이를 통해 지연 시간에 민감한 워크로드가 여러 머신이나 랙에 분산되지 않고 함께 실행됩니다.

결과적으로 요청이 로컬에 머물게 되어 네트워크 홉이 줄고 응답 시간이 단축됩니다.

### Istio locality-aware routing

단일 데이터센터 내에서도 서비스는 여러 노드와 랙에 분산되어 있습니다. Istio는 내부 서비스 간 통신 방식을 관리하는 네트워킹 레이어입니다.

Locality-aware routing을 사용하면 Istio는 각 서비스 인스턴스의 물리적 위치를 파악하고, 가능한 경우 가장 가까운 인스턴스로 트래픽을 라우팅합니다. 요청을 처리하는 서비스가 같은 노드에서 실행 중이라면, 트래픽은 더 먼 인스턴스로 네트워크를 건너지 않고 그 자리에 머뭅니다.

이는 애플리케이션 코드 변경 없이 불필요한 네트워크 홉을 줄여줍니다.

### 마이크로커널 프록시 아키텍처

인프라가 복잡해질수록 긴밀하게 결합된 시스템은 안전하게 변경하기 어려워집니다. 하나의 컴포넌트를 업데이트하면 나머지 스택 전반에 위험이 발생할 수 있습니다.

마이크로커널 방식은 핵심 부분을 작고 안정적으로 유지하며, 크리티컬 패스만 담당하게 합니다. 로깅, 속도 제한, 인증, 라우팅 로직 등 나머지 기능은 그 위에 레이어로 쌓이는 모듈형 컴포넌트로 구현됩니다.

우리의 프록시 레이어는 들어오는 요청과 백엔드 시스템 사이에 위치합니다. 마이크로커널 모델 위에 구축되어 있기 때문에, 핵심 요청 경로를 건드리지 않고도 개별 모듈을 독립적으로 업데이트하고 배포할 수 있습니다. 이를 통해 회귀(regression) 위험을 줄이면서도 빠르게 반복 개선할 수 있습니다.

### Direct-to-datacenter routing

엔터프라이즈 워크로드의 경우, 공용 인터넷을 통한 트래픽 라우팅은 일관되지 않은 지연 시간, 패킷 손실, 그리고 통제할 수 없는 조건에 따라 변하는 혼잡한 경로 등 변동성을 야기합니다.

Direct-to-datacenter routing은 엔터프라이즈 트래픽을 우리 인프라에 직접 연결되는 사설 최적화 네트워크 경로로 전송해 이 문제를 피합니다. 이를 통해 공용 라우팅 공유에 따른 예측 불가능성을 제거하고, 모든 홉에서 더 일관된 저지연 성능을 제공합니다.

## Cortex는 어떻게 확장되는가?

### 전 세계에 배포된 수천 대의 베어메탈 서버

대부분의 클라우드 인프라는 가상 머신 위에서 실행됩니다. 가상화는 유연하지만, CPU, 메모리 대역폭, I/O가 동일 호스트 상의 다른 워크로드와 공유되기 때문에 오버헤드가 발생합니다.

베어메탈은 하이퍼바이저 없이 물리 하드웨어에서 직접 실행하는 것을 의미합니다. 모든 리소스가 요청 처리에 전용으로 할당됩니다. 이를 통해 공유 환경에서 발생하는 성능 변동성을 제거하고, Cortex는 대규모 부하 상황에서도 일관된 처리량을 유지합니다.

### Java virtual threads

대량의 동시 요청을 처리하면 서버의 스레딩 모델에 부담이 가해집니다. 전통적인 OS 레벨 스레드는 메모리 사용량이 많고, 동시성이 높아질수록 컨텍스트 스위칭 관리 비용도 증가합니다.

Java 21에서 도입된 Java Virtual Threads는 운영체제가 아닌 JVM이 관리하는 경량 스레드입니다. 생성 및 전환 비용이 전통적인 스레드보다 훨씬 낮아, 단일 머신이 처리량을 제한하는 메모리 및 CPU 오버헤드 없이 훨씬 많은 동시 작업을 처리할 수 있습니다.

실제로는 기존 하드웨어를 더 효율적으로 사용하고, 성능 저하 없이 트래픽 급증을 흡수할 여유를 더 확보할 수 있다는 의미입니다.

### 예측적 스케일링 로직

일반적인 오토스케일링은 CPU 사용률 같은 임계값을 관찰하다가 해당 임계값을 초과한 후에 용량을 추가합니다. 이는 본질적으로 반응형 방식으로, 수요가 먼저 증가하고 인프라가 나중에 따라잡는 구조입니다.

우리의 스케일링 로직은 CPU, 메모리, 디스크 I/O, 트래픽 패턴 등 여러 신호를 동시에 모니터링하고, 과거 데이터를 사용해 급증이 발생하기 전에 이를 예측합니다. 수요가 발생한 후가 아니라 그 전에 용량이 프로비저닝되므로, 트래픽 증가와 이를 흡수하는 인프라의 능력 사이의 격차가 줄어듭니다.

### AI 기반 노드 플릿 관리

우리의 노드 플릿은 업그레이드, 테스트, 모니터링을 처리하는 완전 자동화된 에이전트 시스템에 의해 관리됩니다. 업데이트는 실시간으로 감지되어 적용되며, 파이프라인에는 자동화된 테스트가 내장되어 있어 필수 네트워크 업그레이드와 하드포크를 놓치는 일이 없습니다.

이는 가동 시간을 개선하고, 중요한 체인 이벤트가 발생했을 때 사람의 대응 지연으로 인한 위험을 제거합니다.

## 이 시스템들이 결합해서 작동하는 이유

이는 개별적인 최적화가 아닙니다. Pod colocation은 지연 시간을 줄입니다. Locality-aware routing은 이를 더 줄입니다. 마이크로커널 아키텍처는 불안정성을 도입하지 않고도 두 가지를 모두 개선할 수 있게 합니다. 베어메탈 하드웨어는 Java Virtual Threads가 효율적으로 동작하는 데 필요한 자원을 제공합니다. 예측적 스케일링은 필요하기 전에 용량이 확보되도록 보장합니다.

각 레이어는 그 위의 레이어를 더 빠르고 더 견고하게 만들도록 설계되었습니다. 근본 원리부터 인프라를 다시 설계한다는 것은 바로 이런 의미이며, Cortex는 그 위에 구축되어 있습니다.

이 모든 것은 내부에서 실행됩니다. 여러분 쪽에서는 마이그레이션도, 새로운 툴링도, 설정 변경도 필요하지 않습니다. 저희가 인프라를 계속 발전시키는 동안, 여러분은 제품 개발에 계속 집중할 수 있습니다.

지금 [빌드를 시작하세요](https://dashboard.alchemy.com/). 맞춤 가격, 통합 관련 질문 등은 [영업팀에 문의하세요](https://www.alchemy.com/contact-sales).

## 자주 묻는 질문

### Alchemy Cortex란 무엇인가요?

Cortex는 RPC API, 데이터 API, rollup, 인프라를 포함한 Alchemy 개발자 플랫폼을 구동하는 지능형 블록체인 엔진입니다. 근본 원리부터 설계되었으며, 수조 건의 요청과 7년 이상의 데이터를 학습해 50ms 미만의 응답 시간, 99.995%의 가동 시간, 그리고 마이그레이션이나 설정 변경 없이 확장 가능한 처리량을 제공합니다.

### Cortex는 어떻게 50ms 미만의 응답 시간을 달성하나요?

Cortex는 Kubernetes affinity를 이용한 pod colocation으로 자주 통신하는 서비스를 같은 물리 머신에 배치하고, Istio locality-aware routing으로 가장 가까운 서비스 인스턴스로 트래픽을 유도하며, 안정적인 코어 성능을 위한 마이크로커널 프록시 아키텍처, 그리고 사설 네트워크를 통한 엔터프라이즈 트래픽용 direct-to-datacenter routing을 사용합니다.

### Cortex의 마이크로커널 프록시 아키텍처란 무엇인가요?

마이크로커널 접근 방식은 핵심 요청 처리 시스템을 작고 안정적으로 유지하는 한편, 로깅, 속도 제한, 인증, 라우팅 로직은 모듈형 컴포넌트로 구현되어 크리티컬 패스를 건드리거나 스택 전반에 위험을 초래하지 않고 독립적으로 업데이트할 수 있습니다.

### Cortex는 스케일링을 어떻게 다르게 처리하나요?

Cortex는 CPU, 메모리, 디스크 I/O, 트래픽 패턴을 포함한 여러 신호를 모니터링하는 예측적 스케일링 로직을 사용하며, 과거 데이터를 활용해 임계값 초과 후 반응하는 대신 수요 급증 이전에 용량을 프로비저닝합니다.

### Cortex는 왜 가상 머신 대신 베어메탈 서버를 사용하나요?

베어메탈 서버는 하이퍼바이저 없이 물리 하드웨어에서 직접 실행되어 모든 리소스를 요청 처리에 전용으로 할당하며, 공유 가상화 환경에서 발생하는 성능 변동성과 오버헤드를 제거해 대규모 부하 상황에서도 일관된 처리량을 제공합니다.

### Java Virtual Threads란 무엇이며 Cortex는 왜 이를 사용하나요?

Java Virtual Threads는 운영체제가 아닌 JVM이 관리하는 경량 스레드로, 전통적인 스레드보다 생성 및 컨텍스트 전환 비용이 훨씬 낮습니다. 이를 통해 단일 머신이 처리량을 제한하는 일반적인 메모리 및 CPU 오버헤드 없이 더 많은 동시 작업을 처리할 수 있습니다.

### Cortex는 블록체인 노드 업그레이드를 어떻게 관리하나요?

Cortex는 업그레이드, 테스트, 모니터링을 실시간으로 처리하는 완전 자동화된 에이전트 시스템을 사용하며, 파이프라인에는 자동화된 테스트가 내장되어 있어 필수 네트워크 업그레이드와 하드포크를 놓치는 일이 없습니다. 이는 가동 시간을 개선하고 사람의 대응 지연 위험을 제거합니다.

### Cortex를 사용하려면 마이그레이션이나 설정이 필요한가요?

마이그레이션, 새로운 툴링, 설정이 전혀 필요하지 않습니다. Cortex는 내부에서 실행되며, 여러분이 계속 제품을 개발하는 동안 자동으로 인프라 개선 효과를 제공합니다.