04. 데이터 팀과 백엔드 협업 상세

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

• 데이터 팀은 백엔드 팀에게 테이블명 외에 어떤 business contract를 필요로 하는가?
• 기능 변경, schema 변경, event 변경을 데이터 팀과 어떻게 리뷰해야 하는가?
• 장애가 났을 때 백엔드와 데이터 팀은 source, pipeline, target 책임을 어떻게 나누는가?
• 협업 문서에 owner, freshness, replay, quality rule을 어떻게 남겨야 하는가?

개요

데이터 팀과 백엔드 협업은 “이 테이블에서 가져가세요”로 끝나지 않는다.

테이블과 event에는 업무 의미, 상태 전이, 삭제/취소 규칙, key 안정성, 지연 허용치, 재처리 방법이 함께 있어야 한다.

백엔드 서비스는 운영 DB의 owner이고, 데이터 팀은 그 데이터를 여러 소비자가 믿을 수 있는 형태로 이동시킨다. 두 팀이 같은 단어를 다른 의미로 쓰면 mart, search index, recommendation feature가 조용히 틀어진다.

데이터 팀이 실제로 필요한 것

데이터 팀이 필요한 것은 컬럼 목록보다 다음 정보다.

• 이 row 또는 event가 어떤 업무 사실을 의미하는가?
• key는 재사용되거나 변경될 수 있는가?
• 상태값은 어떤 순서로 바뀌는가?
• 취소, 환불, 삭제, 만료는 어떻게 표현되는가?
• eventTime은 사용자가 행동한 시간인가, DB commit 시간인가?
• late event와 중복 event는 발생할 수 있는가?
• backfill을 어느 기간까지 허용할 수 있는가?
• 개인정보, 접근 권한, 보관 기간 제약은 무엇인가?

이 정보가 없으면 SQL은 작성할 수 있어도 데이터 제품은 신뢰하기 어렵다.

협업 계약 템플릿

source_owner: order-service
data_owner: data-platform
business_owner: finance
 
source:
  table: orders
  event: OrderPaid v2
  key: orderId
  grain: one row per paid order event
 
meaning:
  paidAmount: coupon applied final paid amount
  orderStatus: CREATED -> PAID -> CANCELED -> REFUNDED
  eventTime: payment approved time
 
change_policy:
  compatible_change: optional field add
  breaking_change: required field removal, enum meaning change
  review_required: new status, amount calculation change, delete policy change
 
operation:
  freshness_sla: 30 minutes for finance mart
  replay_range: 180 days
  quality_rules: count, amount sum, status distribution

이 템플릿은 문서이지만 동시에 운영 계약이다.

owner와 freshness가 없으면 장애 때 아무도 우선순위를 정하지 못한다.

PR 리뷰에서 물어볼 질문

백엔드 PR에는 다음 질문이 들어가야 한다.

• 새 column이나 enum이 downstream schema를 깨뜨리는가?
• integration event version을 올려야 하는가?
• 기존 mart의 grain이 바뀌는가?
• 검색 색인에 반영되어야 하는 field인가?
• 추천 feature에서 제외해야 하는 traffic인가?
• quality rule을 추가하거나 threshold를 바꿔야 하는가?
• 기존 데이터 backfill이 필요한가?

이 질문은 데이터 팀을 늦게 끼워 넣기 위한 절차가 아니다.

서비스 변경의 영향 범위를 개발 중에 드러내기 위한 안전장치다.

변경 협의의 단위

좋은 협업은 “DB schema 변경”과 “event 계약 변경”을 구분한다.

변경	백엔드 관점	데이터 팀 관점
column 추가	migration 필요	mart와 quality rule 영향
enum 추가	코드 분기 추가	unknown value 처리
event field 추가	producer 변경	schema compatibility
상태 전이 변경	domain rule 변경	metric definition 변경
soft delete 추가	query filter 변경	삭제 event, historical fact 처리

같은 변경도 서로 다른 장애를 만든다.

장애 중 협업

장애가 나면 blame보다 먼저 source와 target을 나눈다.

1. source DB의 사실이 맞는가?
2. outbox 또는 CDC에 변경이 기록됐는가?
3. broker와 consumer lag가 있는가?
4. transform logic이 새 상태값을 해석하는가?
5. mart, index, feature target이 최신인가?
6. quality rule이 어떤 dimension에서 실패했는가?

백엔드는 1~2번과 event 의미를 빠르게 확인해야 한다.

데이터 팀은 3~6번과 재처리 범위를 확인한다.

경계가 명확하면 장애 대응이 “우리 쪽 아님”으로 흐르지 않는다.

작은 프로젝트에서의 최소 협업

개인 프로젝트나 작은 팀에서도 복잡한 플랫폼이 꼭 필요한 것은 아니다.

다만 다음 파일이나 table은 있으면 좋다.

• event catalog markdown.
• dataset owner 목록.
• batch run history table.
• quality rule SQL 목록.
• backfill command와 검증 쿼리.

작게 시작하더라도 source 의미와 재처리 방법은 남겨야 한다.

운영 지표

• unreviewed_schema_change_count: 데이터 영향 리뷰 없이 배포된 변경 수.
• unknown_enum_seen_count: downstream에서 처음 본 enum 값 수.
• event_catalog_coverage: 주요 event 중 계약 문서가 있는 비율.
• data_owner_missing_count: owner가 없는 dataset 수.
• backfill_request_lead_time: backfill 요청부터 실행까지 걸린 시간.

협업 지표는 팀의 성실함이 아니라 운영 계약의 빈 곳을 드러낸다.

위험 신호!

• 데이터 팀에 ERD와 컬럼명만 전달한다.
• 상태값 추가가 기능 PR에서는 작아 보이지만 mart 정의를 바꾼다.
• event catalog가 실제 payload와 다르다.
• 장애 때 source owner와 dataset owner가 서로 다르게 말한다.
• 재처리 가능 기간과 개인정보 보관 정책이 문서화되어 있지 않다.

확인 질문

확인 질문

• 데이터 팀이 orderStatus enum의 상태 전이를 알아야 하는 이유는 무엇인가?
• soft delete 도입이 리포트와 검색에 각각 다른 영향을 주는 이유는 무엇인가?
• 백엔드 PR에서 quality rule 변경 필요성을 묻지 않으면 어떤 장애가 생길 수 있는가?
• 장애 중 source DB, outbox, consumer, mart를 순서대로 확인해야 하는 이유는 무엇인가?

참고 문서

• Apache Kafka Documentation
• Spring for Apache Kafka Reference
• PostgreSQL Documentation
• Martin Kleppmann, Designing Data-Intensive Applications