MT4·MT5 서버 유지보수 체크리스트: 일일·주간·월간 점검 항목

MT4·MT5 서버 유지보수는 서버가 켜져 있는지 확인하는 데서 끝나지 않습니다. 고객이 로그인할 수 있어도 일부 종목의 시세가 멈출 수 있고, 주문을 전송할 수 있어도 체결 결과가 CRM이나 운영 보고서에 제때 반영되지 않을 수 있습니다.

브로커에게 필요한 것은 서버 상태와 실제 거래 흐름을 함께 확인하는 점검 체계입니다. 여기에 백업 복구, 관리자 권한, 설정 변경 이력과 장애 대응 절차까지 연결되어야 일상적인 유지보수가 운영 안정성으로 이어집니다.

이 글은 운영 중인 MT4·MT5 환경에서 활용할 수 있는 일일·주간·월간 체크리스트를 정리합니다. 점검 주기는 운영 계획을 세우기 위한 예시이며, 실제 주기와 기준은 거래 시간, 시스템 구성, 계약 및 적용 요건에 맞춰 정해야 합니다. MT4와 MT5는 구조와 관리 기능이 다르므로 구체적인 작업은 각 플랫폼의 버전과 공식 관리자 문서를 기준으로 수행해야 합니다.

점검을 시작하기 전에: 대상과 담당자를 먼저 정한다

점검표에 항목이 많아도 대상 서버와 담당자가 빠져 있으면 문제가 발견된 뒤 조치가 늦어집니다. 먼저 운영 환경을 목록으로 정리하십시오.

구분	기록할 내용
서버와 구성요소	플랫폼, 서버 역할, 운영·테스트·복구 환경, 설치 버전
외부 연결	LP, 브리지, CRM 등 연동 대상과 연결 방식
관리 접근	관리자 계정, 접근 경로, 허용 권한과 승인 담당자
모니터링	확인 지표, 경고 기준, 알림 수신자와 대체 담당자
백업과 복구	백업 대상, 보관 위치, 마지막 성공 시점과 복구 시험 결과
지원 체계	내부 담당자, 기술 유지보수 업체, 외부 공급업체의 연락처와 지원 시간

MetaQuotes는 MT5가 여러 서버에 기능을 분산하는 구조이며, 시스템 데이터베이스에 백업·복구 기능을 제공한다고 설명합니다. 그러나 이러한 기능을 갖추는 것과 실제 운영 환경의 점검·복구 절차를 완성하는 것은 별개의 일입니다. 서버별 역할과 연결 관계를 파악한 뒤 점검 범위를 정해야 합니다.

인프라 구성과 운영 책임을 함께 정리해야 한다면 MT4·MT5 서버 유지보수 서비스의 지원 범위를 검토할 수 있습니다.

일일 점검: 고객이 이용하는 거래 흐름을 확인한다

일일 점검은 자동 모니터링 결과와 전일·직전 근무조의 미해결 사항을 확인하는 절차입니다. 거래 중 발생하는 장애를 하루 한 번만 확인한다는 뜻은 아닙니다. 서비스 중단이나 시세 수신 중단처럼 즉시 대응이 필요한 상황은 운영 시간에 맞춘 감시와 알림 체계로 관리해야 합니다.

점검 항목	확인할 내용	이상 발견 시 우선 조치
서버·서비스 상태	필요한 서비스의 실행 상태, 예상하지 못한 재시작, 고객 접속 경로	영향받는 서버와 고객 범위를 확인하고 관련 기록 보존
자원과 저장 공간	CPU·메모리 추이, 디스크 여유 공간, 저장장치 지연, 네트워크 오류	평소 같은 시간대와 비교하고 용량 부족·지연 원인 확인
시세 수신	거래 시간 중 주요 종목의 최근 수신 시각, 비정상적인 공백과 가격 차이	거래 세션과 공급원 상태를 확인하고 영향 종목 분리
주문 처리	거절·시간 초과·처리 지연의 변화, 주문 요청과 결과의 연결	주문 식별자, 발생 시각과 오류 내용을 확보해 담당자 전달
외부 시스템 연동	LP·브리지 연결, CRM 요청 실패와 처리 지연, 필요한 결과 반영	어느 연결 구간에서 문제가 생겼는지 구분
백업과 로그	예정된 백업 완료 여부, 실패 알림, 로그 수집 중단과 저장 공간	마지막 정상 백업 시점을 확인하고 실패 원인 조사
보안·인수인계	비정상 로그인, 승인되지 않은 변경, 미해결 장애와 예정 작업	담당자·조치 기한을 지정하고 다음 근무조에 전달

연결 상태만으로 정상 운영을 판단하지 않는다

LP 연결이 유지되어도 특정 종목의 시세가 들어오지 않을 수 있습니다. 반대로 시세가 잠시 갱신되지 않는 이유가 장애가 아니라 거래 시간 종료나 휴장일일 수도 있습니다.

따라서 시세 점검은 종목별 거래 시간과 공급원 상태를 함께 확인해야 합니다. 주문 거절 역시 잘못된 주문 조건, 증거금 부족 또는 거래 제한에 따른 정상 응답일 수 있으므로 건수만 보고 기술 장애로 분류하지 않아야 합니다.

고객 화면에서 확인되는 증상과 서버·연결 구간의 기록을 맞춰 보는 것이 핵심입니다. 필요한 경우 승인된 테스트 계정으로 접속과 주문 흐름을 확인하되, 데모 환경의 성공만으로 실거래 환경 전체가 정상이라고 단정해서는 안 됩니다. 실거래 환경에서 주문 시험이 필요하다면 사전 승인과 거래·위험 한도를 정해야 합니다.

경고 기준은 평소 운영 패턴을 기준으로 설정한다

모든 서버에 같은 CPU 사용률이나 지연 시간 기준을 적용하면 불필요한 알림이 늘거나 중요한 변화를 놓칠 수 있습니다.

서버 역할과 시간대별 정상 범위를 먼저 파악하고, 다음과 같은 변화를 함께 확인하십시오.

• 특정 시간대에 반복되는 자원 사용량 증가
• 평소보다 빠른 디스크 사용량 증가
• 특정 LP 또는 종목에 집중되는 오류
• 고객 접속 증가와 동시에 나타나는 처리 지연
• 같은 경고가 조치 후에도 반복되는 현상

경고를 계속 무시하거나 임계값만 높이는 대신, 정상적인 부하 증가인지 설정 문제인지 구분해야 합니다.

주간 점검: 반복 오류와 설정 차이를 정리한다

매일의 점검이 현재 상태를 확인하는 일이라면, 주간 점검은 작은 이상이 반복되는 이유를 찾는 과정입니다.

점검 항목	확인할 내용	남겨야 할 결과
장애·경고 추세	반복 오류, 처리 지연, 재발한 고객 문의	반복 원인과 개선 담당자
거래 설정	승인된 기준과 실제 심볼·그룹 설정의 차이	변경 사유, 승인 기록과 검수 결과
거래 일정	다음 주 휴장일, 단축 거래, 서머타임 전환 관련 공급업체 공지	적용 대상과 변경 일정
관리자 접근	신규·퇴사·외주 인력의 계정, 임시 권한과 공유 계정 사용	회수하거나 조정할 접근 권한
백업 표본 확인	선택한 백업의 접근·복원 가능 여부와 필요한 자료의 포함 여부	시험 대상, 결과와 누락 항목
용량·의존 서비스	저장 공간 증가, 인증서·구독·연결 정보의 만료 예정	대응 기한과 담당자

거래 조건은 승인된 기준과 대조한다

스프레드, 수수료, 스왑, 레버리지, 증거금과 거래 세션은 고객 거래에 직접 영향을 줍니다. 유지보수 담당자가 기술적으로 변경할 수 있다고 해서 해당 조건을 임의로 결정할 수 있는 것은 아닙니다.

운영·리스크 담당자가 승인한 기준을 바탕으로 실제 설정을 확인하고, 변경이 필요한 경우에는 적용 대상과 시점을 명확히 해야 합니다. LP의 거래 조건이 바뀌었다고 고객 그룹 설정을 일괄 변경하기보다, 영향을 받는 상품과 그룹을 먼저 구분하십시오.

서머타임 전환도 운영체제 시계를 임의로 바꾸는 작업으로 처리해서는 안 됩니다. 플랫폼 시간 기준, 공급업체 공지와 종목별 거래 세션을 대조해 필요한 설정 변경을 계획해야 합니다.

퇴사자나 계약이 종료된 외주 인력의 접근 권한은 주간 검토일까지 기다리지 않고 종료 시점에 회수합니다. 주간 점검은 이러한 처리가 누락되지 않았는지 다시 확인하는 절차입니다.

월간 점검: 업데이트·용량·복구 준비를 검토한다

월간 점검은 그달의 운영 기록을 바탕으로 다음 달의 유지보수 계획을 정하는 과정입니다. 매달 모든 구성요소를 반드시 업데이트하거나 서버를 재시작해야 한다는 의미는 아닙니다.

점검 항목	검토할 내용	실행 기준
업데이트 계획	플랫폼·운영체제·관련 구성요소의 공지와 호환성	위험도, 공급업체 안내와 시험 결과에 따라 일정 결정
용량 계획	동시 접속, 시세·주문 처리량, 로그·백업 증가 추세	향후 운영량과 여유 용량을 기준으로 증설 검토
권한과 보안 설정	관리자·서비스 계정, 원격 접근, 방화벽 예외	현재 업무에 필요한 권한과 접근만 유지
로그 보관	수집 누락, 검색 가능 여부, 보관·삭제 정책	적용 요건과 내부 정책에 맞춰 확인
복구 준비	복구 절차, 연락망, 백업 보관 상태와 이전 시험의 미해결 사항	위험도와 복구 목표에 맞춰 다음 훈련 계획
유지보수 보고	장애 영향, 대응 시간, 변경 결과와 반복 문제	개선 과제에 담당자와 완료 기한 지정

긴급한 보안 문제나 서비스 중단 위험이 확인되면 월간 작업일까지 미루지 말고 별도의 긴급 변경 절차로 평가해야 합니다.

용량 검토에서는 계좌 수만 보지 않는 것이 좋습니다. 접속 패턴, 상품 수, 시세 유입량과 주문 활동이 달라지면 같은 계좌 수에서도 부하가 다를 수 있습니다. 브로커 서버 호스팅을 검토할 때도 현재 사양과 함께 실제 운영 지표를 제시하면 필요한 구성을 판단하기 쉽습니다.

백업 점검: 파일 생성보다 복구 결과가 중요하다

백업 작업의 성공 기록은 점검의 출발점입니다. 파일이 존재하더라도 필요한 데이터와 설정이 빠져 있거나, 복구 환경에서 사용할 수 없다면 충분한 대비가 되지 않습니다.

CISA의 랜섬웨어 대응 가이드는 중요 데이터의 오프라인·암호화 백업과 정기적인 복구 가능성·무결성 시험을 권고합니다. 브로커도 운영 환경과 함께 손상될 수 있는 복사본에만 의존하지 않도록 백업 보관 방식과 접근 권한을 검토할 필요가 있습니다.

복구 계획에는 다음 두 목표를 구분해 기록하십시오.

• 복구 시점 목표(RPO): 장애 발생 시 어느 정도의 데이터 손실 시간을 허용할 것인지 정하는 기준
• 복구 시간 목표(RTO): 장애로 중단된 서비스를 목표 수준으로 되돌리기까지 허용할 시간을 정하는 기준

이 목표는 백업 주기나 대기 서버를 갖췄다는 이유만으로 달성되는 것이 아닙니다. 실제 복구 시험 결과와 비교해야 합니다.

복구 시험에서 확인할 항목

1. 선택한 복구 시점에 필요한 데이터와 설정이 포함되어 있는지 확인합니다.
2. 운영 환경과 격리된 시험 환경에서 승인된 절차로 복원합니다.
3. 시험 환경이 실제 LP·CRM 등으로 주문이나 업무 요청을 보내지 않도록 연결을 통제합니다.
4. 서비스 실행 상태와 함께 계정·거래 기록·설정의 일관성을 확인합니다.
5. 소요 시간, 수동 작업, 누락 자료와 실패 원인을 기록합니다.
6. 절차를 수정하고 필요한 부분을 다시 시험합니다.

표본 백업 복원과 전체 서비스 복구 훈련은 범위가 다릅니다. 간단한 복원 시험을 자주 수행하더라도 전체 복구 절차의 검증을 대신할 수는 없습니다. 전체 훈련 주기는 운영 위험, 주요 변경과 적용 요건을 고려해 별도로 정해야 합니다.

대기 서버나 실시간 복제도 과거 시점의 백업을 완전히 대체하지 못합니다. 구성에 따라 잘못된 변경이나 데이터 손상까지 복제될 수 있기 때문입니다. 운영체제·가상머신 스냅샷 역시 플랫폼 데이터의 일관성과 복구 절차가 검증되어야 활용할 수 있습니다.

백업 서버, 대기 환경과 재해복구 체계의 차이, 그리고 복구 목표에 맞춘 서버 배치는 MT5 서버 인프라 구성에서 자세히 설명합니다.

설정 변경과 업데이트: 적용 전후의 검수가 필요하다

설정 변경은 작업 자체보다 대상과 결과를 잘못 판단했을 때 문제가 커집니다. 변경 요청에는 최소한 다음 내용을 포함하십시오.

단계	기록할 내용
요청·승인	변경 목적, 대상 서버·상품·그룹, 승인 담당자
사전 준비	현재 설정, 의존 시스템, 백업 상태와 호환성 확인
시험	테스트 환경의 검수 항목과 적용 가능 여부
작업 계획	작업 시간, 예상 영향, 공급업체 협조와 고객 안내 필요성
복구 계획	작업 중단·되돌리기 기준, 실행 담당자와 복구 방법
적용 후 검수	접속·시세·주문·연동·로그의 확인 결과

주말이라고 항상 안전한 작업 시간이 되는 것은 아닙니다. 취급 상품에 따라 거래가 계속될 수 있고, 외부 공급업체의 지원 시간이 줄어들 수도 있습니다. 실제 거래 일정과 연결된 서비스의 운영 시간을 기준으로 작업 시간을 정해야 합니다.

설정을 이전 값으로 되돌리는 작업과 거래 데이터를 과거 상태로 복원하는 작업은 구분해야 합니다. 거래가 계속 발생한 뒤 오래된 서버 이미지를 그대로 복원하면 이후 거래 기록과 외부 시스템의 상태가 맞지 않을 수 있습니다. 데이터 복원이 필요한 장애는 거래 통제와 기록 대조를 포함한 별도 복구 절차로 처리해야 합니다.

장애 대응: 접수 시간과 복구 시간을 구분한다

장애 대응에서 먼저 확인할 것은 고객과 거래에 미치는 영향입니다. 서버 경고가 같아 보여도 전체 접속 중단, 특정 종목의 시세 문제, 보고서 생성 지연은 우선순위가 다릅니다.

대응 기록에는 다음 내용을 남기는 것이 좋습니다.

• 최초 발생·감지 시각과 적용 시간대
• 영향받는 서버, 상품, 고객 그룹과 외부 연결
• 오류 내용과 주문·요청 식별자
• 최근 변경과 이미 수행한 조치
• 현재 담당자, 공급업체 접수 번호와 다음 보고 시각
• 서비스 재개 기준과 사후 검수 결과

재시작은 승인된 복구 절차에 포함될 수 있지만, 모든 장애의 첫 조치가 되어서는 안 됩니다. 가능한 범위에서 먼저 기록을 확보하고, 재시작이 진행 중인 작업이나 원인 분석에 미칠 영향을 평가해야 합니다.

24시간 모니터링, 담당자의 응답, 실제 복구 작업은 서로 다른 서비스 범위입니다. 계약을 검토할 때는 알림 수신, 최초 응답, 기술 조치와 외부 업체 협조가 각각 어디까지 포함되는지 확인하십시오. 최초 응답 시간은 최종 복구 완료 시간과 같지 않습니다.

지원 범위와 계약 조건이 운영 예산에 미치는 영향은 브로커 구축 첫해 비용과 월 운영비에서 확인할 수 있습니다.

고객 안내에서는 확인된 영향과 다음 안내 시점을 먼저 전달하고, 아직 확인되지 않은 원인이나 복구 완료 시각을 단정하지 않는 것이 좋습니다.

유지보수 보고서에는 무엇을 남겨야 하는가

보고서는 작업 건수보다 운영 상태와 미해결 위험을 설명할 수 있어야 합니다. 다음 항목을 월별로 비교하면 개선 여부를 판단하기 쉽습니다.

보고 항목	기록 방식
장애와 고객 영향	발생 시간, 영향 범위, 지속 시간과 재발 여부
대응 과정	감지·접수·조치·서비스 재개 시각을 구분
주요 변경	승인 내용, 적용 결과와 추가 조치
백업·복구	실패 내역, 마지막 정상 백업, 복구 시험 결과
용량과 성능	같은 조건에서 비교한 추세와 증설 필요성
미해결 사항	위험 설명, 담당자, 기한과 다음 확인 일정

가용성을 보고한다면 측정 대상과 시간 범위도 함께 적어야 합니다. 서버 프로세스의 실행 시간과 고객이 실제로 접속·거래할 수 있었던 시간은 다른 지표일 수 있습니다.

점검표의 상태는 ‘정상’, ‘조치 필요’, ‘확인 불가’, ‘해당 없음’으로 구분하는 것이 좋습니다. 필요한 기록이나 접근 권한이 없어 확인하지 못한 항목을 정상으로 처리해서는 안 됩니다.

EBS FinTech의 MT4·MT5 유지보수 지원

EBS FinTech는 MT4·MT5 서버 환경의 모니터링, 설정 관리, 백업 점검, 장애 분석과 외부 시스템 연동을 지원합니다. 서버 구성과 기존 운영 절차를 바탕으로 정기 점검 항목, 변경 작업, 장애 대응과 보고 범위를 정리합니다. MT4 관련 지원은 기존 운영 환경의 유지보수를 대상으로 합니다.

브리지는 운영사가 해당 공급업체와 직접 계약하고 라이선스를 보유합니다. 브리지 이용료는 EBS FinTech의 구축·지원 요금에 포함되지 않습니다. EBS FinTech는 브리지 제품을 제공하거나 호스팅·운영·유지보수하지 않으며, MT4·MT5 서버 및 LP와 브리지 간 연동 작업을 수행합니다. 브리지 자체의 장애 처리와 제품 지원은 운영사가 해당 공급업체와 체결한 계약에 따릅니다.

현재 유지보수 체계를 점검하려면 플랫폼과 서버 구성, 주요 연동 대상, 필요한 지원 시간과 최근 반복된 문제를 정리해 주십시오. 이를 바탕으로 MT4·MT5 유지보수 상담에서 필요한 지원 범위를 구체화할 수 있습니다.

이 글은 일반적인 운영 참고 자료이며, 구체적인 작업은 각 플랫폼의 공식 문서와 서비스 계약 범위에 따라 수행해야 합니다. MetaTrader 4·5는 MetaQuotes의 상표입니다.