chirho's network world

개발자를 넘어 기술 리더로 가는 길 - 타냐 라일리 지음, 김그레이스 옮김/디코딩

 

개발자에서 개발팀장으로 개발실장으로 역할을 옮겨가면서 붙들고 있는 주제가 있다.

 

'나는 개발자의 정체성을 잃지 않겠다.'

 

처음 개발자에서 관리 업무를 겸하는 팀장으로 역할이 바뀔 때의 다짐이었는데, 현 시점에서 개발 업무와 관리 업무 사이에 몇 퍼센트의 역할 분담이 되고 있는지는 정확하지 않지만, (점차 관리 업무 비중에 높아짐을 느낀다) 개발에 영 손을 놓을 생각은 없다.

 

(나와 비슷한) 이 고민 때문에 시니어 개발자에서 관리자 트랙으로 넘어가지 못 하고 있는 고연차 개발자들이 많고, 또 관리자 수요가 아무래도 개발자 보다는 제한적이기도 하기 때문에 개인으로써도 조직으로써도 개발자의 경력 관리가 그 만큼 어려워지는 측면이 있다.

 

최근 들어서 시니어 개발자 이후의 개발자 트랙에 대한 논의가 활발해 지고 있음을 느낀다. "TL(테크 리드)"에 관한 이야기는 지난 글 2021.12.31 - [서평] - 개발 7년차, 매니저 1일차 에서도 소개한 바 있는데, 최근에는 "스태프 엔지니어"에 관한 소개가 주로 회자되고 있는 편이다.

(한편 매니저 트랙에서는 PM - 여러 역할 중 프로덕트 매니저 - 에 대한 논의가 활발)

 

"스태프 엔지니어"는 주니어와 시니어 개발자를 넘어서 팀 또는 조직에 얽매이지 않고, 팀장(매니저)와는 다른 리더십을 견지하며, 개발자들의 멘토와 코칭, 난도 높은 묹제의 해결 및 재발 방지, 조직 간의 기술 조율, 전체 제품이나 전사 개발 전략의 제안 및 조언 등을 주 역할로 하는 개발 트랙의 최상위 역할로 소개된다.

 

이 책의 저자는 구글과 그 이후 회사의 스태프 엔지니어로써 오랜 기간 활동하면서 '스태프 엔지니어'의 정의와 역할에 대해 여러 기고와 컨퍼런스를 통해 활발한 논의를 이어가고 해당 직군을 정립해 나가고 있으며, 이 책을 통해 막연하게 여겨졌던 '스태프 엔지니어'를 개발자의 다음 역할 중 하나로 자신있게 소개하고 있다.

 

구체적으로는 '스태프 엔지니어'가 가져야 할 3가지 덕목 즉, '빅 픽처 관점의 사고력', '성공적인 프로젝트 실행력', '조직 차원의 레벨업'을 각각 한 개의 부로 나누어 설명한다. 단지 어떤 역할을 해야 한다는 선언적 문구 뿐 아니라, 실행에 관한 이야기도 다루고 있는 점은 저자의 경력에 따른 역량이 잘 드러나는 지점이다.

 

다만, 국내 특히 소규모의 개발 조직은 아직까지 개발과 관리의 역할 분리가 명확하게 이루어지지 않고 있고, 특히나 조직 위계가 명확한 편이어서 관리자와 비슷한 권한과 역할을 가진 '스태프 엔지니어'에 대한 이질감이 적지 않을 듯 하다. 그래도 조직 내 구성원의 선순환과 조직의 경쟁력인 실력 향상을 위해 각자 처한 환경에 맞게 개발자의 다음 경력을 준비하는 편이 도움이 되리라 생각한다.

 

앞서도 말했지만, 현재 나의 역할은 개발자로써의 역할 보다는 관리자로써의 역할이 더욱 확대되는 경향성이 있으므로 이 책을 참고로 매니저의 경력 트랙에도 좀 더 관심을 가져볼 생각이다. 최근에 '프로덕트 매니지먼트'를 위시하여 여러 관리자 트랙의 좋은 책들이 나오고 있다. 양 측면을 잘 보완하면서 관리자로써도 개발자로써도 만족하는 경력을 쌓고 싶다.

 

 

프로덕트 매니지먼트 - 김영욱 지음/한빛미디어

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

관심-삶을 재발견하는 최고의 법칙 국내도서>자기계발 저자 : 척 마틴(Chuck Martin) / 김명신역 출판 : 북스캔 2006.09.13 상세보기

2006년인지는 정확하지 않지만 이 책, 이전에 한번 읽은 적이 있다. 그 당시 별 감흥이 없었던 책은 2012년 현재 어떤 느낌일까? 오늘 이 책을 읽으면서 느낀 점을 남겨보겠다.

'관심'이라는 제목의 이 책은 일에 파묻혀 (정확히는 자신의 일에 파묻혀) 주변을 돌아보지 못하는 관리자 (그 중에서도 부서 책임자, 이사, CEO)들에게 /본인의 일을 잠시 멈추고/주변을 돌아보아/개선점을 찾아내고/실행을 통해 의미 있는 변화를 이끌어내고/다른 사람에게도 이러한 변화를 전파/하는 것이 궁극적으로는 더 생산적이고 더 효율적이라고 설파한다. 

책을 다시 읽고 보니 이전에 이 책을 읽었던 그 당시에 감동이 별로 없었던 이유를 알 것 같다. 나의 변화를 이끌어내고 이를 다른 사람에게 전파하는 데에는 직급이 높고 영향력이 클수록 효과적이고, 당시 나의 위치는 그러하지 않았던 것이었다. 이 책의 주된 독자 층을 꼽아보라면 단연코 임원진이라고 생각한다. 책의 예시에서 보듯 '관심'의 전파는 하향식으로 이루어지는 것이 자연스러운 까닭이다. 현재의 나는 아직 그러한 위치에 있지 않고 따라서 아직도 이 책이 나에게 주는 감동과 공감은 그다지 크지 않은 것 같다. 물론 지난 번보다는 훨씬 와 닿는 내용이 많은 것으로 보아 이 책은 정말 관리자에게는 유용할 가능성이 큰 책인 것 같다. 5년 후나 10년 후의 나라면 어떨까 고민해 보면서 이 책의 감상을 마친다. 

몇 가지 특이점을 기록하고 이 후기를 마치고 싶다. 이 당시(2000년 초중반)의 자기 개발서 들은 거의 비슷한 형식을 따르고 있는데, 최근에 이런 자기 개발서를 보지 않아서 현재도 그런지는 모르겠다.

몇 가지만 꼽아보면, 

첫째로 이러한 자기 개발서는 액자 소설의 형식을 차용한다. 즉, 액자 밖의 주인공들이 액자 안의 주인공의 예시를 통해 어떤 깨달음을 얻는다는 것이다.

두번째로 이러한 깨달음은 항상 다른 사람에게 전파해야 한다는 것이다. '누가 치즈를 옮겼는가'로 대표되는 자기 개발서가 이런 형태이다. 

거의 비슷한 내용을 재반복하는 자기 개발서의 무개성에도 불구하고 꾸준하게 이러한 종류의 책이 소비되는 이유는 무엇일까? 정말 효과적인 방법이기 때문일까? 효과적이게 보이도록 착시 효과가 큰 까닭일까?

몇가지 기억에 남는 문구

1. 멈추지 않고 일을 하니까 하면 할수록 효율성이 떨어지는 겁니다. 

1-1. 문제는 사람들이 휴식다운 휴식을 충분히 취하지 못하는 데 있어요.

; '선생'이 빌에게 멈춤의 중요성을 설명하면서

2. 일이 성사되도록 도와주는 직원과 비서에게 감사해야 합니다.

; '관심'을 실행에 옮기는 단계인 '변화하기'에 대해 설명하면서

2-1. 스트레스의 신호를 찾아내고 더 많은 사람에게 고맙다고 말하는 것 이외에 또 무슨 일을 해야 하죠? / 정말 어려운 건 지속적으로 노력하는 거죠.

; 감사하는 것 외에 무엇을 더 해야하는 지 묻는 빌에게 무엇을 하는지 보다 꾸준히 무엇을 하는 것이 더 중요하다고 말하는 '선생'

3. 경영진에 대한 신뢰와 믿음이야 말로 직원들의 애사심을 높이는 데 가장 효과적인 덕목이죠.

3-1.보수는 회사에 대한 기여도를 양으로 평가하는 공식적이고 유일한 기준인 셈입니다.

; 경영자들이 직원과 연봉에 대해 취해야 하는 자세에 대한 설명

4. 변화는 타인의 영역에서 일어날 때에만 훌륭한 것이라고 여기죠.

; 변화에 대한 두려움과 반발을 설명하면서

5. 하기로 마음먹은 일을 끝까지 실천하는 겁니다.

; 변화하기의 핵심

6. 일을 멈추고만 있으면 실제로 일은 언제 어떻게 하나 궁금해하고 있을 겁니다.

6-1. 이미 시행되고 있는 작업 과정들 중에서 제거할 일을 결정하는 겁니다.

6-2. 이미 익숙해진 것을 중단하기보다 새로운 걸 시작하는 것이 훨씬 쉽긴 하죠.

; 일을 다 처리하는 것이 능사가 아니라 제거할 일을 찾아 효율성을 높이는 방법과 어려움을 설명

6-3. 직원들이 일을 멈추고 주위에서 불필요한 일을 찾아내 그 과정을 없애면, 회사 전체가 정말 필요한 일에 집중할 수 있겠군요.

; 도요타의 린 개발과 유사

7. 새로운 사업을 개발하는 일과 기존 고객의 만족을 유지시키는 프로그래밍 부문이 양립하기란 어려운 일이라는 사실을 발견했다.

; 유지보수와 신규 개발을 한 곳에서 진행할 때의 어려움을 묘사. 사실 관계 설명은 부족

똑똑하고 100배 일 잘하는 개발자 모시기 국내도서>컴퓨터/인터넷 저자 : 조엘 스폴스키(Joel Spolsky) / 이석중역 출판 : 위키북스 2007.09.18 상세보기

• 명령 복종에 대한 거부감
• 미시적인 관리가 불가능함(기본적으로 관리자수가 부족하고, 아래로 동일한 업무를 부여할 수 없기 때문. A는 A의 일, B는 B의 일이 있음)
•  개발자가 팀장보다 더 많은 정보를 가짐

때문에 쉽게 성공할 수 없는 관리 방법이라고 한다. 이 관리의 핵심은 상명하복할 수 있는 복종훈련이 선행되어야 한다는 것인데, 군인이 아니고서야 이러한 훈련이 쉽지 않고 성과도 없다고 봐야 하기 때문이다.

두 번째로 'Econ101'식 관리 방법은 Econ101의 의미를 파악하면 쉽게 이해할 수 있다. Econ은 economy의 약자이고 101은 학과 과정중 대체로 개론 부분이 101임을 감안하면 "경제학 개론에 의한 관리 방법"이라고 보면 되겠다. 이 방법은

• 조직원의 사기를 보상(돈)으로 유혹할 수 있다는 점이 핵심

• 동기 유발을 포상과 불이익 등 금전적인 채찍과 당근으로 할 수 있다는 의미
•  내재적 동기유발이 아닌 외재적 동기유발
•  국소적인 성과 극대화 (버그지수가 낮으면 성과금을 지급하겠다! 등)
•  방임 - 가르치는 대신 결과에 대한 보상, 책임을 회피
  

가 주 내용이다. 이와 관련해서 조엘의 냉소적인 대음 문단이 기억에 남아 적어 보겠다.

"개발자들은 이처럼 영악하다.

회사가 아무리 성과를 객관적으로 평가하려고 해도 저들은 회사의 평가 기준에 맞게 자기 성과를 극대화할 수 있는 방법을 찾아낼 것이고 회사는 원하는 결과를 얻지 못할 것이다."

마지막으로 identity 관리 방법인데, 조엘이 추구하는 관리 방법이라고 한다.

• 조직의 목표가 대체로 고결, 사회적으로 바람직

• 정보를 공유, 개개인의 결정에 반영

개 인의 동기를 유발하는 방법이 외부에 있지 않고 개인의 내부에 있으며 이러한 형태가 가장 이상적인 관리 방법이라고 본다. 최근 성행하는 관리 기법들을 보아도 함께 생각하고, 동의를 구하여 행동하며, 성과를 나누는 등 조엘이 주장하는 관리 방식을 따르는 회사가 많아지는 것이 무관하지 않은 것 같다.

부록으로는 12가지 단답형 질문을 통해 건전한 IT조직인지 개선이 필요한 조직인지 알아보는 조엘 테스트를 요약하여 실어 놓았는데, 기존에 "조엘 온 소프트웨어"에서 읽은 내용이지만, 기억에 남는 몇 가지만 추려서 정리한다.