02. [공학] 시스템 아키텍처: 수집-분석-주문-모니터링 파이프라인 설계

안녕하세요! 보배로의 북테크랩입니다.

지난 시간, 우리는 왜 24시간 잠들지 않는 코인 시장이 자동매매의 최적의 무대인지 확인했습니다. 오늘은 그 강력한 '수익 엔진'을 실제로 어떻게 구성할지, 그 핵심 뼈대인 시스템 아키텍처를 공학적으로 설계해 보겠습니다.

 

단순히 "코드를 짜서 사고파는 것"을 넘어, [PHASE 1] Infrastructure & DevSecOps의 운영 포인트인 안정성, 확장성, 그리고 무결성을 확보하기 위한 파이프라인 설계를 공개합니다.

 

기술적인 용어들이 조금 생소할 수 있습니다. 하지만 핵심은 시스템이 원활하게 작동하기 위한 '역할 분담'과 '신뢰성' 확보에 있습니다. 각 용어의 정의와 비유를 통해 보다 직관적으로 이해하실 수 있도록 구성했습니다.

---

1. 전체 아키텍처 조감도: 4대 핵심 파이프라인

우리의 자동매매 OS는 크게 4개의 독립적이면서도 유기적인 파이프라인으로 구성됩니다. 이들은 각각의 역할을 수행하며 전용 [Event Bus]를 통해 데이터를 주고받습니다.

(1) 데이터 수집 (Data Collection) 파이프라인

시스템의 '눈'입니다. 전 세계 거래소로부터 실시간 시세와 호가창 데이터를 가져옵니다.

• REST API vs WebSocket (10강):
  • 비유: 과거 데이터는 전화(REST API)로, 실시간 시세는 생방송(WebSocket)으로 가져오는 것입니다.
  • 단순 과거 데이터는 REST API로, 실시간 체결과 호가창은 WebSocket으로 최적화하여 수집합니다.
• CCXT 라이브러리 (08강):
  • 비유: 전 세계 모든 거래소와 통화할 수 있는 '만능 통역사'입니다.
  • 수십 개 거래소의 상이한 API를 표준화된 인터페이스로 통합합니다.

(2) 데이터 분석 (Analysis) 파이프라인

시스템의 '뇌'입니다. 수집된 데이터를 가공하여 매매 시그널을 생성합니다.

• Feature Engineering (21강):
  • 비유: 날고기(원시 데이터)를 요리하기 좋게 '손질'(가공)하는 과정입니다.
  • RSI, Bollinger Bands 같은 지표를 계산하고 정제합니다. 이 과정은 [Feature Store]를 통해 AI 에이전트들과 공유됩니다.
• 전략 로직 실행 (18~20강):
  • 비유: 미리 짜둔 매매 족보(변동성 돌파 전략 등)를 보고 냉정하게 판단하는 것입니다.
  • 변동성 돌파, 추세 추종 등 우리가 설정한 알고리즘이 감정 없이 작동합니다.

(3) 주문 실행 (Order Execution) 파이프라인

시스템의 '손'입니다. 분석된 시그널을 바탕으로 실제 주문을 거래소에 전송합니다.

• Fail-Safe 설계 (42, 45강):
  • 비유: 주문 전, 지갑 잔고를 확인하고 미체결 주문을 정리하는 등 '실수 방지 안전장치'입니다.
  • 주문 전송 전 예외 상황을 선제적으로 차단합니다.
• Queue System (53강):
  • 비유: 거래량이 폭발하는 순간, 주문이 몰려도 사라지지 않게 하는 '대기열' 시스템입니다.
  • Kafka/RabbitMQ 기반 큐를 통해 폭주 상황에서도 주문 유실을 방지합니다.

(4) 모니터링 (Monitoring) 파이프라인

시스템의 '신경계'입니다. 봇의 상태와 리소스 사용량을 감시합니다.

• Prometheus + Grafana (11강):
  • 비유: 봇의 체온과 맥박(메모리 사용량, 에러율 등)을 실시간 차트로 보여주는 'CCTV 관제 센터'입니다.
  • 모든 프로세스의 상태를 시각화하여 관제합니다.
• Heartbeat (12강):
  • 비유: 봇에게 "살아있니?"라고 주기적으로 물어보는 '생존 신호'입니다.
  • 봇의 생존을 확인하고, 장애 시 [Self-Healing] 로직을 가동합니다.

---

📝 보배로의 통찰: "운영 포인트가 아키텍처를 결정한다"

단순히 4단계 파이프라인을 연결한다고 해서 완벽한 시스템이 되지는 않습니다. 보배로 OS의 차별점은 바로 PHASE 1의 강력한 운영 포인트들을 아키텍처 전반에 이식했다는 점입니다.

💡 "모든 주문에는 이유가 있어야 합니다." -> [NEW/Audit Trail] (57강)

• 비유: 모든 주문서에 매수 버튼을 누른 순간의 RSI 값이나 AI 감성 점수 같은 '근거 데이터'를 문신처럼 새겨두는 것입니다.
• [그림 2-1]에서 보듯, 분석 단계의 최종 파라미터를 주문 정보와 함께 하나의 스냅샷으로 묶어 DB에 위변조 불가능하게([Immutable Log]) 저장합니다.

💡 "코드 한 줄 건드리지 않고 전략을 바꿉니다." -> [Config System] (07강)

• 비유: 매매 일지(코드)를 고치는 게 아니라, 매매에 쓸 족보(전략 파일)만 교체하는 것입니다.
• 설정 관리 시스템은 YAML/JSON 파일을 기반으로 작동합니다. 우리는 서버를 재시작하거나 코드를 수정하지 않고도, 활성화할 전략([Meta Strategy])을 변경하거나 파라미터를 실시간으로 튜닝할 수 있습니다.

💡 "시스템은 기억(Persistence)을 가져야 합니다." -> [State Recovery] (51강)

• 비유: 서버가 꺼져도 내가 들고 있는 코인과 미체결 주문 목록(기억)은 안전한 창고(Redis/DB)에 저장해 두는 것입니다.
• Event Bus는 Redis 같은 인메모리 DB를 활용하여 모든 상태를 실시간으로 영속화합니다. EC2 장애로 서버가 재부팅되더라도, 봇은 이 '기억'을 불러와 이전 포지션과 주문 상태를 100% 복원합니다.

💡 "100% 신뢰는 없습니다. 오직 검증된 확장만 있을 뿐입니다." -> [Canary Deploy] (06강)

• 비유: 새 전략을 바로 전체 자산에 적용하지 않고, 자산의 1%에만 배포하여 24시간 검증한 후 확대하는 '안전 배포' 방식입니다.
• 우리의 CI/CD 파이프라인([GitHub Actions])은 새 전략을 자산의 1%에만 배포하여 검증한 후, 문제가 없을 때만 단계적으로 전체 서버로 확장하는 Canary 방식을 따릅니다.

---

보배로의 Crypto OS는 이러한 공학적 설계를 기반으로 구축됩니다. 다음 시간에는 이 파이프라인들이 실제로 돌아갈 인프라, AWS EC2 구축 및 DevSecOps 보안 설정을 배워보겠습니다.

---

보배로의 북테크랩(Booktech-lab) 공학적으로 투자하고, 데이터로 증명하며, 시스템으로 승리합니다.