테크리드 1년 회고
처음 테크리드가 된 뒤 겪은 고민과 경험을 나누려 합니다.
어느 날 테크리드가 되었습니다
테크리드 제안을 받았을 때 당황했습니다. 개발 경력 4년, 아직 부족한 점이 많다고 느꼈기 때문입니다. 굳이 장점을 꼽자면 다른 팀이나 다른 역할의 동료와 소통하는 데 어려움이 없었다는 점입니다. 팀 전체의 생산성을 높이고 성과를 끌어올리려 꾸준히 노력해왔습니다.
그날 매니저를 찾아가 물었습니다.
나: 제가 테크리드를 맡을 자격이 있는지 모르겠습니다. 저보다 더 적합한 분이 맡는 게 좋지 않을까요?
매니저: 이미 그 역할을 하고 계세요. 너무 어렵게 생각하지 마세요. 다른 웹 엔지니어분들의 레퍼런스가 되어주시면 됩니다.
부담이 커졌지만, 주어진 기회를 잘 살리고 싶었습니다. 테크리드가 어떤 책임을 져야 하는지 공부하기 시작했습니다.
테크리드란 어떤 책임을 갖는가?
테크리드를 맡기 몇 달 전, 동료에게 선물받은 개발 7년차, 매니저 1일차가 떠올랐습니다. (그는 닥칠 미래를 알았던 걸까요, 아니면 우연이었을까요?)
선물받을 당시에는 매니저가 되려면 멀었다고 생각해 대충 넘겼던 책입니다. 이번에 다시 펼쳐보았습니다.
대개 테크리드는 가장 복잡한 기술을 다루고 최고의 코드를 작성하는 개발자에게 맡겨야 한다고 생각한다.
(...)
이는 경험 많은 매니저조차 흔히 빠지는 일반적인 오해다. 테크리드의 역할을 팀에서 가장 경험이 많거나 실력 있는 개발자로 연결지어 생각하는 것은 잘못된 생각이다.
(...)
테크리드는 팀 전체의 성장을 위해 기술 프로젝트 리더로 활동하면서, 대규모 프로젝트에서 자신의 전문성을 살려 팀에 기여한다. - 개발 7년차, 매니저 1일차
테크리드는 개발 업무의 계획을 세우고, 구성원이 프로젝트를 효율적으로 마무리하도록 돕는 역할입니다.
무엇을 해야 하는가?
팀이 어디로 가는지 모르면 길을 잃거나 중요하지 않은 일에 매달릴 수 있습니다. 같은 목표를 보지 않으면 의견이 갈릴 때 답을 찾기 어렵습니다.
로드맵을 만들었습니다. 다음에 할 일이 무엇인지, 지금까지 어떤 성과를 냈는지, 우선순위는 어떤지 주기적으로 확인할 수 있게 되었습니다. 업무 공유와 우선순위 결정에 드는 시간이 줄었습니다.
그러나 기술 로드맵을 세우기란 쉽지 않았습니다. 기술을 우선하면 비즈니스 요구를 놓치고, 비즈니스만 쫓으면 기술 부채가 쌓입니다. 단기 성과와 장기적인 개발 속도 사이에서 균형을 잡는 일은 의식적으로 시간을 들여 관리해야 한다는 점을 배웠습니다.
1년이 지난 지금, 이대로 괜찮은가?
문제가 생기면 직접 해결하려 했습니다. 꽤 오랫동안 그랬습니다. 이 방법이 빠르고 쉽다고 생각했기 때문입니다. 구성원들을 더 배려하는 것이라고도 여겼습니다.
그러나 시간이 지나며 문제가 드러났습니다.
- 제 일정에 따라 해결이 지연되었고
- 번아웃에 가까운 상태가 되었으며
- 무엇보다 팀원들이 제 결과물을 이해하기 어려워했습니다
당장의 문제는 사라졌지만, 팀의 문제 해결 역량은 크게 자라지 않았습니다.
위임의 중요성
누군가 만든 길만 걷고 싶은 사람은 드뭅니다. 직접 만들거나 함께 만든 길을 가고 싶은 게 자연스럽습니다. 팀의 기술적 방향성을 정할 때도 마찬가지입니다.
함께 방향성을 논의하고 작은 단위로 나누어 위임했어야 한다는 점을 깨달았습니다. 그러지 않으면 구성원들의 참여를 이끌어내기 어려울 뿐 아니라 문제 해결 경험을 쌓을 기회도 줄어듭니다.
심리적 안정감을 주는 팀
심리적 안정감이란 실패와 도전을 숨기지 않고 말할 수 있는 상태입니다.
성공 경험은 쉽게 공유되지만, 실패 경험은 그렇지 않습니다. 부족함을 드러내는 일처럼 느껴지기 때문입니다.
그러나 실패 경험을 나누지 않으면 팀은 성장하기 어렵습니다. 같은 실패를 다른 누군가 겪을 수 있고, 그 경험을 발판 삼아 성장할 기회를 놓칩니다.
실패를 드러내는 행동이 능력 부족이 아니라 신뢰의 표현이 되도록 분위기를 만들어야 했습니다.
말뿐인 리더십은 잔소리일 뿐
“실패를 공유하자”고 말하는 것만으로는 부족했습니다.
운동을 전혀 하지 않는 사람이
“운동 열심히 해야 한다”고 말한다면
그 말은 잔소리로 들릴 수밖에 없습니다.
그래서 먼저 제 실패를 공유했습니다.
- 제가 놓친 판단
- 그로 인해 발생한 장애
- 재발 방지를 위해 무엇을 바꿨는지
부끄러웠습니다.
하지만 그 경험을 나누며 팀과 함께 성장하고 싶다는 의지를 보였을 때,
팀은 비난 대신 지지와 격려로 반응했습니다.
그 순간 깨달았습니다.
앞서 행동하는 리더십이 말보다 훨씬 강력하다는 것을.
요약
테크리드로 1년을 보내며 가장 크게 깨달은 점은, 팀의 레퍼런스가 될 결과를 꾸준히 만들어내는 일과 팀의 성장을 위해 계속 배우는 자세가 필수라는 것입니다.
단기적인 문제 해결보다, 팀원들과 충분히 소통하고 기술적 방향성을 함께 고민하며 더 잘 위임하는 데 집중하려 합니다.
리더십은 말로 설명하는 역할이 아니라 먼저 행동으로 보여주는 역할이라는 점도 배웠습니다. 실패를 공유하자고 말하기 전에 스스로 실패를 드러내고, 도전을 권하기 전에 먼저 시도하는 사람이 되어야 팀에 신뢰와 심리적 안정감을 줄 수 있었습니다.
예전에는 개인으로서 얼마나 기여했는지 고민했다면, 이제는 팀이 얼마나 성장했는지도 함께 봅니다. 쉽지 않은 역할이지만, 그만큼 보람과 배움이 큰 자리라고 느끼고 있습니다.
새 글 알림 받기
새로운 글이 발행되면 이메일로 알려드립니다.