DEV Community

loading...

팀으로 같이 하는 법 - 개발자 이야기

bonjune profile image Bill Jang ・1 min read

혼자 하면 안될까?

개발자로서 항상 헷갈리는 질문일 수 밖에 없다.
개발을 혼자 하면 모든 결정 사항에 대해 스스로 판단을 내릴 수 있으니 일의 진척 속도가 빠를 수 밖에 없다.
게다가 이전에 해오던 기술 스택을 그대로 가져갈 수 있으니 얼마나 효과적인가?
팀을 꾸려서 개발을 하는 것 마치 혼자 개발을 할 수 없는 멍청이들이나 하는 것처럼 보인다. (실제로 개발자는 자신의 능력을 과대평가하는 경향이 심하다.)

그러나 길게 진행되는 개발 프로젝트를 모두 혼자 맡아 진행하면 예외없이 실패하게 될 것이다.
처음보는 에러에 고통받는 것은 예사이고(물론 대부분의 경우 구글신과 스택오버플로우가 여러분을 구원할 것이다), 잘못된 설계에 빠져 개발 진행 속도가 0에 수렴하는 경우도 발생한다. 혼자 진행하다가 나태해져 진행이 중단되는 경우도 허다하다.
또, 현업으로 뛰다보면 시장상황이나 조직 내부상황에 따라 개발 프로젝트가 난항을 겪기도 하는데 이런 상황을 모두 통제하고 이겨낼 수 있는 개발도 잘하는 현신 제갈량은 찾기 힘들 것이다. (제갈량 조차도 촉한 내부의 음모로 난항을 겪은 적이 많다.)
그래서 우리는 팀이 필요하고, 팀을 꾸릴 수 밖에 없는 것이다.

팀은 뭘까?

그래서 팀이란 게 뭘까? 우리는 모두 같이 일해본 경험이 있다. 학교 조별과제에서 시작해서 현업 프로젝트에 이르기까지, 인간으로 살면서 모든 일을 혼자 처리한 인간은 이 행성에 존재하지 않을 것이라 확신할 수 있다. 그래서 우리는 모두 팀이라는 개념을 잘 알고 있다고 어느정도 확신을 가지고 있다. 그러나 팀이 무엇인지 속 시원히 설명할 수 있는 사람은 그렇지 많지 않을 것 같다. 나 또한 정답을 말할 수는 없으나 다음으로 팀을 정의하고 싶다.

목표를 공유하는 사람들

이러한 정의는 최근 읽었던 <피플웨어>를 에서 각색하여 따온 것으로, 이 정의를 들여다보면 팀이란 유기체에 대해 많은 통찰을 얻게 된다.

일단 팀을 꾸리기 위해서는 목표를 공유해야 한다는 것이다. 목표가 일치되고 공유되어야 팀이 제대로 작동할 수 있다.

목표 일치 시키기

목표를 일치시키는 것은 쉬운 일이 아니다. 인간은 모두 동상이몽을 하게 마련이고, 팀에는 다양한 이해당사자가 있다. 이런 혼란 상태를 이겨내야만 팀은 작동할 수 있다. 팀의 목표를 일치시키기 위해 가장 먼저 해야할 것은 무엇일까?

같이 일하자

갑자기 무슨 소리냐 물어보실 분들이 많을 것 같다. 같이 일해야 팀이지, 그것이 팀 아닌가? 하지만 세상에는 같이 일 하지 않는 팀들이 넘친다. 5명으로 이뤄진 팀에 프로젝트가 5개 할당되어 모두 다른 일을 하고 있다거나(파편화된 사람들), 프로젝트의 모든 결정 권한을 한 사람이 독점하고 있고 다른 사람들은 말만 따른다거나(팀이 아니라 군신관계).

이렇게 살펴보니 세상에 얼마나 많은 팀들이 팀이라는 가면을 쓴 사람들의 집합체인지 알 수 있지 않은가? 이들은 팀이 아니다. 목표가 모두 다른 곳에 있으며 팀으로써 작동하지 않는다. 더 나은 결과를 내기 위해 스스로 움직이지 않으며, 적극적으로 문제점을 포착해 해결 하지도 않는다. 이런 팀은 영원히 운이 좋으면 딱 그 수준에 머물며, 운이 나쁘면 도태될 것이라고 확신할 수 있다. 더 나은 팀들은 계속 나타날 것이기 때문이다.

그렇다면 같이 일하는 팀이란 무엇일까? 나는 개발자로서 다음의 개발 및 경영 문화가 잘 정착되어 있어야 한다고 본다.

먼저, 페어 프로그래밍 문화가 잘 자리 잡아야 한다. 페어 프로그래밍은 단순히 말해 모니터 하나를 두고 두명이 앉아 같이 프로그램을 작성하는 것이다. Pair로 프로그래밍을 했는데 전혀 Fair하지 않은 것 같다는 원성을 많이 듣기도 하지만(보통 실력이 불균형하기 때문이다), 페어 프로그래밍이 잘 정착 되었을 때 내놓는 시너지는 매우 높다고 확신할 수 있다. 흔히들 말하는, 에러 발생이 줄어서 품질 관리 비용을 줄일 수 있다거나 하는 장점도 있다. 하지만 페어 프로그래밍의 가장 큰 장점은 코드의 공동 소유권이다. 자신이 적극적으로 참여해 만들어낸 코드라는 사실, 자신이 완성 해낸 프로젝트라는 사실을 팀원에게 행동을 통해 알려주는 것이다.
개발자는 근본적으로 프로그래밍이라는 창작을 하는 사람들이고 자신이 무에서 유를 만들어 냈다는 것에 보람을 느낀다. 프로젝트의 결과물을 같이 창조해냈다는 보람을 일깨워준다면, 개발팀은 스스로 더 나은 결과물을 위해 스스로 미친듯이 내달릴 것이다. 또, 프로젝트 도중에 팀원이 피치 못한 사정으로 떠나더라도 코드 베이스를 이해하고 있는 팀원이 항상 있기 때문에 프로젝트는 더욱 견고(durable)해지는 장점도 가지고 있다. 아무도 이해할 수 없는 문서화에 매달려 시간을 날리는 것보다 팀원과 직접 소통하며 코드 한줄 한줄을 같이 써내려가는 것이 훨씬 효과적인 지식 전달 방법이다.

새로운 팀원이 왔다면 진행되고 있는 업무를 잠시 내려놓고 같이 페어 프로그래밍을 통해 기존 코드 베이스를 탐험하며 프로젝트를 다시 같이 이해해보자. 그러는 도중에 새로운 팀원이 버그를 잡을 수 있는 기회도 줘보고, 리팩토링을 할 수 있는 기회도 줘보자.(하지만 절대 명령형으로 하면 안된다. 자연스럽게 할 수 있도록 도와주자.) 들어온 지 얼마 되지도 않았는데 바로 기여할 거리를 찾는다면 그 팀원은 팀과 프로젝트에 아주 빠른 속도로 동화될 것이다. 그렇게 팀원은 같이 일하고 싶고, 프로젝트를 잘 이해하고 있는 유능한 팀원으로 빠르게 성장하게 된다.

두번째로, 한 팀에는 하나의 프로젝트만 있어야 하고 그 프로젝트는 같이 진행해야 한다. 팀이 파편화되는 것을 막아야 하기 때문이다. 모두 다른 곳에 정신이 팔려 서로 무슨 일을 하는지 모르고 있다면 그곳에서부터 그 팀은 더이상 팀이 아니라 그저 인간들의 집합체가 되고 만다. 팀원들과 같이 프로젝트 밑바당 설계부터 같이 해보자. 새로온 팀원 이라고 해서 그들에게 단순히 업무를 배정하는 식으로 프로젝트가 진행 되서는 안된다. 개발자는 항상 새롭고 흥미로운 것을 찾아 해매는 사람들이고 그들이 흥미를 잃는 순간 프로젝트가 끝나자마자 그들은 새로운 직장을 찾아나갈 것이다. 사람을 새로 구하는 데에는 어마어마한 비용이 든다는 것을 무시하면 안된다.
밑바당부터 같이 참여해 프로젝트를 진행한다면, 프로젝트는 팀원들의 창작물이 되고 자연스럽게 주인의식이 싹트게 된다. 팀원이 주인이 되는 프로젝트는 팀원이 버릴 수 없다. 자신이 애지중지 키운 프로젝트이기 때문이다. 따라서 문제가 있으면 나서서 고치고, 문제가 없으면 더 나은 방법이 없을까 고민하게 된다. 새로온 팀원이 있다면 그동안 고민했던 설계에 관한 이야기부터 그동안 겪은 문제에 대해 같이 식사를 하며 얘기해보자. 그러던 중 새로온 팀원이 공감할 수 있는 얘기가 있다면 팀원은 바로 자신이 기여할 수 있는 부분을 빠르게 찾을 것이다. 개발팀에 있는 모든 팀원은 스스로 문제를 찾을 때 행복감을 느낀다는 것을 다시 생각하자.

Discussion (0)

pic
Editor guide