처음 입사했을때는 연차 높은 FE 동료들과 FE 팀장이 있었고, 그들에게 많은 것를 배웠다. 팀 규모가 작아지게 되면서 심지어 FE 팀을 혼자 맡게 되기까지 했다. 직접 면접을 보고 후임을 뽑는 경험, 뽑은 동료의 멘토링을 맡게 되고, FE 기술적인 결정을 리드하게 되면서 확실히 이전과는 다른 경험을 하고있고, 더 잘하고 싶었다.
많은 매니징 책 중에서도 이 책을 고른 이유는, 멘토 → 테크리드 → 사람 관리 → 팀 관리로 이어지는 매니징 트랙 전체를 한 권에 담고 있기 때문이다. (6장 부터는 더 큰 팀에 대한 내용이라 조금 더 내공을 쌓고 읽어도 될것같다.) 내가 지금 어디쯤 서 있고, 다음 갈림길이 무엇일지 지도처럼 볼 수 있을 것 같았다.
기술 트랙과 매니지먼트 트랙 중 어느 쪽으로 갈지는 선택을 해야하는지에 대해서도 궁금했는데, 이 책은 그 결정을 서두르지 않아도 된다고 말해주기도 했다. (선택을 했다가도 다른 트랙으로 돌아올 수 있다고도 했다.)
책을 읽으면서 각 장마다 책의 요지, 내 경험에 비춰본 생각, 지금 팀에 적용한(할) 것을 적어보았다.
1장. IT 관리 101
관리하는 방법은 '관리되는' 경험에서 배운다. 팀원으로서 내가 매니저를 어떻게 활용하고 도와야 하는지부터 고민해봐야 한다.
- 원온원은 팀원도 안건을 준비해 와야 한다.
- 칭찬은 공개적으로, 교정 피드백은 개인적으로. 평가 시즌에 몰아서 주는 게 아니라 자주, 작게, 제때.
내 경험
내게 좋은 매니저는 과도한 관심도, 무관심도 아닌 매니저였다. 원온원은 한 달에 한 번 1시간, 편한 카페에서 했다. 지금 생각해보면 신뢰를 주는 매니저가 좋았다. 솔직하게 내 생각을 말해도 평가에 나쁜 영향이 없고, 오히려 개발 문화나 시스템이 나아지는 경험을 몇 번 하고 나면 거창한 말보다 큰 신뢰가 생겼다. 나도 그런 "신뢰를 주는" 매니저(또는 동료)가 되고 싶다.
내 상황에 적용
팀원이 매니저를 돕는 방법을 읽으면서, 팀장에게 가장 도움이 되는 방식이 뭘지 고민했다. 팀장이 모든 도메인을 직접 알 수는 없다. 그래서 내 도메인의 리스크나 중요한 사안은 초기에 알리고, 판단 근거를 함께 공유한다. 팀장이 의사결정할 재료를 내가 먼저 준비해 가는 것이다.
2장. 멘토링
좋은 멘토가 되기 위해서는 경청하는 자세가 중요하다.
- 신규 입사자는 기존 온보딩 문서의 빈틈이나 낡은 부분을 알아채기 쉽다. 온보딩 과정에서 직접 고치게 하는 것도 좋은 방법이다.
- 팀 안팎의 사람들과 관계를 만들 수 있게 연결해 주는 것도 멘토의 역할이다.
- 멘토링은 부가 활동이 아니라 실제 업무다. 멘토링에 할애할 시간을 확보해 주고, 성과로 인정해야 한다.
내 경험
후임과 논의를 할 때 내 발화량이 더 많다는 걸 알고 있다. 책에서도 좋은 멘토의 조건으로 경청을 꼽는다. 이걸 경계하려고 후임의 동의하에 세션을 STT로 변환해 AI에게 객관적인 시각의 피드백을 받고 있다. 피드백을 투명하게 공개해서 "경청하는 자세"를 개선하고 있다.
내 상황에 적용
후임이 입사했을 때 한 달 동안 페어 프로그래밍과 코드 리뷰로 코드베이스와 팀 방식을 충분히 익히게 한 뒤, 그 내용을 기반으로 FE 팀 가이드 업데이트와 README 작성을 과제로 줬다. 특히 모노레포 구조처럼 문서 없이 기존 인원 머릿속에만 있던 내용은 내가 설명하고 후임이 직접 분석하면서 문서화했다. 내가 이미 익숙해서 놓치던 부분을 새 사람의 관점에서 채울 수 있었다.
이 문서는 지금 다른 직무 개발자들이 AI로 FE 레포를 분석할 때 기반 자료로 쓰이고 있다. 온보딩 산출물이 팀 전체의 자산이 된 셈이다.
3장. 테크리드
사람 관리는 하지 않지만 기술적인 방향과 실행에 책임을 지는 리더. 나 없이도 굴러가게 만드는 것이 목표다.
좋은 테크리드가 하는 일:
- 아키텍처 이해 — 전체 구조를 파악하고 있어야 한다.
- 팀 플레이어 — 어렵고 재미없는 일을 도맡아서도, 좋은 일만 독점해서도 안 된다.
- 기술적 의사결정 주도 — 팀원 의견을 모으고 최종 판단을 한다.
- 커뮤니케이션 — 팀 바깥과 팀 사이의 통역자. 글로 잘 쓰고, 잘 읽고, 잘 듣는 능력이 중요하다.
프로젝트 관리에서는 큰 작업을 어떻게 쪼갤지가 중요하다. 불확실하고 모르는 부분은 초반에 최대한 드러내야 한다. 마무리(문서화, 정리, 회고)까지 테크리드의 책임이다. 테크리드를 경험한 뒤에 기술 트랙(시니어, 스태프 엔지니어)으로 갈지, 매니지먼트 트랙으로 갈지 결정하면 된다.
내 경험
테크리드의 정의와 하는 일을 보고 문득 생각이 들었다. 나도 프론트엔드 도메인에서는 테크리드 역할을 하고 있는 듯하다. 후임 멘토링까지 맡고 있으니 규모는 작지만 테크리드 + 매니징을 함께 경험해 본 셈이다. 담당 인원이 많아지면 또 다르겠지만, 내 연차에 작은 생태계에서나마 이걸 경험해 본 게 앞으로의 성장에 좋은 영향을 줄 것 같다.
내 상황에 적용
나는 역할을 FE 밖으로 확장하려고 한다. 책에서 테크리드의 조건으로 아키텍처 이해를 꼽는데, 나는 FE는 깊지만 BE 아키텍처와 핵심 도메인 이해가 가장 약하다. 그래서 AI를 활용한 BE 학습 계획을 세워 진행 중이고, 팀 안에서 도움받을 경로도 정해뒀다.
4장. 사람 관리
사람 관리는 관계에서 시작한다. 상대를 개인으로 인식하고 신뢰를 쌓고, 작업을 적절히 위임할 줄 알며, 피드백과 평가를 적시에 해야 한다.
- 불편한 대화를 피할수록 상황은 더 나빠진다.
- 마이크로 매니지먼트는 위험하다. 위임은 선택이 아닌 필수다. 위임 정도는 사람과 상황에 따라 달라지므로 잘 판단해야 한다.
- 매니저가 쉽게 접근할 수 있는 정보를 팀원에게 요청하는 식의 보고에 팀원이 쓰는 시간은 줄여야 한다. 지표와 시스템 모니터링으로 팀원을 쪼지 않고도 상황을 알 수 있게 한다.
- 성과 평가에서 처음 듣는 충격적인 얘기로 팀원을 놀라게 하면 안 된다. 평소 피드백이 실패했다는 증거다.
내 경험
적절한 "위임"이 서로에 대한 "신뢰"가 되는 과정을 직접 겪었다. 처음에는 당연히 신뢰가 쌓이기 전이라 매니저가 대신 결정을 해줬다. 내가 판단 근거를 보여주고 잘 실행하는 경험이 쌓이면서 작업 방식, 구현 방법, 기술 선정까지 위임받게 됐고, 그럴수록 서로에 대한 신뢰는 커져갔다.
내 상황에 적용
팀장이 묻기 전에 필요한 정보를 먼저 공유하고, 팀장뿐 아니라 팀원 누구나 직접 찾아볼 수 있도록 프로젝트와 기능 단위로 문서를 작성해 둔다. FE 프로젝트 하네스에 docs 항목을 추가해 둔 것이 그 예다. 정보를 얻기 위해 팀원에게 묻는 비용을 줄이려는 노력이다.
그리고 주니어에게도 내가 받았던 위임 과정을 경험하게 하고 있다. 작은 범위부터 결정을 맡기고, 스스로 판단할 때까지 기다린 뒤 그 결과를 보고 조언한다.
5장. 팀 관리
팀 관리는 개인 관리의 합이 아니라 시스템을 돌보는 일이다. 기술 감각을 유지하면서 문제를 빨리 진단하고, 결정과 갈등을 피하지 않고 적시에 해결하는 것이 좋은 리더다.
- 기술 감각을 유지하려면 급하지 않은 작업, 버그 수정, 코드 리뷰처럼 병목이 되지 않는 작업을 맡는다.
- 팀의 문제를 진단해서 유형별로 대응한다.
- 시기적절한 의사결정을 위해 데이터로 판단하고, 결정의 목표와 기준을 먼저 정리한다.
- 반복되는 갈등은 구조의 문제인 경우가 많다. 규칙으로 원인을 줄인다.
- 위쪽이나 바깥에서 오는 압박과 소음을 걸러준다. 다만 판단하에 필요한 건 적절히 공유한다.
내 경험
이전에 경험한 매니저는 바깥에서 오는 압박을 대부분 걸러주고, 큰 틀만 정해 공유한 뒤 기술 스택 같은 결정은 우리에게 맡겼다. 덕분에 외부 압박 없이 스스로 판단하는 연습을 할 수 있었다. 돌아보면 보호와 위임을 따로 조절한 것이었고, 책에서 말하는 소음은 걸러주되 필요한 건 공유하는 역할이 이런 모습이었다.
내 상황에 적용
지금은 후임에게 같은 역할을 하고 있다. 사업팀과 의사결정이 필요한 회의는 내가 맡고, 주 1회 FE 회의에서 결과와 그렇게 판단한 이유를 함께 공유한다.
책에서는 팀장이 기술 감각을 유지해야 결정을 제대로 내릴 수 있다고 하지만, 팀장 한 사람이 모든 도메인의 감각을 직접 유지하기는 어렵다. 그래서 FE 도메인 판단은 내가 미리 정리해 공유한다. 결론뿐 아니라 선택지와 판단 기준을 함께 가져가서, 책에서 말하는 "결정의 목표와 기준을 정리하는 일"을 팀장이 결정하기 전에 준비해 두려고 한다.