[넥스트증권] Data Analytics Engineer 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 담당 제품·도메인(예: 금융 투자정보, 계정계·거래, 행동·그로스 등)의 주요 개념을 정의하고 누구나 신뢰하고 쓸 수 있는 의미 계층과 표준 데이터 모델을 설계합니다. 금융 투자정보는 금융 데이터 분석가가 정의한 의미·산출 기준과 Financial Data DE가 제공하는 마스터·분류체계·식별자를 참조해 모델링합니다.

  이렇게 볼 수 있어요

  Semantic Layer는 활성 고객이나 거래대금 같은 지표를 한 번만 정의하고 대시보드·SQL·AI가 모두 그 정의를 쓰게 하는 계층입니다. 테크본부장 인터뷰가 소개한 대화형 데이터 플랫폼(텍스트로 질문하면 SQL이나 리포트로 바뀌는 구조)에서는 정의가 없으면 AI가 테이블을 임의로 조인해 틀린 숫자를 낼 수 있으므로, 지표 정의를 코드로 관리해 여러 도구가 같은 숫자를 내게 한 경험이 이 업무의 중심입니다.

• 표준(Subject-Oriented) 마트와 소비(서비스·분석) 마트를 구분해 모델링하고 일·시간·준실시간 단위의 마트를 설계·운영합니다.

  이렇게 볼 수 있어요

  표준 마트는 고객·계좌·거래처럼 주제별로 한 번 정리한 공용 데이터이고, 소비 마트는 특정 화면이나 분석 목적에 맞게 다시 묶은 데이터입니다. 소비 마트가 표준 마트를 거치지 않고 원천을 직접 읽기 시작하면 같은 지표가 마트마다 달라지므로, 두 층의 경계를 정하고 그 규칙을 지키게 한 방법이 이 업무의 핵심입니다.

• 제품 개발 시점부터 서버·프로덕트 엔지니어와 데이터 모델을 리뷰하고 분석·서빙 관점에서 필요한 스키마·이벤트·식별자를 제안합니다.

  이렇게 볼 수 있어요

  신규 MTS 출시 전이라 지금 서비스 DB와 이벤트 스키마를 설계하는 시기이고, 이때 분석에 필요한 식별자나 상태 이력이 빠지면 나중에 되살리기 어렵습니다. 개발 단계에서 스키마 리뷰에 참여해 이력 테이블이나 이벤트 필드를 추가하게 만든 경험이 있다면 무엇을 요청했고 그 뒤 어떤 분석이 가능해졌는지를 함께 적는 게 좋습니다.

• 빠른 제품 속도에서도 담당 도메인 데이터가 일관되게 제공되도록 처리 로직·품질 규칙·갱신 주기(SLA)·정확도 기준을 정의하고 Platform이 제공하는 공통 품질 게이트에 적용해 시스템화합니다.

  이렇게 볼 수 있어요

  공통 품질 게이트와 운영 도구는 같은 회사 Data Engineer (Data Platform) 공고가 맡으므로, 이 공고가 정하는 것은 그 게이트가 검사할 규칙입니다. 거래 금액 합계가 원장과 맞는지, 휴장일에 시세가 들어오지 않았는지처럼 도메인 지식으로 품질 규칙을 만들어 본 사례가 이 업무에 가장 가깝습니다.

• 원천 리뷰·변경 모니터링부터 생성·활용까지의 End-to-End 추적과, 사람이 읽고 LLM이 이해할 수준의 메타·문서화까지 담당 도메인의 거버넌스를 구축·운영합니다.

  이렇게 볼 수 있어요

  LLM이 이해할 수준의 문서화라면 컬럼 설명에 약어 대신 값의 단위, 기준 시점, 포함·제외 조건까지 담아야 합니다. 원천 변경 모니터링은 서비스 DB 스키마가 바뀌었을 때 하류 마트가 깨지기 전에 알아차리는 장치라, 스키마 변경 감지나 리니지로 영향 범위를 찾아 대응한 경험을 꺼낼 수 있습니다.

• DQ·SLA·Compliance 기준을 마트 단위로 관리하고 금융 데이터 특성에 맞는 보안성·라이선스·접근 통제를 반영합니다.

  이렇게 볼 수 있어요

  금융 데이터에는 고객 개인정보·계좌 정보처럼 접근을 제한해야 하는 데이터와, 시세·기업정보처럼 데이터 벤더 계약에 따라 재배포 범위가 정해진 데이터가 섞여 있습니다. 법무·컴플라이언스가 세운 벤더 데이터 사용 기준을 데이터 요구사항에 반영하는 일은 같은 회사 금융 데이터 분석가 공고에 적혀 있고, 이 공고는 그 기준을 마트 단위로 관리합니다. 마트마다 라이선스 범위를 표시하고 접근을 나눠 본 경험이 이 업무에 쓰입니다.

• 표준화된 모델링을 바탕으로 분석뿐 아니라 서비스에서도 쓸 수 있는 Databricks 기반 마트 변환 파이프라인을 운영합니다(배치 중심, 필요하면 준실시간). 원천 수집·표준화 파이프라인은 Financial Data DE가 맡고 DAE는 표준화 계층 이후의 변환을 책임집니다.

  이렇게 볼 수 있어요

  서비스 화면이나 AI 기능이 마트를 읽으면 갱신이 늦거나 값이 틀린 것이 곧 고객 화면 문제로 번집니다. 마트 갱신 지연을 알림으로 잡고 서비스 쪽과 갱신 시각을 합의해 본 경험은 분석용 마트만 운영해 본 경력과 다른 점이라 따로 적을 만합니다.

• 전략·프로덕트·AI/ML·서비스 조직의 요구를 받아 단순히 이행하지 않고 효율적인 데이터 구조와 활용 기준을 제안·조율합니다. 투자정보 요구사항은 금융 데이터 분석가가 데이터 명세로 구체화하고 DAE는 그 명세를 마트 구조로 설계합니다.

  이렇게 볼 수 있어요

  같은 회사 금융 데이터 분석가 공고는 투자정보 요구사항을 데이터 항목, 산출 기준, 제공 주기, 이력 관리와 품질 기준으로 구체화한다고 적어, 투자정보 요청은 명세 형태로 DAE에게 넘어옵니다. 명세를 그대로 새 테이블로 옮기기 전에 기존 표준 마트로 답할 수 있는지 먼저 확인하는 것이 이 조율의 첫 단계입니다. 비슷한 요청을 묶어 하나의 마트나 지표 정의로 정리해 요청 건수를 줄인 경험이 이 역할을 가장 직접 보여 줍니다.

2자격 요건

• 데이터 엔지니어, Data Analytics Engineer 또는 DW 모델러 경력이 5년 이상이어야 합니다.

  이렇게 볼 수 있어요

  같은 AI데이터플랫폼팀 이름이 붙은 Data Engineer (Data Platform) 공고는 데이터 엔지니어·플랫폼 엔지니어 경력을, 금융 데이터 분석가 공고는 금융 투자정보 분석 경력을 요구해 세 공고가 경력 축에서도 나뉩니다. 이 공고에 DW 모델러라는 직함이 함께 적힌 것은 중심이 파이프라인보다 개념 정의와 마트 설계에 있다는 표시입니다. 5년 가운데 데이터 모델을 설계하고 지표 정의를 정한 프로젝트를 자세히 쓰면 이 공고와 이어집니다. 데이터 엔지니어, Data Analytics Engineer, DW 모델러 경력은 이 조건에 함께 적을 수 있고, 분석가로 일하며 마트를 직접 설계했다면 그 부분도 드러내면 됩니다.

• DW 데이터 모델러로서 담당 제품·도메인의 개념을 정의하고 명확한 데이터 구조를 설계할 수 있어야 합니다.

  이렇게 볼 수 있어요

  개념 정의는 고객을 계좌 기준으로 볼지 사람 기준으로 볼지, 해지 고객을 언제까지 포함할지처럼 업무 규칙을 정하는 일입니다. 증권 데이터에서는 한 사람이 계좌를 여럿 가질 수 있어 이런 정의가 지표 숫자를 크게 바꾸므로, 정의를 놓고 현업과 합의해 문서로 남긴 사례가 이 요건에 맞습니다.

• Database 정규화와 Data Warehouse 특성(Subject-Oriented, Integrated, Non-Volatile, Time-Variant)을 이해해야 합니다.

  이렇게 볼 수 있어요

  Subject-Oriented, Integrated, Non-Volatile, Time-Variant는 빌 인먼(Bill Inmon)이 정의한 데이터 웨어하우스의 네 가지 특성입니다. 특히 Non-Volatile과 Time-Variant는 과거 데이터를 덮어쓰지 않고 시점별로 남기는 것이라, 계좌 상태나 종목 정보 변경을 이력 테이블(SCD Type 2 등)로 설계해 본 경험이 이 요건을 실제 일로 보여 줍니다.

• 표준 영역 마트와 소비 영역 마트를 구분해 설계·운영해 봤어야 합니다.

  이렇게 볼 수 있어요

  dbt의 staging·intermediate·marts 층은 이 공고의 표준 마트·소비 마트와 비슷하게 역할을 나눠 맡으므로, dbt를 썼다면 각 층을 이 공고의 마트 이름에 맞춰 설명할 수 있습니다. 층마다 누가 무엇을 바꿀 수 있는지 규칙을 정해 본 경험은 설계를 넘어 운영 경험에 속합니다.

• 'SQL 활용 능력이 뛰어나고' 효율과 가독성을 갖춘 쿼리를 작성할 수 있어야 합니다.

  이렇게 볼 수 있어요

  마트 정의로 남는 쿼리는 다른 사람과 AI가 다시 읽으므로 이 공고에서는 가독성도 효율만큼 무게가 있습니다. 파티션 프루닝이나 조인 순서를 바꿔 비용을 줄인 사례, 공통 테이블 식(CTE)으로 긴 쿼리를 읽기 쉽게 나눈 사례처럼 효율과 가독성을 각각 보여 주는 사례가 따로 있어야 요건의 두 부분이 다 드러납니다.

• 대용량 처리 환경에서 파이프라인·마트를 다뤄 봤어야 합니다.

  이렇게 볼 수 있어요

  증권사의 체결·시세 데이터는 하루에도 행이 크게 늘고 이력 마트는 시간이 지날수록 커집니다. 바뀐 부분만 다시 계산하는 증분 처리로 마트 갱신 시간을 줄인 경험이라면 처리 규모와 단축 시간을 함께 적으면 됩니다.

• 데이터 표준·품질(정합성·완전성·적시성) 문제를 발견하고 근본 원인을 분석·개선해 봤어야 합니다.

  이렇게 볼 수 있어요

  금융 데이터의 품질 문제는 원천에서 시작되는 경우가 많습니다. 벤더 데이터 정정과 상장폐지·합병·분할에 따른 식별자 변경은 같은 회사 금융 데이터 분석가 공고가 다루는 일이라, 마트 숫자가 어긋나면 벤더 정정 이력이나 식별자 매핑까지 거슬러 올라가야 할 때가 있습니다. 숫자가 틀렸다는 현업 문의에서 출발해 원천 시스템의 변경이나 로직 오류까지 추적해 고치고, 같은 문제가 다시 나지 않게 품질 규칙으로 만든 사례를 하나로 이어서 적으면 요건의 원인 분석과 개선이 함께 드러납니다.

• 데이터 엔지니어·서버 개발자·분석/서비스 조직과 효율적으로 커뮤니케이션하며 기준을 제시할 수 있어야 합니다.

  이렇게 볼 수 있어요

  테크본부장 인터뷰는 엔지니어가 문제 정의와 목표·비목표를 담은 테크 스펙 문서를 쓰고 서로 리뷰한다고 소개했습니다. 기준을 제시하는 일도 그 방식대로 문서와 리뷰를 거칠 가능성이 큽니다. 서버 개발자와는 개발 단계 데이터 모델 리뷰에서 스키마와 이벤트 설계를, 분석·서비스 조직과는 지표 정의를 맞춰야 하므로 같은 기준을 상대마다 다른 말로 전달해야 합니다. 개발 팀에 데이터 요구를 받아들이게 하거나 현업 요청을 다른 구조로 바꾸자고 설득한 경험이 있다면 상대가 누구였고 무엇을 근거로 설득했는지까지 적는 게 좋습니다.

3우대 사항

• 증권·은행·핀테크 등 금융 도메인에서 DW/레이크하우스를 구축·운영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  증권 데이터에는 영업일·휴장일, 결제일(국내 주식 T+2), 기업행사에 따른 가격·수량 조정처럼 다른 산업에 없는 시간 규칙이 많습니다. 금융권 DW 경험이 있다면 이런 규칙을 모델에 어떻게 담았는지를, 다른 산업 출신이라면 정산 주기나 회계 마감처럼 비슷한 시간 규칙을 다뤄 본 경험을 꺼낼 수 있습니다.

• Databricks(Delta Lake, Unity Catalog, Jobs, Databricks SQL) 운영 경험과 dbt 등 변환 프레임워크 또는 Great Expectations 등 품질 도구 활용 경험을 우대합니다.

  이렇게 볼 수 있어요

  Snowflake·BigQuery 같은 다른 웨어하우스 경험만 있다면 Delta Lake의 MERGE나 Unity Catalog 권한 모델처럼 Databricks에서 달라지는 부분을 미리 익혀 가는 편이 낫습니다. dbt와 Great Expectations는 변환과 품질 검사를 각각 코드로 관리하는 도구라, 둘을 함께 써 마트마다 테스트를 붙여 봤다면 업무에 적힌 품질 규칙 시스템화를 이미 코드로 다뤄 본 것입니다.

• 원천 스키마 리뷰부터 마트·서빙까지 End-to-End 오너십을 가져 본 경험과, 메타데이터·리니지·문서화로 Semantic Layer나 데이터 카탈로그를 운영해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  이 우대에서 중요한 것은 원천 스키마 리뷰부터 서빙까지 맡으며 상류의 변경이 하류 지표에 어떻게 번지는지를 리니지로 보여 줄 수 있는지입니다. 카탈로그 운영은 Unity Catalog나 DataHub에 설명과 소유자를 채우는 데서 끝나지 않고 실제로 검색되고 쓰이게 만드는 데까지 갑니다.

• DQ·SLA·컴플라이언스 기준을 정의하고 자동화한 경험을 우대합니다.

  이렇게 볼 수 있어요

  기준을 자동화했다면 사람이 점검하던 항목을 파이프라인 실패나 알림으로 바꾼 것이므로, 자동화 전후로 문제를 발견한 시점이 얼마나 당겨졌는지로 효과를 보여 줄 수 있습니다. 컴플라이언스 기준은 개인정보 컬럼 마스킹이나 벤더 데이터 재배포 제한처럼 금융 데이터에서 실제로 문제가 되는 항목입니다.

• AARRR 등 제품·그로스 지표 프레임워크에 대한 기본 이해가 있는 분을 우대합니다.

  이렇게 볼 수 있어요

  같은 회사 Growth Marketing Manager 공고는 유입부터 계좌 개설, 첫 거래, 리텐션까지의 퍼널을 정의한다고 적었습니다. 증권 서비스에서는 활성화를 앱 실행이 아니라 첫 거래처럼 돈이 오가는 행동으로 정의할 수 있어, 그런 지표 정의를 마트로 만들어 본 경험이 이 우대와 가깝습니다.

• AI 코딩 에이전트(Claude Code, Codex, Cursor 등)를 활용한 Agentic Engineering 경험 또는 관심이 있는 분을 우대합니다.

  이렇게 볼 수 있어요

  업무의 문서화 목표가 LLM이 이해할 수준이라, 에이전트를 코드 작성에만 쓴 경험보다 에이전트에게 테이블 설명과 지표 정의를 주고 SQL을 맞게 쓰는지 확인해 본 경험이 이 공고와 직접 이어집니다. 2026년 4월 사내 테크 컨퍼런스 NEXT BUILDER에서도 Claude Code 기반 에이전트 활용기가 발표됐습니다.

4기타 사항

• 게시일 : 2026년 9월 22일
• 고용형태 : 정규직
• 근무지 : 서울특별시 강남구 강남대로 464 비제바노빌딩 3-6층
• 경력 조건 : 경력 5년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• SQL
• Databricks
• Delta Lake
• Unity Catalog
• Databricks SQL
• dbt
• Great Expectations
• Claude Code
• Codex
• Cursor

전형과 지원

채용 사이트 How We Hire가 밝힌 기본 절차는 서류 접수, 1차 인터뷰, 2차 인터뷰, 처우 협의, 최종 합격의 다섯 단계입니다. 개발·디자인 공고 상당수는 1차 인터뷰 앞에 AI 스크리닝을 더하므로 공고마다 전형 문단을 확인해야 합니다.

지원 전 준비할 것

1. 1

   지표 정의 문서 하나 꺼내기

   직접 정의한 지표나 개념(활성 고객, 매출 인식 기준 등)의 정의 문서를 골라 왜 그렇게 정했고 누구와 합의했는지 설명할 수 있게 정리합니다.

2. 2

   표준·소비 마트 구조 그려 보기

   운영했던 데이터 모델을 원천, 표준, 소비 층으로 나눠 그려 보면 이 공고의 마트 구분과 내 경험이 어떻게 대응되는지 인터뷰에서 바로 설명할 수 있습니다.

3. 3

   증권 데이터 개념 익히기

   금융 경험이 없다면 계좌·주문·체결·잔고·영업일 같은 기본 개념과 각각의 기준 시점을 정리하면 계정계·거래 도메인 질문에 대비할 수 있습니다.