[책] 견고한 데이터 엔지니어링

견고한 데이터 엔지니어링

 

한빛미디어에서 번역서로 발간된 "견고한 데이터 엔지니어링"은 흥미로운 내용을 잔뜩 담고 있습니다. 책의 표지만 봤을 때는 데이터 엔지니어 커리어를 쌓으려는 사람들을 위한 것처럼 보이는데요. 물론 이 책의 내용 중심에는 데이터 엔지니어링이 있지만 데브옵스(데이터옵스와 비교되는)와 모놀리스와 마이크로서비스 인프라 아키텍처 내용도 품고 있습니다. 

데이터 파이프라인을 구축할 때 자주 사용되는 메시지 큐와 데이터 스트리밍 플랫폼(카프카 같은)에 대한 설명도 잘 되어 있습니다. 그리고 OLTP(Online Transactional Processing), OLAP(Online Analytical Processing) 데이터베이스 이야기, 데이터웨어하우스, 데이터 레이크, 레이크 하우스 등 다양한 용어의 설명과 트렌드가 소개됩니다. 뿐만 아니라 우리가 데이터 아키텍처를 설계할 때 명심해야 하는 것들도 책에서 다루고 있습니다. 이건 비단 데이터 아키텍처뿐만 아니라 일반적인 서비스 아키텍처를 설계할 때도 두루 알고 있어야 하는 내용일 겁니다. 중요한 내용 몇 개를 발췌했습니다. 아래를 봐주세요

 

빅데이터는 10대의 섹스와 같다. 모두가 그것에 관해 이야기하지만, 실제로 어떻게 하는지 아는 사람은 아무도 없다. 하지만 다른 모든 사람이 그것을 하고 있다고 생각하기 때문에, 자신도 그것을 한다고 주장한다.

 

한때 빅데이터라는 용어 자체가 아주 핫했던 적이 있습니다. 한국에서는 대충 2015년쯤부터 사용된 것 같습니다. 빅데이터 엔지니어라는 포지션을 채용하는 회사들이 있었고 콘퍼런스장에는 빅데이터를 다루는 기술을 설명하는 곳이 많았습니다. 그리고 시간이 얼마 지나지 않아 대다수 회사들이 (일단 데이터만 있으면) 빅데이터를 다룬다고 이야기하기 시작했습니다. 빅데이터의 정의/기준이 모호한 것도 있었지만 어쩌면 대용량 데이터를 다루는 파이프라인이 더 중요한 시기였기에 모두가 빅데이터를 하고 있다고 이야기해도 다들 끄덕이지 않았나 생각해 봅니다.

 

데이터 엔지니어는 보안을 최우선으로 생각해야 하며, 이를 무시하는 사람은 위험을 감수해야 한다. 보안이 드러나지 않는 요소의 첫 번째 요소인 이유다. 데이터 엔지니어는 데이터와 접근 보안을 모두 이해하고 최소 권한 원칙(principle of least privilege)을 실행해야 한다. 최소 권한 원칙이란 사용자 또는 시스템이 의도된 기능을 수행하는 데 필수적인 데이터와 자원에만 접근할 수 있는 것을 의미한다. 보안 경험이 적은 데이터 앤지니어의 일반적인 안티 패턴은 모든 사용자에게 관리자 권한을 부여하는 것이다. 이는 대재앙으로 이어지는 행위다.

 

보안은 언제나 최우선입니다. 특히 데이터를 다루는 엔지니어라면 권한 관리는 필수입니다. 간혹 권한 때문에 데이터가 흐르는데 방해가 된다며 많은 권한을 부여하는 상황들을 접했는데요. 이건 아주 위험한 신호입니다. 데이터베이스 권한뿐만 아니라 인프라 전반에 걸쳐 권한 관리는 아주 중요한 요소이니 항상 신경 쓰도록 해야 합니다.

 

한 팀이 다른 팀에 의존하지 않고도 시스템을 테스트, 배포, 변경할 수 있도록 시스템 아키텍처가 설계되면, 해당 팀은 작업을 수행할 때 의사소통이 거의 필요하지 않다. 즉, 아키텍처와 팀 모두 느슨하게 결합되어 있다.

 

이 내용은 "구글 데브옵스 기술 아키텍처 가이드"에서 인용된 문장입니다. 물론 모든 상황에서 철저히 분리하는 것은 어려울 수 있지만 아키텍처 전반의 기조를 느슨한 결합으로 가져간다면 불필요한 의사소통을 아주 많이 줄일 수 있을 겁니다.

 

새로운 목표 선정 신드롬 때문에 지나치게 흥분하는 팀들이 있다. 그들은 최신 기술 유행이 프로젝트의 가치에 어떤 영향을 미칠지 이해하지 못한 채 그저 위대한 유행을 따라가야 한다는 강박관념이 사로잡힌다. 또한 프로젝트의 궁극적인 목표에는 우선순위를 두지 않고 인상적인 신기술을 축척해 이력서 주도 개발(resume-driven development)을 하려는 유혹도 있다. 항상 뭔가 멋진 것을 구축하려 하기보다는 작업 요건을 우선시하자

 

중요한 키워드가 나왔습니다. 우리는 서비스를 성공시키는 비즈니스를 개발하기 위해 모였다는 목적을 잊으면 안 되는데요. "이력서 주도 개발"에 빠지면 안 됩니다. 간혹 비즈니스 성공 여부와 무관하게 신기술로 무장한 거창한 아키텍처를 추구하는 사람들이 있는데 조심해야 합니다.

 

종종 소규모 데이터 팀이 대기업의 새로운 최첨단 기술에 관한 블로그 포스팅을 읽고, 그 포스팅의 내용과 같은 매우 복잡한 기술과 사례를 모방하려 시도하는 경우가 있다. 이를 가리켜 카고-컬트-엔지니어링(cargo-cult-engineering)이라 부르는데, 일반적으로 귀중한 시간과 비용을 많이 소비하지만 그 대가로 얻을 만한 것은 거의 없는 큰 실수라 할 수 있다.

 

위에서 살펴본 내용과 비슷한 맥락입니다. 각자 비즈니스에 맞는 기술이 있고 아키텍처가 있는 법인데 무조건 최첨단 기술을 도입하기 위해 시간을 허비하는 걸 피하도록 해야 합니다. 

이 책은 여러 가지 의미로 흥미롭습니다. 데이터 엔지니어와 데이터 엔지니어링을 정의하고 역할 범위를 이야기하는 건 물론이고 데이터 아키텍처를 설명하기 위해 소프트웨어 아키텍처를 다룰 때 나올법한(혹은 이미 널리 사용된) 문장들이 대거 등장합니다. 위에서 언급한 문장들이 이 책에서 처음 표현된 건 아닙니다. 어쩌면 많은 사람들이 이미 어딘가에서 접했던 문장들일 겁니다. 그런 만큼 이 책은 데이터 엔지니어만을 위한 책이 아닙니다(물론 데이터 엔지니어가 보면 더욱 좋습니다). 소프트웨어 엔지니어로 커리어를 잡은 사람이라도 다른 직군을 이해하기 위해서 혹은 소프트웨어 아키텍처를 정리하기 위해 읽어도 아주 좋을 겁니다. 마지막으로 마크 리처즈, 닐 포드의 Fundamentals of Software Architecture에서 인용된 다음 문장을 첨부하며 리뷰를 마칩니다. 이 문장도 책에 실려있습니다. 이 책을 많은 사람들이 일독하기를 바랍니다.

최고의 아키텍처를 추구하기보다는 덜 나쁜 아키텍처를 추구하라.

 

 

---

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.