하이퍼리즘에서는 트레이딩, 시장 모니터링, 리스크 관리 등 여러 핵심 업무가 수백 개의 자동화된 봇(Bot)에 의해 수행됩니다. 테크팀은 이러한 자동화 시스템의 안정적인 운영을 전담하는 조직이며, 민감한 정보와 막대한 자금을 다루는 봇들이 어떤 상황에서도 빠르고 안전하게 실행될 수 있는 기술 환경을 구축한다는 비전을 가지고 있습니다.

이번 글에서는 테크팀의 봇 운영 플랫폼 BOS(Bot Operating System)가 어떤 고민 속에서 만들어졌으며, 그 과정에서 어떤 기술적 선택들을 했는지 이야기해 보려 합니다.

문제의식

BOS가 만들어지기 전, 하이퍼리즘에서는 트레이더와 리서처들이 작성한 수많은 코드가 통일된 기준 없이 제각각의 환경에서 운영되고 있었습니다. 누구나 시장의 아이디어를 빠르게 코드로 구현하고 검증하는 문화는 회사의 핵심 경쟁력이지만, 이 과정에서 생성된 코드들이 각자의 방식으로 관리되면서 기술 부채가 점차 쌓여갔습니다. 최근에는 AI를 활용한 바이브 코딩(Vibe Coding)¹ 트렌드가 더해지며 이러한 움직임이 더욱 가속화되었고, 각개전투에 가까운 개발 및 배포 방식이 가져다 주는 자율성과 속도보다 아래와 같은 단점들이 부각되기 시작했습니다.

권한 관리의 부재

가장 시급한 문제는 보안이었습니다. 빠른 실행을 위해 API 키가 로컬 환경에 평문으로 저장되거나 개인 EC2 인스턴스에 과도한 권한이 부여되는 사례가 많았고, 정교한 권한 관리나 주기적인 키 회수 및 교체(Rotation)는 거의 불가능에 가까웠습니다.

이러한 문제는 직무 구분 없이 개발에 참여하는 하이퍼리즘의 환경에서 더욱 두드러졌습니다. 막대한 자금을 운용하는 핵심 트레이딩 봇부터 AI의 도움을 받아 5분 만에 작성된 데이터 수집용 스크립트까지, 조직 내에는 중요도와 신뢰 수준이 각기 다른 코드가 혼재했기 때문입니다. 사소한 코드에 잘못 부여된 권한이 크리티컬한 시스템에 영향을 미칠 수 있는 가능성을 차단하기 위해, 각 코드의 역할에 맞는 최소한의 권한을 부여하고 민감 정보 접근을 원천적으로 분리하는 체계가 필요했습니다.

운영 안정성의 한계

각자가 프로그램을 독립적으로 실행하고 관리하는 환경에서는 실행 중인 코드의 상태를 통합적으로 감지할 체계를 마련할 수 없었기에 운영 안정성에 뚜렷한 한계가 있었습니다. 프로그램이 예상치 못하게 종료되거나 비정상적으로 동작해도 아무도 즉시 알아차리기 어려웠죠.

문제 발생 시 원인 파악과 복구 또한 전적으로 인프라를 구축한 담당자의 수작업에 의존해야 했습니다. 장애를 자동으로 감지하고, 신속하게 알림을 보내며, 설정된 정책에 따라 자동으로 복구해주는 안정적이면서 통일된 인프라가 필요했습니다.

코드와 실행 환경의 파편화

코드의 실행 환경이 표준화되지 않아 재현성(Reproducibility)을 보장하기 어려웠습니다. 개발자마다, 서버 인스턴스마다 미세하게 다른 개발 환경 차이는 예측 불가능한 버그의 원인이 되었습니다.

이는 개발자 간의 협업 효율을 떨어뜨렸을 뿐만 아니라, 코드를 전달받아 사용하는 트레이더 등 비개발 직군 동료들에게도 큰 혼란을 야기했습니다. 결국 누가 어디서 실행하든 항상 동일한 결과를 보장하는 표준 실행 환경의 필요성이 대두되었습니다.

운영 가시성 및 사용자 경험(UX)의 부재

수백 개의 프로그램이 각기 다른 환경에서 운영되다 보니 전체 시스템 현황을 한눈에 파악할 관제탑이 없었고, 운영 데이터의 조회 방식 및 포맷이 파편화되어 문제 추적과 성능 분석에도 많은 시간이 소요되었습니다.

게다가 인프라에 익숙하지 않은 사용자를 위한 최소한의 인터페이스조차 부재했습니다. 트레이더가 전략을 실행하기 위해 아래와 같이 개발자가 전달해준 복잡한 명령어 목록을 직접 터미널에 입력해야 하는 경우도 종종 발생했죠.

ssh demo-user@demo-server - 서버에 연결
cd sample-trading-runner - 거래 봇이 있는 폴더로 이동
vim src/apis/accountManager.ts - 트레이딩 하기 위해 API 먼저 설정
vim env.yaml 거래 로직 설정
yarn start:not-trade 거래 시뮬레이션
docker build -t <trading-bot-name> . : 띄우기쩜 필수! 거래봇의 템플릿을 생성함 (거래는 시작 안됨)
docker run -d --name <trading-job-name> <trading-bot-name> : 위에서 만든 템플릿을 사용해서 거래봇을 작동시킴
docker ps -a : 현재 거래 실행중인 봇들 리스트 확인
docker stop <stop-job-name> : 돌아가고 있는 봇 중단
docker rm <remove-job-name> : 중지된 봇 삭제 (삭제하기 전 위의 중지부터 해야함)

모든 구성원이 자신의 역할에 맞는 정보를 명확히 확인하고, 복잡한 인프라 지식 없이도 필요한 작업을 수행할 수 있도록 돕는 중앙화된 콘솔과 직관적인 인터페이스가 필요했습니다.

BOS는 이 문제들을 어떻게 해결했나요?

BOS는 크립토 트레이딩 도메인이 요구하는 보안과 안정성 수준을 충족하면서도, 모두가 인프라 운영 부담 없이 핵심 업무에만 집중할 수 있는 환경을 제공하기 위해 다음과 같은 구조를 도입하였습니다.

GitHub 카탈로그

BOS의 중심에는 GitHub 기반의 카탈로그(Catalog) 레포지토리가 있습니다. 이 레포지토리에는 각 프로그램의 실행에 필요한 모든 정보가 YAML 형식의 스키마로 명확하게 정의되어 있고, 이러한 실행 단위를 '봇(Bot)'이라 부릅니다. 일반적으로 봇하면 떠올리는 단순 코드베이스보다 조금 더 복합적인 개념입니다.

봇(Bot): 실행 가능한 코드(Code) + 실행 환경 메타데이터(Metadata) + RBAC 기반 권한(Permission)

새로운 봇을 등록하는 과정은 이 카탈로그 레포지토리에 메타데이터 추가 및 변경에 대한 PR(Pull Request)을 생성하고, 코드 리뷰를 거쳐 병합(Merge)하는 것으로 완료됩니다. 모든 변경 사항과 리뷰 기록이 Git 로그에 남게 되고, 환경 설정의 불일치나 실행 방식의 편차가 원천적으로 해소됩니다. 누구나 (권한만 있다면) 동일한 표준 환경에서 봇을 실행하고 예측 가능한 결과를 얻을 수 있는 것이죠.

RBAC 정책

카탈로그 레포지토리 내에서 RBAC(Role-Based Access Control) 정책 또한 코드로 관리됩니다. 사용자와 봇, 그리고 봇과 API 키 사이의 권한 관계를 코드로 정의하고, 모든 변경사항은 마찬가지로 PR 리뷰를 거쳐서 반영됩니다.

사용자의 봇 권한 정의는 단순히 어떤 봇을 쓸 수 있는지를 넘어, '인스턴스 생성, 삭제'와 같은 동작(verb) 단위까지 지정할 수 있어 매우 세밀한 제어가 가능합니다. 또한, 이렇게 정의된 역할(Role)들은 재사용이 가능하므로 조직의 구조나 정책에 맞춰 직관적인 권한 체계를 구성할 수 있습니다.

API 키에 대한 봇의 권한 정의는 아래에서 설명할 Keyless 아키텍처와 유기적으로 결합하여, 봇이 민감한 정보에 직접 접근하지 않고도 필요한 작업을 안전히 수행할 수 있도록 지원합니다.

실행 환경과 RBAC 정책을 통합한 카탈로그 레포지토리의 전체 구조는 아래와 같습니다.

동적 런타임 구성

BOS에서 봇을 실행하는 과정은 사용자가 특정 설정(Config)을 주입하여 '봇 인스턴스' 생성을 요청하는 것에서 시작됩니다. 이 덕분에 동일한 코드의 봇이라도, 설정을 달리 하여 각기 다른 목적(예: 다른 거래 페어, 다른 전략 변수)을 가진 여러 인스턴스를 동시에 운영할 수 있습니다.

인스턴스의 직접적인 관리는 쿠버네티스 컨트롤러가 담당합니다. 사용자의 요청은 인스턴스 정보를 담은 커스텀 리소스(Custom Resource, CR)를 클러스터 내에 생성하게 되고, 컨트롤러는 CR의 상태를 지속적으로 감시하며 CR이 생성, 수정, 삭제될 때마다 대응되는 파드(Pod)를 생성, 삭제하여 클러스터의 현재 상태를 사용자가 의도한 상태(Desired State)와 일치시킵니다.

이렇게 생성된 파드는 부팅 직후 자신의 메타데이터를 조회하여 지정된 Git 레포지토리의 소스 코드를 복제(Clone)하고, 필요한 의존성을 설치한 뒤 코드를 실행합니다. 컨테이너 이미지를 사전에 빌드하지 않고 파드 시작 시점에 소스 코드를 가져와 환경을 구성하므로, 최신 버전의 코드를 즉시 반영하며 빠른 개발 사이클을 적용할 수 있습니다.

Keyless 아키텍처

BOS는 봇 코드에서 API 키를 완전히 분리하는 Keyless 아키텍처를 채택했습니다. 봇은 민감 정보(Secret)를 직접 소유하는 대신, '어떤 키 ID를 사용해 어떤 동작을 수행해달라'는 추상적인 요청을 내부 API 게이트웨이로 보냅니다.

API 게이트웨이는 요청을 받으면 먼저 파드에 부여된 서비스 어카운트(ServiceAccount) 토큰을 검증하여 요청의 신원을 확인하고, RBAC 카탈로그에 정의된 정책을 조회하여 해당 봇이 요청한 작업을 수행할 권한이 있는지 검증(인가)합니다. 모든 검증을 통과하면, 게이트웨이는 중앙화된 시크릿 저장소에서 키 ID에 대응되는 실제 API 키를 조회한 후 거래소 API 호출을 대행합니다.

이 구조에서 봇은 시크릿 노출 가능성을 원천적으로 배제한 채 원하는 동작을 수행할 수 있고, 키의 회수나 교체는 봇 코드 의존성 없이 인프라 계층에서 독립적으로 이루어질 수 있습니다.

SDK와 웹 콘솔

BOS는 봇 개발자가 오직 비즈니스 로직에만 집중하는 이상적인 환경을 지향합니다. 이를 위해 제공되는 언어별 SDK는 개발자가 로직 구현에만 집중할 수 있도록 로그, 메트릭, 에러 리포트 등 운영에 필수적인 공통 기능을 자동으로 지원합니다.

이렇게 SDK가 수집하고 리포팅한 정보는 운영자가 한눈에 파악할 수 있어야 합니다. 이를 위해 BOS 웹 콘솔은 봇 인스턴스의 현재 상태, 실시간 로그, 핵심 메트릭 등 모든 정보를 한 화면에 제공하고 있으며, 운영자는 별도의 터미널 접근 없이 웹 콘솔에서 인스턴스 제어, 설정 변경 등 대부분의 관리 작업을 수행할 수 있습니다.

물론 운영자가 항상 웹 콘솔만 보고 있을 수는 없으므로 문제 발생 시 즉각적인 대응이 가능하도록 추가로 다양한 알림 창구를 지원하고 있습니다. 가령 실행 중인 봇 인스턴스에 예상치 못한 에러가 발생할 경우, SDK는 이를 감지하고 슬랙으로 알림을 발송하여 담당자가 즉시 문제를 인지하고 대응에 나설 수 있도록 돕습니다.

정리

지금까지 설명드린 BOS의 구성 요소들과 그 역할을 종합해서 정리해보면 아래와 같습니다.

• Github 카탈로그: 봇의 실행 환경, RBAC 정책 등 모든 설정을 한 곳에서 코드로 정의하고 관리하여 환경의 파편화 문제를 해결합니다.
• 쿠버네티스 컨트롤러: 사용자가 정의한 상태(Desired State)에 맞춰 봇 인스턴스의 생명 주기를 자동으로 관리하며 운영 안정성을 보장합니다.
• Keyless 아키텍처: 봇의 신원을 확인하고 권한을 검증한 뒤 API 호출을 대행하여, API 키를 코드로부터 완벽히 격리함으로써 봇 레이어의 보안 문제를 원천적으로 차단합니다.
• SDK와 웹 콘솔: 운영 데이터를 자동으로 수집하고 한곳에서 시각화하여, 운영 가시성 및 사용자 경험(UX)의 부재를 해결합니다.

마치며

현재 BOS는 수백 개의 봇이 안정적으로 구동되는 사내 플랫폼으로 성장했지만, 이는 시작에 불과합니다.

저희는 이제 멀티 리전(Multi-region) 지원을 통한 글로벌 확장, 데이터 파이프라인 통합, 정책 제어 UX 고도화 등 다음 단계의 과제들을 준비하고 있습니다. 그리고 궁극적으로는 AI 에이전트를 접목하여 보다 능동적인 제어 시스템을 구축하는 것을 목표로 합니다.

하이퍼리즘 테크팀은 "기술을 통해 사람을 자유롭게 한다"는 믿음 아래 플랫폼 엔지니어링의 여정을 계속 이어가고 있습니다. 이러한 여정에 함께할 분들의 많은 지원과 관심을 기다립니다!

☕ 커피챗 문의 - cto@hyperithm.com