chirho's network world

안녕하세요, 오늘부터 매니저입니다 - 윌 라슨 지음, 장현희 옮김/길벗

소재의 특징 때문에 관심이 가는 책이었다. 일반적인 매니저에 관한 책은 많으나, 기술자들의 매니저로써 역할에 대해 설명하는 책은 드물고 특히, 매니저들을 관리하는 매니저에 관한 책은 들어본 기억이 없어 관심이 갔다.

1장과 7장은 다른 책이라면 머릿말(혹은 작가의 말)과 부록이고, 2장부터 6장까지가 본문에 해당한다. 2장에서는 조직, 3장은 도구, 4장 접근법, 5장 문화, 6장 경력에 관해 나누어 설명한다. 저자의 이력이 엔지니어로 시작해 매니저로 일한 만큼 개발자 세계의 매니저의 역할과 매니저의 매니저 (매니저 관리자)로써의 역할에 대해서 두루 알고 설명하고자 한다.

첫 저작물인 듯 거친 문장이 눈에 띈다. 군데군데 비문도 보이고.

투박한 번역투는 그럴저럭 여러 번 읽어 적응될 만 하다해도 용어의 직역은 그 뜻을 쉽게 파악할 수 있도록 원문 단어를 병용하던지 역주가 필요하다.

예를 들어 2장의 '팀'과 '조직'은 문맥상 상하위 포함 관계로 보이나, 왜 이렇게 번역했는지 알면 더 좋았을 것이다. (원문을 찾아 읽어야 하나) 저자의 의도가 좀 더 명확했으면 싶은 부분도 있는데, '팀'의 리더(팀장) 혹은 '조직'의 리더(관리자의 관리자)가 어떤 역할을 해야 하는지 먼저 설명한(주장) 후, 팀의 규모가 적거나 많을 때의 장담점을 설명해야 하지 않을까? 싶은 부분도 존재한다.

문제는 이 책이 번역서라는 것이다.

역자의 능력에 따라 거친 문장도 미려한 문체로 번역(의역)될 수 있다고 생각한다.

'저자의 후속작이자 같은 번역가의 전작'(스태프 엔지니어)의 번역 품질을 생각하면 더 아쉬움이 남는다.

스태프 엔지니어 - 윌 라슨 지음, 장현희 옮김/길벗

주제가 참신하고 관심이 가는 책이었는데, 아쉽다.

# 출판사에서 이벤트로 책을 제공 받아 리뷰를 작성하고 있습니다.

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

 

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

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

개발 7년차, 매니저 1일차 - 카미유 푸르니에 지음, 권원상 외 옮김/한빛미디어

내부 사정으로 "개발실 관리자"와 "개발팀장"을 겸직하게 되면서, 이전에 각각 업무를 맡을 때와는 다른 경험을 하고 있다.

개발실 매니저로써 각 팀이 성과를 내도록 R&R을 부여하고 업무를 조율하며, 개발실 전체의 목표를 구상하고 모니터링하다가, 비슷하지만 scope이 더 세밀하고 상세한 팀원 관리 및 '개발팀장'의 업무를 3-4년 만에 다시 경험하게 되니 그 책임감과 그에 따른 스트레스가 꽤 컸던 것 같다.

근래에 잘 안 아팠었는데, 잔병 치레도 많이 하게 되고, 잘 유지되면 다이어트가 일순간 무너지기도 했다. (물론 결과론적 핑계다. ^^)

'팀 관리' 업무와 '개발실 관리' 업무는 비슷하지만 어떤 부분은 명확하게 큰 차이가 있었고, 특히 두 업무를 병행하게 되니 어떤 기준으로 팀 (또는 개발실)을 지원해야 할지 케이스별로 모호한 측면도 생겨서 한 동안 애를 먹은 것 같다. 충분하지는 않지만 이미 관리자로써 어느 정도 경험을 했다 생각했는데, 현실에 부딪혀 보니 '공부가 부족했다', '공부해야 겠다'는 생각이 절로 들었다. 그래서 최근에 리더십, 관리 측면의 책을 많이 읽게 된다. 이 책도 그 중 하나다.

서론이 길었는데, 이 책의 저자는 미국 테크 기업에서 '개발자'로 시작해 '테크 리드 (TL)'을 거쳐 '매니저' 업무를 수행하고 있는 소위 '개발자 출신' 매니저다. 스스로 개발자에서 매니저로 경력을 쌓는 과정에서 '개발 관리'에 대해 다루기 때문에 우리 상황에도 잘 맞고 배울 점도 많다.

TL의 경우 우리는 매니저 업무와 결합한 '개발팀장'으로 운영되고 있고, 저자의 경험과는 일부 다른 부분도 있지만, 매니저 업무를 제외하면 개발팀장과 책 속 TL의 역할은 거의 비슷하기 때문에 큰 무리없이 현 상황과 적용시켜 읽을 수 있었다.

특히, 개발자가 '시니어' 개발자가 되거나, TL을 거쳐 '매니저'가 되기까지 이상적인 역할과 현실을 고루 설명하는 부분은 매우 공감되었다.

조직이 성장하고 발전할수록 내부 구성원의 경력 관리가 중요한 이슈가 된다. 현재 개발팀장의 역할을 맡고 있거나 앞으로 관리자가 되고 싶은 개발자, 심지어 팀장의 역할이 적성에 맞지 않아 싫은 개발자들도 읽어보면 공감가고 도움이 될 만한 부분이 많다.

모든 개발자에게 필독을 권한다.