|
| 1 | +--- |
| 2 | +title: "테크니컬 리더" |
| 3 | +date: "2025-10-16" |
| 4 | +cover: "/img/book/technical-leader.jpg" |
| 5 | +summary: "제럴드 M.와인버그 - 테크니컬 리더(Technical Leader)》" |
| 6 | +--- |
| 7 | + |
| 8 | +:::neutral |
| 9 | +사실 이 책은 2년 전 당시 팀장님으로부터 언젠가는 리더가 될 수 있으니 지금부터 준비하라는 말과 함께 이 책을 추천 받았다. |
| 10 | +책은 바로 주문했었지만, 바쁘다는 핑계, 지금은 다른 공부를 해야한다는 핑계 등으로 인해 책장에 고이 꽂아두기만 했었는데, |
| 11 | +시간적인 여유가 생기기도 했고, 리더라는 자리에도 욕심아닌 욕심이 생기게 되어 드디어 이 책을 펼치게 되었다. |
| 12 | +<b>《테크니컬 리더(Technical Leader)》</b>는 기술 조직에서 <b>리더가 실제로 어떤 사고 방식과 행동을 통해 문제를 해결하고 팀을 이끌어야 하는지</b>에 대해 아주 구체적으로 다루는 책이다. |
| 13 | +단순한 원론이나 추상적인 조언이 아니라, <b>리더가 문제를 다루는 구조 자체</b>를 이야기한다는 점에서 다른 리더십 책들과는 결이 확실히 다르다. |
| 14 | +솔직히 “왜 진작 안 읽었을까” 싶을 정도였다. |
| 15 | +::: |
| 16 | + |
| 17 | +--- |
| 18 | + |
| 19 | +이 책에서 가장 인상 깊었던 개념은 바로 <BlueText>문제 해결형 리더쉽(Problem-Solving Leadership)</BlueText> 이다. |
| 20 | + |
| 21 | +책에서는 리더십을 추상적인 개념으로 설명하지 않는다. |
| 22 | + |
| 23 | +대신 성공한 <BlueText>테크니컬 리더</BlueText>가 실제로 문제를 풀어가는 과정을 세 가지 단계로 보여주고 있다. |
| 24 | + |
| 25 | +- 문제를 정확히 이해하기 |
| 26 | +- 아이디어의 흐름을 관리하기 |
| 27 | +- 품질을 유지하기 |
| 28 | + |
| 29 | +이 세 가지는 단순한 체크리스트가 아닌, <BlueText>리더가 문제를 다루는 사고의 구조</BlueText>다. |
| 30 | + |
| 31 | +나는 이 부분에서 특히 공감하게 되었는데, 실무자로 일할 때는 물론이거니와 서비스의 메인 담당자로 일하면서도 이 세 가지를 체계적으로 생각해보진 않았고, |
| 32 | + |
| 33 | +관성에 의해서 일을 해왔던 것 같다. |
| 34 | + |
| 35 | +늘 "빨리 해결해야 한다" 는 압박감 때문에 곧장 해결책부터 던져버리는 경우가 종종 있었던 것 같다. |
| 36 | + |
| 37 | +### 문제를 정확히 이해하는 것 |
| 38 | + |
| 39 | +--- |
| 40 | + |
| 41 | +책에서는 먼저 <BlueText>문제를 정확히 이해하는 것</BlueText> 의 중요성을 강조한다. |
| 42 | + |
| 43 | +겉으로 드러난 증상에만 반응하게 되면 엉뚱한 방향으로 달리게 된다. |
| 44 | + |
| 45 | +이 책을 읽으며 내가 종종 `문제 정의`를 대충 건너뛰고 해결에만 몰두했었던 장면들이 떠올라서 조금 뜨금했다. |
| 46 | + |
| 47 | +### 아이디어의 흐름을 설계하는 것 |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +그리고 두 번째로 강조 하는 건 <BlueText>아이디어의 흐름을 설계하는 것</BlueText> 이다. |
| 52 | + |
| 53 | +책은 이렇게 말한다. |
| 54 | + |
| 55 | +> 좋은 리더는 정답을 독점하지 않는다. 정답이 흘러나올 수 있는 구조를 만든다. |
| 56 | +
|
| 57 | +그 동안 나는 리더라면 누구보다 먼저 정답을 제시해야 한다고 생각했는데, |
| 58 | + |
| 59 | +책에서는 오히려 질문을 던지고, 팀이 문제를 함께 소화하고 아이디어가 자연스럽게 흘러가게 만드는 사람이 진짜 리더라고 말한다. |
| 60 | + |
| 61 | +생각해보면 내가 가장 신뢰했던 리더들도 항상 정답을 말하기 보다는 좋은 질문을 던지고, 그 흐름안에서 팀 전체가 스스로 해결하게끔 했던 사람들이었다. |
| 62 | + |
| 63 | +### 품질 유지 |
| 64 | + |
| 65 | +--- |
| 66 | + |
| 67 | +세 번째는 <BlueText>품질 유지</BlueText>이다. |
| 68 | + |
| 69 | +이건 단순히 결과물을 깔끔하게 만드는 걸 의미하지 않는다. |
| 70 | + |
| 71 | +문제 해결 과정 전체가 처음 정의했던 문제와 어긋나지 않도록 방향을 지켜내는 일이다. |
| 72 | + |
| 73 | +리더가 일일이 감시자가 되는 것이 아니라, 팀 전체가 품질 기준을 공유하고 지켜낼 수 있는 구조를 설계하는 것이다. |
| 74 | + |
| 75 | +책을 읽고 나서 `품질` 이라는 단어가 단순히 QA 나 코드리뷰의 영역이 아니라 <BlueText>리더십의 영역</BlueText> 이라는 걸 새삼 깨달았다. |
| 76 | + |
| 77 | +--- |
| 78 | + |
| 79 | +이 책에서 가장 크게 느낀 건, <BlueText>리더는 문제를 해결하는 사람이 아니라 문제 해결의 장을 설계하는 사람</BlueText>이라는 점이다. |
| 80 | + |
| 81 | +그리고 이 지점에서 <BlueText>리더와 관리자</BlueText> 의 차이가 아주 뚜렷하게 드러난다. |
| 82 | + |
| 83 | + |
| 84 | +관리자는 일정과 리소스를 관리하고, 정해진 틀 안에서 효율을 높이는 사람인 반면, |
| 85 | + |
| 86 | +리더는 그 틀을 다시 설계한다. |
| 87 | + |
| 88 | +관리자는 계획을 지키는 데 집중하지만, |
| 89 | + |
| 90 | +리더는 그 계획이 왜 존재해야 하는지부터 묻는다. |
| 91 | + |
| 92 | +관리자는 통제의 언어를 쓰지만, |
| 93 | + |
| 94 | +리더는 신뢰의 언어를 쓴다. |
| 95 | + |
| 96 | +이 부분은 책을 읽으면서 정말 많이 공감이 갔던 부분이다. |
| 97 | + |
| 98 | +특히, 기술 조직에서는 `관리`만으로는 절대 팀이 잘 굴러가지 않는다. 문제 해결형 리더십이 필요하다. |
| 99 | + |
| 100 | + |
| 101 | +이 책은 내 사고 방식을 완전히 흔들어놓았는데, |
| 102 | + |
| 103 | +그동안 리더십은 <b>내가 잘 해결하는 것</b>으로 만 생각했는데, 책을 읽고 나서는 <BlueText>함께 해결하는 구조를 만드는 것</BlueText> 이라는 것을 깨달았다. |
| 104 | + |
| 105 | +문제를 정확히 정의하고, 흐름을 만들고, 품질을 지키는 사람이 진짜 리더인 것이다. |
| 106 | + |
| 107 | +앞으로 리더가 될 사람이라면, 문제를 직접 푸는 사람보다 <BlueText>문제를 풀릴 수 있도록 판을 만드는 사람</BlueText> 이 되어야 한다. |
| 108 | + |
| 109 | +그게 바로 이 책이 전달하는 메시지라고 생각된다. |
| 110 | + |
| 111 | + |
| 112 | +:::quote |
| 113 | +리더는 문제를 직접 해결하는 사람이 아니라, 문제 해결의 장을 설계하는 사람이다. |
| 114 | +문제를 정확히 정의하는 것만으로도 절반은 해결된 것이다. |
| 115 | +리더십은 정답을 주는 것이 아니라, 정답이 나올 수 있는 구조를 만드는 것이다. |
| 116 | +::: |
| 117 | + |
| 118 | + |
| 119 | + |
| 120 | +:::success |
| 121 | +<b>이런 분들에게 이 책을 추천합니다!</b> |
| 122 | +✔ 기술적인 문제 해결과 리더십의 접점에서 고민 중인 시니어/리드 개발자. |
| 123 | +✔ 관리자가 아닌 리더로 성장하고 싶은 사람 |
| 124 | +✔ 팀의 문제 해결력을 키우고 싶지만 방법을 잘 모르겠는 사람 |
| 125 | +::: |
| 126 | + |
| 127 | + |
0 commit comments