플랫폼과
포트폴리오 제출

마감 1분 전의 제출, 그리고 비어 있는 리더보드

2026년 가을 학기의 어느 금요일 오후 4시 59분. 주간 제출 마감 1분 전, 한 수강생이 이번 주 포트폴리오 비중표를 올리고 "제출 성공" 배지를 확인한다. 그런데 리더보드를 새로고침해도 점수가 없다. 무언가 잘못된 걸까.

잘못된 것이 아니다. 그 제출은 지금 여행 중이다. 인터넷 가장자리의 검문소에서 토큰을 확인받고, 서버가 미리 파 둔 지하통로를 지나, 접수창구에서 번호표를 받고, 대기줄에 서 있다. 채점은 실행자가 자기 속도로 진행하고, 결과는 그다음에야 게시판에 붙는다. "제출 성공"과 "채점 완료"는 서로 다른 두 사건이다.

이 부록은 그 여행의 경로를 따라간다. 왜 관문이 여러 개인지(§1), 왜 서버에서 연습하면 안 되는지(§2), 왜 비중에 상한이 있고 현금 도피는 안 되는지(§3), 그리고 그 모든 것이 어떤 점수로 환산되는지(§4). 규칙마다 "무엇을 걸러 내려는 장치인가"라는 질문 하나를 붙들고 가면, 암기할 것은 거의 없다.

경비실, 지하통로, 번호표 — 관문마다 푸는 문제가 다르다

하나의 프로그램이 인증도 하고 보안도 지키고 계산도 하면 안 될까. 기술적으로는 가능하지만, 그런 프로그램은 한 군데가 고장 나면 전부 멈춘다. 시스템 설계의 오래된 원칙은 "한 구성요소는 한 가지 문제만 풀게 하라"다.

검문을 서버 본체가 아니라 앞단에서 하는 이유는 단순하다 — 잘못된 요청도 서버까지 도달하면 그만큼 시간과 메모리를 쓴다. 초대장 없는 손님은 파티장 입구가 아니라 단지 정문에서 돌려보내는 편이 낫다. 그리고 접수와 실행의 분리가 바로 도입 장면의 답이다. 접수창구가 채점까지 끝내고서야 응답한다면, 마감 직전 제출이 몰리는 순간 접수가 통째로 마비된다. "제출 성공"과 "채점 완료"가 다른 사건인 것은 버그가 아니라 생존 설계다.

엔진이 두 개인 이유 — 두 채점자가 서로의 실수를 잡는다

플랫폼의 백테스트 엔진은 둘이다. 직접구현 엔진은 체결·비용·룩어헤드 차단의 모든 계산이 눈에 보이는 코드라 연필 계산과 대조할 수 있고, 고속 라이브러리 엔진(vectorbt)은 종목과 파라미터가 많을 때 쓰는 검증된 기성품이다.

둘의 강점은 정확히 반대다. 직접구현은 느리지만 투명하고, 라이브러리는 빠르지만 불투명하다. 빠른 이유는 벡터화 — 날짜를 하루씩 도는 반복문 대신 전체 기간의 가격 배열을 통째로 한 번에 연산한다. 파이썬처럼 반복문이 느린 언어에서 이 차이는 수십~수백 배로 벌어진다. 둘 다 같은 목표비중 인터페이스를 받으므로, 같은 전략을 양쪽에서 돌려 결과가 일치하는지 교차검증할 수 있다 — 시험 답안을 두 명이 따로 채점해 보는 것과 같다.

허용 오차의 감각은 숫자로 잡아 두자. 1년 수익률이 12.34%와 12.36%로 나왔다면 차이 0.02%p는 부동소수점 연산 순서 차이로 흔히 생기는 수준이라 정상이다. 그런데 12.34%와 15.80%처럼 3%p 이상 벌어졌다면 이야기가 다르다 — 하루 수수료 0.1%를 한쪽만 빠뜨렸다면 연 250거래일 × 0.1% ≈ 25%p까지도 벌어질 수 있으니, 거래비용 설정부터, 다음으로 체결 시점(당일 종가 대 익일 시가)을 대조하는 식으로 큰 항목부터 좁혀 간다.

출처 Knight, J. & Leveson, N. (1986). "An Experimental Evaluation of the Assumption of Independence in Multiversion Programming." IEEE Transactions on Software Engineering SE-12(1). — N-버전 프로그래밍의 독립성 가정에 대한 고전적 실험.

코드 제출에서 비중 제출로 — 그림이 단순해진 이유

위 구조는 참가자의 코드를 서버에서 재실행해 검증하던 초기 설계(v1)다. 현재의 공식 평가는 전향 평가 모듈에서 배우는 방식(v2)으로 바뀌었다 — 참가자는 코드 대신 비중표만 제출하고, 서버는 접수·규칙검사·미래 수익률 채점만 한다.

코드를 받지 않아도 평가가 되는 이유는 채점 기준의 이동에 있다. v1은 "과거 데이터에서 이 코드가 정말 그 성적을 냈는가"를 재현으로 확인했다. v2의 전향 평가는 제출 시점 이후의 미래로 채점하므로, 코드가 무엇을 했는지는 중요하지 않고 결과물인 비중표만 있으면 된다. 미래는 아무도 미리 볼 수 없으므로 재현 검증 자체가 필요 없어진 것이다.

동네 공원에서 잰 100m 기록은 공인되지 않는다

100m 기록이 공인되려면 규격 트랙, 전자 계시, 그리고 뒷바람 초속 2.0m 이하라는 조건이 필요하다. 조건이 제각각이면 서울의 9초 95와 부산의 9초 98을 비교할 수 없기 때문이다. 검증 서버가 바로 그 공인 경기장이다.

기록이란 "조건이 통제된 상태에서의 측정값"이고, 조건 통제가 무너지면 숫자는 남지만 의미는 사라진다. 전략의 검증 점수도 같은 성질의 숫자다 — 같은 코드, 같은 데이터, 그리고 같은 자원 조건에서 잰 값이어야 비교할 수 있다. 이 강의의 검증 서버(GB10)는 CPU 20코어, GPU 1장, 128GB 통합 메모리를 가진 한 대의 장비인데, 이 GPU에는 하드웨어 분할 기능이 없다. 두 작업이 같은 GPU에 올라가면 계산 유닛과 메모리 대역폭을 뺏고 뺏기며 뒤엉키고, 40분 걸리던 검증이 70분이 되기도 하며, 최악의 경우 연산 순서가 달라져 소수점 아래 수치까지 흔들릴 수 있다. 그래서 원칙은 하나다. 연습(GPU 학습)은 각자 자기 컴퓨터에서, 서버는 공인 기록 측정 전용으로.

느리지만 공정하다 — 줄 세우기의 산수

검증 요청이 동시에 여러 개 들어와도 플랫폼은 한 번에 하나씩만 실행한다. 이유는 두 가지 — 메모리 사고(OOM) 방지와 측정 간섭 제거다.

OOM(Out Of Memory)은 메모리가 부족할 때 운영체제가 프로세스를 강제 종료하는 사고다. 무서운 점은 예고가 없다는 것 — 메모리가 90% 찼을 때는 아무 경고도 없다가, 한도를 넘는 순간 운영체제가 가장 큰 프로세스를 골라 즉사시킨다(리눅스에서는 실제로 이 장치를 OOM killer라 부른다). 죽는 쪽은 메모리를 많이 쓴 작업이지 나중에 온 작업이 아니므로, 남의 무리한 작업 때문에 내 세 시간짜리 검증이 로그 한 줄 남기고 사라질 수 있다. 산수는 간단하다.

다만 모든 작업을 줄 세우지는 않는다. 데이터 전처리·리포트 생성·소량 조회처럼 GPU를 쓰지 않고 메모리도 몇 GB 수준인 작업은 CPU 20코어 중 일부씩 나눠 가져도 간섭이 미미하므로 두세 개까지 병렬을 허용한다. 반대로 GPU를 건드리는 순간 무조건 줄을 선다. 분할할 수 없는 자원은 독점적으로, 분할해도 안전한 자원은 효율적으로 — 이 비대칭이 규칙의 요점이다.

여섯 개의 규칙, 여섯 개의 필터

공식 평가는 전향 평가다 — 비중을 먼저 제출하고, 그다음에 시장이 움직이고, 실현된 수익률로 채점받는다. 그 틀 위에 얹힌 세부 규칙들은 하나하나가 "무엇을 걸러 내려는 장치인가"라는 질문에 답을 갖고 있다.

"다음 주부터 적용"이라는 반 박자 지연이 전향성의 심장이다. 마감 시점에 아직 일어나지 않은 가격 움직임으로만 채점되므로, 제출 순간의 어떤 정보 우위도 미래를 맞히는 능력 없이는 점수가 되지 않는다. 총노출은 비중 절대값의 합이다 — 롱 50% + 숏 30%면 총노출 80%이고 나머지 20%는 현금이다.

왜 하필 25%인가 — 규칙 설계는 저울질이다

상한 25%는 100% ÷ 25% = 4, 즉 최소 4종목 보유를 강제한다. 한 종목 몰빵은 복권과 구조가 같아서, 참가자가 많으면 누군가는 반드시 대박을 내고 순위표 꼭대기에 앉는다 — 그것은 전략 평가가 아니라 추첨이다.

분산이 "공짜 점심"이라 불리는 이유도 여기서 짚자. 서로 독립인 종목 \(N\)개에 자본을 나누면 평균 수익은 그대로인데 변동성은 \( \tfrac{1}{\sqrt{N}} \)로 준다 — 변동성 20%인 독립 종목 1개면 20%, 4종목이면 10%, 16종목이면 5%다. 현실의 주식들은 공통요인으로 함께 움직이므로 그만큼 줄지는 않는다 — 상관이 ρ면 종목 수를 아무리 늘려도 변동성은 원래의 \( \sqrt{\rho} \) 아래로 내려가지 않는다(변동성 20%, 상관 0.5면 한계는 약 14.1%). 그래도 방향은 같다.

내 비중표는 통과할까 — 3종목 미니 검사기

IR — "얼마나 버나"가 아니라 "얼마나 꾸준히 버나"

투자 트랙은 IR(정보비율)로 채점한다 — 주간 수익률의 합을 그 표준편차로 나눈 값이다. 분모에 변동성이 있으므로 많이 버는 것만으로는 부족하고 꾸준히 벌어야 점수가 난다.

\[ \mathrm{IR} \;=\; \frac{\sum_{t} r_t}{\operatorname{sd}(r_t)} \qquad (r_t = \text{주간 수익률}) \]

같은 총수익 4%가 채점상 여섯 배 넘게 벌어진다. C의 계산을 손으로 따라가면 — 평균 1%, 각 주의 편차 +1, −1, +1, −1이므로 표준편차 1%, IR = 4 ÷ 1 = 4. B는 평균 1%, 편차 +7, −5, +6, −8 → 분산 (49+25+36+64) ÷ 4 = 43.5, 표준편차 ≈ 6.6% → IR ≈ 4 ÷ 6.6 ≈ 0.61이다.

RPS와 듀애슬론 — 점수가 아니라 순위를 섞는 이유

예측 트랙(선택 참가)은 각 종목이 다음 주 수익률 5분위 중 어디에 들지 확률로 제출해 RPS로 채점받는다. 종합 순위는 두 트랙 순위의 평균 — 두 종목을 모두 뛰는 듀애슬론 방식이다.

예측 트랙 제출물의 모양을 그려 보면 이렇다. 유니버스의 종목 각각에 대해 "다음 주 수익률이 전체 종목 중 하위 20%에 들 확률 10%, 그다음 구간 20%, …" 하는 식으로 다섯 확률(합계 1)을 적어 낸다. 정답을 하나 찍는 것이 아니라 불확실성의 분포를 적어 내는 것이 핵심이며, 자신 없는 종목에는 확률을 고르게 펴는 것이 정직한(그리고 채점상 유리한) 답이다. RPS의 계산은 M6 대회 모듈에서 손으로 직접 해 본다.

1. 왜 점수를 직접 섞지 않는가 — IR과 RPS는 단위가 달라 점수를 더하면 한쪽이 계산을 지배한다. 표준화(평균 0, 표준편차 1)로 완화해도 극단값에는 여전히 취약하다 — 한 명이 도박으로 IR을 폭발시키면 표준화 점수도 함께 끌려간다
2. 순위의 강건함 — 순위는 극단값을 "1위"라는 한 칸으로 눌러 담는다. 정보를 조금 버리는 대신 조작과 우연에 둔감해지는 거래이고, 대회 채점에서는 대개 남는 장사다
3. 실증 근거 — M6 대회에서 예측 점수(RPS)와 투자 점수(IR) 순위의 상관이 약 0.04로 보고되었다. 즉 예측 실력과 투자 실력은 거의 별개의 능력이며, 각각 독립적으로 순위를 매겨 평균하는 것이 공정하다

듀애슬론 산수의 예 — 참가자 셋. 갑: 투자 1위·예측 3위 → 평균 2.0. 을: 투자 2위·예측 1위 → 평균 1.5. 병: 투자 3위·예측 2위 → 평균 2.5. 종합 우승은 을이다. 한 트랙의 압도적 1위보다 두 트랙의 고른 상위권이 유리한 구조다.

출처 Makridakis, S., Spiliotis, E. 외 (2023). "The M6 forecasting competition: Bridging the gap between forecasting and investment decisions." arXiv:2310.13357 — 듀애슬론 채점과 RPS·IR 순위 상관의 원 출처.