MT5 EA 데모 계좌 포워드 테스트 체크리스트

MT5 데모 포워드 테스트는 수익보다 오작동을 찾는 단계입니다

이번 포스트의 핵심 내용 3줄요약

• 데모 계좌에서는 며칠 수익보다 EA가 계속 켜져 있었는지, 주문이 한 번만 나갔는지, 손절이 실제 포지션에 붙었는지를 먼저 봅니다.
• 신호 → 요청 → retcode → 주문 → deal → 포지션 → Stop Loss/Take Profit을 연결해 기록해야 백테스트와 다른 원인을 찾을 수 있습니다.
• 입력값이나 코드를 중간에 바꾸면 새 테스트입니다. 설명되지 않은 중복 주문·보호 주문 누락·상태 복구 실패가 있으면 실계좌 검토는 중단합니다.

이전 글인 MT5 Strategy Tester 결과 리포트 읽는 법에서는 백테스트를 Journal, Backtest, Graph 순서로 읽고, 순이익보다 거래 수와 드로다운, 기간별 안정성을 함께 확인했습니다.

그 다음 단계가 데모 계좌 포워드 테스트입니다. 여기서 forward test는 과거 데이터를 재생하는 대신 현재 들어오는 데모 서버 시세에 고정된 EA와 Inputs를 붙여 관찰하는 과정을 뜻합니다.

목적은 “며칠 벌었으니 전략이 된다”를 확인하는 것이 아닙니다. 백테스트가 충분히 재현하지 못하는 연결 끊김, 세션 시간, 변동 스프레드, 주문 거절, 부분 체결, 터미널 재시작, 중복 실행 같은 운영 결함을 드러내는 과정입니다. 데모 체결도 실계좌의 유동성·지연·슬리피지를 그대로 재현하지는 않습니다.

시작 전에 기준선을 고정합니다

포워드 테스트 도중 조건을 바꾸면 전후 결과를 같은 실험으로 비교할 수 없습니다. EA를 차트에 붙이기 전에 아래 항목을 한 번 기록하고, 관찰 ID를 부여합니다.

계좌번호 전체, 비밀번호, API 키는 기록 파일이나 캡처에 남기지 않습니다. 같은 이름의 심볼도 서버에 따라 계약 사양과 거래 시간이 다를 수 있으므로 EURUSD처럼 이름만 적는 것으로는 부족합니다.

코드, Inputs, 계좌, Symbol, Timeframe 가운데 하나라도 바꾸면 기존 관찰 ID를 닫고 새 ID로 시작합니다. 손실이 났다는 이유로 lot이나 손절폭을 중간에 조정하면 그것은 검증이 아니라 즉석 튜닝입니다.

“며칠”보다 어떤 상황을 통과했는지가 중요합니다

5일 또는 10일이라는 달력 숫자만 채웠다고 테스트가 끝나지는 않습니다. 거래가 한 번도 없었던 10일과, 여러 세션·재연결·주문 이벤트를 거친 3일은 증거의 양이 다릅니다.

재시작 시험은 노출이 없는 데모 구간부터 진행하는 편이 안전합니다. 포지션을 보유한 상태에서 PC나 터미널을 끄는 시험은 EA가 클라이언트에서만 관리하는 청산 로직을 멈출 수 있으므로, 코드가 그 상황을 어떻게 처리하는지 먼저 알아야 합니다.

저빈도 전략은 며칠 동안 신호가 없을 수 있습니다. 이때 “문제가 없었다”가 아니라 아직 주문 경로를 관찰하지 못했다고 기록합니다. 거래 횟수를 만들기 위해 조건을 느슨하게 바꾸지 않습니다.

매일 확인할 네 가지 영역

1) 연결과 실행 지속성

로컬 PC에서 EA를 실행한다면 MT5 프로세스, 전원, 인터넷, 브로커 서버 연결이 모두 유지되어야 합니다. Toolbox → Journal에는 플랫폼 시작, 네트워크, 거래 작업이 기록되고, Experts에는 EA 초기화와 EA가 출력한 메시지가 기록됩니다.

매일 다음을 확인합니다.

• Journal 시간축에 예상하지 못한 종료·재접속 공백이 없는가
• 운영체제 절전, 재부팅, 업데이트 때문에 터미널이 멈추지 않았는가
• EA가 올바른 Symbol과 Timeframe 차트에 계속 붙어 있는가
• 전역 Algo Trading과 EA별 자동매매 권한이 의도한 상태인가
• 재접속 후 시세와 계좌 상태를 다시 읽었다는 근거가 로그에 있는가

24시간 관찰이 필요하면 VPS가 선택지가 될 수 있지만, VPS로 옮기는 순간 실행 환경이 달라집니다. MetaTrader 공식 가상 호스팅 문서 새 탭는 지속적인 서버 연결과 전원 공급이 필요한 이유를 설명합니다. VPS 마이그레이션은 별도 관찰 ID로 검증하고, 같은 계좌의 같은 EA를 로컬과 VPS에서 동시에 실행하지 않습니다. 두 실행 주체가 같은 신호를 처리하면 중복 주문 원인이 될 수 있습니다.

2) 주문이 한 번만 나갔는지

“포지션이 하나 보인다”만으로 중복 주문이 없었다고 결론 내리면 안 됩니다. MT5는 주문(order), 체결(deal), 포지션(position)을 구분하며, 한 주문이 여러 deal로 나뉠 수도 있습니다.

또한 계좌의 포지션 회계 방식에 따라 화면이 다릅니다.

따라서 Trade 탭의 포지션 개수만 세지 말고 History의 order와 deal을 함께 봅니다. MetaTrader의 order·deal·position 설명 새 탭도 이 세 단위를 별도로 추적해야 한다고 설명합니다.

중복이 의심되면 아래 값을 나란히 놓습니다.

signal timestamp / bar time
EA version / chart / Magic Number
request timestamp / requested volume
server retcode / order ticket / deal ticket
position identifier / resulting volume

대표적인 원인은 다음과 같습니다.

• 같은 EA가 두 차트, 두 터미널 또는 로컬과 VPS에서 함께 실행됨
• 새 봉 조건 없이 OnTick마다 같은 신호를 다시 처리함
• 타임아웃 뒤 기존 주문 상태를 조회하지 않고 곧바로 재전송함
• 재시작 후 열린 포지션·대기 주문을 복구하지 못함
• EA가 Magic Number, Symbol, 포지션 방향을 충분히 구분하지 못함

MQL5의 OrderSend()가 true를 반환해도 실제 체결 완료를 뜻하지는 않습니다. 공식 OrderSend 문서 새 탭에 따라 MqlTradeResult.retcode, order/deal 값, 이후 거래 이벤트와 최종 계좌 상태를 확인해야 합니다. 불명확한 응답을 “실패”로 단정해 즉시 재전송하면 중복 체결을 만들 수 있습니다.

3) 손절과 익절이 실제 포지션에 붙었는지

EA가 로그에 “SL 설정”이라고 출력한 것과 Trade 탭의 포지션에 Stop Loss가 실제로 존재하는 것은 다른 증거입니다. 전략이 보호 주문을 전제로 한다면 새 포지션마다 다음을 확인합니다.

Stop Loss와 Take Profit은 포지션에 연결되어 브로커 서버에 저장될 수 있으므로 터미널 연결이 끊겨도 서버에서 작동하는 구조입니다. 다만 EA 내부 가격만 보고 청산하는 이른바 가상 손절은 터미널이나 EA가 멈추면 작동하지 않습니다. 둘을 같은 것으로 기록하면 안 됩니다. 자세한 구조는 MetaTrader 공식 포지션 보호 문서 새 탭를 참고하세요.

invalid stops, trade disabled, price changed, timeout, no connection, too many requests 같은 응답이 나오면 횟수와 영향을 받은 ticket을 남깁니다. MQL5 거래 서버 return code 표 새 탭를 기준으로 원인을 분류하고, 보호 주문 누락 상태를 정상 체결로 집계하지 않습니다.

4) 백테스트와 데모의 차이가 설명되는지

백테스트와 데모의 손익 숫자를 하루 단위로 맞추려 하지 않습니다. 먼저 같은 신호가 어떤 경로로 달라졌는지를 사건별로 비교합니다.

관찰 기간이 끝난 뒤 같은 날짜 구간을 동일한 EA와 Inputs로 다시 백테스트하면 진단에 도움이 됩니다. 다만 이미 본 기간이므로 그 비교는 새로운 out-of-sample 증거가 아니라 불일치 원인을 찾는 사후 분석입니다.

비교할 때는 서버 시간대를 먼저 맞추고 아래 항목을 사건별로 연결합니다.

1. 신호 bar와 계산에 사용한 가격
2. 요청 시각·방향·volume·요청 가격
3. 당시 Bid/Ask와 spread
4. retcode와 실제 deal 가격
5. 진입 뒤 SL/TP 가격과 수정 이력
6. 청산 이유와 최종 비용·swap·commission

데모에서 deal 가격이 달랐다는 사실만으로 EA 결함이라고 단정할 수 없습니다. 반대로 “슬리피지니까 어쩔 수 없다”고 끝내서도 안 됩니다. 규칙을 바꿀 정도의 차이인지, 특정 세션이나 spread에서 반복되는지, 주문 재시도 로직이 차이를 키웠는지 분리합니다.

하루 3회 운영 체크리스트

매일 “이익/손실”보다 아래 다섯 문장을 먼저 채웁니다.

오늘 EA가 의도한 시간 동안 실행됐는가:
발생한 신호 수 / 요청 수 / 체결된 거래 아이디어 수:
중복·누락·거절·부분 체결이 있었는가:
모든 필수 보호 주문이 실제 포지션에 존재했는가:
설명되지 않은 차이와 다음 재현 시험:

로그는 당일이 지나기 전에 보관합니다. MT5의 Platform Logs 문서 새 탭에 따르면 Journal과 Experts 로그는 서로 역할이 다르고, 과거 로그는 파일에서 확인할 수 있습니다. 화면 캡처만 남기면 앞뒤 이벤트와 정확한 응답 코드를 잃기 쉽습니다.

중단 기준을 시작 전에 정합니다

포워드 테스트는 통과 도장을 찍는 절차가 아니라, 다음 결함을 더 싸게 발견하는 절차입니다. 상태를 세 단계로 나누면 수익 숫자에 끌려 기준을 완화하는 일을 줄일 수 있습니다.

특히 아래 가운데 하나라도 해당하면 실계좌 검토를 멈춥니다.

• 주문 수, deal 수, 포지션 변화가 전략 규칙과 맞지 않음
• 필수 Stop Loss가 없거나 잘못된 가격에 붙음
• 재접속·재시작 뒤 같은 신호를 다시 주문함
• 오류를 해결하지 않은 채 수익이 났다는 이유로 계속 진행함
• 실행 중 코드나 Inputs를 바꾸고 같은 테스트로 합산함
• 데모와 검토 대상 환경의 심볼 사양·계좌 방식 차이를 설명하지 못함
• 비상 중단 뒤 열린 포지션을 누가, 어떤 규칙으로 관리하는지 정해지지 않음

예상 밖 포지션을 발견했을 때 EA를 무조건 떼는 것도 정답은 아닙니다. 서버에 붙은 SL/TP는 남을 수 있지만 EA만 수행하는 청산·추적 손절은 멈출 수 있습니다. 데모 단계에서부터 신규 진입 차단, 열린 포지션 처리, 로그 보존 순서를 문서화한 중단 절차가 필요합니다.

복사해서 쓰는 포워드 테스트 기록표

Observation ID:
Start / end timestamp and timezone:
OS / MT5 build / broker server:
Demo account mode / currency / leverage:
EA file / version / commit or hash:
Symbol / timeframe / contract notes:
Inputs file / Magic Number:
Expected sessions and signal rule:

Uptime or connection gaps:
Signals observed:
Requests sent:
Server retcodes:
Orders / deals / positions reconciled:
Missing or changed SL/TP:
Duplicate or skipped entries:
Spread / requested price / deal price differences:
Manual intervention or environment changes:

Unexplained discrepancies:
Stop / hold / observation-complete decision:
Next reproducible test:
Evidence paths:

수동 개입도 숨기지 말고 기록합니다. 포지션을 직접 닫거나 SL을 옮겼다면 그 뒤 손익은 순수한 EA 결과가 아닙니다. 실패한 관찰 기록도 삭제하지 않아야 같은 결함이 다시 나타났을 때 비교할 수 있습니다.

자주 묻는 질문

데모 포워드 테스트는 며칠 해야 하나요?

고정된 정답은 없습니다. 첫 며칠은 연결과 주문 경로를 확인하는 운영 점검에 가깝습니다. 전략의 주요 세션, 실제 신호, 보호 주문, 재연결과 재시작을 관찰하지 못했다면 달력 날짜가 지나도 검증은 끝나지 않았습니다.

PC를 끄면 EA가 계속 거래하나요?

로컬 터미널에서 실행 중인 EA 로직은 PC나 MT5가 꺼지면 실행되지 않습니다. 서버에 이미 등록된 SL/TP는 별개로 처리될 수 있지만, EA 내부의 추가 진입·청산·추적 로직은 멈춥니다. VPS를 쓰려면 별도 환경으로 다시 검증합니다.

데모에서 수익이 나면 백테스트가 확인된 것인가요?

아닙니다. 짧은 데모 손익은 표본이 작고, 체결 환경도 실계좌와 다를 수 있습니다. 데모 포워드 테스트는 규칙과 운영 경로가 예상대로 작동했는지 확인하는 증거입니다.

포지션이 하나면 중복 주문이 없었던 것 아닌가요?

Netting 계좌에서는 여러 deal이 하나의 포지션 volume으로 합쳐질 수 있습니다. History의 order와 deal, Magic Number, ticket을 함께 확인해야 합니다.

며칠 동안 거래가 없으면 안정적인 EA인가요?

그 결론을 낼 수 없습니다. 정상적으로 신호가 없었는지, 데이터·권한·시간대 문제로 EA가 멈췄는지 먼저 구분해야 합니다. heartbeat 로그나 예상 신호 계산 기록이 없다면 “미관찰”로 남깁니다.

위험 설명

데모 계좌는 실제 자금을 사용하지 않고 전략과 플랫폼 동작을 연습·관찰하는 환경입니다. 그러나 실계좌의 유동성, 체결 우선순위, 지연, 슬리피지, 급격한 spread 확대를 완전히 재현하지 않습니다. 백테스트와 데모 결과는 미래 성과를 증명하지 않으며, 레버리지 상품은 큰 손실을 빠르게 만들 수 있습니다.

이 글은 정보 제공 목적이며 특정 브로커, EA, 심볼, 파라미터 또는 거래를 권유하지 않습니다. 데모 계좌의 기본 역할은 MetaTrader 5 시작 문서 새 탭와 사용 중인 브로커의 현재 계좌·심볼 사양을 함께 확인하세요.

다음 포스팅 예고

MT5 EA 재시작·재연결 상태 복구 설계에서 Magic Number 범위, 열린 position과 pending order 재조정, 새 봉 중복 방지, OnTradeTransaction 기록, 로컬·VPS 단일 실행 원칙을 코드 관점에서 이어서 확인하세요.