데이터 엔지니어링 세미나 후기

세미나 개요

제목: Insights Into Data Engineering
일시: 2022.10.27 18:40
장소: LT1A, Nanyang Technological University, Singapore
연사: Mr. Raj Kunwar Singh, A senior data engineer working at Grab
주최: Open Source Society, NTU

seminar_poster — 이름만 달아둔 동아리였는데 이렇게 좋은 세미나를 열어주다니!

참석 동기

데이터 엔지니어링이 뭔가 싶어서 이 세미나를 신청했다. IT 직군 중에서 개발자나 디자이너의 업무들은 프리랜서로서 잠시 지켜봤고, 데이터 애널리스트에 대해서도 수업시간에 데이터 분석들을 직접 해보면서 약간 느낌이 왔다. 그러나 데이터 엔지니어링은 도무지 감이 오질 않았다. 전공이나 강의가 따로 있는 것도 아니고 찾아보면 뜬구름 잡는 소리 밖에 없었으니 그 정체가 궁금했다.

NTU 교환학생 생활 중 가입했던 동아리 중 하나인 Open Source Society에서 데이터 엔지니어링에 대한 세미나가 있다길래 얼른 신청했다. 자기 자신을 데이터 엔지니어라고 소개하는 사람은 과연 어떤 말을 하는 지 들어보고 싶었다. 마침 시간도 나고 할일도 없겠다 LT1A로 세미나를 들으러 갔다.

seminar_lt — Zoom으로도 열렸는데 시간이 남아돌아서 직접 참석했다.

세미나 요약

세미나는 전반적인 데이터 엔지니어링에 대해 다루었다. 데이터 엔지니어링이 등장하게 된 배경과, 어떠한 문제상황이 있으며 이를 어떻게 해결하고 있는가에 대한 설명들이 있었다. 그리고 후반부에는 데이터 엔지니어들은 어떠한 일들을 수행하며, 어떠한 고민을 하고, 어떠한 능력들이 필요한 지에 대해서도 언급되었다. 세미나 중에서 우선 내가 이해했으며, 그 중 인상깊었던 포인트들을 정리해보고자 한다.

Various Source and Demand

세상에는 생성되는 데이터도 많고 이를 활용하고 싶어 하는 사람들도 많다. 게다가 그 데이터는 양도 많고 복잡해서 이를 다루는 일은 생각보다 쉽지 않다. 데이터를 잘 수집해서 정리하는 일을 하는 것이 바로 데이터 파이프라인이다. 이 파이프라인이 세상과 닿아있는 부분은 크게 데이터를 활용하는 Output과 그들이 필요한 데이터가 만들어지는 Input 부분으로 나누어 생각해볼 수 있다.

Output 부분에서는 여러 이해관계자들이 등장한다. Data Analyst 들은 기업이 수집할 수 있는 데이터 가운데에서 인사이트를 찾아내려고 노력한다. Business Intelligence 툴들은 최고 관리자의 의사결정이나 중역 관리자들의 업무를 하는데 있어 도움이 되는 데이터들을 잘 보여주길 원한다. 그리고 AI 분야에서도 모델 학습을 위해 방대한 양의 데이터를 필요로 한다.

Input에서 Output의 사람들이 직접 필요한 데이터를 모으는 일은 어렵다. 데이터는 Database 에서만 생겨나는 것이 아니다. 마케팅 부서에서는 Frontend에서 셀 수 있는 클릭 수를 알고 싶어 하고, 전산 부서에서는 Backend에서 어떤 프로세스가 얼만큼의 자원을 필요로 하는 지 알고 싶어할 것이다. 이렇게 다양한 Endpoint에서 데이터를 잘 수집하는 일을 파이프라인이 수행하게 되는 것이다.

Changes of Paradigm

사람들의 데이터에 대한 기대는 점점 늘어나고 있다. 데이터에서 더 많은 인사이트를 얻기 바라며, 더 최신의 것을 필요로 하고, 더 빠른 시간 안에 필요한 정보를 손에 얻길 원한다. 이에 부응하기 위해서는 새로운 기술이 쓰인다거나 기존 접근 방식을 완전히 바꾸는 일도 필요하다.

From ETL to ELT

기존 데이터 파이프라인의 작업은 ETL (Extract, Transform, Load) 이었다. 데이터를 추출하고, 변환하여 저장하고, 이를 필요한 사람들이 가져다 쓰는 것이다. 여기서 주목할 만한 단계는 Transform과 Load 이다. 어지럽게 쏟아지는 데이터 중에서 쓸만한 것들을 찾아내어 Data Warehouse에 저장하고, 필요한 사람들이 그 곳에서 필요한 데이터를 빼내어 쓰는 것이다. 우리는 더 많은 데이터 속에서 조금이라도 더 많은 인사이트를 도출할 수 있다. 하지만 데이터가 많고 복잡할 수록 데이터를 관리하는 일은 어려워지게 된다.

이러한 상충되는 이해관계를 해결하기 위해 ELT (Extract, Load, Transform) 으로 작업 순서를 바꾸게 된다. Data Lake라는 곳에 원본 그대로 저장하고, 데이터 분석이 필요할 일이 있다면 불러낸 다음에 의미있는 형태로 변환한다. Data Analyst 입장에서는 모든 feature를 있는 그대로 확보할 수 있다는 장점이 있으며, 데이터 엔지니어 입장에서도 Schema를 고민할 필요 없이 신속하게 원본을 저장해 버릴 수 있다는 점에서 서로 이득이 있다.

etl_vs_elt — ETL과 ELT의 차이. 출처: integrate.io

From Batch to Streaming

전통적인 데이터 처리 방식은 배치 스케줄링이다. 계속해서 쌓이고 있는 데이터들을 일정 시간마다 데이터 분석에 사용 가능한 상태로 만들어두는 것이다. 예를 들어 낮이나 평일에 생성된 데이터들을 트래픽이 적은 야간이나 주말에 몰아서 Data Warehouse에 넣어주는 작업 방식이다. 이 처리 방식은 데이터를 활용하는 데 전혀 문제가 없다. 하지만 사람들은 좀 더 최신의 데이터를 원한다. 하루나 일주일을 기다리는 것이 아니라 방금 생성된 데이터들도 지금 당장 손에 넣고 싶어 한다.

스트리밍은 기존 데이터 처리 방식과 차원이 다르다. 데이터 공급과 수요 사이에 Publish - Subscribe 관계가 만들어진다. 예를 들어 어떠한 서비스에서 데이터가 생성되었을 때 자신에게 새로운 항목이 있다는 신호가 나온다 (publish). 그리고 그 서비스의 데이터가 필요한 또 다른 서비스는 (혹은 서비스들은) 거기서 신호가 나오길 기다리고 있다 (subscribe). 신호를 포착한 순간 데이터를 받는 곳에서는 각자 그 곳에서 데이터를 가져가게 된다.

data_streaming — 데이터 스트리밍 개요. Pub-Sub 메시징이 사용된다. 출처: hazlecast

이러한 스트리밍의 첫번째 특징은 관심사의 분리다. 데이터를 만들어내는 입장에서는 받는 사람이 누구인지, 필요한 게 뭔지, 언제 보내야 하는 지 고민할 필요가 없이 그저 신호만 보내면 된다. 그리고 데이터를 활용하는 입장에서도 자신이 필요한 데이터를 가진 곳에서의 신호만 듣고 있으면 된다. 두번째 특징은 비동기적 처리다. 데이터를 처리하는 방법을 일련의 작업 형태로 정의할 필요가 없다. 그저 데이터를 활용하고 싶어하는 사람들이 알아서 자신의 필요에 맞게 가져가면 된다.

From Single to Distributed computing

분산 컴퓨팅은 많은 데이터를 짧은 시간 안에 다룰 수 있게 한다. 하나의 디스크는 생성되는 모든 데이터를 담을 수 없게 되었다. 그리고 하나의 프로세서로 거대한 데이터를 다루려고 한다면 작업이 끝나기까지 한세월이 걸리게 된다. 마찬가지로 데이터를 활용하고자 하는 사람들이 많아질 수록 자신이 필요한 결과를 받는데 더 오랜 시간이 걸린다. 사람들의 컴퓨터에 대한 기대는 컴퓨터 한 대의 성능을 한참 벗어나고 있다. 이제는 데이터를 다룰 때 여러 대의 컴퓨팅 파워를 이용해야 한다.

깨달은 점

이번 세미나는 데이터 엔지니어링의 직무를 준비하는 데 큰 도움이 되었다. Data Analyst와 Data Engineer의 관계도 이해했고, 어떤 Tech Stack을 쌓고 있는 지도 알 수 있었다. 무엇보다도 현업에 계신 분이 하시는 말씀이다 보니 전반적인 내용에 믿음이 갔다. 이 시간동안 어떤 점을 깨달았는지 정리해보면 다음과 같다.

깊은 생각과 다양한 기술이 필요하다

데이터 엔지니어링이라고 하는 것은 데이터 수집과 활용 사이의 파이프라인을 관리하는 일이라고 요약할 수가 있다. 전에 나는 그 업무의 범위가 데이터가 흐르는 것을 관리하는 일이라고만 생각했다. 하지만 세미나를 듣고 나니 데이터가 생기는 장소와 필요한 장소에 적절한 방법으로 파이프를 놓는 일이 더 중요함을 알게 되었다. 이러한 장소들은 끊임없이 복잡해지기 때문에 세상 밖의 변화를 민감하게 포착하고 이를 데이터 파이프라인에 반영할 수 있어야 한다.

데이터 엔지니어의 가장 큰 고민은 양과 복잡성이 증가하는 중에도 좋은 품질의 데이터를 적시에 전달할 수 있는가 라고 볼 수 있다. 세상이 그저 돌아가기만 하면 되는 서비스를 요구했다면 이 직무는 만들어지지도 않았을 것이다. 세상의 데이터는 날이 갈 수록 많아지고 기괴해지고 있으며 사람들은 이러한 데이터로부터 인사이트를 서둘러 찾고 싶어 한다. 세상의 요구사항을 충족시키기 위해선 훨씬 더 많은 생각을 해야 하고 훨씬 더 높은 수준의 기술들을 다룰 수 있어야 한다.

차근차근 이해하는 것이 중요하다

grab_pipeline — 그랩의 Data Pipeline. 사실 저런게 궁금했다.

데이터 파이프라인은 크고 복잡하다. 데이터 자체가 크고 복잡하다보니 이를 수집하고 가공하는 과정이 이렇게 불어났다. 게다가 이런 저런 데이터를 필요로 하는 사람들이 많아지다 보니 수많은 endpoint들을 관리하는 것도 꽤나 어려운 일이 되었다. 그냥 데이터를 복붙하면 안되려나 하는 생각이 들지만 이 거대한 시스템을 관리하기 위해 데이터 엔지니어링이라는 개념이 등장했음을 기억해야 한다.

데이터 엔지니어링에 대한 역량은 우선 적고 단순한 데이터를 다루는 일 부터 시작해야 한다. 데이터 엔지니어가 해야할 일은 차고도 넘치지만 궁극적으로 데이터를 다루는 일에 참여하고 있는 것이다. 다루고자 하는 데이터가 작고 단순하다면 익숙한 프로그래밍 언어에 코드 몇 줄 만으로 끝낼 수 있을 정도로 어려울 것이 없다. 이 방식 그대로 더 많고 복잡한 데이터를 다루어보자. Load하는 순간 Memory Overflow가 발생하거나 돌아가더라도 끝나지 않을 것이다.

더 많고 복잡한 데이터를 다루려는 고민과 시도를 해야 한다. 현업 데이터 파이프라인에 쓰인다고 해서 무작정 아무 프레임워크나 공부하는 것은 쉽게 지치는 일이다. 기존 방식의 한계를 몸소 체감해야 이를 극복할 수 있는 다른 방식들을 배울 준비가 된다. 직면한 문제를 해결하기 위해 머리를 싸매다 보면 자연스럽게 새로운 방식들이 눈에 들어오게 될 것이다. 문제 해결이라는 동기가 명확하다면 그 새로운 방식을 배우는 과정은 훨씬 수월할 것이다.

하나부터 확실하게 하자

데이터 엔지니어는 한 번에 만들어지지 않는다. 어느 전공을 4년동안 배우거나, 어느 시험을 통과하거나, 어느 회사에 들어가는 것이 그게 데이터 엔지니어가 되는 방법이라고 말할 수는 없다. 이 커리어를 준비한다는 것은 작은 것 하나부터 시작하면 된다.

학부생 입장에서는 데이터 파이프라인에 사용되는 어느 프레임워크 하나 정도는 능숙하게 쓸 수 있어야 한다. 어떠한 문제 상황이 생겼을 때 그 프레임워크가 효과적으로 쓰일 수 있는지 판단해야 하며 코드를 작성하는 중에서도 (어렵겠지만) 기본적인 문법은 헛갈리지 말아야 한다.

인턴을 한다고 했을 때 기존에 굴러가는 파이프라인에서 작은 이슈부터 해결해야 한다. 처음부터 끝까지 데이터 파이프라인을 설계하고 구현할 수는 없다. 이미 만들어진 파이프라인에서 구성요소들의 관계를 음미하면서 지금 내가 맡은 부분을 설계할 때 어떠한 점들을 고려해야 하는지 차근차근 파악하는 계기로 삼아야 한다.

대학원을 가게 된다면 Streaming이나 Distributed Computing과 관련된 연구에 참여해야 한다. 이는 현업과는 동떨어져 보일 수 있겠지만 어떠한 기능 하나 정도는 연구 분야에서 마음껏 쓸 수 있도록 보장해줘야 산업 분야에서 안심하고 자유롭게 사용할 수 있을 것이다.