협업 효율성을 높이기 위한 노력 - 원티드 프리온 보딩 중간 회고

프리온보딩 코스를 시작하고 벌써 프로젝트 3회차가 지났다. 그 동안 구현에 집중할 수 있고, 효율적인 작업을 위해 팀원들과 회의를 해왔는데, 막상 프로젝트 기간에는 밤을 새우게 되었고 이를 거듭하면 안되겠는 생각이 들었다. 1주일에 2번 이틀 간격으로 프로젝트를 진행하다보니, 사실 프로젝트 기간은 매우 짧은 편이다. 어쩔 수 없는 부분도 있지만 그럼에도 남은 7회 차 동안 조금 더 발전 된 모습으로 나은 결과를 내고자, 다른 팀들을 초청하여 어떤 방식으로 협업을 하고 있는지 논의하는 시간을 가져보았다. 이 글은 그 논의에서 의미있는 결과를 추출하고 정리하는 목적으로 작성하였다.

우리 팀의 현재 (3회차) 상황

1. 소통 방법(장)

우선 우리 팀은 소통이 매우 잘되는 편이다. 슬랙과 게더를 사용하여 코드리뷰 부터 트러블 슈팅까지 전부 진행하고 있다. 비대면 방식으로 협업하다보니 발생할 수 있는 소통 문제는 우리 팀원 모두가 가지고 있던 공통 걱정거리였다. 처음 팀이 꾸려졌을 때 의견을 내서 매체를 잘 선정했고 마치 한 공간에서 협업을 하고 있다고 느낄 정도로 잘 사용하고 있다. 추후에 다른 팀에 배치되어 소통의 부재를 해결해야 한다면, 위 두 매체를 적극 추천할 것 같다.

2. 프로젝트 진행 절차

1. 요구사항 분석
2. 이슈 작성
3. 칸반보드 관리
4. 프로젝트 환경 설정(라이브러리 설치, config 설정 등)
5. 담당 이슈 구현
6. 풀 리퀘스트(병합)
7. 배포

3. 팀원의 성향

팀원 모두 기술을 습득하고자 하는 욕구가 강하다. 그래서 새로운 기술을 도입하자고 하면 적극 찬성하는 편이다. 또한 개개인이 가진 역량 차이가 있고 분야별로 잘하는 부분과 못하는 부분이 극명히 보인다.

4. 지금까지의 팀 빌딩 방향

프리온보딩 코스가 끝났을 때, 팀원들이 값진 시간이었다는 생각이 들길 바라며 모두 성장에 초점을 두고 프로젝트를 진행해 왔다. 우리 팀원은 이 프로젝트에서 어떤 라이브러리를 쓰는게 적합할 것이고 구조적 디자인 패턴등 회의를 통해 기초 설계를 다졌다. 이 때 모르는 기술 스택도 적극적으로 도입했다. 장점은 기술에 대한 지식을 습득하고 어떤 장단점이 있는지 경험할 수 있다는 것이다. 단점은 그 기술을 도입했을 때 발생하는 단점을 미리 전부 파악할 수는 없다는 점에서 나온다. 실제로 사용해 봤을 때 발생하는 문제는 프로젝트의 완성도에 엄청난 영향을 미친다. 트러블 슈팅부터 시간이 오래걸리고 다른 기술을 사용했을 때 쉽게 해결 할 수 있는 문제를 어렵게 해결하기도 한다.

각 팀의 협업 방법 논의 사항

이미 팀 내에서는 충분한 논의를 통해 어느정도는 협업 방법을 개선해왔기 때문에, 더 이상 시단 대비 큰 개선 점 찾지 못했다. 그래서 이번에는 다른 팀을 초청하여 협업과 관련해 논의하는 시간을 가져보기로 했다. 1시간 동안 많은 논의를 했지만, 그 중에 기억하고 싶은 한가지 내용이 있다. 바로 빼기에 대한 내용이다. 어떤 기술을 더하고, 규칙을 적용하는 것도 중요하다. 하지만 선택한 규칙이 정말 우리팀에 도움이 되는 가는 한번 생각해봐야할 문제다. 대부분의 회사에서 채택하고 있는 "(풀리퀘, 이슈) 작성방식, 칸반, git flow, 등의 협업 방식이 지금 현재 우리의 상황에 도움이 되는가?" "혹시 생각의 틀에 갖혀 관례적으로 도구를 사용하고 있지는 않은가?" "혹은 그 도구의 장점을 살려 잘 활용하고 있긴 하는가?" 등의 의문을 품을 수 있다.

앞으로의 팀 규칙

지금까지의 규율이 진정 도움이 되는지, 꼭 필요한 것인지 다시 한번 생각하는 시간을 가졌다. 이 과정속에서 역시 팀원간의 갈등이 발생했다. 현재 규율이 도움이 되었다는 의견이 강했지만, 이전에 발생한 문제를 토대로 규율을 개선하자는 의견이 있었다. 트러블 슈팅과 관련하여, 기존에는 게더에서 구두로 공지하고 그때 그때 해결하는 분위기였으나 때로는 즉시 해결하지 못하는 경우도 있기 때문에 이슈를 통해 기록하고 관리하자는 의견이었다. 트러블에 대한 정의부터 어떠한 유형의 트러블을 이슈로 작성할 것인지 의견이 분분했고 우리는 논의 끝에 역량을 초과하여 해결하지 못하는 기능과 기능오류 및 발견된 디자인 오차를 이슈로 작성하기로 합의했다. 앞으로 트러블 슈팅에 있어서는 어떤 문제를 현재 누가 담당하고 있는지 또 어디까지 해결 됐는지 조금 더 구체적으로 진행사항을 파악할 수 있기를 기대한다.

또 새로운 기술을 적용할 때는 최대한 보수적으로 적용하자는 팀 규약을 추가했다. 새 기술을 적용하기에 앞서 충분히 자료를 조사하고 기술 구현에 무리가 없을 정도로 역량을 갖춰 검증이 되었을 때 사용하자는 취지다.

추가된 규율을 제외하고 마지막으로 무엇을 내려놨는가에 대해 작성하고 글을 마무리 하겠다. 구체적으로 어떤 규율을 제거하지는 않았다. 하지만, 우리는 마음가짐을 달리했다. 각자 생각하는 완벽함의 기준이 모두 다르다. 이 완벽함을 내려놓았다. 본인은 지속적으로 유지보수가 가능한 구조를 만들기 위해 리팩터링과 디자인 설계를 중요시한다. 하지만 이 스타일을 현재 상황에 적용시키면 오히려 역효과가 발생한다. 리팩터링은 장기적으로 보았을 때 기존 코드에 새 기능을 쉽게 추가하기 위해 존재하는 기술이다. 적당한 리팩터링은 필요하겠지만 과도한 리팩터링은 필요하지 않다. 아키텍쳐 설계 또한 많은 시간이 소비된다. 장시적으로 깔끔한 구조를 유지할 수 있지만 현재 상황에서는 1시간 정도내에 상태 설계 정도가 적합하다. 서로가 생각하는 기준은 어떤 상황에서는 모두 정답일 수 있다. 하지만 현재 상황에는 그 기준이 정답이 아닐 수 있기 때문에 잠깐 개개인의 완벽함을 내려놓고 팀을 기준으로 생각하는 마음가짐을 장착했다.

느낀점.

프로젝트 기간만 되면 밤을 새는 일이 잦아지니 팀장으로서 팀을 잘 이끌지 못한다는 생각이 들었다. 과연 팀장이 필요하긴 할까? 생각을 해보았는데, 초보 팀장으로서 내린 한가지 결론이 있다. 팀이 나아갈 수 있는 선택지는 정말 다양하다. 그중 나쁜 방향을 걸러내고, 팀원의 의견을 수렴하여 좋은 방향으로 유도하는 것이 팀장의 역할중 하나라고 느꼈다. 앞으로 남은 7회차 동안 발전하는 팀이 되기를 바라며, 마지막에는 팀원 모두 값진 시간었다고 느끼길 바란다. 끝.