AI 및 AWS를 활용한 미래 거래 플랫폼 구축

세션 노트

AI 및 AWS를 활용한 미래 거래 플랫폼 구축

(LPL Financial 제공) (Cognizant 후원)

세션 소개

• 차세대 거래 플랫폼 현대화 및 구축
• 자산 관리에서 속도, 규모, 탄력성 및 인텔리전스의 중요성
• 세션 안건 개요 자산관리 산업 개요:
• 자산관리의 정의와 핵심목적
• 업계 규모: 운용 자산 144조 달러, 금융 자문가 300,000명, 고객 6,800만 명
• 세대 간 자산 이전: 100조 달러의 자산이 베이비 붐 세대에서 기술에 익숙한 다음 세대로 이전될 전망입니다.

LPL Financial 소개

• LPL Fortune 500 회사이자 국내 최고의 브로커-딜러로서의 위치
• LPL의 비즈니스 모델 및 현재 거래 플랫폼 독립 브로커-딜러에 대한 설명:
• 금융 자문가가 자신의 사업을 운영하는 동시에 필요한 지원(기술, 운영, 규정 준수 등)을 제공할 수 있도록 허용하는 회사 LPL Financial의 입장:
• 금융 자문가 32,000명
• 운용 자산 2.3조 달러 LPL의 고객 중심 접근 방식:
• 사명: 고객이 모든 단계에서 성공할 수 있도록 돕는 것
• 비전: 최고의 자산 관리 회사가 되려면 LPL의 비전을 달성하기 위한 기술 요구 사항:
• 적응형, 최첨단, 미래 지향적 기술 LPL에서 거래 정의:
• 시장 재정 자문가를 위한 연결 조직 비하인드 트레이딩 프로세스:
• 수백 개의 고성능 시스템이 함께 작동합니다.
• 2,000개 이상의 검사를 밀리초 미만에 실행
• 여러 파트너(시장 센터, 핀테크 조직)에 대한 의존성 거래에 대한 사용자 기대:
• 안전한 거래
• 상시 가동 시스템
• 즉시, 거의 실시간 응답
• 비용 효율적인 거래 비즈니스 목표 달성을 위한 기술 목표:
• 보안사고 제로
• 100% 준수
• 빠른 복구 기능을 갖춘 복원력이 뛰어나고 상시 작동되는 시스템
• 최대 거래량 클라우드 여정을 위해 설계된 거래 시스템:
• 빅뱅 마이그레이션이 아닌 반복적이고 증분적인 프로세스
• 비유: 초고층 빌딩 건설(기초, 코어, 전기, 배관, 자동화)
• 2024까지: 온프레미스 데이터 센터에서 클라우드로 프로세스를 마이그레이션하고 EKS에서 중요한 시스템을 실행하며 AI 및 기계 학습 알고리즘을 채택합니다.
• 2024년 중점 사항: 더 나은 확장성을 위한 플랫폼 자동 확장 및 디커플링
• 향후 계획: 플랫폼 복원력 강화, 다중 가용 영역에서 다중 지역, 다중 가용 영역으로 전환, 온프레미스 종속성 감소

현재 상태 아키텍처

• 온프레미스 데이터센터 및 클라우드 내 다중 가용 영역
• AWS의 온프레미스와 클라우드 현재 상태 아키텍처 구성 요소 간의 핸드셰이크를 위해 설계된 워크플로:
• S3 프레젠테이션 레이어 및 콘텐츠 렌더링용 버킷
• EKS Kubernetes 서버리스 설계 및 자동 확장/자가 치유 아키텍처
• Postgres 관계형 요구 사항 및 높은 트랜잭션 처리량을 위한 SQL
• 문서 데이터베이스의 경우 Dynamo DB(주로 사용 사례 읽기)
• Memory DB: 짧은 대기 시간의 고성능 인메모리 프로세스용
• Kafka 계단식 종속성과 실패를 줄이기 위한 메시지 브로커로 사용 기계 학습 알고리즘을 위한
• SageMaker 및 AI 사용 사례
• 계측 및 엔드투엔드 관찰을 위한 CloudWatch 차세대 아키텍처 목표:
• 계층 1 중요 애플리케이션에 대한 온프레미스 종속성을 제거합니다.
• 엔드투엔드 복원력과 간단한 장애 조치를 위해 클라우드의 모든 기능을 활용하세요.
• 액티브-액티브 다중 리전 환경으로 전환
• 과제: 리전 간 데이터 일관성을 보장하고 액티브-액티브 방식으로 여러 리전의 요청을 조정합니다.
• 잠재적 해결 방법: 기본 다중 지역 지원을 위해 Aurora DB 사용 차세대 아키텍처 채택:
• Gen AI 및 LLM를 핵심 워크플로에 더 효과적으로 통합하기 위해 SageMaker와 함께 Bedrock
• Bedrock을 통한 더 쉬운 학습 곡선

사용 사례: Klein Works Rebalancer

• LPL의 주력 국내 거래 플랫폼
• 모델 기반 거래 원칙 기반
• 자문가는 다양한 투자 요구, 목표 및 위험 프로필을 가진 고객을 위한 포트폴리오를 만듭니다.
• 시장은 항상 변화하고 있어 포트폴리오가 의도한 전략에서 벗어나게 됩니다.
• 모델 기반 거래는 고객 목표를 달성하기 위해 포트폴리오 조정 프로세스를 자동화합니다.
• 모델에서 계정까지의 일대다 관계
• 거래는 개인 계좌가 아닌 모델을 통해 이루어집니다.
• 클라이언트 리밸런서는 수백만 건의 드리프트 검사를 병렬로 수행하고 자동으로 거래를 실행하며 완벽하게 규정을 준수합니다.
• 비유: 클라이언트 리밸런서는 트래픽 패턴을 기반으로 재조정하는 GPS와 같습니다.
• 현재 LPL Financial의 자문가 32,000명 중 14,000명이 사용하고 있습니다.
• 지난 5 년 동안 증분 출시
• 플랫폼에서 7천만 건 이상의 거래 실행
• 매일 100만 건의 드리프트 검사 수행

사용 사례: Klein Works Rebalancer

• 하이퍼스케일링을 위해 AWS 제공
• 플랫폼의 각 거래는 50+ 확인(계정 세부정보, 시장 가격, 라이센스, 규정 준수 규칙 등)을 수행합니다.
• 수백 개의 계좌와 자문가를 통한 수천 건의 거래로 인해 분당 수십만 건의 거래량이 발생합니다.
• 플랫폼 설계:
• 자문가의 재조정 요청이 오케스트레이터에 의해 수신됨
• Orchestrator는 대규모 재조정 요청을 더 작은 미니 배치로 나눕니다.
• 미니 배치는 전달을 보장하는 Kafka로 전송됩니다.
• 재조정 알고리즘은 자동 크기 조정을 위해 설계된 EKS 클러스터에서 실행됩니다.
• 알고리즘은 독립적이며 CPU, 메모리 사용률 및 Kafka 대기열 깊이를 기반으로 확장됩니다.
• 거래 실행 가능 여부를 판단하기 위해 200개 이상의 검사를 수행합니다.
• 프로세스 내 캐싱은 거래 유효성에 대한 즉각적인 밀리초 피드백에 사용됩니다.
• 유효하지 않은 거래는 대기열로 다시 보내지며 추가 병렬화 및 CQRS가 처리되지 않습니다.
• 60+ 코드 마이크로서비스 및 데이터베이스 호출은 종속성 맵으로 그룹화되어 병렬로 실행됩니다.
• Command Query Responsibility Segregation (CQRS) 패러다임이 적용됩니다
• 쓰기는 하나의 서버에 최적화되어 일괄 처리되고 버퍼링되어 데이터베이스 적중을 줄입니다.
• 읽기 볼륨이 더 높으므로 읽기 인스턴스에 맞게 최적화하고 AWS Memory DB를 사용해 인메모리에 캐시합니다.
• 읽기 인스턴스의 적응형 확장:
• 시스템의 읽기 작업이 많기 때문에 읽기 인스턴스에 적응형 조정이 적용됩니다.
• EKS는 자동으로 확장되며 읽기도 자동으로 확장되도록 설계되었습니다.
• CloudWatch를 통한 엔드투엔드 관찰 기능:
• 각 거래에는 완전한 추적성을 위해 ID 상관관계가 할당됩니다.
• CloudWatch는 모니터링 및 로깅에 사용됩니다.
• 시스템은 자가 경고 및 자가 치유를 위해 설계되었습니다.
• 조언자의 행동을 모방하기 위해 합성 거래가 생성됩니다.
• 이러한 트랜잭션은 사용자가 영향을 받기 전에 잠재적인 문제를 감지하기 위해 시스템에서 반복적으로 실행됩니다.
• 시스템은 초당 수천 개의 트랜잭션을 처리하며 LPL에서 최대 볼륨 AI 사용 사례 동안 거의 백만 건의 트랜잭션을 확인했습니다.
• 사람 참여형 접근 방식을 선호하며, 자문가가 AI 제안 결과와 지능형 추천을 통제합니다.
• 사용 사례: 마켓 센터 중단 감지
• 마켓 센터에서는 속도 저하, 문제 또는 중단이 발생하여 운영 문제 및 중복 주문이 발생할 수 있습니다.
• 목표: 마켓 센터 중단을 사전에 감지합니다.
• 실시간 거래 및 실행을 알고리즘에 제공하기 위해 만들어진 워크플로
• 사용된 알고리즘 : 시계열 이상 탐지 알고리즘인 Random
• Cut Forest
• 이상 징후가 감지되면 운영팀에 경고하고 조치를 취합니다.
• 두 번째 사용 사례: ETF 분류
• ETF는 보유 종목이 다르며 메타데이터를 기반으로 카테고리(예: 암호화폐, 원자재, 해외 펀드)로 분류되어야 합니다.
• 규제에 따른 영향에는 라이선스 확인, 규정 준수 규칙 및 자문가 교육이 필요합니다.
• 전통적으로 수동으로 수행되었지만 야간에 실행되는 훈련된 모델을 사용하여 자동화되었습니다.
• 사용된 모델: 인공 신경망(ANN), 정확도가 높은 비지도 모델
• 운영진이 모델의 제안을 검토하고 수용합니다.

AI 모델 아키텍처

• 데이터 저장: 두 사용 사례 모두에 대한 기록 데이터는 RDS Aurora PostgreSQL 데이터베이스에 저장됩니다.
• Lambda 함수: 매일 선별되고 업데이트된 데이터를 선택하여 처리한 후 학습을 위해 S3 버킷에 덤프합니다.
• SageMaker: 모델을 교육하고 호스트합니다. 학습된 모델은 다운스트림 소비를 위한 엔드포인트로 게시됩니다.
• 실시간 이상 탐지를 위한 워크플로:
• 실시간 거래 데이터 스트림이 Lambda 함수에 의해 수집됩니다.
• 데이터는 훈련된 모델 엔드포인트(예: Random Cut Forest 알고리즘)를 통해 실행됩니다.
• 이상 징후가 감지되면 직원에게 알립니다.
• 데이터는 모델 결정을 기반으로 한 향후 학습을 위해 RDS로 피드백됩니다.
• ETF 분류에 대한 워크플로:
• 새로운 ETF 데이터가 Lambda 함수로 전송됩니다.
• 데이터는 훈련된 모델 엔드포인트를 통해 실행됩니다.
• 결과는 운영자에게 제공됩니다
• 데이터는 RDS 인스턴스에 저장됩니다.

트레이딩 백오피스 자동화

비즈니스 컨텍스트

• 투자의 목표: 돈을 키우세요
• 포트폴리오 성장으로 인해 자본 이득세가 높아집니다.
• 특히 순자산이 매우 높은 고객의 경우 대규모 계정은 상당한 세금 결과에 직면하게 됩니다.
• 계정에 대한 세금 기준액 존재 리밸런서 복잡성
• 리밸런서 프로세스가 복잡합니다.
• 세금 인식 및 최적화를 추가하면 복잡성이 증가합니다.
• 알고리즘은 상호 의존성과 민감도가 높은 50 변수를 고려합니다.
• 다중 에이전트 AI 프레임워크
• 문제 해결을 위한 에이전트 AI 사용 탐색
• 에이전트는 특정 역할과 작업을 가진 모델입니다.
• 22 데이터 세트로 훈련됨
• 데이터 세트에는 50+ 매개변수가 있는 알고리즘과 세금 거래 재조정기의 과거 실행이 포함됩니다.
• 하루에 수백 건의 요청을 처리합니다.
• 추가 처리를 위해 결과가 다시 전송됩니다.
• 검증 에이전트
• 계단식 종속성과 계정 생태계에 미치는 영향을 확인합니다.
• 유리한 결과를 승인하여 거래 대리인에게 진행
• 검증에 실패할 경우 재처리를 위한 피드백을 보냅니다.
• 거래 대리인
• 마켓 메이커 및 마켓 센터와 거래를 실행합니다.
• 처리량에서 10x 규모를 보여주는 에이전트 루프의 일부 업계 동향
• 모델 기반 거래로 전환
• 일부 계정은 과거 사유 및 운영 강도로 인해 아직 전환되지 않았습니다 AI 해결 방법
• 자문가가 현재 관리하는 장부와 계좌 보유 내역을 분석합니다.
• 계정이 모델 기반 관행으로 전환할 수 있는 모델을 제안합니다.
• 운영 업무를 줄이고 고객 상호 작용 시간을 늘려 자문가의 효율성을 높이는 것을 목표로 합니다.