Table of Contents▼

MT5 서버 구성은 장비 수보다 역할에서 시작한다
메인·거래 서버: 계정과 거래 처리를 담당하는 핵심 영역
액세스 서버: 고객 접속 경로와 거래 처리 위치를 구분한다
백업 서버, 백업 파일, 재해복구는 무엇이 다른가
복구 목표를 정한 뒤 배치 위치를 선택한다
서버 위치: 고객과 LP 사이의 전체 경로를 본다
전용 서버, 클라우드, 코로케이션을 어떻게 비교할까
LP·브리지·CRM 연결을 인프라 설계에 포함한다
견적을 받기 전에 정리할 여덟 가지
EBS FinTech의 MT5 서버 구축·호스팅 지원

MT5 서버 인프라를 준비할 때 가장 먼저 비교하는 항목은 CPU, 메모리와 월 임대료입니다. 하지만 같은 사양의 서버라도 어떤 역할을 맡고, 어디에 배치되며, 다른 시스템과 어떻게 연결되는지에 따라 실제 운영 결과는 달라집니다.

고객이 접속하는 경로와 거래를 처리하는 서버는 구분해야 합니다. 백업 데이터를 보관하는 것과 장애가 발생했을 때 서비스를 이어 갈 환경을 갖추는 것도 다른 일입니다. 클라우드 서버를 임대했다고 플랫폼 설정과 복구 작업까지 자동으로 관리되는 것은 아닙니다.

이 글에서는 브로커의 MT5 서버 인프라를 메인·거래 서버, 액세스 서버, 히스토리 서버와 백업 환경으로 나누어 설명합니다. 이어서 배치 위치, 호스팅 방식과 운영 책임을 정할 때 확인할 사항을 살펴봅니다. 개인 트레이더가 자동매매 프로그램을 실행하는 VPS가 아니라, 브로커가 운영하는 플랫폼 서버 환경을 대상으로 합니다.

MT5 서버 구성은 장비 수보다 역할에서 시작한다

MetaQuotes의 MT5 소개는 플랫폼이 여러 서버에 기능을 분산하는 구조이며, 거래 서버를 여러 접속 지점 뒤에 배치할 수 있다고 설명합니다. 따라서 ‘MT5 서버 한 대’라는 표현만으로 전체 인프라의 범위를 판단하기는 어렵습니다.

설계에서는 먼저 역할을 구분하고, 그다음 각 역할을 어떤 물리 서버나 가상머신에 배치할지 결정해야 합니다. 소프트웨어 구성요소의 수와 실제 장비 수는 반드시 같지 않습니다. 제공되는 구성요소와 확장 범위는 해당 라이선스 및 배포 조건을 확인해야 합니다.

구성요소	주요 역할	구분해야 할 점
메인·거래 서버	메인 거래 서버는 다른 서버의 운영·설정과 플랫폼의 관리 기능·거래 설정을 통제하며 거래 처리도 수행할 수 있음. 추가 거래 서버는 거래 처리와 계정·거래 데이터를 담당	고객 접속 경로를 늘리는 것과 거래 처리 용량을 늘리는 것은 다름
액세스 서버	시스템의 방화벽·프록시 역할을 하며 관리자·매니저·트레이더의 접속 인증을 처리	거래 서버의 장애를 대신 해결하는 서버는 아님
히스토리 서버	시세 이력과 실시간 시세·뉴스·호가 등 데이터 피드 및 ECN 운영 관련 기능 담당	고객 거래 기록 전체의 독립 백업을 뜻하지 않음
백업 서버	거래·히스토리 서버 장애에 대비한 백업 사본을 만들고 주 서버의 자동 장애 조치(failover)를 지원	단순 파일 보관, 대기 환경, 전체 업무 복구의 범위는 서로 다름

위 역할 구분은 MetaQuotes의 MT5 라이선스 브로슈어에 설명된 구성요소를 요약한 것입니다. 실제 배포에서는 해당 버전의 공식 문서와 계약에 포함된 구성 범위를 함께 확인해야 합니다.

‘메인 서버’는 문맥에 따라 주 운영 서버를 뜻하기도 합니다. 이 글에서는 MT5의 메인 거래 서버를 가리키는 표현으로 사용하며, 플랫폼의 Main Label 계약과는 구분합니다. 제안서에는 ‘메인’이라는 말만 적기보다 실제 서버 역할과 복구 대상을 명시하는 것이 좋습니다.

메인·거래 서버: 계정과 거래 처리를 담당하는 핵심 영역

거래 서버는 계정과 주문·거래 처리의 중심에 있습니다. 고객 그룹과 거래 조건, 연결된 외부 시스템이 이 영역과 맞물리므로 사양뿐 아니라 접근 권한과 변경 관리도 중요합니다.

MetaQuotes의 MT5 라이선스 자료는 다른 서버의 운영과 설정을 관리하는 메인 거래 서버와, 거래 처리를 담당하는 거래 서버를 별도 구성요소로 설명합니다. 메인 거래 서버도 자체 계정·거래 데이터베이스를 관리하고 거래를 처리할 수 있습니다. 여러 거래 서버를 통한 분산 거래 처리 범위는 라이선스 등급에 따라 달라집니다. 모든 도입 환경이 동일한 서버 구성을 제공한다고 가정해서는 안 됩니다.

서버 사양은 등록 계좌 수만으로 정하기 어렵습니다. 실제 부하를 판단하려면 다음 정보를 함께 보아야 합니다.

동시에 접속하는 고객과 시간대별 이용 패턴
취급 상품 수와 시세 수신 빈도
주문·정정·취소 요청의 양과 집중 시간대
플러그인, 보고서와 API 연동이 발생시키는 작업량
데이터 증가 속도와 백업·보고 작업의 실행 시간

등록 계좌가 많아도 거래 활동이 적을 수 있고, 계좌 수가 적더라도 자동매매 요청이 특정 시간에 집중될 수 있습니다. CPU 코어 수나 메모리 용량만 비교하기보다 대표적인 운영 부하에서 처리 지연과 저장장치 성능을 확인해야 합니다.

신규 환경이라면 예상 부하와 여유 용량을 기준으로 시작하고, 운영 지표를 보면서 확장 시점을 정합니다. 기존 환경을 이전한다면 평균 사용량뿐 아니라 거래가 몰렸던 시간대의 기록도 준비하는 것이 좋습니다.

액세스 서버: 고객 접속 경로와 거래 처리 위치를 구분한다

액세스 서버는 MT5 시스템의 방화벽·프록시 역할을 하며 관리자·매니저·트레이더의 접속 인증을 처리합니다. 고객 단말의 접속 경로를 제공하고, 업데이트와 히스토리 데이터 캐싱 등의 보조 기능도 수행합니다. 여러 접속 지점을 구성하면 고객의 지역과 네트워크 상태에 맞춰 접속 경로를 설계할 수 있습니다.

그러나 고객 가까이에 액세스 서버를 두었다고 주문 처리 전체가 그 지역에서 이루어지는 것은 아닙니다. 해당 접속 지점에서 거래 서버까지의 경로도 필요하며, 외부로 전달되는 주문은 LP 연결 구간의 영향도 받습니다.

예를 들어 한국 고객이 주로 이용하고 LP 연결은 유럽에 있는 환경이라면, 아시아의 접속 지점과 유럽의 거래 처리 위치를 함께 검토할 수 있습니다. 이때 아시아 액세스 서버를 추가하는 것이 항상 더 빠른 결과를 만드는 것은 아닙니다. 실제 인터넷 경로와 서버 간 연결 품질을 측정해야 합니다.

액세스 서버를 추가할 때는 다음을 확인하십시오.

어떤 고객 지역의 접속 문제를 해결하려는가.
고객에서 액세스 서버까지, 액세스 서버에서 거래 서버까지의 지연은 각각 어떠한가.
접속 지점 하나가 중단되면 고객이 사용할 수 있는 대체 경로가 있는가.
여러 접속 지점이 같은 호스트나 네트워크에 의존하고 있지는 않은가.
거래 서버 자체가 중단되는 상황은 별도의 복구 설계로 다루고 있는가.

액세스 서버를 늘리는 것만으로 거래 처리 용량이나 전체 서비스 가용성이 자동으로 높아지는 것은 아닙니다. 해결하려는 병목이 고객 접속에 있는지, 거래 처리에 있는지부터 구분해야 합니다.

백업 서버, 백업 파일, 재해복구는 무엇이 다른가

‘백업 포함’이라는 표현은 계약마다 다른 의미로 쓰일 수 있습니다. 별도 저장소에 파일을 복사하는 서비스인지, 플랫폼의 백업 구성요소를 운영하는지, 장애 후 대체 환경에서 서비스를 재개하는지 확인해야 합니다.

구분	준비하는 것	별도로 확인할 사항
백업 파일·보관본	특정 시점의 데이터와 설정	보관 주기, 복원 가능성, 운영 환경과의 분리
플랫폼 백업 서버	거래·히스토리 서버의 백업 사본과 주 서버의 자동 장애 조치 기능	보호 범위, 데이터 상태, 전환 조건과 검증 결과
대기 운영 환경	장애 후 가동할 서버와 필요한 연결	실제 처리 용량, 네트워크·접근 권한과 외부 업체 연결
재해복구 체계	주요 장애 후 필요한 업무를 재개하는 절차와 환경	복구 순서, 담당자, 데이터 대조와 서비스 재개 기준

주 서버와 백업 서버가 서로 다른 가상머신이어도 같은 물리 호스트나 저장장치에 있다면 하나의 장애로 함께 영향을 받을 수 있습니다. 서버 이름이나 IP 주소가 다르다는 사실만으로 독립된 복구 환경이라고 판단해서는 안 됩니다.

또한 플랫폼 백업이 CRM 데이터, 고객 포털, 외부 보고 시스템과 브리지 설정까지 모두 보호한다고 가정하면 안 됩니다. 각 시스템의 백업·복구 책임과 연결 복원 절차를 따로 정해야 합니다.

복구 목표를 정한 뒤 배치 위치를 선택한다

복구 설계에서는 두 가지 목표를 먼저 정합니다.

복구 시점 목표(RPO): 장애 시 허용할 수 있는 데이터 손실의 시간 범위
복구 시간 목표(RTO): 중단된 서비스를 목표 수준으로 복구하기까지 허용할 시간

이 목표에 따라 필요한 데이터 보호 방식, 대기 자원과 복구 절차가 달라집니다. 같은 데이터센터 안의 장비 장애에 대비할 것인지, 지역 전체의 장애까지 대비할 것인지도 구분해야 합니다.

AWS의 재해복구 안내 역시 백업 후 복원과 대기 환경 운영을 서로 다른 전략으로 설명하고, 정기적인 검증을 강조합니다. 다만 일반적인 클라우드 복구 기능을 갖췄다고 MT5의 데이터 일관성과 서비스 전환까지 검증된 것은 아닙니다.

자동 전환을 계획한다면 장애 판정 기준과 이전 서버의 처리 중단 방식도 확인해야 합니다. 두 환경이 동시에 같은 업무를 처리하거나, 복구 과정에서 외부 거래 기록과 플랫폼 상태가 어긋나지 않도록 설계해야 합니다.

서버 위치: 고객과 LP 사이의 전체 경로를 본다

서버 위치를 고를 때는 회사가 등록된 국가나 고객이 가장 많은 국가만으로 결정하지 않는 것이 좋습니다. 고객 접속과 외부 거래 연결은 서로 다른 경로이기 때문입니다.

연결 구간	검토할 내용
고객 단말과 접속 지점	실제 고객 지역의 접속 안정성, 통신사별 경로와 지연 변화
액세스 서버와 거래 서버	서버 간 지연, 패킷 손실, 대체 경로와 네트워크 의존성
거래 환경과 LP 연결 지점	LP가 제공하는 실제 접속 위치, 연결 방식과 장애 시 대안
거래 환경과 CRM·업무 시스템	계좌 생성, 설정 반영, 조회·보고 요청의 처리 흐름
운영 환경과 복구 환경	데이터 전달 지연, 복구 시 접속 경로와 필요한 연결 복원

LP의 본사 주소와 실제 기술 접속 지점은 다를 수 있습니다. ‘런던 LP’라는 설명만으로 서버 위치를 정하기보다, 제공받은 연결 정보와 사용 가능한 네트워크 경로를 확인해야 합니다.

같은 도시나 데이터센터에 배치하면 거리 측면의 이점이 있을 수 있지만, 전용 연결이 자동으로 제공되는 것은 아닙니다. 실제 회선, 연결 서비스와 양쪽의 구성을 확인해야 합니다.

또한 네트워크 왕복 시간과 주문 체결 시간은 같은 지표가 아닙니다. 주문 처리는 서버 내부 작업, 연결 소프트웨어와 LP의 응답 등에도 영향을 받습니다. 낮은 핑 값만으로 체결 품질이나 슬리피지를 보장할 수는 없습니다.

전용 서버, 클라우드, 코로케이션을 어떻게 비교할까

호스팅을 선택할 때는 인프라를 확보하는 방식과 운영을 맡기는 범위를 따로 비교해야 합니다.

방식	기본 구조	검토할 사항
전용 서버 임대	공급업체의 물리 서버를 전용으로 임대	하드웨어 교체, 증설 소요 시간, 원격 지원과 네트워크 조건
클라우드 가상머신	선택한 지역에서 가상 서버·저장장치·네트워크 자원 사용	지속 성능, 저장장치·네트워크 한도, 배치 분리와 사용량 비용
코로케이션	직접 소유한 장비를 데이터센터에 설치	장비 구매·교체, 전력·공간·회선 계약과 현장 작업 지원

관리형 호스팅은 위 방식들과 별개의 운영 서비스입니다. 전용 서버나 클라우드 환경에 유지보수를 결합할 수 있으며, 계약에 따라 운영체제 관리만 포함되거나 MT5 설정·모니터링·백업 점검까지 포함될 수 있습니다.

MT5 설정, 모니터링과 백업 점검까지 포함한 운영 범위를 함께 검토하려면 MT5 서버 호스팅 페이지를 참고하십시오.

클라우드는 자원을 배포하고 조정하는 데 유연성이 있지만, 사양 변경이 언제나 무중단으로 이루어지는 것은 아닙니다. 플랫폼의 배포 조건, 운영체제와 외부 구성요소의 호환성도 확인해야 합니다. 거래 서버를 일반 웹 서버처럼 복제하고 자동 확장할 수 있다고 가정해서는 안 됩니다.

AWS와 Azure의 공동 책임 모델에서도 EC2나 Azure Virtual Machines와 같은 인프라 서비스(IaaS)를 사용하는 고객은 운영체제와 애플리케이션 관리 등의 책임을 가집니다. 인프라 공급업체의 책임과 브로커 또는 유지보수 업체의 책임을 구분하는 원칙은 호스팅 계약을 검토할 때도 중요합니다.

비용은 월 서버 임대료뿐 아니라 저장 공간, 백업 보관, 데이터 전송, 네트워크 연결, 운영 지원과 복구 환경까지 포함해 비교해야 합니다. 기본 요금에 포함된 항목과 별도 청구 항목을 구분하면 중복 계산이나 누락을 줄일 수 있습니다. 첫해 비용과 지급 일정은 브로커 구축 첫해 비용과 월 운영비에서 별도로 다룹니다.

LP·브리지·CRM 연결을 인프라 설계에 포함한다

MT5 인프라는 플랫폼 내부 서버만으로 끝나지 않습니다. 어떤 LP 연결을 사용하고, 계좌 생성과 고객 관리를 어떤 시스템에서 처리하는지에 따라 필요한 서버와 네트워크 접근 범위가 달라집니다.

MetaQuotes의 MT5 라이선스 자료는 Trade Gateways를 플랫폼과 공급업체 소프트웨어 사이에서 데이터를 교환하고 거래를 연결하는 네이티브 연결 구성요소로 설명합니다. 따라서 모든 MT5 환경에 제3자 브리지가 반드시 필요한 것은 아닙니다. 다만 선택한 LP와 필요한 기능이 해당 연결 방식에서 지원되는지 확인해야 합니다.

플랫폼에서 지원하는 연결 방식과 선택한 LP·솔루션의 조건을 기준으로 구성을 정하십시오. 브리지나 게이트웨이를 사용하는 경우에는 배치 위치, 연결 정보, 장애 시 연락 체계와 복구 후 재연결 절차를 함께 정리해야 합니다.

CRM과 고객 포털도 거래 서버와 별도의 애플리케이션·데이터 계층을 가질 수 있습니다. 포털에 고객 정보가 표시되는 것과 MT5 계좌에 승인된 그룹·거래 조건이 적용되는 것은 서로 다른 확인 항목입니다.

프로젝트 문서에는 다음 내용을 남기는 것이 좋습니다.

시스템별 계약 상대방과 운영 담당자
연결 대상, 필요한 통신 경로와 접근 권한
운영·테스트 환경의 구분
변경 시 함께 검수해야 하는 시스템
장애와 복구 시 공급업체가 수행할 작업

EBS FinTech는 LP·브리지·CRM 연동을 포함한 MT5 브로커 구축 과정에서 이러한 연결 관계와 작업 범위를 정리합니다.

견적을 받기 전에 정리할 여덟 가지

‘MT5 서버 견적이 필요하다’는 요청보다 운영 조건을 함께 전달하면 적절한 구성을 비교하기 쉽습니다.

플랫폼 상태: 신규 도입인지 기존 환경 이전인지, 사용 가능한 라이선스와 구성요소는 무엇인지 정리합니다.
고객 지역과 거래 시간: 주요 접속 지역, 거래가 집중되는 시간과 취급 상품을 전달합니다.
운영 부하: 예상 동시 접속, 주문 활동, 시세량과 데이터 증가를 정리합니다. 기존 운영 기록이 있다면 함께 제공합니다.
LP 연결: 선택한 LP와 실제 기술 접속 지점, 브리지·게이트웨이 사용 여부를 확인합니다.
업무 시스템: CRM, 고객 포털, 보고 도구와 필요한 API 연동을 나열합니다.
복구 목표: 허용 가능한 중단 시간과 데이터 손실 범위, 대비하려는 장애 유형을 정합니다.
운영 책임: 내부 인력이 맡을 업무와 외부 업체에 맡길 업무, 필요한 지원 시간을 구분합니다.
소유권과 인수인계: 계정·데이터·백업에 대한 접근 권한, 계약 종료 시 이전 절차와 자료 제공 범위를 정합니다.

제안서를 받은 뒤에는 서버 목록만 보지 말고 구성도, 역할별 배치, 연결 관계와 복구 범위를 함께 검토하십시오. ‘백업 포함’, ‘보안 포함’, ‘관리 포함’ 같은 항목은 실제 작업 내용으로 풀어서 확인하는 것이 좋습니다.

보안 서비스도 적용 대상을 구분해야 합니다. 고객 포털에 적용한 웹 방화벽이 MT5 접속 트래픽 전체를 보호하는 것은 아닙니다. 플랫폼 접속, 관리자 접근과 웹 서비스마다 필요한 통제가 다를 수 있습니다.

EBS FinTech의 MT5 서버 구축·호스팅 지원

EBS FinTech는 MT5 서버 구성과 배포, 관리 접근 설정, 고객 접속 환경, LP·CRM 연동과 운영 인수인계를 지원합니다. 서버 역할과 배치 위치를 검토하고, 프로젝트에 필요한 모니터링·백업·복구 범위를 정리합니다.

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

현재 환경의 서버 목록, 주요 고객 지역, LP 연결 위치와 복구 목표를 준비해 MT5 서버 호스팅 상담을 요청해 주십시오. 신규 구축과 기존 환경 개선에 필요한 구성을 구체화할 수 있습니다.

배포 이후의 일일·주간·월간 점검은 MT4·MT5 서버 유지보수 체크리스트에서 확인할 수 있습니다.

이 글은 일반적인 인프라 설계 참고 자료이며, 구체적인 구성과 작업은 해당 플랫폼의 공식 문서, 라이선스 조건 및 서비스 계약 범위에 따라 확인해야 합니다. MetaTrader 4·5는 MetaQuotes의 상표입니다.