4. quant 프로젝트 회고

이번 글은 프로젝트를 만들면서 가장 오래 붙잡았던 두 가지, 즉 클라이언트 UI 설계와 Spring Boot와 Python을 어떻게 연결해야 사용자 경험이 자연스러워지는지에 대한 회고이다. 퀀트 플랫폼은 기능만 많다고 좋은 제품이 되지 않는다. 사용자는 숫자를 읽으러 오는 것이 아니라, 의사결정을 하러 오기 때문이다.

1. 주제 소개

[ 핵심 개념 ]

이 프로젝트의 UI는 일반적인 CRUD 화면과 조금 다르다. 사용자가 하는 일은 단순 조회가 아니라 아래처럼 여러 단계를 오가는 작업에 가깝다.

시장 확인 -> 종목 탐색 -> 전략 설계 -> 백테스트 -> 전략 저장 -> 실행 -> 포트폴리오 및 리스크 관리

즉, 한 화면에서 끝나는 제품이 아니라 흐름이 중요한 제품이다. 그래서 UI를 설계할 때 가장 먼저 고민한 것은 "무엇을 예쁘게 보여줄까"가 아니라 "사용자가 지금 어느 단계에 있는지 헷갈리지 않게 만들 수 있을까"였다.

[ 왜 어려웠는가? ]

퀀트 플랫폼은 정보량이 많다. 지표도 많고 차트도 많고 설정값도 많다. 잘못 만들면 화면은 풍부해 보이지만, 사용자는 무엇부터 봐야 할지 모르게 된다. 특히 아래 상황이 자주 문제였다.

전략 생성 화면에서 옵션이 너무 많아지는 문제
백테스트가 오래 걸릴 때 사용자가 멈춘 것으로 오해하는 문제
데이터 센터 동기화가 진행 중인데 완료처럼 보이는 문제
Spring과 Python이 분리되어 있어서 응답 지연을 사용자가 체감하는 문제

그래서 UI 고민은 곧 API 고민이기도 했다. 백엔드 응답 구조가 UX를 직접 결정했기 때문이다.

이 프로젝트는 Dashboard, Market Overview, Strategy Builder, Backtest, Portfolio, Stock Screener, Research Notebook, Strategy Library, Strategy Execution Center, Trade Center, Data Center, Strategy Optimization, Strategy Compare, Risk Center, Settings로 구성되어 있다.

문제는 모듈이 많아질수록 사용자가 길을 잃기 쉽다는 점이다. 그래서 화면을 나눌 때 아래 기준을 세웠다.

정보 보는 화면과 실행하는 화면을 분리한다
전략 생성과 전략 검증을 한 화면에 섞지 않는다
운용 중 상태와 과거 이력 조회를 구분한다
데이터 관리 화면은 일반 투자 흐름과 분리한다

예를 들어 Strategy Builder와 Backtest를 굳이 분리한 이유도 여기에 있다. 전략을 만드는 행위와 그 전략을 검증하는 행위는 연결되어 있지만, 사용자의 집중 포인트는 다르다. 하나는 규칙을 조합하는 화면이고, 다른 하나는 결과를 해석하는 화면이다.

[ 숫자보다 문맥을 먼저 보여주려 했다 ]

처음에는 카드와 차트를 최대한 많이 넣고 싶었다. 그런데 실제로는 숫자가 많을수록 사용자 이해가 빨라지는 것이 아니라 오히려 느려지는 경우가 많았다. 그래서 나중에는 "이 숫자가 무엇을 의미하는지"를 같이 보여주는 방향으로 바뀌었다.

예를 들어 백테스트 화면에서 중요한 것은 CAGR 숫자 하나보다도 아래 질문에 답하는 것이다.

지금 이 전략은 실행 중인가 대기 중인가
어느 단계에서 시간이 걸리고 있는가
결과가 아직 없는 것인가, 실패한 것인가
이전 결과를 보고 있는가, 방금 실행한 결과를 보고 있는가

즉, UI의 역할은 데이터를 표현하는 것뿐 아니라 상태를 해석해 주는 것이어야 했다.

3. Spring Boot와 Python을 어떻게 연결할지에 대한 고민

[ 단순 동기 호출은 UX를 망가뜨리기 쉬웠다 ]

처음에는 Spring Boot가 Python 엔진을 호출하고, Python이 계산을 끝내면 결과를 받아 바로 응답하는 구조를 생각했다. 하지만 백테스트나 대규모 데이터 동기화는 시간이 길어질 수밖에 없다. 이 구조로 가면 브라우저 입장에서는 그냥 "오래 기다리는 요청"이 된다.

이 방식의 문제는 명확했다.

사용자는 서버가 멈췄는지 모른다
네트워크나 브라우저 타임아웃에 취약하다
진행률을 보여주기 어렵다
실패했을 때 어느 단계에서 멈췄는지 알기 어렵다

그래서 결국 작업형 UX가 필요했다. 즉, 요청을 처리하는 것이 아니라 "작업을 등록하고 상태를 추적하는 구조"로 바꾸는 편이 맞았다.

[ jobId 중심 UX로 바뀐 이유 ]

현재 구조에서는 장시간 작업을 시작하면 즉시 jobId를 반환하고, 이후에는 상태를 주기적으로 조회한다. 이 방식은 단순해 보이지만 UX에는 큰 차이가 있다.

사용자는 요청이 접수되었는지 바로 알 수 있다
작업 ID와 상태를 기준으로 다시 연결할 수 있다
대기, 실행, 완료, 실패를 구분해 보여줄 수 있다
진행률과 단계 설명을 같이 표시할 수 있다

백테스트 화면에서 실제 진행률과 예상 진행률을 함께 보여주려 했던 것도 같은 맥락이다. 실제 진행률이 오지 않는 순간에도 사용자가 "아예 멈춘 것"으로 느끼지 않도록, 예상 소요 시간과 단계 라벨을 같이 보여주면 체감이 많이 달라졌다.

[ Data Center와 Backtest는 UX 방식이 달라야 했다 ]

흥미로웠던 점은 장시간 작업이라고 해서 모두 같은 UX를 쓰면 안 된다는 것이었다.

Data Center
- 운영성 화면이다
- 작업 큐, 진행률, 적재 건수, 최신 시각이 중요하다
Backtest
- 분석 화면이다
- 사용자는 결과 자체를 빨리 보고 싶어 한다
- 진행률과 함께 "무엇을 계산 중인지"가 더 중요하다

즉, 같은 polling 구조를 써도 문맥 설명은 달라야 했다. 데이터 적재는 운영자가 보는 느낌으로, 백테스트는 연구자가 기다리는 느낌으로 설계해야 화면이 자연스러웠다.

4. 예시로 이해하기

백테스트 버튼을 눌렀을 때 사용자가 겪는 경험을 생각해보면 이 고민이 더 분명해진다.

좋지 않은 경험은 이런 것이다.

버튼을 눌렀는데 아무 변화가 없다
20초 동안 스피너만 돈다
새로고침하면 상태가 사라진다
완료인지 실패인지 모른다

반대로 내가 만들고 싶었던 경험은 이런 쪽이었다.

작업이 접수되면 즉시 "대기 중" 또는 "실행 중" 상태를 보여준다
진행 단계 라벨을 보여준다
진행률이 있으면 표시하고, 없으면 예상 진행률이라도 안내한다
새로고침해도 같은 작업에 다시 연결된다
완료 시 결과 화면으로 자연스럽게 이어진다

이 차이는 결국 프론트 기술 선택만으로 해결되지 않았다. Spring Boot와 Python이 작업 상태를 구조화해서 전달해야만 가능한 UX였다.

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

[ 잘 풀렸던 부분 ]

긴 작업을 일반 요청과 분리하면서 사용자 불안을 줄일 수 있었다
모듈이 많아도 사용자 흐름 기준으로 역할을 나눌 수 있었다
전략 설계와 결과 검증 화면의 목적을 구분할 수 있었다
Data Center, Job Monitor 같은 운영성 UI를 별도 문맥으로 잡을 수 있었다

4. Quant 프로젝트 회고