1. 관리자로 진화한 개발자

나는 어디 여긴 누구

직장에서의 내 업무나 역할을 소개할 때면 항상 랙이 걸린다.

시니어나 스태프개발자로 8년 정도 경력을 쌓고, 관리자가 된 지 2-3년 정도 된 초보 "관리자급" 개발자.

명함에 박힌 직함은 수석연구원 (차장이나 부장정도 직급)

영어로는 Principal engineer (수석엔지니어)지만,

이 직함이 내가 하는 업무들을 온전히 담고 있다고 느껴지지 않는다.

아무래도 Principal engineer라는 게 와닿지가 않아서 Technical Product Manager (TPM) 혹은 Technical Leader (TL) 정도로 소개해왔다.

하지만 그마저도 나의 역할을 한마디로 정리할 수는 없었다.

개발자로서의 역할과 관리자로서의 역할이 뒤섞여 있다.

---

실무자로 개발업무에 매진하고 소규모 프로젝트/업무범위 정도 신경 쓰다가

갑자기 수석급으로 승진하게 되면 예상보다 급격한 변화가 찾아온다.

업무가 폭발적으로 늘어나 정신을 차릴 수 없는 상황에 처하게 된다.

기존에 하던 개발업무는 갑자기 사라지지 않는다.

이제는 팀원들 관리, 다른 팀 협업 리드, 버그/이슈 해결, 과제/제품 일정 챙기기, 임원보고, 실적정리 등등. 정신 차릴만하면 신입 인터뷰를 진행해야 하고, 경력 이력서 검토나 직무기술서 작성, 소프트랜딩 지원 등 새로운 역할들이 끊임없이 이어진다. 또한, 팀 내 멘토링, 팀원들 간의 갈등 해결, 업무 분배와 조정 등 팀의 역량과 숙련도에 맞춘 업무 할당 역시 내 몫이다. 더불어 최신 기술에 대한 연구와 이를 팀에 잘 녹여내어 5개년 개발 로드맵 수립 등 거대한 과제들도 수행해야 한다.

개발 외적인 것들을 "잡무"라고 생각했던 시절이 있었는데 그것들이 내 본업이 되어서 하루종일 처리 하다 보면 코드 한 줄 짜지 않는 날이 더 많아진다. 팀원들이 제출한 코드리뷰라도 시간을 내어 꼼꼼히 확인하려 애쓰지만, 점점 물리적인 시간이 부족해지면서 내가 더 이상 모든 것을 챙길 수 없다는 사실을 깨닫고 어느 순간에는 조금씩 포기하게 된다.

내가 짜거나 팔로업하고 있던 코드도 아니지만, 갑자기 문제가 터졌을 때의 대응책도 마련해야 한다.

회사 내부나 외부에서 오는 이메일을 가장 처음 받게 되고, 목적을 정확히 해석해서 설명을 곁들여 팀원들에게 전달도 해 줘야 한다. 이메일 프록시 역할을 하며, 매일 이메일을 전달하기 바쁘지만 팀원들의 업무에 대해 빅픽쳐를 갖고 있어야 한다.

찐(!) 관리직을 맡고 있다면, 인사고과 평가를 위한 성과관리도 중요한 역할이 된다. 이 과정에서 팀원들 성과관리를 위해 미리 기회를 주면서 애써야 하고, 공정한 평가를 진행하도록 해야 한다. 인사팀에서 알려주는 여러 스킬도 익혀야 하며 팀원들 평가에 대해 부담을 짊어지고 1년을 보내게 된다.

아 그리고 회의, 회의 그리고 회의다. 회의를 마치고 나면, 정시퇴근 시간이 지나서야 비로소 본격적인 업무를 시작할 수 있는 상황이 된다. 이렇게 하루가 끝나가는데도, 실제로 내가 해야 할 일은 거의 해내지 못한 채 시간을 보내는 경우가 많다.

그 와중에 내 커리어패스는 아무도 케어해주지 않는다는 게 포인트지만.

---

이러한 고민들을 같은 수석엔지니어들끼리 나눠 보기도 했지만 같은 회사 내에서는 도무지 돌고 도는 뫼비우스의 띠 같은 얘기만 하게 되어서 내가 겪고 있는 현상과 문제, 담론을 좀 오픈해서 기록해두고 싶어졌다.