상태: 진행 중. 이 글은 현재까지 확인된 설계와 구현 범위를 정리합니다. 배포 완료나 사업 성과를 주장하지 않으며, 공개 범위가 확인되지 않은 명칭과 수치는 생략했습니다.

요약

  • 프로젝트: SCP 데이터 파이프라인(정식 공개 명칭 확인 필요)
  • 목표: 여러 출처의 이벤트를 공통 스키마로 분류하고 KPI 판정과 후속 처리에 연결
  • 역할: 분류 스키마, 판정 모듈, 실행 흐름, CI, 운영 알람 구현 주도
  • 현재 상태: 주요 구성요소 구현과 검증이 진행 중이며 프로덕션 결과는 미확정

배경

후속 자동화가 신뢰할 수 있으려면 원천 이벤트를 그대로 전달하는 것만으로는 부족합니다. 서로 다른 형태의 이벤트를 공통 기준으로 분류하고, 계산 가능한 KPI와 별도 집계가 필요한 KPI를 구분하며, 판정 결과가 언제 어떤 근거로 만들어졌는지 추적할 수 있어야 합니다.

SCP는 이 과정을 하나의 파이프라인으로 묶기 위한 작업입니다. 실제 도메인명, 고객·회사 식별자, 내부 리소스명은 공개하지 않습니다.

문제와 관찰 근거

확인된 문제는 다음과 같습니다.

  1. 이벤트 출처마다 payload와 의미가 달라 후속 로직이 소스별 예외를 떠안기 쉽습니다.
  2. 단순 합산할 수 있는 지표와 기간·집합 전체가 필요한 비가산 지표는 같은 방식으로 처리할 수 없습니다.
  3. 신규 데이터의 초기 적재와 이후 증분 처리는 실패 조건과 부하 특성이 다릅니다.
  4. 분류 성공만 확인해서는 KPI 누락, 판정 실패, 후속 처리 단절을 발견하기 어렵습니다.

현재 공개 가능한 근거는 작업 로그에 남은 분류 스키마, 판정 모듈, Lambda·EventBridge 실행 흐름, CI, 알람 구현 기록입니다. 사용자 영향과 사업 지표는 아직 공개 가능한 근거가 없습니다.

역할과 의사결정 범위

분류 스키마와 판정 모듈의 경계를 정하고, 서버리스 실행 흐름과 배포 검증, 운영 알람을 구현하는 역할을 주도했습니다. 다만 프로젝트가 진행 중이므로 최종 운영 책임 범위와 협업 인원은 다음 공개 전에 확인해야 합니다.

  • TODO: 정확한 프로젝트 기간과 팀 구성 확인
  • TODO: 설계·구현·리뷰·운영의 개인 책임 범위 확정

제약 조건

  • 원천별로 형태와 도착 시점이 다른 이벤트
  • 초기 적재와 증분 처리의 서로 다른 부하 패턴
  • 일부 KPI의 비가산성 및 기간 경계 정합성
  • 부분 실패 시 재처리와 중복 판정
  • 실제 계정·리소스·payload를 공개할 수 없는 보안 제약
  • 진행 중 시스템을 완료 성과로 표현할 수 없는 상태 제약

대안과 트레이드오프

1. 원천별 후속 처리

각 이벤트 소비자가 원천 payload를 직접 해석하는 방식입니다. 시작은 빠르지만 같은 분류 규칙이 여러 곳에 흩어지고, 스키마 변경 시 영향 범위가 커집니다.

2. 중앙 분류 후 공통 이벤트 발행

분류 스키마와 판정 경계를 중앙화하는 방식입니다. 초기 설계 비용은 들지만 후속 소비자는 공통 계약에 의존할 수 있고, 분류 실패를 별도로 관측할 수 있습니다. 현재 선택한 방향입니다.

3. 주기적 전체 재계산

정합성을 단순하게 유지할 수 있지만 데이터 규모가 커질수록 반복 비용이 커지고 결과가 늦어집니다. 초기 적재·복구 경로에는 유용하지만 모든 증분 처리의 기본 전략으로 삼기에는 부담이 있습니다.

구현

공개 가능한 논리 경계는 다음과 같습니다.

  1. 원천 이벤트를 수신하고 공개 가능한 공통 스키마로 정규화합니다.
  2. 분류 모듈이 이벤트 종류와 필요한 판정 경로를 결정합니다.
  3. 계산 방식에 따라 KPI를 갱신하거나 별도 집계 작업으로 보냅니다.
  4. 서버리스 이벤트 흐름이 단계별 실행과 후속 처리를 연결합니다.
  5. CI에서 스키마·판정 모듈 변경을 검증합니다.
  6. 치명 경로와 누락 가능성이 있는 경계에 운영 알람을 둡니다.
  7. 초기 데이터는 일반 증분 이벤트와 분리한 배치 경로로 적재합니다.

실제 endpoint, ARN, AWS 계정·리소스명, payload, 설정 원문과 비공개 코드는 의도적으로 생략했습니다.

실패와 막힘

진행 중 작업에서 확인된 핵심 위험은 비가산 KPI의 정합성과 초기 적재입니다. 이벤트 단위 업데이트가 전체 기간 집계와 같은 결과를 보장하는지 검증해야 하며, 초기 적재 중 부분 실패가 발생했을 때 어디서부터 재개할지도 명확해야 합니다.

구체적인 장애 사례와 해결 결과는 공개 가능한 작업 기록이 확보되지 않아 작성하지 않았습니다.

  • TODO: 실제 실패 사례의 증상·원인·복구 경로 확인
  • TODO: 중복 이벤트와 지연 도착 이벤트의 정책 확인

검증과 현재 결과

분류 스키마, 판정 모듈, 실행 함수, 이벤트 연결, CI, 알람의 구성요소 구현 기록은 확인했습니다. 그러나 다음 항목은 아직 확인되지 않았습니다.

  • 프로덕션 배포 완료 여부
  • 데이터 정합성 회귀 테스트의 범위와 결과
  • 초기 적재의 완료 조건과 재시작 검증
  • 사용자 또는 사업 지표의 변화

따라서 현재 결과는 **“구성요소를 구현하고 통합 검증을 진행 중”**으로 제한합니다. 처리량이나 성능 수치는 주장하지 않습니다.

한계와 후속 과제

  • 비가산 KPI의 기준 데이터와 재계산 전략을 명문화해야 합니다.
  • 초기 적재와 증분 처리 사이의 전환 조건을 검증해야 합니다.
  • 알람이 실제 복구 행동으로 이어지는지 운영 런북이 필요합니다.
  • 스키마 변경의 하위 호환성과 재처리 정책을 확인해야 합니다.
  • 공개 전 정식 명칭, 기간, 팀 구성, 검증 결과에 대한 사용자 확인이 필요합니다.

회고

이 프로젝트에서 중요한 판단은 함수의 수보다 데이터 계약과 실패 경계를 먼저 정하는 것입니다. 분류와 판정을 중앙화하면 관리 지점이 명확해지지만, 그 지점이 새로운 단일 실패점이 되지 않도록 재처리와 관측성을 함께 설계해야 합니다. 완료되지 않은 작업은 구현 사실과 기대 효과를 분리해서 기록해야 한다는 원칙도 유지합니다.

관련 글