2026. 09. 18. 23:04
22년부터 꾸준히 이력서x기술면접 트레이닝 과 백엔드 과제전형 대비 과정 운영하는 백엔드 개발자 인큐입니다.
21년부터는 인프런 멘토링도 계속 진행하고 있습니다.
이전 클립인 「2026년을 대비하는 신입 백엔드 개발자 취업 동향 및 전략」에서는 여러 서비스 기업에 합격한 신입들의 준비 수준과 프로젝트 방향을 다뤘습니다.
이번에는 범위를 토스에 맞췄습니다.
최근 2026년 토스뱅크 수시채용(주니어 경력공고) + 백엔드 인턴 서류전형에 합격한 신입 이력서와 포트폴리오를 분석했습니다.
이 클립에서는 다음 내용을 다룹니다.
최근 토스뱅크 백엔드 인턴 서류합격 이력서의 공통점
합격자들이 프로젝트에서 실제로 다룬 문제
금융 프로젝트가 없어도 경쟁력을 만들 수 있는 방법
합격 이력서에서 반복된 프로젝트 서술 구조
처우 협상 가이드이력서와 포트폴리오를 나누는 방법
서류의 한 문장이 실제 면접 질문으로 바뀌는 과정
2026년 토스 지원 전 확인해야 할 체크리스트
🚀 이런 분께 추천합니다
• 토스뱅크·토스페이먼츠·토스증권 등 토스 계열 지원을 준비하는 신입·주니어
• 프로젝트에 Kafka, Redis, Outbox, 분산락을 썼지만 이력서에 어떻게 표현할지 모르는 분
• 금융 프로젝트가 없어 토스 지원이 어렵다고 생각하는 분
• 성능 개선 수치는 있지만 서류에서 강점이 잘 드러나지 않는 분
• 서류에 적은 기술이 실제 면접에서 어떻게 질문으로 바뀌는지 궁금한 분
• 이력서와 포트폴리오에 같은 내용을 반복해서 적고 있는 분
최근 합격 이력서의 공통점은 기술 스택이 많다는 것이 아니었습니다.
정확성이 중요한 데이터, 실패 시나리오, 운영 복구, 수치 검증, 기술 선택 이유가 프로젝트 안에 들어 있었습니다.
신입 이력서인데도 아래 질문에 답할 수 있는 소재가 있었습니다.
이건 경력한테 물어보는거 아니야 할 수 있는데 현재 네임드 신입 채용시장은 신입/경력 구분이 없을 정도로 준비된 신입이 진입이 가능한 상황입니다.
• 왜 이 구조를 선택했나요?
• 외부 시스템이 성공하고 내부 처리가 실패하면 어떻게 되나요?
• 메시지가 중복되거나 유실되면 어떻게 하나요?
• 수치는 어떤 조건에서 측정했나요?
• 서버가 중간에 종료되면 작업은 어디에 남나요?
• 운영자는 실패를 어떻게 발견하고 재처리하나요?
• 다른 기술 대신 이 기술을 선택한 이유는 무엇인가요?
• 현재 구조의 한계는 무엇인가요?
즉, 면접관이 한 문장을 보고 바로 3~5개의 꼬리질문을 만들 수 있는 이력서였습니다.
한눈에 정리하면 다음과 같습니다.
• 합격 요소: 정합성
최신 자료에서 반복된 모습: 결제, 잔액, 알림, 재고, 외부 원천 데이터의 유실·중복·불일치 처리
서류에서 전달되는 신호: 정확성이 중요한 데이터를 다룰 수 있음
• 합격 요소: 실패 대응
최신 자료에서 반복된 모습: 외부 장애, 부분 실패, 중복 발행, batch 중단, 재연결 고려
서류에서 전달되는 신호: 정상 흐름 밖의 상황까지 설계함
• 합격 요소: 수치 검증
최신 자료에서 반복된 모습: 응답시간, 처리시간, query count, 비용, 데이터 건수 제시
서류에서 전달되는 신호: 직접 측정하고 개선했을 가능성이 높음
• 합격 요소: 선택 근거
최신 자료에서 반복된 모습: 락, Outbox, N-gram, presigned URL, batch 구조의 대안 비교
서류에서 전달되는 신호: 기술을 목적이 아니라 수단으로 사용함
• 합격 요소: 운영 복구
최신 자료에서 반복된 모습: 상태값, retry, stuck 처리, alert, 재처리 API
서류에서 전달되는 신호: 실패를 발견하고 복구하는 흐름이 있음
• 합격 요소: 문서 구성
최신 자료에서 반복된 모습: 이력서는 압축하고 포트폴리오에서 근거 확장
서류에서 전달되는 신호: 스캔성과 면접 방어력을 함께 확보함
좋은 이력서는 서류를 통과하기 위한 문서인 동시에 면접 질문지입니다.
인큐커리어에서는 4년간 운영한 백엔드 기술면접 트레이닝 데이터와 실제 토스 계열 면접 복기를 바탕으로, 제출한 이력서에서 나올 수 있는 핵심 질문과 꼬리질문을 정리한 예상질문 리포트를 제공합니다.
https://www.incu-career.kr/backend-expected-question-report
단순 CS 문제 모음이 아니라 본인이 적은 프로젝트와 기술 선택을 기준으로 질문을 구성합니다.
1. 결제 프로젝트가 아니어도 데이터를 돈처럼 다뤘다
토스지원이라고 해서 모두 금융권 핀테크 도메인 기반의 프로젝트를 보유한 것은 아니었습니다.
프로젝트 소재는 다양했습니다.
• PG 결제와 포인트 잔액
• 주문·결제 이력과 지갑 상태
• 실시간 알림과 발송 이력
• 외부 API 원천 데이터 동기화
• 40만 건 데이터 대량 batch 처리
• 재고·매출 데이터 전송
• 금융성 메시지
• Blockchain transaction과 Chain Reorg 복구
도메인은 달랐지만 공통점이 있었습니다.
유실되거나 중복되거나 순서가 바뀌면 문제가 되는 정합성이 중요한 데이터를 다뤘습니다.
금융 프로젝트가 없다고 해서 토스에 적합한 프로젝트가 없는 것은 아닙니다.
예를 들어
알림 프로젝트라도 다음을 고민했다면 충분히 강한 정합성 프로젝트가 됩니다.
• DB commit 전에 메시지가 발행되면 어떻게 되는가
• 발행은 성공했는데 상태 변경 전에 서버가 죽으면 어떻게 되는가
• 같은 메시지가 두 번 소비되면 어떻게 막는가
• 재연결한 사용자가 놓친 알림을 어떻게 복구하는가
• Redis Pub/Sub처럼 저장되지 않는 메시지를 어떤 데이터로 복구하는가
재고 프로젝트도 마찬가지입니다.
• ERP 전송에 실패한 거래가 어디에 남는가
• 판매·교환·환불의 선후 관계를 어떻게 보장하는가
• 자동 재시도와 담당자 확인 후 재처리 중 무엇을 선택할 것인가
• 같은 거래가 다시 전송되어도 안전한가
핵심은 프로젝트명이 아니라 정확성을 어떤 방식으로 지켰는가입니다.
2. 정상 흐름보다 실패 이후의 예외 처리를 고민하였는지
아쉬운 이력서 및 포트폴리오의 프로젝트 설명은 정상 동작에 대해서만 고민했습니다.
합격 이력서에서는 아래의 케이스들을 고민했습니다.
• PG 승인은 성공했는데 내부 저장이 실패한 경우
• DB 저장은 성공했는데 메시지 발행이 실패한 경우
• SMTP 장애가 핵심 요청의 응답시간을 증가시키는 경우
• 외부 API가 느려 검색 기능 전체가 영향을 받는 경우
• batch 처리 중간에 일부 데이터만 반영된 경우
• 다중 WAS에서 SSE 연결 정보가 한 서버 메모리에만 있는 경우
• Redis Pub/Sub 메시지를 구독자가 받지 못한 경우
• 외부 원천 데이터가 사후에 변경되는 경우
토스형 이력서에서는 “성공시켰다”보다 실패가 어디에 남고 어떻게 복구되는지 예외케이스에 대한 고려를 해주셔야 합니다.
3. ‘기술을 사용했다’가 아니라 선택한 이유가 있었다
합격 이력서에는 Redis, Kafka, Outbox, Kubernetes 같은 기술이 많이 등장했습니다.
하지만 기술명 자체가 합격 포인트는 아니었습니다.
좋았던 부분은 대안을 비교한 흔적입니다.(논리적인 접근)
• 비관적 락과 낙관적 락 중 무엇을 선택했는가
• Redis 분산락이 아니라 DB 락으로 충분했는가
• DB 저장 후 직접 publish하지 않고 Outbox를 선택한 이유는 무엇인가
• WebSocket, Polling, SSE 중 왜 SSE였는가
• Redis Pub/Sub을 썼다면 저장형 메시징이 아닌데 복구는 어떻게 하는가
• LIKE 검색 대신 N-gram을 선택한 이유는 무엇인가
• API 서버 업로드 대신 presigned URL을 선택한 이유는 무엇인가
• batch size를 100개 또는 1,000개로 정한 기준은 무엇인가
토스 면접에서는 기술 사용 여부보다 “왜?”가 반복됩니다.
따라서 이력서에도 최소한 선택 기준 하나는 보여야 합니다.
※ 외부 API 장애가 검색 요청 전체로 전파되는 문제를 줄이기 위해 데이터를 내부 DB로 동기화하고, 부분 문자열 검색 요구사항을 고려해 N-gram 인덱스를 적용했습니다.
이 문장은 단순히 “N-gram 적용”이라고 쓰는 것보다 훨씬 많은 정보를 전달합니다.