스킬 평가

데이터 엔지니어 스킬 평가

데이터 엔지니어의 이력서는 어떤 도구를 다뤄 봤는지 알려 줄 뿐, 웨어하우스에 도착하는 숫자가 정확한지는 알려 주지 않습니다. 동일한 기술 스택을 나열한 두 지원자라도 그레인(grain), 멱등성(idempotency), 그리고 잘못된 값이 어디서 유입될 수 있는지를 추론하는 방식에서는 엄청난 차이를 보일 수 있습니다. 역량이 부족한 데이터 엔지니어는 조용히 실패합니다. 야간 잡이 재시도 시 중복 집계를 발생시키고, 지표가 조금씩 틀어지고, 결국 분석가들은 숫자를 신뢰하지 않게 됩니다. 키워드와 출신 학교로 스크리닝하면 바로 이런 문제를 방지하는 판단력을 놓치게 됩니다.

목표는 화이트보드 SQL 퍼즐이 아닙니다. 실제 업무의 직무 관련 샘플 — 불일치하는 두 소스를 조정하고, 지저분한 데이터셋에서 데이터 품질 함정을 찾아내고, 재처리된 배치에서도 살아남아야 하는 파이프라인을 추론하는 것 — 이어야 합니다. H-Evaluate는 귀사의 채용 공고에서 직접 이 평가를 생성합니다. 직무별 생성 방식이므로 어떤 지원자도 질문을 미리 연습할 수 없으며, 모든 지원자를 동일한 루브릭으로 채점합니다.

무엇을 평가할까

이 직무의 성과를 예측하는 역량을 다섯 가지 채용 기둥에 매핑했습니다.

실무 / 샌드박스

실제 환경에서의 파이프라인 작업 및 쿼리

문법에 관한 추상적인 상식을 묻는 것이 아니라, 실제 파이프라인을 설계 또는 디버깅하고 지저분한 데이터셋에 SQL을 작성하는 것 — 조인, 필터링, 멱등성 추론을 포함하여.

도메인 지식

데이터 모델링 및 SQL 깊이

유창하고 관용적인 SQL과 모델링 판단력 — 언제 정규화하고 언제 비정규화할지, 요구사항이 변해도 그레인에 대해 정직함을 유지하는 스키마를 어떻게 설계할지.

인지

데이터 품질 추론

결과를 신뢰하기 전에 '이것이 틀렸다면 어떻게 알 수 있을까?'를 먼저 묻는 반사적 본능 — 중복 키, 타임존 차이, 조용한 드리프트를 포착하고, 숫자에서 출처까지 리니지를 추론하는 것.

상황 판단

모호한 상황에서의 판단력

현실적인 시나리오에서 지원자가 어떻게 대응하는지 — 야간에 조용히 떨어진 지표, 히스토리를 오염시키지 않아야 하는 백필, 리니지를 깨는 지름길을 원하는 이해관계자.

행동

데이터 소비자와의 협업

트레이드오프를 어떻게 설명하고, 모르는 것을 어떻게 인정하며, 자신이 제공하는 데이터에 의존하고 잘못 모델링된 스키마를 오용할 수 있는 분석가 및 데이터 사이언티스트와 어떻게 협력하는지.

실무 / 샌드박스

AI 활용 능력

AI 어시스턴트를 활용해 변환 로직과 SQL을 초안으로 작성하되, 그 출력을 반드시 검증하는 것 — 웨어하우스에 도달하기 전에 조용히 중복 집계를 발생시키는 그럴듯하지만 틀린 쿼리를 포착하는 것.

평가 구성 방법

  • 1화이트보드 SQL 퍼즐 대신, 역할에 특화된 업무 샘플 — 불일치하는 두 소스를 조정하거나 미묘하게 잘못된 숫자를 출력하는 파이프라인을 디버깅하는 것 — 을 우선하세요.
  • 2샘플에 데이터 품질 함정을 의도적으로 심어 두세요. 재시도 후 발생하는 중복 키, 타임존 차이, 조용히 변경된 열거형 값 등을 넣고, 누가 이를 자발적으로 찾아내는지 확인하세요.
  • 3난이도와 가중치를 채용 레벨에 맞게 조정하세요. 그린필드 웨어하우스 구축과 성숙한 플랫폼 유지는 다른 채용입니다.
  • 4AI 어시스턴트를 포함해 지원자가 실무에서 사용할 도구에 접근할 수 있게 하고, 출력을 검증하는지 평가하세요.
  • 5그레인, 리니지, 품질 추론이 비교되도록 모든 지원자를 동일한 루브릭으로 채점하세요 — 최종 쿼리가 실행되는지 여부만 보는 것이 아니라.

성공을 예측하는 신호

  • +신뢰하기 전에 데이터를 먼저 확인한다 — 자발적으로 건수, 널 값, 그레인을 체크한다
  • +멱등성과 재시도 또는 백필 시 발생할 수 있는 상황에 대해 소리 내어 추론한다
  • +숫자를 끝에서 끝까지 추적하고 왜 신뢰할 수 있는지 설명할 수 있다
  • +AI 도구를 활용하되 SQL을 직접 검증하며, 출력이 왜 틀렸는지 정확히 말할 수 있다

주의할 위험 신호

  • 데이터나 AI 출력을 그대로 받아들이고 바로 쿼리 작성에 뛰어든다
  • 파이프라인을 단순 스크립트로 취급한다 — 재실행, 테스트, 롤백에 대한 고려가 없다
  • 도구를 유창하게 나열하지만 그레인이나 리니지에 대해 추론하지 못한다
  • 조용한 중복 집계가 있는 쿼리를 자신 있게 배포하고 전혀 알아채지 못한다

평가 대 면접

면접은 과거 파이프라인에 대한 자신감 있는 서술에 보상을 주지만, 실제로 결과를 신뢰하기 전에 데이터셋을 들여다보는지는 거의 드러나지 않습니다. 업무 샘플은 그것을 직접 보여 줍니다 — 데이터 품질 함정을 찾아내는지, 아니면 그냥 지나치는지를 직접 볼 수 있습니다. 평가를 통해 그 증거를 수집하고, 면접은 샘플로 쉽게 드러나지 않는 것에 활용하세요. 트레이드오프를 어떻게 추론하는지, 틀렸을 때 어떻게 대처하는지, 그리고 자신이 제공하는 데이터에 의존하는 분석가들과 어떻게 협력하는지.

스킬 평가

직무와 직급에 따라 이 평가를 구성하세요

직무와 레벨을 바꾸면 강조점이 실시간으로 이동합니다 — 가입 불필요.

관련 읽을거리

자주 묻는 질문

데이터 엔지니어를 어떻게 평가하나요?

실제 업무를 부여하세요. 파이프라인을 설계 또는 디버깅하고, 지저분한 데이터셋을 모델링하거나, 데이터 품질 함정을 찾아내는 역할에 특화된 샘플입니다. 최종 답이 맞는지뿐만 아니라 스키마, 멱등성, 엣지 케이스를 어떻게 추론하는지를 지켜보세요. 불일치하는 두 소스를 조정하는 것은 화이트보드 SQL 퍼즐이나 키워드로 매칭된 이력서보다 훨씬 더 많은 것을 알려 줍니다.

데이터 엔지니어 테스트에서 어떤 역량을 다뤄야 하나요?

유창한 SQL과 진정한 소프트웨어 엔지니어링 규율이 우선이며, 그 다음은 데이터 모델링, 파이프라인 안정성 및 멱등성, 그리고 데이터 품질에 대한 거의 집착에 가까운 본능입니다. 리니지 추론에 높은 가중치를 두세요 — 숫자가 어디서 왔고 왜 신뢰할 수 있는지 말할 수 있는 사람. Spark, dbt, Airflow 같은 도구 친숙도는 상대적으로 덜 중요하며, 실무에서 배울 수 있습니다.

데이터 엔지니어를 채용하는 데 SQL 테스트만으로 충분한가요?

아닙니다. SQL 유창성은 필요하지만 충분하지 않습니다. 더 어렵고 예측력이 높은 역량은 데이터 품질 판단력입니다. 재시도 후 발생하는 중복 키를 알아채고, 드리프트된 지표에 의문을 품고, 그레인에 대해 추론하는 것입니다. 두 가지 모두 평가하고, 지원자가 쿼리를 실행하기 전에 데이터를 먼저 검증하는지를 채점하세요.

데이터 엔지니어가 AI를 잘 활용하는지 어떻게 테스트하나요?

AI 어시스턴트를 실제로 사용할 수 있는 환경에서 평가를 진행하고, 지원자가 어떻게 활용하는지 지켜보세요. 위험은 AI를 사용한다는 것이 아니라, 무비판적으로 신뢰하고 조용히 중복 집계를 발생시키는 그럴듯해 보이는 쿼리를 그대로 배포하는 것입니다. 분별력을 채점하세요. 잘못된 출력을 웨어하우스에 도달하기 전에 포착할 수 있는지 여부입니다.