데이터 분석 파이프라인 구축 PoC 회고

1. 왜 이 문제를 해결해야 했는가

당시 데이터 분석 요청은 대부분 운영 DB에서 수작업으로 데이터를 추출하고 가공하는 방식으로 처리되고 있었어요. 문제는 요청이 규칙적이지 않았다는 점이에요.

분석 요청은 주 1회 이상 발생
데드라인 2~3시간 전에 급하게 요청되는 경우가 많음
요청마다 조건이 조금씩 달라 매번 쿼리를 수정해야 함

결과적으로 데이터를 추출하는 시간보다, 결과를 검증하는 시간이 더 오래 걸리는 상황이 반복되었어요. 조금만 실수해도 지표가 달라졌고, 재요청이 발생했어요.

이 문제는 단순히 "쿼리를 잘 짜면 되는 문제"가 아니라, 분석 업무 자체가 시스템의 보호를 받지 못하고 있다는 구조적 문제라고 판단했어요.

2. 문제를 어떻게 정의했는가

처음에는 "왜 이렇게 급하게 요청이 올까?", "미리 작업해두어도 되는건가?"라는 불편함만 떠올랐어요. 하지만 구조적으로 보면 문제는 명확했어요.

운영 DB를 직접 조회하는 방식
분석 로직이 사람의 손에 의존
지표 정의가 명확하게 되어있지 않음

결국 분석을 '업무'로 처리하고 있었지, '시스템'으로 제공하지 않고 있었어요.

그래서 이 문제를 다음과 같이 재정의했어요.

"반복되는 분석 패턴을 사람이 아니라 시스템이 책임지게 만들 수 없는가?"라는 생각이 머릿속을 지배했어요. 그러던 중 시니어 개발자분이 평소에 데이터 엔지니어링에 관심이 있었고, 저 역시 관심있어 하는 것을 잘 알기에 다른일에 시간을 더 쓸수 있게 우리가 데이터 분석과의 결합도를 낮추기 위해 시스템을 제공하자고 제안해주었어요.

경험이 전무하던터라 시니어 개발자분이 리딩해주셨고 서포터로 참석할 수 있는 기회가 되었어요.

3. 선택 가능한 대안들은 무엇이었는가

문제를 정의한 뒤, 몇 가지 선택지를 검토했죠.

① 기존 방식 유지 + 쿼리 템플릿화

빠르게 적용 가능
하지만 여전히 운영 DB 직접 접근
데이터 품질 검증은 사람의 몫

→ 쿼리 템플릿화해서 제공하였지만, 여전히 데이터 정합성의 문제가 존재했어요

② 배치 기반 데이터 마트 구축

안정적인 분석 가능
하지만 데이터 반영까지 지연 발생
실시간에 가까운 요청에는 대응 어려움

→ 유지보수의 책임 문제가 있었어요.

③ CDC 기반 분석 파이프라인 구축

운영 DB 부하 없이 변경 데이터 수집 가능
분석 데이터를 상시 최신 상태로 유지 가능
초기 설계 비용은 높지만, 반복 비용은 낮음

→ PoC로 검증해볼 가치가 있다고 판단

4. 그래서 어떤 선택을 했는가

결론적으로 CDC 기반 데이터 분석 파이프라인을 PoC로 구축하기로 결정했죠.

핵심 선택은 다음과 같았죠.

• 운영 Aurora RDB → AWS DMS로 변경 데이터 수집 • S3 Raw 데이터 적재 • Glue를 통한 정제 및 변환 • Athena로 즉시 조회 가능한 분석 환경 제공

이 선택의 목적은 명확했죠.

"분석 요청이 들어오기 전에, 이미 분석 가능한 상태를 만들어두자."

5. 구현에서 가장 중요했던 포인트

① 반복 분석 패턴에 맞춘 스타 스키마 설계

대부분의 분석 요청은 • 날짜별 • 상품별 • 상태 조건 기반 집계

라는 공통 패턴을 가지고 있었어요.

그래서 분석가가 매번 복잡한 조인을 하지 않도록 Fact / Dimension 중심의 스타 스키마 구조를 적용했어요.

지표 정의가 달라질 수 있는 부분은 조건으로 조합할 수 있도록 Dimension에 위임했어요.

② 스키마 단위 데이터 품질 검증(DQ)

수작업 분석에서 가장 시간이 많이 들었던 것은 "이 상태가 맞는지 다시 확인하는 과정"이었어요.

이를 줄이기 위해 • Null 체크 • 타입 검증 • 기본적인 무결성 검증

을 Glue 변환 단계에서 사전에 수행하도록 설계했어요.

분석 결과를 의심하는 시간이 줄어들면, 분석 자체에 집중할 수 있다고 판단했어요.

6. 결과는 무엇이 달라졌는가

PoC 적용 이후 변화는 명확했죠.

• 분석 리드타임: 1~2시간 → 즉시 조회 • 월 평균 4회 발생하던 수동 작업 제거 • 재요청 건수: 사실상 0건 • 분석 요청 대응 시간 단축으로 주당 약 2시간 절감

무엇보다 "급하게 데이터를 뽑아야 하는 상황" 자체가 사라졌어요.

7. 이 경험을 통해 얻은 판단 기준

이 프로젝트를 통해 명확해진 기준이 있죠.

• 분석 요청이 반복된다면, 그건 업무가 아니라 시스템 대상이에요 • 데이터 품질은 분석 결과가 아니라, 파이프라인에서 보장해야 해요 • 사람의 주의력에 의존하는 구조는 반드시 한계에 도달해요

자동화의 목적은 편의가 아니라 신뢰도라는 점을 다시 확인했어요.

8. 다음에 다시 한다면

PoC 단계에서는 평소 간헐적으로 들어오던 분석 지표만 정의하여 진행했어요. 그러다보니 다른 통계에서 사용할 팩트 테이블을 미리 정의해두었으면 더 유연하게 구성할 수 있었겠다는 생각이 들어요. 다음에는 파이프라인 설계와 동시에 지표 정의 문서와 스키마 계약을 함께 가져갈 것이에요.

"업무 담당자가 무엇을 고민하지 않아도 되게 만들 것인가"라는 엔지니어의 근본적인 역할을 다시 한번 생각하게 되었어요.