처음 들어가게 된 직장에서 감히 리드라는 이름을 걸고 들어가게 되었습니다. 어떻게 현업 0년차가 리드가 될 수 있었을까요? 리드의 자리에서 어떤 역할을 했을까요?
처음과 계기
우아한테크코스를 마치고 학업에 대한 열망 보다는 현업에 뛰어들고픈 욕망이 강했습니다. 그래서 3학년에, 조금 이를 수 있지만 학교에서 6개월간 진행하는 IPP(기업연계형 장기현장실습)에 참여했습니다.
학교 친구의 소개로 그 전부터 외주를 조금씩 맡아오던 회사에 들어가게 되었습니다. 프론트엔드 팀원은 저를 포함한 3명이었습니다. 그리고 프론트엔드 리드의 역할을 하게 되었습니다.
이미 프론트엔드 팀원 모두 서로 알고 있는 관계였습니다. 학교 동아리에서 동아리원 교육담당 역할을 했을 때 교육을 받았던 친구 2명이었습니다.
회사 측에서 먼저 기존 팀원의 사수 역할을 맡기기를 원했고, 이 또한 값진 경험이 될 것이라고 생각하며 응했습니다. 기존 팀원 역시 제가 리드로 들어오는 것을 이해해주고 받아들여주었습니다. 동아리에서의 교육담당 역할과 진행력에 있어서 신뢰를 얻었던 것이 컸던 것 같습니다.
이로써 의아하지만 6개월 기한 0년차 리드가 되었습니다.
리드란? 0년차 리드란..?
본래 리드는 현업 경험이 풍부하고 기술적으로도 팀원과는 차별점이 있어야한다고 생각합니다. 이를 활용해 팀원의 고민을 듣거나 기술적인 조언이나 리뷰를 줄 수 있겠죠. 개발 목표, 문화를 만들어가고 팀의 성장을 도모할 수 있는 사람이어야 할 것입니다.
하지만 지금 "내가 위와 같은 사람인가?" 라고 묻는다면 단연코 No 일 것입니다.
0년차 리드에게 현업 경험은 없는 것과 다름이 없습니다. 기술적으로도 뛰어나다고 볼 수 없죠. 그만큼 현재의 위치에서 리드로써 어떤 일을 할 수 있을지 많은 고민을 했습니다. 과연 0년차 리드는 어떻게 팀을 이끌었을까요?
신뢰하는, 신뢰받는
팀원을 신뢰하고 팀원들에게 신뢰받기 위해 가장 먼저 노력했습니다. 이 부분에서는 큰 강점을 가져갈 수 있었습니다. 이미 동아리에서 교육담당을 맡았을 적 신뢰를 어느정도 유지하고 있었기 때문입니다. 그래서 반대로, 팀원들에게 신뢰를 주기 위한 노력을 많이 했습니다.
성급한 일반화
프론트엔드 리더의 역할을 고민하면서 여러 리더분들이 작성한 블로그 글을 참고했는데, 아래의 내용이 제 머리를 때렸습니다.
어쩌면 나를 포함한 많은 (특히 역할을 맡은 지 얼마 안 된) 리드가 자기 능력은 과대평가하고 팀원의 능력은 과소평가한다– 고까지 말할 수 있을 것 같다. 전문
자연스럽게 교육을 진행했었던 팀원들이기도 했고 우테코 활동 등으로 다양한 기술을 공유해 왔기 때문에 팀원들보다는 본인이 실력이 나을 것이라고 생각했습니다. 하지만 이 부분은 성급한 일반화였습니다.
물론 여러 부분에서 팀원이 모르는 기술을 공유해 줄 수 있었던 것은 사실이었습니다. 하지만 회사의 도메인 지식, 기존 로직 설계와 활용 등 팀원이 더 잘 알고 있는 부분도 충분히 많았습니다. 팀원들과 본인을 동등한 선에서 바라보기 시작한 것이 서로간 신뢰 관계를 두텁게 만들어 주었습니다.
신뢰하니까
팀원 서로의 신뢰는 강력한 파급 효과를 가지고 왔습니다.
편한 분위기가 형성 되니 서로 본인의 생각을 좀 더 거리낌 없이 이야기 하게 되었습니다. 특정 주제를 가지고 논의를 진행할 때도 더욱 적극적으로 임하게 되었습니다.
일을 분배할 때에도 도움이 되었습니다. 처음에는 일을 분배할 때 '이 일을 맡기면 잘 해낼 수 있을까?'와 같은 생각을 했었습니다. 하지만 팀원을 신뢰하기 생각하면서 '이 일을 맡겨도 잘 해낼 수 있을거야'와 같이 생각이 전환되었습니다.
이제 본격적으로 팀을 잘 리드하기 위한 시도를 하기 시작했습니다.
팀원 성장
리드를 맡으며 가장 초점을 두었던 것은 '팀원 성장'이었습니다. 저는 6개월 기한이 있는 반면, 팀원은 이 회사에서 아마, 계속 일을 하게 될 수 있는 상황입니다. 뿐만 아니라 팀원의 미래 커리어를 생각해서라도, 팀의 성장을 위해서라도 팀원을 성장시키기 위한 노력은 중요했습니다.
제가 할래요!
회사의 사이클에 맞추어 주간 작업을 정하고 이 작업을 분배 할 때 최대한 팀원이 원하는 일을 할 수 있도록 했습니다.
1 대 1 미팅이나 회의를 여러 번 진행하며 알게된 팀원들의 공통점이 있었습니다. 두 팀원 모두 새로운 것에 대한 두려움이 없고 오히려 시도해 보고자 하는 자세가 있다는 점입니다. 이 점을 활용해 작업을 분배할 때 팀원이 원하는 작업을 하도록 하면서 새로운 기술이나 지식을 필요로 하는 작업을 스스로 가져갈 수 있게 했습니다. 이 과정에서 팀원들도 특정 작업에 대해 어떤 생각을 가지고 있는지 이야기를 해줍니다.
'이 부분에서 사용하는 기술은 아직 접해보지 못했으나 시도해 보고 싶어요. 막히는 부분이 있으면 도움을 줄 수 있을까요?'
이렇게 팀원들이 의존할 수 있는 분위기를 만들었습니다. 알려주고 같이 알아나가는 것을 좋아하는 입장에서 팀원이 이러한 방향으로 의존하는 것은 환영이었습니다. 팀원 입장에서 원하는 작업을 가져가서 하는 것이기 때문에 집중도가 좋아지고 이 작업에 대한 책임감을 더 심어줄 수 있었습니다. 그래서 오히려 일을 지정해 주는 것보다 데드라인을 넘어가는 일이 없었습니다.
코드 리뷰
코드 리뷰에서는 같이 의견을 나누며 본인만의 코드 가치관을 만들고 이야기 할 수 있는 것에 초점을 맞추었습니다.
정해진 답 보다는 '왜 그렇게 했는지?', '나는 이렇게 생각하는데 본인은 어떻게 생각하는지?', '여러 방법 중 이 방법 택한 이유가 뭘지?' 와 같이 생각을 알기 위한 리뷰를 많이 진행했습니다. 예를 들어, '평소라면 당연히 이렇게 쓰는게 좋지 않나?'라고 생각한 내용에 대해서도 '이렇게 쓰는게 더 좋을것 같다.' 보다 '나는 이렇게 생각하는데 본인은 어떻게 생각하는지?'와 같이 물어보았습니다.
살짝 걱정이 되었던 점도 있었습니다. 의견을 위한 리뷰를 남겨도, 리뷰에 제 생각을 포함해 전달하면 본인이 생각할 시간을 갖지 않고 이 생각을 일방적으로 수용해 버릴 수 있겠다는 점이었습니다. 그래서 항상 "나의 의견은 정답이 아니라 생각일 뿐이니 본인이 생각하고 있는 그대로를 전달해 주었으면 좋겠다."는 이야기를 서면으로도 많이 했습니다. 다행히 팀원들도 수용해야겠다는 의견이 생겨도 최소한 본인의 생각을 이야기 해주는 문화를 만들 수 있었습니다.
아무래도 코드 리뷰를 할 때 의견 전달을 위한 생각을 많이 해야 했었기 때문에 시간을 많이 쓸 수 밖에 없었습니다. 하지만 얻은 것이 정말 많았습니다.
이 문화 덕분에 팀원 각각의 코드 스타일과 생각이 쌓이고 중화되면서 점차 팀원 코드에 대한 이해와 존중이 생겨났습니다. 한 가지 떠올려 본다면, if문이나 특정 정의 함수에 사용한 로직이 한 줄일 때 중괄호를 사용해야 하느냐와 같은 문제로 오랫동안 논의했던 기억이 나네요.
지금까지 당연시하며 넘어간 내용에 의문을 가질 수 있게 되었습니다. 예를 들어, 컴포넌트 안에 컴포넌트를 선언하는 경우입니다. 코드 리뷰를 통해 왜 이렇게 쓰면 좋지 않은지 에 대해 설명하려다 보니 그 '왜'에 대한 논리적인 답변이 떠오르지 않아 말문이 막힌 기억이 있습니다. 덕분에 당연하다고 느끼며 넘어간 코드 습관이나 안된다고 알고 있던 개념에 대해서 한 번 더 생각해보고 설명할 수 있는 능력을 많이 기를 수 있었습니다.
점차 팀원들간 코드 스타일과 생각이 중화되면서 팀 자체만의 코드 스타일을 만들어 나갈 수 있었습니다.
책임감
리드이기에 프론트 팀의 성공과 실패는 곧 저와 직결됩니다. 그렇기 때문에 팀에서 일어나는 일에 대한 모든 책임 또한 직결됩니다. 문제는 이 책임의 무게를 지금까지 느껴보지 못했기 때문에 초반에는 그 만큼의 책임감을 짊어지지 못했던 것 같습니다.
초반에 한 번 프론트 팀의 타임라인이 밀려 서비스 런칭기간이 하루 미뤄졌던 적이 있었습니다. 충분히 가능하다보고 막연하게 생각한 것이 패착이었습니다. 물론 작업을 분배할 때 제가 좀 더 가져갔더라면 미루어 지지 않았을 수 있었고 충분히 그럴 수 있었습니다. 하지만 이와 같은 방법은 정론이 아니었습니다. 결국 작업으로써의 비중을 많이 가져가는 것이 리드로써의 맡은 바라고 생각하지는 않았기 때문입니다.
바로 책임이었습니다. 책임의 무게를 소홀히 했고 이 때문에 팀원들도 영향을 받았습니다. 팀원들 또한 본인이 가지고 있는 작업 수행에 대한 책임감이 낮아진 것입니다. 이 때에서야 책임의 무게를 비로소 느낄 수 있었습니다. 다른 팀과 대표님 모두에게 양해를 구하고 다음에는 이렇게 되지 않기 위한 계획을 세워 이야기 했습니다. 다행히 대표님을 포함해 다들 너그럽게 받아주셨습니다.
팀원들과도 이야기를 나누었습니다. 팀원들 또한 각자 미안한 마음을 품고 있었습니다. 리드로써 책임감이 약했던 점을 이야기 하며 팀원 잘잘못 보다는 이번 계기를 통해 좀 더 잘 이끌어보겠다는 의지를 이야기 했습니다. 고맙게도 팀원들 또한 열심히 기대에 부응해 보겠다며 많이 저를 독려해 주었습니다.
이후에는 책임 의식을 더 가지고 일정을 잡았습니다. 좀 버거운 일정이라고 생각이 들면 기획 팀과 프론트 팀원의 의사를 조율해 가면서 중간을 맞추기 위해 노력했습니다. 덕분에 이후 서비스 런칭에 차질을 주지 않고 매끄럽게 작업을 끝낼 수 있는 프로세스가 만들어졌습니다.
좋지만, 그래도.
어쩌면 리드라는 자리는 저에게 잘 맞았던 것 같기도 합니다. 리드로써 완벽히 '잘' 했다, 라기보다 '적성'에 맞았다고 생각합니다. 팀원들을 케어하고 여러 방법과 기술을 같이 고민하고 알려주는 과정이 재미있었습니다. 그만큼 팀원들이 믿고 따라주며 확실히 전과는 달라진 마인드와 자세로 작업에 임할 때면 많은 성취감과 뿌듯함을 느꼈던 것 같습니다. 정말 인간적, 문화적 리드의 역할 만큼은 잘 해냈다고 스스로 생각하고 있고 자랑할 만 하다고 생각합니다.
반대로 걱정되고 아쉬웠던 점은 분명히 있었습니다. 본인이 기술적으로 성장하기에는 아쉬웠다고 생각이 듭니다. 물론 팀원들과 얻어나간 기술과 지식이 있습니다. 하지만 '내가 사수가 있었다면 이 생각에 대해서 어떻게 이야기 해주었을까'와 같이 중간중간에 좀 더 나은 생각을 하기 위한 촉발이 부족하다고 느꼈습니다. 더 많은 것을 배우고 깊게까지 이 분야를 이해하고 있는 분의 의견은 어떨지 목말랐던 것 같습니다.
그래서 이 부분을 조금이나마 해소하고자 몇몇 알고있는 연차가 있는 지인분들께 시간이 맞을 때 의견을 물어 볼 때도 많았던 것 같습니다. 이렇게 이야기를 할 때면 확실히 이렇게 생각할 수 있구나 싶습니다. 또 생각이 확 열리는 기분도 들어 앞으로는 든든한 사수 분이 있는 곳에 들어가고 싶다는 생각을 했습니다.
맺으며
6개월을 끝으로 이제 학교로 되돌아가지만 인연이 닿아 회사와는 외주 활동으로써 조금이나마 남아있기로 했습니다.
리드 경험도, 기술도 엄청 뛰어나지 않을 사람을 리드로 받아주고 믿고 따라준 팀원들에게 참 고맙습니다. 끝이 아닌, 앞으로도 서로 인연을 유지해 다 같이 성장하며 정상을 향해 달려가기를 기원합니다.
부록
아래의 글은 리더에 대해 배우고 변화하기 위해 읽었던 글들입니다.
- https://toss.im/career/article/toss-frontend-leadership-and-growth
- https://jojoldu.tistory.com/626
- https://medium.com/asleepblog/people-in-asleep-%EC%97%84%EA%B2%A9%ED%95%9C-%EC%9B%B9-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EB%A6%AC%EB%93%9C%EA%B0%80-%EC%9D%BC%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-e0a36c0a370d
- https://ahnheejong.name/articles/flex-team-fe-chapter-lead-retrospect/