시니어를 더 뽑으면, 팀은 정말 빨라질까
경력 많은 엔지니어를 채용하면 팀이 빨라질 거라는 기대는 자연스럽다. 근데 채용 전에 확인할 것이 있다. 일이 느린 이유를 어떤 장면으로 설명할 수 있는가. 작업 시간과 경과 시간의 구분, 기대하는 결과를 적는 법, 시니어의 성과를 보는 기준을 정리했다.
어느 팀이든 속도가 기대에 못 미치는 시기가 있다. 그때 가장 먼저 떠오르는 해법이 경력 많은 엔지니어를 더 뽑는 것이다. 복잡한 문제를 빨리 파악하고, 설계를 주도하고, 다른 구성원의 성장을 도와줄 사람. 나도 팀 구성을 고민할 때마다 이 기대를 갖는다. 그래서 채용을 열기 전에 스스로에게 묻는 질문을 정해뒀다. 시니어 채용에 어떤 문제의 해결을 기대하는가.
시니어 채용이 실제로 해결하는 문제는 무엇인가?
경험이 필요한 순간은 분명히 있다. 운영 장애의 원인을 좁혀야 하거나, 권한 모델을 설계하거나, 여러 서비스에 걸친 변경을 안전하게 진행해야 할 때. 이런 일을 맡길 사람이 없다면 역량을 확보하는 것이 가장 중요한 과제가 맞다. 창업 첫 9개월에 적었듯 두 번째 멤버를 기술 깊이가 있는 사람으로 정한 결정은 첫 PoC를 통과시킨 결정이었다.
하지만 채용을 결정하기 전에 확인하고 싶은 것이 있다. 지금 일이 느린 이유를 어떤 장면으로 설명할 수 있는가. "실행력이 부족하다"는 문장만으로는 어떤 사람을 데려와야 하는지도 정해지지 않는다.
팀이 느린 이유는 어떻게 진단하나?
최근에 끝낸 작업 몇 개의 흐름을 처음부터 끝까지 따라가 본다. 착수 전에 무엇을 기다렸는지, 구현 중 어디에서 막혔는지, 리뷰에 얼마나 머물렀는지, 완료 이후 무엇을 다시 했는지. 사람을 평가하기 전에 어떤 조건에서 일이 진행됐는지 이해하는 게 먼저다.
같은 "느림"이라도 장면은 다르다.
- 구현 자체가 자주 막히고, 기술적 판단을 맡을 사람이 없어 여러 사람이 같은 문제를 반복해서 조사한다면 경험의 공백을 의심할 수 있다.
- 구현을 끝낸 뒤 목표가 바뀌어 다시 만드는 일이 많다면, 새 엔지니어에게도 같은 재작업이 생긴다. 채용보다 요구사항을 정리하는 방식이 먼저다.
- 우선순위나 고객 요구를 한 사람만 알고 있어 결정을 기다리는 시간이 길다면, 담당자가 늘수록 질문도 늘어난다. 채용과 함께 어떤 결정을 팀에 넘길지 정하지 않으면 사람이 늘어도 결정의 흐름은 그대로다.
세 장면 모두 느리지만 필요한 조치는 전부 다르다.
작업 시간과 경과 시간은 왜 구분해야 하나?
구현에는 하루가 걸렸는데 완료까지 일주일이 걸렸다면, 나머지 6일은 구현 역량의 문제가 아닐 가능성이 크기 때문이다. 리뷰 대기, 결정 대기, 환경 대기. 이 시간은 시니어를 뽑아도 줄지 않는다.
반대로 아무도 대기시키지 않았는데 같은 유형의 기술적 실수가 반복된다면 역량과 검증 방식을 살펴야 한다. 어느 쪽도 처음부터 결론을 정할 수 없고, 작업 흐름을 실제로 따라가 봐야 보인다. 사실 이 구분은 우리 제품이 다루는 문제와도 겹친다. 변경이 어디에서 얼마나 머물렀는지가 기록으로 남아 있으면, 이 진단은 감이 아니라 데이터로 할 수 있다.
시니어에게 기대하는 결과는 어떻게 적어야 하나?
직급이 아니라 바뀌어야 할 결과로 적는다. 설계 검토가 특정 사람에게 집중되지 않게 할 것인지, 반복되는 운영 문제의 원인을 찾아 개선할 것인지, 다른 엔지니어가 같은 유형의 일을 스스로 끝낼 수 있게 할 것인지. 기대하는 결과가 구체적이어야 후보자의 경험도 그 결과에 비추어 볼 수 있다.
입사한 사람이 그 결과를 만들 수 있는 권한도 함께 적어야 한다. 구조를 개선하라고 데려온 사람에게 일정과 범위를 조정할 여지를 전혀 주지 않으면 기대가 충돌한다. 무엇을 바꿀 수 있고 어떤 결정은 함께 해야 하는지, 팀이 그 변경을 받아들일 시간은 어떻게 마련할지. 이것도 채용의 일부다.
시니어의 성과는 무엇으로 봐야 하나?
혼자 처리한 양과 함께, 주변의 일이 어떻게 달라졌는지로 본다.
- 검토 기준이 문서로 남았는가
- 같은 문제가 반복될 때 다른 사람도 판단할 수 있게 됐는가
- 중요한 지식이 한 사람에게만 쌓이고 있지는 않은가
시니어에게 기대하는 영향은 그 사람의 처리량이 아니라 팀의 판단 능력이 넓어지는 것이다. 이 기준이 없으면 가장 경험 많은 사람이 가장 바쁜 병목이 되는 결말로 흘러가기 쉽다.
어떤 역량이 부족한지 확인했다면 확보해야 한다. 그와 함께 리더가 우선순위를 정리하고 조직이 바꿔야 할 과정도 같이 다뤄야 한다. 새로 들어올 사람이 역량을 발휘할 조건까지 만드는 것이 채용하는 쪽의 책임이다.
채용 전에 완성해야 할 문장은 무엇인가?
"시니어가 필요하다" 다음에 오는 두 문장이다. 그 사람이 오면 어떤 일이 지금과 달라져야 하는가. 그리고 그 변화가 가능하도록 우리는 무엇을 바꿀 것인가. 이 둘에 답할 수 있을 때 채용 공고를 연다. 답이 없으면 채용이 아니라 다른 일을 먼저 해야 한다는 신호다.
비슷한 글
구글을 나온 뒤, "일을 잘한다"는 기준이 달라졌다
세일즈포스와 구글에서 소프트웨어 엔지니어로 일하다 2024년 7월 창업했다. 코드를 잘 짜는 기준은 그대로인데, 그 앞에 놓인 질문이 내 책임이 됐다. 어떤 고객의 문제를 왜 지금 푸는가. 엔지니어에서 창업자로 넘어오며 바뀐 "좋은 일"의 기준을 적었다.
백재민
한국에는 PC방이 있었다. 개발자에게는 어떤 환경이 필요할까
유학 시절 스타크래프트에서 한국인이라는 말 한마디가 만들던 기대에서 시작한 질문이다. 실력은 어디에서 만들어지는가. PC방이 보여준 연습과 피드백의 반복을 개발자의 하루로 옮기면, 변경 뒤에 무엇이 일어나는지 보이는 환경이 된다.
백재민
"주도적으로 일해 달라"는 말에는 무엇이 빠져 있을까
작은 회사를 운영하며 주도성을 요구할 때마다 되돌아오는 질문이 있다. 나는 무엇을 맡겼고, 어디까지 결정하게 했고, 기준을 처음부터 설명했는가. 주도적으로 일할 수 있는 조건 네 가지와 리더가 먼저 해야 할 일을 정리했다.
백재민