CASE STUDY
주요 증권사 일임계약 (160)
공모주 정보 제공과 청약–매도 일임 서비스의 백엔드입니다. 증권사 API 기반 일임계약 프로세스를 설계하고, 상태 정합성과 동시성 문제를 해결했습니다. 전체 6개 증권사 연동 중 하나·한국투자·KB·삼성 4사를 담당했습니다.
4사 (전체 6사)
담당 증권사
13개
운용 앱
문제정의
- 증권사 API 기반 일임계약의 상태를 컨트롤하기 어려웠습니다.
- 계약 상황에 따라 고객 화면이 달라, 화면이 의미하는 정보와 실제 데이터의 정합성을 보장해야 했습니다.
- 증권사 API·웹뷰에 종속적인 로직이라, 계약 완료 시점의 데이터를 충분히 보장하기 어려웠습니다.
- 무중단 배포 시점과 증권사별 업무·중단 시간을 동시에 맞춰야 했습니다.
- monolithic 레포는 CI/CD엔 유리했지만 서버–도메인 간 소통이 어려웠습니다.
문제해결
- SOLID를 지킨 API와 응답 비교 테스트 코드를 작성해, 에러 케이스 응답을 국제 표준 규격으로 반환했습니다.
- 증권사·에러 케이스별 뷰 테이블을 설계해 고객 상태·정보를 케이스에 맞춰 매핑했습니다.
- 증권사 업무 중단 시 오류 상태 대기값을 queue로 처리하고, 중단 후 증권사 API로 resolve하는 로직을 작성했습니다.
- 계약 과정의 동시성을 DB-lock 대신 Redis key-value로 진행 과정을 기록·판단하도록 바꿔 어드민 성능 문제를 해결했습니다.
- 백엔드에서 먼저 확인 가능한 외부·내부 요인(증권사 API, DB 가용성·정합성)을 파악해 세미 기획안을 기획·디자인에 전달했습니다.
- Bull Queue·Redis Producer–Consumer 구조로 10여 개 서버 간 통신을 구축하고, 외부 통신은 AWS SQS로 처리했습니다.
결과
- 증권사의 Spring 규격 통신을 NestJS로 받아 고객 상태를 추적하고 어드민 응대를 정확히 했습니다.
- 계약·청약 데이터를 DB에 정확히 적재하고, 계약 과정의 동시성 문제를 해결했습니다.
- 복잡했던 초기 플로우를 정리·문서화하고, FE·기획과 회의를 이끌어 deprecated 엔드포인트를 정리했습니다.
- 불필요한 로직·쿼리를 걷어내 핵심 경로만 남기는 방식으로 응답 속도를 개선했습니다.
- 사용률에 따라 노드 배치를 달리해 서버 가용성을 높였습니다.
기술스택
NestJSREST APIk8sTypeORMPostgreSQLRedisNCP