각 레벨의 엔지니어에 대한 기대치

매니저 생활을 오랫동안 하면서 팀원들이 주니어-미드-시니어가 되는 과정에 갈피를 잡지 못하는 상황을 심심치 않게 볼 수 있었습니다.

조금이나마 오늘도 성장하길 원하는 분들에게 도움이 되고자 실제로 제 팀원들에게 공유한 내용을 공개합니다.

주니어는 Specialist가 되야 합니다.

1. 전체적인 아키텍처보다 특정 Tool, 라이브러리나 Language(Kotlin, Swift등)에 Expert하는 것을 추천드립니다. 물론 아키텍처가 중요하지만, 언어와 라이브러리의 본질을 깨닫고 능숙하게 사용했을때 전체적인 시야가 넓어지면서 아키텍처도 이해하고 볼 수 있습니다.
2. 시스템의 전체적인 부분보다 1~2개의 도메인 영역에 Specialist가 되시길 추천드립니다. ‘이 서비스에서 저 영역은 저 사람을 찾아가라.’ 정도로 본인의 브랜드를 만들어야 합니다. 회사에서 인정 받는 가장 쉽고 빠른 방법이기도 합니다. 대학도 전공과 부전공이 있듯이 내 메인 영역을 만들고 다른 영역으로 확장하시면 좋겠습니다.

 

미드는 주니어보다 시야를 넓혀서 프로젝트 설계를 주도적으로 할 수 있어야 합니다.

1. 시스템내에서 프로젝트 단위의 아키텍처를 시작하는 단계입니다. 언어와 라이브러리를 자유자재로 사용하시면 시야가 넓어져서 자연스럽게 아키텍처로 관심사가 바뀔겁니다. 그래서 어떻게 설계해서 프로젝트를 수행하는 것이 좋을지 Pros/Cons 관점에서 대안을 도출할 수 있어야 합니다.
2. 설계를 통해서 Pros/Cons 위주로 다양한 Solution을 도출하고 최적이 무엇인지 대안을 상위 리더에게 제시할 수 있는 능력을 길러야 합니다.
3. 당연히 주니어때 쌓은 경험과 노하우를 토대로 확장해서 전체 도메인의 절반의 영역에 영향력을 발휘해야 합니다. 이를 기반으로 도메인에 대해서 주니어를 리딩합니다.

 

시니어는 Business Impact도 고려해야 합니다.

1. 엔지니어링 리더가 되야 합니다. 기술적으로도 Business적으로도 Expert가 되야 합니다.
2. 기술적으로 가장 효과적이라고 하더라도 상황에 따라서 차선책을 선택할 수도 있어야 합니다.
3. 개별 도메인의 최적화가 아닌 시스템 전체의 최적화를 신경써야 합니다. 물론 Business Impact가 더 중요합니다.
4. 팀 뿐만아니라 실/본부 레벨에서도 컨벤션등 개발 문화를 선도하고 제정할 수 있어야 합니다. 이건 정답이 없는 분야이니 시니어들끼리 서로의 경험을 공유하고 합의하면서 리딩이 필요하겠죠. 물론 구성원들과 공감대를 형성하고 정착할 수 있도록 하는 것도 중요합니다.
5. 시니어 엔지니어는 TF 또는 프로젝트의 테크 리더로서 역할을 수행할 수 있어야 합니다. 설계를 주도하고 구현 일정에 대해서 관련자들과 협의할 수 있어야 합니다. 본격적으로 리더의 역할을 수행할 수 있는 리더십을 갖춰야 합니다.

 

Manager는 직접 일을 하는게 아니라 팀원들이 일할 수 있는 환경을 조성하는데 힘써야 합니다. 축구 감독처럼…

1. 기술 회의에서는 내/외부의 요구사항을 바탕으로 최적의 판단을 할 수 있도록 해야합니다.
2. 왜 이런 일을 하는지, 어떤 영향이 있는지등의 Context를 전파하는데 힘써야 합니다.
3. 팀원들이 적극적이고 창의적으로 일할 수 있도록 판을 깔아주는 역할이 되야 합니다. 그게 목표이기도 합니다. 때론 현실이 그렇지 않다는 걸 알기 때문에 간섭과 감독을 해야할때도 있습니다.
4. 매니저는 팀원들에게 업무를 배분하는 사람이 아닙니다. 팀원들의 역량에 맞게 업무를 추천 할 수 있습니다. 하지만 어떤 업무와 역할을 할 것인지는 팀원들이 선택할 수 있도록 합니다. 매니저는 팀원들이 수행하는 업무 과정을 관찰해서 평가를 합니다.
5. 팀 운영뿐 아니라 문화를 만들어가는 감독으로서 역할을 해야 합니다. 팀원들의 역량과 리더십을 끌어올려서 팀을 견고하게 만드는 축구 감독에 비유할 수 있겠네요.
6. 팀의 성장과 Vision을 만들고, 팀원들이 꿈 꿀 수 있도록 노력해야 합니다. (실현이 힘들고 안되더라고…)

 

Thanks

Hans L