[넥스트증권] Data Engineer (Data Platform) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• Databricks Delta Lake·Unity Catalog 기반 레이크하우스의 스토리지·컴퓨트·카탈로그 구조를 설계하고 환경 분리·권한·비용·성능을 관리합니다.

  이렇게 볼 수 있어요

  Unity Catalog는 Databricks에서 테이블·파일·모델의 권한과 계보를 한곳에서 관리하는 계층이라, 금융 데이터처럼 접근 통제가 엄격한 데이터에서는 카탈로그 구조가 곧 권한 설계입니다. 테크본부장 인터뷰는 회사가 레이크하우스 구조를 기반으로 현업 누구나 대화형으로 데이터를 묻고 탐색하는 플랫폼을 만들고 있다고 밝혔습니다. 현업이 직접 조회할 범위를 카탈로그·스키마 단위로 나눠 본 경험은 그 플랫폼에서 권한을 설계할 때 바탕이 됩니다.

• Confluent Kafka 클러스터(브로커·Schema Registry·Kafka Connect 클러스터)를 구축·운영하고, 토픽·ACL·쿼터·보존 정책과 멀티 환경 구성을 관리하며 처리량·지연·장애 복구·버전 업그레이드를 책임집니다.

  이렇게 볼 수 있어요

  채널·코어트레이딩 백엔드 공고들도 Kafka를 기술 스택이나 자격 요건으로 적어, 여러 팀이 Kafka를 쓰는 회사입니다. 이런 환경에서 토픽 ACL과 쿼터는 팀 사이의 경계를 정하는 일이라, 팀별 권한과 사용량 한도를 설계하고 업그레이드를 무중단으로 넘긴 경험을 이 업무의 사례로 들 수 있습니다.

• 데이터 서비스·API·배치 워커가 동작하는 EKS 클러스터와 RDS 인스턴스를 운영하고, 버전 업그레이드·노드와 용량 관리·백업·복구·보안 패치·비용을 책임지며 장애에 대응합니다.

  이렇게 볼 수 있어요

  EKS는 Kubernetes 버전마다 표준 지원 기간이 있고 RDS도 엔진 버전마다 지원 종료 일정이 있어, 두 가지의 업그레이드는 정기적으로 돌아오는 일입니다. 데이터 서비스용 EKS와 RDS까지 이 공고가 맡으므로 Spark·Kafka 운영에 더해 이 두 시스템의 업그레이드·백업을 직접 해 본 경험이 필요합니다. RDS 엔진 업그레이드처럼 서비스 중단 시간이 생기는 작업이라면 그 중단을 어떻게 계획했는지까지 적어야 운영 판단이 드러납니다.

• Financial Data DE·DAE가 개발한 배치·스트리밍 파이프라인이 동작하는 실행 환경(컴퓨트·스케줄러·오케스트레이션·관측)을 운영하고, 재처리·백필을 수행할 수 있는 운영 도구와 절차를 제공합니다.

  이렇게 볼 수 있어요

  백필은 과거 기간의 데이터를 다시 계산해 채우는 일로, 금융 데이터에서는 벤더 데이터 정정이나 기업행사 반영이 늦게 들어올 때마다 필요합니다. 금융 데이터 분석가 공고가 정정·재처리 정책을 정의하는 일을 업무로 적었으므로, 이 공고는 그 정책이 실제로 돌아가게 하는 도구를 만드는 쪽입니다. 다른 팀이 명령 하나로 특정 기간을 다시 돌릴 수 있게 만든 경험이 이 업무에 그대로 쓰입니다. 그 도구를 쓴 팀 수와 재처리 요청 건수도 함께 밝히는 게 좋습니다.

• 데이터 담당자가 정의한 품질 규칙을 파이프라인에 적용하고 결과를 모니터링할 수 있게 공통 품질 게이트와 운영 도구를 제공하며, 카탈로그·리니지 수집 기반과 권한 적용 자동화를 운영하고 데이터별 계약·메타데이터·접근 요건은 데이터 담당자와 협의해 반영합니다.

  이렇게 볼 수 있어요

  같은 회사 Data Analytics Engineer 공고는 담당 도메인의 품질 규칙과 갱신 주기(SLA)를 정의해 Platform이 제공하는 공통 품질 게이트에 적용한다고 적었습니다. 규칙의 내용은 데이터 담당자가 정하고 그 규칙을 실행하는 장치를 이 공고가 맡는 분업이라, 품질 검사 도구를 여러 팀이 같은 방식으로 쓰게 만든 경험이 있다면 쓰는 팀 수와 막아 낸 오류를 함께 적을 수 있습니다.

• Terraform 등 IaC와 CI/CD로 데이터 인프라·워크스페이스·권한·네트워크 구성을 코드화하고 환경 복제·확장을 자동화합니다.

  이렇게 볼 수 있어요

  Databricks 워크스페이스와 Unity Catalog 권한까지 Terraform으로 관리할 수 있어서, 이 업무는 개발·검증·운영 환경을 같은 코드로 만들어 내는 데까지 갑니다. 직무 Summary는 멀티 환경 확장 절차를 팀 표준으로 정립한다고 적었으므로, 새 환경 하나를 코드로 복제하는 데 걸린 시간을 적으면 그 절차를 실제로 다듬어 본 정도가 드러납니다.

• 모니터링·알림·런북을 정비하고 공통 플랫폼·인프라 장애의 온콜 rotation에 참여하며, 개별 파이프라인의 처리 로직·데이터 품질 장애는 해당 데이터 담당자와 협업해 복구하고 사후 개선을 주도합니다.

  이렇게 볼 수 있어요

  데이터 플랫폼 장애는 Kafka 브로커처럼 플랫폼에서 시작해도 증상은 특정 파이프라인의 지연으로 먼저 보이는 경우가 많아, 알림을 받은 쪽이 원인 위치를 바로 알기 어렵습니다. Backend Engineer(Data) 공고도 수집 플랫폼의 primary 온콜을 맡는다고 적어 데이터 쪽 온콜이 여러 공고에 나뉘어 있습니다. 클러스터 지표가 정상이면 파이프라인 담당자를 부르는 식의 판단 기준을 런북에 담아 다른 사람도 대응하게 만든 경험이 있다면 그 판단 기준을 예로 들 수 있습니다.

• 데이터를 쓰는 서비스·분석·AI/ML 팀이 안정적으로 데이터를 소비하게 플랫폼 인터페이스·가용성과 전송 지연 기준·운영 가이드를 제공합니다.

  이렇게 볼 수 있어요

  데이터가 분석에만 쓰이면 몇 시간 지연도 견딜 수 있지만 서비스와 AI 기능에 쓰이면 지연이 곧 사용자 화면 문제가 됩니다. 소비 팀마다 다른 가용성·지연 기준을 합의해 문서로 내놓은 경험이 있다면 우대 사항의 플랫폼 SLA 합의 경험과 함께 꺼낼 수 있습니다.

2자격 요건

• 데이터 엔지니어 또는 데이터 플랫폼 엔지니어 경력이 5년 이상이어야 합니다.

  이렇게 볼 수 있어요

  같은 팀 이름이 붙은 Backend Engineer(Data) 공고는 백엔드 경력을, Data Analytics Engineer 공고는 DW 모델러까지 포함한 모델링 쪽 경력을 요구하고, 이 공고는 플랫폼을 운영하는 쪽 경력을 요구합니다. 데이터 엔지니어 경력과 데이터 플랫폼 엔지니어 경력은 이 조건에 함께 적을 수 있고, 파이프라인 개발이 주였다면 그 파이프라인이 돌던 플랫폼의 클러스터·권한·비용을 직접 운영한 부분을 따로 드러내면 업무 범위(레이크하우스, Kafka, EKS·RDS)와 이어집니다.

• Python, Java, Kotlin 가운데 하나 이상의 프로그래밍 언어에 능숙해야 합니다.

  이렇게 볼 수 있어요

  재처리 도구와 권한 자동화처럼 운영 도구를 직접 만드는 업무라, 언어 능력도 그 도구를 만든 사례에서 드러납니다. Databricks·Spark 작업은 Python, Kafka Connect 커넥터 개발은 Java·Kotlin이 흔하므로 어느 언어로 어떤 도구를 만들었는지를 함께 적는 게 좋습니다.

• Apache Spark 또는 Databricks 등 대용량 처리 플랫폼을 프로덕션에서 운영해 봤어야 하고, 대용량 데이터 처리와 분산 시스템을 이해해야 합니다.

  이렇게 볼 수 있어요

  Databricks는 Spark 클러스터 생성과 자동 확장을 관리형으로 제공하지만, 어떤 크기와 런타임을 누가 쓸지 정하는 클러스터 정책, 잡 클러스터와 공용 클러스터의 구분, DBU 단위로 청구되는 비용 관리는 운영자가 정합니다. 그래서 Spark 작업을 작성한 경험보다 이런 운영 판단과 실패한 작업의 재시도 정책을 다뤄 본 경험이 이 요건과 가깝습니다. 데이터 쏠림(skew)이나 셔플 병목을 찾아 해결한 사례는 분산 시스템 이해를 보여 줍니다.

• 배치·스트리밍 파이프라인의 실행 환경(스케줄러·오케스트레이션·관측)을 운영하고 장애 때 재처리·백필을 지원해 봤어야 합니다.

  이렇게 볼 수 있어요

  요건이 백필을 '지원'한 경험이라고 적었으므로, 다른 팀이 요청한 재처리를 안전하게 돌리도록 격리된 실행 환경이나 우선순위를 정한 사례를 들 수 있습니다. Airflow 같은 스케줄러를 여러 팀이 같이 쓰면 백필 작업이 일상 배치의 자원을 빼앗는 일이 생기므로 자원 경합을 다뤄 본 경험도 같은 맥락입니다.

• AWS 등 퍼블릭 클라우드에서 데이터 인프라를 구축·운영해 봤어야 합니다.

  이렇게 볼 수 있어요

  Databricks on AWS는 데이터가 회사 S3에 남고 컴퓨트가 회사 계정에서 도는 구조라, S3·IAM·VPC처럼 Databricks와 Kafka 밑에 깔리는 AWS 구성을 직접 설계한 경험이 금융 데이터의 보관 위치와 네트워크 경로를 설명할 때 근거로 쓰입니다.

• 다음 가운데 1개 이상을 프로덕션에서 직접 운영해 봤어야 합니다: EKS 등 Kubernetes 클러스터(배포·업그레이드·노드 관리·모니터링·장애 대응), RDS 등 관리형 RDBMS(PostgreSQL, MySQL 등)의 백업·복구·성능 튜닝·보안 설정.

  이렇게 볼 수 있어요

  RDS 자동 백업은 보존 기간 안의 특정 시각으로 되돌리는 PITR을 지원하지만, 복구하면 새 인스턴스가 생기므로 애플리케이션이 바라보는 엔드포인트를 바꾸는 절차가 따로 필요합니다. 그래서 백업 설정만 해 본 경험보다 실제로 복구해 엔드포인트 전환까지 해 본 경험(복구 시간, 데이터 손실 범위)이 이 업무의 복구 책임과 더 직접 연결된 이력입니다. 업무에는 EKS와 RDS 운영이 모두 있어, 한쪽 경험만 있다면 다른 쪽을 어떻게 익히고 있는지 덧붙이면 됩니다.

• Terraform 등 IaC로 인프라를 코드화하고 CI/CD와 함께 운영해 봤어야 합니다.

  이렇게 볼 수 있어요

  Databricks와 Confluent는 둘 다 Terraform provider를 제공해 워크스페이스, Unity Catalog 권한, Kafka 토픽·ACL까지 코드로 관리하는 구성이 가능합니다. 권한을 코드로 관리하면 누가 언제 어떤 권한을 바꿨는지가 Git 이력과 PR 리뷰로 남아, 같은 공고 우대 사항의 전자금융감독규정·ISMS-P 대응에도 그 이력이 쓰입니다. 코드로 관리한 리소스 목록과 CI에서 plan 리뷰를 돌린 방식을 이 요건의 경험으로 적으면 됩니다.

• 모니터링·알림·온콜 등 프로덕션 운영 경험이 필요합니다.

  이렇게 볼 수 있어요

  테크본부장 인터뷰는 온콜, 장애 대응, ADR과 포스트모텀 작성을 팀의 일상 문화로 만들고 있다고 소개했습니다. 이 공고는 공통 플랫폼 장애의 온콜 rotation에 들어가므로, 알림 피로를 줄이려고 알림 기준을 바꾼 경험과 런북·포스트모텀을 남겨 다른 사람도 대응하게 한 경험이 이 요건을 가장 직접 보여 줍니다.

3우대 사항

• Kafka 클러스터(Schema Registry·Kafka Connect·ksqlDB 등)를 프로덕션에서 설계·운영하며 처리량·지연·장애 복구·업그레이드를 직접 다뤄 본 경험과, 멀티 클러스터·미러링·환경 복제 등 플랫폼 확장을 설계해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  미러링(MirrorMaker, Cluster Linking)은 재해 복구용 보조 클러스터나 환경 간 데이터 복제에 쓰여, 직무 Summary의 '장애 복구·멀티 환경 확장 절차'와 같은 일을 다룹니다. 브로커 업그레이드나 클러스터 이전을 무중단으로 넘긴 사례가 이 우대의 구체적인 모습입니다.

• 배치·스트리밍 파이프라인을 직접 설계·운영하며 재처리·백필·멱등성을 확보해 본 경험과, Databricks(Delta Lake, Unity Catalog, DLT) 또는 유사 레이크하우스 플랫폼을 멀티 환경으로 운영해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  멱등성은 같은 데이터를 두 번 처리해도 결과가 같게 만드는 성질이라, 재처리·백필이 잦은 플랫폼에서는 파이프라인을 다시 돌려도 중복이 생기지 않게 하는 전제입니다. Databricks를 개발·운영 환경으로 나눠 운영했다면 환경 사이에 코드와 권한을 어떻게 옮겼는지가 이 우대에서 설명할 부분입니다.

• Helm·Argo CD 등 GitOps 기반 Kubernetes 배포 자동화 경험과, RDS·Aurora PostgreSQL에서 Multi-AZ 구성·읽기 복제본 운영·PITR 복구를 설계하고 운영해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  PITR(Point-In-Time Recovery)은 특정 시각으로 DB를 되돌리는 복구 방식이라, 실제로 PITR로 복구해 본 경험과 그때 걸린 시간을 숫자로 적을 수 있습니다. GitOps 경험은 데이터 서비스·배치 워커를 EKS에 배포하는 업무와 이어지고, 같은 회사 코어트레이딩 백엔드 공고들의 기술 스택에도 ArgoCD가 있습니다.

• 데이터 계약·리니지·카탈로그·품질 도구(dbt, OpenLineage, Great Expectations 등)를 플랫폼에 연동해 본 경험과, 데이터를 사용하는 서비스·분석·AI/ML 팀과 플랫폼 SLA를 합의하고 운영해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  OpenLineage는 파이프라인 실행에서 리니지를 자동으로 수집하는 표준이라 업무의 '카탈로그·리니지 수집 기반'을 만드는 일과 바로 이어집니다. 같은 회사 Data Analytics Engineer 공고가 dbt와 Great Expectations를 우대 사항으로 들었으므로, 그 도구를 플랫폼 공통 기능으로 붙여 본 경험이 있으면 두 공고 사이의 분업에서 이 공고가 맡는 쪽을 이미 해 본 것입니다.

• 증권·은행·카드사 등 금융·규제 환경에서 데이터 플랫폼을 운영한 경험과, 전자금융감독규정·ISMS-P 등 금융 규제·보안 요구사항을 인프라 설계에 반영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  전자금융감독규정은 금융회사 전산 시스템의 망 분리, 접근 통제, 로그 보관 같은 요건을 정하고, ISMS-P는 정보보호와 개인정보보호 관리체계 인증입니다. 클라우드 데이터 플랫폼에서는 개인정보가 담긴 테이블의 접근 권한과 조회 기록이 감사 대상이 되므로 권한 요청·승인·회수를 자동화하고 조회 로그를 남긴 경험이 이 우대에 맞습니다. 정보보호본부 CISO도 채용 사이트 인터뷰에서 로그 정책과 개인정보 마스킹 기준을 지금 직접 정의하고 있다고 설명했습니다.

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

  이렇게 볼 수 있어요

  테크본부장 인터뷰는 AI를 코드 작성 도구가 아니라 문제 정의와 설계 맥락을 함께 이해하는 협업 파트너로 본다고 했습니다. 2026년 4월 사내 테크 컨퍼런스 NEXT BUILDER에서는 Claude Code 기반 에이전트에게 PM·개발·QA·인프라 역할을 맡긴 경험기가 발표됐습니다. Terraform 코드나 런북을 에이전트로 작성하고 검증한 것처럼 인프라 운영에 써 본 사례가 이 공고와 가까운 활용입니다.

4기타 사항

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

쓰는 기술

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

• Databricks
• Delta Lake
• Unity Catalog
• DLT
• Confluent Kafka
• Schema Registry
• Kafka Connect
• ksqlDB
• Apache Spark
• Kubernetes
• EKS
• RDS
• Aurora PostgreSQL
• PostgreSQL
• MySQL
• Python
• Java
• Kotlin
• Terraform
• Helm
• Argo CD
• AWS
• dbt
• OpenLineage
• Great Expectations

전형과 지원

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

지원 전 준비할 것

1. 1

   운영한 데이터 플랫폼 구성도 그리기

   스토리지·컴퓨트·카탈로그·스트리밍·서비스 DB가 어떻게 연결됐고 각각 누가 쓰는지 한 장으로 그리면 Databricks·Kafka·EKS·RDS 네 영역 가운데 내 경험이 어디까지인지 바로 보입니다.

2. 2

   복구 경험 숫자로 정리하기

   Kafka 브로커 장애, DB 복구, 백필처럼 실제로 되살려 본 사례를 골라 걸린 시간과 잃은 데이터 범위를 숫자로 정리합니다.

3. 3

   다른 팀이 쓰게 만든 도구 꺼내기

   재처리 도구, 권한 요청 자동화, 품질 검사 템플릿처럼 다른 데이터 담당자가 직접 쓰게 만든 도구가 있다면 쓰는 팀 수와 줄어든 요청 처리 시간을 정리합니다.