이 자리가 왜 생겼을까요
토스 기술 블로그의 2025년 10월 글에 따르면 토스페이먼츠는 2020년 8월 20년 넘게 운영된 레거시 PG 시스템을 인수하며 출범했습니다. 같은 글은 지난 5년 동안 MSA 전환과 Kubernetes 도입을 포함해 시스템을 9단계로 개선해 왔다고 설명했고, 내부 MSA 서비스 수가 150개가 넘는다고 적었습니다. 2023년 4월에 처음 게시된 이 공고는 3년 이하 개발자에게 무중단 배포가 가능한 MSA 환경에서 새 API를 만들고 정산 시스템과 OpenAPI를 맡기는 일을 적었습니다. 이력서 안내에도 레거시 코드를 리팩토링해 본 경험이 있으면 좋다는 항목이 있습니다. 연차가 짧더라도 오래된 코드를 고친 사례가 있다면 무엇을 바꿨고 그 뒤 무엇이 쉬워졌는지가 이 자리에서 맡을 일과 바로 이어집니다.
토스가 지금 어떤 사업에 집중하고 있는지는 토스 채용 분석에서 이어서 볼 수 있습니다.
1하게 될 업무
지속적으로 증가하는 결제 요청량과 다양한 요구사항을 쉽게 구현할 수 있도록 확장성과 유연성이 높은 시스템을 만듭니다.
이렇게 볼 수 있어요
요청량과 요구사항이 함께 늘어나는 환경입니다. 기능을 추가하면서 구조를 바꿔 다음 기능을 쉽게 만든 경험이 있다면 연차가 짧아도 이 업무와 연결됩니다.
선착순 결제 같은 이벤트로 수십 배의 트래픽이 순간적으로 발생해도 무너지지 않는 시스템을 만듭니다.
이렇게 볼 수 있어요
평소 트래픽보다 순간 최대치를 견디는 설계를 다룹니다. 부하 테스트나 캐시, 큐로 트래픽 급증을 버텨 본 경험이 작게라도 있으면 쓸 수 있는 사례입니다.
수많은 거래를 수백 가지 요구사항에 맞춰 계산해도 빠르고 오차 없는 정산 시스템을 만듭니다.
이렇게 볼 수 있어요
정산은 계산이 틀리면 가맹점에 지급되는 금액이 달라집니다. 숫자의 정합성을 테스트로 지켜 본 경험이 있다면 어떤 경우를 테스트했는지 밝혀 두세요.
자유로운 무중단 배포가 가능한 MSA 환경에서 사업자의 비즈니스 어려움을 해결할 새로운 API를 만듭니다.
이렇게 볼 수 있어요
무중단 배포가 되는 MSA 환경은 이미 갖춰져 있고, 그 위에 새 API를 더해 갑니다. 서비스 사이의 통신이나 배포 파이프라인을 다뤄 본 경험이 이 환경에서 바로 쓰입니다.
토스페이먼츠와 고객사 시스템의 접점이 되는 OpenAPI와 OpenAPI를 지탱하기 위한 생태계를 만듭니다.
이렇게 볼 수 있어요
고객사 개발자가 직접 호출하는 API입니다. 외부에 공개하는 API를 설계하거나 문서화해 본 경험이 있다면 호출하는 개발자를 위해 무엇을 정했는지가 이 업무에서 바로 쓰입니다.
2자격 요건
공고 제목에 경력 조건으로 '3년 이하'가 적혀 있고, 본문에는 자격 요건과 우대 사항 절이 따로 없습니다.
이렇게 볼 수 있어요
경력 상한만 있고 기술이나 도메인 요건은 적혀 있지 않습니다. 대신 공고의 '토스페이먼츠가 사용하는 기술'에 Java, Kotlin, Spring 계열과 MySQL, Redis, Kafka 등이 있습니다. 토스커뮤니티 합류 안내도 개발 직군은 이력서에 기술 스택을 꼭 적어 달라고 했습니다.
4기타 사항
- 게시일 : 2023년 4월 5일
- 고용형태 : 정규직
- 근무지 : 서울특별시 강남구 테헤란로 131, 14층 (역삼동, 한국지식재산센터) (추정)
- 경력 조건 : 경력 3년 이하
- 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
쓰는 기술
공고 본문에 적힌 기술만 모은 목록입니다.
- Java
- Kotlin
- Gradle
- Spring MVC
- Spring Webflux
- Spring Batch
- JPA
- Spring Cloud Gateway
- Spring Cloud Config
- Netty
- MySQL
- Redis
- ElasticSearch
- Kafka
- Oracle
전형과 지원
토스커뮤니티는 합류 여정을 한 페이지로 공개해 두었습니다. 공통 골격은 같지만 계열사와 공고에 따라 단계가 더해지거나 빠지므로, 공고 페이지에 적힌 단계를 함께 확인해야 합니다.
기본 다섯 단계
지원서 접수, 직무 인터뷰, 문화적합성 인터뷰, 레퍼런스 체크, 처우 협의와 합류 결정 순입니다. 안내에는 '포지션에 따라 사전 과제 / 전화 인터뷰 등의 전형이 추가될 수 있어요'라고 적혀 있습니다.
이렇게 볼 수 있어요
공고마다 앞 단계가 다르므로 일정을 잡을 때 공고 페이지를 먼저 봐야 합니다. 같은 계열사 안에서도 사전 과제가 붙은 공고와 없는 공고가 섞여 있습니다. 토스뱅크 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를 권합니다.
계열사 간 중복 지원이 된다
'원하는 포지션이라면 계열사 간 중복 지원도 가능해요'라고 적혀 있습니다. 토스, 토스뱅크, 토스페이먼츠, 토스인슈어런스, 토스증권, 토스씨엑스 등이 함께 열거돼 있습니다.
이렇게 볼 수 있어요
같은 직무를 여러 계열사가 채용하고 있을 때 하나만 고를 필요가 없습니다. 다만 계열사마다 도메인이 다르므로 지원서의 강조점은 각각 맞추는 편이 낫습니다.
이 공고만 다른 점
서류접수 다음이 사전과제이고, 그 뒤로 직무 인터뷰, 문화적합성 인터뷰, 레퍼런스 체크, 처우협의, 최종 합격 및 입사 순입니다.
회사 공통 단계에 사전과제가 하나 더 붙습니다. 과제의 형태는 공고에 적혀 있지 않으므로 서류를 낸 뒤 과제에 쓸 시간을 따로 확보해 두는 편이 안전합니다.
합류할 팀은 인터뷰 과정을 거치며 본인의 강점과 백그라운드를 고려해 조율됩니다.
지원할 때 팀을 고르지 않습니다. 결제, 정산, OpenAPI 가운데 더 해 보고 싶은 영역이 있다면 인터뷰에서 그 이유와 함께 말할 수 있습니다.
채용 진행 과정과 최종 배치에 따라 소속 법인이 토스페이먼츠에서 신규 법인으로 바뀔 수 있습니다. 공고는 바뀌더라도 보상 체계와 복리후생은 토스커뮤니티의 기준과 같게 적용된다고 적었습니다.
어느 법인 소속이 되는지는 배치가 정해질 때 결정됩니다. 처우 협의 단계에서 소속 법인을 확인해 두세요.
지원 전 준비할 것
- 1
해결해 본 문제를 구체적으로 쓰기
이력서 안내가 해결해 본 문제의 규모와 상관없이 개발과 관련한 문제 상황을 개선하거나 해결한 내용을 최대한 구체적으로 적어 달라고 했습니다. 작은 버그 수정이라도 원인을 찾은 과정과 고친 뒤의 변화를 함께 쓰면 됩니다.
- 2
리팩토링 경험 정리하기
레거시 코드를 리팩토링해 본 경험이 있으면 좋다는 항목이 안내에 따로 있습니다. 바꾸기 전 구조의 문제와, 바꾼 뒤 테스트나 배포가 어떻게 달라졌는지를 나눠 정리하세요.
- 3
비즈니스 문제를 기술로 푼 사례 고르기
안내는 기술자로서 비즈니스의 문제를 해결한 경험과 그 과정에서 활용한 기술적 장점이 드러나는 사례를 자세히 적어 달라고 했습니다. 기능 요청을 그대로 구현한 사례보다 요청 뒤의 문제를 다시 보고 설계를 바꾼 사례가 이 요청에 맞습니다.