실행 프로토콜 — 노출 전 확인하는 일곱 게이트

1 / 왜 이런 생각이 들었나

2 / 사전 프로토콜 vs 사후 규칙 준수 점수

둘 다 둔다. 사전 점검을 건너뛴 거래의 높은 준수 점수는, 나쁜 노출을 막은 프로토콜과 같지 않다. 자동 체결 모니터(Isolation Forest execution monitor)는 또 다른 층이다 — 사람의 사전 점검이 아니라 체결의 기계 감시.

3 / 체크리스트가 할 수 있는 것과 없는 것

체크리스트는 챌린지–검증–응답으로 가장 강하다. 계획이 거래를 만들고, 체크리스트가 검증한다. 엣지를 증명하거나, 이벤트 결과를 예측하거나, 손절 체결을 보장하거나, 정신 건강을 진단하거나, 정의되지 않은 규칙을 구하지 못한다. 먼저 결정 체계를 만들고 — 그다음 검증한다.

4 / 일곱 게이트 (증거 + 실패 액션)

5 / 게이트 워크스루 (관찰 가능한 것만)

1 — 이야기가 아니라 셋업을 확인

저장된 셋업과 버전을 이름으로 부른다. 필수 조건을 관찰 데이터로 각각 확인한다. 규칙이 종가·리테스트·거래량·세션 필터를 요구하는데 “돌파처럼 보인다”면 실패다. 새 패턴은 라이브 준비가 될 때까지 연구에 둔다.

2 — 진입, 무효화, 실제 주문

트리거와 무효화 가격·조건을 적는다. 그다음 그 규칙을 표현하는 거래소 지시를 고른다. 손절 가격이 항상 보장 체결은 아니고, 지정가는 가격을 통제하지만 체결되지 않을 수 있다. 주문 이름은 브로커마다 다르다 — 거래소 문서를 확인한다. 불확실한 취소·교체는 다시 보내기 전에 맞춘다.

3 — 예산에서 리스크와 사이즈

원하는 수익이 아니라 허용된 계좌 리스크에서 시작한다. 진입–무효화, 틱/포인트 가치, 수수료, 방어 가능한 슬리피지·갭 여유에서 단위당 리스크를 추정한다.

로트/계약 최소, 증거금, FX 환산, 상관 노출을 확인한다. 한 단위만으로도 예산을 넘으면 유효 수량은 0이다. 체크리스트는 입력을 검증할 뿐, 만능 리스크 %를 고르지 않는다.

4 — 전략 자신의 맥락에서 페이오프

목표/청산 논리와, 추정 리스크 대비 순 보상을 확인한다. 승률·청산 분포·비용·상태와 떨어진 만능 보상/리스크 임계값을 끌어오지 않는다. 가격이 움직인 뒤에는 달성 가능한 진입으로 다시 계산한다 — 예쁜 차트가 깨진 규칙을 되돌리지 않는다.

5 — 타이밍, 유동성, 시장 상태

상품 개장, 전략이 허용한 세션, 데이터 최신, 스프레드/깊이가 실행 모델과 맞는지. 개인 시간 필터는 정의된 전략이나 태그된 일지 증거가 필요하다 — 특정 세션이 “최고”라는 민간 주장이 아니다.

6 — 예정 이벤트와 정확한 계좌 규칙

계획이 실제로 다루는 캘린더를 본다. 문서 규칙이 아니면 만능 “N분 전후 거래 금지”를 하드코딩하지 않는다. 펀딩·제한 계좌에서는 정확한 프로그램·단계·사이즈·일일/최대 손실 산식·일관성 규칙·보유 한도·금지 행위를 확인한다. 일반적인 프롭 소문은 증거가 아니다.

7 — 관찰 가능한 준비 상태

보이는 질문을 한다. 손실을 만회하려고 사이즈를 키우나? 새 셋업 없이 재진입하나? 전략이 정의하지 않은 카운트다운에 쫓기나? 일일 손절 뒤에도 거래하나? 직전 주문 체결이 불확실한가? 누군가의 콜 때문에 이탈하나? 하나라도 예 → 일시 정지·축소·조정·중단. 체크리스트는 프로세스 통제이지 의학적 평가가 아니다.

6 / 챌린지 → 검증 → 응답 → 행동

1. 챌린지 — 게이트를 적힌 그대로 읽는다.
2. 검증 — 차트·계좌·계산기·캘린더·플랫폼·계획 필드를 본다.
3. 응답 — 통과, 실패, 또는 미검증. 현재 상태를 볼 수 있는데 기억으로 답하지 않는다.
4. 행동 — 그 응답에 붙은 액션만.

만능 “몇 초”는 없다. 검증을 끝낼 만큼 길고 전략이 감당할 만큼 짧은 지연이면 충분하다. 셋업이 그 지연을 견디지 못하면 점검을 앞으로 당기거나 자동화한다 — 했다고 위장하지 않는다.

7 / 예외보다 먼저 오버라이드 정책

하드 계좌·리스크 한도는 미리 오버라이드 불가로 표시한다. 문서화된 예외는 권한 규칙·증거·담당·만료를 적는다. “이번만 특별히 좋아 보인다”는 예외가 아니다. 실패한 게이트와 시도된 오버라이드를 — 스킵한 거래 포함 — 모두 기록한다. 가상 손익을 체결처럼 채점하지 않는다.

8 / 스케치: 유효 셋업, 실패한 사전 점검

교육용일 뿐 — 계좌 주장이 아니다. 저장된 풀백이 버전 4와 맞음 (게이트 1 통과). 플랫폼 주문 유형은 스탑-리밋인데, 테스트한 전략은 스탑→마켓을 가정 (게이트 2 실패, 수정 전까지). 행동을 고친 뒤에도 최소 단위가 남은 일일 리스크를 초과 (게이트 3 실패; 수량 0). 타이밍은 통과; 정확한 계좌 일일 손실 상태가 여전히 차단 (게이트 6 실패). 사이즈를 만들기 위해 손절만 줄이려는 충동 (게이트 7 → 중단). 교훈: 유효 셋업 ≠ 지금 유효한 주문.

9 / 모든 답을 감사 가능하게

“통과”를 미리 채우지 않는다. 실패·통과 기록을 모두 남겨, 게이트가 프로세스를 지키는지 아니면 쓰이지 않는지만 나중에 알 수 있게 한다.

10 / 한 결과가 아니라 실패에서 교정

고정 주기와 중대 오류 뒤에 리뷰한다. 누락 응답·실패 게이트·오버라이드·중복 주문·사이즈 수정·이벤트 차단·주문/지시 불일치를 센다. 결과 지표는 프로세스 지표 옆에 두지, 대신하지 않는다. 나중에 “이겼을” 스킵은 결정 시점에 없던 결과 지식이다 — 게이트를 지울 이유가 되지 않는다.

전략·거래소·계좌 프로그램·플랫폼·주문 유형이 바뀌면 프로토콜을 버전한다. 시스템 주문에서는 수동 질문을 사전 검증 어서션으로 바꾸고, 데이터 신선도·노출·한도·미체결·연결·킬스위치 상태를 로그한다.

11 / 이 글이 붙잡는 것 vs 주장하지 않는 것

12 / 사이트 안에서 이어서 볼 곳