<div id="readability-page-1" class="page"><div id="skip-nav"><h2>그대들, 어떤 사다리를 오를 것인가</h2><time>2024-02-04 에 작성하고, 2024-02-04 19:03:35 에 업데이트한 문서입니다. ✅</time> — <a href="/tags/books">Books</a>, <a href="/tags/career">Career</a> — 6 min read<section>
 
 <img alt="배너" title="배너" src="https://juneyr.dev/static/19e208ee453560be9bd1ae8ff1a5627b/7d769/banner.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy" decoding="async">
 <h2 id="서론"><a href="#%EC%84%9C%EB%A1%A0" aria-label="서론 permalink"></a>서론</h2>회사의 시니어 스터디를 마쳤다. 두 권의 책을 읽어가며 생각을 나눴는데, 그 책은
<code>&lt;&lt;개발자를 넘어 기술리더로 가는길&gt;&gt;</code>, 그리고 <code>&lt;&lt;개발자 7년차, 매니저 1일차&gt;&gt;</code> 다. 사실 <code>&lt;&lt;개7매1&gt;&gt;</code> 은 출간 직후에 읽어봤는데, 너무 뻔한 이야기라고 생각되면서 내가 매니징을 할 일은 없다.. 라고 하면서 머릿속에서 잊혀졌던 경험이 있어, 초반에는 사실 좀 회의적인 부분이 있었다.<hr>책을 '스터디' 라는 형태로 읽고 생각을 나눠보니 경험이 좀 달랐다. 기술을 파고들지 않는 스터디는 처음인데, 요약은 최대한 간단히 하고 해당 장에 관련된 주제를 과제 형태로 부여하고 그 답을 스터디시간에 모여서 나눴다. 그러니, 자연스레 다양한 매니징과 기술리딩에 대한 경험들이 공유되어서 상당히 좋은 경험이었다. 업무는, 리딩하는 사람이 어떤 생각을 기저에 가지고 운영을 진행하냐에 따라서 참여하는 작업자의 경험은 판이하게 달라진다. '어떤 생각' 파트에 초점을 두고 토론을 개진했기때문에어떻게 저런 좋은 리딩을 할 수 있었는지, 운영하면서의 넘어짐은 왜 였고 뭘 간과했는지 등 현직 리더분들의 경험을 아주 쏙쏙 뽑아먹을 수 있는 기회였다. (정작 그래서 막 시니어로의 길에 발을 들인 중니어들만 이득을 본 것 같지만 😅)개발자로서 어떤 길이 보통 제공되고 있고 어떤 역량이 계속해서 필요한지는 직접 알아봐야하는 경향이 있다. 그 길에서 이 책은 충분히 읽어볼 가치가 있다. 리딩 경험이 이제 필요한, 혹은 많이 해본 사람들과 하면 더욱 좋겠다. <hr>스터디의 맛은 총정리 아니겠어. 이 두 권의 책과 스터디에서 내가 느낀 점과 그래서 뭘해야하는데 . . . 를 정리해본다. <h2 id="경력-사다리"><a href="#%EA%B2%BD%EB%A0%A5-%EC%82%AC%EB%8B%A4%EB%A6%AC" aria-label="경력 사다리 permalink"></a>경력 사다리</h2>
 
 <img alt="ladder" title="ladder" src="https://juneyr.dev/static/e591a8b61f846e2533aee54f1a7585ed/7d769/ladder.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy" decoding="async">
 levels.fyi 한번쯤은 외국계 IT기업을 들여다보며, 연봉 차트를 볼 수 있다는 <a href="https://www.levels.fyi/">https://www.levels.fyi/</a> 를 들어본 적이 있을 것이다. 들어가자마자 정면에는 다양한 기업의 엔지니어 직급 체계가 나온다. (아래로 갈수록 더 높은 직급) 인상적인 바는, senior 등급과 staff engineer 에 대한 언급이 좀 있다는 것이다. <code>개발자를 넘어...</code> 는 이 staff engineer 로 가는 길을 이야기 해주고 있다.<hr>staff engineer (스태프 엔지니어)는 매니저가 아닌, 기술 리더를 의미한다. <code>개발자를 넘어...</code> 에서는 스태프 엔지니어의 역량으로 다음을 꼽고 있다.<ul><li>빅 픽처 관점의 사고력</li><li>성공적인 프로젝트 실행력</li><li>조직 차원의 레벨업 </li></ul>그러니, 단순히 팀안에서 활동하는 시니어 엔지니어에서 더 발전해서 스태프 엔지니어는 시야를 확장해서 회사 전체, 나아가 사업적인 면모도 볼 수 있는 엔지니어로 역할을 수행하며 기술적인 결정을 내려야한다. 그러나 여전히, 매니저에 비해서는 개인 기여자 (individual contributor) 에 가까운 역할이며, '위로 올라갈수록 기술과는 많이 멀어지는 거 아니야?' 라는 우려를 종식시켜주는 역할이다.반면 매니저는 전문 관리 리더십이면서, 프로젝트를 관리하고 사람을 관리하는 역할을 한다. 매니저는 팀원에게 피드백을 주고, 교육하고 성장을 돕는다. 매니저는 목표를 설정하고, 프로젝트가 성공적으로 진행될 수 있도록 가이드한다. 스태프 엔지니어에 비해서 조직에서의 개개인을 더 케어하고 집중하는 역할 역시 맡는다. 시니어 엔지니어는 어느 순간이 되면 스태프 엔지니어와 매니저의 기로에 선다. 기술 전문 리더십으로 갈 것인지, 관리 리더십을 할 것 인지의 결정을 해야하는 시점에 도달하는 것이다. 여기서 어떤 것을 선택할지는 여러 면면을 봐야겠지만, 한 가지 알아둬야할 점은 스태프 엔지니어에서 매니저로, 매니저에서 스태프 엔지니어로의 이동은 경력 사다리에서 위보다는 옆으로 이동하는 일이라는 점이다.
 
 <img alt="skill" title="skill" src="https://juneyr.dev/static/10cb2ae8dbba92a498ab18cd21638047/7d769/skill.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy" decoding="async">
 언젠가는 당신만의 스킬 트리를 찍어야하는 순간이 온다. 해서, 어떻게든 시니어 엔지니어에 발을 들이게 되었다면 다음 사다리를 준비해야할 지점이 빠르게 도달한다는 의미다. 다만 한국에서는 리더에게 스태프 엔지니어와 매니저의 역할을 동시에 부여하는 조직이 꽤 많다보니, 이 점이 명확하지 않아 보일 수도 있다.그럴때는 나의 개인적인 경험을 참고하면 좋을 것 같다. (한국임) 나의 첫 팀은 최소 경력이 나와 10년 이상 차이나는 시니어 엔지니어 n명, 스태프 엔지니어 1명, 그리고 매니저(팀장님) 으로 이루어진 팀이었다. 팀장님은 기획, 다른 개발팀과의 직접적인 소통, 교통정리, 업무 분장, 프로젝트 매니지먼트에 집중했고 스태프 엔지니어는 전체적인 프로젝트에서의 기술적 결정 진행을 담당했다. 코딩업무를 직접 진행하지는 않았다. 스태프 엔지니어는 직급 상으로는 나처럼 동등한 팀원이어서 나의 연봉이나 거취를 직접적으로 정하진 않았다. 그러나 내게는 기술적인 참고서가 되어줬고, 결정의 기반이 되었다. 팀장님은 반면 시니어 엔지니어 중 한명을 할당해서 나의 개발적 성장을 도울 수 있도록 직접적인 해결책을 제공하거나 정신적인 지지책이 되었다. 아래에서 말해볼 스태프 엔지니어의 일과 매니저의 일을 보면 좀더 이해가 될 것 같다. 🙂<hr><h2 id="스태프-엔지니어의-일"><a href="#%EC%8A%A4%ED%83%9C%ED%94%84-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EC%9D%98-%EC%9D%BC" aria-label="스태프 엔지니어의 일 permalink"></a>스태프 엔지니어의 일</h2>많은 개발자들이 '나는 그냥.. 개인 기여자로 살고 싶어.. 다른 사람과의 계속되는 소통이나 관리업무는 너무 괴롭다..' 라고 생각하는데, 좋은 소식과 나쁜 소식이 하나씩 있다. 좋은 소식은 사람 관리를 직접적으로 안해도 되는 트리 (스태프 엔지니어) 가 있다는 것이고, 나쁜 소식은 소통은 원래 개발자의 일 중에 하나이며(ㅋㅋ) 더 위로 올라갈수록 어쩔 수 없이 소통의 중심이 된다는 것이다. 스태프 엔지니어가 시니어 엔지니어와 구분되는 점이 바로 위에서 말했던 역량이다. <ul><li>빅 픽처 관점의 사고력<ul><li>첫째, 스태프 엔지니어는 팀 전체의 기술적 결정을 주도한다. 전체적인 일에 대한 맥락을 정확하게 알고 적확한 적정 기술을 선택한다. </li></ul></li><li>성공적인 프로젝트 실행력<ul><li>둘째, 스태프 엔지니어는 위급 상황 및 개발적 결정 상황에서 리딩한다. 시스템에 장애가 전파해서 대응해야하는 시점에서 스태프 엔지니어는 다른 멤버들의 액션을 요청해서 해결하게 만든다. </li></ul></li><li>조직 차원의 레벨업
셋째, 스태프 엔지니어는 시니어 엔지니어와 스태프 엔지니어의 다음 세대를 구축하는데 신경쓴다. 그들의 성장에 적합한 다양한 프로젝트와 기회를 제공해야한다. </li></ul>물론 구체적으로 스태프 엔지니어가 될 것인가 역시 스태프 엔지니어의 선택에 달렸다. <ul><li>단독 문제에 집중하는 게 좋은지 vs 특정 기술 분야에 초점을 맞추는게 좋은지 </li><li>코딩이 좋은지, 프로덕트 관리, 프로젝트 관리, 인사관리 중에 선호하는 쪽이 있는지 </li><li>코딩 작업을 어느 정도하는 스태프 엔지니어가 될 것 인지 </li><li>만족감이 정체된다면 어떻게 처리할 예정인지 </li></ul>등등의 결과로 다양한 유형의 <a href="https://staffeng.com/guides/staff-archetypes/">스태프 엔지니어 유형</a>을 생각해볼 수 있다. <hr><h2 id="매니저의-일"><a href="#%EB%A7%A4%EB%8B%88%EC%A0%80%EC%9D%98-%EC%9D%BC" aria-label="매니저의 일 permalink"></a>매니저의 일</h2>매니저는 흔하게들 생각하는 '시니어 개발자의 종착지'다. 다만 여기서는 위에서 살펴본 것처럼 스태프 엔지니어의 책무와 매니저의 책무가 나뉜 시점의 매니저를 의미하여 명시해본다. 시니어 엔지니어때와는 매니저의 업무는 매우 다르다. 시니어 엔지니어가 더 심화된 느낌의 스태프 엔지니어와는 판이하다. <ul><li>매니저는 팀을 관리한다. 매니저는 팀을 통제하고 전체적인 결정을 내리며, 명확한 목표를 제시한다. 팀의 문화를 만들고 가꾼다.</li><li>매니저는 팀원들을 관리한다. 매니저는 팀원과 1 on 1 미팅을 계속해서 진행하고, 팀원의 성장을 돕기 위한 지원을 진행한다. </li><li>매니저 역시 기술 역량을 계속해서 유지한다. 시니어 개발자나 스태프 엔지니어가 존재해도 그들의 결정을 이해하고, 그들이 결정에 책임을 지도록 도울 수 있다. </li><li>매니저는 전체적인 제품 로드맵을 관리한다. 블로커가 있다면 어떤 지점인지 파악하고 생산성을 높이기 위해서 팀에 프로세스를 도입하거나 블로커를 직접적으로 제거한다. </li></ul>매니저로서의 역할을 하다보면, (일반적으로) 처음에는 하나의 팀을 맡아서 진행하게된다. 보통 테크리드 (스태프 엔지니어 + 약간의 매니징)과 협업하거나 혹은 테크리드가 직접 되어서 매니징을 진행한다.
그 다음은 사실 회사상황에 따라 다르다. 여러 팀의 테크리드에게 보고를 받는 직군이 되는 경우가 있다. 이는 엔지니어링 디렉터 라는 이름을 갖고, 기술 조직의 여러 부문에 영향력을 미치며 부서 간 협업에서 커뮤니케이터 역할을 띄게 된다.
혹은 매니저들을 관리하는 매니저가 될 수도 있다. 이 경우 매니저들에게 책임을 일깨우고, 좋은 매니저가 될 수 있도록 도우며, 매니저를 채용한다. 특정 조직에 문제가 생기면 해당 조직을 살펴보면서 어디서부터 잘못되었는지 디버깅하기도 한다. <hr><h2 id="사다리를-오를-때-도움이-되는-지침"><a href="#%EC%82%AC%EB%8B%A4%EB%A6%AC%EB%A5%BC-%EC%98%A4%EB%A5%BC-%EB%95%8C-%EB%8F%84%EC%9B%80%EC%9D%B4-%EB%90%98%EB%8A%94-%EC%A7%80%EC%B9%A8" aria-label="사다리를 오를 때 도움이 되는 지침 permalink"></a>사다리를 오를 때 도움이 되는 지침</h2><code>개발자를 넘어...</code> 에서는 이 사다리를 오르기 시작한 사람들에게 도움이 될 만한 지침을 준다. 가장 중요한 건 당신의 우선순위가 무엇인가? 다. 모든 사람이 사다리 오르기를 원하는 것은 아니다. 사다리를 오르기 전 가장 시간을 내어 들여다봐야할 것은 자신의 내면이다. 나에게 일은 어떤 의미이며 삶에서는 어떤 위치에 있는가? 내가 괴로울 때 가장 먼저 놓아버릴 것은 무엇이며 어떤 점을 끝까지 지킬 것인가? <ul><li>경제적 안정</li><li>가족 부양</li><li>유연한 일정</li><li>지적 만족</li><li>성공의 롤모델</li><li>재미 추구 </li><li>도전 정신</li><li>부의 축적</li><li>경험 추구 </li><li>변화 창조 </li><li>본업 유지 </li></ul>이런 점을 곰곰히 생각해보면 내가 어디로 가야할지에 대한 대략적인 감을 잡을 수 있다. 반경 100m 안까지는 갈 수 있을 것이다. 그 다음에는 내가 정말 어디로 가야하는지를 설정하면 좋다. 다른 사람들은 어떤 여정을 밟아왔는지 보면서 생각해보자. 자료를 읽자. 미팅을 참석하자. 그리고 그 사다리 위로 올라가기 위해서 어떤 스킬이 필요한지 파악하고 투자하자.기술적인 스킬 역량 강화가 필요한가? 잘해야하고 잘하고 싶은 것에 집중하고 노력해서 시간을 투자해야한다. 어떤 스킬이 당신에게 가치가 있는지 알아보고 초점을 깊이 파라.
의외로, 인맥이 필요할 수도 있다. 스킬 역량을 쌓는 것만으로는 원하는 곳으로 이동할 수 없을 수도 있다 (책에서 인용한 한 기사에 다르면 70-80%의 공고가 인맥으로 채용이 이뤄진다고 한다.) 인맥을 쌓아두면, 유능한 사람들의 행동양식을 관찰할 수 있을 뿐 아니라 통찰력이 생긴다. 이 부분 역시 훈련을 통해 가능하다.
이런 부분들을 드러내야할 수도 있다. 책에서는 가시성 확보 라는 이름으로 지칭한다. 오픈 소스 기여, 실무단 활동, 기사 작성, 팟캐스트, 영상 강연 등으로 외부 명성을 쌓을 수 있다. 이런 외부 활동은 선택적이고, 투자가 필요한 활동이다. 눈에 띄는 방식으로 유능함을 드러낼 방식을 찾아내자 .
역할 및 프로젝트 선정에도 공을 들이는게 좋다. 사실 위와 같은 내용을 가장 쉽게 할 수 있는 것이 내가 원하는 스킬을 하며, 관련된 인맥을 쌓고 드러낼 수 있는 조직과 프로덕트에서 일하는 것이다. 그러니 역할은 신중하게 선택하라.<hr><h2 id="두-권을-모두-읽고--그래서-지금은-뭘-해야하죠"><a href="#%EB%91%90-%EA%B6%8C%EC%9D%84-%EB%AA%A8%EB%91%90-%EC%9D%BD%EA%B3%A0--%EA%B7%B8%EB%9E%98%EC%84%9C-%EC%A7%80%EA%B8%88%EC%9D%80-%EB%AD%98-%ED%95%B4%EC%95%BC%ED%95%98%EC%A3%A0" aria-label="두 권을 모두 읽고 그래서 지금은 뭘 해야하죠 permalink"></a>두 권을 모두 읽고 : 그래서 지금은 뭘 해야하죠?</h2>나는 중니어에서 시니어 엔지니어가 되기를 요구받는 시점에, 팀에서 스터디를 꾸려주어 이 책을 읽었다. 말하자면, 한 단계 앞선 내용들을 배워본 셈이다. 당연히 마음에 실제로 와닿지 않는 내용이 대부분이었다. 아마, 실제로 해야하는 때가 오면 부랴부랴 어떻게 해야 좋은 스태프 엔지니어 / 매니저인지 펼쳐보게 될 것 같다. 다만, 먼저 해둘 수 있는 부분은 있다. <ul><li>이제는 단순히 떠밀려서 일하는 게 아님. 이 정도 되었으면 왜 일을 하는지 정확하게 파악하고 자신의 지향점을 알아둬야함. 또한 시간관리와 체력관리는 필수 - 스스로를 관리</li><li>프로젝트 관리나 프로덕트 관리, 약간의 사람관리는 두 직군 모두 공통이다. 원하는 바에 따라 다르겠지만 해당 부분의 역량은 미리 접해보는 게 좋다. - 넓은 관점의 스킬 습득 </li></ul>구체적인 지침으로는 다음과 같은 것들을 시도하거나 관심있게 보고 있다. 스스로를 관리<ul><li>TCI 검사/정식 MBTI 검사/BIG-O/버크만 등 자가 진단 검사에 대한 과정 트래킹 및 개선점 적용 <ul><li>나를 성찰해서 얻는 나에 대한 결론도 있지만, 사람과 상호작용할 때 나오는 반응으로 나를 정확하게 관찰할 수 있기도 하다. 어떤 때 당황하고, 어떤 때 즐겁고 하는 것도 계속 생각해보고 있다. </li></ul></li><li>삶에서 어떤 업무나 일이 힘을 주고 빼는지 파악<ul><li>여러 취미도 시도 중 . . 😀 </li></ul></li><li>꾸준한 운동 및 식단관리 </li><li>업무 분야의 명확한 설정을 위해 설정 - 시도 - 피드백 - 재시도 루프</li></ul>넓은 관점의 스킬 습득<ul><li>각 feature 당 프로젝트 관리자 역할을 담당<ul><li>MD 관리, 프로젝트 순항 체크 🛳, 진행상황 체크 및 피드백</li></ul></li><li>기술적 결정에서 명확한 근거가 있도록 하는 연습<ul><li>여태 해왔어서, 라는 것도 하나의 근거지만 그런 방식의 근거에서 탈피 </li><li>좋은 코드, 적정기술, 프로젝트 상황을 고려한 기술 적용에 대한 고민</li></ul></li><li>사람관리<ul><li>사람에 대한 관심 <ul><li>책이나 실제 관찰을 통해서 얻어내는 중 </li></ul></li></ul></li></ul>이런 과정들을 통해서 어떤 곳을 지향해야하는지 좀 가이드라인이 잡힐 걸로 기대하고 있고 끊임없이 생각해보고 있다. 솔직히 여러가지 스킬들에 좀더 숙련도가 필요하고, 생각보다 넓은 범위의 수련이 요구되는 바라서 막막하기도 하다. 이렇게 여러 분야에서 노력하다가, 생각보다 이런 과정이 지치고 지향점이 아닌 것으로 판명되면 시니어 엔지니어 레벨로 계속되는 삶을 선택할 수도 있을 것이다. (경력사다리를 오르지 않는 것도 결정이다!) 하지만 일단 선택의 시점이 왔을 때, 후회않도록 최대한 노력하고 정보를 모아 결정해보려고한다. :) 그 정보를 모으는 일환으로 이 책들을 읽는 거 나름 추천한다. <h2 id="참고"><a href="#%EC%B0%B8%EA%B3%A0" aria-label="참고 permalink"></a>참고</h2><ul><li>타냐 그레일리. (2023).&nbsp;개발자를 넘어 기술리더로 가는 길. 한빛미디어.</li><li>카미유 푸르니에. (2020).&nbsp;개발 7년차, 매니저 1일차&nbsp;(1st ed.). 한빛미디어.</li></ul></section></div></div>

그대들, 어떤 사다리를 오를 것인가

댓글