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

이 자리가 왜 생겼을까요

1하게 될 업무

• 앱·웹 로그, 시장·거래 데이터 등 다양한 소스를 스트리밍을 거쳐 레이크하우스로 잇는 수집·적재 파이프라인을 설계하고 총괄합니다.

  이렇게 볼 수 있어요

  원천이 앱 로그처럼 일부 유실을 감수할 수 있는 데이터와 거래 데이터처럼 한 건도 빠지면 안 되는 데이터로 섞여 있어, 소스마다 전달 보장 수준(at-least-once, exactly-once)과 재처리 방식을 다르게 설계해 본 경험이 이 업무의 출발점입니다.

• 이벤트·데이터 수집 서버, 광고 분석 플랫폼, 실험(A/B·피처플래그) 플랫폼 등 데이터 제품의 배포와 운영을 맡습니다.

  이렇게 볼 수 있어요

  Backend Engineer (채널 서비스·플랫폼) 공고의 Activation Platform 분야도 Analytics API와 행동 이벤트 수집·적재 파이프라인, A/B 테스트·Feature Flag 지원을 업무로 적었습니다. 그 분야는 SDK가 호출하는 API와 사용자 Context·개인화 Serving 계층을 중심으로 맡는다고 적었고, 이 공고는 수집 서버부터 레이크하우스 적재와 데이터 신뢰성(유실률·DLQ·SLA)까지 데이터가 쌓이는 쪽을 맡습니다. 그래서 행동 데이터를 받아 분석 가능한 형태로 만든 경험은 이 공고에서 더 쓰입니다.

• 대용량 로그의 유실률, DLQ, 재처리, 정합성, 데이터 품질과 SLA를 정의하고 지표로 관리합니다.

  이렇게 볼 수 있어요

  DLQ(Dead Letter Queue)는 처리하지 못한 메시지를 따로 모으는 큐라, DLQ를 운영한다는 것은 실패한 이벤트를 언제 어떻게 다시 넣을지 규칙을 정하는 일까지 포함합니다. 유실률을 어떻게 측정했는지(수집 서버 수신 건수와 적재 건수 비교 등)와 목표값을 얼마로 잡았는지를 밝히면 이 업무가 지표로 관리하는 숫자를 직접 다뤄 봤다는 점이 보입니다.

• Prometheus·Grafana 기반 모니터링 체계를 운영하고 primary 온콜로 장애에 대응합니다.

  이렇게 볼 수 있어요

  primary 온콜은 장애 알림을 가장 먼저 받는 당번이라, 데이터 플랫폼이 멈췄을 때 1차 판단을 직접 내립니다. 데이터 지연이나 유실은 광고 성과 집계와 실험 결과에 바로 영향을 주므로, 온콜 알림의 우선순위를 어떤 기준으로 매겼고 불필요한 알림을 어떻게 줄였는지까지 말할 수 있으면 이 업무를 맡아 본 경험이 보입니다.

• Terraform 등 IaC로 플랫폼 인프라를 코드로 관리하고 운영합니다.

  이렇게 볼 수 있어요

  테크본부장은 인터뷰에서 회사가 Terraform과 Databricks를 일상적으로 쓴다고 소개했습니다. Terraform으로 Kafka 토픽이나 수집 서버, 데이터 플랫폼 리소스까지 관리해 본 경험이 있다면 그 범위를 밝혀 이 업무와 연결할 수 있습니다.

2자격 요건

• 백엔드 엔지니어링 경력이 5년 이상이어야 합니다.

  이렇게 볼 수 있어요

  AI데이터플랫폼팀과 함께 일한다고 적은 Data Engineer (Data Platform) 공고가 데이터 엔지니어 경력을 요구하는 것과 달리 이 공고는 백엔드 경력을 요구합니다. 이벤트 수집 서버는 앱의 행동마다 호출되는 API라 트래픽을 받는 서버 개발이 이 일의 출발점이 되고, 백엔드 경력 5년 가운데 로그 수집 서버나 이벤트 파이프라인처럼 데이터가 흐르는 시스템을 만든 일이 이 공고와 이어집니다. 데이터 엔지니어 직함으로 수집 서버와 스트리밍을 직접 개발했다면 그 경력도 이 조건에 함께 적을 수 있습니다.

• 대규모 트래픽을 처리하는 API 서버를 개발하고 운영해 봤어야 합니다.

  이렇게 볼 수 있어요

  이벤트 수집 서버는 앱이 켜져 있는 동안 사용자 행동마다 호출되는 API라 사용자 수보다 훨씬 많은 요청을 받습니다. 초당 요청 수가 큰 API 서버를 운영하며 여러 이벤트를 한 요청에 묶어 받거나 비동기 적재로 부하를 줄인 경험이 이 요건과 업무를 함께 보여 줍니다.

• 대용량 로그를 수집·적재하는 파이프라인을 구축하고 운영해 봤어야 합니다.

  이렇게 볼 수 있어요

  이 공고의 적재 목적지는 레이크하우스이고 선호 자격에 Databricks·Delta Lake가 있습니다. 스트림에서 Delta 테이블로 적재할 때 생기는 작은 파일 문제와 스키마 변경 대응을 다뤄 봤다면 파이프라인 경험을 그 문제 중심으로 풀어 쓸 만합니다.

• 데이터 수집 플랫폼을 운영하며 안정성을 관리해 봤어야 합니다.

  이렇게 볼 수 있어요

  앱은 네트워크가 끊기면 이벤트를 기기에 쌓았다가 다시 보내므로, 수집 플랫폼은 늦게 도착한 이벤트와 중복 이벤트가 함께 들어옵니다. 같은 회사 Backend Engineer (채널 서비스·플랫폼) 공고의 Activation Platform 분야가 Web/React Native SDK와 이벤트 중복·누락 대응을 업무로 적어, 이 공고의 수집 플랫폼은 그 SDK가 보낸 이벤트를 받는 쪽과 이어질 수 있습니다. 여러 팀의 이벤트를 받는 공용 시스템에서 다른 팀이 이벤트 형식을 바꿔 적재가 깨졌을 때 어떻게 막았는지, 수집 서버 증설이나 장애 격리를 어떻게 했는지를 안정성 관리의 사례로 들 수 있습니다.

• 클라우드 환경에서 CI/CD를 운영해 봤어야 합니다.

  이렇게 볼 수 있어요

  데이터 시스템의 CI/CD는 애플리케이션 배포와 달리 스키마 변경 하나가 하류 테이블을 깨뜨릴 수 있어, 이벤트 스키마 호환성 검사나 적재 작업의 시험 실행을 파이프라인 단계로 넣는 경우가 많습니다. 테크본부장 인터뷰가 GitLab, ArgoCD, Terraform, Databricks를 일상 도구로 꼽았으므로, 이런 도구 위에서 수집 서버와 적재 작업을 함께 배포해 본 경험이 이 공고의 환경과 가깝습니다. 배포 중에도 수집이 끊기지 않게 한 방법(롤링, 버퍼링)을 함께 말하면 운영 경험이 같이 전달됩니다.

• AWS 등 퍼블릭 클라우드 환경에 익숙해야 합니다.

  이렇게 볼 수 있어요

  Data Engineer (Data Platform) 공고가 EKS와 RDS를 운영한다고 적어 이 회사의 데이터 인프라는 AWS 위에 있습니다. 수집 경로의 클라우드 비용은 대부분 데이터 전송량과 저장 용량에서 나오므로, 수집 데이터의 압축이나 보관 주기로 비용을 줄여 본 경험이 퍼블릭 클라우드에 익숙하다는 것을 가장 구체적으로 보여 줍니다. Kinesis·MSK·S3 같은 수집·저장 서비스나 GCP의 Pub/Sub·BigQuery를 다뤘다면 서비스 이름과 처리 규모를 함께 적으면 됩니다.

3우대 사항

• Databricks, Delta Lake 등 레이크하우스로의 적재 파이프라인 경험을 우대합니다.

  이렇게 볼 수 있어요

  Delta Lake는 레이크하우스 테이블에 트랜잭션과 스키마 관리를 더하는 형식이라, 스트리밍 적재에서 중복 없이 쓰기(MERGE), 늦게 도착한 이벤트 처리, 파일 압축 같은 테이블 최적화를 다뤄 봤다면 각각 어떤 문제를 겪었는지 꺼낼 수 있습니다. AI데이터플랫폼팀과 함께 일한다고 적은 Data Engineer (Data Platform) 공고가 Databricks 레이크하우스 자체를 운영하므로, 이 공고는 그 위에 데이터를 넣는 쪽입니다.

• Terraform 등 IaC 도구로 인프라를 자동화한 경험을 우대합니다.

  이렇게 볼 수 있어요

  Kafka 토픽, 수집 서버, Databricks 작업 같은 데이터 플랫폼 리소스를 IaC로 관리하면 환경을 복제하거나 되돌리기 쉬워집니다. 애플리케이션 개발자로서 IaC를 써 본 경험이라면 어떤 리소스까지 코드로 관리했는지 범위를 밝히면 됩니다.

• 이벤트 스키마·택소노미를 설계하고 버전·호환성을 관리하거나 조직 표준으로 정착시킨 경험을 우대합니다.

  이렇게 볼 수 있어요

  이벤트 택소노미는 어떤 행동을 어떤 이름과 속성으로 기록할지 정한 사전이라, 앱·웹·서버가 같은 이름을 쓰지 않으면 퍼널 지표가 맞지 않습니다. 스키마 레지스트리로 호환성을 검사하거나 이벤트 명명 규칙을 문서로 만들어 여러 팀이 따르게 한 경험이 있다면 '조직 표준으로 정착'까지 간 과정을 이야기할 수 있습니다.

• 행동·광고 분석 플랫폼(ThinkingAI, Amplitude, AppsFlyer, Airbridge 등)을 운영한 경험을 우대합니다.

  이렇게 볼 수 있어요

  Amplitude·ThinkingAI는 앱 안 행동을 분석하는 도구이고, AppsFlyer·Airbridge는 광고를 보고 앱을 설치하고 가입하기까지를 매체별로 귀속하는 모바일 측정 파트너(MMP)입니다. 두 종류 도구의 데이터를 사용자 기준으로 이어 광고 유입부터 앱 안 행동까지를 한 흐름으로 본 경험이 있다면 업무의 '광고 분석 플랫폼' 운영과 바로 이어집니다.

• A/B 테스트·피처 플래그 플랫폼을 운영하고 실험 설계를 지원한 경험을 우대합니다.

  이렇게 볼 수 있어요

  실험 플랫폼 운영은 사용자를 그룹에 고르게 나누는 배정 로직, 노출 기록, 결과 집계까지를 포함합니다. 실험 설계 지원은 표본 크기나 실험 기간, 지표를 정해 준 일이고, 배정이 치우치는 문제(SRM)를 찾아낸 경험은 플랫폼 운영 쪽에 속합니다.

• 행동 데이터와 광고 성과 관련 퍼널 지표를 산출해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 회사 Growth Marketing Manager 공고는 유입부터 계좌 개설, 첫 거래, 리텐션까지의 퍼널을 정의하고 설치·가입이 아니라 첫 거래와 코호트 품질로 성과를 판단한다고 적었습니다. 이 공고가 만드는 퍼널 지표가 그 판단에 쓰일 수 있어, 광고 유입부터 결제나 첫 거래 같은 깊은 전환까지 이어지는 지표를 만들어 본 경험이 이 우대에 가장 가깝습니다.

4기타 사항

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

쓰는 기술

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

• Prometheus
• Grafana
• Terraform
• AWS
• Databricks
• Delta Lake
• ThinkingAI
• Amplitude
• AppsFlyer
• Airbridge

전형과 지원

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

지원 전 준비할 것

1. 1

   유실률 측정 방법 정리하기

   운영했던 로그 파이프라인에서 유실과 중복을 어떻게 측정했고 목표값을 얼마로 잡았는지, DLQ에 쌓인 이벤트를 어떻게 재처리했는지 순서대로 정리합니다.

2. 2

   온콜 장애 사례 고르기

   데이터 지연이나 유실로 온콜 알림을 받았던 장애를 하나 골라 감지, 원인, 복구, 알림 기준 변경까지 설명할 수 있게 준비합니다.

3. 3

   채널 공고와 나란히 보기

   같은 회사 Backend Engineer (채널 서비스·플랫폼) 공고의 Activation Platform 분야와 업무를 나란히 놓고 내 경험이 수집·적재 쪽인지 Serving 쪽인지 정한 뒤 지원할 공고를 고릅니다. 공고는 같은 기간 복수 포지션 동시 지원이 제한될 수 있다고 적었습니다.