데이터 팀 조직 구조의 3가지
- 중앙 집중 구조
- 데이터 엔지니어, 데이터 분석가, 데이터 엔지니어가 한 조직에 속해 같이 일을 하는 모습
- 분산 구조
- 현업 조직 밑에 소속됨. 인프라를 구축하는 엔지니어들은 보통 중앙 집중 구조에 속함
- 하이브리드 구조
- 중앙 집중+분산 구조의 형태. 평소에는 중앙 집중 구조를 진행하다가 프로젝트같이 단발성의 경우 분산구조로 진행
중앙 집중 구조
모든 데이터 팀원들이 하나의 팀으로 존재
- 일의 우선 순위는 중앙(데이터팀)이 최종 결정
- 데이터 팀원들간의 지식과 경험의 공유가 쉬워지고 커리어 경로가 더 잘 보임
- 하지만 현업부서들의 만족도는 상대적으로 떨어짐.
- 데이터 팀장이 어떻게 일을 진행하냐에 따라 현업부서의 만족도가 달라짐.
타 부서 : “데이터 팀의 업무가 현업 속도를 못따라 갑니다. 저희 팀에 자체적으로 데이터 분석가를 채용할 수 는 없을까요?” 이런 요구사항 이 계속해서 쌓이다 보면 결국 조직개편을 통해 분산 구조가 이루어 질 수 있음.
분산 구조
데이터 팀이 현업 부서별로 존재
- 일의 우선 순위는 각 팀별로 결정
- 데이터 일을 하는 사람들간의 지식/경험의 공유가 힘들고 데이터 인프라나 데이터의 공유가 힘들어짐
- 공유가 안되는 중복된 데이터를 관리하게 됨.(리소스 과다 사용) 결국 팀 별로 데이터 관리자를 채용하게 됨( 과채용)
- 이러한 경우 조직개편을 통해 하이브리드 구조로 변경될 수 있음.
- 현업부서들의 만족도는 처음에는 좋지만 많은 수의 데이터 팀원들이 회사를 그만두게 됨
2가지 경우 존재
- 중앙 집중 구조에서 조직 개편을 통해 분산 구조화
- 자생적으로(마케팅 팀을 예시로 마케터 중 데이터를 잘 만지는 사람이 들어와서 자생적으로 데이터와 마케팅을 함께 할 수 있는 인력이 충원 됨.) 혹은 인수합병 등을 통해 조직별 데이터팀 존재 <- 이거 완전 이전 직장
- 어떤 문제들이 존재하는가?
- 서로 다른 데이터 전략
- 회사 전체로 볼 때 불완전한 데이터 셋
- 중복 투자
- 보안/규제 관련 이슈 발생 가능성 증가
- 하지만 이는 어쩔 수 없는 트렌드로 보임
- 이 관점에서는 클라우드 이전이 도움이 됨
- 클라우드도 대세다.
****
하이브리드 모델
중앙집중과 분산
- 가장 이상적인 조직 구조
- 데이터 팀원들은 일부는 중앙에서 인프라적인 일을 수행하고 나머지는 현업팀에서 작업
- 중소 규모 회사에서는 기능/목적 조직구조의 형태로 데이터팀 안에서 커리어 경로를 만들 수 있음
회사의 크기에 따른 데이터 조직 형태의 차이점
대형 회사
회사가 아주 커지면 회사 전체 데이터 통합 웨어하우스의 구성은 불가능해짐
- 조직 별로 데이터 시스템을 별도로 갖추게 되고 필요에 따라 통합 시스템을 구성함.
그렇다면 분산구조의 단점(중복 투자 등)은 어떻게 극복 할 것인가?
- 데이터 메쉬를 이용데이터 메쉬 : 중앙 관리와 표준을 염두에 둔 데이터 분산 데이터 아키텍처각 조직별로 데이터 시스템을 갖추어 현업 속도를 늘리되, 각 조직에 어떤 데이터가 있는지 카탈로그를 만들어 공유하고 쉽게 찾을 수 있도록 메이킹.현재로는 기술이라기 보다는 개념에 가까움 조직/문화적인 준비가 필요한 개념이기도 함. 마이크로 서비스와 아주 흡사한 원칙을 갖고 있음 마이크로 서비스 : 웹서비스를 다수의 작은 서비스들로 구현 후 연동 이전에는 하나의 웹서비스로 진행했는데 크기가 커질 수록 속도가 느려지며 관리가 용이하지 않음.

[마이크로서비스 형태]
각 서비스들은 팀 단위로 원하는 언어/기술로 개발하는 자율성을 가짐
각 서비스들은 계약관계로 지켜야하는 책임이 있고 서비스 정보를 등록해야 함
- 마이크로소프트의 예
- 2018년 기준 법무팀과 재무팀의 경우 별도 데이터 시스템 구축
- 그 전에는 조직별로 별도 법무팀과 재무팀 존재
- 별도 시스템을 구성하면서 시스템을 Azure로 이전
- 법무팀과 재무팀을 별도의 팀으로 합치면서 인력비 감축 및 더욱 효율적인 업무를 진행 할 수 있게 됨.