감사 이벤트의 Bronze·Silver·Gold 정제

수집 파이프라인을 연결한 뒤에는 Kafka에 도착한 이벤트를 분석에 사용할 수 있도록 정리했습니다. JSON이 쌓이는 것만으로 사용자 등록이나 권한 변경 건수를 같은 기준으로 집계할 수는 없었습니다.

Databricks에서 원본과 정제 결과, 분석용 데이터를 Bronze·Silver·Gold로 나눴습니다. 각 단계에서 어떤 처리를 했고 문제가 생기면 어디부터 다시 만들 수 있는지 구분하기 위한 구성이었습니다.

Bronze: 원본과 수집 위치

원본 메시지와 함께 수집 시각, Kafka의 토픽·파티션·offset 같은 위치 정보를 보관합니다. offset은 파티션 안의 위치이므로 숫자 하나만으로 전체 메시지를 구분할 수는 없습니다.

본문을 가능한 한 원래 형태로 남겨 두면 나중에 파싱 규칙을 바꾸거나 필드를 추가로 추출할 수 있습니다. 그렇다고 Bronze에 스키마가 전혀 없는 것은 아닙니다. 원본 payload와 수집 메타데이터를 담는 테이블 구조는 필요합니다.

원본 보존도 기간과 접근 권한, 삭제 정책에 맞춰 관리해야 합니다. append-only로 쓰는 것만으로 위변조 방지나 영구 보존이 보장되지는 않습니다.

Silver: 해석과 중복 처리

JSON에서 행동과 대상, 사용자 맥락과 시각을 추출하고 타입을 맞췄습니다. 같은 이벤트가 재전송될 수 있으므로 이벤트 식별자를 기준으로 중복도 확인해야 했습니다.

반대로 같은 요청에서 발생한 서로 다른 행동을 중복으로 지우면 안 됩니다. 요청 ID와 이벤트 ID의 차이가 여기에서도 중요했습니다. 파싱 실패와 필수값 누락, 모르는 행동 코드는 정상 결과와 구분해 조사할 수 있어야 합니다.

시각은 원본에 시간대가 있는지와 적재·조회 세션의 시간대를 함께 확인해야 합니다. 문자열을 TIMESTAMP로 바꿨다는 사실만으로 UTC 기준이 맞춰지는 것은 아닙니다.

Gold: 질문에 맞춘 집계

당시에는 등록과 로그인, 권한 변경 등 질문별로 약 8개의 Gold 테이블을 준비했습니다. 집계 데이터와 사용자별 활동 이력은 서로 다른 용도였습니다.

아래는 정제·중복 처리가 끝난 Silver 테이블을 일별·행동별로 집계하는 예시입니다. 시각을 집계할 시간대는 세션 설정과 데이터 기준을 먼저 맞춰야 합니다.

SELECT
    CAST(event_timestamp AS DATE) AS event_date,
    action_type,
    COUNT(*) AS event_count
FROM audit_event_silver
GROUP BY 1, 2;

이 쿼리는 집계 결과를 조회하는 예시이며 지속적인 적재 작업 전체는 아닙니다. CREATE TABLE IF NOT EXISTS ... AS SELECT를 한 번 실행했다고 이후 데이터가 자동으로 반영되지는 않습니다. 운영에서는 갱신 작업과 지연 데이터, 재처리 시 결과를 덮어쓸 범위를 따로 정해야 합니다.

공유할 데이터의 의미와 권한

Gold를 공유할 때는 테이블 이름과 컬럼 외에 집계 기준도 설명해야 했습니다. 시도와 완료 중 무엇을 센 것인지, 어떤 이벤트를 제외했는지, 어느 시점까지 반영했는지 알아야 같은 결과로 해석할 수 있습니다.

Unity Catalog에서는 필요한 데이터 자산과 범위에 권한을 부여했습니다. 원본에 접근할 수 있는 사람과 집계만 볼 사람을 같게 둘 필요는 없습니다. 사용자 식별 정보가 포함된 결과라면 공유 범위도 그에 맞춰야 합니다.

재처리와 이후 검색의 연결

원본에서 다시 처리할 수 있으려면 해당 기간의 데이터와 스키마·변환 로직이 남아 있어야 합니다. 각 계층의 보존과 의존 관계를 확인하고, 같은 기간을 다시 집계했을 때 중복으로 더하지 않는지도 봐야 합니다.

원본 이벤트를 남기는 Bronze, 정제하는 Silver, 분석에 쓰는 Gold로 나누면서 원본 보관과 집계에 필요한 처리를 구분했습니다. 이벤트를 받는 것에서 나아가, 같은 기준으로 조회할 데이터를 준비한 단계였습니다.

이 구성이 원본 유실이나 중복을 자동으로 해결해 주는 것은 아닙니다. 재처리에 필요한 데이터와 변환 로직을 보관해야 하며, 이후 검색 인덱스에 연결할 때도 소스 테이블과 CDF 요구사항은 따로 확인해야 합니다.

다음 글에서는 이 데이터를 바탕으로 자연어 데이터 조회와 문서 검색을 연결한 과정을 정리합니다.

참고 자료

• Databricks 메달리온 아키텍처 
• Delta 테이블 이력과 보존 조건 
• 검색 인덱스의 소스·동기화 조건