원천 데이터와 실행 스냅샷을 분리한 수집 구조
✨ GPT-5.5의 요약
JSON·CSV·DuckDB 사이에서 흔들리던 기준 데이터를 PostgreSQL로 옮기며 원천 evidence, observation, 기준 데이터, 실행 snapshot, 전달 산출물을 분리한 기록.
JSON·CSV·DuckDB 사이에서 기준 데이터가 흔들렸다
며칠 동안 데이터 수집, 검수, 실행, 전달 플로우를 셋업하면서 여러 가지 이슈들이 자꾸만 튀어나왔다. 확실히 내가 DB를 제대로 배워본 적도 다뤄본 적도 없다 보니, 데이터 저장 방식을 바꾸는 일이 잦았고, 그때마다 단순한 교체로 끝나지 않았다.
처음엔 데이터를 JSON/CSV로 수집하고, 보기용으로 DuckDB를 붙여 확인했다. 그런데 워커 산출물과 코디네이터가 계속 DB를 다시 만드는 구조가 섞이면서, 무엇이 원천 데이터이고 무엇이 기준 데이터인지 계속 흔들렸다.
그래서 MySQL로 DB를 만드는 플랜도 짜봤다. 하지만 문제는 MySQL 자체라기보다, 여러 워커나 스크립트가 기준 데이터를 직접 갱신하는 구조였다. 그 방식으로 가면 동시 update, 충돌, 소유권, 롤백 문제가 반복될 가능성이 컸다.
그 뒤에도 다른 방식들을 검토했지만, 핵심 문제는 같았다. 수집 데이터, 기준 데이터, 실행 데이터, 전달 산출물의 경계가 애매하니 결국 같은 문제가 다시 생겼다.
DB 제품보다 mutation ownership이 핵심이었다
PostgreSQL로 옮긴다고 문제가 저절로 해결되는 것은 아니었다. 어떤 DB를 쓰느냐보다 누가 기준 데이터를 바꿀 수 있는지부터 정해야 했다.
워커는 원천 evidence와 observation을 append-only로 남긴다. 기준 데이터는 직접 수정하지 않는다. 코디네이터가 evidence와 observation을 검수한 뒤 기준 데이터와 기준값을 갱신한다. 기준 데이터를 바꾸는 책임을 한곳에 모아야 충돌이 났을 때 무엇을 되돌려야 하는지도 추적할 수 있었다.
PostgreSQL 안에서 역할을 나눴다
그래서 오늘 PostgreSQL DB로 옮기면서, 며칠 동안 셋업해온 전체 흐름도 같이 정리했다. 모든 것을 DB 한 덩어리로 처리하지 않고 역할을 나눴다.
- 원천 evidence
- 공개된 원천에서 수집한 근거와 원본 값을 저장한다
- 처리된 값과 상태는 원천을 덮어쓰지 않고 별도 이력으로 남긴다
- JSON/CSV 파일은 evidence mirror일 수는 있어도 기준 데이터는 아니다
- observation
- 워커는 맡은 수집 채널의 관측값만 append-only ledger에 제출한다
- 발견과 보강은 서로 다른 역할로 분리한다
- 워커는 기준 데이터를 직접 수정하지 않는다
- 기준 데이터
- 코디네이터가 evidence와 observation을 검수한다
- 검수된 값만 정해진 구조에 맞춰 기준 데이터로 반영한다
- view는 계산, 검수, export를 위한 표면으로 사용한다
- 실행 snapshot
- 수집 view를 바로 실제 실행 기준으로 쓰지 않는다
- 중복 제거와 품질 게이트를 통과한 대상을 한 시점의 snapshot으로 고정한다
- 실행 결과와 제외·후속 상태는 기준 데이터와 분리해서 관리한다
- 전달 산출물
- CSV, Google Sheet, Excel, vox.ai에 넘길 파일은 기준 데이터나 실행 snapshot에서 생성한다
- 이것들은 표시하거나 전달하기 위한 산출물이다
- 산출물을 다시 기준 데이터처럼 수정하지 않는다
근거에서 실행과 전달까지 추적할 수 있게 됐다
이렇게, 수집한 근거가 어디에 쌓이고, 워커가 무엇을 남기고, 어떤 값이 기준값이 되고, 어떤 snapshot이 실제 실행에 쓰이고, 무엇이 전달 산출물인지 추적하는 플로우가 완성되었다.
물론, 아직도 많이 부족한 구조라서 더 만질 부분은 많을 것이다. 또 계속해서 테스트하고 피드백하고 수정하면서 온갖 대격변이 일어나게 될 것이다. 그리고 그렇게 플로우도, 하네스 구조도, 내 직관력도 전부 다 발전해나가겠지.
혹여나 나의 플로우 셋업이 누군가에게 도움이 될까 싶어 공유해본다.
댓글 남기기