오늘이 2024년 10월 5일이고 이 글을 처음 쓰기 시작한 게 2023년 8월 16일이니.. 글을 쓴 지 1년이 넘어버렸다. 관리자에 대한 내 생각이 정리가 되지 않아서 썼다 지웠다를 수도 없이 반복했다. 그 사이 아이도 출산하고 조직도 변경되고 많은 일이 있었다. 이 글을 더 이상 끌 수 없기에 아직도 정리되지 않은 부분은 모두 덜어내고 글을 마무리한다.
이 글은 개발자인 내가 왜 목적조직의 팀장을 하게 되었는지, 팀장은 어땠는지, 왜 그만두었지를 기록한 주관적인 경험기이다.
관리자가 되면 개발에서 멀어진다고 오래 전부터, 아마 처음 개발을 시작한 때부터 들어왔던 것 같다. 내가 목격한 몇몇의 개발자들도 관리자가 된 후 이전과는 다른 모습이 되었었다. 관리자가 되지 않고도 오래 개발을 하는 사람들도 많았다.
나도 "관리자 하지 말아야지" 라고 오래전부터 생각해 왔다.
2023년 초에 전임 팀장이 퇴사하면서 나에게 팀장 제의가 들어왔다. 무려 기획직군과 개발직군이 한 팀에 있는 목적조직 형태의 팀이다. 관리자는 절대 하지 않겠다고 생각해 왔지만, 꽤 오래 함께 일하면서 나를 잘 알고 있는 상위 조직장이 제의를 했기 때문에 진지하게 팀장에 대하여 다시 생각해 보게 되었다.
관리자가 되어야만 개발에서 멀어질까?
관리자가 되지 않더라도 시니어가 되면 어차피 개발에서 멀어질 것이라고 생각도 했었다. 위임을 해야 하기 때문이다.
나는 운이 좋았다. 저연차 때부터 대규모 시스템의 메인 개발자를 맡았고, 여러 개편 프로젝트를 리드하기도 했다. 나에게 이런 역할이 주어진 것도 운이 좋았다고 생각하지만 내가 진짜 운이 좋았다고 생각하는 점은 나에게 이런 역할과 책임을 위임해 준 시니어와 리더를 만났다는 것이다. 적절한 시기에 한 단계 더 나아갈 수 있는 범위나 깊이의 일이 나에게 주어졌다. 나에게 이런 위임이 없었다면 나는 지금보다 훨씬 역량이 작은 개발자가 되었을 것이라 확신한다.
내가 이런 위임을 통해 성장했기 때문에 더더욱 위임을 잘하는 것이 "좋은 시니어"의 필수 요건 중 하나라고 생각하게 되었다.
위임은 선택적인 게 아니라, 시니어의 성장을 위해서도 필수적인 것이라고 생각한다. 위임은 성장을 위한 선택과 집중이다. 조직마다 요구되는 전문가의 방향 혹은 본인이 추구하는 전문가의 방향은 다를 수 있지만 어떤 전문가이든 전문가가 되기 위해서 유한한 시간을 사용해야 하고, 그 시간을 투자할 과제가 필요하다.
위임 없이 각자도생 하는 주니어와 시니어 개발자는 "주니어의 성장"과 "시니어의 성장"에 모두 문제가 있다. 시니어는 주니어가 할 수 있는 일에도 시간을 투자해야 하며, 주니어는 도전할 일감이 줄어들게 될 수 있다.
시니어가 적절한 위임을 한다면 주니어는 주니어가 할 수 있는 도전을 더 많이 할 수 있으며, 시니어는 시니어가 할 수 있는 일에 시간을 더 투자할 수 있게 된다. 요약하자면 주니어가 할 수 있는 일은 주니어에게 위임함으로써 시니어가 할 수 있는 일에 더 집중하는 것이 시니어도 더 잘 성장할 수 있는 방법이란 것이다.
좋은 시니어가 되기 위해서는 위임을 잘해야 한다. 이 과정에서 시니어의 개발업무는 점점 줄어들 것이다. 결국 관리자가 되지 않더라도 경력이 쌓이게 되면 개발에서 멀어질 것이라고 생각했다. 그런데 이 생각은 내가 테크리드를 맡게 되면서 달라지게 되었다.
위임을 하면서도 시니어 개발자가 개발에서 멀어지지 않을 수 있었다.
테크리드, 개발 세계관 확장
동욱님의 추천으로 "자바 웹 프로그래밍 CAMP"라는 강의를 수강한 후 나의 개발에는 많은 변화가 있었다. 내가 하고 있는 개발이 "잘"하고 있는 개발인지를 되돌아보는 계기가 되었고, 그래서 무엇을 어떻게 해야 하는지에 관심을 갖다 보니 객체지향, 클린코드, TDD 등 패키지 세트들을 들여다보게 되었다. 그러면서 알게 된 것들을 전파하고 제안하며 규칙을 만드는 등의 많은 실천과 설득을 한 것 같다.
내가 주로 설득하고 제안한 것들은 그동안 가지고 있던 문제를 해결하거나, 새로운 문제를 해결하기 위한 것들이었다. 내가 직접 겪은 경험들을 발표하여 더 많은 의견을 듣고자 하기도 했다.
2017년 "스프링 부트를 대하는 자세"
2019년 "무엇을 테스트할 것인가, 어떻게 테스트할 것인가"
2019년 "멀티모듈"
2020년 "프론트서버의 사실과 오해"
2022년 "이벤트 기반 아키텍처"
2022년 "레거시 개편의 기술"
매해, 매번 새로운 문제들을 해결하기 위한 어떠한 의미 있는 학습과 실천, 설득을 해왔다.
이러한 노력 덕분인지 언젠가부터는 내게 무언가를 주도하거나 변화를 이끌어내는 역할이 주어졌다. 이 시기에 결제, 주문, 회원, 검색, 광고, 전시 등의 도메인을 돌아다녔고 정말 많은 사람들을 만났다. 다른 개발자나 다른 구성원을 설득하는 건 매번 힘들었는데 이럴 때면 나에게 감투가 있으면 좋겠다고 생각을 했다. 몇 년간 몇 개의 개편을 주도했다. 이 과정에서 많은 사람들을 만났다. 나보다 경력이 더 많은 개발자, 정말 똑똑한 개발자, 나랑 아주 잘 맞는 개발자, 나와 아주 반대인 개발자 등 많은 개발자들을 만나 그들을 설득하고 설득당하기도 하면서 나의 여러 가지 요소들이 성장할 수 있었던 것 같다. 시간이 지나면서 점점 더 내 말에 힘이 실리고 내 의사결정을 존중해 주는 것을 체감하면서 설득이 점점 수월해짐을 느꼈다.
이후에 "존잡생각-자기계발편"을 보며 내가 얻은 것이 "전문적 권력"였으면 좋겠다고 생각했다. 감투도 안 주면서 힘든 일 시키는 조직장에게 서운하기도 했는데, 지금은 그때 감투를 주지 않은 것을 감사하게 생각하고 있다.
그리고 얼마 후 나는 공식적으로 테크리드라는 역할을 맡게 되었다. 테크리드 를 간단하게 설명하면 담당하는 조직의 기술적인 방향을 설정하는 역할을 하며 조직장과 협력하여 비지니스 목표를 달성할 수 있도록 하는 역할이다. 이 역할을 수행하면서 그동안 내가 개발이라고 생각해왔던 범위보다 개발을 더 넓게 생각하게 되었다.
테크리드를 맡으면서부터는 특정 과제를 맡지않고 팀 내 전체적인 과제를 관리하기로 하였다. 시니어의 위임 과정 처럼 자연스러운 일이었다. 내가 어느단계로 올라간만큼 팀원들에게 내가 하던 역할과 책임을 위임하는 것이다. 과제를 맡지 않으니 더 이상 코드를 직접 작성할 필요가 없었다. 이렇게 나는 되고 싶지 않던 개발과 멀어진 시니어, 관리자가 된 것일까?
주어진 미션을 성공적으로 완료하는 것이 그동안의 나의 개발이었다. 설계로 시작하여 코드로 완성이 되었으니 내가 생각하는 개발은 곧 코딩이었다. 그런데 이렇게 코딩에서 멀어지는 날이 오고야 말았다. 개발자로서 좌절감이 올 것이라 생각했었는데 이상하게 일하는 것은 여전히 재미있었다. 돌이켜보니 그동안 내가 개발이라 생각하면서 해왔던 것이 코딩만이 아니었음을 깨달았다.
개편을 진행하면서 항상 나를 어렵게 했던 것은 변경에 취약한 상태였다. 그냥 조심히 변경만 할 수도 있었겠지만 나는 이 문제 자체를 해결을 하고 싶었다. 그래서 "책임과 역할", "의존관계", "테스트"에 대한 규칙을 만들었다. 개편을 하러 계속 돌아다니다보니, 만들어진 규칙이 유지보수와 생산성에 도움이 되었는지를 피드백 받기 어려웠다. 나에게는 운영이 필요했다. 그래서 조직장에게 요청을 하였고, 어느 한 조직에 정착할 수 있었다.
정착하여 다시 "유지보수와 생산성"에 대한 규칙들을 만들어나갔다. 운영을 하게되니 규칙을 꾸준히 개선하고 발전시켜야한다는 것을 알게 되었다. 꾸준히 우리에게 맞는 규칙을 찾아나기 위해 토론, 스터디 문화를 만들어나갔고 만들어진 규칙이 잘 지켜질 수 있도록 코드리뷰, 페어프로그래밍, 브랜치전략 등의 팀 문화도 만들어나갔다.
다시 개편하는 시스템을 만들지 않기위해서 과제를 계획했다. 현재의 문제를 더 잘 해결해줄 수 있는 새로운 방법/기술을 고민하고, 각 시스템별 비지니스에 맞는 이상적인 아키텍처에 도달하기 위한 방향을 설계했다. 팀의 우선순위 높은 비지니스 과제에 밀려 계획만큼 진척되지 않을 때가 많았지만, 만들어둔 과제들이 구성원들의 성장 에 필요한 좋은 재료가 되었다.
코딩만이 개발의 전부는 아니었다. 규칙과 문화를 만들고, 시스템과 비즈니스의 방향성을 설계하는 것 또한 개발의 중요한 범위라는 것을 깨달았다. 단순히 코드를 작성하는 것을 넘어, 변화에 유연하게 대응할 수 있는 구조를 만들고, 팀의 성장과 조직의 생산성을 높이는 문화를 구축하는 것 역시 개발자로서의 중요한 역할이다.
테크리드가 된 후 나는 코딩을 거의 하지 않게 되었다. 대부분의 주요 프로젝트는 팀원들에게 맡겼다. 코딩을 하지 않았지만 괜찮았다. 여전히 나는 활발하게 개발을 하고 있다.
결국 나는 팀장 제의를 수락했다.
목적조직 팀장
결국 나는 팀장 제의를 수락했다. 단, 개발자로서의 커리어를 이어가고싶은 의사를 분명히 밝혔고 새로운 리더가 나타난다면 얼마든지 팀장을 내려놓겠다는 조건부 보험을 걸었다. 수락을 한 이유는 시니어가 되고 테크리드가 되어도 끝날 줄 알았던 내 개발이 끝나지 않았기때문이다. 어쩌면 팀장을 하면서도 나는 여전히 개발을 하고 있을 수 있다고 기대했다.
좋은 경험
팀장이 되고나서 과제들이 어떤 과정으로 만들어지는 것인지 알게 되었다. 그 과정에는 회사의 복잡한 이해관계와 규칙들이 있었다. 놀랐던 점은 팀장이 결정할 수 있는 것들도 많았다는 것이다. 생각보다 할려면 할 수 있는 일들이 많았다.
그래서 나는 이전부터 해결하고 싶었던 불편하고 개선해야한다고는 알고 있었으나 복잡하여 손대지 않았던 문제를 해결하고자 했다. 시스템의 구조와 비지니스 구조를 모두 알고 있다보니 이 문제가 복잡한 것에 비해 가성비있게 해결이 된다는 것을 금방 파악할 수 있었고 이것을 해결해야 우리가 최종적으로 가고자했던 방향에서 문제가 없을 것이라는 것도 알 수 있었다. 개발자 팀장의 장점이었던 것 같다.
이런 빌드업이 재미있었다. 최종적으로 해결하고자하는 목표까지 가기위해 해결해야할 일들이 잘 보였다. 가장 기억에 남는 빌드업은 계정연동 프로세스를 CI 기반으로 개선해나가면서 전화번호(본인인증) 기반 가입/로그인까지 완성시키는 그림이었다. 이메일이 같아야지만 로그인수단이 연동되었던 과거에서, 본인인증만으로도 로그인할 수 있는 현재까지를 위해 약 7개월 간 4-5개의 프로젝트를 진행하였다.
우아한 기술블로그 : 가입은 쉽게, 로그인은 실패없이! 휴대폰번호로 계속하기
목표를 직접 설정하고 지표를 만들어나가는 일은 의미가 있었다. 그동안 개발을 하면서는, 과제를 정상적으로 완수하는 것이 목표였을 뿐 과제로 달성하고자 하는 목표를 깊이 생각하지 않았었다. 측정의 중요함은 잘 알고 있었지만 개발적인 측정만 생각했었지 비지니스적인 측정에 대해서 고민해보지 않았던 것 같다. 내가 하는 개발, 일에 대한 의미를 다시한번 생각해보게도 되었다.
팀장의 무게
팀장이 되었다는 사실만으로 생기는 변화가 있을까? 얼마 전까지만 해도 같은 팀원이었음에도, 나의 태도에 아무 변화가 없음에도 생기는 변화가 있었다. 팀장이 짊어져야할 무게였다.
개발자가 개발만 잘하면 안된다고 생각한다. 방향성과 목적을 이해하고 일이 되게 하기위한 개발을 해야한다고 생각을 하기때문에 나는 어떠한 일을 할 때 제안을 많이하는 편이다. 내 제안은 논의로 이어져 PM 의 판단에 따라 결정이 되었었다.
모닥불 | EP.5 토스 개발자는 개발만 잘해도 될까? 가 공감되어 추천
팀장이 된 후 평소와 같았던 내 제안이 제안이 아닌 지시로 받아들여지는 일이 생겼다. 조직의 변화는 오직 팀원이었던 내가 팀장이 된 것 뿐이었기때문에 나는 이전과 같은 분위기에서 똑같이 일할 수 있을 줄 알았지만 오산이었다. 팀장이 되면서 달라진 역할과 권한은 내 동일한 태도에서도 다른 분위기를 줄 수 있음을 알게 되었다.
기억보단 기록을 | 미움 받을 용기 의 내용이 공감 되었다.
"그 전까지는 같은 팀원이였기에 속에 있는 이야기들도 쉽게 나누었다면, 이제는 평가자가 되었기에, 사측에 가까워졌기에 점점 예전과 같이 편하게 이야기를 하지 않는 것을 느끼게 된다."
목적조직 팀장의 범위
팀장직을 수락하기 전 팀장의 범위에 대해서 생각해보았었다.
우리팀은 개발자와 PM이 함께 있는 목적 조직이다. 그래서 개발자,PM 기준으로 생각을 시작했다. 팀장의 업무 영역이 다른 직군의 업무와는 겹치지 않을 것이라고 생각했 다. 팀장의 역할 중 일부를 TL, PL 에게 위임할 수도 있어보였다. 나는 그동안 TL 로서 팀장에게 개발자들의 관리 를 위임받아왔다. PL 이 있다면 PM 구성원의 관리를 위임할 수 있을 것이다.
나는 TL 역할을 함께 하는 팀장이 될 것이라고 생각했다. 전 팀장과 주변의 다른 팀장들 대부분이 PM 직군이었는데 대부분 PL 의 역할을 하고 있는 것 처럼 보였기 때문에 팀장이 개발 직군이라면 TL 역할을 함께하는 것이 자연스럽게 느껴졌다.
팀의 상황상 PL 역할을 수행해줄 수 있는 인원이 없었기때문에 PM 구성원들의 관리는 위임을 할 수 없는 것은 아쉬웠지만 내가 조금 더 신경을 쓰면 되지 않을까. 처음부터 팀장을 해본 사람이 어디있는가? 나의 경력, 누적된 경험들과 노력이 더해지면 충분히 해볼만하다고 생각했다. 그러나 이 그림이 틀렸다는 것을 금방 알 수 있었다.
위기
"기획 검토 부탁드립니다"
개발자로서가 아니라 팀장으로서 기획 검토 요청을 받은 것이라지만 굉장히 생소한 느낌이었다. 개발자로서는 경험해왔던 일이 아니었기때문이다. 팀장은 팀의 방향과 기획 내용이 부합하는지 검토해야 한다. 즉 팀의 목표, 우선순위, 자원, 성과 지표 등을 고려한 의사결정을 내릴 수 있어야한다. 누구나 팀장이 처음일 때가 있을 것이라고 생각하며 내가 쌓아온 의사결정의 경험과 논리적인 사고를 통해 나름의 명확한 피드백을 하려고 노력했다. 하지만 곧 내 전문성에 대해서 스스로 의심이 들기 시작했다.
나에게 팀의 방향과 기획 내용이 부합하는지를 검토할 수 있는 충분한 전문성이 있는가? 개발자들은 기획 검토를 거친 후에 정리된 기획을 리뷰받아왔다. 리뷰 과정에서 개발자들이 낸 의견을 통해 방향이 변경되는 일이 없는 것은 아니지만 그것은 일이 되게하기위한 의견제시일 뿐 팀의 방향을 고려한 것들은 아니었다. 반면 PM은 프로젝트 관리 과정과 검토 과정에서 목표 설정, 방향성, 자원 관리, 우선순위 조정 등을 다루며 경험을 쌓아왔을 것이다.
즉 PM 출신의 팀장은 프로젝트 관리를 하면서 쌓아온 의사결정에 대한 전문성을 가지고 있는 반면, 개발자 출신인 나는 경험에 기반한 근거없는 감과 의욕만 있는 것 같았다.
처음 그렸던 그림은 잘못되었던 것이다.
팀장과 PM 간 겹치는 영역이 없지 않았다. PM은 팀장의 역할과 밀접하게 관련된 전략적 계획 수립, 자원 관리, 우선순위 설정, 성과 지표 관리 등의 영역에서 경험을 쌓을 수 있다. 직접적으로 영역이 겹치지 않더라도 PM의 경험은 팀장의 역할에 밀접한 것은 확실하다고 생각한다.
팀장은 PL 에게 더 많은 영역을 위임할 수도 있었다. TL 이 위임을 받는 것과 PL이 위임을 받는 것은 그 범위가 달랐기에 TL의 경험으로만 팀장의 범위를 판단했던 것은 오류였다.
PL이 없기때문에 내가 조금 더 노력해야한다고 생각했던 영역은 PM 구성원들의 관리역할만 있는게 아니었다. PM에게는 있고 나에게는 없는 아주 큰 노력이 필요한 그런 영역이었다.
포기
팀장으로서의 전문성이 부족할 수 있다는 것을 인지했으니 그것을 채워야했다. 일단 나의 부족함이 PM 의 업무에 영향이 가지 않도록 내가 부족한 영역에 대한 업무 비중을 크게 높혔다. 대신 TL 업무의 비중을 줄일 수 밖에 없었다. 또한 내가 하는 학습이 더 이상 개발이 아닌 매니저에 대한 학습으로 변하게 되었다.
이 과정에서 현타가 오기 시작했다. 정말로 이제는 되고 싶지 않던 개발과 멀어진 관리자가 되버린 것이다. 스트레스를 극한으로 몰고간 것은 아이러니하게도 도움이 되고자 찾아본 매니저/리더십 교육이었다. 리더 는 원래 가진 커리어를 버려야한다고 이야기를 했다. 이 말은 나에게 더 큰 스트레스로 받아들여졌다. 나는 아직 개발 커리어를 버릴 마음이 전혀 없었기때문이다.
이 상황을 극복하기 위한 2가지의 선택지를 떠올렸다. 첫번째는 개발에 대한 커리어는 접어두고 리더로서 커리어를 시작하는 것이다. 스트레스의 가장 큰 원인이 아직 개발에 대한 커리어를 놓지 못한 것이기 때문이다. 두번째는 팀장을 그만두고 개발자로 돌아가는 것이다.
나는 후자를 선택했다. 내 커리어의 장애상황이었다. 가고싶지 않은 커리어를 유지해봐야 장애상황만 악화된다고 생각했다. 빠르게 실패하고 재시도하는게 좋다고 생각했다. 다행히 조건부 보험이 잘 동작하여 적절한 시기에 팀장을 내려놓을 수 있었다. 이렇게 약 7개월 간의 목적조직 팀장 커리어를 마감하고 나는 다시 테크리드로 돌아갔다.
마치며
7개월 밖에 안되는 팀장 경험이었지만 내게 많은 것을 남겼다. 글에는 작성하지 못했지만 큰 규모의 TF의 테크리드를 병행하기도 했고 조직 구성에 변화가 있는 등 사건도 많았던, 기억에 오래남을 첫번째 팀장 경험이다. 실패는 했지만 좋은 경험이었다.
아쉬움 또한 많이 남았다. 애초에 수락을 하지 말았어야할까? PL이 있는 목적조직이었다면 어땠을까? 개발팀이었다면 달랐을까? 여운이 꽤 길게남아 한동안 꼬리에 꼬리를 무는 리더에 대한 생각을 하게 되었다. 그리고 글로 남기며 정리를 해보아야겠다고 생각을 했다.
관리자 는 생각도 하기 싫었고 개발만 하고 싶었던 개발자의 목적조직 팀장 경험을 공유해본다.
최근 또다시 커리어의 새로운 도전을 하게 되었다. 팀 소속을 떠나 더 큰 규모의 조직에서 테크리드를 맡게 되었다. 과연 나는 앞으로도 행복 개발하는 개발자 생활을 할 수 있을까?
댓글