이 자리가 왜 생겼을까요
토스플레이스 Data Platform Team 리더는 2026년 3월 토스 기술 블로그 글 'Metric Review, 실행을 이끌다'에서 데이터 플랫폼 팀이 전사 데이터 퀄리티를 높이고 데이터 활용 기반을 강화하는 역할을 맡는다고 전했습니다. 이 공고의 팀 소개는 제품과 서비스가 확장되면서 서비스에서 데이터를 실시간으로 활용하려는 요구도 빠르게 늘고 있다고 적었습니다. 같은 팀 소개는 요구마다 파이프라인을 따로 만드는 방식에서 나아가 여러 서비스가 일관된 방식으로 데이터를 쓰는 공통 스트리밍 플랫폼을 만들어 가고 있다고 밝혔습니다. 팀 소개에 따르면 Data Platform Team은 서비스와 분석에 필요한 데이터 플랫폼과 파이프라인을 함께 구축하고 운영합니다. 분석용 적재와 서비스용 실시간 전달을 모두 해 본 경험이 있다면 두 경험을 따로 소개하는 편이 이 팀이 맡는 두 갈래 일과 맞습니다.
토스가 지금 어떤 사업에 집중하고 있는지는 토스 채용 분석에서 이어서 볼 수 있습니다.
1하게 될 업무
Flink와 Kafka를 기반으로 서비스에 필요한 실시간 데이터 파이프라인을 설계하고 구축하며, 기존 데이터 인프라를 바탕으로 스트리밍 파이프라인의 구조와 운영 기준을 직접 만듭니다.
이렇게 볼 수 있어요
팀 소개에 따르면 이 팀은 새 데이터 요구가 생길 때마다 파이프라인을 따로 개발하던 방식에서 공통 스트리밍 플랫폼으로 옮겨 가고 있습니다. 체크포인트 주기나 지연 알림 기준처럼 직접 정한 운영 기준이 있다면 왜 그 값을 골랐는지까지 설명할 수 있습니다.
서비스에서 발생한 데이터를 필요한 형태로 가공해 다른 서비스가 안정적으로 활용하도록 전달하고, 데이터의 생성부터 적재·배포·모니터링·변경까지 전체 과정을 안정적으로 운영합니다.
이렇게 볼 수 있어요
분석용 적재보다 서비스 사이의 데이터 전달이 중심인 업무입니다. 우대 사항의 CDC·CQRS 구조와 결제 데이터 정합성도 같은 흐름에 있어, 서비스 DB 변경을 다른 서비스로 넘기며 지연과 순서 문제를 다뤄 본 경험이 이 업무와 가장 가깝습니다.
반복되는 데이터 파이프라인 구축 과정을 표준화해 플랫폼으로 만듭니다. 새 요구가 생길 때마다 파이프라인을 별도로 개발하지 않도록 공통 구조를 설계하고, 설정이나 SQL, 템플릿으로 파이프라인을 쉽게 생성하고 운영하는 환경을 만듭니다.
이렇게 볼 수 있어요
이력서 안내는 개별 파이프라인을 만든 경험보다 반복되는 요구를 재사용 가능한 구조로 바꾼 경험이 궁금하다고 적었습니다. 파이프라인 몇 개를 템플릿 하나로 묶었고 새 파이프라인을 여는 데 걸리는 시간이 얼마나 줄었는지를 숫자로 적으면 됩니다.
서비스 개발자와 직접 협업하며 데이터를 실시간으로 활용할 기회를 먼저 발굴하고, 파이프라인의 설계부터 개발까지 주도합니다.
이렇게 볼 수 있어요
요청을 받아 만드는 데서 그치지 않고 활용처를 먼저 발굴하는 업무입니다. 서비스 개발자에게 실시간 데이터를 쓰는 방법을 먼저 제안해 기능으로 이어진 경험이 있다면 어떤 데이터가 어떤 기능에 쓰였는지 소개할 수 있습니다.
2자격 요건
Kafka 기반 환경에서 Flink, Kafka Streams, Spark Streaming 등으로 실시간 데이터 처리 파이프라인을 구축하고 운영해 본 사람과 함께하고 싶다고 적었습니다.
이렇게 볼 수 있어요
Kafka 위에서 썼다면 Flink 외에 Kafka Streams나 Spark Streaming 경험도 함께 적을 수 있습니다. 업무는 Flink와 Kafka 기반이므로 다른 엔진을 써 왔다면 처리량과 상태 관리 방식을 구체적으로 밝혀 두는 게 좋습니다.
요구사항을 이해하는 것부터 설계·개발·배포·모니터링까지 데이터 파이프라인의 전체 과정을 주도적으로 경험한 사람과 함께하고 싶다고 적었습니다.
이렇게 볼 수 있어요
요구사항 이해는 서비스 개발자와 직접 협업해 실시간 활용처를 먼저 찾는 업무와 이어집니다. 모니터링 뒤에 업무가 적은 '변경'은 스트리밍에서 스키마나 로직을 바꾼 뒤 상태를 옮기거나 과거 데이터를 다시 흘리는 일이라 손이 많이 갑니다. 파이프라인 하나를 처음 요청받은 시점부터 운영 중 변경과 장애 대응까지 맡은 사례를 단계별로 나눠 설명할 수 있습니다.
반복되는 데이터 처리 요구를 발견하고 재사용할 수 있는 구조로 표준화해 본 경험이 있는 사람을 찾습니다.
이렇게 볼 수 있어요
공통 스트리밍 플랫폼을 만드는 팀이라 이 요건이 업무의 표준화·플랫폼화와 그대로 연결됩니다. 표준화한 구조를 다른 팀이나 서비스가 실제로 가져다 쓴 횟수를 함께 적으면 재사용이 실제로 일어났다는 점이 분명해집니다.
3우대 사항
Kubernetes 환경에서 Flink 또는 Kafka Streams와 Kafka Ecosystem(Kafka Connect, Schema Registry 등)을 활용해 실시간 데이터 파이프라인을 구축하고 운영해 본 경험
이렇게 볼 수 있어요
자격 요건이 처리 엔진 경험을 묻는다면 이 우대는 그 엔진을 Kubernetes 위에서 운영한 경험을 묻습니다. Flink 잡을 Kubernetes에 배포하고 스키마 변경을 Schema Registry로 관리해 본 구성이 이 우대에 맞습니다.
장애나 재시작 상황에서도 데이터가 유실되거나 중복되지 않도록 Exactly-once 또는 멱등성을 보장해 본 경험
이렇게 볼 수 있어요
결제·커머스처럼 데이터 정합성이 중요한 서비스 운영 경험을 따로 우대한 것과 같은 맥락입니다. 재시작 뒤 중복을 막으려고 고른 방식과 그것을 검증한 방법을 함께 밝히면 됩니다.
로직 변경이나 장애 발생 이후 과거 데이터를 재처리(Backfill, Replay)할 수 있는 구조를 설계해 본 경험
이렇게 볼 수 있어요
이력서 안내도 데이터 유실·중복·지연·장애를 어떻게 진단하고 해결했는지 물었습니다. 재처리한 기간과 데이터 양, 재처리하는 동안 서비스 쪽 영향을 어떻게 막았는지가 설계의 깊이를 보여 줍니다.
CQRS, CDC 등을 기반으로 서비스 DB의 변경 데이터를 실시간으로 수집하고, 다른 서비스에서 조회할 수 있는 저장소로 전달·동기화하는 구조를 설계해 본 경험
이렇게 볼 수 있어요
CQRS·CDC로 변경 데이터를 조회 저장소에 전달하는 구조는 업무의 '다른 서비스에서 안정적으로 활용할 수 있도록 전달'하는 일을 구현하는 대표적인 방식입니다. 원천 DB와 조회 저장소 사이의 지연을 얼마로 맞췄는지 숫자로 밝혀 두면 좋습니다.
결제, 커머스 등 데이터 정합성이 중요한 서비스에서 실시간 데이터 파이프라인을 운영한 경험
이렇게 볼 수 있어요
토스플레이스는 결제 단말기와 POS를 만드는 회사라 파이프라인에 결제·매장 운영 데이터가 흐를 수 있습니다. 정합성 문제를 발견해 고친 사례가 있다면 이력서 안내가 꼽은 '데이터 정합성' 전후 변화로 옮겨 쓸 수 있습니다.
Apache Iceberg, StarRocks 등 데이터 저장 및 분석 환경과 스트리밍 파이프라인을 연계해 본 경험
이렇게 볼 수 있어요
팀이 서비스용 실시간 전달과 함께 분석 환경도 다룬다는 점이 이 우대에서 보입니다. 스트리밍 결과를 Iceberg 테이블이나 분석 DB에 적재해 배치 결과와 맞춰 본 경험이 있다면 두 경로의 값을 어떻게 일치시켰는지 설명할 수 있습니다.
4기타 사항
- 게시일 : 2025년 9월 8일
- 고용형태 : 정규직
- 근무지 : 서울특별시 서초구 강남대로 459, 4층, 5층 (서초동, 토스 신논현 오피스) (추정)
- 경력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
- 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
쓰는 기술
공고 본문에 적힌 기술만 모은 목록입니다.
- Flink
- Kafka
- Kafka Streams
- Spark Streaming
- SQL
- Kubernetes
- Kafka Connect
- Schema Registry
- Apache Iceberg
- StarRocks
전형과 지원
토스커뮤니티는 합류 여정을 한 페이지로 공개해 두었습니다. 공통 골격은 같지만 계열사와 공고에 따라 단계가 더해지거나 빠지므로, 공고 페이지에 적힌 단계를 함께 확인해야 합니다.
기본 다섯 단계
지원서 접수, 직무 인터뷰, 문화적합성 인터뷰, 레퍼런스 체크, 처우 협의와 합류 결정 순입니다. 안내에는 '포지션에 따라 사전 과제/ 전화 인터뷰 등의 전형이 추가될 수 있어요'라고 적혀 있습니다.
이렇게 볼 수 있어요
공고마다 앞 단계가 다르므로 일정을 잡을 때 공고 페이지를 먼저 봐야 합니다. 같은 계열사 안에서도 사전 과제가 붙은 공고와 없는 공고가 섞여 있습니다. 토스뱅크 Customer Success Specialist(계약직)와 토스 Financial Data Analyst (FP&A) 공고는 레퍼런스 체크와 처우 협의 없이 문화적합성 인터뷰 뒤 바로 최종 합격으로 갑니다. 토스씨엑스 B2C 패션몰 단순문의 상담원 공고는 서류접수 뒤 단순 화상 인터뷰 한 번을 거쳐 최종합격으로 갑니다. 둘 중 하나만 빠진 공고도 있습니다. 토스증권 Executive Assistant 공고는 레퍼런스 체크 뒤 처우 협의 없이 최종 합격으로 갑니다. Category MD (신선식품 Unit Leader - 과일, 채소), Category MD (뷰티), Category MD (가공식품), Category MD (생활 - 가구/홈데코/주방용품), Search Quality Operations Manager, 토스인슈어런스 Commission Manager 공고는 처우 협의가 레퍼런스 체크보다 먼저 옵니다.
문화적합성 인터뷰가 따로 있다
'인터뷰어는 토스의 핵심가치를 누구보다 잘 이해하고 있는 동료들로 구성되어 있어요'라고 적혀 있고, '지원자를 검증하기 위해 일방적으로 질문을 던지는 것이 아니라, 토스커뮤니티 문화에 대해 서로 진솔한 대화를 나누는 방식으로 진행해요'라고 설명합니다.
이렇게 볼 수 있어요
직무 경험만 준비하면 한 단계를 비워 두게 됩니다. 팀 문화 페이지의 열두 항목 가운데 본인 경험으로 이야기할 수 있는 것을 골라 사례를 미리 정리해 두면 이 단계에서 꺼낼 것이 생깁니다. 토스씨엑스 B2C 패션몰 단순문의 상담원처럼 이 단계 없이 단순 화상 인터뷰 한 번으로 끝나는 공고도 있습니다.
인터뷰는 전부 온라인이다
'모든 인터뷰는 온라인(Google Meet/ Zoom)으로 진행하고 있어요'라고 적혀 있고 '최대한 1:1 커뮤니케이션을 지향'한다고 밝혔습니다. 인터뷰어는 '합류하신다면 가장 많은 협업을 하게 되실 동료들'입니다.
이렇게 볼 수 있어요
이동 시간이 들지 않아 재직 중에도 일정을 잡기 쉽습니다. 안내가 조용한 개인 공간과 이어폰 사용을 권하고 있으므로 환경을 미리 확인해 두는 편이 좋습니다.
지원서는 자유 양식이다
'지원자분의 역량을 최우선적으로 검토하기 위해 자유 양식의 지원서를 받고 있어요'라고 적혀 있습니다. 개발 직군은 '기술 숙련도를 파악하기 위해 이력서 상에 기술 스택을 꼭 작성해 주세요'라는 요구가 따로 붙습니다.
이렇게 볼 수 있어요
정해진 문항이 없으므로 무엇을 보여 줄지 직접 정해야 합니다. 안내는 경험을 나열하기보다 '임팩트와 러닝 포인트'를 적으라고 했고, 주민등록번호와 자택 주소, 연봉은 필수가 아니라고 밝혔습니다. 제출은 PDF를 권합니다.
계열사 간 중복 지원이 된다
'원하는 포지션이라면 계열사 간 중복 지원도 가능해요'라고 적혀 있습니다. 토스, 토스뱅크, 토스페이먼츠, 토스인슈어런스, 토스증권, 토스씨엑스 등이 함께 열거돼 있습니다.
이렇게 볼 수 있어요
같은 직무를 여러 계열사가 채용하고 있을 때 하나만 고를 필요가 없습니다. 다만 계열사마다 도메인이 다르므로 지원서의 강조점은 각각 맞추는 편이 낫습니다.
지원 전 준비할 것
- 1
실시간 데이터 문제 해결 사례 쓰기
이력서 안내는 어떤 규모와 환경에서 데이터 유실·중복·지연·장애가 발생했고 원인을 어떻게 진단해 해결했는지 드러나게 써 달라고 했습니다. 사례마다 초당 처리량 같은 규모, 증상, 원인, 바꾼 것을 한 단락으로 묶어 두세요.
- 2
표준화와 구조 개선 경험 고르기
안내는 개별 파이프라인을 구축한 경험보다 반복되는 문제나 요구를 재사용 가능한 구조로 표준화하고 개선한 경험이 궁금하다고 적었습니다. 템플릿이나 공통 모듈로 묶은 파이프라인 수와 새 파이프라인을 만드는 데 드는 시간이 어떻게 바뀌었는지 준비해 둘 수 있습니다.
- 3
전후 수치를 정리하고 민감 정보 빼기
개선 결과는 처리 지연시간, 처리량, 장애 빈도, 데이터 정합성 같은 전후 변화를 수치로 보여 달라고 했고, 외부 공개가 민감한 내용은 빼 달라고 했습니다. 절대값이 민감하면 개선 비율로 바꿔 쓰는 방법이 있습니다.