프로젝트에서 팀장 역할을 맡으며 했던 고민들

나는 어떤 고민을 하며 프로젝트를 진행하였는가?

 

이번 포스팅에서는 지난 looky 프로젝트를 경험하며 팀장의 역할을 맡아서 협업을 진행하는 과정에서 겪은 협업에 대한 고민을 얘기해보려고 한다.

 

지난날들과 다르게 이번 프로젝트에서는 팀장이라는 역할을 맡아서 프로젝트를 진행해 보았다. 비록 회사는 아니지만 어떻게 보면 사회에서는 첫 팀장의 직책을 맡았던 경험이고 그런 자리와 환경에 있으니 프로젝트의 시작부터 끝까지 여러 걱정들이 많았었다.

 

프로젝트도 성공적으로 끝났고, 팀원들에 대한 나의 평가도 좋아서 기분이 좋지만 글을 쓰면서 다시 정리하고 남겨보고 복기하며 추후 보완해야 할 점을 적어보고자 한다.

---

가장 처음으로 고민했던 것은 바로 일정관리이다. 프론트엔드 구성원들로만 이루어진 우리 팀의 경우 PM의 역할도 내가 병행해야 했다. PM의 역할에는 여러 역할이 있지만 나에게는 프로젝트의 전반적인 일정 관리에 대한 역량이 이번 프로젝트에서 필요했다.

 

일정관리 대해서 굉장히 고민이 컸던 이유는 바로 상대적으로 적은 프로젝트 기간이었다. 일반적인 과제나 프로젝트와 다르게 대주제는 정해져 있었으나 세부적인 기획, 개발, 배포를 단 19일이라는 짧은 시간에 마쳐야 했다. 주말과 휴일을 포함하더라도 27일 정도의 한정된 기간이었다.

 

이러한 사실을 깨닫고 내가 실행했던 것은 기간이 짧다는 것을 팀원들에게 인지시키는 것이었다. 그리고 어렵지 않게 이 부분을 팀원들에게 잘 공유하고 공감을 끌어낼 수 있었다.

 

이로 인해 파생된 첫 번째 Todo사항은 일정 공유에 대한 필요성을 언급하는 것이었다.

이 부분에서도 팀원들을 설득하는 데에 큰 어려움은 없었다. 짧은 기간 동안 빠르게 프로젝트를 완료하려면 필요하다는 것을 어필했고 이후 팀원들과 각자 생활 패턴과 캘린더를 통한 일정 공유를 진행하였다.

 

생활 패턴 공유

 

캘린더를 통한 개인 일정 공유

 

이런 내용뿐만 아니라 휴식에 대한 내용 같은 것들도 공유했던 것으로 기억한다.

이렇게 일정과 패턴을 공유하니 긍정적인 효과들이 많이 있었다. 팀원들이 어떤 성향을 띠고 있는지와 어떻게 휴식을 취하는지 잘 인지할 수 있었고 그에 따라서 프로젝트를 진행하는 데에 필요한 계획이나 일정관리, 스프린트 관리를 효과적으로 수행할 수 있었다.

 

두 번째 Todo 사항은 선제적으로 일정에 접근하는 것이었다.

우리 캘린더의 첫 주차를 자세히 보면 다음과 같다.

프로젝트 1주차

 

스프린트의 시작을 프로젝트 시작과 같이 가져가는 것이 아닌, 계획된 기간보다 빠르게 시간을 내어 프로젝트의 진행을 앞당기는 것이었다. 이렇게 할 수 있었던 근거는 다음과 같다.

1. 해당 일자들에 강의가 그렇게 많지 않았다.
2. 선제적으로 접근한 날짜에는 많은 시간을 투자하는 것이 아닌 예열의 느낌으로 가볍게 자원을 투자하였다.
3. (추후 느낀 점) 우리 팀 모두 프로젝트에 대한 열정이 많이 있었다.

이러한 개인적인 근거를 바탕으로 팀원들에게 미리 제안을 했고, 팀원들 역시 그런 나의 의견을 잘 수렴해 주어서 보다 빠르게 프로젝트에 시작을 앞당길 수 있었다.

 

위 방법들을 통해 진행했던 일정 관리의 결과는 다음과 같다.

1. 기획서, 중간발표에 대한 자료를 하루 일찍 제출할 수 있었다.
2. 예상했던 최초 배포가 4일 단축되어서 QA 및 리팩토링의 시간을 확보해 최종 발표에서 개선된 버전을 릴리즈 할 수 있었고 만족도 높은 프로젝트를 구현할 수 있었다.
3. 최종 발표에 대한 자료 역시 하루 빠르게 마무리할 수 있었고 이후 팀원들 간 소회 및 이후 일정에 대해서 어떻게 진행할지 얘기할 수 있는 시간을 가질 수 있었다.

---

개발 기간 중 나에게 고민을 가져왔던 것은 팀원들 간의 개발 속도의 격차와 방향성 공유의 부재이다. 

 

정말 여러 가지 이유로 인하여 각각의 인원별로 개발 속도의 격차가 생겼다. 이는 팀 프로젝트에서, 협업에서 당연히 그리고 자주 생기는 일이다. 각자의 일정, 경험, 실력, 이해도, 구현 분야 등 많은 이유로 인해 어쩔 수 없이 격차가 생긴다.

 

이번 고민은 나의 개인적인 고민으로부터 파생되었다. 나의 개발 속도는 처음부터 마음에 들지 않았다. 프로젝트에서 기획과 디자인을 받아서 개발만 하는 경우도 있겠지만 이번 경우에는 그런 부분을 모두 우리끼리 담당해야 했다.

 

우리 팀원들이 멋진 아이디어와 기획을 세워주었고 그에 따른 문서화, 자료 제출 등을 지속적으로 신경 써야 했다. 그런 부분에서 고민하고 시간을 투자하다 보니 막상 나의 개발 속도가 많이 늦어졌다.

 

그리고 방향성 역시도 약간 의문이 드는 부분이 중간중간 생겼다. 개발을 하다 보면 비슷한 기능을 구현하거나 공유해야 하는 주제가 생기기 마련인데 그런 부분에서 공유하는 게 맞다는 것을 알면서도 막상 개발에 열중하다 보면 공유보다는 개인의 스타일대로 진행하게 되었던 것 같다.

 

확실하게 문제가 되었다. 지나고 나서 얘기해 보면 나뿐만 아니라 팀원들도 중간중간 그런 감정을, 생각보다 속도가 나오지 않는다는 사실을 은연중에 우리 모두 느끼고 있었던 것 같다.

 

복잡한 문제였다. 어떻게 해결해야 할지 개발 초기부터 계속 고민을 했었는데 그러다 꺼낸 방법은 페어코딩이었다.

 

페어코딩이란?

페어 코딩(Pair Programming)은 소프트웨어 개발 방법론 중 하나로, 두 명의 개발자가 하나의 컴퓨터에서 협업하여 코드를 작성하는 방식을 말합니다. 주로 두 명의 역할은 "드라이버(Driver)"와 "내비게이터(Navigator)"로 나뉩니다.

 

위에서 언급한 것이 페어코딩의 정의이긴 한데.. 아무래도 실력이 비슷하다 보니 드라이버나 내비게이터를 나누기보다는 함께 드라이버로서 코딩을 진행하는 방식을 팀원들에게 제안했다. 

 

사실 그때를 돌이켜 생각해 보면 모두가 비슷한 생각을 하고 있던 것 같았다. 프로젝트 중반부에 지치기도 지쳤는데 막상 크게 뚜렷한 성과는 안 나온 그런 상황이었다. 그런 상황에서 나의 페어 코딩제안은 생각보다 시기적절했던 것 같고 팀원들과 순차적으로 페어코딩을 진행할 수 있었다.

 

 

디스코드

 

라이브 셰어

 

우리의 페어코딩은 VSC의 라이브셰어와 디스코드 화면 공유를 통해서 주로 이루어졌다. 페어코딩을 하면서 겪었던 고민들이 많이 해소되었는데 일단 내가 모르는 건 동료들이 알려주고, 동료들이 모르는 건 내가 알고 있고 이런 상황이 자주 있었다. 그렇기에 속도와 생산성이 매우 향상되었다.

 

그런 과정에서 방향성 역시 같이 공유를 할 수 있었다. 전체 프로젝트 사항에 대한 리뷰와 피드백을 개발을 진행하면서 중간중간 의견을 교환하고 방향을 정할 수 있었다.

 

이후로도 우리의 페어코딩은 계속됐다. 큰 기능을 dev에 Merge 한 경우, 공통 요구사항을 수정해야 하는 경우, dev -> main으로 배포 버전을 업데이트하는 경우 등 페어 코딩을 활용하며 고민들을 해결해 가며 빠르고 효율적으로 프로젝트를 진행할 수 있었다.

 

위 방법들을 통해 진행했던 페어 코딩의 결과는 다음과 같다.

1. 3차 스프린트의 기간의 목표를 3일 빠르게 완성하여 관련된 피드백을 빠르게 받을 수 있었다.
2. 이후 일정에서 내용 공유나 방향성에 이해관계 충돌이 현저히 줄었다.

---

개발과정에서는 위 두 가지 사례에서 가장 고민이 컸고 나름 생각한 해결책이 잘 적용되고 좋은 효과를 내어 프로젝트를 잘 마무리했던 것 같다. 하지만 프로젝트가 끝나고도 일부 지속되는 고민들이 있다.

 

첫 번째로 피로에 잠식되어서 하기로 했던 사항들을 제대로 이행하지 않았다는 것이다. 어떤 얘기인지 간단한 예를 들어보고자 한다. 우리 팀은 19시 이전에 올라온 PR에 대해서 당일 리뷰를 완성하기로 정했다.

 

그러나 여러 사정에 의해서 나도 팀원들도 그러지 못하는 경우가 있었다. 초반에는 이러한 부분에 대해서 리마인드를 남겼지만 점점 피로가 쌓이다 보니 나도 제대로 신경 쓰지 못했다.

 

그런 상황들, 그런 약속들을 잘 이행하지 못한 것이 아쉬웠다. 이러한 부분이 누군가에게는 또 불만적인 부분으로 다가왔을 것 같다는 생각도 들었고 실제로 중간에 팀 분위기가 전체적으로 가라앉았던 느낌을 받기도 했다.

 

중간회고 Problem

 

중간회고를 KPT로 진행했고 해당 부분에 Problem에 관련 내용을 작성해서 이후에는 좀 더 적극적으로 프로젝트의 진행을 가져가서 그런 아쉬움이 적긴 했지만 아무래도 프로젝트 중반부에 나부터 분위기가 가라앉다 보니 팀원들에게도 영향을 미친 것 같아서 아쉬웠다.

 

추후 프로젝트에서는 일단 피로 관리는 당연히 잘해야 하고 그런 진행하기로 했던 약속들은 일관적으로 이행될 수 있도록 보완하고자 하는 목표가 있다.

 

두 번째로는 말에 대한 고민이 너무너무 많았다.

우리는 `성인`이다. 나는 개인적으로 성인이 되었을 때 가장 신경 써야 하는 부분이 의사표현의 적절함을 신경 써야 한다고 생각한다. 때론 나의 말이, 나의 의견이 누군가에게는 날카로운 창처럼 느껴질 수 있기 때문이다. 적어도, 그런 부분에서는 팀원들에게 상처가 되는 행동은 하고 싶지 않았다.

 

그래서 고민이 많았다. 이걸 해줬으면 좋겠는데 그걸 어떻게 잘 말할까? 이렇게 하면 안 될 텐데 어떻게 말할까? 더 좋은 방식이 있는 것 같은데 왜 이렇게 되었을까?

 

이런 필터링들을 실시간으로 머릿속에서 거치다 보니 말이 길어지고 때로는 나조차도 말의 목적이 잊히거나 쓸데없는 말을 추가적으로 하기도 했던 것 같다. 팀원들은 그렇지 않다고들 하셨지만 개인적인 느낌에서 아쉬운 부분은 지울 수 없는 것 같다.

 

왜냐하면 이런 부분에서 내가 아쉬워하는 것은 바로 시간 낭비와 목적성의 상실이다. 말을 잘하는 것은 중요하다. 하지만 그로 인해했던 말 또 하고 시간을 낭비하고 그러다 보면 대화의 목적이 상실되는 느낌을 강하게 받았다.

 

여전히 개인적인 고민거리로 남아있지만 다음 프로젝트에서는 좀 더 간결하고 빠르게 의사표현을 전달하되 상대방을 존중하는 화법은 그대로 이어나가고자 하는 목표가 있다.

---

이번 프로젝트를 진행하며, 첫 팀장을 맡으며 이런 고민을 했던 것 같다.

 

이 밖에도 많은 고민과 고치고 싶은 점이 있기도 하고, 더불어 잘 한 점도 많다고 느낀다. 그 중 내가 중점적으로 느꼈던 고민들을 기술해봤고 차후에 진행될 프로젝트에서 이런 고민을 바탕으로 더 협업을 잘 하고 싶어서 이렇게 글을 남겨봤다.

 

이런 것을 소프트 스킬이라고 한다고 하는데 소프트 스킬 역시 개발만큼 어려운 것 같다. 하지만 이런 소프트 스킬은 어떤 일이 잘 되었을 때 정말 인간적인 행복감을 느껴주게 하는 것 같다. 소프트 스킬은 결국 사람과 연관된 그런 이야기들이 많은 것 같기 때문이다.

앞으로 있을 수 많은 프로젝트에서도 잘 할 수 있길 바라며 포스팅을 마친다.