해외선물솔루션 종목 정보 검수: 틱 크기·승수·가격 정밀도

MES 한 계약의 가격이 한 틱 움직였는데 화면에는 12.50달러가 표시된다고 가정해 보겠습니다. 주문은 정상 접수됐고 차트도 멈추지 않았습니다. 그런데 계산에 ES의 계약 승수를 가져다 썼다면, 연결 상태가 아무리 정상이어도 금액은 잘못된 것입니다.

해외선물솔루션 검수에서 종목 정보는 화면에 붙이는 이름표가 아닙니다. 어떤 계약에 어떤 가격으로 주문하는지, 한 번의 가격 변화가 얼마인지 결정하는 기준 데이터입니다. 이 글에서는 틱 크기, 계약 승수, 가격 표현을 구분하고 개발사에 재현을 요청할 시험 항목을 정리합니다. 특정 고객의 장애 기록이 아니라 공식 규격을 바탕으로 만든 가상 검수 사례입니다.

1. ‘S&P 500’이라는 화면 이름만으로 주문하지 않습니다

상품을 소개할 때는 짧은 이름이 편합니다. 주문을 전송할 때는 부족합니다. ES와 MES를 구분해야 하고, 같은 상품도 월물이 다르면 별도 계약으로 다뤄야 합니다. 거래소와 연동사의 종목 식별 체계까지 확인해야 화면의 선택이 다른 계약으로 바뀌지 않습니다. 기본적인 상품·만기 개념은 해외선물 시장 구조와 상품 단위 안내를 먼저 참고할 수 있습니다.

예를 들어 차트에서 ‘최근월물’이라는 표시용 별칭을 제공하더라도, 주문 확인 단계에서는 실제 전송할 계약과 월물을 확정해 보여주는 편이 좋습니다. 다음 월물로 차트가 전환됐다는 이유로 기존 미체결 주문의 식별자까지 바뀌어서는 안 됩니다. 이 동작은 실제 상품을 주문하지 않는 시험 환경에서 확인해야 합니다.

CME MDP 3.0의 선물 종목 정의 문서도 종목 식별자, 월물, 최소 가격 간격, 가격 표시 변환 정보를 별도 항목으로 설명합니다. 식별자의 재사용 조건도 있으므로 번호 하나를 영구적으로 같은 계약이라고 가정하면 안 됩니다. 다만 이 문서는 CME의 특정 시세 프로토콜 기준이며, 이용하는 증권사·중계 API의 필드와 일대일로 같다는 뜻은 아닙니다.

내부 종목 정보에는 적어도 연동 출처와 식별자, 거래소, 상품 구분, 월물, 가격 단위, 호가 규칙, 금액 계산 단위, 적용 시점과 버전을 함께 남기는 설계를 검토하세요. 과거 체결 기록은 당시 계약을 추적할 수 있어야 합니다. 주문 상태 관리까지 이어지는 흐름은 OMS의 주문·체결 처리 구조와 연결해서 보는 것이 좋습니다.

2. 같은 0.25포인트여도 한 틱의 금액은 다릅니다

다음 표는 CME 규정의 단일 월물 선물 일반 호가를 비교한 것입니다. ES와 MES는 예시이며, 이 사이트가 해당 상품의 중개나 데이터 제공 권한을 보유한다는 표시가 아닙니다.

작은 화면에서는 표를 좌우로 이동해 확인할 수 있습니다.

근거는 CME 규정 358장 35801·35802.C와 353장 35301·35302.C입니다. 두 규정 모두 월물 간 스프레드에는 별도의 호가 간격을 명시합니다. 따라서 위의 0.25를 옵션, 스프레드, 다른 거래 방식까지 공통값으로 저장하면 안 됩니다. 실제 적용 전에는 최신 규격과 연동 경로의 규칙을 다시 확인하세요.

가상 가격이 6,000.00에서 6,000.25로 변한 경우, 한 계약의 가격 변화에 해당하는 금액은 0.25 × 50 = 12.50 USD와 0.25 × 5 = 1.25 USD로 나뉩니다. 호가창의 가격만 비교하면 둘 다 맞아 보이지만, 승수를 바꾸어 넣으면 금액이 열 배 달라집니다. 이 계산은 단위 검증용이며 현재 시세, 실제 체결 결과나 수수료·환전·증거금을 반영한 손익이 아닙니다.

여기서 ‘승수’는 가격 1포인트를 한 계약의 금액으로 바꾸는 계수입니다. 외부 API에 ContractMultiplier라는 이름의 항목이 있다고 해서 문서 확인 없이 그대로 이 계수에 넣지 마세요. 상품과 프로토콜에 따라 필드의 정의·단위가 다를 수 있으므로 실제 예시 값으로 계산을 대조해야 합니다.

3. 소수점 두 자리면 유효한 주문 가격일까요?

0.25 간격을 쓰는 위 예시에서 6000.10은 소수점 두 자리지만 유효한 일반 호가가 아닙니다. 반대로 소수점 표시를 두 자리로 맞추었다고 모든 값이 0.25의 배수가 되는 것도 아닙니다. 표시 자릿수, 입력 정밀도, 허용 호가 간격을 각각 검사해야 합니다.

DB에 넣은 다음 검사하면 원래 입력을 잃을 수 있습니다

가상 입력 6000.251을 먼저 소수점 두 자리로 반올림하면 6000.25가 됩니다. 저장된 값만 검사하면 정상처럼 보이지만 입력자가 보낸 가격은 바뀌었습니다. 예를 들어 PostgreSQL 18의 숫자 자료형 문서는 지정한 소수 자릿수를 초과하는 값을 numeric(p,s)에 저장할 때 반올림한다고 설명합니다. 정확한 십진 자료형을 골랐다는 사실만으로 업무 입력 검증이 끝나지는 않습니다.

주문 접수 경계에서 원래 값을 정확하게 해석하고 허용 규칙을 검사한 다음 저장하세요. 맞지 않는 가격을 조용히 반올림해 전송하기보다, 이유를 알려 사용자가 다시 확인하도록 하는 것이 이 검수안의 기준입니다. 가격 보정 기능을 별도로 제공한다면 바뀐 가격과 확인 절차가 명확해야 합니다. 관련 화면 항목은 주문 입력 실수를 줄이는 UX 검토와 함께 확인할 수 있습니다.

정수 스케일을 쓰더라도 단위 약속이 먼저입니다

설명용으로 가격을 100배 한 정수 단위로 표현하고 틱 간격을 25로 두면, 다음처럼 나머지로 검사할 수 있습니다. 이는 0을 기준으로 한 고정 0.25 간격의 예시일 뿐, 모든 선물 상품의 검증식이 아닙니다.

가격 6000.25 → 정수 표현 600025
틱  0.25    → 정수 표현     25
600025 ÷ 25 → 나머지 0  : 간격 조건 충족
6000.10    → 600010 ÷ 25 → 나머지 10 : 불충족
6000.251   → 반올림하지 않고 입력 규칙 위반 처리

원문 문자열을 읽는 단계부터 십진수 또는 정수 변환 규칙을 정해야 합니다. 먼저 이진 부동소수점으로 바꾼 뒤 100을 곱하는 방식은 정수 설계와 같지 않습니다. 0.25 자체는 이진수로 정확히 표현할 수 있지만, 다른 가격 간격이나 중간 연산까지 모두 그렇다는 뜻은 아닙니다. 정확도 외에도 저장 범위, 곱셈 시 넘침, 전송 형식과 다시 읽었을 때의 값 일치를 시험해야 합니다.

가격 구간에 따라 간격이 바뀌는 상품, 분수 호가나 별도 스프레드 규칙은 해당 정의에 맞는 검증기가 필요합니다. 또한 틱 조건 통과는 가격 제한, 거래 상태, 주문 권한과 위험 한도까지 통과했다는 뜻이 아닙니다.

4. 시세와 주문이 같은 숫자를 다르게 해석하지 않는지 봅니다

화면 가격, 내부 저장 가격, 시세 수신 값과 주문 전송 값의 단위는 서로 같을 수도 있고 다를 수도 있습니다. 따라서 ‘가격’이라는 이름만 맞추지 말고 어느 경계에서 어떤 변환이 일어나는지 적어야 합니다.

가령 가상의 연동 규격이 원시 정수 600025를 받으면 0.01을 곱해 6000.25포인트로 해석하도록 정했다고 합시다. 이미 변환된 값에 다시 0.01을 곱하면 60.0025가 됩니다. 이 0.01은 가격 표현을 바꾸는 계수이지, ES의 50달러 또는 MES의 5달러와 같은 계약 금액 승수가 아닙니다. 이 숫자와 형식은 특정 CME·증권사 API의 실제 전송 예제가 아닙니다.

1. 원시 값과 해당 연동 규격의 단위를 함께 기록합니다.
2. 내부 기준 단위로 변환한 값이 원래 의미를 보존하는지 확인합니다.
3. UI의 표시, 주문 전송 값, 위험 계산에 쓰인 값이 같은 계약을 가리키는지 대조합니다.
4. 동일 시험 값을 바깥으로 보냈다가 다시 해석했을 때, 허용한 정밀도 내에서 원래 값으로 돌아오는지 확인합니다.

종목 정보가 갱신되는 순간도 시험 대상입니다. 화면은 이전 버전의 호가 간격을 보고 서버는 새 버전으로 검증한다면, 사용자는 입력값을 바꾸지 않았는데 주문이 거절될 수 있습니다. 적용 버전의 차이를 식별하고 갱신 안내를 보여주는지 확인하세요. 규칙을 모르는 상태에서 기본값으로 주문을 통과시키는 것은 피해야 합니다.

다만 신규 주문 차단과 기존 주문의 취소·조회는 같은 문제로 묶지 마세요. 설정 불일치가 발생해도 이미 존재하는 주문을 안전하게 조회·취소할 경로는 별도로 설계해야 합니다. 과거 기록은 새 설정으로 덮어 해석하지 않도록 당시 적용 정보도 남깁니다.

5. 평균 체결가에는 주문 가격과 같은 틱 검사를 걸지 않습니다

각각 한 계약씩 6000.00과 6000.25에 체결된 가상 기록의 수량 가중 평균은 6000.125입니다. 두 개별 체결가는 0.25 간격을 만족하지만 평균은 그렇지 않습니다. 평균값이 틱 격자에 없다는 이유만으로 체결 기록을 오류 처리하거나 강제로 주문 틱에 맞춰서는 안 됩니다.

입력 주문가, 개별 체결가, 평균 체결가, 평가 금액에는 각각의 의미와 정밀도 정책이 필요합니다. 화면에서 반올림해 보여주는 값과 내부 계산값도 구분해야 합니다. 합산·반올림 시점과 원장 대조는 백오피스 정산·리포트 검토 항목과 연결해서 확인할 수 있습니다.

아래 표는 공급사와 합의해 사용할 시험 제안입니다. 운영 주문으로 시험하라는 지시도, 당사 솔루션이 이미 통과했다는 결과표도 아닙니다. 대상 API·DB 버전과 모의 계약 정보를 정하고 실제 결과·로그를 별도로 남기세요.

0이나 음수 가격의 허용 여부는 상품과 주문 규칙에 따라 정해야 합니다. 모든 종목에 ‘양수만 허용’을 무조건 적용하는 것 역시 이 표의 취지가 아닙니다. 표의 합격 조건은 해당 연동 규격에 맞게 구체화해야 합니다.

종목 정보 검수표 CSV 내려받기
UTF-8 · 8개 시험 · 환경·결과·증빙·담당자 칸 포함. 실제 시험 결과는 비워 두었습니다.

6. 분양·임대 계약에서는 설정 파일보다 관리 범위를 묻습니다

‘종목 추가 가능’이라는 답변만으로는 누가 언제 규격을 갱신하고 어디까지 검증하는지 알 수 없습니다. 해외선물솔루션 분양이나 맞춤 개발을 검토한다면 종목 정보의 출처, 필드 정의, 단위 변환표, 적용 이력, 시험 데이터와 기대 결과를 인수 범위에 넣는 것이 좋습니다. 소스 권한과 배포 자료의 경계는 분양 라이선스·인수 검수 안내에서 함께 확인하세요.

해선솔루션 임대형이라면 직접 설정을 바꿀 수 있는지보다 공급사의 변경 책임과 통지 절차를 먼저 확인해야 할 수 있습니다. 새 월물·규격 변경 반영, 오류 정정, 과거 기록 조회와 계약 종료 후 자료 제공 범위를 물어보세요. 관련 계약 항목은 임대 계약 범위·데이터 이전 체크리스트에 연결됩니다.

• 기준 자료: 어느 거래소·연동사 문서의 어떤 버전을 기준으로 했는가?
• 계산 계약: 가격, 수량, 계약 승수와 통화의 단위를 누가 승인하는가?
• 변경 증빙: 적용 시점과 구·신 설정, 시험 입력·기대 결과를 다시 확인할 수 있는가?
• 예외 처리: 잘못된 입력을 무엇으로 거절하며, 취소·조회와 과거 기록은 어떻게 유지하는가?

데모에서 마지막으로 볼 것은 차트의 움직임만이 아닙니다. 같은 가격 변화가 다른 계약에서 정확한 단위로 계산되고, 틀린 가격은 조용히 고쳐지지 않는지 확인하세요. 이 두 가지를 재현 가능한 입력과 결과로 받아 두면 ‘지원한다’는 설명을 구체적인 검수 항목으로 바꿀 수 있습니다.