소멸하는 데이터들 — 사이드 프로젝트가 하나에서 셋으로 늘었다

뉴스 하나 모아두려고 만든 프로젝트가, 같은 원칙으로 게시판 심리·분 단위 가격까지 모으는 우산 프로젝트가 됐습니다

퀀트봇 본체 프로젝트에서 작은 프로젝트를 하나 분리했던 게 얼마 전인데, 지금은 그 프로젝트가 셋으로 늘었습니다. 시작은 과거 종목 뉴스를 모아두는 것부터였습니다.

왜 따로 만들었나

새 프로젝트를 만들지 말지 정하는 기준을 하나 세웠습니다. "소멸성(perishability)" — 지금 안 잡아두면 영영 못 잡는 데이터인가, 아니면 나중에 언제든 다시 만들어낼 수 있는 데이터인가.

• 일봉 가격·거시 데이터는 비소멸입니다. 공식 소스에서 몇 년 전 특정 날짜의 데이터를 언제든 다시 조회할 수 있습니다. 굳이 따로 아카이브해둘 이유가 없습니다.
• 종목 뉴스는 다릅니다. 포털 뉴스 페이지는 일정 기간이 지나면 접근이 막히거나, 기사 자체가 삭제되기도 합니다. 오늘 안 모아두면 나중엔 그 시점의 뉴스를 다시는 못 구합니다.

그래서 뉴스부터 따로 떼어서 전담 프로젝트로 분리했습니다. 재미있는 결론이 하나 따라오는데, 뉴스만 탄탄히 모아두면 과거 어느 시점의 전체 스냅샷도 역으로 재구성할 수 있다는 겁니다.

가격/거시 데이터는 언제든 다시 만들 수 있으니, 뉴스만 있으면 나머지는 그때그때 채우면 됩니다. 그래서 이 프로젝트는 저장소라기보다, 본체 프로젝트가 필요할 때 가져다 쓰는 재료 창고에 가깝습니다.

원본과 100% 같은 형식을 유지하는 방법

과거 뉴스를 새로 수집할 때 가장 신경 쓴 부분은 "실시간으로 모으는 뉴스와 형식이 완전히 똑같아야 한다"는 것이었습니다. 형식이 조금이라도 다르면, 나중에 과거 데이터로 뭔가를 재현하거나 비교할 때 "데이터가 달라서 그런 건지, 진짜 차이가 있어서 그런 건지" 구분할 수 없게 됩니다.

그래서 별도로 필터링/가공 로직을 새로 만들지 않고, 본체 프로젝트가 실제로 쓰는 코드를 그대로 가져다 씁니다. 완전히 독립된 프로젝트로 만들 수도 있었지만, 그러면 두 코드가 시간이 지나면서 서서히 달라질 위험이 있었습니다. 지금은 일부러 본체에 의존하게 만들어서, 형식이 어긋날 걱정 자체를 없앴습니다.

수집 경로를 찾기까지

과거 뉴스를 어디서/어떻게 가져올지도 시행착오가 좀 있었습니다. 처음 시도한 방법은 도달 범위가 너무 얕았고, 그다음 방법은 데이터가 너무 많아서 비용이 감당이 안 됐습니다. 결국 두 포털 뉴스 섹션을 통째로 훑으면서 종목명이 언급된 기사만 골라내는 방식으로 정착했는데, 이 방식은 원하는 과거 어느 시점이든 도달할 수 있다는 게 확인됐습니다(실측으로 2015년까지 도달).

지금은 최근 날짜부터 거꾸로 2015년까지 자동으로 수집하는 백그라운드 작업이 상시 돌고 있습니다. 본체 프로젝트의 야간 분석 작업과 자원이 겹치지 않게 스스로 눈치껏 피해서 도는 방식으로 만들어뒀고, 다 모으는 데는 두어 달 정도 걸릴 예정입니다.

어디에 쓰고, 어디엔 안 쓰나

이 데이터는 용도를 미리 좁게 정해뒀습니다. 과거 뉴스로 재구성한 데이터는 실제 미래 수익과 연결짓는 검증에는 쓰지 않기로 했습니다 — 뒤늦게 모은 데이터라 "그 시점엔 어떤 기사가 실제로 남아있었는지"와 완벽히 같다는 보장이 없어서, 실전 검증에 섞으면 결과를 왜곡할 위험이 있기 때문입니다. 대신 모델들이 같은 입력에 대해 얼마나 일관된 결과를 내는지 확인하는, 수익과 직접 연결되지 않는 용도로만 한정해서 쓰기로 했습니다.

뉴스에서 셋으로

뉴스로 시작했던 이 프로젝트는 지금 세 갈래로 늘었습니다.

종목 토론 게시판의 투자자 심리 데이터, 장중 분 단위 가격 데이터가 같은 기준(소멸성)으로 추가됐습니다. 분 단위 가격은 특히 급합니다 — 포털 뉴스는 그래도 며칠 여유가 있는데, 분 단위 가격은 길어야 몇 시간, 짧으면 당일 오후에 이미 다시 못 구하는 경우도 있습니다.

셋 다 저장 방식은 비슷합니다. 처음 관측한 시점과, 그 이후 값이 바뀌었는지 다시 확인한 시점을 따로 남겨둡니다.

게시판 글은 조회수·공감 수가 계속 바뀌고, 분봉은 방금 만들어지고 있는 마지막 봉의 값이 계속 갱신됩니다. 이렇게 이중으로 기록해두지 않으면 "그 시점에 실제로 어떤 값이었는지"를 나중에 복원할 수 없습니다.

게시판 데이터는 아직 수집만 해두는 단계입니다. 지금 진행 중인 다른 비교 실험에 이 신호를 얼떨결에 섞으면 그 실험 자체가 오염될 수 있어서, 반영은 의도적으로 미뤄뒀습니다.

셋이 공유하는 것들

셋으로 늘면서 자연스럽게 겹치는 부분도 생겼습니다.

종목명을 인식하는 로직, 포털 요청 빈도를 조절하는 로직, 네트워크 장애를 감지하고 견디는 로직은 세 프로젝트가 거의 똑같이 필요로 합니다. 처음엔 각자 따로 구현했는데, 같은 유형의 버그가 여러 곳에서 반복되는 걸 보고 공용 모듈로 뽑아냈습니다.

이제 이 세 가지는 어느 한 스트림에 속하지 않고, 우산 프로젝트 바로 아래에 공용 부품으로 자리 잡았습니다. 한 곳만 고치면 세 스트림이 동시에 고쳐집니다.

본체 프로젝트가 점점 커지면서 "이건 같이 둘까, 분리할까"를 계속 판단해야 하는데, 처음 세운 기준(소멸성 여부)이 그대로 세 번 반복 적용됐습니다. 앞으로 비슷한 데이터가 또 생기면, 이 우산 프로젝트 안에 자연스럽게 들어올 것 같습니다.