트레이딩 시스템을 위한 소프트웨어 설계 패턴

금융 소프트웨어는 값비싼 방식으로 실패합니다: 중복 주문, 불일치하는 잔액, 조용한 부분 실패. 디자인 패턴은 트로피가 아닙니다 — 반복되는 실패 모드에 대한 대응입니다: 감사 가능성을 위한 이벤트 소싱(event sourcing), 읽기와 쓰기를 다르게 확장하기 위한 CQRS, 연쇄 장애를 막기 위한 서킷 브레이커, 재시도가 중복 거래를 만들지 않도록 하는 멱등성(idempotency)입니다.

매칭 엔진, 리스크 체크, 시장 데이터 게시자는 거대한 진흙 덩어리(ball of mud) 안에서 서로를 직접 호출해서는 안 됩니다. 발행/구독(publish/subscribe) 버스는 매칭 엔진이 체결(fill)을 방출하게 하고, 다운스트림 서비스는 업스트림의 구현 세부사항을 모른 채 구독할 수 있게 해줍니다 — 다만 전달 보장 방식(최소 1회 대 정확히 1회)과 재생을 위한 보존 정책은 여전히 직접 선택해야 합니다.

서킷 브레이커는 반복된 실패 이후 문제가 있는 의존성 호출을 멈춰서, 그것이 회복할 시간을 주고 여러분의 스레드 풀을 보호합니다. 벌크헤드(bulkhead)는 리소스 풀을 격리시켜 폭주하는 분석 작업이 주문 제출을 굶기지 못하게 합니다.

주문과 이체에는 정해진 생애주기가 있습니다. 허용된 전환을 유한 상태 머신(finite state machine)으로 인코딩해서 잘못된 점프가 불가능하게 만드세요. 여기에 클라이언트 요청에 대한 멱등성 키(idempotency key)를 결합하면 네트워크 재시도가 중복된 실거래 주문을 만들 수 없게 됩니다.

중앙화된 거래소는 들어오는 주문을 대기 중인 유동성과 가격-시간 우선순위로 매칭합니다. (많은 L1 DEX 설계처럼) 온체인 매칭 엔진은 결정론적이어야 합니다: 모든 검증자가 같은 시퀀스를 다시 실행해 동일한 상태에 도달합니다 — GaiaEx는 이 모델을 Hyperliquid의 규칙에서 상속받습니다.

첫날부터 모든 패턴을 맹목적으로 따라 하지 마세요. 명확한 경계, 구조화된 로그, 그리고 자금 이동을 둘러싼 테스트부터 시작하세요. 정합성 검증(reconciliation)의 고통이 나타나면 이벤트 로그를 추가하고, 외부 API가 불안정해지면 서킷 브레이커를 추가하세요. 패턴은 상상 속의 문제가 아니라 실제 상처를 치료합니다.