메달리온 레이어 구성을 이해해보자

메달리온 레이어 구성을 이해해보자

데이터를 수집해서 검색 가능하게 만드는 파이프라인을 짤 때, 원본·중간·최종 산출물을 구분 없이 한 곳에 뒤섞어 처리하다가 “다시 처리하고 싶은데 원본이 이미 가공된 상태로만 남아있어서” 못 되돌리는 상황을 겪었다. Bronze/Silver/Gold로 계층을 나누고 나서야 이 문제가 사라졌다.

1. 서론 (Introduction)

• 문제/상황 (Problem): 수집한 데이터를 정제해 저장했는데, 정제 로직에 문제가 있다는 게 나중에 드러났다. 원본이 이미 정제된 형태로만 남아있어서 처음부터 다시 수집해야 하는 상황이 됐다.
• 목적 (Purpose): 메달리온(Bronze/Silver/Gold) 구조가 무엇이고, 원본·중간·최종을 계층으로 나누는 게 왜 재처리 비용을 줄여주는지 이해한다.
• 대상 (Target Audience): 수집 → 정제 → 서빙으로 이어지는 배치 파이프라인을 설계하는 개발자.

2. 방법 및 과정 (Methods & Process)

• 배경 조사 및 데이터 (Data Collection): 세 레이어는 “무엇을 원본으로 삼아 다시 만들 수 있는지”로 구분된다.

  레이어	역할	원본 훼손	재현 가능 여부
  Bronze	원본을 가공 없이 그대로 보존 + 수집 시점 같은 메타데이터 기록	없음(그대로 저장)	재현의 기준점 자체
  Silver	정제·정규화·중복 제거	Bronze를 다시 읽어 새로 만듦	Bronze만 있으면 통째로 재현 가능
  Gold	검색·서빙에 바로 쓸 최종 형태	Silver를 다시 읽어 새로 만듦	Silver만 있으면 통째로 재현 가능

• 접근 방법 (Approach Methods):
  • [방법 1]: 계층 없이 수집과 동시에 바로 정제해서 저장한다. 구현은 단순하지만 원본이 남지 않아, 정제 로직에 문제가 생기면 재처리 자체가 불가능하다.
  • [방법 2]: Bronze에 원본을 그대로 남기고 Silver/Gold를 분리한다. 재처리가 가능해지는 대신 저장 공간과 처리 단계가 늘어난다.
• 분석 및 해결 프로세스 (Analysis Flow):
  • 도구/기술: 파이썬 dict/JSON. 3개 함수(ingest_bronze/refine_silver/build_gold)와, 공백·대소문자 차이로 생기는 “사실상 중복” 토이 데이터 5건.
  • 주요 단계: 원본 5건 Bronze 적재(가공 없이 그대로) $\rightarrow$ Silver 정제(공백만 정리하는 초기 버전) $\rightarrow$ Gold 생성 $\rightarrow$ 대소문자 차이 중복이 안 걸러지는 버그 확인 $\rightarrow$ Silver 정제 함수에 소문자 비교만 추가 $\rightarrow$ Bronze 재수집 없이 Silver/Gold 재생성.
  • 결과 도출 및 검증: 원본 5건 중 공백만 다른 중복 1건(예: 앞뒤 공백이 있고 없고)은 초기 버전에서도 걸러졌지만, 대소문자만 다른 중복 1건(예: “Reranking”과 “reranking”)은 못 걸러 Silver가 4건으로 남았다. Silver 정제 함수의 비교 키에 소문자 변환 한 줄만 추가해 Bronze를 다시 수집하지 않고 그대로 재실행했더니 3건으로 줄었다 — 정제 로직의 버그를 고치는 데 원본 재수집이 전혀 필요 없었다.

3. 결과 (Results)

• 분석 결과 요약: 아직 데이터 규모별 처리 시간을 잰 수치는 없다. 대신 “정제 로직에 버그가 있어도 Bronze만 있으면 Silver부터 다시 만들 수 있다”는 구조 자체는 확인했다 — 버그가 있던 상태(5건 중 4건으로 정제)에서 원본 재수집 없이 로직만 고쳐 정상 상태(3건)로 되돌렸다.

4. 인사이트 및 액션 (Insights & Action)

• 인사이트 (Insight): 계층을 나누는 이유는 “정제 로직은 나중에 반드시 바뀐다”는 전제에 있다. Bronze가 원본을 그대로 갖고 있으면 Silver의 버그는 Silver부터 다시 만들면 끝나는 문제다. 계층을 나누지 않고 수집과 동시에 정제해버리면, 똑같은 버그가 “원본을 다시 구해와야 하는” 훨씬 비싼 문제로 바뀐다.
• 실행 방안 (Action Plan): 수집 단계에서는 정제·중복 제거 로직이 아무리 단순해 보여도 원본에 직접 적용하지 않는다. 원본은 Bronze로 그대로 남기고, 정제는 항상 Bronze를 읽어 Silver를 “새로 만드는” 별도 함수로 분리해둔다.
• 한 줄 결론 (Key Takeaway): 원본·정제·서빙을 계층으로 나눠두면 정제 로직의 버그는 재수집이 아니라 재실행만으로 고칠 수 있다. 샘플 코드
• 다음 스텝 (Next Step): 이번 데모는 5건짜리 토이 데이터라 Silver를 통째로 다시 만드는 재실행 비용이 사실상 0에 가까웠다. 레코드가 수백만 건으로 늘어나면 Silver 전체를 매번 다시 만드는 것 자체가 부담이 되는데, 그 지점부터는 Silver를 어떻게 나눠 부분적으로만 다시 만들지가 남은 문제다.

---