네트워크 불안정으로 브로커 프로그램 연결 창구(API)가 동일한 주문 상태 응답을 두 번 전송하면, 주문 상태 머신(OMS)이 이를 새로운 이벤트로 오인해 상태 전이를 반복 처리할 수 있습니다. 이 경우 주문이 이미 체결되었음에도 '주문 중' 상태로 돌아가거나, 취소된 주문이 다시 활성화되는 등 데이터 정합성이 무너집니다. 이 글은 멱등성 키(IDempotency Key)가 없을 때 발생하는 구조적 오류와, 응답 타임스탬프를 활용한 중복 제거 로직의 설계 방향을 개념적으로 설명합니다.
동일한 응답이 두 번 도달하면
브로커 서버가 클라이언트의 요청을 처리한 후, 네트워크 지연이나 타임아웃으로 인해 응답이 클라이언트에 도달하지 못했다고 판단하면 자동으로 재전송을 시도합니다. 이때 첫 번째 응답이 실제로는 클라이언트에 도달했으나 확인 응답을 보내지 못한 상황이라면, 클라이언트는 동일한 주문 식별자(ID)와 상태 값을 가진 응답을 두 번 받게 됩니다. OMS는 일반적으로 수신된 메시지를 순서대로 처리하므로, 두 번째 응답을 무시하지 않는 한 시스템 내부 상태가 비정상적으로 변경됩니다. 예를 들어 '체결 완료' 상태의 응답이 두 번 들어오면, OMS는 이를 두 번의 독립적인 체결 이벤트로 해석하거나, 상태 전이 규칙에 따라 허용되지 않는 상태로의 전이를 시도하게 됩니다.
상태 전이 오류가 발생하는 메커니즘
OMS는 주문의 라이프사이클을 상태 기계(State Machine)로 모델링합니다. '신규'에서 '수락', '부분 체결', '전체 체결', '취소' 등으로 상태가 전이되며, 각 전이는 특정 조건에서만 허용됩니다. 중복 응답이 처리되지 않으면, 이미 '전체 체결' 상태에 도달한 주문이 다시 '부분 체결' 상태로 되돌아가거나, '취소' 상태의 주문이 '수락' 상태로 전환되는 등 논리적으로 불가능한 전이가 발생합니다. 이러한 오류는 단순한 로그 기록 오류를 넘어, 실제 자산 잔고 계산이나 리스크 관리 시스템에 잘못된 데이터를 공급하는 원인이 됩니다. 특히 부분 체결된 주문의 경우, 중복된 '부분 체결' 응답이 누적되면 체결 수량이 실제보다 많아지는 오류가 발생하여 정산 과정에서 불일치가 생깁니다.
멱등성 키의 부재와 구조적 위험
멱등성 키는 동일한 요청이 여러 번 전송되어도 동일한 결과를 보장하는 식별자입니다. 주문 생성 시 클라이언트가 생성한 고유한 UUID(범용 고유 식별자)를 멱등성 키로 사용하면, 브로커 서버나 OMS는 이 키를 기준으로 이미 처리된 주문인지 여부를 확인할 수 있습니다. 멱등성 키가 부재하거나 OMS가 이를 검증하지 않는 구조에서는, 중복 응답을 식별할 수 있는 유일한 기준이 주문 ID와 상태 값의 조합이 됩니다. 그러나 상태 값만으로는 중복을 판별하기 어렵습니다. 예를 들어 '부분 체결' 상태의 응답이 두 번 와도, 두 번째 응답이 첫 번째와 동일한 내용인지, 아니면 추가 체결이 발생한 것인지 구분할 수 없습니다. 이 구조적 취약성은 네트워크 환경이 불안정할수록 그 위험이 기하급수적으로 커집니다.
중복 제거 로직의 설계 방향
중복 응답을 처리하기 위해서는 응답에 포함된 메타데이터를 활용해야 합니다. 주요 검증 요소는 주문 ID, 상태 변경 타임스탬프, 그리고 상태 변경 시퀀스 번호입니다. OMS는 각 주문에 대해 마지막으로 처리된 타임스탬프와 시퀀스 번호를 저장하고, 수신된 응답의 타임스탬프가 저장된 값보다 과거이거나 동일하면 해당 응답을 중복으로 판단하여 무시합니다. 시퀀스 번호가 증가하지 않는 응답도 중복으로 간주할 수 있습니다. 이 로직은 OMS의 메모리나 데이터베이스에 상태 추적 테이블을 유지해야 하므로, 성능 최적화와 데이터 일관성 유지 사이의 균형이 필요합니다. 또한, 타임스탬프의 정밀도(밀리초 또는 마이크로초)와 클라이언트-서버 간 시계 동기화 상태도 검증 정확도에 영향을 미칩니다.
| 검증 요소 | 역할 | 중복 판별 시 고려 사항 | 한계 |
|---|---|---|---|
| 주문 ID | 주문의 고유 식별 | 동일 ID의 응답이 반복 수신되는지 확인 | 상태 변경 이력을 구분하지 못함 |
| 타임스탬프 | 상태 변경 시점 | 저장된 최신 타임스탬프와 비교 | 시계 동기화 오류 시 판별 실패 가능 |
| 시퀀스 번호 | 상태 변경 순서 | 이전 시퀀스 번호와 비교하여 증가 여부 확인 | 브로커가 시퀀스를 제공하지 않을 경우 적용 불가 |
이 표는 중복 응답을 판별하기 위해 활용할 수 있는 메타데이터 요소와 그 한계를 정리한 것입니다. 단일 요소만으로는 중복을 완벽하게 식별하기 어렵기 때문에, 주문 ID와 타임스탬프, 시퀀스 번호를 조합하여 검증 로직을 설계하는 것이 일반적입니다. 특히 브로커 API가 시퀀스 번호를 제공하지 않는 경우, 타임스탬프의 정밀도와 시계 동기화 안정성이 검증 결과의 신뢰도를 결정하는 핵심 변수가 됩니다. 이 설계 방향은 실험 결과가 아닌, 분산 시스템에서 데이터 정합성을 유지하기 위한 일반적인 개념적 설명입니다. 실제 적용 시에는 사용 중인 브로커 API의 응답 구조와 네트워크 환경을 고려하여 구체적인 검증 규칙을 정의하고, 다양한 네트워크 장애 시나리오를 시뮬레이션하여 로직의 정확성을 테스트하는 과정이 필요합니다. 독자가 판단할 수 있는 점은, 중복 응답 처리가 OMS의 데이터 정합성에 직결된다는 것이며, 아직 판단할 수 없는 점은, 특정 브로커 환경에서 타임스탬프 기반 검증의 실제 오류율이나 성능 영향은 해당 시스템의 하드웨어 사양과 네트워크 조건에 따라 달라지기 때문에, 이 글의 개념만으로는 최적의 파라미터를 결정할 수 없다는 것입니다.
함께 보면 좋은 연구
고정 시간 간격 가정의 오류와 데이터 정렬 · 시계열 데이터 정렬 오류가 만드는 정보 누출 · 타임아웃 늘리기 vs 멱등성 키: 주문 정합성 확보법
이어서 볼 연구
데이터 정제 단계의 미세한 시간 불일치가 통계 검증에 미치는 영향
과거 데이터 검증(백테스트)에서 전략이 실제로 작동하는지 판단할 때, 데이터의 미세한 타임스탬프(Time Stamp) 정렬 오류는 결과의 신뢰도를 근본…
고정 슬리피지가 검증 결과를 왜곡하는 구조
주문 규모가 크거나 시장 변동성이 높은 순간, 실제 체결 가격은 예상과 크게 다를 수 있습니다. 그러나 많은 과거 데이터 검증(백테스트) 로직은 이…
백테스트 기간, 주말 포함 여부로 달라지는 이유
주요 거래소가 주말과 공휴일에 휴장한다는 사실은 잘 알려져 있지만, 과거 데이터 검증(백테스트) 시 이 기간을 어떻게 처리하느냐에 따라 검증 대…
본 사이트의 콘텐츠는 정보 및 연구 기록을 목적으로 하며 특정 금융상품의 매수·매도를 권유하지 않습니다. 투자 판단과 결과에 대한 책임은 투자자 본인에게 있습니다. 투자 고지 전문