오라일리의 <Fundamentals of Data Engineering>이라는 책을 번역하는 과정에서, 현장에서 내가 겪었던 아찔했던 기억들을 새삼 돌이켜볼 수 있었다. 당시에는 그냥 넘어갔지만, 이제 와서 생각해보면 움찔하게 만드는 순간들이었다.

매력적인 ‘이력서 주도 개발’의 함정

기술을 선택하는 과정은 언제나 오묘하며 깔끔하지 않을 때가 많다. 특정 기술을 검토할 충분한 시간이 주어지더라도 어느 한 측면이 내내 마음에 걸릴 수 있고, 또 다른 매력적인 측면이 오랫동안 마음을 사로잡을 수도 있다. 그러한 상황에서 누군가 이력서 주도 개발(resume driven development)을 시작하면, 기술 선택은 매우 색다른 국면으로 접어들게 된다.

‘빅데이터 프로젝트’나 ‘대용량 트래픽 처리’ 같은 멋진 키워드는 매력적인 커리어를 쌓고 싶은 사람이라면 그냥 지나칠 수 없는 강렬한 유혹과 같다. 문제는 그러한 키워드가 어울리는 프로젝트가 생각처럼 많지 않다는 점이다. ‘빅데이터’나 ‘대용량 트래픽’은 어디까지나 상대적으로 해석되는 용어로, 대부분의 프로젝트는 해당 용어에 어울리지 않는 규모에 그친다.

<Fundamentals of Data Engineering(견고한 데이터 엔지니어링)>의 1.2.1절에서는 데이터 성숙도와 데이터 엔지니어에 관해 살펴보고, 본인이 속한 조직의 데이터 성숙도에 따라 어떤 작업을 수행해야 하는지를 간략히 소개한다. 

예를 들어 데이터 팀이 처음 만들어진 경우라면 해당 절에서 소개하는 ‘1단계: 데이터로 시작하기’ 관련 사항들을 먼저 수행해야 한다. 즉, 데이터 조직이 그 자체로 계속 인정받고 유지될 수 있도록 데이터 조직이 기여할 수 있는 업무를 찾아내고 기초를 세워나가야 한다.

데이터 조직에 기대하는 경영진의 흔한 착각 중 하나가 “데이터로 뭔가 멋있는 것을 바로 만들어서 보여주겠지?”와 같은 것이라면, 기술 실무자의 착각은 “잘 나가는 오픈 소스를 도입해서 멋진 이력서를 만들어볼 수 있겠지?”일 것이다. 

하지만 ‘데이터로 시작하는’ 단계에서 하둡이나 스파크 같은 매력적인 키워드보다 더 필요한 것은 다양한 실무 팀에서 실제로 필요로 하는 데이터 작업이 있는지, 그리고 주기적으로 발생할 수 있는 업무는 무엇인지를 확인하는 것이다. 

그다음 스텝은 장기적으로 팀 또는 조직에 기여할 수 있는 방안을 고민하는 것이다(보통은DW를 구축하는 일이 이에 해당한다).

실제로 나 역시 상대적으로 넉넉한 용량의 RDBMS와 cron job으로 충분히 해결할 수 있는 작업들을 ‘굳이’ 하둡으로 구현하는 바람에 해당 프로젝트가 많은 위기를 겪는 과정을 지켜본 경험이 있다. 

레거시 기술을 쓰면 해당 프로젝트는 실패라고 규정짓는 듯한 분위기 속에서 프로젝트는 상상 이상으로 많은 시간을 소요하며 진행되었고, 결국 서비스 오픈 후 수많은 장애를 겪고 나서야 구현 가능한 레거시 기술로 회귀하면서 사태가 마무리될 수 있었다

고품질로 이어지는 ‘데이터 책임’의 중요성

현장에서 문제가 발생하기 전까지는 꼭 필요할까 싶지만, 결국 문제가 터지면 찾게 되는 존재가 바로 ‘책임자’다. 그런 의미에서 <견고한 데이터 엔지니어링>의 2.2.2절에서 다루는 ‘데이터 책임’은 짧은 구절이지만 매우 중요한 항목이기도 하다.

데이터 관련 작업은 여러 명이 함께 수행할 때도 있고 1~2명의 소수 팀원이 수행할 때도 있다. 어느 쪽도 정답이라고 단언할 수는 없지만, 중요한 것은 협업하는 과정에서 발생하는 ‘소통’과 ‘책임’이다. 근래 수년간 인기를 끌고 있는 오케스트레이션 도구인 에어플로는 이러한 데이터 책임의 중요성을 일깨워준 사례라고 할 수 있다.

데이터 프로젝트 초기에 데이터를 여기저기서 수집하다 보면 그만큼 에어플로의 DAG이 점점 늘어난다. 여러 명이 함께 작업하면 그만큼 작업 스타일(coding convention)이 다양해지는데, 그러한 과정에서 많은 문제가 발생한다. 

나 역시 이러한 상황에 맞닥뜨린 적이 한두 번이 아니었다. DAG에서 공통으로 사용하는 값들을 잘못 설정하는 바람에 엉뚱한 목적지에 데이터가 쌓일 때도 있었고, 누군가의 DB 패스워드 변경으로 인해 DAG가 계속 실패하는 것을 며칠간 방치했던 때도 있었다.

그러한 문제를 어째서 빨리 처리하지 않았는지 궁금할 것이다. 하지만 누구나 DAG을 만질 수 있고, 누구나 DB에 접속할 수 있는 상황에서 책임 관계는 애매했고 작업 이력(history) 역시 묘연했다. 결국 데이터 관련 작업의 전체적인 정책을 결정하고 프로젝트를 이끌어줄 담당 리더를 뽑은 뒤, 하나씩 체계를 정립해나감으로써 문제를 해결할 수 있었다.

흥미롭고 경쟁력 있는 기술로 이력서를 채우는 일에 민감한 엔지니어에게 ‘데이터 책임자’라는 용어는 다소 지루하게 들릴 수도 있지만, 그 책임은 매우 크며 프로젝트의 많은 부분을 살필 수 있는 능력이 요구된다. 

흔히 애자일이라고 생각하는 ‘빠르게 작업하고 빠르게 반영하는’ 스타일 대신 반 박자 정도 템포를 늦추고, 정책적으로 설정한 스타일에 맞춰 작업물을 생성하며, 테스트를 통해 신중하게 반영하는 기조가 자리 잡게 된 것도 데이터 책임자를 뽑은 뒤부터였다.

‘데이터 책임’을 인지하고 그 담당자를 정하는 행위는 왠지 레거시 문화처럼 보이고 작업 속도를 늦추는 것 같지만, 시간이 흐르면서 누적되는 데이터 품질과 그러한 데이터로 파생되는 여러 가지 결과물은 결국 ‘데이터 책임’ 유무에 달려 있다는 것을 현장에서의 경험을 통해 비로소 깨달을 수 있었다.

잘못된 관행에 따른 데이터 처리 문제

데이터 조직 또는 데이터 프로젝트는 경영진(또는 팀장급)에게 상대적으로 많은 주목을 받기 마련이다. 데이터는 곧 해당 기업의 실체이자 민낯인 만큼, 대부분 설레는 마음(또는 지금까지 겪어본 적 없는 걱정)으로 데이터 결과물을 기다린다. 하지만 실제로 기대에 부응하는 고품질의 결과물을 얻으려면 먼저 ‘데이터 사일로 허물기’부터 시작해야 한다.

데이터 사일로는 데이터 기반 조직이 아직 존재하지 않거나 데이터 기반 사업을 해본 적 없는 조직에서 흔히 발생하는 현상의 하나다. 데이터로 업무를 시작하는 첫 번째 단계가 ‘전사의 모든 데이터를 한데 모아’ 해당 조직의 현재 상태를 파악하는 것이기에, 데이터 사일로만큼 조직의 데이터 성숙도를 파악하기에 좋은 지표도 없다.

이러한 데이터 사일로를 허물고 새로운 데이터 체계를 갖추는 과정에서 수많은 데이터 장애를 경험할 수 있는데, 그중 하나가 ‘정확하지 않은 데이터 문제’다. 이러한 문제는 각 부서에서 데이터를 집계하는 특유의 방식에서 비롯되는데, 예를 들면 다음과 같다.

● 해당 업무를 몇몇 특정 인원이 오랜 기간 전담했다. 담당자가 항상 알아서 해왔기에 굳이 다른 사람이 건드리지 않았고, 실제로 대체할 사람도 없었다.

● 집계할 때마다 담당 임원의 요청으로 특정 조건이 계속 발생했는데, 그 조건이 일정하지 않았다.

● 임원보고 때마다 매출을 당겨 집계했기에, 실제 원시 데이터(raw data)를 맞춰보면 전부 결과가 달랐다.

● 10분기째 매출이 하락하는 가운데, OO 부문 임원의 요청에 따라 매출 데이터를 살짝 반등하는 방향으로 수정했다.

이러한 상황은 (믿기지 않겠지만) 실제로 꽤 다양한 현장에서 발생하는데, 대부분 그냥 지나치고 만다. 데이터 사일로는 곧 소통의 부재인 만큼, 데이터 처리에 대한 공통된 이해가 전제되지 않으면 이러한 상황은 계속해 반복될 수밖에 없다. 

문제는 데이터 전담 조직이 기존 데이터를 긁어모아 그동안의 누적 데이터를 데이터 웨어하우스에 쌓고 시각화하는 과정에서, 기존 데이터와는 매우 이질적인 데이터를 마주하게 된다는 점이다.

기존 관행에 문제가 있었음을 솔직히 인지하고 새로운 데이터 처리 방식을 지지한다면 문제를 해결할 수 있겠지만, 기존 이해관계자와의 충돌이 잦고 데이터 결과물을 부정한다면 이러한 문제의 실타래를 푸는 데만 매우 많은 시간을 소모할 것이다.

이 글은 <견고한 데이터 엔지니어링> 도서 내용 일부를 발췌 편집하여 작성되었습니다. 실용적인 데이터 엔지니어링의 A부터 Z까지, 이에 대한 보다 자세한 내용은 하기 링크에서 살펴보실 수 있습니다. 

 『견고한 데이터 엔지니어링』