data-engineering

당근의 사용자 행동 로그 관리 플랫폼: 이벤트센터 개발기. 코드로 관리하던 사용자 행동 로그를 플랫폼으로 만든 이유 | by Suyeon Kang | 당근 테크 블로그 | Jan, 2026 | Medium (새 탭에서 열림)

당근은 방대한 사용자 행동 로그를 보다 효율적이고 체계적으로 관리하기 위해 기존의 Git 기반 코드 관리 방식에서 벗어나 UI 중심의 로그 관리 플랫폼인 ‘이벤트센터’를 구축했습니다. 이를 통해 복잡한 JSON 스키마 작성 과정과 수동 리뷰 절차를 자동화하여 데이터 관리 비용을 획기적으로 낮추었으며, 전사적인 로그 컨벤션을 확립해 데이터의 일관성과 분석 편의성을 동시에 확보했습니다. 결과적으로 개발자와 분석가 모두가 데이터 기반의 의사결정에만 집중할 수 있는 환경을 조성하는 데 성공했습니다. **기존 Git 기반 관리 방식의 한계** * **높은 진입장벽:** 새로운 로그 스키마를 추가하기 위해 Spark의 StructType JSON 형식을 직접 코드로 작성해야 했으며, 이는 데이터 엔지니어링 지식이 부족한 구성원에게 큰 부담이 되었습니다. * **비효율적인 프로세스:** 스키마 하나를 추가할 때마다 PR 생성, 데이터 팀의 수동 리뷰, 수정 반복 과정을 거쳐야 했기에 데이터 반영 속도가 느려지는 문제가 발생했습니다. * **일관성 없는 명명 규칙:** 이벤트 이름에 대한 강제적인 컨벤션이 없어 유사한 행동이 서로 다른 이름으로 정의되거나, snake_case와 camelCase가 혼용되는 등 데이터 정합성 관리가 어려웠습니다. **사용자 행동 로그 수집 및 처리 아키텍처** * **실시간 파이프라인:** 모바일 앱 SDK에서 발생한 이벤트는 서버를 거쳐 GCP Pub/Sub으로 전달되며, Dataflow를 통해 유효성 검증, 중복 제거, 데이터 변환(Flatten)이 실시간으로 이루어집니다. * **스키마 기반 자동 테이블 생성:** 이벤트 스키마를 정의하면 BigQuery에 해당 이벤트 전용 테이블이 자동으로 생성되며, JSON 형태의 커스텀 파라미터가 일반 컬럼으로 펼쳐져 저장되어 복잡한 쿼리 없이도 즉시 분석이 가능합니다. * **데이터 신뢰성 확보:** 스트리밍 단계에서의 단기 중복 제거와 배치 단계에서의 시간 윈도우 기반 중복 제거를 병행하여 데이터의 정확도를 극대화했습니다. **이벤트센터를 통한 로그 관리 혁신** * **UI 중심의 스키마 정의:** 코드를 직접 수정하는 대신 웹 인터페이스에서 필드명, 타입, 설명, 오너십 등을 설정할 수 있어 누구나 쉽게 로그를 설계하고 관리할 수 있습니다. * **명격한 컨벤션 적용:** '행동(Action)-서비스(Service)-대상(Object)' 구조의 명명 규칙을 시스템적으로 강제하여 이벤트 검색성을 높이고 중복 정의를 방지했습니다. * **자동화된 유효성 검사:** 스키마 변경 시 발생할 수 있는 오류를 시스템이 사전에 체크하고, 변경 사항을 즉시 데이터 파이프라인에 반영하여 운영 리소스를 최소화했습니다. 데이터의 양이 늘어날수록 로그 관리의 핵심은 '자율성'과 '통제' 사이의 균형을 잡는 것입니다. 당근의 사례처럼 로그 정의 과정을 플랫폼화하고 컨벤션을 시스템으로 강제한다면, 휴먼 에러를 줄이는 동시에 전사 구성원이 데이터라는 공통 언어를 더욱 쉽고 정확하게 사용할 수 있는 환경을 만들 수 있습니다.

당근은 왜 User Activation을 전사 공통 데이터 레이어로 만들었을까? | by Juyeon Park | 당근 테크 블로그 | Jan, 2026 | Medium (새 탭에서 열림)

당근은 단순한 액티브 유저(Active User) 수치만으로는 파악하기 어려운 사용자 행동의 원인과 흐름을 분석하기 위해 전사 공통 데이터 레이어인 'Activation 레이어'를 구축했습니다. 이를 통해 사용자의 활성 상태와 상태 전이를 일관된 기준으로 정의함으로써 데이터 신뢰성을 확보하고, 팀 간 중복 계산으로 인한 비용과 운영 리소스를 대폭 절감했습니다. 결과적으로 데이터 분석 환경을 쿼리 중심에서 시스템 중심으로 격상시켜 전사적인 의사결정 속도와 정확도를 높였습니다. **단순 지표를 넘어선 User Activation의 중요성** * 단순한 액티브 유저 수는 '무슨 일이 일어났는지'는 보여주지만, '왜' 일어났는지에 대한 해답을 주지 못하므로 유저를 상태별로 쪼개어 보는 관점이 필요합니다. * **활성 상태**: 특정 시점에 유저가 신규(New), 유지(Retained), 복귀(Reactivated), 이탈(Inactive) 중 어떤 상태인지 분류합니다. * **상태 전이**: 기간의 흐름에 따라 유저가 어떤 경로로 이동하는지(예: 유지 → 이탈) 파악하여 활동성 수준에 따른 구체적인 액션을 가능하게 합니다. * 이전에는 팀마다 이 기준을 각자 계산하여 신뢰도가 낮고 운영 안정성이 떨어졌으나, 이를 공통 레이어로 통합하여 해결했습니다. **신뢰성 확보를 위한 기준 행동의 고정** * 단순한 UI 로그(클릭 등)가 아닌, 비즈니스적 의미를 담은 **Fact 모델**을 기준으로 Activation을 계산하도록 설계했습니다. * 로그 내 파라미터에 따라 의미가 달라지는 혼선을 방지하기 위해, 사전에 정제된 Fact 레이어를 입력값으로 사용합니다. * `<fact_name>_activation_<time_grain>`과 같은 엄격한 네이밍 컨벤션을 적용하여 모델 이름만으로도 어떤 행동과 주기(일/주/월)를 기준으로 하는지 누구나 쉽게 알 수 있게 했습니다. **증분 모델(Incremental Model)을 통한 비용 최적화** * 수천만 명의 사용자 데이터를 매일 전체 재처리하는 방식은 비용 소모가 크기 때문에, dbt의 증분 모델 방식을 도입했습니다. * **FirstLast 모델**: 각 유저별 최초/직전/최근 활동일을 별도로 관리하여 전체 이력을 매번 스캔하지 않도록 했습니다. * **Activation 모델**: 당일 활동 유저 정보와 FirstLast 모델을 결합하여 상태와 복귀 간격 등을 계산하고, 결과를 다시 FirstLast 모델에 업데이트하는 순환 구조로 데이터 스캔량을 최소화했습니다. * **Activation Status 모델**: 활동이 없는 유저를 포함한 전체 유저의 현재 상태(특히 이탈 기간)를 관리하여 분석 편의성을 높였습니다. **dbt 매크로를 활용한 생산성 극대화** * 다양한 행동(앱 방문, 게시글 작성 등)과 시간 단위(Daily, Weekly, Monthly)별로 수많은 모델을 직접 구현해야 하는 번거로움을 매크로로 해결했습니다. * 복잡한 상태 계산 로직을 dbt 매크로로 표준화하여, 새로운 Activation 모델이 필요할 때 설정값만 입력하면 자동으로 수십 개의 모델이 생성되도록 자동화했습니다. * 이를 통해 데이터 엔지니어의 반복 작업을 줄이고, 분석가들이 필요할 때 즉시 공통 레이어를 확장할 수 있는 환경을 만들었습니다. 데이터를 단순히 쿼리 결과물로 보는 단계를 넘어, 시스템화된 '인프라'로 구축할 때 비로소 전사적인 데이터 활용도가 극대화됩니다. 당근의 사례처럼 상태 전이와 같은 복잡한 로직을 공통 레이어로 추상화하고 자동화한다면, 분석 효율성을 높이는 동시에 데이터 기반의 의사결정 문화를 더욱 공고히 할 수 있습니다.

비용, 성능, 안정성을 목표로 한 지능형 로그 파이프라인 도입 (새 탭에서 열림)

네이버의 통합 데이터 플랫폼 AIDA 내 로그 수집 시스템인 'Logiss'는 대규모 로그 파이프라인을 운영하며 겪었던 무중단 배포의 한계, 리소스 낭비, 로그 중요도 미분류 문제를 해결하기 위해 지능형 파이프라인을 도입했습니다. 핵심은 Storm의 멀티 토폴로지 구성을 통한 블루-그린 배포 구현과 실시간 트래픽 상태에 따라 처리 속도를 동적으로 조절하는 지능형 제어 알고리즘의 적용입니다. 이를 통해 서비스 중단 없는 배포는 물론, 인프라 비용을 약 40% 절감하고 장애 시 핵심 로그를 우선 처리하는 안정성까지 확보하며 성능과 비용의 최적점을 찾아냈습니다. **멀티 토폴로지와 블루-그린 배포를 통한 무중단 운영** * 기존 Traffic-Controller는 단일 토폴로지 구조로 인해 배포 시마다 데이터 처리가 3~8분간 중단되는 문제가 있었으나, 이를 해결하기 위해 멀티 토폴로지 기반의 블루-그린 배포 방식을 도입했습니다. * Storm 2.x의 `assign` 방식 대신 Kafka의 컨슈머 그룹 관리 기능을 활용하는 `subscribe` 방식으로 내부 로직을 커스텀 변경하여, 여러 토폴로지가 동일 파티션을 중복 소비하지 않도록 개선했습니다. * 이를 통해 트래픽이 몰리는 낮 시간대에도 중단 없이 안전하게 신규 기능을 배포하고 점진적인 트래픽 전환이 가능해졌습니다. **지능형 트래픽 제어를 통한 리소스 최적화** * 낮과 밤의 트래픽 차이가 5배 이상 발생하는 환경에서 피크 타임 기준으로 장비를 고정 할당하던 비효율을 제거하기 위해 '지능형 속도 제어' 알고리즘을 도입했습니다. * Kafka의 랙(lag) 발생량과 백엔드 시스템(OpenSearch 등)의 CPU 부하 상태를 실시간으로 감시하여, 시스템이 여유로울 때는 로그 처리 속도를 자동으로 높여 적체를 빠르게 해소합니다. * 유동적인 속도 조절 덕분에 기존 대비 투입 장비 리소스를 약 40% 절감하는 성과를 거두었으며, 갑작스러운 트래픽 유입에도 유연하게 대응할 수 있게 되었습니다. **로그 중요도 기반의 우선순위 처리** * 모든 로그를 동일한 속도로 처리하던 방식에서 벗어나, 비상 상황 발생 시 서비스 핵심 로그가 먼저 처리될 수 있도록 우선순위(High, Medium, Low) 개념을 도입했습니다. * 트래픽 지연이 발생하면 중요도가 낮은 로그의 처리 속도는 제한하고, 사업 및 서비스 운영에 필수적인 핵심 로그는 지연 없이 전송되도록 파이프라인 가용성을 확보했습니다. **저장소별 차등 샘플링을 통한 비용 절감** * 실시간 검색을 위한 OpenSearch와 장기 보관을 위한 랜딩 존(Landing Zone)에 데이터를 전송할 때, 각 저장소의 목적에 맞게 샘플링 비율을 다르게 설정할 수 있는 기능을 구현했습니다. * 모든 데이터를 무조건 100% 저장하는 대신, 분석 목적에 따라 일부 샘플링만으로 충분한 로그는 저장량을 줄여 인덱싱 부하를 낮추고 스토리지 비용을 효율적으로 관리할 수 있게 되었습니다. 대규모 로그 파이프라인 운영에서 비용 효율과 안정성은 상충하기 쉬운 가치이지만, 시스템의 상태를 실시간으로 파악하고 제어하는 '지능형' 로직을 통해 두 마리 토끼를 모두 잡을 수 있습니다. 특히 스트리밍 처리 프레임워크의 제약 사항을 직접 커스텀하여 비즈니스 요구사항에 맞춘 최적화 사례는 유사한 데이터 플랫폼을 운영하는 기술진에게 실무적인 통찰을 제공합니다.

DBT, Airflow를 활용한 데이터 계보 중심 파이프라인 만들기 (새 탭에서 열림)

네이버웹툰은 기존 데이터 파이프라인에서 발생하던 복잡한 데이터 적재(Backfill) 작업과 높은 운영 비용 문제를 해결하기 위해 DBT와 Airflow를 결합한 'Flow.er' 시스템을 구축했습니다. Flow.er는 데이터 간의 의존성을 명확히 정의하는 데이터 계보(Lineage)를 중심으로 설계되어, 엔지니어가 데이터의 흐름을 온디맨드로 파악하고 관리할 수 있게 돕습니다. 이를 통해 데이터 품질을 높이는 동시에 여러 데이터 조직으로 확장 가능한 고도화된 데이터 플랫폼으로 발전하고 있습니다. **과거 파이프라인의 한계와 Flow.er의 탄생** * 과거에는 파이프라인 복구와 수동 백필 작업에 과도한 운영 리소스가 소모되어 업무 효율이 저하되는 문제가 있었습니다. * 데이터 간의 복잡한 연결 고리를 한눈에 파악하기 어려워 데이터 정합성을 유지하고 장애에 대응하는 데 한계가 존재했습니다. * 이러한 문제를 극복하기 위해 데이터 계보를 가시화하고 자동화된 운영이 가능한 'Flow.er' 서비스에 대한 PoC를 거쳐 실무에 도입했습니다. **DBT와 Airflow를 활용한 계보 중심 아키텍처** * **DBT의 역할**: SQL 기반의 데이터 모델링을 통해 데이터 변환 로직을 관리하며, 모델 간 의존성을 바탕으로 데이터 계보와 관련 문서(Documentation)를 자동 생성합니다. * **Airflow의 역할**: DBT로 정의된 모델들이 선후 관계에 맞춰 정확히 실행되도록 워크플로우를 오케스트레이션하고 스케줄링을 담당합니다. * **개발 생산성 향상**: 개인 인스턴스를 제공하여 개발자가 격리된 환경에서 모델을 테스트할 수 있게 하고, CI/CD 파이프라인을 통해 코드 변경 사항을 안전하게 배포합니다. **시스템 안정성 및 확장을 위한 컴포넌트** * **Playground & Tower**: 자유로운 데이터 실험을 위한 샌드박스 환경인 Playground와 파이프라인 상태를 실시간으로 감시하는 Tower를 통해 운영 가시성을 확보했습니다. * **Partition Checker**: 상위 데이터 소스의 파티션 생성 여부를 사전에 체크하여 데이터 누락을 방지하고 적재 정합성을 획기적으로 개선했습니다. * **Manager DAG System**: 수많은 데이터 모델과 DAG를 효율적으로 관리하기 위해 관리 전용 시스템을 개선하여 운영 편의성을 극대화했습니다. **Flow.er의 미래와 기술적 지향점** * **MCP(Model Context Protocol) 서버**: 데이터 모델의 컨텍스트를 외부 도구나 AI 에이전트가 이해할 수 있는 규격으로 제공하여 데이터 활용도를 높일 예정입니다. * **AI Agent 연동**: 단순한 파이프라인 운영을 넘어 AI가 데이터 계보를 분석하고 문제를 해결하거나 코드를 최적화하는 단계로의 발전을 준비하고 있습니다. 데이터 파이프라인의 복잡성으로 인해 백필과 운영에 고통받고 있다면, DBT를 활용해 계보를 명확히 정의하고 이를 Airflow와 유기적으로 연결하는 접근 방식이 필수적입니다. 데이터 계보 중심의 아키텍처는 단순한 자동화를 넘어 데이터 프로덕트의 신뢰성을 담보하는 가장 강력한 수단이 될 것입니다.

쿠팡 SCM 워크플로우: 효율적이고 확장 가능한 low-code, no-code 플랫폼 개발 | by 쿠팡 엔지니어링 | Coupang Engineering Blog | Medium (새 탭에서 열림)

쿠팡 SCM 팀은 복잡한 공급망 관리 과정에서 발생하는 다양한 직군 간의 협업 비용을 줄이고 시스템 확장성을 높이기 위해 'SCM 워크플로우 플랫폼'을 구축했습니다. 이 플랫폼은 Low-code와 No-code 방식을 도입하여 개발자뿐만 아니라 비개발자도 직접 데이터 파이프라인을 설계하고 서비스에 적용할 수 있는 환경을 제공합니다. 이를 통해 요구사항 변화에 민첩하게 대응하며, 데이터 생성부터 프로덕션 연동까지의 전 과정을 효율화하는 것을 목표로 합니다. **No-code 데이터 빌더를 통한 데이터 접근성 혁신** * **다양한 데이터 소스 통합:** Redshift, Hive, Presto, Aurora, MySQL, Elasticsearch, S3 등 산재한 공용 데이터 소스에 대한 접근 및 질의를 코드 없이 수행할 수 있습니다. * **시각적 노드 기반 설계:** 사용자는 데이터 추출, 계산, 연동 등의 과정을 시각적인 '노드'로 생성하고 연결함으로써 직관적인 데이터 워크플로우를 구성할 수 있습니다. * **협업 효율화:** 비즈니스 분석가(BA)나 데이터 사이언티스트가 개발자에게 매번 파이프라인 생성을 요청하던 기존 프로세스를 개선하여, 스스로 데이터를 가공하고 시스템에 반영할 수 있게 함으로써 커뮤니케이션 비용을 획기적으로 낮췄습니다. **Low-code 기반의 서비스 확장 및 운영 효율화** * **도메인 확장성 확보:** 새로운 시스템을 매번 구축하지 않고도 워크플로우 설정을 통해 도메인을 확장할 수 있어, 변화가 빠른 이커머스 환경에 유연하게 대처합니다. * **기존 도구의 복잡성 해소:** Jenkins, Airflow, Notebook 등 파편화된 도구들이 가진 연결성 문제를 단일 플랫폼 안에서 통합하여 관리 편의성을 높였습니다. * **신속한 서비스 론칭:** 간단한 조작만으로 데이터를 시각화하거나 간단한 서비스를 출시할 수 있는 환경을 제공하여 아이디어의 실행 속도를 높였습니다. **실용적인 결론 및 제언** SCM 워크플로우 플랫폼은 데이터 기반 의사결정의 주체를 전 직군으로 확대하는 '데이터 민주화'를 실현하는 도구입니다. 복잡한 MSA(마이크로서비스 아키텍처) 환경에서 데이터 파이프라인 유지보수에 많은 리소스를 소모하고 있는 조직이라면, 이러한 로우코드 기반의 워크플로우 플랫폼을 도입하여 엔지니어링 역량을 핵심 알고리즘 개발에 집중시키고 운영 효율을 극대화할 것을 추천합니다.