3. 수석엔지니어의 리더십이란?

나도 모르겠다

수석엔지니어란 어디인가 (무엇인가)

진급을 하고 명함을 받고 나서도 수석엔지니어의 뜻을 몰랐다. 진급하고나서야 본격적으로 수석엔지니어의 직급에 대 찾아보기 시작했는데 보통 엔지니어의 직급은 보통 아래처럼 분류된다.

Junior Engineer: 주니어엔지니어 (+ 신입)

Senior Engineer: 시니어엔지니어

Staff Engineer: 스태프엔지니어

Principal Engineer: 수석엔지니어

수석엔지니어는 단순히 코딩이나 구현 작업에서 벗어나, 팀 전체를 엔지니어링 관점에서 이끄는 역할을 맡는다. 기술적인 리더십을 발휘하며, 기술이슈나 방향에 대한 '결정'을 할 수 있다. 비지니스 방향에 도움이 되는 기술적인 목표를 정하는 역할을 포함한다. 가장 일반적인 형태의 역할이며 Technical Leader (TL)로 부른다. 나도 수석엔지니어 초반에는 스스로를 TL이라고 많이 소개했다.

회사 별로 커리어레벨에 따라 요구되는 역량이 다르지만, 수석엔지니어가 되기 위해서는 아키텍쳐 디자인, 요구사항 분석과 적용, 코드리뷰 뿐만 아니라 비기술적인 측면, 멘토링이나 리더십 등도 필수 역량에 포함된다. 

Engineering Manager 라는 직함이 따로 있는 경우도 있는데, 커리어레벨이 고도로 발달한 회사라고 해도 수석엔지니어가 Technical Leader (TL) 하면서 겸임을 하게 되는 경우가 많은 것 같다. 

수석엔지니어는 Product Manager (PM)도 할 수 있다. 주로 프로젝트의 로드맵이나 기능개발 관리, 일정관리 등을 맡게 된다. 개발 TL과 보통은 분리 되어야 하지만, 내가 속한 팀에는 그런 역할구분은 없었다.

수석엔지니어 =? 리더

회사마다 다르지만 일반적으로 C레벨 밑으로 실장이나 팀장이 있고, 그 밑으로 다시 그룹장 또는 랩장

그리고 그 밑에 소규모 단위로 파트나 셀이 존재한다. 규모는 회사마다 다르지만 보통 20명 내외.

파트장이나 셀장 밑에 다시 TL들이 존재할 수 있다!

각종 개발방법론에 적용되는 팀의 종류를 버무려, 수직구조 관료제로 탄생시킨 느낌이다.

수평관계를 강조하기 위해 직함이나 역할을 빼고 있지만, 여튼 수석엔지니어는 그 규모가 어떻든 팀원들을 리딩하면서 같이 일하게 된다.

수석엔지니어는 크고 간단히 생각해보면 두 가지 코스다. 

전문가형 코스: 실무만 하는 사람

관리자형 코스: 실무 반, 관리 반

해외에서는 수석엔지니어의 TL과 PM역할이 조금은 명확히 나뉘어져있는 반면

수석엔지니어에게 100% 관리만 맡기는 회사는 국내는 잘 없는 것 같다.

보통은 기술적인 책임을 지는 동시에, 관리자 역할도 함께 수행한다. 

그 모든 역할을 통칭하여 수석엔지니어는 '리더'라는 모자를 쓰게 된다.

---

수석엔지니어의 리더십이란, 정말 다양한 방법이 있을 것 같다. 사실 리더십이라는 문구는 허상과도 같아서, 리더십을 강조하고는 하지만 정작 실행방법에 대해서는 논란이 많다.

아래는 최소한 이것만은 지키자고 생각한 것들이다.

결정은 본인이 하자

모든 결정을 본인이 하라는 뜻이 아니다, 그럴 시간도 없다. 사공이 많아지고 아무도 결정 못 하는 상황이 오면 단호하게 결정을 내려 줘야 한다는 뜻이다.

주니어/시니어 엔지니어들에게 의견을 물어볼 수는 있지만, 결정하는건 수석엔지니어 본인이어야 한다.

의견을 취합하고, 조금 더 좋은 선택을 위해서 팀원들끼리 같이 논의할 수는 있지만 결정에 대한 책임을 회피하는 건 옳지 않다. 좋은 팀이라면 90% 이상은 팀원들이 생각하는 방향이 일치하는 경우가 많고, 10% 정도의 상황에서 조율을 하고 결정해야 하는 상황이 온다.

100% 옳은 결정이라는 건 없다, 장단점을 이해하고 현재 팀에게 가장 필요한 항목을 달성하는 방향으로 결정하면 된다. 지금 필요한게 좋은 구조인지, 빠른 패치인지, 성능개선인지 가장 중요한 항목을 달성할 수 있도록 결정하고 팀원들에게 설명하도록 한다. 

팀원들이 납득할만한 결정이 아니라면, 왜 내가 이렇게 결정했는지 설득시키는 과정도 필요하다.

플랜B를 만들어 두자

리스크 관리는 기본이다. 이슈에 대한 해결책이 나왔다하더라도, 플랜B 플랜C를 만들어두고 최악의 경우를 대비하는 것이 수석엔지니어의 역할이다.

주니어들은 프롬프트처럼 곧바로 패치를 쏟아내곤 하는데, 보통은 그런 땜빵코드들이 더 문제를 만들어낸다. 

구조적으로 리뷰할 수 있도록 하고 수정포인트를 스스로 찾아내도록 하면 좋다.

시니어들은 문제가 해결되면 그 이후를 생각하는 습관이 덜 들어있다. 놓치고 있는 것들이 뭔지 계속 상기시켜주고, 회사 프로세스 상 잘 지켰는지 등 개발 이외의 것들을 좀 더 챙겨주면 좋다.

액션아이템을 끝까지 수행하자

액션아이템이라는 거 듣기만 해도 지긋지긋할텐데, 생각보다 액션아이템을 끝까지 완수하는 경우는 드물다.보고할 때 반짝 액션아이템 만들고, 무덤으로 사라지는 경우를 많이들 봤을 것이다.

얘기하고자 하는 것은 팀의 개발 액션아이템이다. 개발하다 만들게 되는 TODO, FIXME 같은 것들.

특히 메가패치난 핫픽스 같은 것들을 넣게 되면 수십개씩 TODO가 나오곤 하는데

이걸 아무도 챙기지 않으면 결국 프로젝트 코드는 몇년 동안 known 이슈들을 안고 가는 형태에서 벗어날 수 없게 된다.

이러한 것들을 따로 Technical debt 혹은 backlog 형태로 관리하고, 수석엔지니어라면 이러한 액션아이템들을 팀원들에게 적절하게 할당하고 완료할 수 있도록 해야 한다.

너무 사소해서, 혹은 너무 거대해서 손댈 수 없는 아이템들을 업무 중간중간에 수행할 수 있도록 배치해야 한다.

개인적으로 수정을 미루는 작업을 Technical debt로 분류해두는 걸 싫어하는 편이다. 그때그때 수정할 수 있도록 가이드 해야 한다. 그렇게 할 수 없다면 팀원들이 일주일에 적어도 10% 정도는 Technical debt를 완수하는 작업을 하도록 해야 한다.

---

반대로 수석엔지니어가 주제넘게 잘 하려고 하지 말아야 될 것들에 대해서 고민해보았다.

그럴 필요도 없거니와, 신경 쓴 만큼 결과가 좋지 않았던 경우가 너무 많다.

비전 제시와 전략적 사고

원하지 않아도 매년 로드맵을 짜 오라고 요청 받을 테니까, 전략구성에 관한 연습을 할 수는 있다. 

하지만 수석엔지니어가 회사의 비전과 전략을 책임져야 하는 것은 아니다. 그것은 회사의 과도한 기대이며 스스로 그걸 책임져야 된다고 생각하면 또한 오만이다.

기술적인 트렌드, 혹은 팀의 방향성에 대해서 제시할 수는 있지만 회사의 사업화 전략이나 비지니스모델에 대한 구체적인 계을 세워오라는 일에 대한 욕심은 버리는 편이 좋다. 조금 더 기술적인 면에 집중하자.

갈등 해결

팀 내에서 발생하는 모든 갈등을 해결하려고 하지 말자. 대부분은 알아서들 해결한다.

갈등을 해결하기 위해서, A한테 가서 얘기하고 B한테 가서 또 얘기하고 이런 소모적인 관리는 하지 않는 편이 좋다. 수석엔지니어는 갈등을 해결하는 사람이 아니다.

갈등이 장기전이 되거나 해결될 기미가 없어보이면 업무를 분리하는 편이 좋다.

팀원들 간의 갈등은 종종 업무 방식에 대한 차이에서 비롯되기 때문에, 업무를 분리하거나 다른 방식으로 접근하는 것이 문제를 풀어가는 더 좋은 방법이 될 수 있다.

---

수많은 리더십 책이나 강의들에서 이렇게 해라, 저렇게 하지 말아라 라는 가이드가 쏟아지곤 한다.

그런 가이드에 지나치게 초조해하거나, "이건 꼭 해야 한다" 혹은 "저건 하면 안 된다"는 생각에 너무 매몰되지만 않으면, 좋은 수석 엔지니어가 될 수 있을 것 같다.