
이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다
개발이 시작되었다...!
현재까지 한 80% 개발이 완료되었다.
수많은 오류, 이슈가 있었지만 기억나는 몇 가지 이슈가 있다.
문제 내용
백엔드 개발 과정에서 stock, sector 데이터가 external-assistant 모듈 내에서만 관리되고 있었다. 하지만 다른 서비스(internal-assistant, chart-similarity-service)에서도 동일한 데이터를 참조해야 했기 때문에, 각 모듈마다 중복된 코드가 생기고, 데이터 불일치 문제가 발생했다.
해결 방법
stock, sector 관련 엔티티 및 공용 로직을 common-service 모듈로 이관하여 통합 관리했다. 각 마이크로서비스가 공통 모듈을 직접 참조하도록 구조를 개선했다.
결과적으로 중복 코드가 제거되고, 데이터 구조와 참조 방식이 표준화되어 서비스 간 데이터 일관성과 유지보수 효율이 크게 향상되었다.
“공통화는 결국 ‘편리함’이 아니라 ‘책임’이었다.”
한 번 고치면 세 서비스가 다 움직이기 때문에, 공통 모듈 설계 단계에서의 명확한 책임 분리가 얼마나 중요한지 절실히 느꼈다.
문제 내용
사용자의 평균 거래 일수, 거래 금액 등 통계성 데이터를 실시간으로 계산해야 하는 구간이 있었는데, 데이터 양이 많을 때는 API 응답 시간이 급격히 늘어나는 문제가 발생했다.
해결 방법
통계 데이터를 배치 프로세스로 정기 계산해 DB에 저장하도록 구조를 개선했다. 실시간 요청 시에는 사전에 계산된 데이터를 조회하도록 변경해 응답 속도를 대폭 개선했다.
배치 주기 및 캐싱 전략을 조정하여, 데이터 최신성과 성능 간의 균형을 유지했다.모든 걸 실시간으로 계산하려는 집착에서 벗어나야 했고, 데이터는 즉시성보다 신뢰성이 우선이라는 걸 배웠다.
MSA 공통 모듈 구조 정립

API 일관성 확보


인프라 환경 구축 및 검증
데이터 처리 자동화

공통 모듈(common-service)은 편리하지만, 동시에 모든 서비스의 근간이 된다. 작은 수정 하나에도 전체 서비스가 다시 빌드되기 때문에, "진짜 공통이어야 하는 것만 올려야 한다"는 기준이 정말 중요했다.
MSA가 너무 어렵다. 코드를 쪼개는 건 쉬웠지만, 경계선을 정의하는 건 어려웠다. 한 줄짜리 DTO도 어느 서비스에 있어야 하는지를 놓고 팀 내에서 많이 고민했다.
PM으로서 백엔드 구조가 안정되어야 프론트와 데이터팀이 자유롭게 움직일 수 있었다. 개발 일정 조율과 기술적 의사결정을 병행하는 일이 쉽지는 않았지만, 결국 팀이 "한 방향으로 움직이게 만드는 것"이 PM의 역할이라는 걸 다시 느꼈다.