SSOT 이상과 환상 그리고 지금까지 겪어온 경험을 이야기를 해볼까합니다.
SSOT란 무엇인가?
Single Source of Truth : 모든 데이터가 단 하나의 출처에서 관리되어야 한다는 원칙
- 이 출처 외에 존재하는 데이터는 ‘참조용’일 뿐, 데이터의 진실로 간주되지 않습니다.
- 데이터의 일관성을 유지하고 중복을 방지하며, 데이터 관리의 효율성을 높이기 위해 사용됩니다.
- SSOT가 부재한 환경에서는 명확성, 생산성, 유지 관리 등 전방위적인 문제가 터져 나오기 시작합니다.
현실은?
제가 겪은 문제는 아래와 같습니다.
- 같은 값이 재무, 구글 시트, 내부 백오피스 등 여러 곳에서 제각각 다르게 관리되고 있고 어떤 값이 정확한 값인지 알수가 없습니다.
- 심지어 하나의 데이터베이스 안에서도, 같은 의미의 값이 여러 컬럼 값으로 달리 존재했습니다.
- 이미지 URL 조차 덮어쓰기, 하드코딩 등으로 누가 무엇을 사용하는지도 모르는 상황이었습니다.
- 모든 팀이 필요에 따라 데이터를 만들어 쓰면서도, 그로 인한 책임은 결국 데이터팀으로 귀결되었습니다.
SSOT 구축을 위한 첫 시도
이 상태로는 안된다고 판단하여, 다음과 같은 시도를 했습니다.
- Superset을 활용한 메타데이터 수집
- 테이블, 칼럼 정보 수집
- 인프라 비용, 각 팀에서 관리되는 데이터를 팀 내부에서도 확인이 어렵고 비협조적인 태도로 난항을 겪었습니다.
- 주요 협업 영역부터 정리 시작
- 각 팀과 합의 및 스키마 정의
- 초반 3~4개월 간은 문제가 없었습니다.
문제의 시작
- 협업 및 공감했던 사람들의 이직/팀 변경
- 공유 없이 Prod 배포되는 변경 사항
- 스키마 변경 시 알림 시스템은 있었으나, 발생하여도 배포까지 오래 걸리니 “알아서 처리해라” 반응
- 심지어 로그 값도 공유 없이 변경되거나 자체 코드 삭제, 기존에 합의된 칼럼에 맞지 않는 값 배포하기 시작했습니다.
- 중복이 발생되거나 다른 서비스값과 연동될 데이터 값이 들어오지 않았고 이를 문제제기하여 중복을 식별 가능한 값이 개선되기 까지 6개월 넘게 소요되었습니다.
이쯤되니 드는 생각은 하나였습니다.
데이터적인 관점에서 공감대 형성 회의 및 개선 요청하여도 개선할 의지가 없고, 강제화하지 않는데 어떻게 바꿀 수 있을까?
SSOT가 실패한 이유
단순히 시스템이 부족해서보다는 프로세스를 체계화하고 공감대를 형성하는 과정이 필요한데, 이를 이끌어내는 부분이 어렵고 방법을 잘 모르겠습니다.
- 사람은 바뀌고, 책임은 사라지고, 기준은 문서로만 있습니다.
- 데이터팀이 감당하지 못할 책임을 지고 있는 구조
- “나만 아니면 돼” 라는 마인드를 변경할 만한 힘
SSOT는 기술적인 시스템이 아닌 조직의 신뢰 체계였습니다.
배운 점
주니어 2명이 300명이 넘는 조직의 데이터를 지킨다는 건 현실적으로 불가능합니다.
SSOT가 이루어지기 위해선, 조직 내 프로세스화, 책임의 재정의, 지속적인 교육이 필요하다고 느꼈습니다.
가장 중요한 것은 아래인거 같다고 생각이 듭니다.
데이터는 모두의 것이라는 조직 문화
- SSOT는 단순 합의 및 선언만으로 만들어지지 못한다.
- 문서화보다 중요한 것이 프로세스화이며, 책임의 공유가 필요합니다.
- 데이터 관리에는 기술이 아닌 사람이 있다.