개인용 자동매매와 여러 고객에게 파는 서비스는 코드량이 두 배가 아니라 관심사가 다릅니다. 전략의 정확도보다 ‘고객 A의 사고가 고객 B에게 번지지 않는가’가 중요해집니다.
첫 버전에서 반드시 정해야 하는 세 가지
- 계좌 자격 증명을 누가 보관하는가
- 고객 간 격리를 어디서 보장하는가
- 실행 실패의 책임 경계가 어디인가
이 세 가지는 나중에 바꾸기가 매우 어렵습니다. 기능은 추가할 수 있지만 이 결정은 데이터 모델과 약관에 동시에 걸려 있습니다.
1. 자격 증명 보관
고객의 MT 계좌 로그인 정보를 우리 시스템이 보관해야 하는지부터 결정합니다. 선택지는 셋입니다.
- 보관하지 않음: 고객이 직접 계좌를 연결하고 우리는 발급된 계좌 참조만 저장합니다. 위험이 가장 낮습니다.
- 암호화 보관: 키 관리 서비스로 암호화해 저장합니다. 편의성이 높지만 유출 시 피해가 큽니다.
- 조회 전용만 보관: 성과 표시가 목적이면 투자자(조회 전용) 비밀번호만 받습니다. 매매 권한이 없어 위험이 크게 줄어듭니다.
서비스 성격이 ‘성과 대시보드’라면 세 번째로 시작하는 것이 합리적입니다. 주문 실행이 필요해진 뒤에 범위를 넓히면 됩니다.
2. 멀티테넌시: 격리 지점을 하나로
고객 데이터가 섞이는 사고는 대부분 조회 코드 한 줄에서 발생합니다. 테넌트 식별자를 개별 쿼리에서 챙기는 방식은 언젠가 빠집니다.
# 나쁜 패턴 — 매 쿼리에서 tenant_id를 기억해야 한다
rows = db.query("SELECT * FROM accounts WHERE tenant_id = ?", tid)
# 나은 패턴 — 접근 계층에서 강제한다
class TenantScope:
def __init__(self, tid): self.tid = tid
def accounts(self):
return db.query("SELECT * FROM accounts WHERE tenant_id = ?", self.tid)
def account(self, acc_id):
r = db.query("SELECT * FROM accounts WHERE tenant_id=? AND id=?", self.tid, acc_id)
if not r: raise NotFound() # 남의 계좌 ID를 넣어도 없는 것으로 처리
return r[0]요청 하나가 하나의 TenantScope만 갖게 만들고, 그 밖에서는 DB에 접근하지 않는다는 규칙을 둡니다. 코드 리뷰에서 확인할 지점이 하나로 줄어듭니다.
3. 실행 실패의 책임 경계
주문이 실패하면 누구의 책임인지 미리 정해 문서화해야 합니다. 브로커 거부, 마진 부족, 시장 휴장, 우리 서비스 장애, 고객 설정 오류 — 원인별로 처리 방식과 고지 방식을 정합니다.
기술적으로는 모든 주문 시도에 대해 요청·응답·시각을 남기는 것이 유일한 방어입니다. 분쟁이 생겼을 때 근거가 없으면 서비스 쪽이 불리합니다.
구성 요소는 결국 다섯 개
- 인증·계정: 고객 로그인, 요금제 상태, 권한
- 계좌 연결: 고객의 MT 계좌 등록과 연결 상태 표시
- 수집기: 잔고·포지션·내역을 주기적으로 가져와 저장 (구조)
- 실행기: 주문을 넣는 경로. 큐를 두어 동시 요청과 재시도를 통제합니다
- 과금: 요금제·사용량·결제 상태. 미납 시 어떤 기능이 멈추는지 정의
실행기에 큐를 두는 것은 선택이 아니라 필수에 가깝습니다. 고객 수가 늘면 같은 순간에 수십 건의 주문 요청이 몰리고, 그대로 흘려보내면 어느 요청이 실패했는지 추적할 수 없습니다.
과금 설계에서 흔한 함정
고객당 계좌 수가 늘어나는데 원가가 계좌 수에 비례하면 마진이 사라집니다. 요금제를 ‘계좌 수 무제한’으로 팔면서 원가가 계좌 단위인 구조가 가장 위험합니다. 원가 구조를 먼저 확인하고 판매 구조를 맞추세요. 요금 기준
초기 범위를 좁히는 방법
첫 버전에서 주문 실행을 빼는 것을 진지하게 검토할 만합니다. 조회 전용 서비스는 위험이 낮고, 고객이 원하는 것의 상당 부분(성과 가시성)을 이미 해결합니다. 실행을 추가하는 순간 약관, 장애 대응, 분쟁 처리가 따라옵니다.
- 1단계: 조회 전용 대시보드 — 계좌 연결, 성과 표시, 알림
- 2단계: 규정·리스크 감시 — 손실 한도, 노출 경고
- 3단계: 주문 실행 — 큐, 멱등성, 감사 로그를 갖춘 뒤에
서비스 형태에 따라 각국 금융 규제 적용 여부가 달라질 수 있습니다. 타인의 자금이나 계좌를 대상으로 하는 서비스라면 법률 검토가 필요합니다. 본 글은 기술 구조에 관한 내용입니다.
자주 묻는 질문
트레이딩 SaaS의 첫 버전에 주문 실행을 넣어야 하나요?
조회 전용으로 시작하는 편이 안전합니다. 성과 가시성만으로도 고객 요구의 상당 부분을 해결하며, 주문 실행을 추가하면 약관·장애 대응·분쟁 처리가 함께 따라옵니다.
고객 계좌 데이터가 섞이는 사고를 어떻게 막나요?
테넌트 식별자를 개별 쿼리에서 챙기지 말고, 요청마다 하나의 테넌트 범위 객체를 만들어 그 객체를 통해서만 데이터에 접근하도록 강제하는 방식이 안전합니다.