[최종 프로젝트 - 현재 시세를 반영한 모의 투자 서비스] 5분 브리핑

✅ 구현한 기능

📌 주문 관리: 지정가(Limit) 및 시장가(Market) 매수/매도 주문

• 지정가 매수/매도: 사용자가 원하는 가격과 수량으로 주문 생성
• 시장가 매수/매도: 현재 시장 가격으로 즉시 주문 실행
• 주문 조회 및 취소: 계좌별 주문 내역 조회 및 취소 기능 제공

 

✅ 주요 로직

1. 지정가 주문 (LimitOrderService)
   • 계좌 유효성 검사 및 잔액 확인
   • 지정가 × 수량 → 총액 계산 및 잔액 차감
   • 주문 객체 생성 및 저장, 응답 DTO 반환
2. 시장가 주문 (MarketOrderService)
   • 계좌 및 주식 조회 후 시장 가격으로 즉시 주문 처리
   • 보유 자산 수량 또는 계좌 잔액 업데이트
3. 주문 조회 (OrderService)
   • QueryDSL 기반 커서 페이징으로 효율적 조회
   • 계좌 ID, 주문 유형, 상태, 날짜 필터링 지원

 

✅ 프로젝트 배경

📌 목적

• 실시간 주식 시세 기반의 모의 투자 플랫폼 구축
• 사용자가 투자 경험을 쌓을 수 있도록 지원

 

✅ 요구사항

📌 기능적 요구사항

• 지정가/시장가 주문 생성, 조회, 취소
• 계좌 잔액 및 보유 주식 관리

📌 비기능적 요구사항

• 멀티스레드 환경에서도 동시성 보장
• 높은 처리 속도 및 데이터 무결성 유지
• 확장 가능한 아키텍처 설계 (예: 분산 환경)

 

✅ 의사결정

⚠️ 문제 정의 (Why)

• 멀티스레드 환경에서 동일 계좌에 대한 동시 주문 처리 시
  • 잔액 및 보유 자산 데이터 불일치 발생

 

 

2개의 동일한 보유 주식 매도시 하나의 주문만 실행됨.

📌 원인

• 동시성 제어 부족 → 여러 스레드가 동일 자원(계좌, 보유 자산)을 동시에 수정

 

✅ 해결 방법

• 계좌 잔액 및 보유 자산 업데이트 시 락 필요
• 동시 접근을 제한해 단일 스레드만 수정하도록 제어

📌 기술 선택지 비교

기술	장점	단점	적합성
비관적 락	- DB 수준 무결성 보장 - 구현 간단	- 성능 저하 - 데드락 위험 - 분산 환경 부적합	단일 DB 환경에 적합
낙관적 락	- 충돌 적을 경우 성능 우수 - 구현 간단	- 충돌 많으면 재시도 비용 증가 - 롤백 처리 복잡	주문 충돌 많아 부적합
분산 락 (Lettuce)	- 가볍고 빠름 - 높은 확장성	- 설정 복잡 - 락 해제 실패 위험	확장성 좋지만 관리 어려움
분산 락 (Redisson)	- 자동 락 갱신 - 간단한 API - 다양한 락 지원	- Redis 의존성 - 설정 복잡도 증가	확장성과 안정성 모두 만족

 

 

✅ 최종 선택: Redisson

📌 선택 이유

• 확장성: 분산 환경에서 동시성 제어 가능
• 안정성: 자동 락 갱신으로 락 해제 실패 방지
• 간편한 API: getLock, lock 등으로 빠른 통합 가능

 

✅ 회고

📌 Redisson의 장단점

장점

1. 자동 락 갱신: 네트워크 지연이나 예외 상황에서도 락 유지
2. 확장성: 분산 환경 대응 가능 → 사용자 증가에 유리
3. 간편한 API: 빠른 구현과 유지보수 가능

단점

1. Redis 의존성: Redis 장애 시 락 기능 중단
2. 설정 복잡도: Redisson 설정 학습 필요
3. 성능 오버헤드: Redis 통신 비용
4. 락 관리 부담: 락 대기 시간 증가 위험 존재

 

✅ 설계/기술 선택 학습 회고

• 동시성 문제의 원인을 직접 파악하고, 해결 방법을 다양하게 탐색
• Redisson을 활용한 확장 가능한 동시성 제어 적용 경험
• QueryDSL 기반 커서 페이징으로 대량 주문 처리 최적화 학습