브로커나 IB의 백오피스에서 반복되는 작업은 대체로 같습니다. 고객이 계좌를 만들면 CRM에 입력하고, 입금이 들어오면 확인하고, 월말에 거래량을 집계해 리베이트를 계산합니다. 이 흐름을 사람이 하면 실수가 나고, 규모가 커지면 사람으로는 불가능해집니다.
자동화 대상은 네 갈래
- 계좌 상태 동기화: MT 계좌의 잔고·순자산·거래 여부를 CRM 레코드에 반영
- 입출금 반영: 결제 시스템과 MT 계좌 사이의 잔고 처리 확인
- 거래량 집계: 리베이트·수수료 계산의 근거 데이터
- 상태 기반 조치: KYC 미완료 계좌 제한, 장기 미거래 계좌 표시 등
1. 계좌 상태 동기화
가장 먼저 만들게 되는 부분이고, 구조는 단순합니다. 계좌 목록을 순회해 요약을 조회하고 CRM에 씁니다. 주의점은 두 가지입니다.
- 전량 갱신 대신 변경분만. 계좌가 수천 개면 매번 전체를 조회할 수 없습니다. 마지막 갱신 시각과 우선순위(활성 계좌 먼저)를 두고 순환합니다.
- 실패를 상태로 기록. 조회 실패를 ‘잔고 0’으로 쓰면 안 됩니다. 별도의 ‘조회 실패’ 상태를 두고 마지막 성공 시각을 남깁니다.
for acc in due_for_refresh(limit=200): # 오래된 것부터 배치로
try:
s = fetch_summary(acc.mt_id)
crm.update(acc.crm_id, balance=s["balance"], equity=s["equity"],
synced_at=now(), sync_state="ok")
except Exception as e:
crm.update(acc.crm_id, sync_state="failed", sync_error=str(e)[:200])2. 입출금은 ‘확인’이지 ‘실행’이 아닙니다
여기서 설계를 잘못하면 사고가 큽니다. 결제 시스템의 입금 이벤트를 받아 자동으로 계좌에 반영하는 흐름을 만들 때, 반드시 멱등성을 확보해야 합니다. 같은 웹훅이 두 번 오면 두 번 반영되는 구조는 언젠가 실제로 두 번 반영합니다.
결제 시스템의 트랜잭션 ID를 유일 키로 저장하고, 이미 처리한 ID면 아무 것도 하지 않고 성공을 반환합니다. 그리고 자금 이동은 자동 실행보다 ‘검증 후 승인’ 단계를 두는 편이 안전합니다.
3. 거래량 집계와 리베이트
리베이트 분쟁의 원인은 대체로 계산식이 아니라 데이터 기준입니다. 다음을 명시적으로 정해두어야 합니다.
- 기준 시각: 진입 시각인지 청산 시각인지. 월말 경계에 걸친 거래의 귀속이 달라집니다.
- 랏 환산: 심볼별 계약 단위가 다르므로 ‘랏’을 단순 합산하면 상품 간 가중치가 왜곡됩니다.
- 취소·정정 거래: 사후 조정된 거래를 어떻게 처리할지.
- 스냅샷 보관: 집계 시점의 원본 내역을 그대로 보관합니다. 나중에 재계산이 필요할 때 유일한 근거입니다.
내역 구조는 MT4와 MT5가 다릅니다. 부분 청산이 별건으로 기록되는 차이를 무시하면 거래 건수가 부풀려집니다. 플랫폼 차이를 먼저 확인하세요.
4. 권한과 감사
백오피스는 고객 계좌를 조회하고 조치할 수 있는 시스템입니다. 그래서 두 가지가 필요합니다.
- 역할 분리: 조회만 가능한 계정과 조치 가능한 계정을 구분합니다. 지원팀 전원이 자금 관련 조치 권한을 가질 이유는 없습니다.
- 감사 로그: 누가 어떤 계좌에 무엇을 했는지 시각과 함께 남깁니다. 사후 확인이 불가능한 시스템은 사고가 났을 때 원인을 특정할 수 없습니다.
연동 방식 선택
MT 서버에 직접 붙는 방식(브로커 자체 서버 접근)과 계좌 단위 API로 접근하는 방식이 있습니다. 자체 MT 서버를 운영하는 브로커라면 전자가 가능하지만, IB나 화이트라벨 파트너는 계좌 단위 접근만 가능한 경우가 많습니다.
계좌 단위 접근으로 시작하면 계좌 수가 늘어날 때 비용 구조가 중요해집니다. 계좌 단위 과금이면 고객 확대가 곧 원가 증가입니다. 요금 기준을 먼저 확인하는 편이 좋습니다.
정리
브로커 백오피스 자동화에서 어려운 부분은 조회가 아니라 ‘돈이 움직이는 경로’입니다. 멱등성, 집계 기준, 감사 로그 — 이 세 가지를 처음부터 만들어 두면 나머지는 반복 작업의 자동화일 뿐입니다.
자주 묻는 질문
입금 웹훅을 계좌에 자동 반영해도 되나요?
반영하려면 멱등성이 필수입니다. 결제 시스템의 트랜잭션 ID를 유일 키로 저장해 중복 처리를 막고, 자금 이동은 자동 실행보다 검증 후 승인 단계를 두는 편이 안전합니다.
리베이트 분쟁을 줄이려면 무엇을 정해야 하나요?
귀속 기준 시각(진입 또는 청산), 심볼별 계약 단위를 반영한 랏 환산, 취소·정정 거래 처리 방식, 그리고 집계 시점의 원본 내역 보관입니다.