이상적인 DataOps 조직 구조

조직의 외부 커뮤니케이션은 내부 커뮤니케이션을 반영하는 경향이 있습니다. 이것이 바로 Melvin Conway가 우리에게 가르쳐 준 것이며, 이는 데이터 엔지니어링에도 적용됩니다. 명확하게 정의된 데이터 운영(DataOps) 팀이 없다면, 회사의 데이터 출력물은 입력 데이터만큼이나 엉성할 수 있습니다.

데이터 운영은 데이터를 생성, 처리하고 유지 관리하기 위해 인프라를 구성하는 프로세스일 뿐만 아니라, 이 업무를 수행하는 팀의 이름이기도 합니다. 이 팀을 흔히 데이터 운영(DataOps) 팀이라고 부릅니다. 그렇다면 DataOps의 역할은 무엇일까요? 회사가 데이터 파이프라인을 운영하고 있다면 이 파이프라인을 관리하기 위해 DataOps라는 이름으로 하나의 팀을 출범시키는 것만으로도, 기존에는 부족했던 조직화와 통제력을 가져올 수 있습니다.

DataOps는 데이터를 판매하는 기업만을 위한 것이 아닙니다. 최근의 역사를 보면 데이터의 출처나 용도에 관계없이 데이터 운영 팀이 필요하다는 것이 입증되었습니다. 내부 고객이든 외부 고객이든 모두 동일합니다. 파이프라인을 구축하거나, 현실적으로는 기존 파이프라인을 물려받아 다시 구축하려면, 하나의 팀이 필요합니다. 이 팀은 관측 가능성 및 추적 툴을 구현하고, 데이터의 네 가지 속성 전반에 걸쳐 데이터 품질을 모니터링하는 역할을 맡아야 합니다(많은 조직에서는 이 역할을 한 명이 담당하기도 합니다).

물론, 파이프라인을 구축한 사람들이 대시보드가 다운되었을 때 받는 두려운 PagerDuty 알림을 직접 받아야 합니다. 이는 처벌을 위한 것이 아니라 교육을 위한 것입니다. 자신이 책임을 지고 있는 상황에서는 사람들의 설계 방식이 달라집니다. 이는 좋은 동기 부여가 되며, 문제 해결 능력을 높이고 보다 신속한 대응을 가능하게 합니다.

마지막으로, 데이터 운영 팀에는 단순히 A 지점에서 B 지점으로 데이터를 이동하는 것을 넘어서는 사명이 필요합니다. 이것이 바로 팀명에서 '운영(operations)'이라는 부분이 중요한 이유입니다.

데이터 운영은 의도한 목적에 맞게 데이터를 이동하기 위한 탄력적인 프로세스를 구축하고 있습니다. 모든 데이터는 이동해야 하는 이유가 있어야 합니다. 그 이유는 수익인 경우가 많습니다. 데이터 운영 팀이 최종 목표(예: 영업 팀이 더 나은 예측을 하고 더 많은 수익을 창출하는 것)에서 파이프라인 관리 활동까지의 명확한 연결고리를 추적할 수 없다면 문제가 있는 것입니다.

운영 팀이 없으면 규모가 커질수록 다음과 같은 문제가 발생할 수 있습니다.

• 데이터 중복
• 협업 문제
• 데이터 대기 시간
• 나중에 문제를 일으킬 임시방편
• 탐색 문제
• 연결되지 않는 툴
• 로그 불일치
• 프로세스 부재
• 책임자와 SLA 부재

연결이 끊어지면 단순히 기존 방식의 데이터 관리만 하고 있는 것입니다. 데이터 관리는 데이터 운영의 기계적 유지 관리 측면입니다. 이는 중요하기는 하지만 전략적인 것은 아닙니다. 유지 관리 모드에서는 누락된 열이나 파이프라인 장애의 원인을 찾아 임시로 수정하게 되지만, 계획을 세우고 개선할 시간은 없습니다.

진정한 운영 업무는 발생한 문제 티켓을 반복 가능한 해결책으로 바꿀 때 시작됩니다. 한 예로 파트너로부터 발생한 변환 오류를 발견하고, 이 오류가 파이프라인에 영향을 미치기 전에 파트너에게 이메일을 보내 수정하도록 요청하는 경우를 들 수 있습니다. 또는 경영진의 대시보드에 문제가 발생했음을 알려주는 '알림' 배너를 구현하여, 업데이트가 완료될 때까지 기다리도록 안내할 수도 있습니다. 데이터 운영은 개발자 운영과 마찬가지로 반복 가능하고, 테스트 가능하며, 설명 가능하고, 직관적인 시스템을 구축하여 궁극적으로 모든 사람의 수고를 덜어주는 것을 목표로 합니다.

이것이 바로 데이터 운영과 데이터 관리의 차이입니다. 그렇다면 데이터 운영 팀을 어떻게 구성해야 할까요?

이제 처음 시작한 부분으로 돌아가서 시스템 출력이 조직 구조를 어떻게 반영하는지에 대해 이야기해 보겠습니다. 데이터 운영 팀이 이름뿐인 '운영' 팀이고 대부분 유지 관리만 한다면, 끝없이 늘어나는 요청 백로그가 생길 가능성이 높습니다. 장기적인 유지 관리 변경(예: 시스템 교체, 프로세스 조정)위해 숨 돌릴 시간조차 거의 없습니다. Jira나 ServiceNow에서 발생하는 응답 지옥에 갇히게 됩니다.

반면에 강력한 원칙과 구조로 데이터 운영 팀을 설립(또는 재출시)했다면 고품질의 내부 구조를 반영하는 데이터를 생성하게 됩니다. 데이터 운영 팀 구조가 좋으면 좋은 데이터를 낳게 됩니다.

데이터 엔지니어, 데이터 과학자, 분석가를 그룹 또는 '파드'로 모아 이전에는 각자 따로 해결했을 문제를 함께 해결하도록 하세요. 이 세 가지 관점이 모이면 더 나은 결정, 책임 회피 감소, 그리고 더 큰 선견지명으로 이어집니다. 예를 들어, 데이터 과학자가 이해하기 어려운 노트북을 작성해 엔지니어에게 전달하고, 그로 인해 반복적인 질문과 확인이 오가는 상황 대신, 데이터 과학자와 분석가가 필요한 사항을 함께 논의하고, 엔지니어가 어떻게 구현해야 하는지 설명할 수 있습니다.
많은 데이터 운영 팀이 이미 이러한 방식으로 작업하고 있습니다. Uber의 Krishna Puttaswamy와 Suresh Srinivas는 "팀은 '풀 스택'으로 구성되어야 하며, 이를 통해 데이터의 전체 수명 주기를 장기적 관점에서 관리할 수 있는 데이터 엔지니어링 인재를 확보할 수 있습니다"라고 말합니다. 여행 사이트 Agoda에서도 같은 이유로 엔지니어링 팀이 파드를 사용합니다.

단 한 명이라도 이 작업을 수행하세요. 각 역할은 누군가가 반드시 맡아야 하는 '모자'와 같습니다. 데이터 운영 팀의 기능을 높이려면, 어떤 모자가 어디에 있는지, 그리고 누가 어떤 데이터의 소유자인지를 파악하는 것이 도움이 됩니다. 또한 각 개인의 통제 범위를 관리 가능한 수준으로 줄여야 합니다. 이렇게 정리하면 채용의 필요성을 설득하는 데 도움이 될 수도 있습니다.

데이터 운영 팀 관리란 무엇인가요? 서번트 리더의 역할을 하는 파드 구조 위에 있는 조정 계층입니다. 아들은 프로젝트를 관리하고, 지도하고, 방해물을 제거합니다. 이상적으로는 팀에서 가장 지식이 풍부한 사람이어야 합니다.

우리는 우리만의 이상적인 구조를 구상했으며, 아직 진행 중입니다. 중요한 점은 데이터에 대한 비전을 가진 한 명(VP)이 팀을 이끈다는 것입니다. 그 아래에는 여러 데이터 분야를 해당 비전을 향해 이끄는 리더들(Directors)이 있으며,그 아래에는 데이터 조직과 데이터 기능이 함께 작동하도록 하는 다학제(interdisciplinary) 팀이 있습니다. (이러한 아이디어는 데이터 솔루션 아키텍트인 Michael Harper의 공로입니다.)

북극성 지표(North Star Metric)를 선택하면 관련된 모든 사람이 무엇을 최적화해야 하는지 명확히 이해할 수 있습니다. 이러한 합의가 없으면 분쟁이 발생할 수 있습니다. 내부 데이터 '고객'이 데이터가 느리다고 불평할 수도 있습니다. 하지만 속도가 느린 이유는 그들이 은연중에 품질을 최우선으로 최적화하고자 한다는 것을 알기 때문입니다.

일반적인 DataOps 북극성 지표는 데이터 품질, 자동화(반복 가능한 프로세스), 프로세스 분산(즉, 최종 사용자의 자급자족)입니다.

북극성 지표를 정하면, 그 북극성을 가리키는 하위 지표나 하위 원칙을 결정할 수도 있습니다. 이러한 북극성 지표는 거의 항상 후행 지표(lagging indicator)입니다.

팀을 구성할 때 팀 내 여러 그룹이 자주 상호 작용하고 서로에게 요청할 수 있도록 하세요. 이러한 상호 작용은 귀중한 자산이 될 수 있습니다. Agoda의 수석 엔지니어링 관리자인 Amir Arad는 "데이터 과학자와 엔지니어가 서로의 작업 방식에 대해 알게 되면서 이들 팀은 더 빠르게 움직이고 더 많은 것을 생산하고 있습니다"라고 말합니다.

Amir는 다기능 팀의 약간의 중복성이 가진 숨겨진 가치 중 하나로, 팀원 누구도 생각하지 못했던 질문을 할 수 있다는 점을 꼽습니다.

Amir는 “엔지니어링 지식 격차는 사실 꽤 멋진 부분입니다. 이로 인해 우리가 단순화하도록 요구하기도 하거든요. 그들은 ‘그런데 왜 우리는 그렇게 할 수 없을까?’라고 묻기도 하고, 때로는 우리가 돌아가서 생각해보면 그 코드나 서버가 실제로 필요하지 않다는 것을 깨닫기도 합니다. 비전문가가 새로운 아이디어를 가져오는 경우도 있죠”라고 설명합니다.

DevOps와 마찬가지로 최고의 데이터 운영 팀은 눈에 띄지 않게 존재하면서, 직접 개입할 필요가 없을 정도로 프로세스를 돌아가게 합니다. 모든 사람을 구하기 위해 뛰어들어 시스템을 취약하게 만드는 영웅 역할을 하기보다는, 팀을 돕는 서번트 리더 역할을 하세요. 노자의 말처럼, 사람들이 '우리가 직접 해냈다'고 스스로 느낄 수 있도록 솔루션으로 이끄는 것을 목표로 하세요.

데이터 운영 팀을 제품 팀처럼 대하세요. 고객을 분석하고, 수정 사항은 백로그로 관리하며, 데이터를 실제로 활용할 수 있을 만큼 툴을 유용하게 만드는 것을 목표로 하세요.

데이터 모니터링 및 관측 가능성에 '너무 이른 시기'란 존재하지 않습니다. 모니터링을 미루기 위한 변명으로 흔히 쓰이는 비유가 '우리는 비행 중에 비행기를 만들고 있다'는 것입니다. 이 장면을 머릿속에 그려 보세요. 장기적인 생존을 위해 알아야 할 모든 것을 말해주지 않나요? 더 나은 비유는 평범한 건축입니다. 기초를 설치하는 것을 오래 미룰수록 비용이 더 많이 들고, 기초가 없어서 생기는 문제도 늘어납니다.

읽어보기: 데이터 관측성이란 무엇인가요?

데이터 인프라를 통해 지금 내리는 결정은, 막시무스 장군의 말처럼 '영원의 메아리'를 남길 것입니다. 오늘의 임시 성장 전략이 내일의 거대한 데이터 변환과 내부 시스템 혼란이라는 악몽으로 이어질 수 있습니다 불편하지만 올바른 결정을 내릴 수 있도록 경영진의 지원을 확보해야 합니다. 예를 들어, 문제를 해결하기 위해 한 분기가 필요하니 모든 요청을 잠시 중단하라고 알리는 식입니다.

CASE는 'copy and steal everything(모든 것을 모방하고 가져오기)'의 약자로, 모든 것을 처음부터 새로 구축하지 말라는 의미입니다. 오늘날에는 유용한 마이크로서비스와 오픈소스 제품이 매우 많습니다. 거인들의 어깨 위에 서서, 실제로 커스터마이징이 필요한 파이프라인의 40%에 집중하고, 이를 잘 구축하세요.

백로그에 있는 티켓을 살펴보세요. 문제를 사전에 예방하기보다는 사후에 대응하는 경우가 얼마나 자주 발생하나요? 해결한 문제 중 근본 원인을 명확하게 파악할 수 있는 문제가 몇 개나 되나요? 그중 몇 가지를 영구적으로 고칠 수 있었나요? 문제를 더 많이 예방할수록 진정한 데이터 운영 팀에 가까워집니다. 또한 데이터 관측성 툴이 얼마나 유용한지 더 잘 느낄 수 있을 것입니다. 완전한 가시성 확보는 단순한 유지 관리에서 적극적인 개선으로 전환하는 데 도움이 됩니다.

구조를 적극적으로 개선하는 팀은 데이터를 적극적으로 개선합니다. 내부의 조화는 외부의 조화로 이어지며, 이는 Melvin Conway가 자랑스러워할 만한 연결고리가 됩니다.

IBM Databand의 지속적인 데이터 관측 가능성 플랫폼에 대해 자세히 알아보세요. 이 플랫폼이 데이터 인시던트를 조기에 감지하고, 더 빠르게 해결하며, 비즈니스에 더 신뢰할 수 있는 데이터를 제공하는 방법을 확인할 수 있습니다. 더 자세히 살펴볼 준비가 되셨다면 지금 바로 데모를 예약하세요.