루미나(Lumina) 구축 사례: Bybit 연동 코인 자동매매 프로그램 개발

핵심 요약

1. 여러 사용자가 전문가의 자동매매 전략을 공유하고 각자의 조건으로 편집해 실행할 수 있는 거래 환경이 필요했습니다. 2. 트램스는 전략 설정 기능에 Bybit API 실거래 연동, WebSocket 공통 시세 수신, 요청 대기 큐와 모의투자를 연결했습니다. 3. 사용자는 전략을 직접 구성하거나 공유 전략을 수정하고, 모의거래와 실제거래를 구분해 이용할 수 있습니다.

프로젝트 소개

루미나(Lumina)는 트램스가 제작한 Bybit 기반 코인 선물 자동매매 프로그램입니다. 자동매매는 사용자가 정한 진입·청산 조건에 따라 프로그램이 거래를 실행하는 방식입니다. 이 프로젝트는 전략을 만드는 트레이더와 그 전략을 활용하려는 사용자를 하나의 서비스에서 연결하는 것을 목표로 했습니다.

핵심 요구는 전문가가 올린 전략을 여러 사용자가 활용하면서도 자신의 조건에 맞게 편집할 수 있도록 하는 것이었습니다. 따라서 전략을 공유하는 화면뿐 아니라, 거래 조건을 구체적으로 설정하고 실행 환경을 선택하는 흐름이 중요했습니다.

Bybit 거래 연동과 전략 공유·모의투자를 갖춘 서비스를 준비하는 핀테크 사업자에게는 이 기능들을 연결하는 구조가 필요합니다. 루미나는 사용자 설정을 출발점으로 실시간 시세를 받아 전략을 실행하고, 모의거래와 실거래를 각각 이용할 수 있는 환경을 구축했습니다.

자동매매 전략 설정: 조건·종목·위험 한도를 데이터로 저장

전략 공유 기능에서는 사용자가 새 전략을 만들거나 다른 사용자가 공개한 전략을 수정할 수 있습니다. 전략 설정 화면은 거래소·종목·시간 간격·진입 조건·수량·청산 조건을 입력하는 구조입니다. 공유받은 전략에서도 자신이 적용하려는 거래 조건을 구체적으로 다룰 수 있도록 했습니다.

이때 자동매매 전략은 프로그램이 판단할 수 있는 항목별 설정값으로 다룹니다. 종목은 어떤 시장을 볼지, 시간 간격은 어느 주기의 데이터를 볼지 정하는 입력입니다. 진입·청산 조건과 수량은 언제 거래하고 어느 규모로 실행할지를 결정하는 규칙으로 연결됩니다.

전략 설정을 구현할 때는 이 항목들을 하나의 전략 설정 모델로 묶고 입력 형식과 허용 범위를 검사한 뒤 저장하는 구조를 적용할 수 있습니다. 예를 들어 수량의 숫자 형식, 필수 조건의 누락, 선택한 종목과 시간 간격의 유효성을 검사하도록 설계합니다. 잘못된 설정을 실행 단계까지 넘기지 않고 해당 입력에서 수정하도록 안내하는 방식입니다.

위험 한도를 다루려면 주문 수량의 상한과 거래를 종료할 조건도 명시적인 데이터로 저장하는 설계가 필요합니다. 실행 로직은 전략의 진입 조건을 판단한 다음, 주문이 설정한 한도를 충족하는지 별도로 확인하도록 구성할 수 있습니다. 이렇게 하면 매매 신호와 주문 허용 범위를 각각 검토할 수 있습니다.

공유와 편집이 함께 있는 서비스에는 전략의 버전을 나누어 저장하는 방식도 적용할 수 있습니다. 원본 전략과 사용자 수정본을 구분하고, 실행할 때 선택한 버전의 설정값을 연결하는 구조입니다. 이후 조건을 바꾸더라도 어느 설정으로 실행했는지 비교할 기준을 남길 수 있습니다.

설정 저장을 검증할 때는 입력값을 저장한 뒤 다시 불러왔을 때 조건이 유지되는지부터 점검합니다. 공유 원본을 수정본으로 저장했을 때 두 전략이 구분되는지, 허용 범위를 벗어난 값이 실행 전에 걸러지는지도 확인 대상으로 둡니다. 전략 편집이라는 사용자 행동을 실제 실행 규칙으로 연결하는 데 필요한 검증입니다.

실시간 시세·주문 연동: Bybit API와 공통 WebSocket 수신

여러 사용자가 같은 종목을 거래하면 동일한 시세를 반복해서 요청할 수 있습니다. 루미나는 Bybit WebSocket을 이용한 공통 데이터 센터를 구축해 시세를 함께 사용하는 구조를 적용했습니다. WebSocket은 연결을 유지하면서 서버가 보내는 갱신 데이터를 받는 통신 방식입니다.

공통 데이터 센터는 거래소에서 받은 시세를 여러 사용자의 전략 실행에 활용하는 역할을 합니다. 사용자가 동일 시세를 각각 호출하는 부담을 줄이면서, 수신한 데이터를 실거래와 모의거래 기능에서 활용할 수 있게 했습니다. 시세 수집을 여러 사용자가 함께 쓰는 부분으로 묶은 것이 기술 선택의 핵심입니다.

실거래에는 프로그램과 거래소가 요청·응답을 주고받는 연결 수단인 Bybit API를 사용했습니다. 전략이 거래 조건을 만족해 주문 요청을 만들면 거래소 연동으로 이어지는 구조입니다. 여러 사용자의 요청이 한꺼번에 몰리는 상황을 고려해 대기 큐를 두고 주문 호출의 집중을 완화했습니다.

이 과정에서 시세 수신, 주문 요청, 체결 확인은 구분해서 다뤄야 합니다. 가격 데이터가 도착한 사실과 거래소에서 주문이 실제 체결된 사실은 서로 다른 상태입니다. 주문 처리 설계에서는 주문을 보낸 결과와 이후 체결 상태를 별도로 관리해 사용자에게 현재 상태를 보여주는 방식이 필요합니다.

시세를 전략 조건으로 변환하는 세부 로직도 명확해야 합니다. 현재 Bybit의 Kline 기능은 일정 시간의 가격 변화를 묶은 캔들 데이터를 제공하며, confirm 값으로 해당 캔들이 마감됐는지 구분합니다. 마감 가격을 기준으로 판단하는 전략을 새로 구현한다면 이 값을 활용할 수 있습니다.

이러한 설계에서는 갱신 중인 가격을 사용할지, 마감된 캔들을 사용할지 전략의 판단 시점부터 정합니다. 화면에 표시할 차트 데이터의 공급자와 주문을 보낼 거래소도 별도로 정의해야 합니다. 차트의 표시 가격을 주문 거래소의 체결 가격으로 취급하지 않도록 데이터의 용도를 구분하는 방식입니다.

다중 사용자 서비스에서는 인증키를 보호하는 설계도 필요합니다. 사용자별 거래소 인증키는 서버에서 보호하고, 해당 사용자의 주문 처리에 필요한 범위에서 접근하도록 구성할 수 있습니다. 공통으로 사용하는 시세 데이터와 계정별 인증·주문 권한을 구분하면 다중 사용자 환경의 접근 범위를 명확히 설계할 수 있습니다.

모의투자 검증: 같은 전략을 실거래와 분리해 실행

전략을 편집한 사용자는 그 조건이 어떻게 동작하는지 살펴볼 과정이 필요합니다. 루미나는 공통 시세 데이터 센터를 활용한 모의거래 프로그램과 Bybit API를 연결한 실제거래 프로그램을 구축했습니다. 사용자는 모의거래 화면과 실제거래 화면을 구분해 이용할 수 있습니다.

모의투자는 전략에 따른 주문을 가상으로 처리하는 방식이고, 실거래는 실제 거래소로 주문을 전달하는 방식입니다. 같은 전략을 검토하더라도 주문을 처리하는 환경이 달라집니다. 이 구분을 통해 사용자는 실제 주문을 내기 전에 전략의 조건과 실행 흐름을 살펴볼 수 있습니다.

모의거래와 실거래를 함께 설계할 때는 전략 설정과 시세를 받아 매매 여부를 판단하는 부분은 공통으로 두고 주문 처리 부분을 나눌 수 있습니다. 모의 실행에서는 가상 체결 규칙을 적용하고, 실거래 실행에서는 거래소 주문 처리로 전달합니다. 전략 조건을 두 환경에서 별도로 작성하지 않아도 비교할 수 있도록 만드는 방식입니다.

환경 구분은 화면 표시와 실제 주문 전달 경로에 함께 반영하는 것이 필요합니다. 예를 들어 모의 실행의 잔액·보유 수량·주문 기록을 실거래 기록과 구분해 관리하도록 설계할 수 있습니다. 실행 전에 선택한 환경을 확인하게 하면 사용자가 어떤 결과를 보고 있는지도 명확해집니다.

모의 주문의 체결 기준은 검증 결과를 해석하는 데 영향을 줍니다. 가상 체결을 구현할 때는 수수료, 주문 전달 지연, 일부 수량만 체결되는 상황을 가상 처리 규칙에 반영할 수 있습니다. 어느 시점의 가격으로 가상 체결을 계산했는지 함께 남기면 조건을 바꿨을 때 결과가 달라진 이유를 검토하는 데 도움이 됩니다.

전략 실행을 검증할 때는 동일한 전략 설정에 대해 진입 판단, 주문 생성, 청산 판단을 순서대로 점검할 수 있습니다. 주문을 만들지 않아야 하는 조건과 위험 한도에 걸리는 조건도 검증 항목에 포함할 수 있습니다. 이는 전략 실행 로직의 동작을 확인하는 과정이며, 모의투자에서 얻은 수익이 실제 거래의 수익을 보장하지는 않습니다.

성공 요소

첫 번째 성공 요소는 전략을 공유하는 목적과 사용자가 편집하는 목적을 함께 반영한 점입니다. 전문가의 전략을 여러 사람이 활용하려면 각 사용자가 적용할 조건을 다룰 수 있어야 했습니다. 전략 생성·공유·수정 기능을 연결해 사용자가 거래 조건을 구성하는 흐름을 제공했습니다.

두 번째는 다중 접속·다중 거래라는 제약에 맞춰 시세 수신과 주문 요청을 각각 다룬 점입니다. 공통 데이터 센터는 동일 시세의 중복 호출을 줄이는 역할을 하고, 요청 대기 큐는 주문 호출이 집중되는 상황을 완화합니다. 두 구성을 함께 적용해 여러 사용자가 거래소 연동을 이용하는 기반을 마련했습니다.

다만 거래소의 호출 제한은 운영 조건에 따라 계속 고려해야 합니다. 현재 Bybit는 IP와 사용자 계정 식별자인 UID, API 기능별로 요청 한도를 구분합니다. 따라서 유사 서비스를 운영할 때는 공통 수신과 큐에 더해 적용 한도와 남은 요청량을 확인하는 설계가 필요합니다.

오류 대응도 원인에 맞게 구분해야 합니다. 공식 문서는 HTTP 429를 시스템 수준 빈도 제한으로 설명하며, IP 요청 빈도 초과에 따른 403과 API 한도 초과 코드 10006을 별도로 안내합니다. 공통 시세 수신과 큐는 제한 위험을 낮추는 구성이며, 모든 차단이나 오류의 제거를 보장하지는 않습니다.

세 번째는 모의거래를 별도 이용 흐름으로 제공한 점입니다. 전략을 편집하는 기능과 실거래 연동 사이에 조건을 살펴볼 환경을 마련했습니다. 사업자는 전략 공유부터 시험 실행, 실제 거래까지 이어지는 사용자 흐름을 서비스 범위로 검토할 수 있습니다.

개발 기간 · 비용 · 투입 인력

루미나의 개발 기간은 2개월, 개발 비용은 2,500만 원이며 투입 인원은 2명입니다. 전략 설정과 공유, Bybit 연동, 공통 시세 수신과 모의거래 등을 포함한 해당 프로젝트의 구축 범위 기준입니다. 유사 프로젝트의 기간과 비용은 필요한 기능과 연동 범위를 정한 뒤 별도로 검토합니다.