토스증권의 Nasdaq Smart Options 실시간 제공 사례

들어가며

Viva Republica의 모바일 금융 플랫폼 ‘토스’는 2015년 간편송금 서비스를 시작으로 누구에게나 평등한 금융을 선보이고 있습니다. 토스는 소비자의 관점에서 더 좋은 가치를 담은 서비스를 제공하겠다는 신념 아래 은행, 증권, 결제, 통신 등 다양한 영역에서 서비스를 선보이며 성장해 왔습니다. 그 결과 2024년 기준 월간 활성 이용자(MAU) 수 2,480만 명을 돌파하며 대한민국 대표 핀테크 플랫폼으로 자리매김했습니다. 2025년 현재 100여 종 이상의 서비스를 토스 앱에서 만날 수 있습니다.

토스증권은 기술 기반의 투자 플랫폼으로, ‘투자의 힘을 모두에게’라는 슬로건 아래 개인투자자들을 위한 투자의 새로운 표준을 만들어가고 있습니다.
2021년 3월 MTS(Mobile Trading System)를 출시하며 대고객 서비스를 시작한 토스증권은 쉽고 직관적인 사용자 인터페이스(UI)와 사용자 경험(UX)를 강점으로 빠르게 성장하고 있습니다.
이제는 모바일을 넘어 PC기반의 WTS(Web Trading System)로 채널을 확대하고, 국내 및 해외주식에 이어 해외채권까지 투자 상품을 다각화하며 전국민 투자 플랫폼으로 거듭나기 위해 서비스를 지속적으로 확장해나가고 있습니다.

최근 국내 투자자들 사이에서 SOXL, TSLL 등 레버리지 ETF와 같이 소액을 투자하여 큰 수익을 얻을 수 있는 상품에 대한 수요가 뚜렷해지고 있습니다. 토스증권은 이러한 사용자들의 수요에 응답하고자 새로운 자산군인 미국 옵션(US Options) 출시하려 합니다. 아직까지 국내에서는 CME 선물에 비해 미국 옵션에 대한 인지가 낮은 편이지만, 토스증권은 이를 새로운 기회로 보고 시장의 변화를 주도하고자 합니다.
이번 게시물은 토스증권이 Nasdaq의 Smart Options 서비스를 통해 어떻게 미국 시세 데이터를 사용자에게 제공하는지 소개할 것입니다. 특히 실시간 데이터 전송이 중요한 주식 시세 데이터를, 미국에 데이터센터 혹은 인프라 없이도 자유롭게 국가(미국, 한국) 간 데이터를 전송할 수 있었는지 말씀드리려 합니다.

공통 – 용어정리

이번 블로그는 증권 서비스 최적화 사례인 만큼, 익숙하지 않은 용어들을 사용하고 있습니다. 먼저 일부 용어들에 대해 간략히 소개하겠습니다.
투자자: 토스증권을 통해 주식투자를 수행하는 애플리케이션 이용자를 의미합니다.
Market Data Vendor (이하 Data Vendor): 이번 블로그에서는 해외주식 데이터를 국내에 제공하기 위해 데이터를 제공하는 업체를 의미합니다.
시세정보(Market Data): 주식, 옵션 등 금융상품이 시장에서 거래되는 체결 가격 정보, 매수/매도 호가정보, 거래량 정보 등 전반적인 거래 관련 정보를 의미합니다. 이 중 호가와 체결 정보는 가장 기본적이고 실시간성이 높은 데이터입니다.
호가: 투자자들의 매수 및 매도 주문이 제출된 현황을 실시간으로 보여주며, 일반적으로 가격별로 몇 개의 주문(수량)이 대기하고 있는지 단계별로 제공합니다. 매수호가와 매도호가로 구분됩니다.
체결: 매수자와 매도자 간에 거래가 성사되어 실시간으로 형성되는 가격정보를 의미합니다. 호가가 주문 의향을 나타낸다면, 체결가격은 실제로 거래가 이루어진 가격입니다. 일반적으로 거래시각, 체결가격, 체결수량 등을 제공합니다.

Nasdaq Smart Options

일반적으로 국내 주식 서비스가 미국 증권거래소의 데이터를 가져오는 방법은, Data Vendor를 통해 사용료를 지불하고 데이터를 제공받게 됩니다. 이는 원천 데이터에 대한 계약 이외에도 현지 데이터센터 확보, 국가간 데이터 전송 인프라 부재 등의 문제로 국내 증시 서비스 업체가 이를 수행하기 어려운 환경이었습니다.
이는 Data Vendor 업체의 장애가 고스란히 사용자의 불편으로 전이되는 환경이지만, 이를 해결하기 위한 방법은 여러 Data Vendor와의 계약을 통해 시세 데이터를 전송하는 형태로 다중화 하는 전략 뿐이었습니다.
이러한 어려움을 해결하기 위해, 토스증권은 Data Vendor로부터 가공된 데이터를 받는 기존의 방식 대신 직접 Nasdaq의 Smart Options(http://www.nasdaq.com/solutions/data/options/smart-options) 상품을 활용하여 국내의 미국 증시 시장 이용 투자자에게 안정된 사용경험을 제공할 수 있도록 데이터 파이프라인을 구축하고자 하였습니다. 하지만 Smart Options을 바로 한국의 데이터 센터에 연결하여 테스트를 수행해보니, 몇 가지 문제가 발생했습니다.
첫 번째는 미국과 한국의 물리적 거리에서 기인하였습니다. Nasdaq에서 제공한 Endpoint를 바로 데이터센터로 연결하니 Public Internet을 사용하게 되며 패킷 손실, 네트워크 경로 최적화 문제 등 통신 자체에 문제가 발생하였습니다. 동시에 물리적 거리로 인해 발생되는 높은 RTT(Round Trip Time)는 높은 Latency를 야기하였고, 이렇게 높은 RTT는 단순한 응답지연을 넘어 지속적으로 Lag이 증가하는 문제를 야기했습니다.

[그림1. 한국으로 바로 연결 시 발생하는 Kafka Consuming Lag]

Kafka는 Pull 방식으로 메시지를 비워내는데(참고: http://kafka.apache.org/documentation/#design_pull), 한국에 위치한 Consumer가 미국의 Message Queue를 비워내다보니 Queue에 대한 소비가 즉각적으로 이루지지 못하며 Lag이 누적되게 된 것입니다.
두 번째 문제는 시스템 자원 예측의 어려움입니다. 증권 시장은 그 특성상 장 시작 및 마감, 특정 뉴스로 인한 주문량의 증감으로 인해 데이터 처리와 전송에 대한 일관성을 확보하기 어려웠습니다. 또한 실제 데이터를 처리해보니 Kafka의 각 Topic들의 분포도가 고르지 않아 각 Partition의 초당 요청량을 예측하는 것도 힘들었습니다.

[그림2. 토픽 별 데이터 발생량 TPS 현황]

그래프에서 확인할 수 있듯이, 데이터 발생량의 편차가 가장 큰 두 토픽은 100987.2 TPS 과 4652.6 TPS로 20배 이상 차이가 납니다. 이러한 격차는 데이터 처리에 필요한 자원의 예측을 힘들게 하며, 서비스 품질을 떨어뜨리는 원인이 됩니다.

AWS Global Infrastructure를 통한 아키텍처

토스증권은 현재 AWS 이외에도 다양한 데이터센터를 통해 많은 사용자들의 시세 요청을 처리하고 있습니다. 한국 주식, 미국 주식 외에도 미국 채권 및 미국 옵션 데이터를 실시간으로 수집하고 있습니다.
수 많은 데이터를 실시간으로 처리하기 위해 속도 및 안정성 확보가 필요하였고, 이를 위해 다양한 기술 스택을 고려하여 Application / Database / Message Broker 형태의 애플리케이션으로 구성하였습니다.
실시간 시세 데이터는 외부로부터 전송된 체결, 호가 등의 데이터를 수신하고 이를 가공 및 저장, 분배하는 다수의 Data Processor로 전달하게 됩니다. 이렇게 정제된 데이터는 Message Broker 혹은 Storage로 전달되어 Mobile Trading System(이하 MTS)와 같은 Channel Service를 통해 사용자에게 전송되게 됩니다. 현재 토스증권의 시세 서버는 마켓 데이터 수신 서버와 소켓 서버를 분리하여, AWS 환경에서 다음과 같이 별도의 Scaling이 가능한 형태로 구성되어 있습니다.

[그림3. 토스증권의 MTS 서비스 아키텍처]

지난 AWS Seoul Summit 2023에서 이러한 토스의 사례를 발표하기도 하였습니다. 자세한 내용은 Summit 2023에서 발표한 투자를 모두에게, 토스증권의 MTS 구축 사례 를 통해 살펴보실 수 있습니다.

Nasdaq의 Smart Options 서비스가 AWS Infrastructure, 특히 그 중에서 HAQM MSK(HAQM Managed Streaming Kafka, 이하 HAQM MSK)를 통해 제공된다는 점과 토스증권의 높은 클라우드 이해와 경험을 바탕으로 앞서 소개한 전송과정의 문제를 AWS Global Infrastructure를 활용하여 해결하기로 결정하였습니다.
높은 RTT로 인한 Lag 해결과 데이터 처리 자원의 확보를 위해, 토스증권은 Virginia Region(us-east-1)에 HAQM EKS(HAQM Elastic Kubernetes Service, 이하 EKS) Cluster를 구축하고, 이를 통한 데이터 처리 및 전송을 수행하도록 하였습니다. 이를 도식화 하면 아래와 같습니다.

[그림4. Virginia Region에서 Kafka Queue를 소비하는 테스트 아키텍처]

특히 Nasdaq의 Smart Options을 제공하는 Kafka Cluster가 HAQM MSK로 구성되어, 해당 Cluster의 공인 IP로 요청하더라도 AWS가 보유한 자원으로 간주되어 Virginia Region의 Cluster로의 통신은 ‘동일 리전 내 AWS 서비스로의 접근’이 됩니다. 이는 Public Internet을 사용하는 대신 AWS의 네트워크 인프라를 사용한다는 의미가 됩니다. 또한, 초당 요청량(Request Per Second)를 알기 어려운 환경인 만큼 빠르게 시도하고 실패하며 가용 자원의 최적화를 수행할 필요가 있었습니다. 이를 위해 다양한 Consumer EC2들을 Scale-up/out하며 최적의 용량을 산출하였습니다.

[그림5. Virginia Region에서 Kafka Queue를 소비하며 안정화 된 Queue 수신 지연]

이렇게 Nasdaq의 Kafka Cluster를 Virginia Region에서 직접 소비하여 빠르고 안정적으로 데이터를 토스증권의 VPC로 전송하게 되었습니다.
Virginia 리전에서 출발한 데이터는 서울 리전 내 Transit Gateway를 통해 토스증권의 Data Center로 전송됩니다. 이로써 국내 투자자에게 실시간에 준하는 시세 데이터를 전송할 수 있게 되었습니다.

데이터의 특성을 반영한 전송 최적화 알고리즘

전송과 관련된 준비는 끝났지만, 시세 정보를 보다 효율적이고 안정적으로 전송하기 위해 다양한 방안을 접목해야 했습니다.
실제 전송되는 시세 데이터는 앞서 소개한 호가와 체결 데이터로 크게 구분할 수 있으며, 각각의 특징은 다음과 같습니다.

호가 데이터: Nasdaq Smart Options 데이터의 약 95%를 차지합니다. 사용자의 실시간 의사결정에 활용되어 최신성이 중요합니다.
체결 데이터: 투자 판단의 핵심 요소입니다. 체결 데이터는 누락 없이 제공되어야 하며, 시계열 차트 분석이나 특정 가격 도달 시 이벤트 트리거로 활용됩니다.

시장 상황이 급변할 때 데이터 량이 급증하는 호가 및 체결 데이터는 원거리 전송 환경에서 용량에 대한 예측을 어렵게 만듭니다. 전송 용량 초과 시 전체 시세 데이터 지연으로 인해 투자자들이 최신 정보가 아닌 지연된 정보로 투자 결정을 내려야 하는 문제가 발생할 수 있습니다.
이러한 문제의 해결을 위해 다음과 같이 요건을 정리하였습니다.

과거 시장 데이터보다 실시간 정보에 우선순위를 두며, 전송한도를 초과하는 데이터는 전송하지 않습니다.
시간 경계에 데이터 전송이 편향되거나 집중되지 않도록 구성합니다.
시장에서 데이터 발생이 없을 경우 limit을 초과한 데이터라도 다음 전송 시 즉시 제공해야 합니다.

이러한 요구사항을 충족하기 위해, Rate Limit 기법 중 Sliding Window Counter을 기반으로 한 전송률 제어 알고리즘을 적용하여 데이터를 전송하였습니다.
Sliding Window Counter는 연속적으로 이동하는 시간 윈도우를 사용하여 데이터 전송량을 제어하는 알고리즘입니다. 이 알고리즘의 주요 특징은 다음과 같습니다.

연속적 시간 윈도우: 정해진 시간마다 Window를 만들어 전송하는 고정 시간 간격(Fixed Window) 알고리즘이 아닌 Sliding Window를 사용함으로써, 시간 경계에서 발생할 수 있는 데이터 편향을 피하고 일정한 데이터 전송 속도를 유지합니다.
적응적 처리: 이전 시간대에 데이터가 적었다면 현재 시간대에 더 많은 데이터를 전송할 수 있어, 네트워크 자원을 최대한 효율적으로 활용합니다.

Sliding Window Counter는 다음과 같은 형태로 작성됩니다.

class SendTpsManager {
   private val MAX_NBBO_TPS_PER_ONE_OPTION = 3.0
   private val counterMap = ConcurrentHashMap<String, Counter>()


   // 호가 전송 여부 판단
   fun judge(optionKey: String, channelSecond: Int, nanoSecond: Int, sequence: Long, pending: Boolean): JudgeResult {
       val counter = counterMap.getOrPut(optionKey) {
           Counter(0, MAX_NBBO_TPS_PER_ONE_OPTION.toInt(), 0, 0, 0)
       }.copy()
      
       // 오래된 시퀀스는 처리하지 않음
       if (counter.lastSequence >= sequence) return JudgeResult.DROP
      
       // 초가 바뀐 경우 카운터 업데이트
       if (counter.currentSecond < channelSecond) {
           counter.beforeCount = if (channelSecond - 1 == counter.currentSecond)
                                   counter.currentCount
                                 else
                                   MAX_NBBO_TPS_PER_ONE_OPTION.toInt()
           counter.beforeSecond = channelSecond - 1
           counter.currentSecond = channelSecond
           counter.currentCount = 0
       }
      
       // Sliding Window 알고리즘으로 처리량 제한 확인
       if (!pending && !isWithinTpsLimit(counter.beforeCount, counter.currentCount, nanoSecond)) {
           return JudgeResult.PENDING
       }
      
       counter.currentCount++
       counter.lastSequence = sequence
       counterMap[optionKey] = counter
       return JudgeResult.SEND
   }
  
   // Sliding Window Counter 핵심 로직
   private fun isWithinTpsLimit(beforeCount: Int, currentCount: Int, nanoSecond: Int): Boolean {
       val weight = 1 - (nanoSecond / 1_000_000_000.0)
       return (beforeCount * weight) + (currentCount + 1) < MAX_NBBO_TPS_PER_ONE_OPTION
   }
  
   private data class Counter(
       var beforeSecond: Int,   // 이전 초
       var beforeCount: Int,    // 이전 초 카운트
       var currentSecond: Int,  // 현재 초
       var currentCount: Int,   // 현재 초 카운트
       var lastSequence: Long   // 마지막 처리 시퀀스
   )
}

Rate Limit 적용을 통해 초당 데이터 발생 수를 효과적으로 제어할 수 있게 되었습니다. 특히, 시간 경계에서 최대 2배까지 트래픽이 집중될 수 있는 Fixed Window 방식의 문제점을 해결하여 균일한 데이터 전송이 가능해졌습니다.

Nasdaq Option Market에는 2025년 3월 기준으로 약 160만개의 옵션 종목이 존재하며, 데이터가 가장 많이 발생하는 장 초반에는 초당 200만-300만건의 데이터가 발생합니다. Sliding Window Counter 기반 알고리즘을 통해 Rate Limit를 적용하여 한국으로 전송해야 할 최대 초당 데이터건수를 예측하고, 제어할 수 있게 되었습니다.

[그림6. Sliding Window를 적용해 실제 전송되는 데이터를 최적화 한 결과]

최적화 결과, 위의 그래프와 같이 시장 상황이 아무리 급변하더라도 지정한 Limit에 따라 시세 데이터가 전송됩니다. 그 결과 예측할 수 없는 시장 변동 상황에도 초당 데이터 전송량을 통제하여 안정적인 서비스 품질을 유지하고, 네트워크 및 컴퓨팅 자원의 사용량을 예측할 수 있게 됩니다.

구간 별 장애 대비 및 대응 전략

앞서 설명한 리전 간 데이터 전송 Pipeline 구성, 최적화 알고리즘 적용 등을 통해 한국 사용자들에게 제공할 데이터를 안전하게 전송하는데 성공했습니다. 하지만 모든 서비스는 실패 및 장애 상황에 대한 대비와 대응이 필요합니다. 이번에는 구간 별 장애에 대한 대비 및 대응 전략을 알아보도록 하겠습니다.
Virginia 리전은 AWS의 리전 중 가장 큰 리전 중 하나로, 6개의 가용영역에 걸쳐 서비스가 제공됩니다. 한국의 투자자들에게 데이터를 전송함에 있어 가장 중요한 것은 Data Source에 대한 안정성입니다. 토스증권은 가장 먼저 이 부분에 대한 가용성을 확보하기 위해 다양한 가용영역과 EKS의 Multi Cluster를 활용하였습니다.
Kafka 메시지 소비 및 최적화 알고리즘을 수행하는 Kubernetes Cluster를 두 개로 구성하고, 각각은 시세 데이터를 토스증권 DC의 이중화 된 채널로 전송합니다. 각 클러스터는 3개의 가용영역에 걸쳐 구성됩니다.

[그림7. 가용성 확보를 위해 2개의 Cluster를 통해 Nasdaq Smart Options을 소비하는 아키텍처]

전체 Topic은 Data Receiver들에게 분산되어 할당되며, 각 Receiver들은 고정된 Topic을 구독합니다. Data Receiver들은 Virginia Region의 모든 가용영역에 분산해 배포되어 있습니다. 만약 특정 가용영역에 물리적 장애가 발생하는 경우를 대비하여 여러 가용영역에 걸쳐 분산 구성함으로써 데이터의 손실 발생 시 그 원인이 Nasdaq인지 규명하여 백업 Vendor로 전환 여부를 결정지을 수 있게 됩니다.
만약 전체 데이터의 손실이 발생할 경우, Data Source 의 이중화를 통해 문제를 해결합니다. 주 데이터 제공자인 Nasdaq Smart Options의 서비스 중단에 대비하여, 추가 Data Vendor와의 계약을 통해 백업 Data Origin을 확보했습니다. 자동화된 모니터링 시스템을 통해 Nasdaq 데이터의 결측이 감지되면, 즉시 사내 Slack으로 알림이 전송되며 보조 Data Vendor가 자동으로 활성화됩니다. 이러한 이중화 구조를 통해 투자자들에게 중단 없는 시세 정보 제공이 가능해졌습니다.
이를 통해 하나의 가용영역에서 문제가 발생한다고 하더라도, 동일한 Topic을 수신하는 Consumer가 다른 가용영역에 구성되어 있어 투자자들에게는 정상적으로 데이터가 전달됩니다. ICMP를 통해 Virginia – Seoul Region 간 Latency를 매 초 체크하고, 임계점을 넘어가는 오류 상황이 되면 오류 또는 결손으로 판단, 보조 Vendor를 활용할 수 있도록 알림 및 후속 조치를 자동화 해두었습니다.

[그림8. 리전 간 데이터 전송 모니터링 그래프]

마지막으로 데이터센터로 반입되기 전, 보안처리를 위한 점검 작업이 수행됩니다. 이렇게 처리된 데이터는 토스증권 데이터센터로 전송되어 필요한 형태로 가공, 전송되게 됩니다.

[그림9. 실시간 시세 전송을 위한 최종 아키텍처]

최종 시세 데이터 보정

구간 별 발생할 수 있는 문제에 대비하고 대응하더라도 대량의 데이터가 짧은 시간내에 자주 전송되는 만큼 특정 데이터가 누락되거나 지연되는 문제가 발생할 수 있습니다. 특히 시세 데이터의 경우, 실시간으로 발생하는 대량의 데이터로 비정상적 상황에서 속도 또는 정합성 중 하나를 희생해야 합니다. 이 또한 데이터의 특성에 맞는 전략이 필요합니다.
미국 거래소의 통합 최우선 매수/매도호가(NBBO, National Best Bid/Offer)의 경우 최신 데이터, 가장 마지막 상태가 중요합니다. 반면 체결 데이터의 경우 데이터 순서의 정합성이 더 중요하며, 데이터 유실이 잘못된 차트를 만들어낼 수 있다는 특징을 가지고 있습니다. 이러한 특징을 유념하고, 유실 상황에 대한 대응 방안을 설명하겠습니다.
메시지 Queue, 애플리케이션 에러 등을 통해 시세 데이터의 유실이 탐지되었다면, Rewind 혹은 Drop 두 가지 행동 중 한 가지를 선택하여 대응할 수 있습니다. 각각은 다음과 같은 특징을 가지고 있습니다.

Rewind: 순서에 맞는 처리 가능하지만 오래된 시세 데이터를 처리하는 동안 Latest Data 처리가 늦어집니다.
Drop: 데이터의 순서가 유지되지 않고 중간에 들어온 시세는 버려지기 때문에 정상적인 차트 제공이 불가능합니다.

시세 데이터를 제공할 때 가장 중요한 것은 최신 데이터를 투자자에게 제공하는 것입니다. 지연된 시세 데이터로 인해 현재가가 과거 상태에 머무르는 경우 투자자는 잘못된 정보에 기반한 거래를 하게 되며, 주문가/감시가의 도달을 제때 감지하지 못해 주문이 불발되는 등, 투자자의 매매에 직접적인 피해를 끼칩니다. 이에 따라 시세 데이터가 유실되는 경우에도 Drop을 우선 고려해야 하며, 유실된 과거 데이터는 2차적인 복구가 필요합니다. 데이터를 Drop하는 경우에도, NBBO는 가장 최신의 정보를 수신하게 되면 자연적인 복구가 가능합니다.
또한 체결 데이터의 유실이 발생한 경우, 차트의 캔들스틱을 구성하는 시/고/저/종가가 잘못된 정보로 남아있게 됩니다. 속도와 실시간 데이터 전송이 중요한 장 중에는 체결/NBBO정보 전송을 Kafka Producer의 ack=0 설정을 통해 메시지를 전달하여 실시간 데이터 전송이 가능하도록 속도에 중점을 둡니다. 동시에 ack=all 설정으로 체결 데이터를 한번 더 전달하여 유실 없이 Kafka에 영속화 할 수 있도록 데이터 전송을 이중화 합니다. 이렇게 영속화된 데이터를 활용하여 데이터 유실 시 복구를 위한 원천 데이터로 사용될 수 있게 되어, 빠른 데이터 전송과 정합성을 동시에 보장할 수 있게 됩니다.

향후 발전 방향

이렇게 구성된 데이터 파이프라인은 토스증권을 이용하는 투자자 뿐만 아니라, 다양한 증권사에 제공하여 더욱 다양한 투자자들에게 안정적으로 데이터를 제공할 수 있습니다.
특히 Nasdaq의 실시간 Option 시세가 필요한 증권사들이 AWS Seoul Region을 이용한다면, AWS Infrastructure를 사용하기에 보다 안정적이고 빠르게 이 데이터를 사용할 수 있을 것입니다.

[그림10. 전체 아키텍쳐]

한번 구축한 데이터 파이프라인은 다양한 형태로 재사용 될 수도 있습니다. 현재는 OPRA(Options Price Reporting Authority)를 통한 데이터 제공에 주안점을 두고 있지만, 다른 Market의 데이터 또한 유사한 파이프라인을 통해 제공할 수 있습니다.
이렇게 안정적이며 확장 가능한 구조를 가져감으로써, 토스증권 서비스를 이용하는 투자자가 보다 좋은 투자경험을 가질 수 있도록, 그리고 한국의 투자자들이 보다 다양하고 안정적인 투자경험을 가질 수 있도록 하는 토스증권 팀의 목표를 달성할 수 있을 것입니다.

아시아 최초의 나스닥 스마트옵션 시세 서비스는, 실시간 대용량 데이터 처리와 글로벌 환경에서 저지연 아키텍처 구현이라는 복합적인 기술 과제를 해결해야 했습니다. 이를 위해 토스증권 엔지니어들은 고도화된 설계와 끊임없는 개선을 이어갔고, AWS의 클라우드 인프라와 긴밀한 기술 지원을 바탕으로 글로벌 수준의 안정적이고 확장성 높은 서비스를 성공적으로 구축할 수 있었습니다. 이번 토스증권의 기술적 경험 사례가 혁신을 꿈꾸는 모든 조직에게 많은 도움이 되길 바랍니다.

오창훈, 토스증권 CTO

결론

이렇게 토스증권이 어떻게 Nasdaq Smart Options 데이터를 활용하여 투자자들에게 실시간 시세 데이터를 제공할 수 있었는지, 앞으로 어떻게 확장해나가고자 하는지 살펴보았습니다. 토스증권은 앞으로도 투자자들에게 안정적인 시스템과 보다 다양한 시장 데이터의 확장을 통해 모두에게 공평한 투자 환경을 만들 것입니다.

AWS 기술 블로그