2025년 이직 회고 (숨고 최종합격)

dwchoi99·2025년 5월 28일
128
post-thumbnail

이직을 결심한 이유

noondate

가장 큰 이유는 백엔드 엔지니어로서 성장하기 위해 이직이 필요하다고 판단했기 때문이다. 재직중인 정오의데이트(이하 정데)는 500 RPS 규모로 트래픽이 꽤 많이 발생하고 있었지만, 백엔드 엔지니어는 나와 CTO님 단 두 명뿐일 정도로 조직 규모가 작아 시도해볼 수 있는 것들에 한계가 있었다.

예를 들어서 MSA를 도입하려고 해도 각 서비스의 배포, 모니터링, 장애 대응을 모두 소수의 인원이 감당해야 하므로 오히려 오버엔지니어링이 될 가능성이 컸다. 이러한 조직 규모의 한계가 이직을 결심한 결정적인 계기가 되었다.

반면, 조직이 작다는 건 곧 내가 해보고 싶은 것들이 합리적이라면 직접 설득해 시도해볼 수 있다는 의미이기도 했다. 실제로 이직을 결심하기 전까지는 다양한 도전을 통해 가파른 성장 곡선을 그릴 수 있었다. 예를 들어, ECS 기반의 인프라 재구성, 웹뷰 시스템을 Next.js로 전환하는 등의 작업을 통해 백엔드뿐만 아니라 인프라와 프론트엔드 영역까지 경험을 넓힐 수 있었다.

물론 백엔드 측면에서도 PHP 기반의 레거시 시스템을 Python + FastAPI로 마이그레이션하거나, 신규 서비스의 백엔드를 처음부터 런칭까지 주도하는 등, 스타트업에서 경험할 수 있는 기회는 밀도 있게 쌓아왔다. 이처럼 할 수 있는 건 거의 다 해본 느낌이라, 개인적으로는 큰 아쉬움 없이 마무리할 수 있었던 것 같다. (물론 CTO님은 많이 아쉬워 하셨다…)


이직 준비

이력서 준비과정

포맷 선정

legacy-resume

처음에는 이력서를 노션으로 작성했다. 이전에 이직할 때도 노션으로 작성했고, 당시에는 별다른 불편함을 느끼지 못했기 때문에 이번에도 노션 이력서를 채택했었다.

하지만 여러 레퍼런스들을 찾아보고, 이력서를 잘 작성하는 방법들에 대한 자료들을 여럿 보다 보니 플랫폼을 변경할 필요성을 느끼게 되었다. 얻은 인사이트와 주변 지인들의 피드백을 받았을 때 공통으로 나온 문제점은 다음과 같다.

  1. 이력서 포맷에 차별성이 없기 때문에 눈에 잘 띄지 않는다.
  2. 페이지가 많아서 검토할 때 지루하고 핵심 내용을 파악하기 어렵다.

위와 같은 문제 인식을 기반으로 새로운 플랫폼을 찾아보았는데,

결론적으로 피그마를 사용하기로 했다. 이유는 이미 사내에서 디자인 툴로 사용하기도 했고, 이전에 사이드프로젝트 UI 디자인을 하면서 사용했던 경험도 있기 때문이다. 그리고 무엇보다 이력서의 형태에 제한 없이 내 맘대로 만들어 나갈 수 있다는 점이 매력적이었다.

figma-template

피그마로 옮겨가면서 이력서 포맷을 내가 원하는 포맷으로 수정할 수 있게 되었기 때문에 1번의 문제는 해결되었다. 물론 시간이 너무 오래 걸리기 때문에 내가 처음부터 포맷을 디자인하지는 않았고, 피그마 커뮤니티에서 마음에 드는 이력서 템플릿 하나를 골라서 커스텀해서 사용했다.

new-resume

페이지가 많았던 문제도 기존의 내용을 압축하고 글자 크기와 행간을 줄여서 기존의 3페이지에서 2페이지로 줄여서 2번의 문제도 해결할 수 있었다.

나처럼 한 직장에서 3년 이상 다닌 경우 수행한 업무들이 여러 가지 있을 텐데 나는 그중에서 기술적으로 어려운 문제를 해결했거나 비즈니스 임팩트가 큰 것들에 대해서만 작성했다. 임팩트가 작은 여러 업무를 정량적인 수치 없이 나열해 봤자 별다른 흥미가 생기지도 않고, 역량 검증 측면에서도 큰 의미가 없다고 생각하기 때문에 필요 없는 내용들은 과감하게 모두 제거했다. (전 직장 이력들은 대부분 제거) 그리고 대부분의 내용은 ‘문제정의 → 해결 방안 제시 → 성과’ 형태 안에서 작성했다. 특히 최근에는 AI 발전의 영향 때문인지 문제를 어느 경로로 인식했고, 그걸 어떻게 정의하는지가 꽤 중요해진 것 같다.

나열한 순서에 대해서는 검토자가 흥미를 느낄만한 순서대로 배치했다. 개인적으로 수치가 명확하게 나와 있는 내용이 흥미를 느낄만한 내용이라고 생각하기 때문에 AWS 비용 최적화와 성능 개선 순으로 배치했다.

레퍼런스는 여러 글과 유튜브 영상들을 참고했는데, 내 이력의 경우 주로 기술적인 내용을 담고 있어서 1~2페이지 내로 핵심 내용을 전달하는 미국식 이력서 포맷이 좋겠다는 생각이 들어서 이를 채택했다. 국내 이력서 중에서는 정겨울님 이력서가 특히 잘 쓰였다고 생각해서 많이 참고하게 되었다. 이 외에도 개발자 이력서를 작성해 보신 분들은 한 번쯤은 참고했을 법한 워니님의 ‘개발자 이력서 작성하기’라는 글도 다시 한번 참고하면서 수정했다.

피드백 요청

작성하면서 중간중간에 주기적으로 개발자 지인분들께 피드백 요청을 드려가면서 수정해 나갔다.

자기소개 내용이나 이력서 포맷에 대한 부분은 충분히 피드백을 받을 수 있었지만, 주변에 알고 있는 백엔드 개발자분들이 몇 분 없어서 기술적인 측면에서 현재 내용만으로 역량을 충분히 검증할 수 있을지 확신이 없었다. 그러던 중 유튜브 커뮤니티에 토스 서버 개발자 출신이신 딩코딩코님이 이력서 피드백을 해준다는 글을 접하게 되었는데, 좋은 기회라고 생각되어서 신청해서 피드백을 요청드렸다.

feedback1

feedback2

감사하게도 상세하게 피드백을 주셨다. 기술적으로 좋은 평가를 해주신 덕분에 작성한 내용이 기술적인 역량을 검증하기에도 괜찮은 수준이라는 것을 검증받을 수 있었다. 그리고 필요 없는 내용들도 제거할 수 있었다. 기존에는 버리기 아깝다는 생각과 백엔드 포지션이어도 프론트 역량을 어필하면 의미 있겠다는 생각이 들어서 남겨둔 프론트 내용들을 과감하게 모두 제거해서 백엔드 역량을 어필하는 데 집중했다.

우대사항으로 들어가 있지 않은 경우에는 기본적으로 본인이 지원하는 포지션에 맞는 스택으로 구성하는 게 검토자 입장에서 지원자의 역량을 더 잘 파악하는 데 도움이 될 수 있을 것 같다. (포지션 직무 외 내용은 모를 가능성이 높으므로) 이력서의 전체적인 임팩트도 더 높아질 것으로 생각한다.

이처럼 피드백 요청은 제 3자의 입장에서 바라보기 때문에 내가 인지하지 못한 부분에 대해서 알 수 있어서 꼭 요청하는 것을 추천한다. 만약 나처럼 주변에 관련된 직군의 지인이 많이 없다면 외부 커뮤니티를 활용하거나 이도 어렵다면 인프런 멘토링을 활용해 봐도 좋을 것 같다.


각 전형 후기

결과 요약

summary

이보다는 더 많은 곳을 지원했지만, 그중에서도 서류 이후 단계로 진행하고 얘기할 만한 내용들이 있는 전형에 대해서만 다뤄보려고 한다.

기술스택에 대한 고민 (번외)

내가 주로 다루는 언어가 Python과 PHP인데 그 때문인지 JVM을 메인으로 사용하는 포지션은 모두 서류 탈락을 경험했다. 기존에는 어려운 문제를 해결한 경험이나 공통으로 사용되는 CS 지식이 중요하다는 생각이 있었다. 물론 지금도 그렇게 생각하지만, 합격률에는 내가 사용하는 기술 스택이 지원하는 포지션과 얼마나 맞는지가 꽤 큰 영향을 준다는 사실을 알게 됐다.

물론 기술적으로 아웃라이어 영역에 있는 분들은(오픈소스 메인테이너 등) 기술 스택이 맞지 않는 장벽을 쉽게 뛰어넘을 수도 있겠지만, 서류 합격률이라는 정량적인 수치를 맞닥뜨려보니 보통의 경우에는 어려울 수 있겠다는 생각이 들었다. 이러한 고민으로 JVM을 메인으로 사용하는 배민이나 카카오 개발자분들과 커피챗을 해보니 실제로 영향이 크다는 것을 알 수 있었다.

여전히 기술 스택에 대한 고민은 있지만 Python을 주 언어로 사용하고 있으니 이를 강점으로 승화시켜서 ML 쪽의 역량을 키우거나, 앞으로의 계획에 해외 취업에 대한 고민도 하고 있으니 (아직은 영어가 부족해서 어렵지만…) 여러 가지를 시도해 보면서 돌파구를 찾아야겠다고 생각하고 있다.


버즈니

서류

buzzni-docs

버즈니는 플레이스토어 기준 1,000만+ 다운로드 수인 ‘홈쇼핑모아’를 개발하는 곳이다. 이러한 배경을 봤을 때 대규모 트래픽을 경험해 볼 수 있겠다는 생각이 들어서 지원하게 되었다. 여러 팀 중에서 서비스 스쿼드로 지원했고 약 1주일 정도 뒤에 서류 결과를 받아 볼 수 있었다.

사전과제

과제 내용은 생각했던 것과는 큰 차이가 있었는데 서비스 스쿼드이다 보니 API를 구현하는 내용일 것이라고 예상했지만 난이도 있는 기능을 구현하는 데 초점이 맞춰져 있었다. 그리고 구현해야 할 기능도 러닝 커브가 필요한 생소한 영역이었기 때문에 처음에는 좀 막막했던 기분이 들었던 것 같다. 하지만 하다 보니 오히려 해보지 않은 영역이어서 흥미를 느끼고 학습해 나가면서 구현해 나갔던 것 같다.

buzzni-subject

열심히 리서치하고 학습하면서 구현했지만 내가 보기에도 아쉬운 부분들이 많았기 때문에 예상했던 대로 탈락이라는 결과를 받았다. 그런데 버즈니에서 AI커머스 포지션으로 다시 제안을 주셨다.

과제 내용을 확인해 보니 이쪽이 API 구현하는 내용이었고 내가 원하는 직무와 더 가깝다는 생각이 들었다. 하지만 당시에는 이미 일주일 동안 과제를 진행하다 보니 에너지가 적은 상태였고 다른 전형도 진행 중이어서 해당 제안은 정중하게 거절하게 되었다. 처음부터 해당 포지션으로 지원했다면 좋았을 텐데 하는 아쉬움이 남았다.



AB180

서류

ab180-docs

링크드인을 통해서 사내 채용 담당자분이 직접 제안을 주셔서 전형을 진행하게 되었다.

사실 AB180은 기술 블로그를 통해서 인상적으로 본 글들도 많고, 내용도 정말 좋다고 느꼈기 때문에 기술적으로 뛰어난 조직이라는 인식이 있었다. 그뿐만 아니라 B2C 업계에서는 데이터 분석 도구로 앰플리튜드와 에어브릿지를 많이 사용하고 있었기 때문에 서비스 자체에 대한 흥미도 있었다.

결정적으로는 제안받은 포지션인 Platform 팀에서는 매일 10억 개 이상의 이벤트 데이터가 발생하기 때문에 합류하면 대규모 트래픽을 제대로 경험해 보겠구나 싶어서 기쁜 마음으로 전형을 진행했다.

사전과제

사전과제는 에어브릿지 내 기능 중 하나를 구현해 보는 내용이었다. 개인적으로는 AB180의 과제가 지원자의 백엔드 역량을 가장 잘 검증할 수 있도록 설계되었다고 느꼈다. 캐싱, 데이터베이스 설계, 대규모 트래픽 처리, 예외 처리, 테스트케이스, 고가용성 등 과제라는 한정적인 상황에서도 지원자가 고민해야 할 지점들이 많았고 그만큼 난도가 높았던 것 같다.

하루 동안 정말 몰입해서 구현했지만 아쉽게도 전형은 통과하지 못했다. 고려해야 할 부분들이 많았기 때문에 어느 부분이 통과하지 못한 요인이 되었는지는 아직 잘 모르겠지만, ‘가상면접 사례로 배우는 대규모 시스템 설계 기초’ 책을 보면서 공부했던 내용들을 실제로 적용해 볼 수 있는 기회가 되어서 좋은 경험이 되었다.



올거나이즈

서류

allganize-docs

블라인드 하이어를 통해서 제안을 받아서 전형을 진행했다. 공고를 몇 번 스쳐 지나가면서 본 기억은 있었지만, 서비스에 대해서는 잘 몰랐는데 찾아보니 ‘알리’라는 B2B 챗봇 솔루션을 개발하는 곳이었다. 대표님이나 CTO님의 이력이 기술적으로 뛰어나 보였고, 국내뿐만 아니라 일본에서도 유의미한 성과를 내는 곳이라고 생각되어서 전형을 진행하게 되었다.

코딩테스트

코딩테스트는 coderbyte라는 플랫폼에서 진행했다. 문제는 모두 영문이었고 난이도는 릿코드 이지, 미디엄 정도의 난이도로 출제되었다. 특이한 점으로는 알고리즘 문제 외에도 서술형 문제가 있었다. 제출하고 약 5일 뒤에 합격 결과를 받아서 1차 인터뷰을 진행하게 되었다.

1차 기술 인터뷰

내 이력에 대한 질문을 받기보다도 직접 설명하는 형식으로 진행됐다. 거기서 꼬리 질문을 하면서 검증하는 방식으로 진행될 것이라고 예상했는데 별다른 질문이 없어서 역량을 깊게 검증받는 느낌이 들지 않았다. 이력서 외에도 프로젝트 기술서도 요구했었는데 이에 대한 내용에서도 질문이 없었고, 코딩테스트 관련된 질문도 들어오지 않아서 의아했다.

가장 납득이 되지 않는 부분은 이력 중에 레디스를 다뤄본 내용이 있었지만 NoSQL DB를 사용해 본 적이 있는지 질문하셨다. 그래서 레디스를 사용한 경험이 있다고 답변을 드렸는데, 레디스가 NoSQL DB가 아니라고 하셨다. ‘이후에 MongoDB를 사용해 본 경험이 있는지?’로 다시 질문을 주셔서 취지는 이해가 됐으나 ‘레디스가 NoSQL DB가 아니다’에 대한 내용은 납득이 가지 않아서 관련해서 역질문을 드렸다. 하지만 명쾌한 해답은 듣지 못해서 이후 인터뷰를 진행하는 시간이 아깝다는 생각이 들었던 것 같다.

위의 경험들로 인해서 인터뷰 경험이 좋지는 않았지만, 그래도 도움이 되는 부분이 있었다. 자료구조에 대해서 만약 직접 구현하면 어떤 방식으로 구현할 수 있을지, 그리고 해당 자료구조의 pop, push, search 등 각 기능의 시간복잡도는 어느 정도 소요될지 질문을 해주셨다. 자료구조의 기본적인 개념은 알고 있었지만 깊이 있게는 알지 못해서 제대로 답변하지 못했다. 덕분에 인터뷰이 끝나고 나서 깊이 있게 공부할 필요성을 느끼게 되었고, 블로그에 정리해 나가면서 학습하고 있다. (자료구조 개념정리 1편 - 배열, 연결 리스트, 자료구조 개념정리 2편 - 스택, 큐, 해시 테이블) 결과는 예상했던 대로 인터뷰을 보면서 핏이 맞지 않는 느낌을 받기도 했고, 답변이 부족한 부분도 있었기 때문에 전형은 통과하지 못했다.



에이블리

서류

ably-docs

에이블리에 재직 중인 지인분에게 제안을 받아서 내부 추천으로 전형을 진행하게 되었다. 지원 날짜를 기록하지 않아서 정확하지 않지만 2~3일 정도 뒤에 결과를 받아본 것 같다. 서류 전형은 합격해서 이후 전형인 전화 인터뷰 일정을 잡았다.

전화 인터뷰

ably-phone-interview

전화 인터뷰는 HR 분과 컬쳐핏에 대한 내용으로 30분 정도 간단하게 얘기를 나눴다.

대략 아래와 같은 질문을 받았고 이후에는 역질문하는 시간을 가졌다.

  • 이직을 고려하고 있는 이유가 무엇인지?
  • 평소에 업무 스타일이 어떻게 되는지?
  • 선호하는 동료 유형이 있는지?
  • 불가피하게 본인이 담당하고 싶지 않은 업무를 맡은 적이 있는지? 있다면 어떻게 대처했는지?

일하는 방식에 대해서 추천해 주신 분과 평소에 의견을 많이 공유했기 때문에 에이블리의 핵심 가치와 문화에 대해서는 어느 정도 알고 있었다. 그 과정에서 나도 에이블리의 문화에 일부분 공감하고 있었고, 업무를 하면서 녹여내고 있던 부분도 있어서 무난하게 잘 대답할 수 있었던 것 같다. 바로 다음 날에 합격이라는 결과를 받았다.

사전과제

ably-subject

비밀유지확약서를 작성했기 때문에 관련된 내용은 작성할 수 없다는 점을 먼저 말씀드린다. 간단하게 느낀 점을 말하자면 백엔드 엔지니어 직무에 대한 기본적인 역량을 잘 검증할 수 있도록 구성되어 있다고 느꼈다. 디테일한 요구사항이 적혀 있기보다 기능과 관련된 기본적인 요구사항에 대해서만 제시했는데, 이 부분은 지원자가 자율적으로 다양한 케이스를 고려해서 설계하라는 의미로 볼 수도 있을 것 같다. 과제 제출 후 3일이 지나서 합격 결과를 받았다.

1차 기술 인터뷰

기술 인터뷰에서는 처음에는 내 이력을 기반으로 질문을 해주셨다. 답변에 대해서 꼬리 질문을 여러 번 해주시면서 깊이 있게 검증했는데 꼬리 질문에 대한 대비를 3뎁스까지 해두어서 이력서 기반의 질문에 대해서는 무난하게 대답할 수 있었던 것 같다. 이 외에도 문제 인식을 어떻게 하고, 문제 정의를 어떻게 하는지와 같이 업무 수행 방식을 알기 위한 취지의 질문도 들어왔던 것 같다.

두 번째로는 사전 과제와 관련된 내용에 대해서 질문을 해주셨는데 구현한 내용을 기반으로 문제 상황을 가정하고 그에 대해서 어떻게 대응하고, 개선할지에 대한 질문들을 해주셨다. 개인적으로 엄청 예리한 질문들이 많았다고 생각한다. 덕분에 이후에 다른 회사의 전형을 준비하는 데에서도 도움이 많이 됐다.

한 가지 예시를 들자면 나의 경우에는 인가 기능을 JWT로 구현했는데 ‘만약 액세스 토큰이 탈취되면 어떤 식으로 대응할 건지?’와 같은 질문이 있었다. 당시에는 RTR(Refresh Token Rotation)과 같은 기법을 몰랐기 때문에 즉흥적으로 생각하면서 버벅대면서 대답했었는데 인터뷰가 끝난 후 자세하게 알아본 덕분에 다른 전형에서는 이를 보완할 수 있었다.

이후로는 컬쳐핏과 관련해서 몇 가지 질문이 있었는데 그중 ‘선호하지 않는 업무가 있었는지?’라는 질문에 대해서 잘 대답하지 못했던 기억이 있다. 유저 경험을 해치는 업무를 선호하지 않는다고 답변했는데 그 사례가 명확하게 떠오르지 않아서 엉뚱한 답변을 했었다. 꼬리 질문으로 들어온 ‘광고도 유저 경험을 해칠 수 있는데 이에 대해서는 어떻게 생각하는지?’라는 질문에 대해서도 ‘광고도 유저 경험을 해치기 때문에 최대한 지양해야 한다’와 같은 내용으로 답변했던 것 같다. 당시에는 유저 경험과 회사의 비지니스 사이의 균형에 대해 고민을 하지 않고, 단순히 유저 경험에만 치우쳐져서 생각하다 보니 나온 답변이었다. 이 질문을 받은 이후로 유저 경험과 회사의 비즈니스 사이의 균형에 대해서 고민하게 된 계기가 되었다.

결과는 2일 뒤에 나왔는데 아쉽게도 탈락이라는 결과를 받게 되었다.



토스

토스는 가장 합류하고 싶던 팀이었다. 사실 토스 팀의 팬이라고 봐도 될 것 같다. SLASH, Simplicity, PO Session, 유난한 도전 등 토스 관련 콘텐츠는 대부분 챙겨보는 것 같다. 볼 때마다 느끼는 점은 정말 치열하게 일하면서도 재밌게 일한다는 느낌을 받았다. 이런 콘텐츠를 소비하면서 자연스럽게 나도 토스 팀에서 한 번쯤은 일해보고 싶다는 생각이 들었다.

서류

toss-subject

Python Developer(Platform) 포지션으로 지원했는데, 일단 Python Developer를 선택한 이유는 당연하지만, 자격요건과 우대사항에 일치하는 포지션이었기 때문에 합격할 가능성이 높았기 때문이다. 나는 기본적으로 언어나 프레임워크를, 문제를 해결하는 도구로 바라보지만 (문제 해결에 적합한 스택을 유연하게 선택한다는 측면에서), 이 생각과는 별개로 능숙한 도구를 사용할 때 최대의 역량을 발휘할 수 있는 것도 사실이기 때문에 해당 포지션에 지원했다. 다만 지원하기 전에 몇 가지 우려가 있었다.

첫 번째는 해당 포지션에서 ‘대규모 트래픽을 경험할 수 있는가?’였다. 왜냐하면 JD를 봤을 때 토스 서비스의 방대한 트래픽을 처리하는 포지션은 Server Developer에 가깝다는 생각이 들었기 때문이다. 이에 대한 걱정은 SLASH24에 참여해서 Platform 팀에 대한 얘기를 나눠보면서 해소할 수 있었다. Platform 팀에서는 토스 서비스의 공통적인 기능을 일부분 담당하게 되면서 대규모 트래픽을 처리하는 경험도 해볼 수 있을 것이라는 답변을 들었기 때문이다. 이러한 이유로 나는 Internal Product 팀 대신에 Platform 팀을 선택하게 되었다.

서류를 제출하고 나서 결과 안내까지 2주 정도가 소요되었다. 사실 전에 지원했을 때도 하루 만에 결과가 나왔고 후기에서도 이만큼 오래 걸렸던 적은 없었기 때문에 탈락을 예상했으나 예상과 다르게 합격이라는 안내를 받을 수 있었다. 아마 결과를 기다리면서 이 글을 보고 있는 분들도 있을 텐데 나 같은 사례도 있으니, 결과가 나올 때까지는 모른다고 얘기해주고 싶다.

직무 인터뷰

toss-tech-interview

전날에 Pycon이라는 파이썬 관련 컨퍼런스를 참석하고 바로 다음 날에 직무 인터뷰를 진행했는데, 재밌게도 면접관 중 한 분이 전날 Pycon 토스 부스에서 인사를 나눴던 분이었다. 덕분에 아이스브레이킹 되면서 좋은 분위기로 인터뷰를 시작할 수 있었다.

위에서 언급한 것처럼 사실 약 1년 전에 동일한 포지션으로 지원했던 이력이 있다. 당시에는 문화 적합성 전형에서 탈락이라는 결과를 받았는데, 그 때문에 주로 1년 전 이후의 이력에 관해서 얘기를 나눴다. 이번에도 어김없이 이전처럼 토스의 직무 인터뷰는 가장 난도가 높았던 것 같다. 어떤 내용에 관해서 설명하면 정말 깊게 꼬리 질문이 이어진다. 그 기술을 선택한 이유 (장단점, 비교군에 비해 나은 점 등), 기술의 원리적인 부분, 문제를 발견한 경로와 정의 과정, 해결한 방법과 예외 케이스에 대한 질문 등 내 이력에 대해서 정말 자세하게 정리하고 가야 답변을 잘할 수 있다고 느꼈다.

개인적으로는 전보다는 대답에 부족한 부분도 많다고 생각했고, 결과 안내까지 2주 정도 소요되어서 이번에는 진짜 탈락이라고 생각했지만 감사하게도 합격이라는 결과를 주셨다.

문화적합성 인터뷰

toss-culture-interview

서류 섹션에서 언급했듯이 평소에도 토스 콘텐츠를 많이 소비하고 있었고, 토스 핵심 가치에도 크게 공감하며 평소에 일을 하면서도 이를 종종 떠올리면서 적용 했었던 것 같다. 중점적으로 준비했던 내용은 이전의 인터뷰를 회고하면서 보완을 위주로 했다. 그리고 SLASH24의 리크루팅세션에서 이전 인터뷰에 대한 피드백도 받을 수 있었는데 이 점도 참고하면서 준비했다. (전체적으로 SLASH24의 도움을 많이 받은 것 같다. 여러분들도 관련 기업의 컨퍼런스를 잘 활용해 보길 바란다!)

결과적으로는 탈락이라는 결과를 받게 되었다. 가장 큰 패착의 요인으로는 준비하면서 넷플릭스의 문화를 다루는 ‘규칙 없음’이라는 책을 읽으면서 준비했는데, 인상 깊게 본 내용중에서 넷플릭스의 4A 피드백 문화가 있었다. 이 때문에 인터뷰를 하면서 피드백과 관련된 얘기를 많이 하고, ‘피드백 하기’가 주요 역량 중 하나인 것 처럼 얘기를 하는 실수를 범했다. 그래서 구체적인 사례들을 물어보는 질문에서 많이 막혔다. 만약 한 1년 전쯤에 이 책을 읽고, 그때부터 일을 하면서 여러 번 피드백을 해왔다면 자연스럽게 답변했을텐데 실제 사례가 많지 않다보니 금방 소진이 되었기 때문이다.

합격한 분들의 문화적합성 후기들을 보면 ‘솔직하게 답변했더니 합격했다.’라는 후기가 많은데 사실은 잘 와닫지 않았었다. 그런데 이를 이번에 명확하게 느낄 수 있었다. 토스의 인터뷰에서는 구체적인 사례를 기반으로 여러 번 꼬리 질문을 하는 방식으로 진행하는데, 이 때문에 평소에 꾸준히 해왔던 것들이 아니면 결국 답변에 막히는 부분이 있을 수 밖에 없게된다. 그러면 면접관 입장에서는 검증이 되지 않은 것으로 판단할 수 밖에 없고, 결국 탈락할 가능성이 높아지겠다는 생각이 들었다.

정말 합류하고 싶은 팀이었기 때문에 많은 아쉬움이 들었다. 그래도 회고를 통해서 내가 실수한 부분을 알 수 있었으니 한번 더 성장할 수 있었다는 점에서 의의를 둬야겠다. 여전히 한번쯤은 꼭 일해보고 싶은 팀으로 남아있으니 언젠가는 다시 도전해보지 않을까 싶다.



숨고

서류

soomgo-docs

사실 예전에 이미 몇 번의 인연이 있던 곳이다. 모젯에 합류하기 전에 라이브 코테를 진행하면서 인터뷰를 봤었는데, 당시 경험도 실용적으로 역량을 잘 검증할 수 있는 방식이라고 느꼈다. 그리고 서비스도 일본어 과외 선생님을 구하면서 잘 이용했었기 때문에 기본적으로 인식이 좋았던 것 같다. 채용 광고를 통해서 처음 접하게 됐는데, 공고를 단톡방에 공유하니까 친구 중에서 숨고에 재직중인 지인분이 있다고 해서 지원하기 전에 간단하게 궁금한 점을 물어볼 수 있었다.

일하는 방식이나 핵심 가치, 조직의 분위기 등 다방면으로 질문드렸고 가능한 선에서 최대한 답변을 해주셨던 것 같다. 무엇보다도 이번 이직에서 중요한 기준 중 하나인 트래픽에 대해서도 질문드렸는데, 모젯의 규모보다 훨씬 많은 수준이었기 때문에 결정적으로 지원하게 되었다. 결과는 지원한 후에 일주일 정도 뒤에 나왔다.

1차 기술 인터뷰

soomgo-tech-interview

1차 인터뷰에서는 처음에는 내 이력을 기반으로 질문이 들어왔다. 그중에서 꽤 비중 있게 다뤘던 내용은 글로버디에서 채팅 기능을 구현한 내용인데 Socket IO에 대한 설명이나 WebSocket 대신 선택한 이유, 그리고 배포 이후에 발생한 문제를 어떻게 해결했는지 등에 대해서 얘기를 나눴다.

이 외에는 새로운 파이썬 서버를 DDD 기반으로 어떻게 설계했는지에 대한 과정을 얘기하고(이벤트 스토밍, 바운디드 컨텍스트 나누기 등), 디렉토리 구조를 어떻게 구성하고, 전술적 설계는 어떤 것들을 적용했는지에 대한 설명을 화이트보드에 그려가면서 설명했다. 인터뷰에서 화이트보드를 사용하면서 설명한 경험은 처음이어서 재미있었다. 저번 인터뷰에서도 라이브 코테를 숨고 전형 진행하면서 처음 경험했었는데 뭔가 숨고에서 처음 해보는 게 많은 것 같다. 아무튼 이후에는 DB 격리 수준과 같이 기본적인 CS 질문들이 몇 가지 있었다. 후기를 말해보자면 적절한 수준으로 꼬리 질문이 들어와서 역량을 검증하기에는 충분한 수준이었던 것 같다. 전반적으로 좋은 분위기에서 마무리할 수 있었고, 3일 뒤에 합격 결과를 받을 수 있었다.

원데이 2차&3차 인터뷰

숨고는 2차와 3차 인터뷰를 하루에 한 번에 진행했다. 두 인터뷰 모두 기본적으로 컬쳐핏 위주로 진행됐지만 2차는 HoE(Head of Engineering)분과 진행해서 중간에 기술적인 질문도 종종 들어왔고, 3차에서는 HR 분과 진행해서 좀 더 숨고의 미션과 핵심 가치에 공감 하는지를 확인하는 질문 위주로 진행됐다.

soomgo-failed

시니어 포지션을 지원했기 때문에 주니어들을 리딩(Leading) 해본 경험이 있는지도 물어보셨는데, 리더 직책을 맡은 경험은 없었기 때문에 이 부분에서는 제대로 답변할 수 없었다. 그나마 후임으로 들어온 분의 온보딩과 프로젝트를 도와줬던 경험과 책에서 본 내용들 안에서 최대한 답변했던 것 같다. 아무래도 시니어 포지션이다 보니 리딩 경험이 꽤 중요했던 것 같았다. 결과적으로 약 일주일 정도 뒤에 탈락이라는 결과를 받았다.

그러고 나서 약 6개월 뒤에 재정비를 마치고 다시 이직 활동을 준비하려는 차에 숨고에서 연락이 왔다. 이번에 새로 미들급 포지션이 열렸는데 해당 포지션으로 진행할 의사가 있는지 물어보셨다. 예상대로 시니어 포지션은 경력이 더 많은 리더분을 모셨지만, 인터뷰 경험이 좋았기 때문에 포지션이 열리자마자 공고를 올리기 전에 바로 연락을 주셨다고 했다. 나도 인터뷰 경험이 좋았기 때문에 바로 진행하겠다고 말씀드렸다.

이미 모든 전형을 진행했기 때문에 6개월간 업데이트 된 내용에 관해서 얘기하는 간단한 커피챗을 진행한 뒤 레퍼런스 체크를 진행한다고 안내받았다.

커피챗

soomgo-coffeechat

커피챗을 진행하기 전에 6개월간 진행한 업무에 대해서 1.5장 분량으로 정리했다. 당일 날에는 A4 용지로 두 장을 인쇄해서 가져갔는데 다행히 매끄럽게 얘기를 나누는 데 큰 도움이 되었다. 위 내용을 기반으로 기술적인 내용과 숨고의 문화에 대해서 빠르게 약 30분 정도 얘기를 나눴고 그 자리에서 바로 마지막 전형인 레퍼런스 체크 안내를 받을 수 있었다. (TMI) 6개월이 지나면서 숨고에도 많은 변화가 있었는데 새롭게 리브랜딩도 하고, 새로운 오피스로 이사도 가 있어서 뭔가 더 기대됐다.

레퍼런스 체크 & 최종합격

soomgo-final-pass

레퍼런스 체크는 현 직장(퇴사자) 세 분과, 전 직장 한 분을 적어서 전달했다. 제출한 날을 기준으로 다음 날에 전화로 레퍼런스 체크가 진행됐고, 바로 다음 날에 최종 합격 안내를 받을 수 있었다.



마무리

이번에 이직을 준비하면서 채용 시장이 얼어붙은 게 체감이 들었던 것 같습니다.

특히 가고 싶은 기업의 전형에서 정말 많은 준비를 했음에도 탈락할 때는 정말 에너지 소모가 많았습니다. 그 와중에 인터뷰 일정이랑 학교 시험 기간이 겹치고, 글또라는 글쓰기 활동에도 참여하는 등 한 번에 너무 많은 것들을 하다 보니 번아웃을 겪기도 했습니다. 그래도 어떻게든 회복한 이후에 계속 도전해 나가면서 결국에는 좋은 결과를 얻을 수 있었던 것 같습니다.

저도 종종 이직 후기들을 보면서 힘을 얻었던 기억이 있는데, 이 글을 보고 계신 분들도 힘을 얻어 갔으면 좋겠습니다. 긴 글 읽어주셔서 감사합니다!


5개의 댓글

comment-user-thumbnail
2025년 6월 2일

포스팅 잘 봤습니다! 이직도 너무너무 축하드려요 🎉
저는 프론트엔드지만 신입 때는 어떻게든 화려한 인터렉션을 구현한 홈페이지와 패기 넘치는 자소설(?)로 어필을 했다면 경력이 조금 찬 지금은 이력서를 어떻게 써야 할지 고민이었는데,
동우 님 벨로그 내용 중 이력서 피드백을 보고 배웠습니다..
지원하신 회사들 보니까 저도 이직통이 오네요.. ㅠ 다시 한 번 정말 축하드립니다!

1개의 답글
comment-user-thumbnail
2025년 6월 4일

으아니 동우님 넘 축하드립니다!!!! ㅎㅎㅎㅎ 개취뽀 오프라인 발표 하셔야죠!! 시간 괜찮으실 때 연락 한 번 주십셔 ㅎㅎ

1개의 답글