"얼음장 같은 회사에서, 방 하나에 시작했다" ”멋진 동료들과 함께한 TF 회고”
25.12.11 yoda
스크린샷 하나로 2편을 시작하려 한다.
7개의 acceptance test. 이게 우리가 3달 동안 풀어야 했던 문제 목록이었다. 단순히 기능을 만들었냐가 아니라, "이 TF로 해결되어야 할 문제들이 실제로 해결됐는가"를 기준으로 완료를 정의했다.
5개 통과. 2개 CANCEL.
CANCEL된 2개는 실패가 아니었다. TF 진행 중에 비즈니스 판단으로 scope out된 것들이었다. 이것도 TDD 방식론의 연장이었다. 만들어야 하는 것과 만들지 않아도 되는 것을 명확히 구분하는 것이 중요한거구나 깨닫게되었다.
사실 TF 시작 전에는 백테스팅 성능을 트래킹하는 수단 자체가 없었다. 얼마나 걸리는지, 어떻게 동작하는지, 어디서 느린지. 아무것도 몰랐다.
프레임워크를 완성하고 나서 처음 한 일이 기준점을 만드는 것이었다. 과거 특정 시점을 프로비저닝하고, 그 시점부터 백테스트를 재연했다. 성능 트래킹조차 안 됐던 환경에서 측정 가능한 환경을 만들었다.
결과는 신규 Framework 는 20분 이내, 기존 대비 약 10배 빨라진 수치였다.
단순히 코드를 최적화한 게 아니었다. 프레임워크 디자인을 일원화하고, 병목이 발생하던 구조 자체를 걷어낸 결과였다. 1편에서 리버스 엔지니어링으로 Data Loader를 해체하고, 불필요한 캐싱 레이어와 중복 매핑을 제거한 것. subscribe 기반으로 데이터 피딩 구조를 바꾼 것. 그 모든 결정이 쌓여서 나온 숫자였다.
실제 운용 중인 공모펀드 전략 2종을 새 프레임워크로 포팅했다. 기존 백테스팅 결과와 비교했을 때 매우 유사하게 나왔다.
TF의 본질인, 효용가능성 높은 효율적인 이벤트 기반 백테스팅 프레임워크 개발. 모델에 대한 성능이 아닌, 동일한 로직내에서 결과에 해당하는 숫자가 조금만 달라져도 검증이 안 된 것이다. 유사하게 나왔다는 건 프레임워크가 기존 로직을 정확하게 재현했다는 뜻이었다.