이 공고, 이렇게 물어볼 겁니다

모바일 업무 자동화 요구사항을 받았을 때, 초기 요구사항이 정확히 어떻게 들어왔고, 그걸 설계까지 연결하는 과정에서 가장 모호했던 부분이 뭐였어요?

🎯 요구사항 해석 → 기술 설계의 주도권 / 추상 지시를 측정 가능한 사양으로 변환하는 사고 과정

수백 대 모바일 디바이스를 원격으로 제어하는 플랫폼을 설계했을 때, 안정성 장애를 어떻게 미리 예상했고, 그걸 기술로 어떻게 해결했어요? 그 결과를 어떤 지표로 확인했나요?

🎯 비기능 요구사항의 구체적 기술 구현 / 측정 메커니즘의 현실성 / 예방 vs 사후 대응의 균형

개발자 생산성 도구나 공용 라이브러리를 만들 때, 실제 사용자(다른 개발팀)의 피드백을 어떻게 수집했고, 초기 계획과 뭐가 달라졌나요? 그리고 최종적으로 그 도구를 몇 개 팀이 얼마나 자주 썼어요?

🎯 사용자 중심 설계의 실제 구현 정도 / 도구 성공의 개인 기여도 vs 팀 성과의 경계 정직함

gRPC나 WebSocket 같은 실시간 통신을 구현하다가, 예상하지 못한 장애나 성능 문제가 있었나요? 구체적으로 뭐가 터졌고, 어떻게 원인을 파악했으며, 비슷한 일이 다시 안 생기도록 뭘 바꿨나요?

🎯 실제 장애 경험에서의 근본 원인 분석 능력 / 시스템 개선의 구조적 사고 / 사후 대응이 아니라 예방

높은 코드 품질(TDD, OOP)을 추구하다가, 일정이나 팀원의 역량 때문에 의견이 안 맞은 적 있나요? 그때 본인이 어떻게 결정했고, 그 결정이 실제로 뭘 낳았어요?

🎯 기술 신념과 현실의 균형 / 의사결정 시 주인의식과 실용성 / 팀 갈등 상황에서의 리더십

질문만 읽으면 컨닝이에요. 소리 내어 답해보세요 — 어디서 틀어지는지 짚어드립니다.

공고 내용

Node.js Developer는 모바일 자동화 플랫폼을 통해, 토스 내부의 업무 자동화와 개발 생산성 도구를 만드는 팀에 합류하게 돼요.
모바일 디바이스를 원격으로 제어하고 자동화 작업을 수행하는 플랫폼을 함께 개발하고 운영해요. 토스 전체 개발자의 생산성을 높이는 인프라를 직접 만들어요.
새로운 시스템을 구축할 때, 많은 팀 구성원이 모여 코드 리뷰를 해요. 버그나 네이밍 미스, 컴포넌트 설계에 어색한 부분은 없는지 함께 리뷰하고 코드의 질적 향상에 대해 끊임없이 토론해요.
일주일에 한번씩 엔지니어링 데이를 해요. 다양한 계열사에서 얻은 기술적인 지식들을 공유받고, 공유할 수 있어요.

모바일 자동화, 자동화 프레임워크, CI/CD 파이프라인 등 자동화 인프라 개발 경험이 있다면 기재해주세요.
실시간 통신(WebSocket, gRPC) 또는 분산 시스템을 구축한 경험을 작성해 주세요.
Node.js, NestJS, MongoDB, Kafka 등 다양한 기술을 활용한 백엔드 서비스 운영 경험을 작성해 주세요.
AWS, GitHub, Docker, Kubernetes 등의 경험이 있으시면 도움이 돼요. 관련 개발 경험이 있으시다면 기재해주세요.
Functional Programming, Object Oriented Programming, Test Driven Development 경험이 있으시다면 기재해주세요.

함께할 동료를 위한 한마디

"토스에서 Node.js Developer는 단순히 기능을 만들고 버그를 고치는 역할을 넘어, 기술을 통해 차별화된 가치를 만들어내는 사람들이에요."

우리는 모바일 금융 서비스를 지탱하는 자동화 플랫폼을 만들고, 개발자가 더 효율적으로 일할 수 있는 도구를 개발해요. 수백 대의 모바일 디바이스를 안정적으로 제어하고, 복잡한 자동화 시나리오를 구현하는 기술적 도전을 함께 해요. 그 여정을 함께할 분을 기다리고 있어요.