팀장으로서의 6개월

작년은 ‘캠프’라는 목적 조직에서 겸직으로 한 해를 보냈다.

나를 포함해 세 명의 개발자가 해당 조직에 속했고, 회사에서 공식적으로 존재하는 직책은 아니었지만 리드 개발자 역할을 맡았다.

연차와 경험이 쌓이면서 여러 프로젝트를 이끌어 왔지만, 목적 조직에서의 리딩은 프로젝트 하나를 이끄는 것보다 더 넓은 범위를 다루는 일이었다.

당시 함께 일하던 동료들에게 우리가 맡은 제품과 도메인이 낯설었다. 그래서 직접 개발하기보다는 도메인 지식을 공유하고, 설계를 함께 고민하고, 코드 리뷰를 하는 데 많은 시간을 썼다.

특정한 사람에게 지식과 경험이 집중되지 않도록 하는 것에도 신경 썼다. 이른바 버스 팩터(Bus Factor)를 높이는 일이었다. 누군가 자리를 비우더라도 다른 사람이 충분히 업무를 이어갈 수 있는 팀을 만들고 싶었다.

그러다 보니 자연스럽게 제품과 관련된 요구사항을 가장 먼저 접하고, 우선순위를 정해 적절한 사람에게 배분하는 일도 맡게 됐다.

코드를 직접 작성하는 시간은 크게 줄었지만 성취감이 있었다.

내가 직접 코드를 작성하지 않더라도 동료가 문제를 풀 수 있도록 돕고, 여러 사람이 더 나은 방향으로 움직이게 만드는 것 역시 개발과는 다른 방식의 기여라는 생각이 들었다.

그리고 이 경험은 자연스럽게 한 가지 질문으로 이어졌다.

팀장을 한번 해봐도 괜찮지 않을까?

Two-way Door

올해 2월, 내 원소속 팀의 팀장 자리가 공석이 됐다.

나는 팀장을 맡아보고 싶다는 의사를 밝혔다.

그렇다고 이 선택을 매니저 트랙으로 완전히 전환하는 결정이라고 생각하지는 않았다. 내게 팀장은 승진이라기보다 팀 안에서 누군가 맡아야 하는 여러 역할 중 하나에 가까웠다.

무엇보다 궁금했다.

내가 이 역할에서도 좋은 성과를 낼 수 있을까. 개발자로 일할 때처럼 충분한 성취감을 느낄 수 있을까.

그래서 이 선택을 Two-way Door, 즉 되돌릴 수 있는 선택이라고 생각했다.

익숙한 역할과 컴포트 존에 머무르기보다 기회가 왔을 때 경험해 보고 싶었다. 잘 맞는다면 계속해 보고, 충분히 경험한 뒤에도 나와 맞지 않는다고 판단한다면 다시 개발자의 역할로 돌아가면 된다고 생각했다.

그렇게 팀장이 되었고, 어느덧 6개월이 지났다.

리드 개발자와 팀장은 생각보다 달랐다

작년의 경험 덕분에 팀장 역할도 어느 정도 비슷할 것이라고 생각했다.

하지만 직접 해보니 꽤 달랐다.

리드 개발자로 일할 때 마주했던 일들은 대부분 내가 지난 10년 동안 개발자로서 쌓아온 경험 안에 있었다. 도메인을 설명하고, 기술적인 방향을 정하고, 설계를 함께 고민하고, 코드 리뷰를 하는 일들이었다.

팀장이 된 뒤에는 다뤄야 할 영역이 달라졌다.

팀의 우선순위를 정하고, 팀 밖에서 들어오는 여러 요구와 기대를 조율해야 했다. 동료가 겪는 어려움을 듣고 함께 방법을 찾아가는 것도 중요한 일이 됐다.

특히 회사나 조직에서 팀으로 전달되는 도전과 압박을 어떻게 받아들이고 전달할지가 생각보다 어려웠다. 때로는 그 무게를 내가 그대로 떠안기도 했다.

동료가 느끼는 불안이나 답답함을 충분히 받아들이는 일도 내게는 익숙하지 않았다. 기술적인 문제라면 원인을 찾고 대안을 고민할 수 있지만, 사람의 감정에는 그렇게 명확한 정답이 존재하지 않았다.

지난 6개월 동안 알게 된 사실 중 하나는 나는 문제를 해결하는 것에는 익숙하지만, 당장 해결할 수 없는 문제를 안고 가는 것에는 익숙하지 않은 사람이라는 점이었다.

반대로 나와 잘 맞는 부분도 있었다.

팀이 어디에 집중해야 하는지 고민하고 우선순위를 정하는 일, 기술적인 방향을 함께 고민하는 일, 누군가 막혀 있을 때 상황을 정리하고 앞으로 나아갈 수 있도록 돕는 일은 여전히 재미있었다.

특히 내가 직접 나서지 않았더라도 동료가 성장하거나 팀 전체가 이전보다 더 나은 방식으로 일하게 되었을 때 느끼는 성취감은 개발자로 일할 때와는 또 다른 종류의 것이었다.

결국 지난 6개월은 팀장이라는 역할뿐 아니라, 내가 가진 강점과 약점을 이전보다 정확하게 알게 된 시간이기도 했다.

연차가 쌓인다고 자연스럽게 좋은 리더가 되는 것은 아니었다

좋은 리더는 타고난 재능의 결과가 아니라 꾸준한 학습의 실천, 그리고 작은 실패에서 배운 교훈이 쌓여 만들어진다.

— 《리더십 연습》, 한기용·김지윤

팀장을 시작할 때부터 연차와 경험이 쌓였다고 해서 자연스럽게 잘할 수 있는 역할은 아니라는 것을 알고 있었다.

그럼에도 이런 생각이 강했던 것 같다.

“각 조직과 팀의 상황이 모두 다른데, 결국 내 상황에 맞는 답은 내가 찾아야 하지 않을까?"

틀린 생각은 아니지만, 돌이켜보면 조금 극단적으로 받아들였다.

처음 해보는 역할인데도 스스로 답을 찾아야 한다고 생각하다 보니 자주 길을 잃었다. 내가 잘하고 있는지 판단할 기준도 부족했고, 필요 이상의 압박감을 느끼기도 했다.

마침 여름 휴가 시즌이 되었고, 여러 이유가 겹쳐 과감하게 2주간 휴가를 가졌다.

쉬는 동안 그동안 미뤄두었던 리더십과 매니지먼트 관련 책들을 읽었다. 그런데 책 속에서 의외로 익숙한 장면들을 많이 만났다.

내가 부족해서 겪는다고 생각했던 일 중 상당수는 처음 팀장이 된 사람들이 반복해서 경험하는 일이었다. 혼자 답을 찾아야 한다고 여겼던 고민에도 이미 먼저 경험한 사람들이 정리해 둔 원칙과 방법이 있었다.

상황이 달라진 것은 아니지만, 적어도 그것을 바라보는 마음은 한결 편해졌다.

특히 도움이 되었던 책은 다음 세 권이다.

• 《요즘 팀장의 오답노트》 — 서현직
• 《리더십 연습》 — 한기용, 김지윤
• 《개발 7년차, 매니저 1일차》 — 카미유 푸르니에

세 책은 조금씩 다른 이야기를 하지만 내게 남긴 메시지는 비슷했다.

리더십 역시 개발과 마찬가지로 배우고 연습해야 하는 기술이라는 것.

생각해 보면 개발자가 된 첫날부터 지금처럼 일할 수 있었던 것도 아니다.

수많은 코드를 작성하고, 잘못된 설계를 하고, 장애를 만들고, 코드 리뷰에서 지적받고, 더 좋은 개발자들의 코드를 보면서 조금씩 나아졌다.

그런데 팀장이 되고 나서는 이상하게도 처음부터 잘해야 한다고 생각했던 것 같다.

6개월이 지나고

아직 팀장이 나에게 가장 잘 맞는 역할인지는 모르겠다.

6개월은 그 질문에 답하기에는 짧은 시간이라고 생각한다.

다만 몇 가지는 이전보다 분명해졌다.

첫째, 좋은 개발자였다고 해서 자연스럽게 좋은 팀장이 되는 것은 아니다. 개발자로 쌓은 경험은 분명 도움이 되지만 사람과 조직을 이끄는 데에는 별도의 학습과 연습이 필요했다.

둘째, 팀장이 모든 문제의 답을 가지고 있을 필요는 없다. 어떤 일은 해결하기보다 잘 듣고 기다려야 하고, 어떤 일은 동료 스스로 답을 찾을 수 있도록 돕는 편이 낫다. 아직도 내게 가장 어려운 부분이다.

셋째, 내가 직접 한 일만을 성과라고 생각하지 않게 됐다. 코드를 작성하지 않았더라도 팀이 더 좋은 판단을 내리도록 돕고, 누군가 성장하고, 팀 전체가 더 안정적으로 움직이게 되었다면 그것 역시 내가 기여한 결과라고 생각한다.

처음 팀장을 선택할 때 나는 이 결정을 Two-way Door라고 생각했다.

6개월이 지난 지금도 그 생각은 변하지 않았다.

언젠가 다시 개발에 집중하는 선택을 할 수도 있고, 생각보다 오랫동안 이 역할을 계속하게 될 수도 있다.

다만 지금은 ‘나에게 팀장이 맞는가?’라는 질문에 너무 빨리 답을 내리기보다, 일단 제대로 한번 배워보고 싶다는 생각이 더 크다.

개발자로서 지난 10년 동안 그랬던 것처럼 작은 실패를 하고, 회고하고, 다른 사람에게 배우면서 조금씩 나아가는 것.

지금은 그것이 내가 팀장이라는 역할을 대하는 방식이다.