본문 바로가기
C.W.K.
Stream
Lesson 04 of 04 · published

신선도는 표시하는 값이야

~11 min · staleness, provenance, error-handling, honesty

Level 0원석
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"오래된 데이터는 오래됐다고 표시한다. 숨기지도 않고, 늘려 잡지도 않는다."

오래된 숫자로 할 수 있는 네 가지

소스가 갱신을 안 했어. 대시보드 게이지에 사흘 전 값이 앉아 있고. 선택지는 정확히 넷이고, 그중 셋이 제일 심심한 하나보다 나빠.

카드를 숨긴다. 깔끔해 보이고 정보를 파괴해. "사흘 됨" 이랑 "아무것도 없음" 은 완전히 다른 상태고, 둘을 합치면 독자가 조용한 주말이랑 망가진 연동을 구분 못 해. 장애도 뒤집혀. 망가질수록 대시보드가 더 비고 더 차분해 보이거든.

늘려 잡는다. 그럴듯한 숫자로 빈칸을 채워. 가능한 선택지 중 최악이야. 결과가 측정값이랑 구분이 안 되는데 거기 붙일 정직한 출처 문자열이 없거든. 저장하는 모든 값에 출처를 붙이는 게 핵심 약속인 앱에서 지어낸 숫자는 작은 타협이 아니라 제품에 대한 모순이야.

조용히 제공자를 바꾼다. 이제 값은 진짜인데 출처 문자열이 거짓말이고, 제공자 둘은 거의 확실히 방법이 조금씩 달라. 역사 중간에 소스가 조용히 바뀌는 계열은 빈칸보다 나빠. 그 결과 생기는 불연속이 시장 사건처럼 보이니까.

마지막 정상값을 날짜랑 신선도 표시랑 같이 보여준다. 심심하고 정직하고, 독자가 실제로 알려진 걸 손에 쥐게 하는 유일한 선택지야.

정직한 빈칸이 그럴듯한 숫자를 이겨. 시스템이 뭔가를 모를 때 제일 값어치 있는 행동은 그걸 정확하게 말하는 거야. 뭘 갖고 있고, 언제 것이고, 왜 더 새 게 없는지. 나머지 선택지는 전부 시각적 깔끔함 조금이랑 독자가 측정이랑 추측을 구분할 능력을 바꿔먹는 거고, 측정 자체가 주장인 시스템에서 그 거래는 절대 남는 장사가 아니야.

오래됨이 항상 장애는 아니야

이 설계를 에러 처리 이상으로 만드는 게 이거야. 이 제품에서 오래됨의 대부분은 정상이야.

Buffett 지표 미국 분자는 분기 통계 발표에서 오니까 정당하게 몇 달 묵어 있고, 아키텍처는 발표 지연을 숨기지 말고 신선도로 보여주라고 적어놨어. 장기 금리 계열 셋 중 둘은 월간이야. 한국이랑 일본 Buffett 값은 연간이고 — 일 년에 행 하나, 그리고 살아 있는 화면이 그걸 연간이라고 라벨 붙여서 연 단위 숫자가 일간 틱인 척 못 하게 해.

화면이 나이를 에러 상태로 다뤘으면, 딱 예정대로 도착하는 데이터를 두고 영구히 경보를 울리고 있었을 거야. 칩은 고장이라고 안 해. 이건 그때 것이라고 하고, 발표 일정을 아는 독자가 알아서 옳은 결론을 내리게 둬.

물리는 건 이거: 섞인 기준 시각. 진짜 함정은 오래된 값 하나가 아니라, 나이가 서로 다른 값 여럿이 하나의 일관된 그림처럼 그려지는 거야. 일간 값이랑 분기 값으로 지은 합성 지표는 제일 늙은 다리만큼만 최신이고 — 화면이 기준 시각 하나만 찍으면 존재하지 않는 동시성을 단언하는 거야. 그래서 이 제품 합성 지표는 제일 오래된 입력 이름을 명시적으로 대고, 그게 뒤쪽 트랙 주제야.

Code

저장하는 모든 값이 자기 출처를 들고 다녀·text
ROW SHAPE:  (gauge, market, series, data_date, value,
             source, fetched_at)

  data_date   the date the MARKET says this reading belongs to
  fetched_at  when this process asked
  source      exactly which provider and series produced it

# data_date and fetched_at are different questions, and keeping both
# is what makes staleness computable rather than guessed:
#
#   data_date 2026-08-05, fetched_at 2026-08-08
#     -> 3 days stale, and we know we asked today
#
#   data_date 2026-08-05, fetched_at 2026-08-05
#     -> we have not asked since; a very different problem
#
# One timestamp cannot tell those apart. Most systems store one.

External links

Exercise

네가 관리하는 시스템에서 외부 소스에서 오는 값을 하나 찾아서, 데이터가 언제 것인지랑 마지막으로 언제 물어봤는지를 둘 다 저장하는지 확인해봐. 하나만 저장하면 지금 어떤 장애들을 구분 못 하고 있는지 따져봐. 보통 답은 죽은 연동이랑 조용한 소스가 똑같이 보인다는 거고, 그래서 누가 그 숫자에 대해 질문할 때까지 죽은 쪽을 아무도 못 알아채.
Hint
타임스탬프는 항상 둘. 대상의 시각이랑 내 시각. '이 숫자 왜 오래됐지?' 조사 거의 전부가 사실은 '우리가 안 물어본 거야, 저쪽이 발표를 안 한 거야?' 라는 질문이고, 타임스탬프 하나로는 답이 안 나와.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고
💛 by 피파— warm

댓글 0

🔔 답글 알림 (로그인 필요)
로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.