1. quant 프로젝트 회고

이번 글은 코드를 본격적으로 만들기 전, 왜 이 프로젝트를 퀀트 투자 플랫폼으로 잡았는지와 설계 단계에서 어떤 개념을 먼저 공부했는지를 정리한 회고이다. 처음에는 화면부터 만들고 싶었지만, 막상 퀀트라는 단어를 제대로 이해하지 못한 상태에서 기능만 나열하면 금방 흔들린다는 점을 느꼈다. 결국 설계의 출발점은 프레임워크가 아니라 투자 개념을 공부하는 일이었다.

0. 퀀트 투자란 무엇인가

퀀트 투자는 말 그대로 정량적 기준을 바탕으로 투자 의사결정을 내리는 방식이다. 여기서 정량적이라는 말은 숫자로 표현할 수 있는 조건과 규칙을 사용한다는 뜻이다. 예를 들어 "좋은 회사 같아 보인다"가 아니라 "ROE가 일정 수준 이상이고, PBR이 낮고, 최근 6개월 수익률이 양호한 종목"처럼 비교 가능한 기준으로 바꾸는 접근이라고 볼 수 있다.

즉, 퀀트 투자는 감을 완전히 배제하는 투자라기보다, 사람의 직관에만 의존하지 않고 데이터를 기준으로 판단하려는 방식에 가깝다. 미리 정한 규칙에 따라 종목을 고르고, 같은 규칙을 과거 데이터에 적용해 보고, 결과가 어떠했는지 다시 검증하는 흐름이 핵심이다.

여기서 중요한 점은 퀀트 투자가 단순히 수학을 많이 쓰는 투자 방식이라는 의미는 아니라는 점이다. 실제로는 아래와 같은 질문에 체계적으로 답하려는 방법에 더 가깝다.

• 어떤 종목을 후보로 볼 것인가
• 어떤 지표를 기준으로 점수를 매길 것인가
• 몇 종목을 선택할 것인가
• 언제 다시 종목을 바꿀 것인가
• 결과를 어떤 기준으로 검증할 것인가

예를 들어 어떤 사람이 "최근에 많이 오른 종목이 앞으로도 더 오를 것 같다"고 생각할 수 있다. 이 생각을 퀀트 방식으로 바꾸면 "최근 12개월 수익률이 높고, 최근 1개월 급등은 과하지 않은 종목을 정해진 개수만큼 선별해 월 1회 리밸런싱한다"처럼 규칙으로 표현할 수 있다. 다시 말해 퀀트는 투자 아이디어를 반복 가능한 규칙으로 바꾸는 과정이라고 할 수 있다.

그래서 퀀트 투자에서 자주 함께 등장하는 개념이 팩터, 유니버스, 리밸런싱, 백테스트, 벤치마크, 리스크 관리이다. 이 개념들은 각각 따로 있는 것이 아니라 하나의 흐름으로 연결된다. 종목 범위를 정하고, 평가 기준을 고르고, 포트폴리오를 구성하고, 과거 성과를 검증하고, 마지막으로 실제 운용 가능한 전략인지 위험까지 함께 확인하는 식이다.

결국 퀀트 투자는 "무엇을 살까"보다 "어떤 규칙으로 사고팔까"를 먼저 정의하는 투자 방식이라고 정리할 수 있다. 이 프로젝트도 바로 그 지점에서 출발했다. 단순히 종목 차트를 보여주는 서비스가 아니라, 투자 규칙을 만들고 검증하고 관리하는 프로그램을 만들고 싶었기 때문이다.

1. 주제 소개

[ 핵심 개념 ]

퀀트 투자는 감이나 뉴스 헤드라인만으로 판단하기보다, 미리 정한 규칙을 데이터에 적용해 의사결정을 내리는 방식이라고 볼 수 있다. 다시 말해 "좋아 보이는 종목"을 고르는 것이 아니라 "어떤 조건을 만족한 종목을 어떤 방식으로 고를 것인가"를 먼저 정의하는 접근이다.

이 프로젝트를 설계하면서 가장 먼저 정리한 개념은 아래와 같았다.

• 팩터: ROE, PBR, 모멘텀처럼 종목을 평가하는 기준
• 유니버스: 전략이 탐색할 종목 범위
• 리밸런싱: 일정 주기마다 종목과 비중을 다시 조정하는 과정
• 벤치마크: 전략 성과를 비교할 기준 지수
• 백테스트: 과거 데이터에 규칙을 적용해 성과를 검증하는 과정
• 리스크 지표: CAGR, Sharpe, MDD, 변동성처럼 수익과 위험을 함께 보는 기준

이 개념들은 이름만 보면 익숙하지만, 실제 제품 기능으로 옮기려면 훨씬 구체적으로 정리해야 했다. 예를 들어 "모멘텀을 본다"는 말만으로는 부족하다. 몇 개월 수익률을 볼지, 상장폐지 종목은 어떻게 처리할지, 거래량이 적은 종목은 제외할지까지 정해야 비로소 구현 가능한 요구사항이 된다.

[ 왜 필요한가? ]

처음에는 대시보드, 전략 만들기, 백테스트, 포트폴리오 같은 화면 이름부터 먼저 정의했다. 그런데 곧바로 부딪힌 문제가 있었다. 화면이 많아도 그 안에 들어갈 계산 규칙이 정리되지 않으면 결국 숫자만 보여주는 껍데기가 되기 쉬웠다.

예를 들어 사용자가 전략 만들기 화면에서 아래 순서로 작업한다고 가정해보자.

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

이 흐름이 자연스럽게 이어지려면, 각 단계가 어떤 데이터를 입력으로 받고 어떤 결과를 다음 단계에 넘기는지 먼저 정리되어야 한다. 즉, 설계 단계에서 공부한 퀀트 개념은 단순한 배경지식이 아니라 제품의 화면 구조와 API 설계를 결정하는 기준이었다.

2. 설계 단계에서 먼저 공부한 것들

[ 투자 아이디어를 프로그램 기능으로 풀어내는 법 ]

가장 먼저 한 일은 투자 아이디어를 프로그램이 처리할 수 있는 기능 요구사항으로 쪼개는 일이었다. 예를 들어 "재무가 좋은데 저평가된 종목을 고른다"는 문장을 그대로 구현할 수는 없다. 대신 아래처럼 풀어야 했다.

• 재무가 좋다는 것은 ROE가 일정 기준 이상인가
• 저평가라는 것은 PBR이나 PER이 특정 구간 이하인가
• 너무 작은 종목은 제외할 것인가
• 거래량이 부족한 종목은 필터링할 것인가
• 최종적으로 몇 종목을 뽑을 것인가

이 과정을 거치면서 퀀트 전략은 멋진 문장이 아니라, 필터와 점수 계산, 정렬 규칙, 리밸런싱 주기, 비중 배분 규칙의 조합이라는 점이 분명해졌다.

[ 백테스트는 단순 재생이 아니라 검증이다 ]

처음에는 백테스트를 "과거 가격에 적용해보는 기능" 정도로 생각했다. 그런데 공부를 하다 보니 여기서 중요한 것은 단순 재생이 아니라 검증의 질이었다.

특히 아래 항목들은 설계 단계에서 반드시 이해해야 했다.

• 거래 비용을 무시하면 결과가 과하게 좋아질 수 있다
• 미래 데이터를 현재 시점에서 참조하면 룩어헤드 바이어스가 생긴다
• 지금 살아남은 종목만 보면 생존 편향이 생길 수 있다
• 리밸런싱 주기와 체결 기준이 성과를 크게 바꾼다
• CAGR만 보고 전략을 고르면 큰 낙폭을 놓치기 쉽다

즉, 백테스트 화면은 차트만 예쁘게 그리는 곳이 아니라 전략의 허점을 드러내는 장소여야 했다. 이 생각이 나중에 MDD, 변동성, 승률, 트레이드 로그, 시그널 타임라인 같은 항목을 넣게 된 이유이기도 하다.

[ 위험 관리를 처음부터 모듈로 생각한 이유 ]

설계 초반에는 위험 관리를 나중 문제로 미루기 쉽다. 하지만 퀀트 프로젝트에서는 오히려 반대였다. 수익률 지표만 보여주면 사용자는 전략이 좋아 보인다고 착각할 수 있다. 그래서 Risk Center를 별도 모듈로 두고, VaR, Beta, Volatility, Sector Exposure 같은 항목을 아예 플랫폼 구조 안에 넣었다.

여기서 중요한 점은 리스크 관리가 성과 분석의 부가 기능이 아니라는 점이다. 다시 말해 전략이 실제 운용 단계로 넘어가려면, 백테스트 결과와 리스크 지표가 같은 흐름 안에서 연결되어야 했다.

3. 설계하면서 머릿속에서 바뀐 것들

[ 처음 생각보다 더 "플랫폼"에 가까운 프로젝트였다 ]

처음에는 전략 만들기와 백테스트 정도만 있으면 되는 줄 알았다. 그런데 퀀트 업무 흐름을 따라가다 보니 필요한 것이 계속 늘어났다.

• 데이터 적재 상태를 확인하는 화면
• 종목 검색과 종목 상세 데이터 화면
• 전략 실행과 중지 상태를 보는 화면
• 작업 큐와 장시간 작업 모니터링
• 뉴스와 이벤트를 함께 보는 대체 데이터 화면

결국 이 프로젝트는 단순한 백테스트 툴이 아니라, 데이터 수집부터 전략 생성, 검증, 실행, 사후 점검까지 이어지는 운영형 플랫폼이라는 관점으로 재정의되었다.

[ 한국 시장과 미국 시장을 함께 보려면 설계가 달라진다 ]

처음에는 국내 종목만 다루는 쪽이 구현이 쉬워 보였다. 하지만 KOSPI, KOSDAQ과 미국 주식을 함께 다루려면 심볼 체계, 거래일 차이, 통화, 데이터 공급원 차이까지 고려해야 했다. 그래서 종목 마스터 자체에 시장 구분과 거래소, 통화, 자산군을 넣는 방향으로 설계가 커졌다.

즉, 퀀트 개념 공부는 투자 이론을 이해하기 위한 목적도 있었지만, 실제로는 데이터 모델을 안정적으로 설계하기 위한 준비 작업이기도 했다.

4. 예시로 이해하기

설계 단계에서 자주 했던 상상 실험은 이런 것이었다.

사용자가 "ROE가 높고 PBR이 낮으면서 최근 6개월 모멘텀이 좋은 종목 20개를 월간 리밸런싱으로 운용하고 싶다"고 말한다고 해보자.

이 문장을 시스템이 이해하려면 아래 정보로 바뀌어야 한다.

• 유니버스: 한국 전체 시장인지, 미국 전체 시장인지, 특정 섹터인지
• 필터: ROE 하한, PBR 상한
• 점수화: 모멘텀 점수 반영 방식
• 선택 개수: 20개
• 리밸런싱: 월간
• 비중 방식: 동일 비중인지 점수 비례인지
• 검증 기준: CAGR, Sharpe, MDD, 거래 로그, 벤치마크 비교

즉, 사람이 말하는 전략 문장은 결국 구조화된 입력값 집합으로 바뀌어야 한다. 이 전환이 제대로 설계되지 않으면 나중에 화면은 많아도 전략을 일관되게 저장하거나 재실행할 수 없게 된다.

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

[ 설계 단계에서 개념 공부를 먼저 한 장점 ]

• 기능 우선 개발에서 자주 생기는 방향 흔들림이 줄어든다
• 데이터 모델과 API 필드가 왜 필요한지 설명하기 쉬워진다
• 백테스트, 포트폴리오, 리스크 관리가 한 흐름으로 연결된다
• UI가 단순 카드 나열이 아니라 실제 사용자 작업 흐름을 따라가게 된다

[ 아쉬웠던 점 ]

반대로 개념 공부가 길어질수록 구현을 미루게 되는 문제도 있었다. 퀀트 용어는 파고들수록 끝이 없어서, 어디까지 공부하고 어디부터 제품으로 고정할지 경계선을 잡는 일이 생각보다 어려웠다. 결국 설계 단계에서는 완벽한 금융 이론보다 "지금 구현 가능한 수준의 규칙"을 우선해야 했다.

[ 주의할 점 ]

퀀트 프로젝트를 처음 만들 때 가장 조심해야 할 것은 용어를 안다고 구현이 쉬워지는 것이 아니라는 점이다. 예를 들어 팩터, 리밸런싱, 위험 관리라는 단어를 알아도, 이를 테이블 구조와 API 요청, 계산 순서로 풀지 못하면 실제 제품은 만들어지지 않는다.

6. 정리

정리하면, 이 프로젝트의 출발점은 화면 디자인이나 프레임워크 선정이 아니라 퀀트 투자 개념을 제품 요구사항으로 번역하는 일이었다. 팩터, 유니버스, 백테스트, 리스크 관리 같은 개념을 먼저 이해했기 때문에 나중에 Strategy Builder, Backtest, Portfolio, Risk Center 같은 모듈도 자연스럽게 연결할 수 있었다.

결국 중요한 것은 퀀트를 "복잡한 금융 용어"로 보는 것이 아니라, 데이터를 기반으로 규칙을 만들고 검증하는 시스템으로 이해하는 것이다. 따라서 첫 설계 단계에서는 멋진 기능 목록보다, 어떤 개념이 어떤 입력과 계산과 결과로 이어지는지부터 정리하는 것이 훨씬 중요하다고 느꼈다.