'데이터 엔지니어'라는 직무는 어떻게 탄생되었나: 요구사항과 도구들

새로운 직무는 보통 기존의 직무에서 어떤 요구사항이 지속적으로 발생하면서 점점 복잡해지며 기존의 직무에서 떨어져나와 탄생하게 됩니다.

 

데이터 엔지니어라는 직무가 어떻게 탄생하게 되었는지 알기위해 지난 20년 동안 어떤 요구사항들이 발생하고 어떤 도구들이 쓰였으며, 그러한 부분이 시간이 지남에 따라 어떻게 변화했는지 살펴보려 합니다. 그것을 통해 최종적으로 데이터 엔지니어의 컨택스트(Context)와 본질을 알아보겠습니다 [1].

 

관련글:

• 데이터 엔지니어란?
• 기업 내의 데이터 환경은 어떤 모습인가
• 데이터 엔지니어의 업무범위(하는 일)
• 데이터 엔지니어 역량 (feat. 구인구직사이트 자격요건)

 

현재 데이터 시스템에 대한 좀 더 상세한 도구들이 궁금하신 경우 아래와 같은 글(또는 책)을 참고하시면 좋을 것 같습니다:

• 주요 IT 기업의 모던 데이터 시스템  
• 통합적인 관점에 기반한 온프레미스 데이터 플랫폼 구조 비교분석
• The Self-Service Data Roadmap 

728x90

 

엑셀로 분석하던 시대

386 Intel 컴퓨터에서 작동하던 엑셀은 가장 처음 도입된 도구이자 현재까지도(사용되며) 데이터 분석에 대해 기대되는 모습, 결과를 형성한 도구입니다.  데이터 관리, 시각화, 처리 등의 기능과 함께 기대되는 결과로는 시각화, 함수(Sum, Group By 등), 그래픽(차트 등), 의사결정 (조건문을 통한 대상 추출 등)를 만들었습니다.

 

데이터베이스 시대

스프레드시트가 데이터베이스로 변하는 시대에는 Microsoft Access, Oracle, SQL Server과 같은 기술이 등장했습니다. 이러한 데이터베이스는 엑셀에서 하던 작업을 스케일하고 더 풍부한 데이터(유저의 접근패턴과 트랜잭션 정보 등에 대한 정보 등)를 사용할 수 있도록 하였습니다.

 

그러나 구조상의 Normalization은 단순한 사실 확인을 위해서도 수많은 테이블을 조인하여야 하였고, 복잡한 데이터 분석에는 더욱 어려움이 있었습니다. 또한, 해당 DB 구조를 모르는 경우에는 많은 시간이 소요되었습니다. 

 

그리고 join이나 window 함수는 엄청난 부하로 인해 쿼리 시간이 오래 걸리기도 하였습니다. 그러한 이유로 다양한 기업에서 아래의 Appliances를 제공하기 시작하였습니다.

 

Appliances

기본적인 개념은 데이터베이스를 여러 노드에 분산하여 처리가 느리거나 불가능했던(또는 저장이 불가능했던) 부분을 해결하는 것이었습니다. 하지만 아래와 같은 문제점들이 존재하였습니다:

• 분산 시스템 구현에 대한 경험 부족: 업계 내의 분산시스템 구현 경험은 아직 성숙하지 않았고 그로 인해 분산시스템 구현 상의 많은 문제점이 발생
• 최성능의 하드웨어를 요구하는 부분: 위로 인하여 노드 실패는 매우 큰 타격을 입히는 상황이었고 그렇기에 (노드 실패를 피하기 위해) 많은 백업 장비를 필요로 했음
• 저장 및 쿼리성능에 대한 한계: 증가하는 데이터 사이즈와 복잡한 쿼리를 따라잡기엔 어려운 상황이었음

위와 같은 문제로 인해, 화면한 모습으로 등장했던 Appliances에 대한 기대는 무너졌고, 다른 대안이 없이 비싸고, 느린 환경이 몇 년 동안 지속되었습니다 [2].

 

 ETL(Extract, Transform, Load) 플랫폼의 등장

위의 문제점을 고치기 위한 한 가지 대안으로 제시된 것이 appliance의 역할을 재정의하는 것이었습니다. 그리고 문제는 appliance가 아니라 '데이터가 커지고 처리가 복잡해져서'이기 때문에 그러한 transform 부분에 다른 도구를 사용하자고 주장하였습니다.

 

그렇게 appliance는 분석가가 사용할 수 있도록 놔두고, 복잡한 처리는 다른 곳에서 해결하는 구조(ETL)이 등장하였습니다. 이러한 형태는 다음 3가지의 목적을 가지고 있었습니다:

 

• Appliance 상에서 분석가에게 쾌적한 분석 환경 제공
• 데이터 엔지니어에게 Transform 코드와 운영을 담당하게 함 (데이터 엔지니어가 점차 하나의 직무로 생성되던 때)
• 벤더(Vendor)에게 새로운 카테고리의 상품을 판매할 수 있도록 함

 

ETL과 같은 용어는 이전에 쓰였을지 모르나, 이 시기에 데이터 파이프라인(Data Pipeline)과 데이터 엔지니어의 역할을 전면적으로 등장하게 되었습니다. 당시에는 데이터 파이프라이닝과 관련해 1) 어떤 시스템을 사용할지, 2) 가공 비용, 3) 스케쥴링 리소스, 4) 접근 관리 등이 주요한 주제였습니다.  

 

그러나, 당시 대부분은 하나의 시스템이 이 복잡한 모든 것을 담당하기는 어렵다는 인식이 팽배하였고, 기존의 appliance + 다양한 transform 도구의 조합이 만족스럽지 않다는 부분도 공감하였습니다. 

 

Kafka, Spark, Hadoop, SQL, 그리고 NoSQL 플랫폼

2000년대 초의 인터넷 기업들을 위와 같은 문제점을 인식하고 있었고 기업 내부적으로 해당 문제를 해결하기 위한 다양한 시스템을 개발하였습니다(GFS 등). 그러한 발명들은 유사한 형태의 다양한 오픈소스 프로젝트(HDFS 등)를 촉발시켰습니다. 그리고 그 오픈소스 프로젝트들은 현재까지의 데이터 환경의 기반을 이루고 있습니다. 그 중심 개념들은 아래와 같습니다:

 

• 복잡도 최소화: Normalization으로 인한 join 시 복잡도 증가가 문제라면 그냥 하나의 테이블에 nested type 형태로 몰아넣자 (NoSQL)
• fault-tolerant: 노드 실패를 피하기 위해 비싼 하드웨어를 사용하지 말고 노드 실패를 그냥 당연한 걸로 여기고 소프트웨어 레벨에서 핸들링 할 수 있도록 하자
• 논리적으로 저장소(Storage)와 컴퓨팅(Computing)을 분리: appliance는 데이터가 저장되는 노드에서 데이터 처리까지 했다면, 데이터 저장과 데이터 처리는 분리해서 decoupling 시키자
• SQL 이상으로: 데이터 접근 시 SQL과 코드도 같이 사용 가능하도록 하자

많은 개선이 이루어졌지만, 1) 다양한 도구들은 특정 목적에 국한되어 개발됨, 2) 그 많은 도구들을 조합하여 사용함, 3) 그 많고 복잡한 도구들을 다루는 사람을 고용하기 어려움이라는 문제점들이 존재하였습니다.

 

당시의 기업의 데이터 운영의 어려움은 도구나 시스템의 부족보다는 coordination, auditing, 비젼과 이해(거버넌스 등)가 많이 부족에 있었습니다.

 

 

클라우드, 온프레미스, 그리고 하이브리드 환경

점점 이러한 도구들에 대한 이해가 발전하고 있을 때, 클라우드는 모든 것을 바꿔놓았습니다. 처음엔 모든 인터넷 서비스 회사들은 클라우드 진입을 꺼렸으나, CIA가 Amazon을 클라우드 제공자로 선택하고, FINRA(US 주식 Regulator)가, Capital One이 클라우드를 사용하자 클라우드에 대한 이견은 모두 사라졌습니다.

 

이전 Hadoop 탄생 시기의 도구들이 바뀌지는 않았지만, 그러한 오픈 소스 도구들이 탁월하게 통합되어 손쉽게 클라우드를 통해 사용할 수 있게 되었습니다. 또한, Cloudera와 같은 데이터 플랫폼 Integration 서비스를 제공하는 기업이 등장하며 온프레미스의 환경도 개선되었습니다. 

 

 

데이터 사용의 다양화: Machine Learning, Advanced BI, IoT

최근의 데이터 사용의 다양화가 데이터 환경을 변화시키며 현재를 만들어 왔습니다. IoT 사물들에서 텍스트, 이미지, 온도 등의 다양한 데이터가 실시간으로 수집되고 추천, 이상탐지, 다양한 예측 등 다양하게 데이터를 사용하면서 복잡해지는 데이터 환경을 따라가기 벅차지만, 현재는 대부분의 요구사항들이 반영될 수 있는 단계에 이르렀습니다.

 

현재도 그러한 솔루션을 도입하는 데에는 뛰어난 엔지니어가 필요하지만, 점점 더 그러한 단순한 서비스 형태로 제공되고 있습니다. 이러한 모습은 자동차 산업이 고도화 되면서, 한 회사에서 만들던 베어링, 엔진 등과 같은 부분을 하나의 전문화된 회사가 만들고 있는 현재의 형태로 발전해가는 모습과 유사합니다. 

 

앞으로는 더욱 그러한 방향으로 진행되며 데이터와 관련해 다양한 직무가 좀 더 명확히 구분되어질 것으로 추측해 봅니다.

 

Reference

[1] Rebuilding Reliable Data Pipelines Through Moderns Tools  

[2] “One Size Fits All”: An Idea Whose Time Has Come and Gone