분기 재무 데이터 구축 방법: 제출일, 수정 데이터, 재처리 기준

분기 재무 데이터는 매출, 영업이익, EPS 같은 숫자만 모아 두면 금방 한계가 온다. 같은 분기 값도 최초 제출본인지, 수정 제출본인지, 나중에 재처리한 값인지에 따라 의미가 달라지기 때문이다. 그래서 테이블을 만들 때는 값보다 먼저 공개 시점과 수정 이력을 고정해야 한다.

운영 관점에서는 최신 값을 빨리 보여주는 화면과, 과거 특정 날짜에 알 수 있었던 값만 재현하는 분석 화면을 분리하는 편이 안전하다. 이 둘을 한 테이블에서 대충 처리하면 백테스트와 대시보드가 서로 다른 이야기를 하기 쉽다.

분기 재무 데이터 구축 방법: 제출일, 수정 데이터, 재처리 기준 핵심 설정 흐름

분기 데이터에서 따로 봐야 할 날짜

필드	의미	흔한 실수
fiscal_period	회계 기준 분기	2024Q4처럼 기간만 보고 최신 데이터라고 착각한다.
filed_at	보고서가 제출된 날짜	과거 분석에 미래 제출 값을 섞는다.
accepted_at	원천 시스템이 접수한 시각	일 단위 배치에서 시차를 무시한다.
revised_at	수정본을 반영한 시각	수정 전후 값을 덮어써서 차이를 잃어버린다.

원본, 표준화, 분석용 테이블을 나누기

원본 파일은 나중에 다시 검증할 수 있어야 하므로 최대한 그대로 둔다. 표준화 테이블에서는 회사 ID, 회계 기간, 통화, 단위처럼 분석에 필요한 기준을 맞춘다. 분석용 테이블은 조회 속도와 사용 목적에 맞춰 따로 만들면 된다.

create table quarterly_filing_raw (
  company_id text,
  fiscal_period text,
  filed_at timestamp,
  revision_no integer,
  source_payload jsonb
);

create table quarterly_fact (
  company_id text,
  fiscal_period text,
  metric text,
  value numeric,
  currency text,
  filed_at timestamp,
  revision_no integer
);

덮어쓰기보다 이력 보관이 먼저다

수정 제출이 들어왔을 때 기존 행을 바로 바꾸면 어떤 값이 언제 바뀌었는지 추적하기 어렵다. 최신 화면은 최신 revision을 고르면 되고, 과거 재현은 filed_at 기준으로 그날까지 공개된 값만 고르면 된다.

재처리 기준

• 새 제출본이 들어오면 해당 회사와 해당 회계 기간만 먼저 재계산한다.
• 수정 폭이 큰 지표는 별도 로그에 남겨 대시보드 변경 원인을 추적한다.
• 통화, 단위, 회계 기간 기준이 바뀐 경우에는 관련 파생 지표까지 같이 재처리한다.
• 배치가 끝난 뒤 row count, key count, 주요 합계가 예상 범위를 벗어나는지 확인한다.

읽을 때 확인할 점

이 글의 핵심은 분기 데이터를 최신 값 하나로만 보지 않는 것이다. 운영 화면은 최신 값을 보여줘도 되지만, 전략 검증이나 과거 성과 분석은 당시 공개됐던 값만 써야 한다. 두 목적을 분리하면 데이터가 바뀌었을 때 원인을 훨씬 빨리 찾을 수 있다.

함께 보면 좋은 글

• 주식 데이터 정합성 점검
• 기업 데이터 식별자 매핑 설계