[신투 프디아] 그룹형 주식 투자 서비스 - ToGather 프로젝트 회고

 

드디어 반 년간의 프디아 교육 기간이 끝나고 최종 발표까지 끝마쳤다!

오늘은 파이널 프로젝트였던 ToGather 프로젝트에 대해 간단하게 회고해보려고 한다!

 

 

---

 

9월 25일부터 10월 23일까지 진행된 신한투자증권 프로디지털아카데미 파이널 프로젝트가 마무리됐다.

주제는 'MSA & 클라우드를 활용한 금융 프로젝트' 개발이였다.

 

우리 팀은 🧶공동 목표 달성을 위한 그룹형 주식 투자 서비스, ‘ToGather’를 개발했다.

 

 

아래는 ToGather 프로젝트의 GitHub 레포지토리다.

ToGather-Final

---

 

기획 배경

시작은 모임 통장이었다.

친구들과 여행 자금을 모으거나, 계모임·동아리 회비를 관리하기 위해

모임통장을 이용해 정기적으로 돈을 모으는 사람들이 늘고 있다.

최근 금융권에서도 이러한 모임통장을 고객 락인(Lock-in) 수단으로 주목하며 전략적으로 확대하고 있다.

모임 통장의 인기!

 

문제 상황

하지만 모임통장을 사용하다 보면, 돈이 쌓이기만 하고 활용되지 못한 채 묵혀지는 경우가 많다.
특히, 예금이나 입출금 계좌 위주로 구성되어 있다 보니 모은 돈을 적극적으로 불려나가기엔 한계가 있다.

 

이에 우리 팀은 ‘국내 주식 소수점 거래’에 주목하여
모임통장의 자금을 함께 투자하고 성장시킬 수 있는 서비스 'ToGather'를 기획하게 되었다.

 

주식도 다함께 할 수 있으면 좋겠다!

 

핵심 기능

차례대로 다음과 같은 흐름으로 구성되어있다.

 

- 계좌 개설 & 그룹 생성

계좌 개설 & 그룹 생성

 

- 포트폴리오

포트폴리오

 

- 주식 리스트 & 캔들 차트

주식 리스트 & 캔들 차트

 

- 주식 매매 (매수, 매도)

매수 & 매도

 

- 투표 & 히스토리

 

투표 & 히스토리

- 페이(거래 내역, QR 스캔)

페이(거래 내역, QR 스캔)

 

---

시연 영상

 

---

프로젝트 회고

이 프로젝트를 떠올리면 가장 먼저 생각이 나는건 단연 트레이딩 시스템이다.

한땀한땀 갈고 닦은.. 기능들..

설계부터 개발까지 고려해야 할 요소들이 정말 많았다.

 

그중에서도 특히 기억에 남는 이슈를 꼽자면,

 

1. 매매 로직 구현을 위한 캐싱 테이블 도입 & ERD 전면 수정

 ㄴ 중간 발표 QnA 시간에, 선임님께서 “ERD가 실제 매매에 사용되는 실무 테이블 구조와 굉장히 유사하네요.”라고 말씀해주셨다.

너무! 큰 감동..이었다. 사실 그 ERD를 만들면서 하루 반이 걸렸었다.

프론트엔드, 백엔드 강사님 바짓가랑이를 붙잡아가면서 수정하고 수정했는데 알아봐주셔서 정말 감사했다..

 

[신투 프디아] ERD 트레이딩 시스템 개선기 - 왜 다시 설계했을까?

 

 

2. 결제가 정수가 되도록 매매 로직 개선

ㄴ 그룹원별 결제 금액이 소수점 단위로 분배되면서, 일부 그룹원의 원화 결제 처리에 오류가 발생했다.

 

예를 들어, 삼성전자(84,000원)를 세 명이 공동 구매할 경우 인당 약 0.3333주, 즉 27,997.2원이 결제되어야 한다.

하지만 주식 거래는 소수점 단위가 가능해도, 결제는 반드시 정수 단위여야 한다.
그래서 체결 금액이 정수가 되도록 금액을 조정하는 방식을 도입했다.

 

마지막까지 머리를 굴려가며 고민했던 기능이라 더욱 기억에 남는다.

매매 시 가격 조정 로직

 

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

 

 

3. MSA 설계 & API Gateway 활용

ㄴ MSA 구조로 설계하며 정말 많은 이슈를 마주했다.

개발을 진행할수록 통신, 인증, 배포 등 고려해야 할 부분들이 계속해서 늘어났다.

 

아래는 JWT 검증 로직에서 중복 문제를 해결한 과정이다.

JWT 검증 로직 중복 이슈

 

 

차례대로 왜 MSA 구조를 선택했는지, 그리고 API Gateway를 통해 어떤 문제를 해결했는지 그 과정을 자세히 정리했다. 👇

 

[신투 프디아] MSA 좋은 듯 어렵다 - 왜 투게더는 MSA로 설계했을까?

 

[신투 프디아] API Gateway와 MSA에서의 경로 설계 - /api 접두사, 꼭 써야 할까?

 

 

4. Websocket: 프론트 - 백엔드 연동 이슈

ㄴ 처음에는 기본 WebSocket(ws) 으로 잘 동작하고 있었지만, 프론트엔드에서 SockJS로 교체한 뒤부터 문제가 발생했다.

우리 서비스는 API Gateway를 통해 포트별로 요청을 라우팅하기 때문에 별도의 CORS 설정이 필요 없었다.
그런데 이상하게도 계속 CORS 에러가 발생했다.

 

해결 과정이 길어 더보기에 넣었다!

속는 셈치고 하위 서비스에도 CORS 설정을 추가해봤지만, 이번엔 403 Forbidden 오류가 떴다.
Gateway에서 이미 인증·인가 필터를 거친 요청만 통과하도록 되어 있었기 때문에, CORS 요청이 Gateway 단에서 차단된 것이다.

 

문제의 근본적인 원인은 SockJS의 통신 방식에 있었다.
SockJS는 초기 연결 시 WebSocket으로 바로 접속하지 않고

먼저 HTTP 요청(XHR 폴백 방식)으로 핸드셰이크를 시도한 뒤
그 다음에야 WebSocket으로 업그레이드한다.

 

즉, 첫 요청이 WebSocket이 아닌 일반 HTTP 요청이기 때문에

Gateway 입장에서는 이를 WebSocket 요청으로 인식하지 못하고

기존의 CORS·인증 필터를 타게 된다.

 

그 결과, CORS가 이중으로 검증되고 핸드셰이크가 정상적으로 완료되지 않았던 것이다.

• CORS는 API Gateway에서만 허용, 하위 서비스에서는 제거
• Gateway가 WebSocket 연결을 직접 받아 하위 서비스로 라우팅
• 프론트엔드는 SockJS 대신 순수 WebSocket(ws) 으로 복귀

위의 방식으로 해결했다. 이 이슈는 따로 글을 써서 첨부해야 할 것 같다!

웹소켓 연결 중 CORS 중복 에러 이슈

 

5. 현재가 - Rest 방식, 호가 - 웹소켓 구독 이슈

ㄴ 주식 화면에서는

• 리스트 페이지에서 종목의 현재가를 보여주고
• 매매 페이지에서는 호가창(매수·매도 단가) 을 표시해야 했다.

그러나 현재가와 호가 데이터가 각각 별도의 WebSocket 채널로 구독되어야 해서

두 데이터를 동시에 받으려면 구독 수가 두 배로 늘어났다.
게다가 API에서 제공하는 최대 구독 한도가 있어 그대로 구현하기엔 부담이 컸다.

 

따라서, 다음처럼 해결했다.

• 호가 데이터 → 실시간성이 중요하므로 WebSocket으로 구독
• 현재가 데이터 → 초 단위 실시간성보다 안정성이 중요하므로 1분 주기 REST API로 갱신

또한, 장 마감 이후에는 WebSocket 구독이 불가능하기 때문에
그 시점부터는 자동으로 REST API로 폴백(fallback) 하도록 설계했다.

 

이 방식으로 서버 부하를 줄이면서도 실시간성을 유지할 수 있었다.

웹소켓 현재가, 호가 구독 이슈

 

6. 팀 로그!

위에서 언급한 것들 외에도, 정말 많은 기술적 이슈들이 있었다.
그때마다 우리 팀은 매주 작성하는 이슈 리포트에 최대한 자세히 기록하려고 노력했다.

 

개발 일정에 쫓기면서도 매주 금요일마다 팀 로그를 자세히 쓰려니 쉽지 않았다.

그래도 지금 돌이켜보면, 이 기록들이 우리 팀이 성장하는 발자취가 되었다고 생각한다.

한땀한땀 팀로그

 

7. 최종 발표 회고

사실 최종 발표 직전까지도 이슈가 많았다.

 

바로 배포 과정에서 문제가 생겨, 만들어둔 몇몇 기능들이 하루 전에 모두 날아가 버린 것이다.

그래서 다같이 급하게 날라간 기능을 복구시키느라 돌아가면서 한 명씩 울 뻔했다.

사실 난 전 날 밤에 피피티 만들다가 정말 울었다..

 

다행히 거의 다 복구를 시켰고

기존 개발 단계에서의 완성도가 100이었다면 최종 발표 때의 완성도는 85 정도였던 것 같다.

아직도 이게 아쉽다!

 

특히 장 마감 이후에도 매매 제안이 가능하도록 구현해두었는데,
시연 당일 배포된 서비스에서는 WebSocket 연동 이상으로 매매 창이 뜨지 않는 문제가 발생했다.
그래서 급하게 로컬 환경에서 실행한 버전을 보여드려 임기응변으로 문제를 해결했었다.

 

아직도 요상한 것은 최종 발표가 끝나고 인프라 팀원이 재배포하니 매매창이 멀쩡하게 잘 떴다는 점..

정말 뭐였을까..?

 

결국 당일까지 팀원 모두가 밤을 새워 PPT를 완성했고

발표 후에 QnA 때 “필요한 내용이 잘 정리되어 있어서 보기 좋았다”는 피드백을 들었다.

 

발표 준비할 시간도 부족해서 프리스타일로 발표했는데 다 끝나니 도파민이 싹 돌더라..

 

 

 

우리 서비스가 잘한 점은,
유저 → 그룹 → 투표 → 매매 → 페이로 이어지는

하나의 완전한 로직 사이클을 설계하고 구현했다는 것이다.

 

MSA 구조라 복잡함이 많았음에도

각 서비스 간의 연동을 끝까지 해냈고,
실제로 굴러가는 하나의 사이클을 완성한 것이 정말 뿌듯했다!

 

특히 매매에서 멈추지 않고 페이까지 연결한 점이
우리 서비스만의 확실한 차별점이었다고 생각한다.

 

 

 

무엇보다 다섯 명의 모든 팀원들이

각자의 영역에서 굵직하고 도전적인 개발 과제를 하나씩 맡아

끝까지 완성해냈다는 점이 정말 자랑스럽다!

 

회고를 쓰는 지금은 수료도 했고, 우수 수료생 발표도 나온 상황이다.

다음 글은 수료 회고 및 인턴 합격 글로 돌아올게요!

 

가보자!