혹시 당신은 데이터를 모르는 백엔드 개발자 인가요?│인프콘2024

백엔드는 한 사용자나 요청의 행을 정확히 읽고 쓰는 데 집중하는 반면 데이터 팀은 특정 속성의 열을 전체 행에서 집계해 패턴과 비즈니스 인사이트를 찾는다. 사과 판매량이나 매출을 계산하려면 컬럼이 일관되게 분석 가능한 형태로 저장되어 있어야 한다. 같은 데이터를 보는 방향의 차이를 설계 때 이해하면 향후 집계 비용을 줄이고 새로운 분석 요구에 대응하기 쉬워진다.

애플리케이션에서 다루기 쉬운 JSON과 배열에 설정·태그를 넣으면 행 단위 처리는 편하지만 수억 행에서 여러 조건을 조합하는 분석은 매우 비싸진다. 결제 방식을 새 컬럼의 불리언 값으로 계속 추가하는 안전한 변경도 문서와 맥락이 없으면 분석가가 의미를 찾기 위해 사람을 수소문하게 만든다. 데이터가 분석에 쓰일 가능성과 스키마 확장을 처음부터 고려하고, 중요한 속성은 정규화된 구조와 명확한 의미를 갖게 해야 한다.

설계 이유와 컬럼의 의미를 전사 데이터 카탈로그에 모아 테이블·설명·문서를 한 번에 검색할 수 있게 하면 파편화된 지식과 반복 질문을 줄일 수 있다. 카탈로그를 구축하기 어렵다면 DB 코멘트에 원본, 허용 값과 생성 경로만이라도 자세히 기록해야 한다. 수십억 행 분석은 운영 RDBMS에서 수행하지 않고 Spark와 파일 형식, S3 기반 데이터 레이크 같은 분리된 환경에서 처리해 고객 트래픽과 분석 부하를 격리한다.

화면이 정상이어도 운영 스크립트와 수동 변경의 경로가 기록되지 않으면 서비스 만료일 같은 과거 상태를 재구성할 수 없어 데이터 유효성이 깨진다. 물리 삭제는 복구와 이탈 분석의 근거를 없애므로 미래 가치를 판단하기 어렵다면 저장을 우선하고, 하나의 완료 시각 컬럼에 주문과 배송처럼 여러 의미를 섞지 않아야 한다. 유효성·정확성·일관성을 갖춘 데이터만이 신뢰할 수 있는 의사결정을 만들며, 잘못된 기록은 결국 제품 전체의 판단을 왜곡한다.