05. 백엔드 개발자가 알아야 할 분석 요구사항 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• 분석 요구사항을 단순 컬럼 추가로 처리하면 어떤 문제가 생기는가?
• 백엔드 개발자는 지표, event, fact, freshness에 대해 무엇을 질문해야 하는가?
• 분석 요구가 API transaction과 데이터 파이프라인 중 어디에 속하는지 어떻게 판단하는가?
• 데이터 팀에 어떤 맥락을 제공해야 재처리 가능한 분석 모델이 되는가?

개요

분석 요구사항은 “컬럼 하나 더 내려 주세요”로 시작하는 경우가 많다.

하지만 실제로는 지표 정의, 집계 기준, event 의미, 지연 허용치, 재처리 범위가 함께 필요하다.

백엔드 개발자는 분석 SQL을 모두 작성하지 않더라도 원천 데이터의 의미를 가장 잘 아는 사람이다.

따라서 분석 요구를 받을 때 API 응답 필드처럼만 보지 말고 데이터 계약으로 봐야 한다.

원리

분석 요구사항은 네 가지 질문으로 나눠야 한다.

• 무엇을 측정하는가?
• 어떤 사건이나 상태를 source로 삼는가?
• 어느 시간과 어떤 dimension으로 집계하는가?
• 얼마나 늦어도 되고, 틀렸을 때 어떻게 다시 계산하는가?

이 질문 없이 table column부터 추가하면 나중에 dashboard마다 다른 수치가 나온다.

요구사항 질문지

metric: paid_order_amount
business meaning: 결제 완료 후 취소되지 않은 주문 금액
source event: OrderPaid, OrderCanceled, OrderRefunded
grain: order line
dimensions: order_date, product_category, member_grade
freshness: 30 minutes
late data policy: D+7까지 재계산
exclusion: test order, internal coupon
owner: commerce analytics

이 정도 정보가 있어야 데이터 팀은 fact와 mart를 안정적으로 만들 수 있다.

백엔드 팀은 source event와 status 의미를 정확히 설명해야 한다.

API 요구와 분석 요구 구분

질문	API 요구	분석 요구
누가 소비하는가	현재 사용자	운영자, 분석가, 제품팀
지연 허용	거의 없음	초, 분, 시간 가능
데이터 범위	한 사용자, 한 주문	기간, segment, cohort
정합성 기준	transaction 결과	freshness, completeness
실패 대응	API 오류	stale 표시, 재처리

사용자에게 즉시 보여야 하는 현재 주문 상태는 API 요구다.

어제 상품 카테고리별 결제 금액은 분석 요구다.

두 요구를 같은 repository method로 풀면 운영 DB와 지표 정의가 함께 흔들린다.

백엔드가 제공해야 할 원천 의미

분석 모델의 품질은 원천 의미 설명에 크게 의존한다.

백엔드 개발자는 다음을 제공해야 한다.

• status 값의 전이 순서
• 결제, 취소, 환불의 business event
• 테스트 데이터와 내부 데이터 구분 기준
• 삭제와 익명화 정책
• timestamp의 의미
• idempotency key와 중복 발생 가능성
• schema 변경 일정과 호환 기간

예를 들어 paid_at이 결제 승인 시각인지 주문 상태 변경 시각인지에 따라 일별 매출 기준이 달라진다.

Event Schema 예시

{
  "eventId": "evt-20260630-991",
  "eventType": "OrderPaid",
  "eventVersion": 1,
  "occurredAt": "2026-06-30T10:15:30+09:00",
  "orderId": 10042,
  "memberId": 77,
  "paymentId": "pay-555",
  "paidAmount": "49000.00",
  "currency": "KRW",
  "isTestOrder": false
}

이 event는 분석 요구에 필요한 source event가 될 수 있다.

단, 취소와 환불 event가 없으면 순매출 mart를 정확히 만들 수 없다.

Fact 요구 예시

CREATE TABLE fact_order_payment (
    payment_id varchar(50) PRIMARY KEY,
    order_id bigint NOT NULL,
    member_id bigint NOT NULL,
    paid_amount numeric(14, 2) NOT NULL,
    paid_at timestamp NOT NULL,
    source_event_id varchar(36) NOT NULL,
    loaded_at timestamp NOT NULL
);

이 fact의 grain은 결제 한 건이다.

분석 요구사항에는 grain이 명시되어야 한다.

주문 한 건, 주문 상품 line, 결제 한 건, 환불 한 건은 서로 다른 fact가 될 수 있다.

판단 축

• 분석 요구에 “기간별”, “카테고리별”, “전환율”이 나오면 지표 정의부터 확인한다.
• status column 추가 요청이면 그 status가 event로도 필요한지 묻는다.
• 현재 상태 조회인지 과거 사건 집계인지 구분한다.
• 지연 허용치가 있으면 API path에서 분리할 수 있는지 본다.
• 재계산해야 하는 기간과 late data 정책을 요구사항에 포함한다.

실패 모델

• “매출”이라는 단어만 합의하고 취소/환불 기준을 정하지 않는다.
• API response field를 그대로 mart column으로 사용한다.
• 테스트 주문 제외 기준이 백엔드와 분석 SQL에서 다르다.
• event가 결제 완료만 보내고 취소/환불을 보내지 않는다.
• 지연 허용치가 없어 dashboard 지연이 API 장애처럼 처리된다.

품질 검증

분석 요구사항에는 검증 방식도 들어가야 한다.

SELECT DATE(paid_at) AS paid_date,
       COUNT(*) AS payment_count,
       SUM(paid_amount) AS paid_amount
FROM fact_order_payment
WHERE paid_at >= TIMESTAMP '2026-06-30 00:00:00'
  AND paid_at < TIMESTAMP '2026-07-01 00:00:00'
GROUP BY DATE(paid_at);

이 SQL은 fact 수준 검증의 출발점이다.

최종 mart 검증은 source count와 금액 합계, freshness를 함께 봐야 한다.

협업 포인트

데이터 팀에는 column 목록보다 business rule을 전달한다.

인프라 팀에는 추출 방식, 예상 건수, peak time, 보관 기간을 전달한다.

QA에는 정상 주문뿐 아니라 취소, 환불, 테스트 주문, 늦게 들어온 event 케이스를 제공한다.

분석 요구사항 리뷰에는 백엔드, 데이터, 제품 owner가 함께 들어가는 편이 안전하다.

실전 팁

• “이 수치는 어떤 의사결정에 쓰이나요?”를 먼저 묻는다.
• “몇 분 늦어도 되나요?”를 물어 API와 pipeline 경계를 정한다.
• status column을 추가할 때 event와 mart 영향도 같이 본다.
• 분석 요구마다 metric owner와 정의 문서를 남긴다.
• schema 변경에는 downstream mart와 dashboard 영향 범위를 포함한다.

위험 신호!

• 분석 요구사항이 column 이름 목록으로만 되어 있다.
• event 의미와 발생 조건을 백엔드 팀만 알고 있다.
• dashboard 수치가 틀렸을 때 어떤 source event부터 볼지 모른다.
• late arriving data가 들어와도 과거 mart 재계산 정책이 없다.
• 지표 owner 없이 여러 팀이 같은 이름의 지표를 다르게 쓴다.

확인 질문

확인 질문

• 분석 요구사항에서 가장 먼저 확인할 것은 무엇인가?
  • 지표의 business meaning, source event 또는 source state, grain, dimension, freshness다.
• API 요구와 분석 요구를 나누는 핵심 기준은 무엇인가?
  • 현재 사용자 transaction에 즉시 필요한지, 기간과 segment를 두고 재계산 가능한 지표인지다.
• 백엔드 개발자가 데이터 팀에 반드시 제공해야 하는 정보는 무엇인가?
  • status 의미, event 발생 조건, key, timestamp 의미, 취소/삭제/환불 표현, schema 변경 계획이다.

참고 문서

• Kimball Group, Dimensional Modeling Techniques
• dbt Documentation
• Apache Kafka Documentation
• Martin Kleppmann, Designing Data-Intensive Applications