이 포스팅은 도서 개발자를 넘어 기술 리더로 가는 길에 대한 리뷰를 담고 있습니다.

요약

대략 15년 간 10개의 정도의 개발 프로젝트를 경험하며 업무가 왜 올바른 방향으로 가지 않을까? 라는 생각을 종종 하게 된다. 아마 여기서의 올바름은 각자가 갖고 있는 철학이나 합리성 등 일 것이다. 직책은 주니어 개발자부터 시작해 꽤 높은 직책까지 맡은 적이 있는데 연차가 쌓일 수록 개발을 어떻게 하지? 라는 단계에서 어떻게 하면 같이 협업하는 동료와 목표를 향해 빠르게 도달할 수 있을까? 의 단계로 넘어가는 중이다.

위 문단에 적힌 내용 중 단 하나라도 공감하시는 것이 있다면 이 책 - 개발자를 넘어 기술 리더로 가는 길 - 은 반드시 읽어보셔야 한다. 최근 읽은 책 중 하나는 회사의 조직 구조에 따라 어떻게 행동하는 것이 본인 혹은 조직이 갖고 있는 목표 혹은 의지를 관철할 수 있는지에 대한 내용을 담고 있다. 좀 놀라웠던 것은 해당 책의 내용을 엔지니어 입장에서 다시 적어둔 것 같다는 느낌을 받은 점이다. 엔지니어링을 넘어 좀 더 영향력을 발휘하고 싶으신 분들이라면 이 책을 읽어보실 것을 권한다.

IT 엔지니어

이 블로그 (altari.io) 를 방문하신 분들이라면 개발자 - Software Engineer - 에 속해 계실 확률이 높을 것이다. 저의 경우 개발자로 있으면서 아래의 단계를 거치는 중인 것 같다.

• 주니어 개발자: 주어진 기능 명세를 구현하는데 있어 두려움이 많았다. 일정안에 개발을 마칠 수 있을지, 이 명세를 구현할 때 필요한 API 등은 어디서 알아내야 하는지 등 기술 스택 자체에 대한 지식이 부족하니 이를 열심히 메우고자 노력한 시기이다.

• 시니어 개발자: 주어진 기능 명세를 빠르게 구현하고 이를 사용할 부서 및 동료에게도 공유를 열심히 하기 위해 노력한 시기이다.

• 매니저 혹은 풀스틱 개발자: 매니저를 하거나 혹은 풀스택 개발을 진행한 시기이다. 매니저를 하는 동안 개발을 다시 못하게 되면 어쩌지 라는 고민을 많이 했으나 일감이 주어지면 그냥 하면 되더라 라는 것을 깨달은 시기.

• 현재? 현재는 새로운 직장에서 그간 배운 것을 녹여내기 위해 노력중이다. 아주 좋은 타이밍에 개발자를 넘어 기술 리더로 가는 길 이라는 책을 접한 것 같다.

개발자를 넘어 기술 리더로 가는 길

최근 마이크로소프트에 재직중인 친구를 만나 사티아 나델라 CEO에 대해서 느낀 점을 이야기 한 적이 있다. 몇 년 전 GitHub을 인수 할 때 이해하기 어려웠는데 최근 GPT-3를 보며 이 모든 것이 큰 흐름 중 하나였구나 라는 것을 인식하게 되며 전율을 느꼈다. 단지 이런 전율만 느낀 것은 아니다. 그렇다면 사티아 나델라와 같은 분들은 어떻게 조직내에 영향력을 발휘했을까? 리더가 되려면 무엇이 필요한걸까? 매니저를 시작한 이후 이런 질문을 꾸준히 해오고 있다.

이 책에서는 그 질문에 대한 답을 아래의 3가지로 설명하고 있다.

1. 빅 픽처 관점의 사고력
2. 성공적인 프로젝트 수행력
3. 조직 차원의 레벨업

각 기둥의 의미는 무엇일까?

빅 픽처 관점의 사고력

이는 말 그대로 크게 보는 것이다. 크게 본다는 뜻은 현재 진행중인 업무 뿐 아니라 조직의 1년 뒤 그리고 회사의 3년 뒤를 바라보며 생각하는 것을 의미한다. 물론 이 기간은 상황에 따라 다를 것이다. 다만 나의 경우를 돌아보자면 이를 명시적으로 나열하기보단 막연히 주변 동료와 이야기하며 앞으로 일어날 일과 필요한 일이 무엇일지 논의를 했었다.

성공적인 프로젝트 실행력

어떤 책을 보더라도 기술적으로 주어진 기능을 만족하지 못한 조직이 성공할 수 있는 방법에 대해선 알려주지 않았다. 즉, 프로젝트를 성공적으로 진행하는 것은 기본이라는 뜻이다. 이 책에서는 기본 엔지니어링 스킬외에 정치적인 자본력 혹은 기업 문화의 변화 등 목표를 달성하기 위해 스태프 엔지니어가 해야할 일들에 대해 이야기하고 있다.

조직 차원의 레벨업

스태프 엔지니어로써 표준 정립 및 주변 동료의 스킬 향상 시켜야 할 책임이 있다고 이야기 하고 있다. 물론 이런 것들은 다양한 경험 및 협업을 하며 자연스레 쌓이겠지만 가르침 및 멘토링을 통향 영향력 발휘를 의도적으로 해야 한다고 설명하고 있다. 이런 부분은 스스로 보완하면 좋겠다는 생각을 하며 보았다.

마무리

위의 요약 에서 대략적인 정리를 하였으니 좀 다른 이야기를 해보고자 한다. 스태프 엔지니어는 매니저로 진급하지 않고 엔지니어로써 좀 더 영향력을 발휘하기 위한 직급이라고 이해하고 있다. 이 직급이 있는 이유는 결국 회사의 목표를 달성하기 위해 필요하기 때문이다. 이를 위해서 우리가 무엇을 해야할지에 대한 많은 고민이 이 책에 담겨있다고 느끼고 있다.

기술 스택을 설명하는 책이라면 금방 읽고 넘길 수 있을텐데 이 책은 놓인 상황별로 설명을 해주기에 손에서 오래 잡고 보게 된다. 그리고 고민을 하게 된다. 나라면 어떻게 했을까? 그리고 어떻게 해야할까? 매니저 혹은 스태프 엔지니어로 나뉘는 커리어 패스가 한국 기업에 익숙한 분류는 아닐 것이라 생각되지만 소프트웨어를 활용한 산업이 커지면 커질수록 필요할 수 밖에 없을 것이라 생각한다.

조직을 어떻게 끌어갈지 하루하루 고민하시는 분들이라면 이 책을 한번 읽어보시길 권한다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.