퀴즈: 주문의 생애주기와 시계

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 주문 이벤트를 재생할 때 cancel_req 가 상태를 바꾸지 않아야 하는 이유는?

   1. 취소 요청은 거래소에 도달하지 않을 수도 있어 신뢰할 수 없기 때문에
   2. 요청을 보낸 것과 취소가 확정된 것은 다른 사실이고, 요청 뒤에 체결이 붙을 수 있기 때문에
   3. cancel_req 이벤트에는 수량 정보가 없어 상태를 계산할 수 없기 때문에
   4. 거래소가 cancel_req 를 로그에만 남기고 처리하지 않기 때문에

2. 거래소 시각으로 재생하면 취소, 수신 시각으로 재생하면 체결로 나오는 주문이 40건 있다. 사후 재구성과 분쟁 대응의 근거로 삼아야 할 것은?

   1. 수신 시각. 우리 시스템이 실제로 그렇게 처리했기 때문에
   2. 두 시각의 평균. 어느 한쪽에 치우치지 않기 때문에
   3. 거래소 시각. 시장에서 실제로 일어난 일의 순서이고 규정도 그것을 기준으로 쓰기 때문에
   4. 애플리케이션 처리 시각. 최종적으로 상태를 확정한 시점이기 때문에

3. 같은 exec_id 를 가진 체결 이벤트가 두 번 들어왔다. 올바른 해석은?

   1. 거래소 장애 신호이므로 즉시 세션을 끊고 재접속해야 한다
   2. 체결이 실제로 두 번 일어난 것이므로 수량을 두 번 더해야 한다
   3. 재전송이나 세션 복구에서 흔히 일어나는 정상 동작이고, 거르는 것은 받는 쪽 책임이다
   4. 우리 로그 저장 과정의 버그이므로 로그를 다시 받아야 한다

4. 중복 체결을 찾을 때 '누적 체결이 주문 수량을 넘긴 주문' 만 세면 무엇을 놓치는가?

   1. 부분체결로 끝난 주문에서 부풀었지만 주문 수량을 넘지 않은 건들. 아무 경보도 울리지 않는다
   2. 정정으로 수량이 늘어난 주문. 초과 판정 기준이 달라진다
   3. 거부된 주문에 붙은 체결. 상태가 rejected 라 집계에서 빠진다
   4. 가격이 다른 두 체결. 수량은 같아도 금액이 어긋난다

5. 재생이 끝난 뒤 '누적 체결이 주문 수량 이상이면 상태는 filled' 라는 규칙을 넣는 근거로 가장 적절한 것은?

   1. 체결이 취소보다 더 자주 일어나므로 통계적으로 유리하기 때문에
   2. 체결은 되돌릴 수 없는 사실이고 취소는 잔량에만 적용되므로, 잔량이 0이면 취소가 체결을 지울 수 없기 때문에
   3. 거래소가 체결 이벤트를 취소 이벤트보다 먼저 보내도록 규정하고 있기 때문에
   4. 상태 필드를 filled 로 두면 정산 배치가 오류를 내지 않기 때문에

6. OMS 상태 필드와 재구성 결과를 대조했더니 상태가 다른 것이 27건, 체결 수량까지 보면 67건이었다. 이 40건의 차이가 뜻하는 것은?

   1. 대조 기준일이 달라 생긴 시차이므로 같은 시점으로 맞추면 사라진다
   2. 재구성 코드의 반올림 오차이므로 허용 오차를 두어야 한다
   3. 상태 문자열은 우연히 같지만 체결 수량이 빠져 있는 주문들. 상태만 보는 대조로는 영원히 드러나지 않는다
   4. OMS 가 아직 처리 중인 주문들이므로 조금 뒤에 다시 세면 맞는다

7. 실시간 처리기가 낸 상태와 사후 재구성이 낸 상태가 다를 때 가장 현실적인 운영 방침은?

   1. 실시간 처리기를 거래소 시각으로 정렬하도록 바꿔 두 결과를 항상 일치시킨다
   2. 사후 재구성 결과를 정본으로 두고 실시간 결과를 그것으로 보정하는 절차를 만든다
   3. 두 결과가 다르면 그 주문을 보류 상태로 두고 담당자가 매번 판단한다
   4. 실시간 결과를 정본으로 두고 사후 재구성은 참고 지표로만 쓴다