데이터 엔지니어 이력서 작성법 - 데이터가 제때, 정확하게 도착했다는 것을 숫자로 보여 줘야 합니다

여기서 말하는 데이터 엔지니어는 회사 안팎의 데이터를 모아 다른 사람이 쓸 수 있는 형태로 만들고, 그 데이터가 매일 제때 정확하게 들어오도록 시스템을 만들고 운영하는 엔지니어입니다. 수집·적재 파이프라인을 만드는 일, 데이터 웨어하우스와 마트를 설계하는 일, 이 모두가 돌아가는 데이터 플랫폼을 운영하는 일이 여기에 들어갑니다. 공고에서는 데이터 엔지니어, 데이터 플랫폼 엔지니어, 애널리틱스 엔지니어(Data Analytics Engineer)처럼 이름이 나뉘어 있습니다. 애널리틱스 엔지니어는 분석가와 가까이 일하지만 결과물은 분석가와 현업이 쓰는 마트와 지표 산출 로직이라서 이 글에서 함께 다룹니다. 이 직무의 경력을 Airflow 기반 ETL 파이프라인 구축, Kafka 실시간 파이프라인 운영, DW 마트 설계 같은 문장으로 적는 경우가 많습니다. 이런 문장은 어떤 도구로 어떤 일을 했는지 알려 줍니다. 그런데 담당자가 확인하려는 것은 그 파이프라인이 얼마나 많은 데이터를 얼마나 자주 옮겼는지, 데이터가 늦거나 틀린 날에 지원자가 무엇을 했는지, 그 데이터를 누가 어떤 기준으로 쓰게 됐는지입니다. 카카오페이의 데이터 엔지니어(데이터 플랫폼) 공고는 지원서 작성 팁에서 직접 설계하거나 운영한 파이프라인의 규모(처리량, 지연 등)와 본인이 맡은 역할을 구체적으로 적기를 권장했습니다. 파이프라인 장애나 성능 문제를 해결한 경험이 있다면 원인과 해결 과정, 결과를 함께 적으면 좋다고도 했습니다(2026년 10월 분석 기준).

데이터 분석가·사이언티스트·머신러닝·AI 엔지니어와 다른 점

데이터를 다루는 직무가 여럿이라 데이터 엔지니어의 경력 문장이 이웃 직무의 것처럼 보이기 쉽습니다. 회사마다 경계는 조금씩 다르지만 직무를 나누는 가장 분명한 기준은 결과물입니다.

• 데이터 분석가: 데이터로 사업의 질문에 답한 분석과 결론
• 데이터 사이언티스트: 예측·분류 모델이나 인과 추론처럼 통계적 방법으로 낸 결론
• 머신러닝 엔지니어: 서비스 안에서 돌아가는 모델과 그 시스템
• AI 엔지니어: LLM을 써서 만든 서비스 기능(RAG, 에이전트 등)
• 데이터 엔지니어: 위 직무와 현업이 가져다 쓰는 데이터를 제때 정확하게 공급하는 파이프라인과 플랫폼
  • 애널리틱스 엔지니어는 이 가운데 분석가와 현업이 함께 쓰는 마트와 지표 산출 로직을 맡습니다. 그 마트 위의 대시보드와 해석은 분석가의 결과물입니다.

그래서 데이터 엔지니어의 경력 문장에서 결과 자리에는 데이터가 어떻게 달라졌는지가 와야 합니다. 적재가 끝나는 시각, 데이터가 들어오기까지의 지연, 누락·중복 건수, 그 데이터를 쓰는 팀과 테이블의 수 같은 것입니다. 분석 결과로 매출이 늘었다거나 모델 정확도가 올랐다는 숫자는 그 데이터를 쓴 사람의 결과입니다. 함께 적을 수는 있지만 그것만 있으면 담당자는 지원자가 데이터 쪽에서 무엇을 바꿨는지 알 수 없습니다. 분석가와 머신러닝 엔지니어의 이력서에 무엇을 적는지는 데이터 분석가 이력서 작성법과 머신러닝 엔지니어 이력서 작성법에서 볼 수 있습니다.

얼마나 많은 데이터를 얼마나 자주 옮겼는지

같은 "파이프라인 운영"이어도 하루에 한 번 수십만 건을 옮기는 배치와 초당 수만 건을 받는 스트리밍은 다른 일입니다. 다루는 데이터의 양과 주기에 따라 도구도, 장애가 나는 방식도 달라집니다. 공고도 규모와 지연을 업무로 적었습니다. 카카오페이 공고는 수천만 사용자의 이벤트를 처리하는 실시간·배치 파이프라인을 설계하는 일과 스트리밍 처리 시스템의 지연·유실·중복 문제를 직접 찾아 개선하는 일을 업무로 꼽았습니다. 토스증권의 Data Engineer (Realtime) 공고는 더 높은 처리량과 낮은 지연 시간을 위해 아키텍처를 개선하는 일을 업무로 적었습니다. 레브잇의 [쇼포트] Product Engineer (Data)는 수천만에서 수억 건 규모의 데이터를 수집하고 처리하는 파이프라인을 만드는 자리입니다. 그래서 이력서에는 원천 시스템이 몇 개였는지, 하루 처리량(건수나 용량), 맡은 파이프라인과 테이블의 수를 적습니다. 배치라면 몇 시간 주기로 돌았고 몇 시까지 적재를 끝내야 했는지를, 스트리밍이라면 초당 이벤트 수와 이벤트가 발생해서 조회되기까지 걸린 시간을 씁니다. "주문·결제 DB의 테이블 12개를 CDC로 받아 변경이 생긴 뒤 p95 기준 1분 안에 분석 DB에서 조회되게 했습니다"처럼 쓰면 담당자가 지원자의 경험을 자기 회사의 데이터 규모와 바로 견줄 수 있습니다.

늦거나 틀린 데이터를 먼저 알아채는 체계

데이터 파이프라인은 실패해도 에러 없이 끝나는 경우가 있습니다. 작업은 성공으로 끝났는데 원천의 일부가 빠져 있거나 같은 데이터가 두 번 들어가 있으면 숫자가 이상하다는 현업의 문의가 와서야 문제를 알게 됩니다. 그래서 데이터 엔지니어의 운영 경험은 문제를 누가 먼저 알았는지로 드러납니다. 미리디의 Data Engineer 공고는 정합성·freshness·schema drift 지표를 모니터링해 데이터 문제를 소비 단계 이전에 탐지하는 일을 업무로 적었습니다. CJ올리브영의 Data Analytics Engineer 공고는 원천과 제공 데이터 사이의 정합성을 자동화된 방식으로 검증하고 신선도 SLA와 모니터링 체계를 관리하는 일을 업무로 꼽았습니다. 컬리의 시니어 데이터 엔지니어 공고의 Data Observability·품질 관리 업무에는 누락·중복·지연 감지가 들어 있습니다. 당근의 Data Analytics Engineer 공고는 단일 모델 수준이 아니라 파이프라인 전반에서 품질을 관리하고 정합성을 검증해 본 경험을 자격 요건으로 요구했습니다. 이력서에는 어떤 품질 규칙을 몇 개 만들었는지(건수 대조, 키 중복, 필수 값 누락 등), 어떤 도구로 자동화했는지(dbt tests, Great Expectations 등)를 적습니다. 테이블마다 몇 시까지 들어와야 한다는 신선도 기준을 정했다면 그 기준과 지킨 비율을 씁니다. 현업의 문의로 알던 문제를 알림으로 먼저 알게 바꿨다면 그 변화를 숫자로 적습니다. 한 분기 동안 발견한 데이터 이상 가운데 현업이 알려 오기 전에 알림으로 먼저 잡은 비율 같은 숫자입니다.

장애 뒤에 데이터를 어떻게 다시 채웠는지

데이터 장애는 파이프라인이 다시 돌아간 뒤에도 끝나지 않습니다. 그 사이에 빠지거나 두 번 들어간 데이터는 그대로 남고 그 데이터로 만든 하위 테이블과 리포트도 함께 틀립니다. 장애가 난 기간을 다시 돌려 채우는 일(backfill)과 같은 기간을 여러 번 다시 실행해도 결과가 같도록 만드는 설계(멱등성)가 이 직무의 장애 대응입니다. 토스의 Data Engineer (Global) 공고는 장애가 발생했을 때 근본 원인을 추적하고 backfill과 재발 방지까지 스스로 완결해 본 경험을 자격 요건으로 요구했습니다. 카카오페이 공고는 파이프라인 장애(지연, 유실, 중복)를 디버깅하고 해결한 경험을, 미리디 공고는 파이프라인 장애나 데이터 이상을 원인까지 추적해 해결해 본 경험을 자격 요건으로 요구했습니다. 메가존의 제조AX 데이터 엔지니어 공고는 원천 스키마가 예고 없이 바뀌어도 파이프라인이 중단되지 않도록 대응해 본 사람을 우대합니다. 장애 한 건을 적을 때는 영향 범위를 먼저 씁니다. 영향 범위는 어느 기간의 데이터가 몇 개 테이블에서 어떻게 틀렸는지, 그 데이터를 누가 쓰고 있었는지입니다. 그다음 원인, 다시 채운 방법과 걸린 시간, 같은 일이 생기지 않도록 바꾼 것을 적습니다. 틀린 테이블에 기대는 하위 마트를 몇 개 다시 돌렸는지, 그 순서를 어떻게 정했는지도 적습니다. 재처리를 날짜 단위로 덮어쓰도록 바꿨거나 원천 스키마가 바뀌면 적재 전에 알림이 오게 했다면 그 뒤 같은 원인의 장애가 몇 번 났는지까지 적을 수 있습니다. 백엔드 개발자의 장애 대응을 적는 방법은 백엔드 개발자 이력서 작성법에 있습니다. 데이터 엔지니어는 거기에 더해 데이터를 어떻게 바로잡았는지까지 적습니다.

테이블과 지표의 설계 기준

웨어하우스와 마트를 만드는 일은 테이블 수로는 잘 드러나지 않습니다. 담당자는 한 행이 무엇을 뜻하는지(grain)를 어떻게 정했는지, 부서마다 다르게 세던 숫자를 하나의 산출 로직으로 맞췄는지를 봅니다. 미리디 공고는 차원 모델링(grain, fact/dimension, SCD 등)을 바탕으로 데이터 웨어하우스나 마트를 설계해 본 경험을 자격 요건으로 요구했습니다. 오늘의집의 Data Analytics Engineer 공고는 주문부터 배송 완료까지 이어지는 물류 프로세스를 일관된 grain으로 연결하는 데이터 웨어하우스 모델을 설계하고, 리드타임·물류비 같은 물류 핵심 지표의 정의를 표준화하는 일을 업무로 적었습니다. CJ올리브영의 Data Analytics Engineer 공고와 토스뱅크의 Data Analytics Engineer 공고는 단순 요청 처리에 그치지 않고 데이터 구조와 활용 관점에서 기준을 제시할 수 있어야 한다고 적었습니다. 이력서에는 어떤 주제 영역을 어떤 grain으로 모델링했는지, 팀마다 다르게 계산하던 지표 몇 개를 하나의 산출 로직으로 모았는지, 그 마트를 몇 개 팀이 쓰는지를 적습니다. 요청이 올 때마다 쿼리를 새로 짜 주던 방식을 공통 마트로 바꿨다면 요청 건수나 처리 시간이 어떻게 달라졌는지도 씁니다. 여기서 데이터 엔지니어가 맡는 것은 현업·분석가와 합의한 지표 정의를 하나의 산출 로직으로 만들고 관리하는 일입니다. 그 지표가 왜 달라졌는지 해석하는 일은 분석가가 맡으므로 분석까지 했다면 따로 적습니다. 개인정보가 든 데이터를 다뤘다면 그것도 설계의 일부입니다. 미리디 공고는 개인정보 마스킹과 접근 제어를 관리하고 ISMS-P 요건에 맞는 데이터 환경을 운영하는 일을 업무로 적었습니다. 카카오뱅크의 데이터 엔지니어(Data Warehouse) 공고는 금융권에서 고객정보 파기 프로세스를 다뤄 본 경험을 우대합니다. 어떤 컬럼을 어떻게 가명처리하거나 마스킹했는지, 누가 어떤 데이터를 볼 수 있게 했는지, 보관 기한이 지난 데이터를 어떻게 파기했는지를 적을 수 있습니다.

도구를 고른 이유와 그 비용

데이터 엔지니어링 도구에는 같은 일을 할 수 있는 것이 여럿 있습니다. 배치로 충분한 일에 스트리밍을 쓰거나 작은 데이터를 큰 클러스터로 돌리면 비용과 운영 부담이 함께 커집니다. 그래서 담당자는 지원자가 무엇을 썼는지보다 왜 그것을 골랐는지를 봅니다. 컬리의 시니어 데이터 엔지니어 공고는 기술이 어떤 문제를 풀기 위해 나왔는지와 어디까지가 한계인지 이해하고, 도입할 때의 비용·복잡성·유지보수 부담까지 고민해 본 경험을 자격 요건으로 요구했습니다. 같은 공고는 프로젝트와 도메인별 데이터 비용을 보여 주는 Data FinOps 도구를 만드는 일도 업무로 적었습니다. 토스뱅크의 Data Analytics Engineer 공고는 분산 처리 기반 쿼리 엔진의 동작 원리를 이해하고 튜닝할 수 있어야 한다고 했고, Airflow 오케스트레이션을 최적화해 배치를 효율화한 경험을 자격 요건으로 요구했습니다. 도구를 바꾼 경험이 있다면 바꾸기 전의 문제, 검토한 선택지, 고른 이유, 바꾼 뒤의 숫자를 적습니다. 비용을 줄였다면 무엇을 바꿨는지가 함께 있어야 합니다. "BigQuery에서 조회가 많은 로그 테이블 3개를 날짜로 파티셔닝하고 대시보드 쿼리가 파티션 조건을 쓰도록 고쳐 월 스캔량을 약 1.2PB에서 300TB로 줄였습니다"처럼 쓰면 절감 폭과 방법이 함께 보입니다.

같은 경력을 이렇게 적으면

강한 문장에는 데이터의 양과 주기, 지원자가 바꾼 것, 그 결과 데이터가 어떻게 달라졌는지, 그 데이터를 누가 쓰는지가 들어 있습니다. 같은 도구를 썼더라도 강한 문장에서는 지원자가 데이터가 제때 정확하게 들어오는 것을 책임져 왔다는 점이 드러납니다.

자리에 따라 무게가 다르다

같은 데이터 엔지니어 공고여도 무게를 두는 곳은 다릅니다. 기업 채용 분석의 데이터 엔지니어 공고를 보면 크게 세 갈래가 있습니다. 첫째는 플랫폼과 인프라 쪽입니다. 토스의 Data Engineer (Global) 공고는 Kubernetes 환경에서 Terraform 같은 IaC 도구로 인프라를 구축·운영해 본 경험을 자격 요건으로 요구했고, 새 국가를 런칭할 때 데이터 인프라를 코드로 구축하는 일을 업무로 적었습니다. 컬리의 시니어 데이터 엔지니어 공고는 파이프라인을 돌리는 AWS·GCP 인프라를 운영하고 비용·안정성·확장성의 균형을 고려해 설계하는 일을 업무로 꼽았습니다. 둘째는 배치와 실시간 파이프라인을 만드는 쪽입니다. 당근의 Software Engineer, Data 공고는 배치와 스트리밍 데이터 처리 시스템을 설계하는 일을 업무로 적었습니다. 토스증권의 Data Engineer (Realtime)는 실시간 파이프라인을 만드는 일에 더해 Kafka 클러스터와 OLAP 운영 같은 플랫폼 쪽 일도 함께 맡는 자리입니다. 셋째는 웨어하우스와 마트, 지표를 설계하는 애널리틱스 엔지니어링 쪽입니다. 카카오의 Data Analytics Engineer 공고는 제품을 이해하고 활용 관점에서 마트를 디자인할 수 있어야 한다고 적었습니다. 이력서에는 경험을 갈래별로 나눠 적고, 지원하는 공고가 무게를 두는 갈래의 경험을 더 자세히 씁니다. 플랫폼 쪽이라면 운영한 클러스터(Spark, Trino, Kafka 등)의 규모, 그 위에서 도는 작업과 사용하는 팀의 수, 이전이나 업그레이드를 서비스 중단 없이 마친 경험을 적습니다. 산업 경험을 요구하는 공고도 있습니다. 현대오토에버의 Robot Data Engineer 공고는 로봇이나 스마트팩토리의 데이터 수집 경험을 자격 요건으로 요구했습니다. 딜로이트 컨설팅의 데이터 엔지니어 경력직 공고는 제조 산업군 프로젝트 수행 경험을 필수로 적었습니다. 토스뱅크의 Finance Data System Developer 공고는 금융권에서 관리회계나 ALM 시스템을 관리해 본 경험을 요구했습니다. 산업 경험은 "금융 도메인" 같은 말보다 다룬 데이터의 이름(여신·수신 거래, 주문·재고, 설비 센서 로그)으로 적어야 담당자가 바로 알아봅니다.

AI나 분석 업무를 함께 맡는 자리

데이터 엔지니어라는 이름의 공고가 AI 쪽 일을 함께 맡기기도 합니다. 여기서도 결과물로 나누면 두 종류가 됩니다. 하나는 AI 시스템이 쓸 데이터를 만드는 일입니다. 미리디 공고는 디자인 에셋용 비정형 데이터 레이크를 구축하는 일을 업무로 적었고, 이미지 같은 대용량 비정형 데이터를 AI/ML 학습과 분석에 쓸 수 있도록 데이터 레이크를 구축해 본 경험을 우대합니다. 메가존클라우드의 Data Engineer Junior 공고는 Feature Store, Vector Store 같은 AI용 데이터 기반을 만드는 일을 업무로 꼽았습니다. 여러 모델과 서비스가 함께 쓰는 저장소와 그 적재 파이프라인을 만드는 일은 데이터 엔지니어의 경력입니다. 특정 모델에 맞춰 피처를 정의하고 학습과 서빙의 피처를 맞추는 일은 머신러닝 엔지니어의 일에 가깝습니다. 다른 하나는 AI 기능 자체를 만드는 일입니다. 우아한형제들의 데이터엔지니어링(데이터서비스 AI) 공고는 데이터 파이프라인과 함께 AI Agent의 백엔드 개발, Agent 평가 데이터셋과 품질 지표 설계, LLMOps까지 업무로 꼽았습니다. 이 자리는 AI 엔지니어의 일까지 함께 맡습니다. 분석 쪽 일을 함께 맡는 자리도 있습니다. 넥슨코리아의 [슈터본부] 슈터플랫폼실 데이터 엔지니어 공고는 게임 데이터를 분석해 인사이트를 도출하는 일을 업무로 적었습니다. 이런 공고에 지원한다면 두 종류의 경험을 구분해 적습니다. 문서나 이미지를 몇 건씩 얼마나 자주 수집·파싱해 저장소에 반영했는지, 파싱에 실패한 비율이 얼마였는지는 데이터 엔지니어링의 숫자입니다. 청크를 어떻게 나누고 어떤 임베딩 모델을 쓸지처럼 검색 품질로 판단하는 결정, 에이전트 답변의 품질을 무엇으로 평가했는지, 분석으로 어떤 결론을 냈는지는 이웃 직무의 경험으로 따로 씁니다. 이렇게 구분해 두어야 지원자가 어느 범위까지 맡을 수 있는지 담당자가 판단할 수 있습니다.

운영 환경을 맡아 본 적이 없다면

학교나 개인 프로젝트로 파이프라인을 만들어 봤지만 실제 운영 환경은 맡아 본 적이 없는 분도 있습니다. 메가존클라우드의 Data Engineer Junior 공고는 신입부터 8년 미만까지를 대상으로 하고, 클라우드에서 데이터 수집·정제·적재를 해 본 실무 경험이 있거나 데이터 파이프라인 구축 과정을 이해하고 있어야 한다고 적었습니다. SQL, Python, Spark 같은 데이터 처리 기술을 쓴 프로젝트 경험도 자격 요건입니다. 이런 공고라면 운영 경험이 없어도 개인 프로젝트에서 아래와 같은 것을 만들어 적을 수 있습니다.

• 공개 API나 공개 데이터를 정해진 주기로 수집해 웨어하우스에 적재하고 변환까지 이어지게 만든 파이프라인(데이터 양과 한 번 실행하는 데 걸린 시간 포함)
• 같은 날짜를 여러 번 다시 실행해도 결과가 같게 만든 설계와 일부러 실패를 일으켜 그 기간을 다시 채운 기록
• dbt tests 같은 도구로 건수·중복·누락을 검사하는 규칙을 만들고 그 규칙으로 찾아낸 문제
• 같은 작업을 단일 노드와 Spark에서 각각 실행해 데이터 크기에 따라 처리 시간과 비용이 어떻게 달라지는지 비교한 결과
• 왜 그 도구와 구조를 골랐는지 적은 설계 문서

숫자를 적을 때는 데이터 크기와 장비 조건을 함께 밝힙니다. 조건이 없는 숫자는 비교할 수 없기 때문입니다. 하루 수 TB의 데이터나 현업이 매일 쓰는 데이터의 운영 경험은 개인 프로젝트로 대신할 수 없습니다. 그래도 운영에서 무엇을 재고 무엇을 지켜야 하는지 안다는 것은 보여 줄 수 있습니다. 백엔드 개발을 하다 데이터 엔지니어로 옮기려는 경우라면 백엔드 경력을 함께 인정하는 공고도 있습니다. 쿠팡의 Staff, Security Data Platform Engineer 공고는 데이터 엔지니어링 또는 백엔드 시스템 개발 경력 7년 이상을, 우아한형제들 공고는 데이터 엔지니어링 또는 백엔드 개발 경험 5년 이상을 자격 요건으로 적었습니다. 카카오페이 공고는 백엔드 서버 개발 경험을 우대합니다. 서비스 DB를 다루거나 배치 작업을 만든 경험이 있다면 다룬 데이터의 양과 주기, 그리고 정합성을 어떻게 지켰는지를 중심으로 다시 씁니다.

적재 시간과 장애 기록은 그날 남겨 둔다

파이프라인을 맡는 동안에는 위에 적은 숫자를 찾기 어렵지 않습니다. 적재 시간은 오케스트레이션 도구에, 품질 검사 결과와 알림은 모니터링 도구에, 장애 기록은 사내 문서에 남아 있습니다. 그런데 이 기록은 회사 계정으로만 볼 수 있어서 회사를 옮기면 다시 확인하기 어렵습니다. 이력서를 쓸 때쯤이면 기억에는 다룬 도구 이름과 "꽤 빨라졌다" 정도만 남고 이력서에도 그것만 적게 됩니다. 그래서 개선 작업이나 장애 대응 하나가 끝나는 날 결과를 개인 기록으로 남겨 두는 것이 좋습니다. 무엇을 바꿨는지, 적재 시간과 지연이 전후로 어떻게 달라졌는지, 장애라면 영향 범위와 다시 채우는 데 걸린 시간을 몇 줄로 적으면 됩니다. 회사의 코드나 데이터는 빼고 결과 숫자와 판단만 남깁니다. 회사 밖에 적어도 되는 숫자인지는 보안 규정에서 먼저 확인합니다. GridResume 커리어 기록에 이렇게 남겨 두면 이력서를 쓸 때 데이터의 양과 시간, 정확성이 들어간 문장을 바로 만들 수 있습니다.

정리하면

데이터 엔지니어 이력서에 들어가야 할 것은 다섯 가지입니다.

• 얼마나 많은 데이터를 어떤 주기와 지연으로 옮겼는지
• 늦거나 틀린 데이터를 어떤 규칙과 알림으로 먼저 알아챘는지
• 장애 뒤에 데이터를 어떻게 다시 채우고 재발을 막았는지
• 테이블과 지표를 어떤 기준으로 설계했고 누가 그것을 쓰는지
• 도구를 왜 골랐고 비용이 어떻게 달라졌는지

도구 이름만으로는 이력서가 기술 목록에 그칩니다. 결과 자리에 분석 결론이나 모델 성능 대신 데이터가 어떻게 달라졌는지를 적어야 데이터 엔지니어의 경력으로 보입니다.