사수가 꼭 필요하다고 생각하는 사람들에게

보통 이 바닥에서 사수라고 하면

• 같이 일하는 사람인데 업무 프로세스를 이해하고 먼저 하고 있던 사람
• 같이 일하는 사람인데 업무에 필요한 기술에 대해 경험해 보고 잘 아는 사람 (실제 아닐 수도 있는 건 함정)
• 같이 일하는 사람인데 그 업무를 같이 진행하거나 다른 업무를 하더라도 기술적으로 뭔가 나에게 알려줄 수 있는 위치에 있는 사람 (대부분 여기에 해당)

이런 사람일 것이다.

<사수-부사수의 정석
출처: 국방홍보원 블로그>

개념은

군대에서 사전적 의미로 총을 쏘는 사람인데 보통은 2인 1조 경계 근무에서 지시하는 사람: 사수, 지시를 받는 사람: 부사수에서 사수를 의미하는 것이다. 그래서 보통 경험이 있는 선임들이 이제 경험을 쌓아야 하는 신병과 함께 조를 이루어서 일에 대해 배우고 경험하고 또 문제 생기면 감싸줄 수 있는 사람이다 보니 일반 사무실에서도 같은 개념으로 쓰고 있다.

그런데 개발에서는 일단 사수가 있는게 좋다라는 의견에 반대하는 편이다. 물론 사수가 있다면 일도 배우고, 자신의 부족한 부분을 보고 배울 수 있는 walk-through 개념으로 받아들이면 일 하기가 한결 수월하다는 점에서는 좋을 수 있다. 그게 개발이 아닌 쪽 그러니까 군대나 기타 다른 일에는 한 조로 움직여서 동일한 업무를 수행하니까 맞는 개념인데, 개발은 같은 개발을 둘이 동일하게 하지는 않는다. 

즉, 보통은 같은 프로젝트 내에서 일을 해도 큰 부분에 일부분을 맡아 개발을 하던가 아예 다른 모듈이나 파트 (예를 들면 프론트, 백엔드)를 맡게 되는 경우가 많으므로 사수한테 배운다라는 것이 잘 되지 않을 경우가 많다는 것이다.

그러면 "어차피 프로젝트는 달라도 같은 팀 내에서라면 같은 기술을 쓸 텐데 그러면 기술이라도 배울 수 있는 거 아니냐?" 라고 생각할 수 있다. 좋은 개발 문화가 정착된 회사라면 코드 리뷰나 포스트 모멘텀 발표, 페어 프로그래밍 등을 통해 공유하고 배우고 할 수 있는데, 거의 보통은 자기 할 일 바쁘다 보니 대충 찾아봐야 할 키워드 정도만 공유하고 알아서 찾아서 해야하는 일이 더 빈번하게 일어난다. 그리고 보통 사수라 불리는 사람들은 바쁜 사람들이기 때문에 신입들에게 세세한 관심이나 케어를 해주기가 힘들다.

결국 사수가 하는 역할은 같이 일 하는 사람인것 뿐인데, 조금 업무를 먼저 해본 사람 + 기술적으로 먼저 실무에 써본 사람인 것 뿐이고 삽질 방지를 위한 키워드 던져주기 + 가이드 역할 정도가 사수 역할의 전부라 할 수 있다. 또 업무 프로세스 익히는 것도 신입의 경우도 대략 3~6개월 정도면 사수가 안알려줘도 자연스럽게 파악이 가능한 부분이기 때문에 사수가 굳이 알려주지 않아도 된다.

오히려 사수가 있을 경우 내가 개발하는 일에 더 방해가 될 가능성도 있는데, 방치형 사수일 경우는 문제가 없으나 오지랖 부리는 사수일 경우는 갈굼 + 쓸데없는 관심 + 삼천포로 빠지는 잡담으로 인해 오히려 일 하는데 방해가 되기도 한다. 갈구는 사수라도 있는게 좋다라는 이상한 생각을 가진 사람도 있는 걸 봤는데, 절대 도움되지 않으며 어차피 그 사수도 사수한테 배운게 아니라 자기가 구글 검색이나 별도 스터디를 통해서 알게 된 걸 알려주는 거 정도 밖에 안되므로, 꼭 사수한테 배울 필요도 없다.

결론은

사수한테 뭔가 배워야 겠다는 생각 보다는, 내가 알아서 배워서 사수나 팀원들과 함께 목표를 달성하기 위한 일에 집중하고 그 일원으로써 노력하는 모습을 보여주는게 훨씬 좋다는게 내 생각이다.

단 한명의 개발자가 있다고 하더라도 스스로 주늑 들어서 사수가 있어야 한다는 생각에 사수를 정하고 본인 스스로 부사수를 자청하지 말고 각각의 동등한 입장에서 함께 일하는 co-worker 개념으로 생각하고 일하는게 맞다고 본다.

단 한가지 예외 사항이라면, 회사에 직원 중에 개발자는 아무도 없고 나 혼자 개발자라면 문제가 있을 가능성이 높다. 애초에 그런 회사에 들어가면 혼자 개발 관련된 걸 모두 혼자 해 나가야 하기 때문에 방향성을 잃을 가능성이 높다. 최소한 내가 개발이 뭔지 알고 일 진행을 어떻게 하는 지 알아서 개발의 방향성은 잃어버리지 않는다고 하더라도 개발을 잘 모를 가능성이 높은 영업, 디자인, 대표 등등의 사람들에 의해 개발일이 쉽게 휘둘리는 건 시간 문제기 때문에 그런 곳은 비추한다.