[토스증권] 데이터 엔지니어 (금융데이터/DRE) (Data Engineer) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 주식 공시, 실적, 시세, 뉴스 등 담당 데이터 도메인의 원천과 유입 경로를 이해하고 데이터 입수부터 가공, 검증, 제공까지 전체 파이프라인을 설계하고 운영합니다.

  이렇게 볼 수 있어요

  공시와 시세는 원천마다 형식과 도착 시각이 달라 한 파이프라인에 모으는 단계에서 어긋남이 생깁니다. 고객은 그 숫자를 투자 판단에 쓰고, 팀 소개도 같은 이유로 정확성과 일관성이 서비스 신뢰를 정한다고 적었습니다. 원천이 여럿인 데이터를 하나로 모은 경험이 있다면 원천별로 어떤 불일치가 나왔는지를 적을 수 있습니다.

• 담당 도메인의 데이터 품질 기준과 정합성 검증 체계를 데이터 거버넌스 규칙으로 정의하고, 문제가 발생하면 원천부터 고객 노출 지점까지 추적해 원인을 해결하고 재발을 방지합니다.

  이렇게 볼 수 있어요

  기준을 정의하는 일과 사고 뒤 추적이 한 업무에 묶여 있습니다. 토스뱅크 Data Governance Manager 공고는 같은 거버넌스를 전사 데이터 표준, 품질, 접근 권한, 메타데이터 관리 체계로 다룹니다. 이 공고의 규칙은 특정 도메인의 데이터가 맞는지를 가리는 검증 기준입니다. 틀린 값이 고객 화면까지 간 사고를 원천까지 거슬러 추적한 경험이 있다면 어느 구간에서 틀어졌는지를 단계별로 나눠 씁니다. 그러면 원천부터 고객 노출 지점까지 추적한 범위가 보입니다.

• 선언형 데이터 계약(Data Contract)으로 품질 기준을 정의하고 자동으로 검증하고 관측하는 데이터 품질 플랫폼을 함께 개발하고 운영합니다.

  이렇게 볼 수 있어요

  데이터 계약은 컬럼 형식, 허용 범위, 갱신 주기 같은 기대치를 코드로 선언하고 파이프라인이 그것을 어기면 자동으로 알리는 방식입니다. 우대 사항이 ODCS, dbt test, Great Expectations, Soda를 예로 들었습니다. 이 가운데 하나로 검증 규칙을 코드로 관리하고 CI에 붙여 본 경험이 있다면, 규칙 수와 잡아낸 오류 건수로 계약 기반 품질 검증을 운영한 규모가 숫자로 남습니다.

• 고객에게 노출되는 서비스 지면에서 원천까지 데이터 계보(lineage)를 추적해 검증 공백을 찾고, 외부 벤더 데이터와 사내 원천 데이터를 교차 검증하는 체계를 만듭니다.

  이렇게 볼 수 있어요

  검증을 원천 쪽에서만 하지 않고 고객 화면에서 거꾸로 확인하는 설계입니다. 동료의 한마디도 데이터 품질은 원천에서만 관리할 문제가 아니라 고객이 실제로 보는 지면에서 확인해야 하는 문제라고 적었습니다. 시세나 실적을 외부 벤더에서 받는 증권사에서는 벤더 값과 사내 값이 어긋날 때 어느 쪽이 맞는지 가리는 규칙이 필요합니다. 두 출처를 대조해 불일치를 잡아낸 경험이 있다면 불일치 비율과 함께 어느 쪽 값이 맞는지 정한 처리 방식까지 적습니다. 그래야 교차 검증 체계를 직접 만든 일이 분명해집니다.

• Airflow, Kubernetes 기반 데이터 파이프라인의 관측 가능성을 높이고, 데이터 장애 수집과 원인 추적 같은 반복 운영 업무를 AI 에이전트로 자동화해 나갑니다.

  이렇게 볼 수 있어요

  관측 가능성은 파이프라인이 지금 어떤 상태인지를 메트릭과 로그로 볼 수 있게 하는 일이고, 이 팀의 기술 목록에 Prometheus, Grafana, Kibana가 있습니다. 업무는 그 위에서 장애 알림 수집과 원인 후보 정리 같은 반복 운영을 AI 에이전트에 넘기는 데까지 나아갑니다. 이력서 안내가 요청한 모니터링·알림·런북 같은 운영 체계를 도입한 경험에 에이전트 자동화를 얹은 사례가 가깝고, 스크립트나 LLM으로 자동화한 경험도 같은 종류입니다. 줄어든 대응 시간과 사람이 다시 확인하는 비율이 자동화의 효과를 보여 줍니다.

2자격 요건

• Data Engineering 또는 데이터 플랫폼 개발·운영 경험이 3년 이상 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  공고가 Data Engineering 경력과 데이터 플랫폼 개발·운영 경력을 같은 조건에 적었으므로 두 경력은 이 연차에 함께 적을 수 있습니다. 팀 소개는 담당 데이터 도메인의 신뢰성에 대해 데이터 라이프사이클 전반의 ownership을 가진다고 밝혔습니다. 연차 안에서 한 도메인의 데이터를 입수부터 제공까지 책임진 일이나 데이터 품질·장애 대응을 맡은 일은 도메인 이름과 함께 밝히면 업무의 품질 기준·장애 추적 항목과 이어지는 부분이 분명해집니다.

• Python과 SQL로 데이터 검증·처리 로직을 프로덕션 수준으로 구현하고 테스트할 수 있어야 한다고 적었습니다.

  이렇게 볼 수 있어요

  이 요건은 검증 로직의 테스트까지 요구합니다. 검증 코드가 틀리면 틀린 데이터가 통과하므로 검증 쪽에도 단위 테스트가 필요하다는 뜻입니다. 데이터 검증 쿼리나 규칙에 테스트를 붙여 오탐과 미탐을 줄인 경험이 있다면 방법과 결과가 이 요건과 가장 가깝습니다.

• Airflow, Kubernetes 기반 데이터 파이프라인을 구축하고 운영한 경험이 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  업무의 관측 가능성 개선이 같은 스택 위에서 이뤄지고, 토스증권이 쓰는 기술 목록에도 Airflow, DBT, Kubernetes, ArgoCD가 있습니다. 구축과 운영을 둘 다 적었으므로 직접 만든 파이프라인이 장애가 났을 때 복구한 사례를 함께 적으면 두 가지가 모두 드러납니다.

• RDBMS와 분산 쿼리 엔진(Impala, Spark, ClickHouse 등)을 활용해 데이터 정합성과 품질을 검증하는 로직을 설계하고 운영한 경험이 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  이 팀의 기술 목록에 Impala, Spark, ClickHouse, Iceberg가 모두 있어 같은 엔진 위에서 검증을 돌립니다. 건수 대조나 합계 대조 같은 단순한 검증도 대용량 테이블에서는 엔진별로 비용과 시간이 달라집니다. 어떤 엔진에서 어떤 검증을 돌리고 실행 시간을 어떻게 줄였는지가 이 요건에서 묻는 부분입니다.

• 데이터 장애를 탐지부터 복구, 재발 방지까지 끝까지 책임진 경험이 필요하다고 적었습니다. 드러난 현상 뒤에 숨은 근본 원인을 끝까지 파고드는 일을 좋아하는 분이면 더 잘 맞는다고 덧붙였습니다.

  이렇게 볼 수 있어요

  탐지에서 복구와 재발 방지까지라는 범위가 업무의 문제 추적과 재발 방지 항목과 같습니다. 동료의 한마디는 실패를 두려워하는 대신 관리하는 방식으로 데이터 신뢰성을 엔지니어링 문제로 풀겠다고 적었습니다. 데이터 장애가 사람의 신고로 알려지던 상황을 자동 탐지로 바꾼 경험이 있다면 탐지까지 걸린 시간이 얼마나 줄었는지가 그 변화를 숫자로 보여 줍니다.

• 제품을 만드는 과정에서 Product Owner, SW Engineer, Machine Learning Engineer 등 다양한 포지션의 팀원과 협업하고 커뮤니케이션할 수 있어야 한다고 적었습니다.

  이렇게 볼 수 있어요

  팀이 만드는 데이터는 투자자에게 정보를 주는 AI 기반 서비스에 쓰이므로 데이터가 틀리면 서비스를 만드는 Product Owner와 Machine Learning Engineer의 작업에도 영향이 갑니다. 검증 기준을 정할 때 이들과 무엇을 합의했는지를 협업 경험으로 꺼낼 수 있습니다.

• 요구사항과 문제를 스스로 명확히 정의하고, AI 도구를 활용해 검증 엔진부터 어드민 화면까지 플랫폼 전체를 직접 만들고 운영할 수 있는 사람을 찾는다고 적었습니다.

  이렇게 볼 수 있어요

  검증 엔진부터 어드민 화면까지는 업무에 적힌 데이터 품질 플랫폼(선언형 데이터 계약으로 검증하고 관측)의 개발·운영을 화면 쪽까지 넓힌 범위입니다. 데이터 팀에서 백엔드 로직만 만들던 사람도 어드민 화면을 AI 코딩 도구로 직접 만든 경험이 있다면 그것도 이 항목의 사례입니다. 이 경험은 우대의 Claude Code, Codex 도구 활용 항목과도 이어집니다. 화면의 사용자가 누구였고 그 화면으로 무엇을 확인하게 됐는지도 함께 적는 것이 좋습니다.

• Data Reliability Engineer라는 이름으로 일한 경험이 없어도 괜찮다고 적었습니다. 데이터 엔지니어링 기초가 탄탄하고 데이터가 틀리는 문제를 시스템으로 풀어 본 사람을 찾습니다.

  이렇게 볼 수 있어요

  팀 소개는 DRE를 데이터 신뢰성을 엔지니어링으로 보장하고 검증·모니터링 시스템을 직접 만들고 개선하는 역할로 설명했습니다. 그래서 이 이름을 달지 않았던 경력도 그 일을 했다면 사례가 됩니다. 데이터 엔지니어, 분석 엔지니어, 플랫폼 개발 어느 직함이었든 틀린 데이터를 시스템으로 막은 사례가 있다면 문제, 접근, 결과 순으로 적는 편이 좋습니다. 이력서 안내가 기술 스택보다 그 접근을 고른 이유와 트레이드오프를 함께 적어 달라고 했습니다.

3우대 사항

• 데이터 계약(ODCS, dbt test, Great Expectations, Soda 등) 기반 품질 검증 도구를 도입하거나 운영한 경험이 있으면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  우대에 적힌 도구들은 업무의 데이터 품질 플랫폼이 쓰는 선언형 데이터 계약과 같은 계열입니다. dbt test는 SQL 모델에 대한 테스트이고 Great Expectations와 Soda는 데이터 기대치를 검증하는 도구라 같은 목적을 서로 다른 방식으로 풉니다. 도입했다면 고른 이유와 후보로 본 다른 도구를 함께 말하면 이 우대와 맞습니다.

• SRE 관점의 SLI/SLO, 에러 버짓, 인시던트 관리 체계를 설계하거나 운영한 경험이 있으면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  동료의 한마디는 고객 노출 지점의 신뢰성을 숫자로 잰다고 적었습니다. 데이터에도 최신성이나 정확도 같은 SLI를 정해 목표를 세운 경험이 있다면 어떤 지표를 골랐고 에러 버짓을 어떻게 썼는지가 이 우대에서 묻는 부분입니다.

• 대용량 데이터 플랫폼과 분산 처리에 대한 이해와 경험(Iceberg/Clickhouse/ES 등)이 있으면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  기술 목록에 Iceberg, ClickHouse, ElasticSearch가 모두 들어 있습니다. Iceberg는 테이블 포맷, ClickHouse는 분석용 DB, ElasticSearch는 검색용이라 데이터가 쌓이는 층마다 검증 방식이 다릅니다. 이 가운데 어느 층에서 검증을 돌렸는지가 이 우대의 경험 범위입니다.

• Claude Code, Codex 같은 AI 코딩 도구를 설계·구현·검증 과정에 활용하고 그 산출물을 스스로 검증할 수 있는 사람이면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  AI가 쓴 검증 쿼리는 실행은 되는데 조건이 하나 빠져 틀린 데이터를 통과시키는 일이 있습니다. 이 팀은 검증이 곧 제품인 팀이라, 산출물을 스스로 검증할 수 있는 사람이라는 조건도 그 위험과 이어지는 것으로 보입니다. 필수 요건이 검증 로직에 테스트를 붙일 수 있어야 한다고 적었으므로, AI가 쓴 검증 로직을 일부러 틀린 테스트 데이터로 확인한 방식이나 틀린 출력을 잡아낸 사례가 가깝습니다. 이력서 안내도 AI 코딩 도구로 개발·검증 방식을 바꾼 경험을 적으라고 했습니다.

• 증권 도메인과 제품에 관심이 많고 투자 경험과 기준이 있는 사람이면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  공시, 실적, 시세가 이 팀의 데이터라 투자 경험이 있으면 어떤 값이 틀릴 때 투자자가 곤란한지를 직접 압니다. 예를 들어 액면분할 같은 이벤트가 과거 시세 이력에 반영되는 방식을 알면 검증 규칙의 예외를 먼저 떠올릴 수 있습니다.

4기타 사항

• 게시일 : 2026년 9월 28일
• 고용형태 : 정규직
• 근무지 : 서울특별시 강남구 테헤란로 133, 7층 (역삼동, 한국타이어빌딩) (추정)
• 경력 조건 : 경력 3년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

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

• Python
• SQL
• Airflow
• DBT
• Impala
• Spark
• Iceberg
• ElasticSearch
• Neo4j
• Kafka
• Flink
• Clickhouse
• Kibana
• Grafana
• Prometheus
• Github
• Kubernetes
• ArgoCD

전형과 지원

토스커뮤니티는 합류 여정을 한 페이지로 공개해 두었습니다. 공통 골격은 같지만 계열사와 공고에 따라 단계가 더해지거나 빠지므로, 공고 페이지에 적힌 단계를 함께 확인해야 합니다.

지원 전 준비할 것

1. 1

   데이터 품질 문제를 정의한 방식 쓰기

   이력서 안내는 데이터 정합성과 품질 문제를 어떻게 정의하고 어떤 검증 체계나 시스템으로 해결했는지 작성해 달라고 했습니다. 문제의 정의, 검증 기준, 잡아낸 오류 건수를 한 사례로 묶어 정리합니다.

2. 2

   장애 대응을 흐름으로 쓰기

   안내는 데이터 장애를 탐지하고 분석하고 복구해 재발을 막기까지 문제 상황, 접근 방식, 구현·운영, 결과와 학습의 흐름이 보이게 쓰라고 했습니다. 장애 사례 하나를 이 네 칸으로 나눠 정리하면 직무 인터뷰에서도 같은 순서로 답할 수 있습니다.

3. 3

   선택 이유와 트레이드오프 적기

   안내는 사용한 기술 스택보다 왜 그 접근을 선택했고 어떤 트레이드오프를 고려했는지를 함께 적어 달라고 했습니다. 검증 엔진이나 도구를 고른 경험이라면 후보 도구와 버린 이유를 적습니다. AI 코딩 도구로 개발·검증 방식을 바꾼 경험은 안내가 따로 적으라고 한 항목이므로 한 줄 넣습니다.