이 자리가 왜 생겼을까요
토스뱅크 Head of Technology는 2026년 3월 토스 커리어 아티클에서 '은행이기 때문에 숫자 하나도 틀리면 안 되고, 장애가 발생해서는 안 돼요'라고 말했습니다. 같은 인터뷰에서 그는 고객 수가 빠르게 늘고 대용량 트래픽을 다루는 경험도 커지고 있으며, 앞으로 법인 뱅킹과 글로벌 서비스로 확장 폭이 더 클 것이라고 설명했습니다. 이 공고는 SRE팀이 계정계와 채널계를 포함한 전사 시스템을 대상으로 모니터링과 성능 테스트, 장애 대응을 맡는다고 적었습니다. 트래픽이 커지는 서비스에서 성능 테스트로 병목을 미리 찾아 고친 경험이 있다면 테스트 조건과 개선 전후 수치가 함께 있어야 합니다.
토스가 지금 어떤 사업에 집중하고 있는지는 토스 채용 분석에서 이어서 볼 수 있습니다.
1하게 될 업무
시스템의 Stability, Scalability, Availability, Observability 그리고 Latency를 지속적으로 개선합니다.
이렇게 볼 수 있어요
다섯 가지 축이 모두 업무에 들어 있습니다. 이 가운데 무엇을 어떤 수치로 개선했는지가 이력서에 있으면 업무 범위가 바로 전해집니다.
대규모 트래픽 환경에서 원인을 빠르게 분석할 수 있도록 모니터링 및 분석 시스템을 지속적으로 개선하고 자동화합니다.
이렇게 볼 수 있어요
모니터링 도구를 쓰는 쪽보다 만드는 쪽에 가깝습니다. 공고 속 동료의 한마디에도 맞는 오픈소스가 없으면 서버나 웹을 직접 구현한다고 적혀 있어, 사내 운영 도구를 개발한 경험이 쓰입니다.
장애가 발생하면 근본 원인을 찾아 해결하고, 재발 방지를 위한 개발과 설계를 주도하며 해법을 마련합니다.
이렇게 볼 수 있어요
복구 다음 단계인 재발 방지 설계까지 맡습니다. 장애 하나를 원인, 조치, 재발 방지 순으로 정리해 두면 이력서 안내의 'Dive deep' 질문에도 그대로 쓰입니다.
2자격 요건
Java/Kotlin, Spring Framework 관련 개발 경험과 문제해결 능력이 있으면 좋다고 적었습니다.
이렇게 볼 수 있어요
SRE지만 근무 직무는 Server Developer로 적혀 있습니다. 그래서 운영 경험만이 아니라 Spring 기반 서버를 직접 개발한 이력도 이 자리의 경력으로 셉니다.
성능 테스트로 시스템의 가용성을 확인하고 병목지점을 해결할 수 있는 사람이면 좋다는 항목입니다.
이렇게 볼 수 있어요
팀 소개에 성능 테스트 환경을 구축하고 수행한다는 내용이 따로 있습니다. 부하 테스트로 찾은 병목과 고친 뒤의 처리량이 이 항목에 그대로 쓰이는 숫자입니다.
리눅스와 네트워크 시스템에 대한 깊은 이해를 요구합니다.
이렇게 볼 수 있어요
커널 설정이나 네트워크 구간에서 원인을 찾은 장애 사례가 있으면 리눅스·네트워크 이해를 실제 경험으로 보여 줄 수 있습니다.
MSA, Kubernetes, Istio, Redis, Kafka, ELK 기반의 인프라 운영 경험이 있으면 좋다고 적었습니다.
이렇게 볼 수 있어요
토스뱅크가 사용하는 기술 목록에도 같은 이름이 있습니다. 다룬 구성 요소와 규모를 함께 밝히면 범위가 분명해집니다.
Mission-Critical한 서비스 운영 환경을 즐기며 높은 책임감으로 탄탄한 서비스를 함께 만들어 갈 수 있는 사람을 찾습니다.
이렇게 볼 수 있어요
은행 시스템이라 장애가 고객의 금융 거래로 바로 이어집니다. 장애 대응 당번이나 비상 대응 체계에 참여한 경험이 이 항목을 보여 줍니다.
변화를 두려워하지 않고 새로운 기술에 빠르게 적응하며 지속적인 성장을 원하는 사람을 찾습니다.
이렇게 볼 수 있어요
팀이 오픈소스 제품을 실험하고 도입하는 일을 적극적으로 검토한다고 적었습니다. 새 도구를 도입해 운영 방식을 바꾼 사례가 이 요건의 '새로운 기술에 빠르게 적응'에 대한 답입니다.
4기타 사항
- 게시일 : 2022년 5월 17일
- 고용형태 : 정규직
- 근무지 : 서울특별시 강남구 테헤란로 131, 13층 (역삼동, 한국지식재산센터) (추정)
- 경력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
- 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
쓰는 기술
공고 본문에 적힌 기술만 모은 목록입니다.
- Kotlin
- Java
- Gradle
- Netty
- Spring Mvc
- Spring Webflux
- Spring Boot
- Spring Cloud Gateway
- Spring Cloud Config
- JPA/Hibernate
- MySQL
- MongoDB
- Oracle
- Hadoop
- Redis
- Zookeeper
- Kubernetes + Istio
- HAproxy
- Nginx
- GoCD
- ArgoCD
- Consul
- Vault
- Git
- Docker
- Ceph
- Harbor
- Kafka
- ELK
- Prometheus + Thanos
- Grafana
전형과 지원
토스커뮤니티는 합류 여정을 한 페이지로 공개해 두었습니다. 공통 골격은 같지만 계열사와 공고에 따라 단계가 더해지거나 빠지므로, 공고 페이지에 적힌 단계를 함께 확인해야 합니다.
기본 다섯 단계
지원서 접수, 직무 인터뷰, 문화적합성 인터뷰, 레퍼런스 체크, 처우 협의와 합류 결정 순입니다. 안내에는 '포지션에 따라 사전 과제 / 전화 인터뷰 등의 전형이 추가될 수 있어요'라고 적혀 있습니다.
이렇게 볼 수 있어요
공고마다 앞 단계가 다르므로 일정을 잡을 때 공고 페이지를 먼저 봐야 합니다. 같은 계열사 안에서도 사전 과제가 붙은 공고와 없는 공고가 섞여 있습니다. 토스뱅크 Customer Success Specialist(계약직)와 토스 Financial Data Analyst (FP&A) 공고는 레퍼런스 체크와 처우 협의 없이 문화적합성 인터뷰 뒤 바로 최종 합격으로 갑니다. 둘 중 하나만 빠진 공고도 있습니다. Category MD (신선식품 Unit Leader - 과일, 채소), Category MD (뷰티), Category MD (가공식품), Search Quality Operations Manager 공고는 처우 협의가 레퍼런스 체크보다 먼저 옵니다.
문화적합성 인터뷰가 따로 있다
'인터뷰어는 토스의 핵심가치를 누구보다 잘 이해하고 있는 동료들로 구성되어 있어요'라고 적혀 있고, '지원자를 검증하기 위해 일방적으로 질문을 던지는 것이 아니라, 토스커뮤니티 문화에 대해 서로 진솔한 대화를 나누는 방식으로 진행해요'라고 설명합니다.
이렇게 볼 수 있어요
직무 경험만 준비하면 한 단계를 비워 두게 됩니다. 핵심가치 네 가지에 각각 대응하는 본인 사례를 미리 한 개씩 정리해 두면 이 단계에서 꺼낼 것이 생깁니다.
인터뷰는 전부 온라인이다
'모든 인터뷰는 온라인(Google Meet/ Zoom)으로 진행하고 있어요'라고 적혀 있고 '최대한 1:1 커뮤니케이션을 지향'한다고 밝혔습니다. 인터뷰어는 '합류하신다면 가장 많은 협업을 하게 되실 동료들'입니다.
이렇게 볼 수 있어요
이동 시간이 들지 않아 재직 중에도 일정을 잡기 쉽습니다. 안내가 조용한 개인 공간과 이어폰 사용을 권하고 있으므로 환경을 미리 확인해 두는 편이 좋습니다.
지원서는 자유 양식이다
'지원자분의 역량을 최우선적으로 검토하기 위해 자유 양식의 지원서를 받고 있어요'라고 적혀 있습니다. 개발 직군은 '기술 숙련도를 파악하기 위해 이력서 상에 기술 스택을 꼭 작성해 주세요'라는 요구가 따로 붙습니다.
이렇게 볼 수 있어요
정해진 문항이 없으므로 무엇을 보여 줄지 직접 정해야 합니다. 안내는 경험을 나열하기보다 '임팩트와 러닝 포인트'를 적으라고 했고, 주민등록번호와 자택 주소, 연봉은 필수가 아니라고 밝혔습니다. 제출은 PDF를 권합니다.
계열사 간 중복 지원이 된다
'원하는 포지션이라면 계열사 간 중복 지원도 가능해요'라고 적혀 있습니다. 토스, 토스뱅크, 토스페이먼츠, 토스인슈어런스, 토스증권, 토스씨엑스 등이 함께 열거돼 있습니다.
이렇게 볼 수 있어요
같은 직무를 여러 계열사가 채용하고 있을 때 하나만 고를 필요가 없습니다. 다만 계열사마다 도메인이 다르므로 지원서의 강조점은 각각 맞추는 편이 낫습니다.
지원 전 준비할 것
- 1
임팩트와 러닝 포인트로 쓰기
이력서 안내가 경험을 단순히 나열하지 말고 경험 속 임팩트와 러닝 포인트를 보여 달라고 했습니다. 장애 대응이나 개선 프로젝트마다 무엇이 바뀌었고 무엇을 배웠는지 한 줄씩 붙여 두세요.
- 2
스스로 찾아낸 안정성 문제 고르기
안내는 서비스 안정성을 높이려고 스스로 문제를 찾아 해결해 본 경험과, 운영 중인 시스템을 크게 개선했거나 새로운 것을 도입해 생산성·효율성을 높인 경험이 궁금하다고 적었습니다. 누가 시키기 전에 발견한 문제였다는 점이 드러나게 시작 시점을 밝혀 두세요.
- 3
트래픽 급증을 고려한 설계 사례 정리하기
대규모 트래픽이나 순간 트래픽이 급증하는 환경을 고려해 설계부터 효율성을 강조해 개발한 경험도 안내의 질문 목록에 있습니다. 예상 트래픽을 어떻게 잡았고 실제 트래픽에서 어떻게 버텼는지를 나란히 정리하면 직무 인터뷰에서도 이어서 말할 수 있습니다.