ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 데이터 엔지니어의 업무범위(하는 일)
    Data 2021. 1. 6. 18:05
    반응형

    데이터 엔지니어의 업무는 단순하게 보면 '데이터 상품'을 만들기 위한 업무 또는 해당 업무의 기반을 만드는 업무라고 할 수 있습니다. 

     

    최종적으로는 데이터, 데이터 플랫폼, 데이터 서비스 등의 다양한 형태의 상품으로 보이더라도, 사실 그 내부에서는 서로 유기적으로 연결되어 있습니다. 이번 글에서는 먼저 domain 결합이 강한 형태와 self-service 형태의 데이터 업무 구조를 알아보고, 데이터 구조의 부분별로 상세히 어떤 일을 하는지 살펴보겠습니다.

     

    관련글:

    Domain-Oriented vs Self-Service 형태의 데이터 업무 구조

    데이터 엔지니어는 한 팀에서 사용자(주로 분석가나 데이터사이언티스트)와 도메인에 기반하여 함께 업무를 진행하는 경우가 있는 반면, 도메인에서 완전히 벗어나 도메인과 관련한 사항은 모두 사용자가 담당하고 데이터 엔지니어는 Self-Service를 제공하는 집중하는 형태로 일을 하게될 수도 있습니다 [1]. 파이프라인을 운영할지 아니면 파이프라인을 제공할지의 차이라고 보시면 될 듯 합니다.

     

    다만 다양한 데이터 상품이 데이터에 기반해 있고, 그 데이터의 흐름이 한쪽으로 흐르는 경우가 많아 '데이터 파이프라인'이라고 부르는 형태는 둘 다 유사합니다. 

     

    아래 이미지를 보면:

    Domain-Oriented, Image from Author

    도메인과 결합한 형태로 데이터 엔지니어가 데이터 분석가(또는 데이터 사이언티스트 등)가 어떤 형태의 데이터를 원하고, 어떻게 가공할지 논의하면서 업무를 진행하게 됩니다. 그렇기에 보통 데이터 팀 초기에 이러한 형태로 이뤄지고, 점점 self-service 형태로 진화하여 사용자의 업무가 데이터 엔지니어에 의존적인 형태를 벗어나게 됩니다.

     

    Self-Service, Image from Author

    반면, Self-Service 형태인 경우에는 수집, 저장, 가공의 다양한 서비스가 사용자가 직접 접근할 수 있는 형태의 Self-Service로 제공됩니다. 

    통합적인 관점에 기반한 온프레미스 데이터 플랫폼 구조 비교분석에서 언급된 것과 같이, 특정 도메인에 데이터 엔지니어가 관여하지 않고 사용자가 자신의 목적에 맞게 직접 접근하고 변경할 수 있어야 합니다. 

     

    이러한 구조에서 데이터 엔지니어는 직접 수집, 저장, 가공을 처리하기 보다는 해당 기능들을 어떻게 더 self-service로 제공하며 전체적으로 관리할지(거버넌스)를 고민하고 구현하는 데에 더 많은 시간을 쏟게 됩니다. 

     

    각 부분별 하는일

    이 부분에서는 각 부분별로 어떤일을 하여야 하는지를 주로 위의 도메인 기반 구조 관점에서 전달드리겠습니다.

     

    기본적으로 Self-Service 형태에서는 아래에서 말씀드릴 각 부분에서 사용자가 직접 접근이 필요한 부분을 빼고 담당하는 대신, 사용자가 접근할 수 있도록 하는 서비스나 거버넌스에 좀 더 중점적으로 업무를 진행한다고 생각하시면 될 것 같습니다. 

     

    개괄적인 부분만 기술하였기에, 실질적인 도구 또는 좀 더 상세한 사항이 궁금하신 경우에는 주요 IT 기업의 모던 데이터 시스템을 참고하시면 될 것 같습니다.

     

    수집

    다양한 원천에서 데이터를 수집하는 업무입니다.

     

    데이터베이스에 저장된 유저테이블일 수도 있고, 실시간으로 IoT 기기에서 들어와 Kafka에 저장된 데이터일 수도 있습니다. 다양한 원천이 존재합니다. 또 다른 부분은 배치로 수집할지 아니면 실시간(Streaming)으로 수집할지 여부입니다. 

     

    운영에 있어서는 데이터가 수집되어야 이후의 데이터에 기반한 가공이나 서비스가 보장받을 수 있기에(또는 데이터 자체가 수집되지 않아 아예 잃어버릴 수 있기에) 안정성 측면이 많이 요구되는 부분입니다. 구체적으로 나열하자면, 수집하는 애플리케이션을 운영하거나 모니터링하거나 CRUD하거나(또는 개인정보 등의 이유로 암호화 & 복호화를 하거나) 등등이 있습니다.

     

    이렇게 수집한 데이터는 주로 영구적인 저장소에 저장됩니다.

     

    저장

    데이터를 저장하는 부분입니다. 어디에 저장할지, 어떤 파일포맷으로, 어떤 압축방식으로 저장할지 등을 고민하고 운영적인 면에서는 이후의 거버넌스와 관련해 디스크(또는 데이터)사이즈를 모니터링하거나 라이프사이클을 관리하거나 하는 부분이 관련되어 있습니다. 

     

    가공

    저장한 데이터를 목적에 맞게 가공하는 작업입니다. 어떻게 가공할지, 어떤 가공도구들을 사용할지, 다양한 작업들의 선행작업 관계는 어떻게 관리할지, 작업들이 실패할 경우 어떻게할지 등을 고민하고 개선합니다 [2].

     

    사용 및 거버넌스

    사용자는 기본적으로 잘 관리된 데이터를 사용하는 것 이외에도 메타데이터를 확인하기 위한 서비스, 데이터 분석을 하기 위한 데이터 탐색도구, 훈련시킨 모델을 실제로 배포하기 위한 모델관리도구 등 현재에도 지속적으로 추가되고 발전하는 다양한 사용패턴을 가집니다. 

     

    또한, 특히 Self-Service 형태에서는 더욱, 각 부분에서 '데이터의 신뢰성을 높이기 위해' 거버넌스가 필요하기도 합니다. 

     

     

    Reference

    [1] How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

    [2] Rebuilding Reliable Data Pipelines Through Moderns Tools  
    [3] https://naver-career.gitbook.io/kr/service/search/ai-and-data-platform

    반응형
Kaden Sungbin Cho