애널리틱스 엔지니어

애널리틱스 엔지니어는 회사에 쌓인 원본 데이터를 누구나 바로 분석할 수 있는 표로 다듬어 내놓는 직무입니다. 데이터를 모아 오는 사람과 그 데이터로 답을 찾는 사람 사이에서 일합니다. 손에 쥔 도구는 주로 데이터베이스 조회 언어입니다. 일하는 방식은 소프트웨어 개발자와 닮았습니다.

상세

식당 주방에는 재료를 다듬어 두는 사람이 따로 있습니다. 채소를 같은 크기로 썰어 통마다 담아 둡니다. 요리사는 주문이 들어오면 통을 열어 바로 볶습니다. 다듬는 사람이 없으면 요리사마다 감자 껍질부터 깎습니다. 써는 크기도 저마다 다릅니다.

데이터 일에도 재료를 다듬는 사람이 있습니다. 회사의 데이터는 처음에 서비스가 쓰던 모양 그대로 쌓입니다. 주문 표에는 주문 한 건이 한 줄로, 결제 표에는 결제 한 건이 한 줄로 들어 있습니다. 이렇게 서비스에서 복사해 온 손대지 않은 표를 원본 데이터라고 부릅니다.

원본 데이터로는 「지난주 매출이 얼마인가」에 바로 답하기 어렵습니다. 주문과 결제를 맞춰 봐야 합니다. 그다음 환불 건을 빼고 날짜별로 더합니다. 애널리틱스 엔지니어는 이 작업을 미리 해 두는 직무입니다.

이 직무는 날짜별 매출이나 고객별 첫 구매일처럼 질문에 바로 쓰는 표를 만들어 둡니다. 이렇게 다듬어 둔 표를 이 문서에서는 분석용 표라고 부릅니다.

그 표를 읽고 질문에 답하는 사람은 데이터 분석가입니다. 애널리틱스 엔지니어는 분석가가 계산을 처음부터 다시 하지 않게 해 줍니다. 분석가는 다듬어진 표를 열어 바로 답을 찾습니다.

이 표들이 사는 곳은 대개 데이터 웨어하우스입니다. 분석에 쓰려고 회사 곳곳의 데이터를 한데 모아 둔 데이터베이스입니다. 서비스용 데이터베이스와 따로 두는 까닭은 오래 걸리는 집계 조회가 서비스 응답을 늦추지 않게 하려는 데 있습니다.

표를 만드는 데 쓰는 말은 SQL(Structured Query Language, 구조화 질의어)입니다. 데이터베이스에 표를 조회하고 만들라고 지시하는 언어입니다. 애널리틱스 엔지니어가 쓰는 코드는 대부분 SELECT 조회문입니다. 결과 표의 모양을 조회문으로 적어 두면 웨어하우스가 그 표를 만듭니다.

다듬은 표들이 어떤 칸을 갖고 서로 어떻게 이어지는지 정하는 일을 데이터 모델링이라고 합니다. 이 직무가 하는 일의 한가운데가 이것입니다. 어느 표를 한 줄에 주문 하나로 둘지, 고객 하나로 둘지를 정합니다. 이 결정이 분석가가 쓰기 편한 표인지 아닌지를 가릅니다.

데이터가 지나가는 길

이 소절에서는 데이터가 서비스에서 화면까지 가는 길 위에 세 직무를 놓아 봅니다. 누구의 손을 떠나 누구에게 넘어가는지가 보이면 애널리틱스 엔지니어가 맡는 구간이 드러납니다.

flowchart TD
    A["서비스 데이터베이스 · 외부 서비스"] -->|데이터 엔지니어가 옮겨 온다| B["웨어하우스의 원본 표"]
    B -->|애널리틱스 엔지니어가 다듬는다| C["분석용 표"]
    C -->|데이터 분석가가 읽는다| D["대시보드 · 보고서"]

맨 앞 구간은 데이터 엔지니어가 맡습니다. 서비스 데이터베이스나 결제 대행사 같은 외부 서비스에서 데이터를 꺼내 웨어하우스로 옮깁니다. 옮기는 작업이 매일 빠짐없이 돌도록 돌보는 것도 이 직무의 몫입니다.

맨 뒤 구간은 데이터 분석가가 맡습니다. 분석용 표를 읽어 「왜 지난주 매출이 떨어졌나」 같은 질문에 답합니다. 그 답을 보고서로 쓰거나 대시보드로 띄워 둡니다. 대시보드는 숫자와 그래프를 한 화면에 모아 늘 최신 값으로 보여 주는 화면입니다.

가운데 구간이 애널리틱스 엔지니어의 몫입니다. 원본 표를 받아 분석용 표로 바꿉니다. 분석가가 스스로 답할 수 있게 깨끗한 표를 내놓는 쪽이지, 질문에 직접 답하는 쪽은 아닙니다.

이 직무가 생긴 까닭

예전에는 원본에서 꺼낸 데이터를 웨어하우스 밖의 별도 서버에서 먼저 바꿨습니다. 다 바꾼 결과만 웨어하우스에 넣었습니다. 이 꺼내기·바꾸기·넣기 순서를 ETL(Extract-Transform-Load, 추출-변환-적재)이라고 부릅니다.

이때는 데이터를 옮기는 사람이 바꾸는 일까지 같이 했습니다. 바꾸는 코드를 데이터 엔지니어가 짰으므로 분석가는 새 표가 필요할 때마다 요청하고 기다렸습니다.

웨어하우스가 크고 빨라지면서 순서가 바뀌었습니다. 원본을 먼저 전부 넣어 두고 웨어하우스 안에서 SQL 로 바꾸는 방식입니다. 이 순서를 ELT(Extract-Load-Transform, 추출-적재-변환)라고 부릅니다.

바꾸는 일이 웨어하우스 안의 SQL 로 옮겨 오자 분석가도 직접 표를 만들 수 있게 됐습니다. 분석가는 대개 이미 SQL 로 표를 조회해 답을 찾던 사람이기 때문입니다.

그러자 다른 문제가 생겼습니다. 분석가마다 자기 조회문을 따로 짰습니다. 같은 「매출」을 한 사람은 환불을 빼고 계산하고 다른 사람은 빼지 않았습니다. 회의에 숫자 두 개가 올라오면 어느 쪽이 맞는지 가릴 방법이 없었습니다.

조회문은 계속 불어났습니다. 누가 어떤 표를 읽는지는 아무도 몰랐습니다. 원본의 칸 하나가 바뀌면 어느 대시보드가 깨지는지 알 수 없었습니다. 이 변환 구간을 맡아 한곳에 정리하고 코드처럼 관리할 사람이 필요해졌습니다. 그 일에 붙은 이름이 애널리틱스 엔지니어입니다.

이 직무와 함께 자주 이름이 오르는 도구가 dbt 입니다. 웨어하우스 안에서 SQL 조회문 파일들을 돌려 분석용 표를 만드는 도구입니다. 한 표가 다른 표를 읽어 만들어지는 일이 많아서, 먼저 있어야 할 표부터 차례로 돌립니다. 아래 소절에서 보는 일하는 방식을 이 도구가 받쳐 줍니다.

코드처럼 다루는 분석 SQL

예제 조회문 하나를 따라가며 그 파일이 어떻게 관리되는지 봅니다.

먼저 원본 주문 표가 아래처럼 생겼다고 합시다. 한 줄이 주문 한 건이고 status 칸이 결제 상태를 담습니다. 3번 주문은 환불됐습니다.

날짜별 매출 표는 아래 조회문 하나로 정의합니다. 환불을 뺀 결제 완료 건만 날짜별로 더합니다.

select
    ordered_on,
    sum(amount) as revenue -- 10-01: 30000
from orders
where status = 'paid'  -- 3번 주문 빠짐
group by ordered_on    -- 날짜당 한 줄

10월 1일 줄은 1번과 2번 주문을 더한 30000 이 됩니다. 10월 2일 줄은 8000 입니다. 이제 회사의 「매출」은 이 파일 하나가 정합니다. 매출이 필요한 사람은 이 표를 읽고 직접 계산하지 않습니다.

이 파일은 애플리케이션 코드와 같은 대접을 받습니다. 버전 관리 도구인 Git 저장소에 올려 누가 언제 무엇을 바꿨는지 남깁니다. 고친 내용은 합치기 전에 검토를 청하는 요청인 풀 리퀘스트로 올립니다. 동료의 코드 리뷰를 거치면 매출 정의가 한 사람의 손에서 조용히 바뀌는 일이 줄어듭니다.

표에는 테스트도 붙습니다. order_id 가 비어 있지 않은지, 같은 값이 두 번 나오지 않는지를 확인하는 식입니다. 원본이 잘못 들어와 주문이 두 번 복사되면 이 테스트가 실패해 알려 줍니다. 틀린 매출이 대시보드에 뜨기 전에 잡으려는 장치입니다.

조회문을 고쳐 풀 리퀘스트를 올리면 테스트가 저절로 돌게 해 두기도 합니다. 코드가 바뀔 때마다 자동으로 빌드하고 검사하는 이 관행을 지속적 통합(CI, Continuous Integration)이라고 합니다.

표마다 어느 칸이 무슨 뜻인지 적은 문서도 같은 저장소에 둡니다. 분석가가 표를 읽다 막히면 이 문서를 찾아봅니다.

백엔드 개발과 맞닿는 곳

백엔드 개발자에게 이 직무의 일하는 모양은 낯설지 않습니다. 코드를 Git 에 올려 리뷰를 받습니다. 테스트를 돌린 뒤 배포합니다. 다른 점은 만들어 내는 것이 API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스)가 아니라 표라는 것입니다. 쓰는 사람도 바깥 고객이 아니라 회사 안의 분석가와 경영진입니다.

두 직무는 데이터로 이어져 있습니다. 애널리틱스 엔지니어가 다듬는 원본은 백엔드가 짠 서비스 데이터베이스의 복사본입니다. 백엔드에서 칸 이름을 바꾸거나 칸 하나를 지우면 그 칸을 읽던 분석용 표가 다음 갱신 때 깨집니다.

표의 칸 구성을 바꾸는 일을 스키마 변경이라고 합니다. 서비스 쪽 스키마 변경은 백엔드에게는 작은 정리여도 분석용 표에는 장애가 됩니다. 이 직무가 백엔드 팀에 변경을 미리 알려 달라고 청하는 까닭입니다.

따로 두는 때와 안 두는 때

모든 데이터 팀이 이 직무를 따로 두지는 않습니다. 분석가가 한두 명이고 보는 숫자가 적으면 분석가가 직접 표를 다듬어도 숫자가 갈릴 일이 드뭅니다. 데이터 엔지니어가 변환까지 맡는 팀도 있습니다.

따로 두는 쪽으로 기우는 신호는 숫자가 부딪히기 시작할 때입니다. 분석가와 대시보드가 늘어 같은 지표가 여러 곳에서 다르게 계산되면 정의를 한곳에 모을 사람이 필요해집니다. 원본이 바뀔 때마다 어디가 깨졌는지 찾느라 시간이 새는 것도 같은 신호입니다.

대가도 있습니다. 데이터와 질문 사이에 넘겨받는 단계가 하나 늘어납니다. 분석가가 새 숫자를 원하면 분석용 표가 고쳐질 때까지 기다려야 합니다. 이 기다림이 길어지면 분석가가 다시 원본을 직접 읽기 시작합니다. 그러면 숫자가 또 갈립니다.

관련 항목

애널리틱스 엔지니어와 일을 나누는 데이터 직군

데이터 엔지니어링 · 데이터 분석 · 데이터 분석가 · 데이터 과학자 · 비즈니스 인텔리전스

분석용 표가 놓이는 저장소

데이터 웨어하우스 · 데이터 마트 · 데이터 레이크 · 데이터 레이크하우스 · 스키마

원본을 분석용 표로 옮기고 바꾸는 방식

ETL · ELT · 오케스트레이션 · Apache Airflow · dbt · SQL

분석용 표를 설계하는 기법

데이터 모델링 · 차원 모델링 · 스타 스키마 · 팩트 테이블 · 차원 테이블 · 정규화

분석 코드에 들여온 개발 관행

버전관리 · Git · 코드 리뷰 · 풀 리퀘스트 · 단위 테스트 · 지속적 통합

분석용 표를 믿을 수 있게 지키는 수단

데이터 품질 · 데이터 계보 · 데이터 카탈로그 · 시맨틱 레이어 · 스키마 변경

분석용 표를 읽어 보여 주는 도구

대시보드 · 비즈니스 인텔리전스 · 지표 · 보고서