로그 파이프라인 개선기 - 기존 파이프라인의 문제 정의와 해결 방안 적용

기존 로그 파이프라인은 KDS → Firehose → S3 → Airflow 분류 → GCS → BigQuery 흐름으로 운영됐다. 하나의 파일에 여러 로그 타입이 섞여 있어 분류 작업이 필수였고, 그 과정에서 처리 시간이 길어지고 S3와 GCS의 중복 저장도 발생했다.

문제는 크게 세 가지였다. 첫째, 모든 타입을 한 번 분류해야 해서 비효율적이었고, 분류 단계에 장애가 나면 전체 적재가 멈추는 단일 장애 지점이 생겼다. 둘째, Airflow 기반 배치라 데이터 신선도가 낮아 실시간 분석 요구에 맞지 않았다. 셋째, 스키마 변경 관리 체계가 없어 생산자와 소비자가 같은 규칙을 보지 못했고, BigQuery 스키마를 수기로 바꾸는 운영 부담이 컸다.

개선 방향은 단일 원본 데이터 소스(SSoT) 를 만들고, 배치 중심 구조를 스트리밍 구조로 바꾸는 것이었다. 이를 위해 메시징 플랫폼은 MSK로 전환하고, 소비는 Firehose 대신 커스텀 Kafka Consumer를 직접 구현했다. 이렇게 하면 Consumer 단계에서 타입별 분류와 파티셔닝을 바로 처리할 수 있어, 기존의 분류 작업을 없애고 준실시간 적재가 가능해진다.

스키마 관리에는 Data Contract와 Schema Registry를 도입했다. Protobuf를 공통 스키마 포맷으로 쓰고, Buf로 린팅·포맷팅·호환성 검증·코드 생성을 자동화했다. 변경 흐름은 생산자와 소비자가 PR 리뷰와 테스트를 거치며, Buf 플러그인으로 BigQuery 스키마, Python 클래스, Java 클래스를 생성해 각 서비스에 배포하는 방식으로 정리했다.

새 아키텍처에서는 서버가 로그를 MSK로 보내고, Consumer가 이를 ProtobufDeserializer로 읽어 필요한 형태로 가공한 뒤 GCS에 저장한다. GCS는 BigQuery External Table의 소스가 되고, 외부 테이블 성능 한계를 보완하기 위해 매일 내부 테이블로 적재한 뒤, 최종적으로 View Table에서 외부 테이블과 내부 테이블을 함께 제공한다. 결과적으로 데이터는 더 빨리, 더 일관된 방식으로 제공되고, 스키마 변경도 중앙에서 통제할 수 있게 됐다.