EA 실행 이상 점검 방법: 먼저 MT4 로그를 보존하고, 그다음 설정을 변경

작성자: 토마스｜EA와 플랫폼 실무｜2026년 10월 5일

EA가 갑자기 거래하지 않거나 중복 주문이 발생하거나, 재시작 후 기대와 다르게 동작할 때 가장 흔한 실수는 곧바로 파라미터를 바꾸고 프로그램을 재설치한 뒤 문제가 어디 있는지 추측하는 것이다. 이렇게 하면 가장 가치 있는 현장 정보를 덮어쓸 수 있다. 점검은 먼저 증거를 보존한 뒤 프로그램, 터미널, 계정 수준의 원인을 구분하는 것부터 시작해야 한다.

이상 발생 전후 기록을 먼저 보존

이상이 나타난 시간, 전체 거래 종목, 차트 주기, EA 버전, 파라미터 파일, 당시 계정 포지션을 기록한다. 여기서 시간은 컴퓨터 시간, 거래 서버 시간, 자체 환산한 베이징 시간 중 무엇을 사용했는지 반드시 명시하고, 서로 다른 시계의 기록을 그대로 이어 붙이지 않는다.

로그가 프로그램의 모든 의사 결정 과정을 포함한다고 볼 수는 없다. 개발자가 출력하지 않은 정보는 '오류가 없다'는 이유만으로 정상 실행이라고 추론할 수 없다. 앞뒤로 연속된 기록을 보존하는 것이 단일 오류 스크린샷보다 사건의 순서를 판단하는 데 더 도움이 된다. 공개하거나 지원 담당자에게 보내기 전에 계정, 개인정보 또는 기타 민감한 내용이 포함되어 있는지 먼저 확인한다.

Experts와 Journal, 각각 무엇을 보나

MT4의 Experts 탭은 주로 부착된 EA의 실행 정보, 즉 프로그램 자체 메시지와 관련 작업 기록을 보여 준다. Journal 탭은 현재 세션에서 클라이언트 터미널의 활동에 중점을 둔다. 같은 이상을 점검할 때 두 곳의 정보를 대조할 수 있지만, 어느 한쪽을 완전한 체결 증빙으로 간주해서는 안 된다.

해당 탭의 오른쪽 클릭 메뉴에서 Open을 사용하면 관련 로그 디렉터리를 열고 현재 표시된 기록을 로그 파일에 기록할 수 있다. 공식 도움말에 따르면 EA 로그는 터미널 데이터 디렉터리 아래 MQL4/LOGS에 있고, 터미널 로그는 LOGS에 있다. 파일은 일반적으로 날짜별로 이름이 지정된다. 설치 인스턴스마다 데이터 디렉터리가 다를 수 있으므로 현재 사용 중인 터미널에서 들어가야 하며, 다른 터미널의 파일을 잘못 가져오지 않도록 해야 한다.

먼저 판단한다: 트리거되지 않았는가, 아니면 트리거 후 체결되지 않았는가

'새 주문 없음'은 적어도 몇 가지 다른 상태에 해당할 수 있다: 전략 조건이 충족되지 않음, 프로그램이 정상적으로 로드되지 않음, 자동 거래 권한이 제한됨, 거래 요청이 거부됨, 요청 결과가 예상과 다름. 차트에 있는 프로그램 표시만 보고 어느 상태인지 바로 판단할 수 없다.

먼저 전략의 기존 규칙에 따라 지정된 종목과 주기에서 실제로 트리거되어야 하는지 확인한다. 그다음 관련 시간대에 로드, 초기화 또는 거래 작업 정보가 있는지 본다. 거래 요청이 존재한다면 반환 메시지와 계정 주문 기록을 대조해 결과를 확인해야 하며, 프로그램이 출력한 문구만으로 체결 성공을 단정할 수 없다. 로그에 핵심 단계가 빠져 있다면 개발자에게 기록 보완을 요청해야 한다.

권한 점검은 항목별로 맞춰 확인하고, 전부 열어서는 안 된다

MT4 터미널 설정과 EA 자체 속성은 자동 거래 권한에 영향을 준다. 계정, 차트 종목 또는 주기를 바꾸는 작업도 터미널의 자동 거래 설정과 관련될 수 있다. 현재 실제 설정을 확인하고 프로그램 설명과 함께 예상 동작을 판단해야 하며, 버튼을 반복해서 클릭하는 것으로 점검을 대신할 수 없다.

프로그램이 거래를 시작하게 만들기 위해 무조건 DLL 호출이나 기타 외부 접근을 허용해서는 안 된다. 먼저 프로그램이 실제로 해당 기능을 필요로 하는지, 출처를 신뢰할 수 있는지, 용도가 명확히 설명되어 있는지 확인한다. 권한 부족이 어느 한 단계의 원인일 수는 있지만, 모든 권한을 여는 것은 신뢰할 수 있는 해결 방법이 아니다.

재시작하기 전에 기존 포지션을 어떻게 처리할지 먼저 확인한다

현재 주문, 대기 주문, 프로그램 상태를 보존한 뒤 재시작 여부를 결정한다. 프로그램을 다시 시작할 때 기존 주문을 인식하는지는 구체적인 구현에 달려 있다. 모든 EA가 원래의 내부 상태를 자동으로 복구한다고 가정할 수 없다. 특히 포지션 추가 또는 다중 주문 관리 로직이 있는 프로그램은 반복 시작이 기존 포지션과 충돌할 수 있으므로 프로그램 규칙에 따라 확인해야 한다.

자동 거래를 끄는 것이 기존 포지션이 이미 청산되었다는 뜻은 아니며, '프로그램 일시 정지'를 위험이 사라졌다는 의미로 이해해서도 안 된다. 기존 주문의 처리 방식은 미리 정해 두어야 하며, 이상이 발생한 뒤에 임시로 추측해서는 안 된다. 프로그램이 비정상 주문을 만들고 있다고 의심되면 정해진 일시 정지 및 수동 점검 절차에 따라 처리하고, 동시에 계정의 실제 익스포저를 확인한다.

단일 변경으로 수정 결과를 검증한다

시뮬레이션 환경은 작업을 재현하고 프로그램 동작을 점검하는 데 사용할 수 있지만, 실계좌 체결 조건이 완전히 같다는 것을 증명하지는 못한다. 매번 하나의 명확한 요인만 바꾸고, 수정 전후의 파라미터와 로그를 보존한 뒤 관련 이상이 사라졌는지 관찰한다. 버전 교체, 파라미터 변경, 계정 교체를 동시에 하면 어느 단계가 효과를 냈는지 판단하기 어려운 경우가 많다.

효과적인 점검 기록에는 현상, 시간, 증거, 수정 내용, 재확인 결과를 명시해야 한다. 설명할 수 없는 이상은 계속 개발자 또는 플랫폼 지원에 확인해야 하며, '거래가 재개되었다'는 말로 원인 분석을 대신하지 않고, 기술 수정을 수익 보장으로 쓰지도 않는다.

레버리지 거래는 중대한 손실을 초래할 수 있다. 이 글은 운영 및 유지보수 지식 공유를 위한 것이며, 매매 지시를 구성하지 않는다. 로그 점검은 문제를 찾는 데 도움이 될 수 있지만, 프로그램의 안전성, 전략의 유효성 또는 미래 수익을 보장하지 않는다.