MT4 EA 오류 130은 어떻게 점검해야 할까? 손절 거리에서 동적 제한까지의 4단계 방법

저자: 토마스｜EA와 MT4 실무｜2026년 10월 20일

EA를 이미 차트에 올리고 자동 거래도 켜 두었는데 주문 제출 시 "130"이 나타나면 보통 프로그램이 완전히 고장 났다고 오해하기 쉽습니다. MQL4 참고 문서는 130을 ERR_INVALID_STOPS로 분류합니다: 요청의 손절·이익실현, 대기 주문 가격 또는 그 정규화 방식이 거래 서버에서 허용되지 않았다는 뜻입니다. 이는 원인을 찾기 위한 단서이지, 손절을 무작정 완화해도 된다는 근거가 아닙니다. 이 글은 4단계 점검법으로 어떤 기록을 봐야 하는지 설명합니다.

1단계: 어느 요청이 실패했는지 먼저 확인

MT4 터미널 또는 프로그램의 관련 로그를 열어 오류가 발생한 서버 시간, 종목, 주문 방향, 작업이 OrderSend인지 OrderModify인지, 그리고 반환된 오류 코드를 기록합니다. 로그에 "주문 실패" 네 글자만 있다면, 먼저 EA가 비밀번호 등 민감한 데이터를 출력하지 않는 전제하에 요청 가격, 손절, 이익실현 및 반환값을 기록하도록 합니다. 먼저 포지션 개설 실패, 손절 수정 실패, 대기 주문 실패를 구분해야 합니다. 세 가지는 점검해야 할 가격 관계가 다릅니다.

실계좌에서 동일한 실패 요청을 반복 전송하며 "운에 맡기는" 행동을 하지 마십시오. 반복 시도는 추가 부하를 만들 수 있고, 시세 변화 후 갑자기 성공하여 의도치 않은 포지션이 생길 수도 있습니다. 먼저 모의 환경에서 재현하고, 매개변수 버전과 당시 플랫폼 호가를 보관하십시오.

2단계: Bid, Ask, Point 및 Digits 확인

MQL4의 MarketInfo로 현재 종목의 Bid, Ask, Point 및 Digits를 읽을 수 있습니다. Point는 해당 호가의 최소 표시 단위 중 하나를 나타내고, Digits는 소수 자릿수를 의미합니다. "10포인트"가 몇 달러인지는 해당 종목의 실제 Point로 계산해야 하며, 서로 다른 브로커의 금 코드와 정밀도를 혼동해서는 안 됩니다. 가격을 전달하기 전에 해당 자릿수에 맞게 정규화해야 합니다.

예시는 수학적 설명일 뿐입니다: 어떤 모의 종목의 Point가 0.01이고 최소 거리가 50포인트라면 계산된 거리는 0.50 호가 단위입니다. Point가 0.001인 종목이라면 0.05가 됩니다. 숫자는 어떤 실제 플랫폼의 오늘 계약 규칙도 의미하지 않습니다. 로그를 볼 때 매수·매도 가격을 함께 저장하여, 매도 가격으로 점검해야 할 쪽을 매수 가격으로 보거나 그 반대로 하는 일을 피하십시오.

3단계: MODE_STOPLEVEL과 주문 유형 확인

공식 OrderSend 문서는 손절과 이익실현이 시장가에 너무 가까울 수 없으며, 대기 주문의 예정 개시 가격도 현재 시장에 너무 가까울 수 없다고 설명합니다. MarketInfo(Symbol(),MODE_STOPLEVEL)로 공개된 최소 거리를 포인트 단위로 조회할 수 있습니다. 그런 다음 주문이 매수, 매도 또는 어떤 대기 주문인지에 따라 가격 방향, 거리 및 정규화를 각각 확인해야 하며, 하나의 고정 오프셋을 모든 주문에 적용해서는 안 됩니다.


위 그림은 독자 제작한 절차示意图이며 실제 호가나 계좌 자료가 없습니다. 최소 거리는 서버가 주문을 수락하는 기술적 경계일 뿐, 전략적으로 합리적인 손절 거리와 같지 않습니다. 130을 우회하려고 손절을 멀리 옮기면 원래 계획한 건당 위험이 커집니다. 먼저 포지션 크기를 다시 계산하고, 필요하면 해당 거래를 포기해야 합니다.

4단계: 0이 반환되어도 제한이 없다고 단정할 수 없음

MQL4 공식 MODE_STOPLEVEL 설명은 특히 주의를 줍니다: 0이 반환되면 고정 최소 거리가 없음을 의미할 수도 있고, 서버가 터미널에서 직접 표현할 수 없는 동적 제한을 사용함을 의미할 수도 있습니다. 후자의 경우에도 여전히 130이 반환될 수 있습니다. 따라서 "0을 확인했으니 손절을 가격에 바짝 붙인다"는 성립하지 않습니다. 시세가 급변할 때 호가 갱신, 스프레드 변화 및 서버 측 규칙으로 인해 이전에 계산한 거리가 무효가 될 수도 있습니다.

코드 계산식이 당시 로그와 일치하는데도 여전히 130이 발생하면 실패 시간, 종목, 주문 매개변수 및 플랫폼 버전을 보관하고, 브로커의 종목 사양과 주문 제한을 확인하며 플랫폼 기술 지원에 문의하십시오. 다른 플랫폼의 Point와 StopLevel로 본 계좌 규칙을 추론하지 말고, 손절 삭제로 진짜 실패 원인을 가려서도 안 됩니다.

수정 후 검증 순서

먼저 모의 계좌에서 최소 재현 사례를 실행합니다: 동일 종목으로 네 가지 호가 매개변수와 StopLevel을 기록하고, 단일 테스트 요청을 보내 서버 반환과 주문 상태를 확인합니다. 그다음 가격이 빠르게 변하거나 거래 시간대가 다른 경우의 동작을 테스트합니다. 프로그램에 실패 후 중지 또는 쿨다운 메커니즘이 있고, 재시도 시 포지션이 중복 개설되지 않는지 확인합니다. 마지막으로 리스크 예산, 스프레드 및 허용 가능한 손실이 여전히 원래 계획과 일치하는지 점검합니다.

오류 130 점검의 핵심은 "요청이 왜 거부되었는가"이지 "어떻게 강제로 체결시키는가"가 아닙니다. EA 실행 결과는 전략 로직, 네트워크 및 플랫폼 실행의 영향도 받습니다. 어떤 수정도 수익을 보장하거나 손실을 피하게 보장하지 않습니다. 레버리지 거래는 중대한 손실을 초래할 수 있습니다.