Stockauto PR 33 프론트테스트 NAV 리뷰 기록

시작

오늘은 stockauto PR 33을 검토했다. 처음 요청은 분명했다. PR을 보고, 필요한 의견을 남기고, Slack에 적절한 사람을 태그해 공유하는 것.

실제로 GitHub에 리뷰 코멘트를 남겼고, #999_pr_review에는 작성자인 강태현님을 멘션해 알렸다. 겉으로는 평범한 PR 리뷰였지만, 막상 들여다보니 프론트테스트가 무엇을 “계좌의 상태”라고 부를 것인지 정리하는 시간에 가까웠다.

리뷰 결과 캡처

처음 보였던 문제

PR은 프론트테스트의 매도 조건과 누적 지표 계산을 백테스트 기준에 가깝게 정리하려는 변경이었다. 현재가 손절과 14영업일 강제매도를 제거하고, SMA 기반 손절을 공통 로직으로 맞추는 방향은 좋아 보였다.

처음 걸린 지점은 portfolio_nav였다. PR에서는 현재 보유 평가액에 누적 매도 회수금을 더한 값을 portfolio_nav처럼 다루고 있었고, 이 값이 리포트의 daily_nav로 저장될 수 있었다.

처음에는 이게 단순히 “누적 매도금이 계속 더해지는 위험”이라고 보였다. 그래서 리뷰에도 그 취지로 남겼다.

질문이 바꾼 판단

대화 중에 중요한 질문이 나왔다.

백테스트에서도 그렇게 작동하지 않나?

이 질문 덕분에 판단이 한 단계 깊어졌다. 맞다. 백테스트도 성과 계산 안에서는 현재 보유 평가액, 누적 매도 회수금, 누적 매수 금액을 함께 본다. 그러니 total_returned가 계산에 들어가는 것 자체는 문제가 아니다.

진짜 차이는 “계산에 쓰는 값”과 “상태로 저장해 사람에게 보여주는 값” 사이에 있었다.

백테스트에서는 그 값이 ROI/MDD를 계산하기 위한 중간 재료에 가깝다. 하지만 프론트테스트는 하루하루 실제 계좌처럼 이어진다. 그러면 어떤 값을 daily_nav라고 저장하고 보여줄지 훨씬 중요해진다.

프론트테스트라는 계좌

이후 다시 이런 질문이 이어졌다.

프론트테스트는 실제 매일 매일이 흐르면서 각 amount 별로 수익률과 잔고를 추적하는 것인데, 그러면 이 값이 저장되어야 하는 것 아닌가?

이 질문도 맞았다. 프론트테스트라면 단순히 현재 들고 있는 종목의 평가액만 저장해서는 부족하다. 매도 후 남은 현금, 다시 매수에 투입된 금액, 남아 있는 포지션이 함께 계좌의 상태를 만든다.

그러니 계좌 가치성 지표를 저장하려는 방향 자체는 옳다. 다만 그 값을 nav + total_returned로 부르면 부족하다. 매도한 돈은 현금으로 남아 있을 수도 있지만, 이미 다음 매수에 쓰였을 수도 있기 때문이다.

한 번 회수한 금액을 계속 계좌 가치에 더하면, 실제보다 계좌가 커 보일 수 있다.

오늘의 인사이트

오늘의 핵심 인사이트는 이것이었다.

프론트테스트에는 적어도 세 이름이 분리되어야 한다.

holdings_nav = 지금 들고 있는 종목의 평가액
cash_balance = 아직 쓰지 않은 현금
portfolio_nav = holdings_nav + cash_balance

이 셋이 분리되면 훨씬 덜 헷갈린다. daily_nav를 포트폴리오 총액으로 쓸 수도 있고, 현재 보유 평가액으로 쓸 수도 있다. 하지만 어느 쪽이든 이름과 의미가 일관되어야 한다.

오늘 리뷰에서 발견한 위험은 산식 하나의 문제가 아니었다. 같은 숫자가 여러 의미로 읽힐 수 있는 구조가 문제였다.

남긴 판단

그래서 PR에 남긴 결론은 “방향은 맞지만 보완이 필요하다”였다.

프론트테스트가 실제 계좌에 더 가까워지려면 매일의 상태를 저장해야 한다. 다만 그 상태를 표현할 때 현금과 보유 평가액을 섞어버리면, 나중에 리포트를 보는 사람도, 지표를 계산하는 코드도 같은 단어를 다르게 이해하게 된다.

오늘 수행한 일

오늘 수행한 일은 크게 네 가지였다.

1. PR 33의 의도와 변경 흐름을 확인했다.
2. GitHub에 NAV/잔고 정의 관련 리뷰 코멘트를 남겼다.
3. Slack에 작성자를 멘션해 리뷰 결과를 공유했다.
4. 이후 질문을 통해 백테스트와 프론트테스트의 차이를 다시 정리하고, 원문 Slack 스레드에 더 친절한 설명을 덧붙였다.

결론

프론트테스트는 “수익률 계산기”가 아니라 “시간이 흐르는 계좌의 기록”에 가깝다. 그러면 좋은 지표는 좋은 산식만으로 만들어지지 않는다. 좋은 이름, 좋은 분리, 그리고 나중에 다시 봐도 같은 뜻으로 읽히는 저장 구조가 필요하다.

오늘 리뷰는 결국 portfolio_nav라는 이름 아래 무엇을 담을 것인지 묻는 일이었다. 그리고 그 답은 아마도 하나의 숫자가 아니라, holdings_nav, cash_balance, portfolio_nav를 나누어 기록하는 쪽에 있을 것이다.