[개발 문화] 2. 팀워크를 이끌어내는 방법 (어떻게해야 팀의 능률을 향상시킬 수 있는가?)

🤔 이게 소프트웨어 엔지니어링과 무슨 상관이죠?

이 포스트의 제목을 보시게되면 팀워크 에 대한 내용을 다룬다는걸 짐작하실 수 있을겁니다. 그런데 누군가는 이런 생각을 하시게 될지도 모릅니다.

🤔 소프트웨어 엔지니어링과 팀워크가 관계가 있는거에요?

이전에도 말씀드렸다시피, 소프트웨어 엔지니어링이란 프로그래밍에 덧붙여서 비용(Cost) 까지도 포함하는 개념입니다. 팀워크또한 개발 과정에 있어서 개발 속도, 팀원들의 능률을 좌지우지 가능한 요소이기 때문에 팀워크도 소프트웨어 엔지니어링의 일부라는 것이 저의 생각이기도합니다.

본격적으로 팀워크를 향상시키는 방법에 대해서 소개를 드리겠습니다.

😭 제 코드는 너무 보잘것 없어서 여러분께 공개해드리기가 싫습니다.

이번 단락에서 다루는 내용은, 자신의 코드에 대한 불안감 입니다.

여러분들은 팀에서 협업하지 않고 개발해본 경험이 한번씩은 있을겁니다. 또한 혼자서 개발해보다가 어느 순간부터 팀에서 협업을 시작한 경험또한 필연적으로 있을겁니다. 그리고 협업에 익숙치않다면 개발을 하다가 이런 경험이 한 번씩은 있으실수도 있을겁니다.

🥲 제 코드는 나중에 리뷰해주면 안될까요? 아직 여러분께 보여드리기에는 많이 모자랍니다. 추가 개발해야할 것도 너무 많구요.

물론 저도 사람이기 때문에 저런 생각을 가진적이 많고, 또한 무의식에도 저런 생각이 남아있기 때문에 저또한 현재진행형입니다. 그러나 저렇게 자신의 코드를 하나둘씩 은닉하기 시작한다면 나중에 커다란 문제를 초래하게됩니다. 그리고 이러한 불안감은 나중의 더 큰 문제의 씨앗이 되기도합니다.

우선 개발자들 사이에 만연해있는 천재 신화 에 대해서부터 짚고 넘어가겠습니다.

1️⃣ 천재신화

많은 개발자들 사이에서는 천재 신화라는 것이 많이 퍼져있는게 현실입니다. 예를 들면 이런것들이 있을 수 있겠네요.

• 파이썬의 창시자 귀도 반 로썸은 휴가 가서 심심해서 만든 언어가 파이썬이라더라.
• 리누스 토르발스는 혼자서 리눅스를 만들었다더라.

물론 저 사람들이 대단한게 맞습니다. 저도 그건 부정하고싶지는 않습니다. 그러나 여러분들이 아셔야할 것은, 리눅스 그리고 파이썬은 절대로 개인이 완벽하게 만든것이 아니라, 협업의 결과로 탄생한 작품 이라는 것입니다.

파이썬은 분명히 귀도 반 로썸이 첫번째 버전을 작성한건 사실입니다. 그러나 그 이후의 버전들은 수천 명의 개발자가 붙어서 개선하고, 기능을 추가하고, 버그를 수정하는 과정을 거쳤을겁니다.

왜 사람들은 이러한 천재신화에 열광을 하고, 이러한 천재들을 우상화하게 되는걸까요? 사람들은 본능적으로 자신이 되고싶은 사람, 소위 말하는 롤모델을 따라하고 흉내내고 언젠가는 저기에 도달하고 싶다는 목표를 세우게됩니다. 특히나 이는 프로그래밍 세상에서 기술 전문가 셀럽 현상 으로 등장합니다.

많은 사람들은 또한 자신이 천재로 비춰지기를 열망할지도 모릅니다. 하지만 현실을 직시해볼 필요는 있습니다. 대부분의 사람은 절대로 천재가 아닙니다. 저또한 천재가 아닙니다. 그저 열심히 코딩에 대해서 공부를 하는 일개 평범한 사람에 불과하지요. 내가 천재였으면 의대에서 해부학 수업을 듣고있었겠지...

그러나 걱정할것은 없습니다. 앞에서 말씀드렸다시피 대부분의 사람은 절대로 천재가 아닙니다. 그리고 현재의 시대는 천재 한명이서 뭔가를 이루기에는 이미 개발의 규모는 많이 커져있고, 그리고 많이 복잡해져있는게 현실입니다. (특히 대부분의 백엔드 서비스는 현재 MSA를 기반으로 돌아가기 때문에 그렇기도하죠)

그렇기 때문에 이 책에서 말하고 있는것은 최고수준의 프로그래밍 실력이 소프트웨어의 성공을 보장하지는 않지만, 협력은 소프트웨어의 성공 확률을 높여준다 라는 것입니다. 따라서 천재신화를 가지고 괜히 겁을 먹을 필요도 없다는 것이 이 책에서 말하고자 하는 바입니다.

2️⃣ 부끄럽다고 숨기는 것이 더 해롭다

이 단락의 결론부터 먼저 말하자면, 만약에 여러분이 오롯이 혼자서 일한다면 실패할 위험성을 불필요하게 키우고 있는 것이며, 또한 자신의 성장 잠재력을 속이고 있는걸지도 모른다는 것입니다.

일단 가정부터 깔고 시작하겠습니다. 여러분이 만약에 위대한 아이디어를 가지고 구현함에 있어서 그것을 완벽하게 코드를 깎을때까지 아무도 들여다보지 못해게 github repository를 private으로 맞추고 누구에게도 공개를 하지 않는다고 가정을 하겠습니다.

그러나 이 행위는 매우 위험한 도박에 가깝습니다. 개발은 초기 설계가 잘 되어있어야만 이후에도 개발의 방향이 잘 잡히는 법이지만, 초기 설계에 결함이 존재한다면 그 초기설계를 기반으로한 수많은 코드들을 뜯어야할수도 있습니다.

그렇기 때문에 개발을 진행함에 있어서 조기 피드백이라는 것은 매우 중요한 존재입니다. 따라서 이러한 관점에서라도 자신의 코드를 부끄럽다고 숨긴다면 실패의 위험성을 실시간으로 키우고 있는걸지도 모른다는 것입니다. 또한 자신의 코드가 결함 투성이임에도 불구하고 나의 코드는 완벽할거야 라는 착각을 불러일으켜서 자신의 성장을 가둘지도 모릅니다.

3️⃣ 혼자 개발하는건 끔찍한 일이다

이 부분은 저의 경험을 섞어서 이야기를 드리도록 하겠습니다.

저는 올해 3월까지만해도 백엔드 라는 것을 혼자서 공부하고, 혼자서 개발하고, 혼자서 강의를 찾아들었습니다. 게다가 주변에는 백엔드를 하는 사람들 또한 존재하지 않았거나, 혹은 있었더라도 직장인이었기 때문에 피드백을 받을 여건이 저는 존재하지 않았습니다.

그러나 우연찮게 올해 3월 초에 백엔드를 하고있던 분과 같이 협업을 하게될 기회를 가지게되었고, 협업을 하는 과정에서 저는 다음의 감정을 느끼게되었습니다.

• 나는 우물 안의 개구리에 불과했다. 백엔드의 세상은 내 생각보다 훨씬 복잡한 세상이었다
• 생전 처음 들어보는 단어들을 갑자기 접하니까 진짜 어지럽다 ㅠㅠ

그렇게 저는 그 분으로 부터 인사이트를 얻어서 MSA라는 것에 대해서 본격적으로 고민하게 되었던 것 같습니다.

이 단락에서 말하려고 하는것은 위에서 언급한 저의 경험과 일맥상통합니다. 혼자서 일하는거는 일단 아래의 두가지 문제를 야기합니다.

1. 개발이 진짜 느리다. 너무 기대 이상으로 느리다.
2. 공동의 지혜라는 이점을 버리고 시작한다.

게다가 더더욱 큰 문제는, 나의 개발 방향이 틀리더라도 주변에서 해법을 알려줄 사람도 없다는 것입니다. 그렇기 때문에 울릉도로 가야할 배가 마치 목표하지도 않은 일본으로 향하는 것처럼 나의 코드또한 엉뚱한 방향으로 향할 수 있다는 것입니다. 그러다가 내 코드가 침몰할지도..?

개발자들 사이에서 유명한 말이 있습니다. 눈이 많아야 프로젝트가 탈선하지 않고 옳은 방향으로 나아간다 라는 것인데요, 그 만큼 보는 시야가 많아야만 프로젝트의 빠른 즉각적인 피드백이 가능하고, 또한 잘못된 개발로 인한 cost를 많이 줄일수있습니다.

4️⃣ 결론적으로는, 내 코드를 숨기지말자.

결론적으로는 나의 코드를 많은 이들에게 오픈하거나, 혹은 팀원들에게 오픈하여 빠르게 피드백을 받고, 그리고 빠르게 옳은 방향으로 수정을 해야만 나의 프로젝트가 먼 산으로 향해버리는 일을 방지할 수 있을겁니다.

🔥 개발자는 실력이 전부가 아니다.

우선 이 단락에 대해서 설명하기 이전에 제가 흥미롭게 보았던 문구를 하나 소개시켜드리겠습니다.

위의 문구는 배달의 민족에서 제시하는 일을 잘하는 방법 11가지 중의 1가지입니다. 흔히 말하는 스몰토크의 힘이라는 것인데요, 이를 배달의 민족이 내걸고있다는 뜻은 개발자는 실력이 전부가 아니라, 사회력또한 개발자의 덕목중 하나이다 라는 것을 말하는걸지도 모르겠습니다.

이 책에서도 사회적 상호작용을 매우 강조하고 있는데요, 하나씩 짚어보겠습니다.

1️⃣ 사회적 상호작용의 세 기둥

우선 사회적 상호작용의 세 기둥에 대해서 언급하고 시작하겠습니다.

1. 겸손

• 당신은 절대로 완벽하지 않고, 모든걸 알지도 못합니다. 겸손한 사람은 배움에 열려있습니다.

2. 존중

• 팀원들에게 친절하게 대하고, 그들의 능력과 성취에 감사하십시오.

3. 신뢰

• 동료들이 유능하고 올바른 일을 하리라 믿으십시오.

이제 사회적 상호작용의 세 기둥을 알았으니, 이를 실천하는 방법을 구체적으로 리뷰해보겠습니다.

2️⃣ 쓸데없는 자존심은 개나 주자.

여러분들은 겸손함 없이 상대방의 화를 제일 빨리 돋구는 방법을 알고계신가요? 그 정답중 하나는, 자신이 모든 것을 꿰뚫고 있고, 모든걸 알고있고, 그리고 여기서 가장 중요한 인물처럼 행동을 하면됩니다. 특히나 능력도 없는데 저러면 팀원들은 이렇게 생각할지도 모릅니다.

😡 저 놈은 지만 잘난줄알아 ㅡㅡ

만약에 팀원중에 저런 사람이 있다면 분명 다른 팀원들은 위와 같이 생각하면서 절대로 좋아하지 않을겁니다. 설령 자신이 팀원들 중에서 가장 현명하고 인사이트가 제일 깊다고 확신이 들더라도 그런 속내를 절대로 드러내서는 안됩니다.

그러나 겸손은 매우 중요하지만, 절대로 바싹 엎드리라는 것은 아닙니다. 할 말은 하고 살아야죠. 그러나 그저 모든걸 다 안다는듯이 행동해서는 안된다는것을 말합니다.

그러나 다음과 같이 행동하면 팀의 능률을 올릴수 있을지도 모릅니다. 자신이 잘 아는 분야에 대해서 팀을 의심하기 보다는 팀의 성취와 자부심을 높이려 노력을 하는겁니다.

3️⃣ 비평하고, 비평받는 방법을 배우자 (자존심을 적당하게 내려놓는 방법을 배우자)

이 단락은 코드리뷰를 대하는 자세와도 연관이 깊습니다. 이 단락에서는 제가 상담사 경력 1년 동안, 그리고 팀에서 코드리뷰 문화를 접하면서 알아낸 사실들을 좀 참조해서 적도록 하겠습니다.

하나의 상황을 가정하겠습니다. 새로운 팀원이 들어와서 기존의 한 팀원에게 아래와 같이 피드백을 주었다고 합시다.

🤔 왜 Presentation Layer에서 Data Access Layer로 2단계 하향 참조를 하고 계시는거죠? 그거 잘못된 참조인거 몰라요? Implementation Layer는 왜 존재한다고 생각해요? 그러면 왜 Implementation Layer에 해당 logic을 구현하지 않고 Presentation Layer에서 작성하고 계시는거죠? 당장 고쳐요.

위의 피드백에는 문제점이 꽤나 많습니다. 문제점을 하나하나 열거하겠습니다.

1. 피드백에 감정이 실려있다. 공격과 비평은 엄연히 다른 개념이다.
2. 타인이 잘못됐다고 말을 하고있다. 이는 말에 공격성을 추가시킨다.
3. 무언가를 고치라고 요구하고있다.
4. 상대방을 지적함에 있어 '왜' 라는 단어 선택은 굉장한 공격성을 가진다.

첫번째로 공격과 비평 의 차이에 대해서 말하고자합니다. 건설적인 비평의 경우 프로젝트에 도움이 되며 개선을 위한 지침을 팀원에게 부여할 수 있습니다. 그러나 팀원을 공격하는 경우 공격 과정에서 개선점을 포함한다고 할지라도 팀원에게는 도움이 되지못합니다. 오히려 화만 돋궈서 쓸데없는 코스트를 불러일으킬 뿐이죠.

여기서 중요한 점은, 건설적인 비판은 상대방을 진심으로 생각하고 상대방의 업무가 개선되기를 바래야한다는 것입니다. 위와 같은 피드백은 상대를 진심으로 생각하지도 않고, 상대방의 업무가 개선되기를 바라기는 커녕 감정을 토해내는 행위밖에 더 되지 않습니다.

두번째, 타인이 잘못됐다고 말하는 행위는 사회적 상호작용의 세 기둥 중 첫번째인 겸손에 반하는 행위입니다. 위와 같은 발언을 들은 사람은 무의식적으로 방어태세를 취하게 되어있습니다. 그리고 그러한 무의식적 방어태세로 인해서 상대방의 말을 무시하거나, 혹은 감정적으로 대응할 수도 있을겁니다.

따라서 잘못된 행위가 발견되었다고 할지라도, 직설적으로 말하는 것 보다는 완곡하게, 그리고 돌려서 개선책을 제시해주는 것이 바람직할겁니다.

따라서 위와 같은 피드백은 아래와 같이 수정되면 그나마 나은 피드백이 될겁니다.

🤔 보니까 Presentation Layer에서 Data Access Layer의 클래스를 참조하는 부분이 하나 발견됐더라구요. 물론 이렇게 해도 동작은 되겠지만 Implementation Layer에 코드를 옮겨서 그거를 Presentation Layer에서 참조를 해주면 추후에 유지보수에 있어서 편리성이 증대될지도 모르겠네요!

위의 피드백 핵심은, 개선책을 제시하고있지만 자기 자신을 낮췄다는데서 차이점을 보입니다. 여러분들이 보시기에도 위의 피드백이 나아보일겁니다.

그리고 반대로, 자신또한 피드백에 열려있어야합니다. 제일 좋은 방법은, 자신을 자신의 코드와 동일시 하지 않을것 입니다. 그렇게 생각한다면 쓸데없는 자존심을 굽히는데 도움이 될겁니다.

4️⃣ 비난이 없는 포스트모템 문화

구글에는 포스트모템 문화가 존재합니다. 이는 실패한 근본 원인을 분석하여 문서로 남기는 문화 를 의미합니다. 실패를 제대로 기록해두면 나중에 다른 사람이 같은 실수를 반복하지 않는데 도움을 많이 줍니다.

포스트모템은 다음 내용이 담겨야합니다.

• 사건의 개요
• 사건을 인지하고 해결하기 까지의 타임라인
• 사건의 근본 원인
• 영향, 그리고 피해에대한 평가
• 문제를 즉시 해결하기 위한 조치 항목
• 재발 방지를 위한 조치 항목
• 교훈

5️⃣ 구글답게 행동하자 (Act Googley)

구글에서 정의하는 구글다움(Googleyness)는 아래와 같이 정의되어있습니다.

• 모호함을 뚫고 번창하라
  끊임없이 변화하는 환경 속에서도 상충하는 메시지와 방향에 잘 대처하고, 합의를 잘 이끌어내고, 문제에 대한 진전을 이루어내자
• 피드백을 소중히 하여라
  피드백 과정에서 품위와 겸손을 유지하고, 피드백의 가치를 인정해라
• 저항을 극복하자
  다른 팀원들이 저항하거나 관성 때문에 움직이지않으려 한다고 하더라도 야심찬 목표를 세우고 굳게 나아가라
• 사용자를 우선하여라
  구글 제품의 사용자 입장에서 생각하고 존중하고, 사용자 경험에 도움이 되는 행동을 추구해라
• 팀에 관심을 기울여라
  동료들의 입장에서 생각하고 존중하며, 팀의 결집을 위해서 누가 시키지 않더라도 적극적으로 도와라
• 옳은 일을 하여라
  모든 일에는 윤리의식을 가지고 행하여라.

🌲 글을 마치며

책을 읽고 글을 쓰다보니 저 또한 고쳐야 할 점이 많이 보이는 것 같습니다. 저 또한 코드리뷰에 있어서 타인의 잘못을 지적하고 고치기를 강요한 적이 있었기 때문이죠.

이 포스트가 여러분께 많은 도움이 되셨기를 바랍니다.

다음 포스트에서는 지식 공유 문화에 대해서 다뤄보겠습니다. 다음 포스트에서 뵙겠습니다!