[신투 프디아] 그룹 단위 주식 공동 매매 - 결제는 정수, 거래는 소수

 

바쁘다 바빠 현대 사회 🏃‍♀️

투게더를 개발하기 시작한게 엊그제 같은데 벌써 다음 주면 발표와 수료식이 다가온다.

마지막까지 힘내서 달려보자!

 

그럼 글 시작!

이번 주는 이슈가 정말 많았다.

그중에서도 특히 기억에 남는 두 가지가 있다.

 

1️⃣ 그룹 단위 공동 매매 시, 결제 이슈

2️⃣ 한국투자증권 OpenAPI WebSocket 연동

 

오늘은 그중 첫 번째, 그룹 공동 매매 결제 이슈에 대해 이야기해보려고 한다.

 

 

---

문제의 시작: 소수점은 거래되는데, 결제는 정수만 된다?

주식 거래는 소수점 단위로 가능하다.

예를 들어 42,500원의 주식을 7명이 공동으로 산다면, 인당 6071.428571..원을 내야 한다.

 

문제는 결제 시스템(은행, 결제 API)이다.

결제 시에는 소수점을 지원하지 않기에, 6,071원 또는 6,072원 단위로만 결제할 수 있다.

 

이 단순한 제약이 기존 트레이딩 로직에 큰 혼선을 불러왔다.

 

- 금액을 내림 처리하면 총 결제 금액이 부족해 주문 실패

- 금액을 올림 처리하면 일부 사용자가 초과 납부 → 잔액 정산 필요

- 보유 수량은 소수점인데 결제 금액은 정수 → 매도 시 금액 불일치 발생

 

---

해결 방안 1️⃣ : 서비스에서 차액을 보전해주자 (실패)

처음에는 이렇게 생각했다.
“금액이 애매하게 남는다면, 서비스에서 그만큼 메워주면 되지 않을까?”

 

이는 카카오페이의 자투리 금액 지원을 보고 떠올린 아이디어였다.

 

자투리 금액 지원

 

예를 들어, 42,500원을 7명이 나누면 인당 6,071.428…원이다.

그룹원마다 6,071원으로 결제하고 남은 0.428원 x 7명분은 우리 서비스가 부담하는 방식을 떠올렸다.

반대로 매도 시에는 소수점 차액을 올림 처리하여 서비스가 소액을 회수하는 구조다.

 

카카오페이는 여러 명이 금액을 나눌 때 잔액이 생기면 플랫폼이 대신 부담한다.

사용자 간 정산의 복잡성을 플랫폼이 대신 해결해주는 방식이다.

 

하지만 우리의 경우는 결제 서비스가 아닌, 투자·거래 시스템이다.

단순히 서비스를 통해 돈을 메워주는 방식으로는 문제가 근본적으로 해결되지 않았다.

 

1. DB에 기록된 보유 단가와 실제 결제 금액이 일치하지 않아, 매도 시 오차가 누적된다.

2. 사용자 거래 내역이 소수점 없이 저장되어 > 데이터 정합성 유지가 불가능하다.

 

결국, '서비스가 대신 내주는 방식'은 결제 플랫폼에는 통하지만,

거래 정합성이 중요한 트레이딩 시스템에서는 통하지 않는다.

 

---

해결 방안 2️⃣ : 애초에 ‘나누어 떨어지는 값’만 계산하자 (성공)

그래서 결제 단계에서 맞추는 대신,
매수 투표 단계에서부터 나누어떨어지는 금액만 계산하기로 했다.

 

42,500 ÷ 7 = 6,071.428… → 자동으로 6,071원 × 7 = 42,497원

 

이렇게 매매 가능한 정수를 계산해

사용자에게 그 값을 매매 투표 생성 전 보여주기로 했다.

 

초기에는 이 로직을 Trading-service에 두려고 했지만,
이 서비스는 주문·체결에 집중해야 하므로
소수점 반올림과 같은 비즈니스 로직은 프론트엔드 혹은 Vote-serice로 분리하는 것이 낫다고 판단했다.

 

정리하자면!

1. 프론트엔드에서 먼저 정수 단위로 나누어 떨어지는 금액을 계산한다.

 - 사용자에게 나누어 떨어지는 금액을 표시하고,

 - 확인된 금액으로 투표를 진행한다.

2. Trading-service는 전달받은 정수 금액으로만 실제 주문, 체결을 수행한다.

3. 이후에는 Vote-service(백엔드)에서 프론트가 전달한 금액을 한 번 더 검증, 확정하는 구조로 고도화하는 방식을 고민중이다.

 

결론 ✍️

결제는 정수, 거래는 소수

둘 사이의 경계를 명확히 관리하는 것이

그룹 기반 트레이딩의 핵심이었다!