5. quant 프로젝트 회고

이번 글은 전체 프로젝트를 만들고 나서 무엇이 아쉬웠고, 앞으로 어떤 점을 보완하면 더 나아질지에 대한 회고이다. 개발을 하다 보면 일단 동작하는 것을 만드는 데 집중하게 된다. 그런데 퀀트 플랫폼은 "된다"와 "믿고 쓸 수 있다" 사이의 거리가 꽤 멀다. 이 차이를 크게 느낀 프로젝트였다.

1. 주제 소개

[ 핵심 개념 ]

이 프로젝트는 꽤 많은 축이 동시에 움직인다.

웹 UI
플랫폼 백엔드
Python 계산 엔진
외부 데이터 수집
전략 저장과 재실행
백테스트와 리스크 분석
작업 큐와 운영 모니터링

즉, 단순 기능 하나를 더 붙인다고 끝나는 구조가 아니다. 한 부분을 수정하면 다른 부분에 영향이 가기 쉽다. 그래서 마지막 회고에서는 무엇을 잘 만들었는지보다, 무엇을 더 단단하게 만들어야 하는지에 더 집중해 보려고 한다.

[ 왜 이런 회고가 중요한가? ]

퀀트 프로젝트는 겉으로 보기에는 차트와 지표가 중심이지만, 실제 품질은 데이터 신뢰도와 재현성, 예외 처리, 운영 안정성에서 갈린다. 다시 말해 기능이 많다고 좋은 플랫폼이 되는 것이 아니라, 같은 전략을 다시 돌렸을 때 비슷한 의미의 결과가 나오고, 실패했을 때 이유를 추적할 수 있어야 한다.

2. 만들면서 느낀 부족한 점

[ 데이터 신뢰도에 대한 고민이 더 필요하다 ]

가장 먼저 떠오르는 보완점은 데이터 계층이다. 현재 구조는 Yahoo Finance, SEC, Nasdaq Trader, KRX KIND, NewsAPI를 역할별로 잘 나눠 쓰고 있다. 하지만 외부 데이터 소스를 사용하는 순간, 애플리케이션 품질은 우리 코드만으로 결정되지 않는다.

앞으로 더 보완하고 싶은 점은 아래와 같다.

데이터 소스별 갱신 주기와 신뢰 수준을 명확히 표시하기
동일 종목에 대해 서로 다른 소스 값이 충돌할 때 우선순위를 더 체계화하기
적재 실패와 부분 성공을 운영 화면에서 더 분명히 보이기
데이터 품질 검사 규칙을 별도 레이어로 분리하기

예를 들어 "가격 이력은 들어왔지만 펀더멘털은 비어 있다" 같은 상태를 단순 누락이 아니라 운영 가능한 상태 코드로 다뤄야 한다고 느꼈다.

[ 테스트 전략이 더 촘촘해야 한다 ]

이 프로젝트는 화면, Kotlin 서비스, Python 엔진, 외부 데이터 소스가 함께 움직이기 때문에 테스트 범위도 넓다. 그런데 실제로는 기능이 커질수록 수동 확인 비중이 높아질 수밖에 없었다.

특히 앞으로 보완하고 싶은 테스트는 이런 것들이다.

전략 생성부터 백테스트 완료까지의 E2E 시나리오
외부 데이터 소스 실패 시 fallback 동작
장시간 작업의 상태 전이 검증
동일 조건 재실행 시 중복 작업 방지 검증
종목 유니버스 변경이 백테스트 결과에 미치는 영향 검증

즉, 단위 테스트만으로는 부족하고, 실제 사용자 흐름 기준의 시나리오 테스트가 더 필요하다고 느꼈다.

[ 전략 품질을 평가하는 기준이 더 다양해져야 한다 ]

현재도 CAGR, Sharpe, MDD, 변동성, 승률 같은 핵심 지표를 다루고 있지만, 더 깊게 가려면 전략 해석 축이 늘어나야 한다.

예를 들어 앞으로는 아래 항목을 더 고민하고 싶다.

기간 분할 검증 결과를 더 쉽게 비교하기
특정 시장 국면에서만 잘 되는 전략인지 분리해 보기
turnover와 거래 비용 민감도 분석 강화
factor exposure 변화 추적
전략별 실패 패턴 요약

즉, "좋은 전략인가"를 묻는 질문을 "수익률이 높았는가"에서 끝내지 않고, "어떤 조건에서 무너지는가"까지 확장해야 한다고 느꼈다.

3. 구조적으로 더 개선하고 싶은 부분

[ Kotlin과 Python 사이 계약을 더 엄격하게 만들고 싶다 ]

지금 구조는 역할 분리가 잘 되어 있지만, 양쪽 서비스가 동시에 진화할수록 공통 계약 관리가 더 중요해진다. 특히 이런 부분을 더 강화하고 싶다.

상태값 enum 표준화
날짜와 시간 포맷 일관화
메타데이터 필드 구조 버전 관리
에러 코드와 사용자 메시지 분리

현재도 잘 동작하지만, 장기적으로는 "문자열 필드 몇 개 맞추는 수준"보다 더 명시적인 계약 관리가 필요하다고 본다. 예를 들어 공통 스키마 문서나 계약 테스트를 두면 유지보수가 훨씬 쉬워질 것이다.

[ 운영 관측성을 더 높이고 싶다 ]

작업 큐와 진행률 구조는 어느 정도 갖춰졌지만, 운영 관점에서 더 필요한 것들이 보였다.

어떤 외부 API가 자주 실패하는지
어느 단계에서 시간이 많이 쓰이는지
어떤 유니버스 조건에서 백테스트가 느려지는지
어떤 작업이 반복해서 실패하는지

즉, 지금은 "상태를 볼 수 있다"에 가깝고, 앞으로는 "왜 느리고 왜 실패하는지 설명할 수 있다"까지 가야 한다고 느꼈다.

4. 예시로 이해하기

예를 들어 사용자가 특정 전략으로 백테스트를 실행했는데 결과가 기대보다 좋지 않다고 해보자. 지금도 결과 차트와 지표는 볼 수 있다. 하지만 앞으로 더 좋아지려면 아래 질문에도 답할 수 있어야 한다.

이 전략은 어느 리밸런싱 구간에서 가장 많이 흔들렸는가
특정 섹터 쏠림이 심했는가
뉴스 이벤트가 겹친 시점에 손실이 커졌는가
거래 비용 가정을 바꾸면 결과가 얼마나 달라지는가

즉, 퀀트 플랫폼이 성숙해질수록 정답 하나를 보여주는 시스템보다, 전략을 의심하고 해석할 수 있게 도와주는 시스템에 가까워져야 한다고 생각한다.

5. 장점 / 한계 / 주의사항

[ 지금 단계에서 분명히 의미 있었던 점 ]

단순한 백테스트 도구가 아니라 플랫폼 흐름을 갖춘 구조를 만들었다
데이터, 전략, 실행, 리스크, 운영 상태를 하나의 제품 안에서 연결했다
Spring Boot와 Python 엔진의 책임 분리가 비교적 명확하다
장시간 작업을 UI와 운영 화면에서 추적할 수 있다

[ 아직 부족한 점 ]

데이터 품질 보증 체계가 더 촘촘해야 한다
E2E 테스트가 더 필요하다
운영 로그와 메트릭 기반 분석이 더 강화되어야 한다
사용자에게 설명되는 에러 메시지가 더 친절해져야 한다
전략 품질을 해석하는 보조 도구가 더 많아져야 한다

[ 주의할 점 ]

퀀트 프로젝트는 계산 로직만 잘 만든다고 완성되지 않는다. 데이터가 흔들리면 결과도 흔들리고, 상태 관리가 약하면 사용자 신뢰도도 함께 떨어진다. 결국 제품의 완성도는 알고리즘, 데이터, UX, 운영성이 같이 올라가야만 나온다는 점을 계속 의식해야 했다.

정리하면, 이 프로젝트는 분명히 많은 기능을 갖춘 퀀트 플랫폼으로 자라났지만, 아직 더 단단해질 여지가 크다. 앞으로는 새로운 기능을 무작정 늘리기보다 데이터 신뢰도, 계약 일관성, 테스트, 운영 관측성, 전략 해석 도구를 보강하는 쪽이 더 중요하다고 본다. 결국 중요한 것은 "무엇을 더 만들까"보다 "지금 만든 것을 얼마나 믿을 수 있게 만들까"이다. 따라서 다음 단계에서는 기능 확장과 함께 품질과 설명 가능성을 높이는 작업에 더 집중하는 것이 맞겠다는 생각이 남았다.

7. 결과

GitHub : https://github.com/dsds60321/quant

5. Quant 프로젝트 회고