조각투자증권(STO) 거래 시스템 설계 프로젝트를 시작하며

 최근 금융 시스템과 거래 처리 구조에 대한 관심이 커지면서, 단순한 CRUD 서비스가 아니라 실제 금융 서비스에 가까운 시스템을 직접 설계해보고 싶다는 생각이 들었다. 그 과정에서 눈에 들어온 주제가 바로 조각투자증권 시스템이었다.

 

 

 조각투자는 하나의 자산을 여러 투자자가 나누어 보유할 수 있도록 만든 구조라는 점에서 흥미롭지만, 시스템 관점에서 보면 더 매력적인 요소가 많다. 단순히 상품을 등록하고 매수·매도하는 수준이 아니라, 자산 등록과 심사, 증권 발행, 청약, 주문, 체결, 정산, 보유 원장 관리, 수익 분배, 공시, 감사 추적까지 이어지는 긴 흐름을 가진다. 즉, 하나의 서비스 안에 금융 시스템에서 중요하게 다루는 핵심 요소들이 모두 녹아 있다.

 

 나는 이 프로젝트를 통해 “조각투자 앱”을 만드는 것이 아니라, 금융 시스템답게 동작하는 조각투자증권 플랫폼을 설계하는 것을 목표로 삼으려고 한다. 그래서 화면이나 단순 기능보다 먼저, 시스템의 중심이 되는 구조를 어떻게 잡을지 고민했다. 특히 다음 세 가지를 중요한 설계 기준으로 두고 시작하려고 한다.

 

 

 첫째, 정합성이다.
금융 시스템에서는 잘못된 거래 한 건이 단순 오류로 끝나지 않는다. 청약 금액, 예수금, 보유 수량, 체결 내역, 정산 결과가 모두 연결되어 있기 때문에 하나라도 어긋나면 전체 데이터의 신뢰가 흔들린다. 그래서 이 프로젝트에서는 주문, 체결, 정산을 명확히 분리하고, 현금과 수량의 변화를 원장 중심으로 관리하는 구조를 우선적으로 설계할 예정이다.

 둘째, 투자자 보호와 운영 관점이다.
조각투자는 일반적인 커머스와 달리 투자 적합성, KYC, 투자 한도, 공시, 이상거래 탐지 같은 요소가 중요하다. 그래서 단순한 거래 기능만 넣는 것이 아니라, 회원/KYC 시스템, 공시/알림 시스템, 감사로그와 이상거래 탐지까지 함께 설계 범위에 포함하려고 한다.

 셋째, 성능과 확장성이다.
유통시장에서는 동일 자산에 대해 동시에 주문이 몰릴 수 있고, 이때 정합성을 지키면서도 처리 성능을 확보해야 한다. 이 프로젝트에서는 주문 관리 시스템(OMS)과 체결 엔진을 분리하고, 종목별 파티셔닝이나 큐 기반 처리 구조, 락 전략 비교 같은 방식으로 성능 개선 포인트도 함께 고민해보려 한다. 단순히 기능이 돌아가는 수준이 아니라, 왜 이런 구조를 선택했는지 설명할 수 있는 설계를 목표로 한다.

 

 현재 구상 중인 핵심 서브시스템은 다음과 같다.

• 회원/KYC 시스템
• 자산 등록/심사 시스템
• 증권 발행/청약 시스템
• 주문 관리 시스템(OMS)
• 체결 엔진
• 예수금/원장/정산 시스템
• 수익분배 시스템
• 공시/알림 시스템
• 이상거래 탐지 및 감사로그 시스템

 처음에는 이 많은 영역을 한 번에 설계하는 것이 막막하게 느껴졌지만, 흐름을 정리해보니 결국 중심은 명확했다.
이 시스템은 발행시장과 유통시장을 거쳐, 원장과 정산으로 귀결되는 구조다. 따라서 가장 먼저 해야 할 일은 화면이나 API를 나열하는 것이 아니라, 자산이 어떻게 증권이 되고, 투자자가 어떻게 청약하고, 그 결과가 어떻게 보유 수량과 현금 원장에 반영되며, 이후 거래와 수익 분배까지 어떻게 이어지는지를 정의하는 것이었다.

 그래서 이 프로젝트는 다음 순서로 정리해보려고 한다.

1. 조각투자증권 시스템의 도메인과 전체 생명주기 정리
2. 핵심 서브시스템과 책임 분리
3. 원장 중심 데이터 모델과 ERD 설계
4. 주문, 체결, 정산 흐름 설계
5. 수익분배, 공시, 감사로그 설계
6. 동시성 제어와 성능 개선 포인트 정리

 이 글은 그 출발점이다.

 앞으로의 글에서는 단순히 “이런 테이블을 만들었다”는 수준이 아니라, 왜 이 구조가 필요한지, 금융 시스템에서는 어떤 기준이 중요한지, 정합성과 성능을 동시에 만족시키기 위해 어떤 선택을 했는지를 중심으로 하나씩 풀어보려고 한다.

이번 프로젝트를 통해 단순한 웹 서비스 구현을 넘어, 금융 도메인을 이해하고 시스템 구조를 설계하는 경험을 더 깊게 쌓아보고 싶다.