본문 바로가기
기술 도서 리뷰

견고한 데이터 엔지니어링 Chapter 2.2 - 데이터 엔지니어링 수명주기

by Seungyoon1786 2024. 9. 30.

이 글은 스터디 활동에서 진행하는 견고한 데이터 엔지니어링 정리입니다.

 

Fundamentals of Data Engineering

Data engineering has grown rapidly in the past decade, leaving many software engineers, data scientists, and analysts looking for a comprehensive view of this practice. With this practical book, you'll … - Selection from Fundamentals of Data Engineering

www.oreilly.com


2.2 데이터 엔지니어링 수명 주기의 드러나지 않는 요소

 

데이터 엔지니어링은 단순히 기술적인 문제를 해결하는 것을 넘어서, 데이터 관리, 비용 최적화, DataOps와 같은 기업 환경에서의 운영 효율성을 높이는 방향으로 발전하고 있다. 과거의 데이터 엔지니어링은 주로 특정 기술 스택에 대한 집중적인 관리와 운영에 초점이 맞춰져 있었다. 그러나 현재의 데이터 엔지니어링은 다양한 도구와 기술을 추상화하고 단순화하여, 보다 포괄적인 전략을 구축하는 방향으로 변화하고 있다.

 

이러한 변화는 단지 기술적인 발전에 그치지 않고, 기업 전반의 비즈니스 프로세스가치 창출에도 큰 영향을 미친다. 데이터 엔지니어링은 데이터 관리, 보안, DataOps, 데이터 아키텍처, 오케스트레이션 등 다양한 요소들이 결합된 드러나지 않는 요소(undercurrent)를 통해, 데이터의 수명 주기를 관리하고 최적화하는 것이 중요해졌다.

2.2.1 보안

보안은 데이터 엔지니어에게 가장 중요한 우선순위여야 하며, 이를 무시하는 것은 큰 위험을 초래할 수 있다. 데이터 보안의 기본 원칙 중 하나는 최소 권한의 원칙이다. 이 원칙은 사용자나 시스템이 그들이 수행해야 할 작업에 필요한 최소한의 데이터와 리소스에만 접근할 수 있도록 허용하는 것이다. 많은 데이터 엔지니어들이 보안 경험이 부족할 때, 흔히 저지르는 실수는 모든 사용자에게 관리자 권한을 부여하는 것인데, 이는 큰 보안 위험을 초래할 수 있다.

 

데이터 엔지니어는 사용자에게 필요한 액세스 권한만 제공하고, 그 이상은 허용하지 않아야 한다. 예를 들어, 단순한 작업을 수행할 때는 루트 권한이나 슈퍼유저 권한을 사용하는 대신, 작업에 필요한 최소한의 권한만 부여하는 것이 중요하다. 이를 통해 우발적인 데이터 손상을 방지하고, 보안 우선 사고방식을 유지할 수 있다.

 

보안 취약점은 주로 사람과 조직 구조에서 비롯된다. 많은 보안 침해 사례에서 보안 사고는 직원이 기본적인 예방 조치를 무시하거나 피싱 공격에 당하는 등 인적 오류에서 발생한다. 따라서, 보안 문화를 조직에 스며들게 하여 모든 사람이 데이터 보안에 대한 책임을 인식하게 만드는 것이 중요하다.

 

데이터 보안은 적시성도 중요한 요소다. 작업을 수행하는 동안에만 데이터에 접근할 수 있도록 하고, 암호화, 토큰화, 데이터 마스킹 등의 기술을 사용하여 전송 중이든 저장 중이든 데이터를 보호하는 것이 필요하다.데이터 엔지니어는 보안 관리자로서의 역량을 갖춰야 한다. 클라우드온프레미스 환경 모두에서 보안 모범 사례를 이해하고, 사용자 및 ID 액세스 관리(IAM), 네트워크 보안, 암호 정책 등에 대한 깊은 지식이 필요하다.

2.2.2 데이터 관리

데이터 관리는 오랜 역사를 가지고 있지만, 최근 데이터 엔지니어링 분야에서 그 중요성이 다시 부각되고 있다. 한때 대기업에만 적용되던 데이터 거버넌스, 마스터 데이터 관리, 데이터 품질 관리, 메타데이터 관리 등의 모범 사례가 이제는 모든 규모의 기업으로 확산되고 있으며, 이는 데이터 엔지니어링이 더 기업적으로 진화하고 있음을 보여준다. 이러한 변화는 결국 데이터 관리가 조직 전반에 걸쳐 데이터 자산을 효율적으로 관리하는 중요한 요소로 자리잡게 만들고 있다.

데이터 관리란 데이터 및 정보 자산의 가치를 수명 주기 전반에 걸쳐 전달, 제어, 보호하고 향상시키기 위한 계획, 정책, 프로그램 및 관행을 개발, 실행 및 감독하는 것입니다. - DMBOK

 

데이터 관리 협회 국제(DAMA)데이터 관리를 데이터 자산의 가치를 극대화하고 보호하기 위해 수명 주기 전반에 걸쳐 계획, 정책, 프로그램을 실행하고 감독하는 것으로 정의한다. 이 정의는 다소 길지만, 데이터 관리가 데이터 엔지니어링의 필수적인 부분임을 설명해 준다. 데이터 엔지니어는 데이터를 단순히 처리하는 것에 그치지 않고, 데이터 라이프사이클을 전체적으로 관리하며, 기업 내 데이터의 유용성을 극대화해야 한다.

 

과거에는 데이터 관리가 기술적인 작업에만 그쳤을 수 있지만, 이제는 데이터 엔지니어가 조직의 가치 사슬에서 한 단계 더 나아가 전략적인 책임도 함께 짊어지고 있다. 이로 인해, 기업들은 데이터를 자산으로 바라보고, 이를 적절히 관리하는 프레임워크를 구축함으로써 더 많은 가치를 창출할 수 있다.

 

데이터 관리의 주요 요소는 데이터 거버넌스, 데이터 모델링, 데이터 계보, 데이터 통합, 데이터 수명 주기 관리, 고급 분석 및 ML 시스템, 윤리와 개인정보보호 등을 포함한다. 이 책에서는 이러한 데이터 관리의 각 측면을 간략하게 다루며, 데이터 엔지니어링에서 어떻게 적용될 수 있는지 설명하고 있다.

 

데이터 엔지니어는 기술적인 작업뿐만 아니라 데이터 관리의 모범 사례를 활용해 기업 내 데이터를 조직적으로 관리해야 하며, 이를 통해 데이터가 비즈니스 전반에 걸쳐 필수 자산으로 자리잡을 수 있도록 기여해야 한다. 데이터 엔지니어링이 기업적이 되는 것은 긍정적인 변화이며, 이는 데이터의 가치를 극대화할 수 있는 새로운 기회를 제공한다.

데이터 거버넌스

데이터 거버넌스는 조직에서 수집한 데이터의 품질, 무결성, 보안, 사용성을 보장하기 위한 중요한 데이터 관리 기능이다. 이를 단순히 데이터 관리로만 국한할 수 없으며, 사람, 프로세스, 기술을 모두 포함하는 전략적인 접근이 필요하다. 효과적인 데이터 거버넌스는 조직 전체의 지원을 받아야 하며, 의도적이고 체계적으로 실행될 때 비로소 데이터의 가치를 극대화할 수 있다.

 

데이터 거버넌스가 부실하게 이루어지면 신뢰할 수 없는 데이터, 보안 침해, 그리고 잘못된 비즈니스 의사결정과 같은 심각한 문제가 발생할 수 있다. 예를 들어, 비즈니스 분석가가 적절한 데이터를 찾지 못해 잘못된 보고서를 작성하고, 그 보고서가 기반한 데이터의 신뢰성이 의심을 받는 상황을 상상해보자. 이러한 상황은 조직 내 데이터에 대한 불신을 낳고, 나아가 비즈니스 계획에 혼란을 초래하게 된다.

 

반면, 효과적인 데이터 거버넌스는 조직 내 모든 데이터 프로세스를 데이터 중심의 비즈니스 관행으로 정렬하여, 데이터 문제가 발생하면 즉각적으로 처리될 수 있는 환경을 구축한다. 이를 통해 데이터는 핵심 비즈니스 동인으로서 제 기능을 다하게 된다.

 

데이터 거버넌스의 핵심 범주로는 발견 가능성, 보안, 책임성이 있다. 이러한 범주 안에는 데이터 품질, 메타데이터 관리, 개인정보 보호와 같은 중요한 하위 범주가 포함된다. 데이터 거버넌스는 데이터 엔지니어링 라이프사이클의 중요한 부분으로, 의도적이고 체계적인 거버넌스 시스템을 통해 조직이 데이터에서 최대의 가치를 창출하고 비즈니스 의사결정을 신뢰할 수 있게 만들어야 한다.

 

발견 가능성

데이터 중심 기업에서 데이터는 사용 가능하고 발견 가능해야 하며, 최종 사용자는 필요한 데이터를 신속하게 액세스하고, 데이터의 출처, 연관성, 의미를 이해할 수 있어야 한다. 데이터 발견 가능성의 핵심 영역에는 메타데이터 관리마스터 데이터 관리가 포함된다.

 

메타데이터

메타데이터는 "데이터에 대한 데이터"로, 데이터 엔지니어링 라이프사이클의 모든 단계를 지원한다. 메타데이터는 데이터를 찾고, 이해하고, 관리할 수 있게 해주며, 주로 자동 생성된 메타데이터인간이 생성한 메타데이터로 나뉜다.

메타데이터 관리를 자동화하는 도구들이 많이 등장했으며, 이는 데이터베이스를 크롤링하고 데이터 파이프라인을 모니터링하여 데이터의 출처와 흐름을 추적할 수 있게 한다. 하지만 메타데이터 수집에서 인간의 역할도 여전히 중요하다. 메타데이터는 단순한 기술적 데이터뿐만 아니라 조직 내 사회적 자본프로세스의 집합으로서, 데이터에 대한 조직 내 지식을 체계화하는 데 기여한다.

 

메타데이터는 비즈니스 메타데이터, 기술 메타데이터, 운영 메타데이터, 참조 메타데이터로 나눌 수 있다.

  1. 비즈니스(business) 메타데이터: 비즈니스에서 데이터가 어떻게 사용되는지 설명하며, 데이터 정의, 데이터 규칙, 데이터 소유자 등을 포함한다. 데이터 엔지니어는 이를 통해 비기술적인 질문에 답할 수 있다.
  2. 기술(technical) 메타데이터: 데이터의 구조와 흐름에 대한 정보를 제공한다. 여기에는 데이터 모델, 스키마, 파이프라인 메타데이터 등이 포함된다. 기술 메타데이터는 데이터가 어디서 오고 어떻게 변환되는지를 추적하는 데 필수적이다.
  3. 운영(operational) 메타데이터: 시스템의 운영 결과를 설명하며, 작업 로그, 에러 로그, 프로세스 통계 등을 포함한다. 데이터 엔지니어는 이를 통해 프로세스의 성공 여부를 확인하고 문제를 해결할 수 있다.
  4. 참조(reference) 메타데이터: 다른 데이터를 분류하는 데 사용되는 데이터로, 예를 들어 코드 표준, 측정 단위, 지리적 코드 등을 포함한다. 참조 메타데이터는 데이터를 해석하는 데 필요한 기준을 제공한다.

메타데이터는 데이터 엔지니어가 데이터 파이프라인을 설계하고 데이터를 효율적으로 관리하는 데 필요한 기초를 제공하며, 이는 데이터 엔지니어링 전반에서 중요한 역할을 한다.

 

데이터 책임성

데이터 책임성은 특정 데이터를 관리할 개인을 지정하는 것을 의미한다. 이 책임자는 해당 데이터와 관련된 거버넌스 활동을 조정하며, 데이터의 품질과 일관성을 유지하기 위한 중요한 역할을 담당한다. 만약 데이터에 대한 책임자가 없다면, 데이터 품질을 유지하고 관리하는 것이 어렵기 때문에 책임자를 명확히 정하는 것이 필수적이다.

 

데이터 책임자는 반드시 데이터 엔지니어일 필요는 없으며, 소프트웨어 엔지니어, 제품 관리자, 또는 다른 역할을 맡는 사람일 수 있다. 중요한 것은 이 책임자가 데이터 엔지니어, 개발자, 또는 비즈니스 분석가데이터와 상호작용하는 모든 사람과 협력해야 한다는 점이다. 즉, 데이터를 다루는 여러 이해관계자들이 함께 협력해 데이터의 품질을 유지하고 관리한다.

 

데이터 품질

데이터 품질은 데이터를 신뢰할 수 있는지에 대한 중요한 질문을 중심으로 한다. 데이터가 비즈니스 기대치에 부합하는지 확인하는 과정은 필수적이며, 이 과정은 데이터를 사용하는 모든 사람에게 영향을 미친다. 데이터 품질을 관리하는 데 있어 중요한 질문은 "이 데이터가 내가 기대한 것과 일치하는가?"이다. 이는 비즈니스 메타데이터와 비교하여 데이터가 올바르게 수집되고 사용되는지를 평가하는 것이다.

 

데이터 엔지니어는 데이터 수명 주기 전반에 걸쳐 데이터 품질을 테스트하고, 스키마 기대치에 맞게 데이터가 완전성, 정밀도, 그리고 적합성을 유지하는지 확인해야 한다.

 

에브렌 에리우렉의 저서에 따르면 데이터 품질은 다음의 세 가지 주요 특성으로 정의된다:

  1. 정확성: 수집된 데이터가 사실적으로 정확한가? 중복된 값이 존재하는가? 숫자 값이 정확한가?
  2. 완전성: 데이터가 완전한가? 모든 필수 필드에 유효한 값이 포함되어 있는가?
  3. 적시성: 데이터를 적절한 시기에 사용할 수 있는가?

각 특성은 데이터의 신뢰성을 보장하는 데 중요한 역할을 한다. 예를 들어, 웹 이벤트 데이터를 처리할 때, 봇과 웹 스크래퍼가 발생시키는 트래픽을 어떻게 다룰 것인가가 데이터 정확성에 직접적으로 영향을 미칠 수 있다. 봇이 인간으로 잘못 분류되면 데이터 정확성 문제가 발생하며, 그 반대의 경우도 마찬가지다.

 

완전성적시성에 대한 문제는 실질적인 비즈니스 상황에서 더욱 복잡해질 수 있다. 예를 들어, Google의 데이터 흐름 모델에 따르면, 광고가 오프라인 플랫폼에서 사용된 후 그 데이터를 나중에 업로드하는 상황에서는 데이터가 지연되면서 수집되기 때문에 이를 어떻게 처리할지에 대한 표준이 필요하다.결국, 데이터 품질 문제는 단순한 기술적 문제가 아니라, 엔지니어들이 표준을 설정하고 이를 일관되게 적용해야 하는 중요한 의사결정 문제로 볼 수 있다.

 

데이터 품질은 단순히 기술적인 문제가 아니라 인간과 기술의 경계를 넘나드는 중요한 요소다. 데이터 엔지니어는 데이터를 사용하는 사람들의 피드백을 수집하고, 이를 토대로 품질을 개선할 수 있는 프로세스를 구축해야 한다.

 

마스터 데이터 관리
마스터 데이터 관리(MDM)는조직의 직원, 고객, 제품, 위치와 같은 주요 비즈니스 엔터티에 대한 데이터를 일관되게 관리하는 방법이다. 조직이 성장하거나 인수를 통해 복잡해질수록 이러한 엔터티와 아이덴티티에 대한 통일된 그림을 유지하는 것이 점점 어려워지고 있다.

MDM은 골든 레코드라는 일관된 엔터티 정의를 구축하여, 조직 내부와 외부 파트너 간에 데이터를 조화시키는 과정이다. 이를 위해 비즈니스 운영 프로세스와 함께 기술 도구를 구축하고 배포한다. 예를 들어, MDM 팀은 주소 형식을 표준화하고, 이를 바탕으로 데이터 엔지니어와 협력하여 모든 부서에서 일관된 주소 데이터를 사용할 수 있는 시스템을 구축할 수 있다.

MDM은 전체 데이터 사이클에 걸쳐 운영되며, 데이터 엔지니어가 직접 관리할 수 있지만, 대부분은 전담 팀이 이를 책임진다. 데이터 엔지니어는 MDM에 참여하거나 이를 지원할 수 있으며, MDM 이니셔티브에 대해 항상 알고 있어야 한다.

데이터 모델링 및 설계

데이터에서 비즈니스 통찰력을 얻으려면, 비즈니스 분석데이터 과학을 통해 데이터를 사용 가능한 형태로 변환하는 과정이 필수적이다. 이 변환 과정은 데이터 모델링디자인이라고 하며, 전통적으로 데이터베이스 관리자(DBA)나 ETL 개발자가 담당했지만, 실제로는 조직의 거의 모든 곳에서 발생할 수 있다. 예를 들어, 펌웨어 엔지니어가 IoT 장치의 데이터 형식을 설계하거나, 웹 애플리케이션 개발자가 API 호출이나 MySQL 테이블 스키마에 대한 JSON 응답을 디자인하는 것도 데이터 모델링의 한 형태다.

 

데이터 모델링은 새롭게 등장하는 다양한 데이터 소스와 사용 사례로 인해 점점 더 복잡해지고 있다. 예를 들어, 엄격하게 정규화된 데이터 모델이벤트 데이터와 잘 맞지 않을 수 있다. 다행히도, 새로운 세대의 데이터 도구는 측정, 차원, 속성, 계층 등을 논리적으로 분리하면서도 데이터 모델의 유연성을 보장한다. 클라우드 데이터 웨어하우스Kimball, Inmon, Data Vault와 같은 전통적인 데이터 모델링 패턴을 여전히 지원하며, 동시에 비정규화된 데이터반구조화된 데이터도 효과적으로 수집할 수 있다. Spark와 같은 데이터 처리 프레임워크는 플랫 구조화된 관계형 데이터부터 비정형 텍스트에 이르는 다양한 데이터를 처리할 수 있다.

 

데이터 모델링이 점점 복잡해짐에 따라, 이를 포기하고 싶은 유혹이 들 수 있지만, 이는 잘못된 생각이다. 데이터 엔지니어는 모델링 모범 사례를 이해하고, 다양한 데이터 소스와 사용 사례에 맞는 적절한 데이터 모델링을 적용할 수 있는 유연성을 키워야 한다. 모델링을 포기하면, 이는 곧 한 번 쓰고 다시는 읽지 않는(WORN) 데이터 패턴을 만들거나 데이터 늪을 조성하게 되어, 데이터 활용도가 현저히 떨어질 수 있다.

데이터 계보

데이터 계보는 데이터가 수명 주기를 거치면서 어떤 시스템이 데이터에 영향을 미쳤는지, 데이터가 변환되거나 전달될 때 어떤 모습으로 구성되었는지를 추적하는 방식이다. 이를 통해 데이터가 어떤 경로를 따라 이동했는지, 그리고 어떤 시스템과 업스트림 데이터에 의존하는지를 명확하게 파악할 수 있다.

 

데이터 계보는 오류 추적, 책임성 확보, 디버깅에 필수적이며, 데이터 수명 주기 전반에 걸친 감사 추적을 제공하여 규정 준수를 도와준다. 예를 들어, 사용자가 시스템에서 특정 데이터를 삭제하고 싶어 할 때, 데이터 계보는 그 데이터가 어디에 저장되어 있는지, 어떤 종속성을 갖고 있는지 확인할 수 있도록 돕는다.

 

이러한 데이터 계보는 원래 엄격한 규정 준수 기준이 필요한 대기업에서 주로 사용되었지만, 이제는 데이터 관리가 더 널리 확산되면서 소규모 기업에서도 점점 채택되고 있다. 또한 Andy Petrella데이터 관찰성 주도 개발(DODD) 개념도 데이터 계보와 밀접한 관련이 있다. DODD는 데이터 계보를 바탕으로 데이터를 관찰하고, 개발, 테스트, 생산 과정에서 데이터를 추적하여 품질적합성을 보장한다.

데이터 통합과 상호 운용성

데이터 통합상호 운용성은 다양한 도구와 프로세스를 통해 데이터를 연결하는 과정이다. 과거에는 단일 스택 접근 방식으로 분석을 수행했지만, 오늘날에는 다양한 클라우드 환경에서 여러 도구가 데이터를 처리한다. 이로 인해 통합과 상호 운용성은 데이터 엔지니어의 주요 업무 중 하나로 자리 잡고 있다.

 

점차적으로, 통합은 사용자 정의 데이터베이스 연결 대신 범용 API를 사용하여 이루어진다. 예를 들어, 데이터 파이프라인은 Salesforce API에서 데이터를 가져와 Amazon S3에 저장하고, Snowflake API를 통해 테이블에 데이터를 로드하며, API를 다시 호출하여 쿼리를 실행하고 그 결과를 Spark에서 사용할 수 있도록 S3로 내보낼 수 있다.

 

이 모든 작업은 데이터를 직접 처리하는 대신, 데이터 시스템과 통신하는 간단한 Python 코드로 관리할 수 있다. 데이터 시스템과 상호작용하는 복잡성은 줄어들었지만, 시스템의 수파이프라인의 복잡성은 크게 증가했다. 처음에는 맞춤형 스크립트로 작업을 시작하는 엔지니어들도 시간이 지나면서 오케스트레이션의 필요성을 절실히 느끼게 된다.

데이터 수명 관리

데이터 레이크의 도입으로 조직은 데이터 보관 및 파기에 대한 관심을 줄이게 되었지만, 두 가지 변화로 인해 데이터 엔지니어들은 데이터 라이프사이클의 마지막 단계에 더욱 주의를 기울이게 되었음. 첫째, 클라우드 스토리지로의 전환으로 사용량에 따라 비용을 지불하게 되면서 CFO들이 비용 절감의 필요성을 인식하게 되었음. 클라우드 환경에서 데이터 보관은 비교적 간단하며, 주요 클라우드 제공업체들은 저렴한 장기 보관 옵션을 제공하고 있음.

 

둘째, GDPR과 CCPA 같은 개인정보 보호법의 등장으로 데이터 엔지니어들은 사용자의 데이터를 삭제할 수 있는 절차를 마련해야 함. 클라우드 데이터 웨어하우스에서는 SQL을 이용해 데이터를 쉽게 삭제할 수 있지만, 데이터 레이크에서는 Hive ACID나 Delta Lake 같은 도구를 사용해 더 복잡한 삭제 트랜잭션을 처리해야 한다.

윤리와 개인 정보

윤리와 개인정보보호는 데이터 엔지니어링에서 매우 중요한 요소이다. 최근 몇 년 동안 발생한 데이터 침해 사건들과 잘못된 데이터 처리로 인해 데이터가 사람들에게 직접적인 영향을 미친다는 점이 더욱 분명해졌다. 과거에는 데이터가 자유롭게 거래되고 수집되던 시절이 있었지만, 이제는 윤리적 기준과 개인정보보호가 데이터 수명 주기의 핵심으로 자리 잡았다. 데이터 엔지니어는 아무도 지켜보지 않을 때에도 올바른 결정을 내려야 하며, 이는 언젠가 모두가 지켜볼 수 있기 때문이다.

 

데이터 엔지니어링 라이프사이클에서 윤리와 개인정보보호는 특히 중요한 역할을 한다. 데이터 엔지니어는 데이터 세트에서 개인 식별 정보(PII)와 같은 민감한 정보를 보호해야 하고, 데이터가 변환되는 과정에서 편향을 추적하고 식별할 수 있어야 한다. GDPR 및 CCPA와 같은 데이터 규정을 준수하는 것도 점점 더 중요해지고 있다. 데이터 엔지니어는 규정에 맞춰 데이터를 처리하고 보호해야 하며, 이 책에서는 데이터 엔지니어링 과정에 윤리와 개인정보보호를 어떻게 통합할 수 있는지에 대한 팁을 제공한다.

2.2.3 데이터옵스

데이터옵스는 Agile 방법론, DevOps, 통계적 프로세스 제어(SPC)의 모범 사례를 데이터 작업에 적용하는 개념이다. DevOps가 소프트웨어 제품의 품질과 릴리스를 개선하는 데 중점을 두는 것처럼, 데이터옵스는 데이터 제품에서도 동일한 목표를 지향한다.

 

데이터 제품은 소프트웨어 제품과 다르다. 소프트웨어 제품이 기능과 기술적 특징을 제공하는 반면, 데이터 제품은 비즈니스 로직메트릭을 기반으로 사용자가 결정을 내리거나 자동화된 작업을 실행할 수 있게 돕는다. 따라서 데이터 엔지니어는 기술적 측면뿐만 아니라, 비즈니스 로직품질까지 이해해야 한다.

 

데이터옵스린 제조공급망 관리에서 영향을 받아 사람, 프로세스, 기술을 결합해 가치 실현 시간을 단축한다.DataOps 전문가들이 정의한 것처럼, 데이터옵스는 빠른 혁신, 높은 데이터 품질, 낮은 오류율, 그리고 명확한 결과 측정을 목표로 한다.

 

데이터옵스는 단순한 기술 도구 이상의 문화적 습관이다. 팀이 사일로를 허물고, 비즈니스와 협력하며, 빠르게 반복하는 사이클을 채택해야만 최적의 결과를 도출할 수 있다.회사의 데이터 성숙도에 따라, 데이터 엔지니어는 DataOps를 처음부터 도입하거나 기존 인프라에 점진적으로 추가할 수 있다. 첫 단계로는 관찰 가능성모니터링을 도입하고, 이후 자동화사고 대응을 포함시킬 수 있다.

 

데이터옵스는 자동화, 모니터링 및 관찰 가능성, 사고 대응의 세 가지 핵심 기술 요소로 이루어져 있으며, 이를 통해 데이터 엔지니어링 라이프사이클을 최적화한다.

자동화

데이터옵스에서 자동화는안정성과 일관성을 제공하며, 데이터 엔지니어가 기존 워크플로에 새로운 기능개선 사항을 신속하게 배포할 수 있도록 돕는 중요한 요소이다. 데이터옵스 자동화는 DevOps와 유사한 프레임워크를 가지고 있으며, 변경 관리, 지속적인 통합 및 배포(CI/CD), 코드로 구성 등의 방식을 사용한다. 또한 데이터 품질, 모델 드리프트, 메타데이터 무결성 같은 추가적인 차원을 통해 시스템의 안정성을 지속적으로 확인하고 유지한다.

 

데이터옵스 성숙도가 낮은 조직에서는 주로 cron 작업을 사용해 데이터를 처리하려고 하지만, 파이프라인이 복잡해지면 다양한 문제를 겪게 된다. 예를 들어, 작업이 오래 실행되거나 실패하여 오래된 데이터를 생성할 수 있다. 성숙도가 높아지면 조직은 AirflowDagster 같은 오케스트레이션 프레임워크를 채택하게 된다. 이를 통해 종속성을 검증하고 더 효율적인 작업 실행이 가능해진다.

 

점차적으로 데이터 팀은 자동화된 DAG 배포를 도입해 더 높은 수준의 운영 안정성을 확보한다. 이는 DAG 배포 전 테스트를 통해 안정성을 검증하고, 잘못된 배포로 인한 시스템 오류를 방지한다. 데이터옵스에서 변화를 수용하는 것은 지속적인 개선을 의미하며, 각 단계에서 운영 효율성을 높일 수 있는 기회가 존재한다. 성숙도가 높아지더라도 데이터 팀은 계속해서 자동화 개선을 통해 업무 부하를 줄이고, 비즈니스 가치를 높이려는 노력을 지속해야 한다.

관찰 가능성과 모니터링

불량 데이터가 보고서에 남아 임원들이 잘못된 결정을 내리는 경우가 많으며, 그 오류를 발견하는 데는 수개월 혹은 수년이 걸린다. 이러한 잘못된 결정은 기업에 치명적인 영향을 미칠 수 있으며, 심각한 경우에는 회사가 재정적 파멸에 이를 수 있다.

 

또한, 데이터 생성 시스템이 무작위로 작동을 멈추어 보고서가 지연되는 상황도 자주 발생한다. 데이터 팀이 이러한 문제를 미리 파악하지 못하면, 다양한 이해 관계자들이 데이터 팀에 대한 신뢰를 잃고 독립적인 분파 팀을 구성하게 된다. 이로 인해 일관성 없는 보고서와 사일로 시스템이 생겨 조직이 더욱 복잡해지고 비효율적으로 변한다.

 

이러한 데이터 문제를 방지하려면 관찰 가능성, 모니터링, 로깅, 경고추적 시스템을 도입해야 한다. SPC(Statistical Process Control)를 통해 모니터링하는 데이터가 허용 범위를 벗어나는지 확인하고, 문제가 발생했을 때 빠르게 대응할 수 있도록 해야 한다.

 

Petrella의 DODD(Data Observability Driven Development) 개념은 데이터 체인의 모든 구성원이 데이터 변화를 즉시 파악하고 대응할 수 있는 가시성을 제공한다. 이를 통해 데이터 엔지니어링 라이프사이클 전반에서 데이터의 관찰 가능성을 최우선으로 삼고, 데이터 문제를 예방하고 해결할 수 있다.

사고 대응

데이터 옵스를 사용하는 고성능 데이터 팀은 새로운 데이터 제품을 신속하게 제공할 수 있지만, 실수는 피할 수 없다. 시스템 다운타임, 새로운 데이터 모델로 인한 보고서 중단, 오래된 ML 모델의 부정확한 예측 등 여러 문제가 데이터 엔지니어링 수명 주기를 방해할 수 있다. 사고 대응은 자동화 및 관찰 도구를 통해 문제의 근본 원인을 신속히 파악하고, 빠르게 해결하는 과정이다.

 

사고 대응에서 중요한 것은 기술이 아닌, 개방적이고 비난받지 않는 의사소통이다. Amazon Web Services의 CTO인 베르너 포겔스가 "모든 것은 항상 고장난다"라고 한 것처럼, 데이터 엔지니어는 이러한 고장에 대비하고 효율적으로 대응할 준비가 필요하다.

 

데이터 엔지니어는 비즈니스에서 문제가 제기되기 전에 이를 미리 발견하고 해결해야 하며, 문제가 발생하더라도 이미 적극적으로 해결 중이라는 인식을 주는 것이 중요하다. 신뢰는 오랜 시간 쌓아야 하지만, 순식간에 사라질 수 있다. 따라서 사고 대응은 사후 대처뿐만 아니라 사전 예방적 조치도 포함된다.이러한 데이터 옵스 접근 방식은 단순히 시스템 관리가 아닌, 문제를 빠르고 투명하게 해결하며, 신뢰를 유지하는 데 중점을 두고 있다.

2.2.4 데이터 아키텍처

데이터 아키텍처는 데이터 엔지니어링 수명 주기의 숨겨진 요소 중 하나이자 조직의 장기적인 데이터 요건과 전략을 지원하는 데이터 시스템의 현재 및 미래 상태를 반영함. 조직의 데이터 요구 사항은 빠르게 변화할 가능성이 높고, 빠르게 바뀌는 분위기인 만큼, 데이터 엔지니어는 적절한 아키텍처를 이해해야 함. 먼저 비즈니스 요구 사항을 이해하고 새로운 요구 사항을 수집해야 함. 그런 다음 이러한 요건을 변환해 비용과 운영 간소화를 균형 있게 유지하면서 데이터를 캡처하고 제공하는 새로운 방법을 설계해야 함. 즉, 원천 시스템, 수집, 저장, 변환, 및 데이터 서빙에 있어서 설계 패턴, 기술 및 도구의 트레이드 오프(trade-off)를 파악해야 함.

 

trade-off: 데이터 아키텍처 설계에서 각기 다른 설계 패턴, 기술 또는 도구를 선택할 때 반드시 고려해야 하는 상충 관계를 의미하며, 나타날 수 있는 여러 장단점.

 

다만, 데이터 엔지니어가 곧 데이터 아키텍처라는 의미는 아니며, 데이터 엔지니어가 데이터 아키텍처와 함께 작업할 경우 데이터 엔지니어는 데이터 아키텍처의 설계를 이행하고 아키텍처 피드백을 제공할 수 있어야 함.


2.2.5 오케스트레이션

오케스트레이션은 데이터 옵스 프로세스의 중심이자, 데이터 작업을 위한 엔지니어링 및 배포 흐름의 중요한 부분이다. 작업들이 예약된 순서대로 효율적으로 실행되도록 조정하는 과정으로, 에어플로(Airflow) 같은 도구는 스케줄러로 불리지만, 단순히 시간만 관리하는 크론(Cron)과 달리, 유향 비순환 그래프(DAG)를 사용해 작업 간 종속성을 관리한다. 오케스트레이션 시스템은 지속적으로 작업을 모니터링하고, 문제가 발생할 경우 경고를 보낸다. 또한, 백필(backfill) 작업을 통해 누락된 데이터를 다시 처리할 수 있다. 에어플로는 파이썬으로 작성되어 확장성이 뛰어나며, 루이지(Luigi), 컨덕터(Conductor) 같은 다른 오케스트레이션 도구들도 있지만, 에어플로가 널리 채택되고 있다. 오케스트레이션은 기본적으로 배치 개념을 따르지만, 스트리밍 DAG처럼 실시간 처리를 위한 대안도 존재하며, 펄사(Pulsar) 같은 플랫폼이 이를 간소화하려고 한다.

 

DAG : 방향성이 있는 간선과 순환이 없는 그래프 구조 

A → B → D
     ↘ C ↗

2.2.6 소프트웨어 엔지니어링

소프트웨어 엔지니어링은 데이터 엔지니어에게 중요한 기술로, 2000년부터 2010년까지의 현대 데이터 엔지니어링 초기에 데이터 엔지니어는 저수준 프레임워크에서 작업했으며, C, C++ 및 자바에서 맵리듀스 잡을 작성했음. 2010년대 중반 빅데이터 시대의 정점에 이르자 엔지니어들은 이러한 저수준의 세부사항을 추상화한 프레임워크를 사용하기 시작했음.

이런 추상화는 오늘날에도 계속됨. 클라우드 데이터 웨어하우스는 SQL 시맨틱을 사용한 강력한 변환을 지원함. 스파크(Spark)와 같은 도구는 저수준의 코딩 세부 정보를 데이터 프레임(DataFrame)으로 전환하면서 더욱 사용자 친화적으로 발전함. 이러한 추상화에도 불구하고 소프트웨어 엔지니어링은 여전히 데이터 엔지니어링에 매우 중요함.

 

맵리듀스(MapReduce): 대규모 데이터 세트를 처리하기 위한 분산 처리 프레임워크인 맵리듀스에서 실행되는 데이터 처리 작업.

코어 데이터 처리 코드

코어 데이터 처리 코드는 데이터를 추출, 변환, 적재(ETL 또는 ELT)하는 작업을 중심으로 설계된 소프트웨어의 핵심 로직으로, 데이터 엔지니어링 수명 주기 전반에 나타나는 코어 데이터 처리 코드는 계속 작성되어야 함. 데이터 엔지니어는 수집, 변환, 데이터 서빙과 관계없이 스파크, SQL, 빔(Beam) 등의 프레임워크와 언어에 매우 능숙하고 생산성이 뛰어나야 함.

오픈 소스 프레임워크 개발

많은 데이터 엔지니어가 오픈 소스 프레임워크 개발에 크게 관여하고 있으며, 데이터 엔지니어링 수명 주기의 특정 문제를 해결하기 위해 이러한 프레임워크를 채택 후 프레임워크 코드를 계속 개발해 사용 사례에 맞는 도구를 개선하고 커뮤니티에 기여함.

빅데이터 시대에는 하둡 생태계 내에서 데이터 처리 프레임워크가 폭발적으로 증가했는데, 이러한 도구는 주로 데이터 엔지니어링 수명 주기의 일부를 변환하고 서빙하는 데 초점을 맞췄음. 데이터 엔지니어링 도구의 진화가 중단되거나 느려지지는 않았지만, 그 강조점은 직접적인 데이터 처리에서 벗어나 추상화의 사다리(ladder of abstraction)로 옮겨가고 있음.

 

추상화의 사다리(ladder of abstraction)  : 데이터 엔지니어링 도구들이 점점 더 세부적인 저수준 데이터 처리에서 벗어나, 데이터 파이프라인과 작업을 더 높은 수준에서 관리하고 자동화할 수 있도록 추상화된 도구와 기능을 제공하는 방향으로 진화하고 있다는 뜻

스트리밍

스트리밍 데이터 처리는 본질적으로 배치보다 더 복잡하며, 도구와 패러다임이 아직 덜 성숙했음. 데이터 엔지니어링 수명 주기의 모든 단계로 더욱 확산됨에 따라 데이터 엔지니어는 흥미로운 소프트웨어 엔지니어링 문제에 직면하고 있음. 그 예시로, 배치 처리 세계에서는 당연하게 여기는 조인(join)과 같은 데이터 처리 작업은 종종 실시간으로 더 복잡해져, 더 복잡한 소프트웨어 엔지니어링이 필요함. 또한 엔지니어는 다양한 윈도잉(windowing) 방법론을 적용할 코드를 작성해야 함.

 

윈도잉: 연속적인 데이터 스트림을 특정 시간 간격이나 데이터의 특정 범위로 나누어 처리하는 방법론. 사용 시 추적 통계 함수 같은 중요한 측정 지표를 계산할 수 있음.

코드형 인프라

코드형 인프라(Infrastructure as Code, IaC)는 인프라 구성 및 관리에 소프트웨어 엔지니어링 관행을 적용하는 방식임. 빅데이터 시대의 인프라 부담은 기업들이 데이터브릭스나 아마존 EMR(Elastic MapReduce) 같은 관리형 빅데이터 시스템과 클라우드 데이터 웨어하우스로 이전하면서 감소하고 있음. 데이터 엔지니어는 클라우드 환경에서 인프라를 관리할 때, 인스턴스를 수동으로 스핀업하고 소프트웨어를 설치하는 대신 IaC 프레임워크로 대응하는 사례가 늘고 있음. 이러한 프레임워크를 사용하면 일련의 사양에 따라 인프라를 자동으로 배포할 수 있으며, 대부분의 경우 인프라뿐만 아니라 클라우드 서비스도 관리할 수 있음. 이는 데브옵스의 중요한 부분으로, 버전 제어와 배포의 반복성을 실현할 수 있음. 당연히 이러한 기능은 데이터 엔지니어링 수명 주기 전반에 걸쳐 매우 중요함.

 

스핀업(Spin up) : 클라우드 환경에서 새로운 인스턴스(가상 서버나 리소스)를 생성하고 실행하는 것을 의미

코드형 파이프라인

코드형 파이프라인(Pipelines as code)은 오늘날 오케스트레이션 시스템의 핵심 개념으로, 데이터 엔지니어링 수명 주기의 모든 단계에 영향을 미침. 데이터 엔지니어는 코드(일반적으로 파이썬)를 사용해 데이터 작업과 데이터 간의 종속성을 선언함. 오케스트레이션 엔진은 이 선언을 해석해, 가용한 자원을 활용하여 각 단계를 효율적으로 실행함.

범용 문제 해결

실제로 어떤 고급 도구를 채택하든, 데이터 엔지니어는 데이터 엔지니어링 수명 주기 전반에 걸쳐 도구의 한계를 넘는 문제를 해결하고 사용자 정의 코드를 작성해야 하는 상황에 자주 직면함. 데이터 엔지니어는 파이브트랜(Fivetran), 에어바이트(Airbyte), 또는 마틸리언(Matillion)과 같은 프레임워크를 사용할 때, 기존 커넥터가 지원되지 않는 데이터 소스를 다루기 위해 사용자 정의 코드를 작성해야 할 수 있음. 이를 위해서는 API를 이해하고, 데이터 풀링 및 변환을 수행하며, 예외 처리를 구현하는 등 필요한 소프트웨어 엔지니어링 기술에 능숙해야 함.

 

 

문제 1

다음은 어떤 용어에 대한 설명인가?

클라우드 환경에서 새로운 가상 서버나 리소스를 생성하고 실행하는 것을 의미한다. 이는 데이터 엔지니어들이 클라우드 인프라를 효율적으로 관리할 수 있도록 하며, 자동화를 통해 반복적인 인프라 작업을 줄인다.

  1. 맵리듀스 (MapReduce)
  2. 코드형 인프라 (Infrastructure as Code)
  3. 스핀업 (Spin up)
  4. 윈도잉 (Windowing)
더보기

정답: 3.스핀업 (Spin up)

문제 2:

윈도잉(windowing) 방법론은 어떤 데이터를 처리하는 데 사용되는가?

(1) 배치 데이터
(2) 스트리밍 데이터
(3) 이미지 데이터
(4) 오프라인 데이터

더보기

정답: 2. 스트리밍 데이터