"'오늘 변동' 은 캐묻기 전까진 뻔해 보여. 근데 정확히 언제부터의 변동인데? 그 '언제' 를 틀리면 화면의 빨강 초록 숫자가 전부 작은 거짓말이 돼."
순해 보이는 숫자
포트폴리오 앱이라면 다 'day change' 를 보여줘. 이 포지션이 오늘 얼마나 움직였는지. 계산도 시시해 보여. 현재가에서 previous close 를 빼면 끝이잖아. 근데 그 'previous close' 라는 말 속에, 대충 넘기면 숫자를 조용히 오염시키는 질문이 숨어 있어. 도대체 어느 종가를 말하는 거야? Keep 의 답은 정확해. live tick 은 언제나 가장 최근에 완결된 종가에 대고 재. 반사적으로 '어제 종가' 를 집는 게 아니라, 실제로 장이 끝났고 durable 하게 저장된 가장 최근의 종가를 골라 내는 거야.
순진한 prev_close 는 어디서 틀리나
함정은 이래. 저장된 일일 row 가 월요일 장 마감 후에 마지막으로 갱신돼서 월요일 종가를 들고 있다고 하자. 지금은 화요일 장중이고, live tick 이 막 도착했어. 이때 변동을 tick - stored_prev_close 로 계산하면 한 세션 전이 아니라 두 세션 전 값을 빼고 있는 걸 수도 있어. 저장된 'previous' close 는 오늘 기준으로 무엇이 previous 인지가 아니라, 그 row 가 마지막으로 언제 쓰였는지에 따라 정해지거든. 결과는 두 세션에 걸친 움직임이 하루 변동이라는 라벨을 달고 나오는 것. 변동성이 큰 구간에선 반올림 오차 수준이 아니야. 당당한 얼굴로 틀려 있는, 눈에 띄게 잘못된 숫자지.
Keep 가 올바른 기준선을 고르는 법
규칙은 두 갈래야. durable 하게 저장된 row 의 날짜가 live tick 의 날짜와 같으면, 그러니까 row 가 이미 오늘을 담고 있으면, 올바른 기준선은 previous close 야. 어제 종가지. 오늘 row 는 지금 진행 중인 세션이니까. 반대로 저장 row 의 날짜가 더 이르면, 그러니까 이전 세션에서 갱신이 멈춰 오늘을 못 따라왔으면, 그 row 의 last close 가 올바른 기준선이야. 조건문 하나짜리 작은 분기인데, 이 덕분에 day change 가 말 그대로의 의미를 갖게 돼. 그리고 결정적으로 프론트엔드가 이 로직을 그대로 mirror 해. 브라우저가 서버와 다른 기준선을 계산하는 일은 없어.