[넥스트증권] 금융 데이터 분석가(Financial Data Analyst) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 금융 투자정보 분석: 종목·시세·지수·기업정보·재무제표·컨센서스·기업행사 등 투자정보의 구조와 의미를 분석하고, 금융상품·거래소·시장·통화·거래 캘린더 등 기준정보와 데이터 필드별 산출 기준, 제공 주기, 정정·재처리 정책을 정의합니다.

  이렇게 볼 수 있어요

  필드마다 정정·재처리 정책을 정한다는 것은, 예를 들어 재무 데이터가 잠정 실적에서 확정 실적으로 바뀌거나 벤더가 과거 값을 정정했을 때 사내 데이터를 덮어쓸지 이력으로 남길지를 미리 정한다는 뜻입니다. 거래 캘린더도 시장마다 휴장일과 거래 시간이 달라 해외 종목 시세의 날짜 기준을 정하는 데 필요합니다. 덮어쓰기와 이력 보존 가운데 무엇을 택할지는 이 업무에서 데이터마다 다시 내릴 판단이므로, 이런 정책을 문서로 정해 본 경험이 있다면 어떤 데이터에서 무엇을 택했는지 그 기준을 함께 적습니다.

• 데이터 벤더 연계 및 표준화: LSEG 등 외부 벤더의 데이터 명세와 전달 방식을 분석해 벤더별 데이터 모델과 식별자 체계를 사내 표준 데이터 모델로 매핑하고, 벤더 데이터의 도입·변경·종료가 내부 시스템에 미치는 영향 분석과 복수 벤더 간 값 차이의 적용 기준 수립을 담당합니다.

  이렇게 볼 수 있어요

  LSEG는 옛 Refinitiv의 데이터 사업을 이어받은 금융 데이터 벤더이고 RIC가 그 식별자 체계입니다. 복수 벤더 간 값 차이의 기준을 정한다는 업무와 우대 사항의 복수 벤더 비교·통합·전환 경험은 회사가 벤더를 둘 이상 쓰거나 바꿀 수 있는 상황을 전제로 합니다. 같은 종목의 종가나 재무 수치가 벤더마다 다를 때 어느 쪽을 언제 쓸지 정한 경험은 이 업무를 그대로 해 본 것입니다.

• 종목 및 식별자 기준 정의: 티커, ISIN, RIC 등 종목 식별자 간 매핑 규칙을 정의·검증하고 상장·상장폐지·합병·분할 등 기업행사에 따른 식별자 이력 관리 기준을 정의해 동일 종목·금융상품·발행기관을 일관되게 식별하는 기준을 마련합니다. 매핑의 구축과 운영은 Financial Data DE가 맡습니다.

  이렇게 볼 수 있어요

  티커는 바뀌거나 다른 회사에 다시 쓰일 수 있고, ISIN은 증권 단위, RIC는 거래소별 상장 단위라 한 회사에 여러 식별자가 걸립니다. 코어트레이딩플랫폼팀의 Backend Engineer(계좌·종목/상품) 공고가 종목·상품 마스터를 설계해 서비스에 기준정보를 제공하므로, 이 공고가 정한 식별자 기준은 실제 거래 화면의 종목 정보까지 영향을 줍니다.

• 금융 분류 기준 정의: 섹터·산업·테마·기업행사 유형 등 금융 데이터의 분류 기준을 정의하고 벤더 분류체계를 사내 분류에 대응시키는 기준을 정합니다. 분류체계(taxonomy) 모델의 설계와 버전 관리는 Financial Data DE가 맡습니다.

  이렇게 볼 수 있어요

  벤더의 업종 분류(LSEG의 TRBC, MSCI·S&P의 GICS 등)는 체계마다 다르고 한국 투자자에게 익숙한 테마와도 다르기 때문에, 벤더 분류를 사내 섹터·테마에 대응시키는 기준이 필요합니다. AI서비스개발팀 ML엔지니어(NLP·LLM) 공고가 뉴스·공시의 엔티티를 금융 온톨로지의 종목·기업·섹터·테마와 연결한다고 적어, 이 공고의 분류 기준이 AI 검색과 콘텐츠의 기준으로도 쓰일 수 있습니다.

• SQL 기반 데이터 품질 검증: SQL로 대용량 투자정보를 탐색해 누락·중복·이상값·식별자 매핑 오류를 탐지하고, 가격 조정·통화 환산·시점 기준 등 주요 가공 규칙의 정확성과 원천-가공 데이터 간 정합성·완전성·적시성을 검증합니다.

  이렇게 볼 수 있어요

  가격 조정은 액면분할·배당 같은 기업행사 뒤 과거 가격을 같은 기준으로 맞추는 일이고, 통화 환산과 시점 기준은 해외 종목 시세를 원화로 보여 줄 때 어느 시각의 환율을 쓰느냐의 문제입니다. 이런 규칙이 원천과 가공 데이터에서 맞는지 SQL로 대조해 오류를 잡아낸 사례는 건수나 오류율을 붙이면 설득력이 커집니다.

• 데이터 요구사항 및 모델 정의: 서비스·리서치·AI/ML 조직의 투자정보 요구사항을 데이터 항목, 산출 기준, 제공 주기, 이력 관리와 품질 기준으로 구체화하고, Financial Data DE·DAE와 협업해 레이크하우스의 데이터 모델과 파이프라인을 검증합니다. 구체화한 명세를 마트 구조로 설계하는 일은 DAE가 맡습니다.

  이렇게 볼 수 있어요

  요구사항을 내는 조직이 서비스, 리서치, AI/ML로 셋이라 같은 데이터에도 화면용, 분석용, 모델 학습용 요구가 다르게 들어옵니다. Data Analytics Engineer 공고는 금융 데이터 분석가가 구체화한 명세를 DAE가 마트 구조로 설계한다고 적어, 이 공고의 결과물은 다른 엔지니어가 그대로 구현할 수 있는 명세여야 합니다.

• 데이터 거버넌스 및 라이선스 정책 적용: 투자정보의 정의·오너십·메타데이터·데이터 계보 관리에 참여하고, 법무·컴플라이언스가 수립한 벤더 데이터 사용 기준을 데이터 요구사항에 반영하며 준수 여부를 검증합니다.

  이렇게 볼 수 있어요

  금융 데이터 벤더 계약은 보통 내부 사용, 화면 표시, 외부 재배포를 다른 조건으로 허락해, 같은 시세라도 MTS 화면이나 AI가 만든 콘텐츠에 쓰면 별도 권한이 필요할 수 있습니다. 라이선스 조건을 데이터 항목별 접근 규칙으로 바꿔 본 경험이 있다면 이 업무에서 특히 쓰입니다.

2자격 요건

• 5년 이상의 금융 투자정보 분석이나 금융 데이터 관련 실무 경험이 필요합니다.

  이렇게 볼 수 있어요

  증권 업계에서 투자정보 데이터는 리서치센터, 정보계(DW) 조직, 데이터 벤더의 콘텐츠 운영 조직이 나눠 다뤄 온 경우가 많아, 같은 5년이라도 데이터를 쓰는 쪽과 만드는 쪽의 경험이 섞여 있기 쉽습니다. 금융 투자정보 분석 경력과 금융 데이터 실무 경력은 이 조건에 함께 적을 수 있고, 이 공고의 업무가 산출 기준과 매핑 규칙을 정의하는 쪽이므로 5년 가운데 데이터의 정의나 매핑 기준을 직접 정했던 프로젝트를 자세히 보여 주면 업무와 이어집니다.

• LSEG나 유사 금융 데이터 벤더가 제공하는 투자정보를 실무에서 활용해 봤어야 합니다.

  이렇게 볼 수 있어요

  LSEG 외에 Bloomberg, FactSet, S&P Capital IQ나 FnGuide·코스콤 같은 국내 데이터 제공사의 데이터를 다뤘다면, 어떤 상품(시세, 재무, 추정치 등)을 어떤 방식(API, 파일 피드)으로 받았는지 밝히면 업무의 벤더 명세 분석에 그대로 연결됩니다.

• 종목·시세·지수·기업정보·재무·기업행사 가운데 하나 이상의 데이터 도메인을 깊이 이해해야 합니다.

  이렇게 볼 수 있어요

  기업행사는 이 공고의 여러 업무에 걸친 도메인입니다. 식별자 이력, 가격 조정, 분류 기준이 모두 상장·합병·분할·액면분할 같은 기업행사로 바뀌기 때문에, 기업행사 데이터를 깊게 다뤄 봤다면 그 도메인 하나가 여러 업무의 공통 배경이 됩니다.

• 금융상품과 종목 식별자 체계, 종목 마스터 데이터를 이해해야 합니다.

  이렇게 볼 수 있어요

  코어트레이딩플랫폼팀이 국내 주식과 해외 주식 주문·체결 백엔드 공고를 따로 낸 만큼, 국내 종목코드와 해외 티커·ISIN·RIC를 한 마스터에서 다루게 됩니다. 한 종목이 여러 거래소에 상장된 경우나 ADR처럼 같은 회사가 다른 증권으로 거래되는 경우를 마스터에서 어떻게 표현했는지가 이 요건의 핵심입니다.

• Python과 SQL로 대용량 금융 데이터를 분석하고 검증할 수 있어야 합니다.

  이렇게 볼 수 있어요

  AI데이터플랫폼팀과 함께 일하는 다른 공고들이 Databricks 레이크하우스를 운영한다고 적어, 분석과 검증도 그 위에서 SQL과 Python으로 하게 될 가능성이 큽니다. 수억 행 규모 시세 데이터에서 누락이나 이상값을 찾은 쿼리를 예로 들면 '대용량'의 규모가 드러납니다.

• 벤더 데이터 명세를 분석해 사내 데이터 모델과 매핑 규칙을 정의하고, 투자정보의 요구사항과 업무 규칙을 명확한 데이터 명세로 문서화할 수 있어야 합니다.

  이렇게 볼 수 있어요

  벤더 명세는 이름이 같은 필드라도 산출 기준이 다를 수 있어(시가총액을 보통주만으로 셀지 우선주까지 합칠지 같은 차이), 매핑 규칙에는 필드 이름의 대응만이 아니라 산출 기준의 차이와 예외 처리까지 함께 적어야 합니다. 매핑의 구축은 Financial Data DE가, 명세를 마트로 설계하는 일은 DAE가 맡으므로 이 공고가 쓰는 두 문서는 각각 그 엔지니어가 그대로 구현할 수 있는 수준이어야 합니다. 직접 쓴 명세서를 회사 정보를 지운 형태로 설명할 수 있게 준비하면 1차 인터뷰에서 쓸 수 있습니다.

• 데이터 정합성과 품질 문제를 발견하고 근본 원인을 분석할 수 있어야 합니다.

  이렇게 볼 수 있어요

  금융 데이터의 품질 문제는 벤더 원천, 사내 가공 규칙, 식별자 매핑 가운데 어디서 생겼는지에 따라 고칠 사람이 다릅니다. 문제를 찾은 뒤 원인이 벤더 쪽인지 사내 규칙인지 구분해 벤더 문의나 규칙 수정으로 이어 간 사례라면 근본 원인 분석을 이 공고의 구조 그대로 보여 줍니다.

• 데이터 엔지니어, AI/ML 엔지니어와 서비스 조직과 원활하게 협업할 수 있어야 합니다.

  이렇게 볼 수 있어요

  Data Analytics Engineer 공고는 금융 투자정보를 금융 데이터 분석가가 정의한 의미·산출 기준을 참조해 모델링한다고 적었습니다. 이 역할이 기준을 늦게 정하거나 자주 바꾸면 마트 설계도 함께 늦어집니다. 금융 용어는 조직마다 뜻이 조금씩 달라(수익률에 배당을 포함할지, 거래일 기준인지 결제일 기준인지), 엔지니어와 서비스 조직이 같은 말을 다르게 쓰던 상황에서 하나의 정의로 맞춘 경험을 협업 사례로 들 수 있습니다.

3우대 사항

• 복수 금융 데이터 벤더의 데이터를 비교·통합하거나 전환한 경험과, 데이터 벤더의 라이선스·권한·재배포 정책을 검토한 경험을 우대합니다.

  이렇게 볼 수 있어요

  벤더를 바꾸거나 더할 때는 데이터 값뿐 아니라 계약 조건도 함께 바뀌어, 어떤 데이터를 어디까지 보여 줄 수 있는지 다시 정해야 합니다. 업무의 벤더 도입·변경·종료 영향 분석과 라이선스 정책 적용이 이 두 우대를 한 번에 쓰는 일이라, 전환 프로젝트에서 값 차이와 계약 조건을 함께 다룬 경험을 자세히 쓰는 게 좋습니다.

• 글로벌 주식, ETF, 채권, 파생상품이나 지수 데이터를 다룬 경험을 우대합니다.

  이렇게 볼 수 있어요

  채용 사이트 파생영업본부 인터뷰는 회사가 1997년 현대선물로 출범해 선물·파생상품 분야에 전문성을 쌓아 왔다고 소개했고, 코어트레이딩플랫폼팀은 해외 주식 주문·체결 공고를 따로 냈습니다. 국내 주식 밖의 상품 데이터가 한 체계에 들어올 수 있어, ETF 구성 종목이나 선물 만기 교체처럼 상품마다 다른 데이터 구조를 다뤄 본 경험이 쓰입니다.

• 기업행사에 따른 가격·수량·식별자 조정 업무 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 회사의 국내 주식 결제 및 권리 업무 공고는 배당 등 권리처리를 운영하고, Backend Engineer(계좌·종목/상품) 공고는 배당·유상증자·권리락 같은 권리 이벤트를 계좌에 반영하는 로직을 만듭니다. 이 공고의 조정 기준은 투자정보 쪽이지만 같은 기업행사 데이터가 운영과 계좌 시스템에서도 쓰이므로, 기준일과 반영일 같은 일정 정보를 어떻게 맞췄는지까지 말할 수 있으면 회사 안에서 이 데이터가 쓰이는 범위와 연결됩니다.

• Databricks, Spark나 데이터 레이크하우스 환경에서 분석한 경험을 우대합니다.

  이렇게 볼 수 있어요

  테크본부장 인터뷰는 회사가 레이크하우스 구조 위에 텍스트로 질문하면 SQL이나 리포트로 바꿔 주는 데이터 인텔리전스 플랫폼을 만들고 있다고 소개했습니다. 그 플랫폼이 투자정보에 대해 맞는 답을 내려면 이 공고가 정하는 정의와 메타데이터가 바탕이 될 수 있어, Unity Catalog 같은 카탈로그에 데이터 설명을 정리해 본 경험도 이 우대에서 꺼낼 수 있습니다.

• 데이터 품질 규칙과 모니터링 체계를 설계하거나 운영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  Data Engineer (Data Platform) 공고는 데이터 담당자가 정의한 품질 규칙을 파이프라인에 적용하는 공통 품질 게이트를 제공한다고 적었습니다. 이 공고는 그 규칙을 정의하는 쪽이므로, 규칙을 정해 자동 점검으로 넘긴 뒤 경보가 너무 많거나 적을 때 기준을 조정해 본 경험이 있다면 그 조정 과정에서 이 공고가 맡을 일이 그대로 드러납니다.

• AI 코딩 에이전트나 생성형 AI로 SQL 작성, 데이터 분석과 문서화 생산성을 높인 경험을 우대합니다.

  이렇게 볼 수 있어요

  회사가 일하는 원칙으로 반복 업무는 AI와 자동화에 맡긴다고 적었고, 이 공고의 명세·매핑 문서는 양이 많고 형식이 반복돼 생성형 AI를 쓰기 좋은 작업입니다. AI가 쓴 매핑 규칙이나 SQL을 어떤 방식으로 검증했는지까지 적으면 이 공고가 맡는 품질 책임과 이어집니다.

4기타 사항

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

쓰는 기술

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

• LSEG
• Python
• SQL
• Databricks
• Spark

전형과 지원

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

지원 전 준비할 것

1. 1

   매핑 규칙 문서 하나 고르기

   직접 정의한 식별자 매핑이나 분류 대응 규칙을 하나 골라 예외 처리(상장폐지, 합병, 중복 상장)를 어떻게 적었는지 설명할 수 있게 정리합니다.

2. 2

   벤더 값 차이 사례 정리하기

   같은 데이터가 벤더나 원천마다 달랐던 사례를 골라 차이를 어떻게 찾았고 어떤 기준으로 정했는지를 SQL 예시와 함께 한 장으로 만듭니다.

3. 3

   자기소개서에 협업 경계 쓰기

   필수 서류에 자기소개서가 있으므로 분석가로서 기준을 정하고 엔지니어가 구현한 역할 분담을 겪어 봤다면 그 경계와 협업 방식을 구체적으로 적습니다.