목차18개 항목
출처와 참고
「개발자에서 개발팀장이 되기까지 겪은 5가지 실수」(Patrick Kua의 「Techie to Tech Lead」 번역), 「초보 개발 팀장의 1년 회고 - 좋은 팀장이 되기 위한 노력들」(2020.04)을 바탕으로 재구성한 노트다. 매니저 자리에서 달라지는 것은 Sofia의 「The Truth About Being a Manager」(2026.06)로, 동기·업무량·평가·보상은 아웃스탠딩의 조직 기고(「문제는 동기 부여가 아니라 사라지는 동기입니다」, 「대체 불가능한 직원이 회사를 떠나게 되는 이유」, 「평균의 배신」 등, 2026)로 보강했다.
역할이 바뀌면 성공 기준이 바뀐다
개발자의 성과는 내가 만든 것으로 잰다. 리더의 성과는 팀이 만든 가치로 잰다. 리더가 된 뒤에도 개인 산출물로 자신을 평가하면, 직접 코딩을 놓지 못하고 팀의 병목이 된다.
| 구분 | 개발자 | 테크 리드·팀장 |
|---|---|---|
| 성과 | 내가 짠 코드, 해결한 이슈 | 팀 전체의 산출과 성장 |
| 주로 보는 신호 | 빌드 성공, 테스트, 배포 | 이해도, 동의와 저항, 업무 부담, 소통 구조 |
| 핵심 역량 | 기술 깊이 | 영향력, 설득, 코칭, 이해관계자 관리, 전략적 사고 |
| 시간 쓰는 곳 | 구현 | 장애물 제거, 의사결정, 사람 |
기술은 리더십의 뿌리이지만 리더십 자체는 아니다. 기술 역량과 리더 역량은 따로 길러야 한다.
새 리더가 흔히 하는 다섯 가지 실수
| 실수 | 결과 | 바꿀 것 |
|---|---|---|
| 1. 기술 실력이 리더 자격이라고 믿는다 | 팀원을 경쟁자로 보고 불신과 우유부단이 생긴다 | 팀원을 협력자이자 잠재적 후계자로 본다 |
| 2. 기술만 계속 깊게 판다 | 설득·코칭 같은 넓은 역량이 자라지 않는다 | 익숙하지 않은 역량을 의식적으로 연습한다 |
| 3. 여전히 생산자로 일한다 | 과로하고, 리더가 팀의 병목이 된다 | 팀원이 집중하도록 방해 요소를 치운다 |
| 4. 모든 것을 알고 통제하려 한다 | 결정이 몰리고 틀린 정보를 퍼뜨린다 | 위임하고, 모르면 모른다고 말한다. 멘토링·팀 코드 리뷰 같은 구조로 푼다 |
| 5. 역할이 바뀐 신호를 못 읽는다 | 사람 문제를 늦게 알아챈다 | 기술 지표 대신 사람의 신호를 본다. 원인 해석은 신중하게 한다 |
팀을 키우는 실천
1:1 면담을 고정 일정으로
- 주 또는 월 단위로 30~60분을 달력에 고정한다. 바쁠 때 가장 먼저 밀리기 때문이다.
- 감정 상태, 고민, 커리어 방향, 강점을 듣는다. 업무 진행 점검은 다른 자리에서 한다.
- 기록을 남기고 질문을 템플릿으로 만든다. 쌓인 기록으로 사람마다 고민이 어떻게 바뀌는지 볼 수 있다.
사람에 맞춰 일을 나눈다
- 팀원이 집중하고 싶은 영역과 강점을 업무 배정에 최대한 반영한다.
- 빨리 크는 사람에게는 도전 과제를, 천천히 크는 사람에게는 작은 성공을 주는 과제를 준다.
- 정답을 바로 주지 않고 스스로 생각할 질문을 던져 문제 해결력을 키운다.
심리적 안전감과 피드백
- 질문과 반론이 부끄러운 일이 아니라는 신호를 꾸준히 보낸다. 정기 회고로 자유로운 피드백 통로를 연다.
- 피드백은 사실에 근거하고 대안을 함께 준다. 듣기 좋은 말만 하는 것은 성장을 막는다.
- 판단 기준과 말을 일관되게 유지한다. 방향이 자주 바뀌면 신뢰가 깎인다. 비교나 도덕적 평가가 담긴 말은 피한다.
목표·규칙·문서
- 분기·연 단위 목표와 진행을 잴 지표를 정하고 주기적으로 본다.
- 회의 방식, 코드 리뷰 가이드, 공용 도구를 문서로 남겨 새 팀원이 빨리 적응하게 한다.
- 성과는 가능한 한 수치로 남기고, 수치화가 어려운 기여는 조직에 준 영향을 설명하는 자료로 보완한다.
리더 자신부터 점검한다
자신의 스트레스 요인, 능률이 높은 시간, 원하는 커리어를 알아야 팀원의 이야기를 여유 있게 들을 수 있다.
매니저 자리에서 달라지는 것
엔지니어링 매니저는 권한과 책임을 함께 진다. 그래서 같은 사람이라도 팀과의 관계, 말의 무게, 일하는 시간의 단위가 바뀐다.
| 달라지는 것 | 무슨 일이 생기나 | 대응 |
|---|---|---|
| 팀과의 거리 | 연봉 협상·어려운 결정 뒤로 팀원 사이의 대화에서 빠지게 된다 | 자연스러운 변화로 받아들인다. 속을 털어놓을 동료 매니저를 최소 한 명 둔다 |
| 말의 무게 | 가벼운 한마디가 지시로 들려 혼란과 걱정을 만든다 | 말을 줄이고, 의견인지 결정인지 밝히고, 다른 사람이 먼저 말하게 한다 |
| 공유할 수 없는 정보 | 조직 개편, 성과 문제, 예산 삭감, 개인 사정을 알고도 말할 수 없다 | 질문에 신중하게 답하고 감정을 드러내지 않는다 |
| 동의하지 않는 결정 | 위에서 내린 결정을 팀에 설명하고 설득해야 한다 | 팀 앞에서 불만을 털어놓지 않는다. 반대는 위로 전한다 |
| 보이지 않는 진척 | 하루가 끝나도 손에 잡히는 산출물이 없고, 일이 몇 주 단위로 굴러간다 | 분명한 목표를 세워 추적하고 작은 성과도 짚는다. 회의만으로 하루를 채우지 않는다 |
| 업무 바깥의 압박 | 어려운 대화와 사내 정치, 팀원의 개인 위기가 퇴근 뒤에도 머리에 남는다 | 스트레스와 되새김을 빨리 끊는 자기 관리 방법을 만든다 |
| 무력감 | 내 의견 없이 결정이 나고 예산이 깎인다. 책임보다 통제권이 작다 | 감정을 조절해 팀에게 흔들리지 않는 존재가 된다 |
매니저가 새로 익혀야 하는 일
- 피드백을 미루지 않는다. 분명한 피드백을 피하면 문제 행동이 이어지고 팀 전체가 그걸 본다. 반대로 팀원·동료에게 솔직한 피드백을 청하고, 실수를 인정하고, 내 상사에게도 피드백한다. 매니저의 태도가 팀 문화의 기준이 된다.
- 호감보다 존중을 택한다. 인기 없는 결정, 어려운 대화, 때로는 내보내는 일까지 해야 한다. 모두에게 사랑받으려 하면 신뢰와 존중을 둘 다 잃는다.
- 방 안의 어른이 된다. 압박 속에서도 침착하게 갈등을 풀고 미성숙한 행동을 가라앉힌다. 팀은 매니저의 행동을 따라 한다.
- 비즈니스와 옆 조직을 안다. 제품·디자인·데이터·영업·마케팅·고객 지원과 관계를 쌓고, 회사의 핵심 지표와 전략을 이해해야 팀의 맥락과 의존성을 챙길 수 있다.
- 팀을 대변한다. 좋은 일도 누군가 알리지 않으면 인정받지 못한다. 팀의 성과를 다른 조직에 알리고, 팀원의 보상·승진을 위해 싸운다.
- 위로 관리한다(managing up). 상사의 우선순위를 알고, 나쁜 소식은 분명하게 전하고, 상사를 막는 문제를 풀어 준다. 상사의 성공은 나중에 팀을 도울 신뢰 자본이 된다.
- 전체 그림을 지킨다. 여러 매니저·부서와 이야기하면 팀 사이의 의존성과 오해를 위기 전에 발견할 수 있다. 이 시야는 매니저만 줄 수 있는 기여다.
- 스스로 배운다. 매니저 교육을 제대로 하는 회사는 드물다. 학습 목표를 정해 공부하고, 휴가·휴직 규정과 노동 법규의 기본을 익히고, 인사 담당자와 관계를 만들고, 멘토를 찾는다.
엔지니어링을 그리워하는 것은 자연스럽다. 대신 코칭한 사람이 자라고 팀이 성과를 내는 것을 보는 데서 오는 보람이 있다.
동기·업무량·평가·보상
동기를 만들기보다 사라지는 곳을 찾는다
새로 들어온 사람은 대체로 배우고 기여하려는 동기를 이미 갖고 온다. 1년쯤 지나 질문이 줄고 시키는 일만 한다면, 사람이 변했다기보다 조직이 실제로 어떻게 움직이는지 알게 된 결과일 수 있다. 리더가 물을 것은 「어떻게 동기를 부여할까」가 아니라 「있던 동기가 어디서 꺾였나」다(묵살된 제안, 바뀌지 않는 절차, 보이지 않는 기여 등).
역할 누적: 일이 교체되지 않고 쌓인다
일 잘하는 사람에게 프로젝트, 고객, 문제 수습이 몰린다. 새 일이 붙어도 기존 일은 줄지 않아 업무가 교체가 아니라 추가로 쌓인다. 처음에는 신뢰의 신호로 받아들이지만 결국 과부하와 이탈로 끝난다. 새 역할을 맡길 때는 무엇을 내려놓을지 함께 정한다.
「문제만 말고 해결책도 가져오라」의 함정
작은 문제를 거르는 데는 좋은 원칙이다. 그러나 팀장 권한을 넘는 사안(검증이 부족한 채 출시할지)에도 똑같이 적용하면 문제가 왜곡된다. 해결책을 요구받은 사람은 자기 권한 안의 선택지(우선순위, 인력, 일정 조정)만 내놓고, 「이 위험을 감수할 것인가」라는 판단 문제가 「일정에 어떻게 맞출까」라는 실행 문제로 줄어든다. 위험 감수처럼 상위 결정이 필요한 사안은 해결책 없이도 그대로 올릴 수 있어야 한다.
평가: 평균이 아니라 무엇을 해냈나
| 문제 | 내용 |
|---|---|
| 평균식 평가 | 평균에 가까운 평가·보상은 공정해 보여서가 아니라 분쟁과 설명 비용을 줄여 관리하기 편해서 택한다. 품질 편차를 줄이던 제조업 시대에는 맞았지만, AI를 쓰면 같은 시간에도 결과물 밀도 차이가 커져 고성과자의 동기를 꺾는다 |
| AI와 함께 낸 성과 | 산출물의 양으로는 개인 기여를 판단하기 어렵다. 어떤 문제를 정의했나, 무엇을 AI에 맡겼나, 결과를 어떻게 검증해 업무에 적용했나를 본다. 평가 항목에 「AI 활용도」를 더하는 것으로는 부족하다. AI를 얼마나 썼는지가 아니라 AI로 무엇을 해냈는지를 평가한다 |
보상: 크기보다 기준
| 함정 | 결과 |
|---|---|
| 지나치게 큰 보상 | 실패 공포와 압박이 커져 일의 본질에 집중하지 못하고(댄 애리얼리), 목표 밖의 가치를 무시한 채 수단을 가리지 않게 되며, 내적 동기가 밀려난다(에드워드 데시) |
| 소수에게 몰린 보상 | 협업이 줄고 정보 독점과 성과 가로채기가 는다 |
| 대표 사비로 일부에게만 주는 보상 | 법인과 개인이 섞여 거버넌스가 무너지고, 형평성과 절차적 정당성이 깨지며, 대표 개인에 대한 충성을 요구하는 문화로 흐른다. 받는 쪽에서는 기분에 따라 번복될 수 있는 보상이다 |
보상은 대상, 형평성, 기대 효과, 회사 유보금을 따진 공식 체계와 기준으로 준다. 모두가 같은 기준으로 받는 주거 지원 같은 제도는 이와 다르다. 전사 지표 달성률에 연동해 모두에게 같은 비율의 성과급을 주고 예상 지급률을 실시간으로 공개하는 방식도 기준을 드러내는 설계의 예다.
리더십은 직함이 아니다
- 리더십은 직선으로 자라지 않는다. 리더를 하다 다시 개발자로 돌아가는 것도 경력의 한 경로다.
- 직함 없이도 리더십은 발휘된다. 팀은 리더 역할이 없는 사람에게도 안전하게 연습할 기회(회의 진행, 기술 결정 주도, 온보딩 맡기)를 준다.
정리
- 리더의 성과는 팀이 만든 가치다. 내 코드가 아니다.
- 직접 생산과 통제를 줄이고, 위임과 장애물 제거에 시간을 쓴다.
- 1:1 면담, 사람에 맞춘 업무 배정, 근거 있는 피드백, 문서화된 규칙이 팀을 키운다.
- 기술 지표가 아니라 사람의 신호를 읽는 감각을 기른다.
- 매니저는 말의 무게, 공유할 수 없는 정보, 보이지 않는 진척을 안고 일한다. 의견과 결정을 구분하고, 피드백을 미루지 않고, 팀을 대변하고 위로 관리한다.
- 꺾인 동기를 찾고, 새 역할을 줄 때 내려놓을 일을 정하고, 상위 판단이 필요한 위험은 해결책 없이도 올리게 한다. 평가는 AI로 무엇을 해냈는지, 보상은 공식 기준으로 한다.
관련 노트: 친절한 엔지니어링, 회사에서 빠르게 성장하는 법, 회의 잘하는 법, 협업을 잘하는 개발자, 엔지니어 레벨
원본 기록10
- 원문 (새 창) muchtrans.com/translations/techie-tech-lead-my-5-biggest-mistakes.ko.html
- 원문 (새 창) zzsza.github.io/diary/2020/04/26/novice-leader-retrospect
- 원문 (새 창) sofiakodar.github.io/posts/becomingmanager/
- 원문 (새 창) outstanding.kr/motivation20260713
- 원문 (새 창) outstanding.kr/roleaccumulation20260909
- 원문 (새 창) outstanding.kr/issuesshrink20261008
- 원문 (새 창) outstanding.kr/average20260304
- 원문 (새 창) outstanding.kr/performancereviews20261106
- 원문 (새 창) outstanding.kr/reward20260608
- 원문 (새 창) outstanding.kr/dontplz20260406