암호화폐 거래소 매칭 엔진은 실제로 어떻게 작동하는가

목차

• 거래소의 성패를 가르는 소프트웨어
• 매칭 엔진이 실제로 하는 일
• 오더북 자료구조: 성능이 결정되는 곳
• 가격-시간 우선 원칙: 공정성 약속
• 지연 시간과 처리량: “빠르다”의 실제 의미
• 주문 유형: 보기보다 복잡하다
• 거래소를 망가뜨릴 엣지 케이스들
• 확장 전략: 단일 스레드의 딜레마
• 메모리 대 디스크: 영속성 문제
• Codono는 이 모든 것을 어떻게 처리하는가
• 결론

거래소의 성패를 가르는 소프트웨어

모든 거래소 창업자는 UI 이야기를 하고 싶어 합니다. 세련된 TradingView 차트, 다크 모드 토글, 모바일 앱 말이죠. 물론 이런 것들은 사용자 확보에 중요합니다. 하지만 거래소가 첫 실전 거래일을 버텨낼 수 있을지를 실제로 결정하는 것이 무엇인지 알고 싶다면, 매칭 엔진을 보십시오.

매칭 엔진은 들어오는 매수 및 매도 주문을 받아 서로 체결 가능한 주문을 찾아내고 거래를 실행하는 핵심 소프트웨어입니다. 간단해 보이지만, 실제로는 그렇지 않습니다. 설계가 엉망인 매칭 엔진은 부하 상태에서 주문을 조용히 누락시키고, 유령 체결을 만들어 내고, 잘못된 잔고를 생성하며, 감사인이 그만두게 만드는 종류의 회계 악몽을 일으킵니다. 저는 이런 문제를 충분히 많이 디버깅해 봐서 그 고통을 직접 알고 있습니다.

사람들을 놀라게 하는 것은 핵심 로직이 얼마나 기만적으로 작아 보이는가입니다. 기존 매도 주문과 매수 주문을 매칭하는 기본 알고리즘은 100줄 미만의 코드로 작성할 수 있습니다. 하지만 그 장난감 수준 구현과 프로덕션급 트레이딩 엔진 사이의 차이는 약 50,000줄에 달하는 엣지 케이스 처리, 영속성 로직, 복구 메커니즘, 성능 최적화입니다.

최신 매칭 엔진 남부에서 실제로 어떤 일이 일어나는지, 그리고 각 설계 결정이 왜 중요한지 하나씩 살펴 보겠습니다.

매칭 엔진이 실제로 하는 일

교과서적 정의는 잠시 잊어 주십시오. 매칭 엔진이 실제로 매 거래일의 매 밀리초마다 하는 일은 다음과 같습니다.

1. 들어오는 주문 수락 — 유형(지정가, 시장가, 스탑), 가격(있을 수도 있고), 수량, 트레이더 ID가 포함된 매수 또는 매도 요청.
2. 주문 검증 — 가격이 틱 크기 요건을 충족하는지, 수량이 최소 로트 크기를 충족하는지, 트레이더가 충분한 잔고를 보유하고 있는지, 그리고 주문이 거래소 규칙을 위반하지 않는지 확인.
3. 매칭 시도 — 오더북 반대편에서 호환되는 대기 주문을 스캔. $50,000의 매수 주문은 $50,000 이하의 모든 매도 주문과 매칭될 수 있습니다.
4. 거래 실행 — 각 매칭에 대해 거래 기록을 생성하고, 양쪽 트레이더의 잔고를 업데이트하고, 오더북을 조정.
5. 나머지 처리 — 들어온 주문이 완전히 체결되지 않은 경우, 오더북에 대기 상태로 남거나(지정가 주문) 취소됩니다(남은 유동성이 없는 시장가 주문).
6. 이벤트 발행 — 거래 체결, 오더북 업데이트, 잔고 변경 사항을 시스템의 나머지 부분에 브로드캐스트.

1단계부터 6단계까지는 원자적으로(atomically) 일어나야 합니다. “결과적 일관성”도, “나중에 조정하겠다”도 아닙니다. 원자적으로요. 4단계가 성공했는데 6단계가 실패하면, 트레이더가 절대 알지 못하는 숨겨진 체결이 생깁니다. 3단계가 성공했는데 4단계가 부분적으로 실패하면, 오더북에 유령 유동성이 생깁니다. 두 상황 모두 어떤 해킹보다 빠르게 신뢰를 파괴합니다.

이것이 바로 매칭 엔진이 주어진 거래 쌍에 대해 거의 항상 단일 스레드의 순차적 프로세서인 이유입니다. 여기서 동시성은 친구가 아니라 부채입니다. 이에 대해서는 확장 이야기를 할 때 더 다루겠습니다.

오더북 자료구조: 성능이 결정되는 곳

오더북은 모든 대기 지정가 주문을 가격 수준별로 정리해 보관하는 자료구조입니다. 매수(bid)와 매도(ask) 두 가지 측면이 있습니다. 매수는 높은 가격에서 낮은 가격 순으로 정렬됩니다. 매도는 낮은 가격에서 높은 가격 순으로 정렬됩니다. 각 측면의 최상단 가격인 최우선 매수가와 최우선 매도가가 스프레드를 정의합니다.

이를 위한 올바른 자료구조 선택은 여러분이 내릴 가장 중요한 아키텍처 결정 중 하나입니다. 실제 선택지는 다음과 같습니다.

정렬된 배열 또는 연결 리스트

가장 간단한 접근법입니다. 정렬된 가격 수준 리스트를 유지하고, 각 수준에 주문 큐를 둡니다.

장점: 구현이 매우 간단. 캐시 친화적인 메모리 레이아웃. 오더북을 순회해야 할 때 빠른 반복.

단점: 삽입이 O(n)이며, 여기서 n은 가격 수준의 개수. 수천 개의 활성 가격 수준이 있는 BTC/USDT 같은 페어에서는 느려집니다. 시프팅 때문에 삭제도 O(n).

결론: 프로토타입에는 적합. 상당한 거래량을 처리하는 프로덕션에는 용납 불가.

균형 이진 탐색 트리(레드-블랙 트리, AVL 트리)

대부분의 프로덕션 매칭 엔진이 사용하는 방식입니다. 자가 균형 BST는 O(log n)의 삽입, 삭제, 조회를 제공합니다. 최솟값과 최댓값 노드에 대한 포인터를 유지하여 최우선 매수가와 최우선 매도가를 효율적으로 찾을 수도 있습니다.

장점: 모든 핵심 연산이 O(log n). 잘 이핸드된 알고리즘. 최우선 매수/매도 포인터 유지가 쉬움.

단점: 포인터가 많은 구조는 캐시 미스를 유발할 수 있음. 리밸런싱 중 트리 회전이 상수 배수 오버헤드를 추가.

결론: 그럴 만한 이유가 있는 업계 표준. 아주 특수한 요구사항으로 다른 방향으로 밀리지 않는 한 이것을 사용해야 합니다.

해시 맵과 스킵 리스트

일부 고빈도 거래 회사는 가격 수준을 키로 하는 해시 맵을 스킵 리스트나 유사한 정렬 구조와 결합해 사용합니다. 이렇게 하면 특정 가격 수준에 대한 O(1) 조회와 정렬된 순회에 대한 O(log n)을 얻을 수 있습니다.

장점: 기존 가격 수준에 주문을 추가하는 일반적인 경우에 번개처럼 빠름.

단점: 올바르게 구현하기가 더 복잡. 스킵 리스트 컴포넌트는 여전히 새 가격 수준에 대해 O(log n) 삽입.

결론: 프로파일링 결과 대부분의 주문이 기존 가격 수준에 들어온다고 나타난다면 고려할 가치가 있습니다(거래가 활발한 페어에서는 실제로 그렇습니다).

실제 하이브리드

대부분의 진지한 구현이 실제로 어떻게 생겼는지 보여 드리겠습니다. 가격 수준 인덱스를 위한 균형 BST가 있고, 각 가격 수준에는 개별 주문의 이중 연결 리스트(FIFO 큐)가 있습니다. 또한 주문 ID에서 주문 노드로의 해시 맵을 유지하여, 취소가 O(1) 조회와 연결 리스트에서의 O(1) 제거로 이루어지게 합니다.

주문 취소를 위한 이 해시 맵이 매우 중요합니다. 활발한 거래소라면 취소 거래량이 보통 거래 체결 거래량의 10~50배입니다. 마켓 메이커들은 끊임없이 주문을 넣고 취소합니다. 취소 경로가 느리면 전체 엔진이 느려집니다.

가격-시간 우선 원칙: 공정성 약속

가격-시간 우선 원칙, 즉 FIFO 매칭이라고도 불리는 이것은 사실상 모든 정상적인 거래소에서 사용하는 표준 알고리즘입니다. 규칙은 간단합니다.

1. 주문은 먼저 가격으로 우선순위가 정해집니다. $50,001의 매수 주문이 $50,000의 매수 주문보다 먼저 체결됩니다.
2. 같은 가격 수준에서는 시간으로 우선순위가 정해집니다. 먼저 도착한 주문이 먼저 체결됩니다.

당연해 보이지만, 이것은 심오한 의미를 갖습니다. 가격-시간 우선 원칙은 근본적으로 공정성 보장입니다. 특정 가격에 주문을 먼저 넣었다면, 나중에 같은 가격을 제출해 대기열을 뛰어넘을 수 있는 사람은 아묵도 없다는 뜻입니다. 대기열에서 여러분의 위치는 여러분의 자산입니다.

이것이 왜 그렇게 중요할까요? 엄격한 가격-시간 우선 원칙이 없으면 온갖 조작 행위에 문을 열어 주기 때문입니다. 거래소 운영자가 이론적으로 특정 마켓 메이커에 유리하도록 대기열을 재정렬할 수 있습니다. 더 빠른 연결을 가진 트레이더가 주문을 취소하고 다시 넣어 앞으로 뛰어넘을 수 있습니다. 이것은 가상의 시나리오가 아닙니다. 실제로 부정직한 거래소에서 일어난 일이며, 규제 당국이 매칭 엔진 공정성에 신경 쓰는 정확한 이유입니다.

일부 거래소는 대체 우선순위 방식을 실험해 왔습니다. 일부 선물 시장에서 사용되는 비례 배분(pro-rata) 매칭은 한 가격 수준의 체결을 모든 대기 주문에 비례적으로 분배하며, 크기-시간 우선 방식은 더 큰 주문에 우선권을 줍니다. 하지만 표준 현물 거래소에서는 가격-시간 FIFO가 표준이며, 이에서 벗어나려면 매우 타당한 이유와 트레이더에 대한 명확한 공시가 필요합니다.

사람들이 걸려 넘어지는 구현 세부 사항: 타임스탬프 해상도가 중요합니다. 클럭 해상도가 밀리초에 불과하면, 같은 밀리초 안에 도착한 두 주문은 임의의 순서를 갖게 됩니다. 프로덕션 엔진은 마이크로초 또는 나노초 타임스탬프를 사용합니다. 그리고 타임스탬프는 주문이 API 게이트웨이에 도착한 시점이 아니라, 매칭 엔진의 처리 큐에 들어가는 순간에 부여되어야 합니다.

지연 시간과 처리량: “빠르다”의 실제 의미

사람들은 맥락 없이 매칭 엔진의 성능 수치를 떠들어 대곤 합니다. 그래서 실제 벤치마크를 제시해 드리겠습니다.

티어 1 거래소(Binance, Coinbase, Kraken): 이 엔진들은 개별 주문을 한 자릿수 마이크로초에 처리합니다. 공표된 수치는 일반적으로 거래 쌍당 초당 100,000건 이상의 주문, 5마이크로초 미만의 매칭 지연 시간을 주장합니다. 이 수준에서는 C++이나 Rust로 작성하고, 락 프리 자료구조를 사용하며, 스레드를 CPU 코어에 고정하고, 커널의 네트워크 스택을 우회합니다.

티어 2 거래소(중견 규모, 자리 잡은 곳): 50500마이크로초 범위의 주문 처리. 초당 10,00050,000건의 처리량. 보통 Java, Go, C++로 작성됩니다. 대부분의 정상적인 거래소가 이 영역에서 운영되며, 솔직히 말해 대부분의 사용 사례에는 충분하고도 남습니다.

티어 3 거래소(스타트업, 소규모 플랫폼): 110밀리초 범위의 처리. 초당 1,00010,000건의 처리량. 흔히 Python, PHP, Node.js, Java로 작성됩니다. 일일 거래량이 1,000만 달러 미만인 거래소에는 완벽하게 적합합니다.

아묵도 큰 소리로 말하고 싶어 하지 않는 사실은 이것입니다: 새 거래소의 95%에게 티어 3 성능은 전혀 문제가 없습니다. 거래소가 하루에 1,000건의 거래를 처리한다면(이는 매우 건강한 런칭입니다), 평균적으로 초당 약 0.01건의 주문 처리량이 필요합니다. 평균의 100배인 피크 버스트를 고려해�도 초당 1건 정도의 주문이면 됩니다. 단일 코어에서 실행되는 Python으로 작성된 매칭 엔진도 이를 식은 죽 먹기로 처리할 수 있습니다.

성능 문제는 런칭 당일의 문제가 아닙니다. 성장했을 때 어떤 일이 일어나느냐의 문제입니다. 엔진이 전면 재작성 없이 초당 1,000건에서 100,000건으로 확장될 수 있을까요? 그것이 실제로 중요한 아키텍처 질문입니다.

이것이 검증된 거래소 소프트웨어를 선택하는 것이 중요한 큰 이유 중 하나입니다. Codono 암호화폐 거래소 플랫폼에는 이미 프로덕션 규모에서 부하 테스트를 거친 매칭 엔진이 포함되어 있어, 여러분의 직접 구현이 첫 트래픽 급증에서 살아남을지 도박할 필요가 없습니다. 그리고 거래소 스크립트가 완전히 암호화되지 않았기 때문에, 여러분의 팀이 매칭 로직을 직접 검토하고 튜닝할 수 있습니다.

주문 유형: 보기보다 복잡하다

지정가 주문과 시장가 주문은 간단합니다. 하지만 스탑 주문을 추가하는 순간 상황이 흥미로워지고, OCO(one-cancels-other) 주문을 추가하면 상태 관리 복잡도가 대략 두 배가 됩니다.

지정가 주문

가장 기본적인 유형입니다. “1 BTC를 $49,500 이하로 매수.” 주문은 체결되거나, 취소되거나, 만료될 때까지 오더북에 대기합니다. 구현은 간단합니다. 검증하고, 반대편과 매칭을 시도하고, 체결되지 않은 수량을 대기 상태로 둡니다.

시장가 주문

“현재 가격이 얼마든 1 BTC를 매수.” 주문은 오더북 반대편을 순회하며, 완전히 체결되거나 유동성이 더 이상 없을 때까지 가격 수준을 뚫고 지나갑니다. 중요한 구현 세부 사항: 가격 보호 메커니즘이 필요합니다. 유동성이 얇은 오더북에서 시장가 매수가 누군가 장난으로 걸어 둔 $999,999의 매도 주문에 체결되어서는 안 됩니다. 대부분의 엔진은 최대 슬리피지 파라미터나 마지막 체결가 대비 백분율 편차에 기반한 암묵적 지정가를 구현합니다.

스탑 로스 및 스탑 리밋 주문

매칭 엔진이 진정으로 까다로워지는 부분입니다. 스탑 주문은 조걶� 주문입니다: “시장 가격이 $48,000에 도달하면 시장가 매도 주문을 제출.” 스탑 주문 자체는 보이는 오더북에 올라가지 않습니다. 별도의 자료구조인 스탑 북(stop book)에 앉아 있다가 스탑 가격 이상에서 거래가 체결되면 트리거됩니다.

까다로운 부분은 연쇄 스탑(cascading stops)입니다. $48,000의 거래가 스탑 매도를 트리거하고, 그 스탑 매도의 체결이 가격을 $47,500까지 밀어 내리고, 그것이 더 많은 스탑을 트리거하고, 그것이 가격을 더 밀어 내리면… 밀리초 안에 오더북을 고갈시키는 연쇄가 발생할 수 있습니다. 이것은 실제로 역사적인 여러 플래시 크래시 동안 일어난 일입니다. 엔진에는 서킷 브레이커가 필요합니다. 시간 창당 최대 가격 변동, 최소 오더북 깊이 점검, 그리고 상황이 엉망이 되면 매칭을 일시 중지할 수 있는 기능이 필요합니다.

OCO(One-Cancels-Other) 주문

OCO는 두 주문을 함께 연결합니다. 일반적으로 이익 실현 지정가 주문과 스탑 로스입니다. 둘 중 하나가 체결되면 다른 하나가 자동으로 취소됩니다. 이를 위해서는 주문 간의 관계 그래프를 유지해야 하며, 취소가 체결과 원자적으로 일어나야 합니다. 스탑 로스가 트리거되어 체결됐는데 이익 실현 취소가 몇 밀리초라도 지연되면, 두 주문이 모두 체결되어 트레이더가 원하지 않았던 포지션을 갖게 될 수 있습니다.

Codono의 엔진은 이러한 고급 주문 유형을 네이티브로 처리하며, 또 다른 복잡성 계층을 추가하는 reduce-only 및 post-only 주문 같은 선물 거래 주문 유형도 지원합니다.

거래소를 망가뜨릴 엣지 케이스들

이 섹션은 매칭 엔진을 실제로 출시해 본 엔지니어와 그에 대해 읽어 본 엔지니어를 구분합니다. 실제 프로덕션 사고를 일으킨 엣지 케이스들은 다음과 같습니다.

셀프 트레이드 방지(STP)

트레이더가 $50,000에 대기 중인 매도 주문을 갖고 있는데 $50,000에 매수 주문을 제출하면 어떻게 될까요? STP가 없으면 트레이더는 자기 자신과 거래하게 됩니다. 경제적 목적 없이 양쪽 수수료를 내는 것입니다. 마켓 메이커들은 알고리즘이 여러 전략을 동시에 실행할 때 늘 우발적으로 이런 일을 겪습니다.

STP 정책이 필요합니다. 일반적인 세 가지 옵션:

• 최신 주문 취소: 셀프 트레이드가 될 들어온 주문을 취소.
• 최초 주문 취소: 대기 중인 주문을 취소하고 들어온 주문은 매칭을 계속.
• 양쪽 모두 취소: 두 주문 모두 취소.

대부분의 거래소는 기본적으로 최신 주문 취소를 사용하지만, 트레이더별로 설정 가능하게 해야 합니다. 마켓 메이커들은 이에 대해 강한 의견을 갖고 있습니다.

더스트 주문

0.00000001 BTC 주문은 어떻게 처리할까요? 0.000000003 BTC의 잔여 체결은요? 이런 더스트 금액은 거래하기에도, 출금하기에도 너무 작지만 오더북과 데이터베이스를 어지럽힙니다.

최소 주문 수량, 최소 명목 가치(가격 곱하기 수량이 일반적으로 몇 달러 정도의 임곗값을 초과해야 함), 그리고 최소치 미만 잔고를 주기적으로 정리하는 더스트 수집 메커니즘이 필요합니다.

틱 크기 및 로트 크기 강제

가격은 틱 크기의 배수여야 합니다(예: BTC/USDT는 $0.01). 수량은 로트 크기의 배수여야 합니다(예: 0.00001 BTC). 이를 매칭 엔진 수준에서 강제하지 않으면, $50,000.003 같은 가격의 주문이 생겨 다른 어떤 주문과도 맞지 않은 채 오더북에 영원히 남습니다. 더 나쁜 것은 소수점 정밀도 문제로 잔고 불일치가 발생한다는 것입니다.

오버플로와 정밀도

이것은 다른 어떤 것보다 많은 거래소를 물어뜯은 문제입니다. 가격과 수량에 부동소수점 연산을 사용하고 있다면, 지금 당장 멈추십시오. 부동소수점 연산은 수백만 건의 거래에 걸쳐 실제 잔고 불일치로 누적되는 반올림 오류를 만들어 냅니다. 프로덕션 매칭 엔진은 고정소수점 정수 연산($50,000.00을 정수 5000000으로 표현) 또는 임의 정밀도 소수 라이브러리를 사용해야 합니다. 세 번째 선택지는 없습니다.

매칭 후 잔고 점검

사전 거래 잔고 검증이 있더라도 사후 거래 잔고 단언(assertion)이 필요합니다. 모든 거래 체결 후, 모든 사용자 잔고의 합에 거래소 수수료를 더한 것이 예상 총액과 일치하는지 확인하십시오. 이 불변 조건이 깨지면 매칭을 중단하고 조사하십시오. 이것이 그렇지 않으면 사용자 자금을 서서히 고갈시킬 버그에 대한 마지막 방어선입니다.

확장 전략: 단일 스레드의 딜레마

매칭 엔진이 거래 쌍당 거의 항상 단일 스레드라고 말한 것을 기억하시나요? 이것은 명백한 확장 문제를 만듭니다. 최신 하드웨어의 단일 스레드는 초당 대략 100,000~500,000건의 단순 연산을 처리할 수 있습니다. 대부분의 거래소에는 충분합니다. 하지만 그렇지 않다면요?

수직 확장

더 빠른 하드웨어를 투입합니다. 더 높은 클럭 속도의 CPU, 더 많은 L3 캐시, 더 빠른 메모리. 이것이 첫 번째로 시도할 것이며 종종 충분합니다. 최신 고빈도 거래 엔진은 기본 매칭 연산을 위해 CPU를 완전히 우회하는 FPGA 기반 네트워크 카드를 탑재한 맞춤형 하드웨어에서 실행됩니다. 하지만 일반적인 거래소라면 5GHz 이상 프로세서와 128GB RAM을 갖춘 튼튼한 서버가 엄청난 거래량을 처리할 것입니다.

거래 쌍별 수평 확장

가장 간단한 수평 확장 전략은 거래 쌍당 하나의 매칭 엔진 인스턴스를 실행하는 것입니다. BTC/USDT는 자체 엔진을 갖습니다. ETH/USDT는 자체 엔진을 갖습니다. 완전히 독립적입니다. 공유 상태도, 조정도 필요 없습니다. 거래 쌍 수에 따라 선형으로 확장됩니다.

과제는 잔고 관리입니다. 트레이더가 10 BTC를 갖고 5개의 BTC 거래 쌍에 주문을 넣으면, 각 매칭 엔진이 가용 잔고를 알아야 합니다. 표준 접근법은 각 엔진이 주문을 수락하기 전에 확인하는 중앙 잔고 서비스입니다. 이 잔고 서비스가 새로운 병목이 되지만, 복잡한 매칭 로직이 아니라 단순한 읽기-쓰기 연산을 수행하므로 확장이 훨씬 간단합니다.

거래 쌍 내 샤딩

거래량이 가장 많은 페어의 경우 오더북 자체를 샤딩해야 할 수도 있습니다. 한 가지 접근법은 가격 범위별 샤딩입니다. 하나의 엔진이 $49,000~$50,000의 가격을 처리하고, 다른 엔진이 $50,000~$51,000을 처리합니다. 하지만 크로스 샤드 매칭(가격 범위를 넘나드는 시장가 주문)은 엄청나게 복잡합니다.

솔직히 말해서요? Binance 수준의 거래량을 처리하지 않는 한 이것은 필요 없습니다. 그리고 Binance 수준의 거래량을 처리하고 있다면, 먼저 처리해야 할 더 큰 아키텍처 과제가 있습니다.

대부분의 거래소 운영자에게 현명한 방법은 단일 페어의 매칭 엔진을 샤딩하려고 시도하는 대신 유동성 애그리게이션으로 오더북 깊이를 보강하는 것입니다.

메모리 대 디스크: 영속성 문제

매칭 엔진의 오더북은 메모리에 존재합니다. 그래야만 합니다. 디스크 I/O는 실시간 매칭에 전혀 용납할 수 없는 밀리초 단위의 지연을 추가합니다. 하지만 엔진이 크래시되면 어떻게 될까요? 모든 대기 주문을 그냥 잃을 수는 없습니다.

표준 아키텍처는 세 개의 계층을 사용합니다.

계층 1: 인메모리 오더북. 이것이 핫 패스입니다. 모든 매칭이 여기서 일어납니다. 정상 작동 중 디스크 I/O는 0입니다.

계층 2: 쓰기 전 로그(WAL). 들어오는 모든 주문과 모든 매칭 이벤트는 엔진이 처리하기 전에 디스크의 순차 로그에 추가됩니다. 엔진이 크래시되면 마지막 체크포인트부터 로그를 리플레이하여 오더북을 재구성합니다. 순차 쓰기는 빠릅니다. NVMe 드라이브는 초당 500,000건 이상의 순차 쓰기 연산을 유지할 수 있으며, 이는 충분하고도 남습니다.

계층 3: 주기적 스냅샷. N초마다(또는 N개 이벤트마다) 엔진이 오더북의 전체 스냅샷을 디스크에 씁니다. 이는 크래시 후 WAL을 얼마나 과거까지 리플레이해야 하는지를 제한합니다. 스냅샷이 없으면 24시간 작동 후의 크래시는 수백만 개의 이벤트 리플레이를 요구할 수 있습니다.

WAL이 핵심입니다. 지연 시간을 희생하지 않고 내구성을 제공합니다. 트레이드오프는 디스크에 비동기적으로 쓴다는 것입니다. 거래가 메모리에서 매칭되는 시점과 디스크에 영속되는 시점 사이에 아주 작은 창(마이크로초)이 있습니다. 정확히 그 창에 머신이 전원을 잃으면 그 이벤트들을 잃습니다. 대부분의 거래소에서는 이 위험이 수용 가능합니다. 절대적인 무손실 보장이 필요한 곳은 거래를 승인하기 전에 대기 머신에 대한 동기 복제를 추가합니다.

Codono는 이 모든 것을 어떻게 처리하는가

매칭 엔진을 처음부터 구축한다는 것은 위에서 설명한 모든 문제를 해결한다는 뜻입니다. 자료구조, 우선순위 로직, 엣지 케이스, 영속성, 확장까지 전부요. 그리고 시장은 진화하고 새로운 주문 유형이 등장하기 때문에 영원히 유지보수해야 합니다.

이것이 바로 우리가 Codono의 트레이딩 엔진을 이런 방식으로 구축한 정확한 이유입니다. Codono 거래소 소프트웨어에는 다음을 처리하는 프로덕션급 매칭 엔진이 포함되어 있습니다.

• 마이크로초 타임스탬프 해상도를 갖춘 가격-시간 우선 FIFO 매칭
• 지정가, 시장가, 스탑 로스, 스탑 리밋, OCO를 포함한 모든 표준 주문 유형
• API 키별 설정 가능한 정책을 갖춘 셀프 트레이드 방지
• 전체 거래 파이프라인에 걸친 고정소수점 연산 — 잔고 계산 근처 어디에도 부동소수점 없음
• 자동 체크포인트 및 복구를 갖춘 쓰기 전 로깅
• 거래 쌍별 독립 엔진 인스턴스를 통한 수평 확장
• 플래시 크래시 보호를 위한 내장 서킷 브레이커

엔진은 우리의 유동성 엔진과도 직접 통합되어, 유기적 오더북이 얇더라도 들어오는 주문이 집계된 외부 유동성과 매칭될 수 있습니다. 이는 유기적 유동성을 구축하는 데 시간이 걸리는 새 거래소에 특히 중요합니다.

프로그래매틱 접근이 필요한 운영자를 위해, API 레이어는 오더북 업데이트와 거래 체결 보고를 위한 저지연 WebSocket 피드를 제공하여 마켓 메이커가 엔진과 효율적으로 상호작용할 수 있게 합니다.

결론

매칭 엔진은 개념적으로는 기만할 정도로 단순하고 실행에서는 잔인할 정도로 어렵습니다. 핵심 알고리즘은 머릿속에 들어갑니다. 하지만 프로덕션 관심사(영속성, 복구, 공정성, 정밀도, 엣지 케이스, 부하 상태의 성능)는 수년의 엔지니어링 노력을 나타냅니다.

제 솔직한 조언: 매칭 엔진 개발이 여러분의 핵심 역량이자 경쟁 우위가 아니라면, 처음부터 만들지 마십시오. 실전 검증된 소프트웨어를 사용하고, 실제로 거래소를 차별화하는 것들(사용자 경험, 코인 상장, 규제 준수, 마케팅)에 엔지니어링 리소스를 집중하십시오. 매칭 엔진은 런웨이를 소모하는 과학 프로젝트가 아니라, 배포하면 끝나는 이미 해결된 문제여야 합니다.

성공하는 거래소는 가장 화려한 매칭 엔진을 가진 곳이 아닙니다. 현명한 구축 대 구매 결정을 내리고, 빠르게 출시하고, 사용자에게 중요한 것을 반복 개선한 곳입니다. 매칭 엔진은 정확하고, 충분히 빠르고, 신뢰할 수 있어야 합니다. 예술 작품일 필요는 없습니다. 작동하면 됩니다.

---

Codono의 매칭 엔진은 가격-시간 우선 원칙, 내장 서킷 브레이커, 유동성 애그리게이션으로 초당 수천 건의 주문을 처리합니다. 현물 거래소 기능 페이지를 보거나 데모를 요청하여 직접 테스트해 보십시오.