시니어 개발자 너머의 길, '리드 개발자'

개발자라면 누구나 시니어를 꿈꾸지만, 그 너머 '리드 개발자'라는 역할 앞에서는 막막해지기 마련이다. 코딩만 잘해서는 안 될 것 같은데, 그렇다고 관리자가 되는 것은 아닌 그 모호한 경계. 바로 그 지점을 파고드는 반가운 책, 'Lead Developer Career Guide' 이다.

개발팀의 구심점을 위한 안내서

아마 비슷한 주제의 책들이 여럿 있었지만, 경력 관리나 리더십 원론에 그쳐 아쉬웠던 기억이 있다. 이 책은 철저히 '개발팀의 리드'라는 역할에 초점을 맞춘다. 번역 품질도 준수하고, 현업의 예시가 많아 술술 읽히는 수준이라 개념을 이해하는 데 큰 문제가 없다.

무엇보다 이 책은 기술적 탁월함(Technical Excellence)과 팀 리더십 사이의 균형을 강조한다. 기술을 놓지 않으면서 어떻게 팀을 이끌고 프로젝트를 성공시킬 수 있는지, 그 실질적인 노하우를 다루는 점이 가장 마음에 들었다. 다만 너무 많은 주제를 다루려다 보니, 그 깊이가 부족한 부분도 있지만 어쩔 수 없는 부분이지 싶다.

내용을 살펴보면,

1장 '리드 개발자란 무엇인가?'라는 근본적인 질문으로 시작해, 2장에서 4장까지는 리드 개발자의 커리어 경로와 이 역할에 필요한 스킬, 그리고 더 나아가 개발자로서 스킬을 배우는 일반적인 방법에 대해 다룬다. 5장부터 8장까지는 기술 문서 작성, 개발 프로세스 최적화, 프로젝트 팀 및 클라이언트와의 협업 등 매우 실무적인 역량들을 상세히 설명한다. 마지막으로 9장에서 12장까지는 멘토링, 주도적으로 이끌기, 감성 지능을 활용한 리더십, 그리고 이 모든 것을 아우르며 성공적인 리드 개발자가 되는 법을 다루며 마무리된다.

이 책은 어떻게 읽어야 할까?

시니어 개발자가 되었다고 저절로 리드 개발자가 되는 것이 아니라는 점은 우리 모두 알고 있을 것이다. 이 책에 나오는 기법이나 역할들을 그저 흉내만 낸다고 해서 팀이 저절로 굴러갈 것이라는 환상은 갖지 말자.

과거에 어설프게 아키텍처 패턴을 적용하며 복잡도만 높였던 경험이 떠오른다. 리드 개발자의 역할도 마찬가지다. 이 책은 단순히 '무엇을 하라'는 체크리스트가 아니다. 각 장의 내용을 바탕으로 '왜 이 활동이 필요한지', '우리 팀의 현재 상황에 맞는 방식은 무엇인지'를 치열하게 고민해야 한다. 책의 조언들을 그대로 따라 하기보다는, 그 본질을 이해하고 자신의 팀에 맞게 조금씩 변형하며 적용해보는 것이 중요하지 않을까 싶다. 물론, 그 과정에서 겪는 수많은 실패는 성장을 위한 필수 연료겠다.

마지막으로,

훌륭한 리드 개발자는 '코드로 증명하는 것'을 넘어 '팀의 잠재력을 코드로 끌어내는 사람'일 것이다. 단순히 가장 뛰어난 프로그래머가 아니라, 팀 전체의 기술적 수준과 비즈니스 임팩트를 함께 높이는 역할이다.

자, 이제 이 책을 읽고 코딩 그 너머의 세계로 나아갈, 진정한 '리드 개발자'가 되어볼 차례이다.
(라지만 개인적으로 리드라는 말에는 항상 책임과 성과가 따르다보니 항상 어려운 영역이 아닐까 싶다.)

• 마인드셋 전환: 개인의 성취에서 팀의 성공으로 초점을 이동하며, 팀이 겪는 어려움에 대한 책임감을 갖춰야 한다
• 소프트 스킬의 중요성: 기술 스택은 빠르게 변하지만, 위기 관리, 갈등 해결, 효과적인 커뮤니케이션과 같은 소프트 스킬은 커리어 전반에 걸쳐 지속적인 가치를 발휘한다

• 개발팀 리딩, 프로텍트에 참여하는 팀과 협업, 클라이언트 및 이해관계자와 소통, 개발표준 설정, 기술 아키텍처 구축
• 개발팀 리딩 : 솔선수범, 신뢰구축, 멘토링
  • 긍정적이고 열린 소통 문화 구축, 팀원을 존중하고 공중하게 대하기, 팀원의 성장과 건강한 직장생활 영위를 위한 지지와 지원
  • 힘들고 부담되는 내용도 솔직하게 피드백할 수 있는 신뢰에 기반한 환경 조성
  • 팀원의 성장을 함께 논의하고 번 아웃에 빠지지 않고 생활하며 솔직한 고민을 나누고 방향 제시
• 프로젝트팀과 협업 : 프로젝트관리자,  QA팀, 클라이어트/이해관계자 직접 소통하며 협력
• 클라이언트 및 이해관계자와 의사소통 : 정말로 원하는 것은 무엇인지? 언어로 전달되는 피상적 내용 넘어 진실한 목표, 욕구가 무엇인지 알아내는 것이 매우 중요하며 이를 위해 능동적 경청을 사용

• 개발표준설정 : 팀 전체가 따라야 하는 개발표준을 만들거나, 준수시키는 것이 중요한 업무(생산성 측면).
• 기술아키텍처 구축 : 현재 업계표준과 관행을 기반으로 기술 아키텍처를 어떻게 구축할 지 이해하고 있어야 한다. 구현방식의 비용과 안정성도 고려해야 한다.

• 모범을 보인다 : 패닉에 빠지지 않고 침착하게 상황의 핵심을 파악하고 평정심을 위지하고 낙관적 태도를 유지한다. 전문성을 바탕으로 극복가능하다는 확신을 심어줘야 한다.
• 해결책에 집중한다 : 문제자체에 매몰되지 않고 해결책을 찾는데 집중하도록 격려. 이를 계기로 성장할 수 있도록 격려와 지지
• 서로 돕고 지원하는 환경 조성 : 편안하게 도움을 요청하고 우려사항을 표현할 수 있는 분위기를 조성.
• 효과적 소통: 내부 팀뿐만 아니라, 영향을 받는 외부 이해관계자(클라이언트, 고객사)에게도 상황을 투명하게 알리고 대응 계획을 공유해야 합니다.
• 자기 관리 연습 : 휴식, 일과 삶의 균형을 통한 에너지 충전을 항상 장려해야 한다. 긍정적 사고방식으로 채워져야 긴급상황에 대처할 수 있다.

1. 관리적 부분
   • 비용, 개발 소요 시간, 업무 우선 순위 : 주요 관리 항목이자 프로젝트 관리자/이해관계자와 커뮤니케이션의 대상이다.
   • 이 내용이 책 전반에 걸쳐서 무수히 반복되는 핵심 키워드일 정도로 리드 개발자는 이 3가지에서 떨어질 수 없다. 이해관계자와 만나는 접점이자 업무의 시작/변경/종결에 모두 영향을 주는 3요소이다.
2. 리더십 부분
   • 리드 개발자에게 바라는 리더십은  팀원 코칭/감정과리, 성장을 위한 멘토링, 팀/프로젝트 관리, 이해관계자 소통 , 채용/해고 등 매우 다양한 영역에 걸쳐있고 어느 하나가 문제가 생기면 전체에 영향을 준다.
   • 리드 개발자의 성패는 팀의 성패와 따로 분리할 수 없다. 시니어 개발자와 가장 차이나는 부분이며,  대부분의 업무가 팀과 프로젝트에 관련 업무이다.(개인의 기술력, 생산성 등의 문제가 아님)
   • 채용 또한 팀의 성공을 위해 중요한 부분이며 채용시에는 팀에 기여할 수 있는 사람을 뽑기 위한 구조적 질문을 준비해야 한다
   • 
   • 또한 팀원 관리도 빼놓을 수 없으며 피드백이 가장 중요한 역할을 한다. 효과적 피드백 기술은 아래와 같다.
   • 
   • 부정적 피드백 제공 부분에 개인적 관심이 커서 집중해서 읽었으며 이 부분은 경험적인 부분이라 지면으로 설명은 되었지만 좀 아쉬웠다.
     피드백은 팀 성장의 핵심이지만, 부정적인 내용을 전달할 때는 기술이 필요하다(이 기술에 대한 설명이 좀 아쉬웠다)
   • 
   • 또한 리드개발자가 피할 수 없는 업무의 영역인 “해고” 관련 내용도 있었다.
     심지어 아래와 같이 해고할 때 구체적 사례를 준비해 두고 해고 프로세스를 진행할 것을 조언한다.
   • 
3. 자기개발 부분
   • 리드 개발자는 네트워킹 중요하며 꾸준한 커뮤니티, 포럼, 이벤트, 컨퍼런스 참여와 oss 프로젝트 기여, 링트인 기술 문서 등등 통해 네트워크를 확장해 나가는 것이 장기적으로 효과가 크다.
   • 리드 개발자가 가지는 자기개발에서 부담되는 부분은 주로 끊임없는 학습, 커뮤니케이션을 비롯한 소프트스킬 기술 향상의 어려움(기술적 부분 대비), 자주 심리적으로 부정적인 영향을 주는 가면증후군(임포스터 신드롬) 등 다양하다. 아래는 부정적 사고가 침투하는 것을 막기 위한 안내이다. 실제 사례가 조금 있으면 좋겠으나 그 부분을 전문으로 다루는 서적이 아닌 이상 한계가 있고, 추가적인 공부를 위한 여러 자료를 제시하고 있다.
   • 
   • 리드 개발자로서의 역량을 끌어올리기 위해서는 선임/멘토 리드개발자의 의사결정 과정을 동행관찰(shadowing)하는 것의 유용함을 얘기하고 있으나, 과연 직장 생활에서 가능한 일일까? 좀 의심이 든다. 물론, 할 수만 있다면 직접 관찰에서 배우는 것이 가장 많을 것이지만 외국에서는 현실적인 것인가 하는 생각이 들었다.
   • 
   
   
4. 최종 감상평
   짧지 않은 내용(약 500페이지)에 리드 개발자란 어떤 사람이고 무엇을 하는/해야 하는 사람이고, 어떻게 리드 개발자가 되며, 된 이후에는 어떻게 성장해야 하는가라는 주제를 전체적으로 모두 짚고 있다. 책 전반적인 내용에도 나오지만 기술적 전문성에 대한 내용은 기술 범위가 너무 다양하기 때문에 간결히 설명되어 있고, 소프트 스킬과 경력개발에 관련된 내용 위주로 많이 기술되어 있다. 아마, 저자가 준비가 부족한 상태로 리드개발자의 역할을 수행하면서 이런 부분이 많이 아쉬웠다고 생각하는 부분을 기술했기 때문으로 보인다. 개발자적인 전문성 부분만 빼놓고 생각한다면 꼭 개발자만이 아니라 하나의 팀을 이끄는 리더에게 요구되는 많은 내용들이 있다고 보아도 될 정도이다. 기술적 내용이 아닌 책을 오랜 만에 봐서 머리에 신선한 자극이 되었고, 내가 막연히 그러려니 생각한 부분을 상세히 설명하는 책을 만나서 많은 생각을 하게 되었다.
   평생 개발자로만 살거야 하는 생각으로 직장 생활을 시작해도 상황에 따라서 혹은 본인의 숨겨져 있던(?) 적성에 따라서 경력을 발전시켜 나가는 과정이 많이 변하기도 한다. 개발자들은 주로 관리/커뮤니케이션/프리젠테이션/감정 관리 등 소프트 스킬 관련 업무를 힘겨워 하거나 힘들어서 회피하거나 혹은 혐오(?)까지 하기도 한다. 그러나, 사회생활을 조금만 한 사람들은 결국 팀이나 프로젝트가 성공해야 거기에 연관된 개인들도 성공하는 것을 잘 알고 있다. 반대로 리더의 커뮤니케이션 미숙이나 고객과 잘못된 커뮤니케이션, 우선 순위의 갑작스러운 조정 등으로 인해 팀에 소속된 개인들은 수 없이 많은 시간을 들여 고생해서 개발했으나 제대로 된 평가를 받지 못하는 경우도 숱하게 존재한다. 이런 경험을 할 때 마다‘우리에게 제대로 된 리더가 있었으면 이런 삽질(?)을 하지 않았을 텐데…… “라고 생각할 것인데, 이 책을 읽고 그렇게만 생각할 것이 아니라 리드 개발자로 성장하여 팀/프로젝트를 성공으로 이끌고 속한 개발자들을 성장시키는 것에 성취감을 느끼는 사람이 되는 것은 어떤가 하는 생각이 든다.
   내용을 다 보면 리드 개발자는 이런 걸 다 할 수 있어야 하는 거야?라고 할 정도로 많은 내용이 있는데, 내용 자체는 반복되는 것도 많고 편하게 읽을 수 있다. 이 책을 통해 평소 관심 가지고 있지만 구체적 내용을 모르고 피상적인 상상만 하던 분야를 새로이 알 수 있는 좋은 경험이었다. 개발과 관리의 중간 영역에서 팀과 프로젝트의 성공을 위해 분투하는 리드 개발자가 되려는 사람에게 좋은 길잡이가 되는 책으로 생각된다.
   
   좋은 책을 리뷰할 기회를 주신 제이펍에 감사드립니다.
   
   #제이펍 #리드개발자로가는길 #주니어개발자 #리더 #소프트스킬 #협업 #멘토링