화성에서 온 개발자, 금성에서 온 경영자 (2)

1편: 화성에서 온 개발자, 금성에서 온 경영자(1)

1편에서 개발자와 경영자가 왜 서로를 이해하기 힘들어하는지, 본질적인 차이점을 짚으며 설명을 하였습니다. 팀민트에서는 두 그룹이 어떻게 좀 더 가까워지는 시도를 하고 있는지 살펴보도록 하겠습니다.

2편: 경영자와 개발자의 간극 극복하기

A. 넘칠 정도의 커뮤니케이션 시간 확보

• 매일 한두시간씩 전화/카톡을 하는 연인을 한번 떠올려보겠습니다. 매일을 연락하는데 무슨 별다른 일이 있을까 싶지만 애정전선이 그렇게 순탄하게 유지되지 않는다는 것은 여기 계신 분들 다 아실겁니다. 실제로 연인들은 매일매일 서로의 일상과 생각을 공유합니다. 그럼에도 불구하고 항상 싸움의 불씨가 어디선가 피어나고 오해할 일이 생기고 서운한 감정이 들곤 합니다.
• 출근해서 자리에 앉아 8시간 근무를 한다고 하면, 우리는 얼마나 많은 시간을 커뮤니케이션에 할애하고 있을까요? 매일 수행해야 하는 고단한 루틴 업무와 대외미팅, 쏟아지는 문서 작업에 대부분의 시간을 할애한다면 우리는 얼마만큼의 대화를 하고 있는 것일까요? 대화는 협업의 가장 기본적인 것임에도 불구하고 대화를 업무로 생각하는 회사가 있나요?
• 팀민트에서는 커뮤니케이션 시간을 다량 확보하는 것이 굉장히 중요하다고 생각합니다. 회사 커뮤니케이션 룰 중에는 잡답은 경쟁력이다. 잡담을 적극 권장한다 문장도 있습니다. 그렇기에 팀원과 커피를 마시러 가는 것은 업무를 하러 가는 것입니다! 팀민트는 경영자와 개발자를 막론하고 커피챗 / 식사시간 / 그외의 시간 등을 활용해 넘칠 정도의 커뮤니케이션 시간을 확보하려고 합니다. 그래도 부족한게 대화이더라구요

B. 같은 언어를 쓰기 위해 노력합니다

• 대화의 빈도도 중요하지만 방식도 중요합니다. 경영진과 개발진이 치열하게 논의를 하는 것이 프로젝트 관리일텐데요. 팀민트는 경영진이 요구한 간트 차트(Gantt chart) 형식으로 Todo / 프로젝트 진척을 의사소통하며 일정에 대한 조율을 이어갑니다. (개발팀 내부로는 스프린트 단위로 업무를 쪼개서 관리하고 있습니다) 또한 프로젝트에서 기준점으로 삼을만한 기능과 구현 목표 날짜를 마일스톤으로 지정합니다.
• 간트차트는 하나의 예시일 뿐 여기서 중요한 것은 개발자가 경영자의 언어로 쓴 내용으로 정리해서 문서로 써온다는 것입니다. 일반적으로 경영자의 방식은 광범위하게 조망하는 view를 가지고 있고, 개발자는 기술이나 구현 레벨에서 depth 있는 view를 가지고 있습니다. 이러한 관점의 차이는 같은 상황을 똑같이 바라보고 있음에도 불구하고 대화가 이뤄지지 않는 것처럼 보이곤 합니다.
• 팀민트는 경영진이 개발자에게 미리 어떠한 언어로 커뮤니케이션할 지에 대한 방식과 충분한 시간을 제공합니다. 개발자는 주어진 방식과 시간을 수용하여 경영진의 view에 맞게 대화를 이어갈 수 있는 준비를 미리 문서로 작성하고 준비합니다.
• ping-pong 시간이 더딘 것처럼 보일지라도 공통 언어를 쓰며 대화를 하게 되니 대화의 효율이 올라가고 서로 잘못이해하는 상황이 줄어들게 됩니다.

C. 변화를 시도하는 의견에 더 많은 힘을 싣는다

• 만약 경영진과 개발진이 어떠한 접점에서 첨예하게 의견이 대립한다면 어떻게 의사결정을 해야 할까요? 경영진의 의견을 개발진이 수용해야 하거나, 개발진의 의견을 경영진이 수용해야 하는 일방적인 프로세스로 의사결정이 이루어진다면 두 그룹은 영원히 평행선을 달리게 될 것 입니다.
• 가장 이상적인 것은 의견의 근거로 상대를 설득하는 것이지만, 본질적으로 다른 두 그룹은 근거조차 다른 관점으로 준비해오기 일쑤입니다. 이럴 때 과연 누구의 편을 들어야 할까요?
• 팀민트는 변화를 꾀하는 의견에 대해 더 많은 가중치를 부여합니다.
  • 새로운 시도를 꾀하는가?
  • 더 나은 내일을 만드려 하는가?
  • 실패를 두려워하기보다 도전하려고 하는가?
• 그렇다고 대답할 수 있는 의견이라면 동등한 수준의 반대 근거가 있다고 하더라도 우리는 일을 벌려보는 쪽으로 힘을 실어주고 있습니다.
• 성공할 지 실패할 지 두드려보는 것도 중요하지만, 일단 해보자는 마인드가 더 중요하다는 것입니다. 이러한 점은 경영자와 개발자 간의 본질적 차이를 넘어서서, 어떠한 방향으로 의견을 내는지에 대해 좀 더 주안점을 두고 생각한다고 볼 수 있습니다.

D. 멋있게 해결하기보다 빠르게 해결하는 것에 초점을 맞춘다

• 바둑을 정복한 AI 알파고에게 스타크래프트2를 학습시켰습니다. 게임에는 APM (Actions Per Minute)이라는 용어가 있는데 분당 명령 횟수라고 보시면 됩니다. 바둑을 정복한 구글 딥마인드 팀은 APM을 높게 허용할수록 AI에게 유리한 조건이라고 생각하고 승률이 올라갈 것이라고 생각했습니다.
• 바둑을 평정할 때 무한에 가까운 경우의 수를 학습시킨 것처럼 시간을 무한하게 잘게 쪼개고 더욱 섬세한 명령을 가할 수 있게 한것이죠. 하지만 놀랍게도 APM을 제한하자 AI의 승률은 더욱 더 올라갔습니다.
  
• 여기서 다른 점은 뭘까요? 바둑은 모든 경우의 수를 계산할 수 있는 closed form입니다. 단지 그 수가 너무 많을 뿐이죠. 정보는 모두 오픈되어 있습니다. 하지만 스타크래프트는 나의 정보만 보이고 어두운 맵 밖의 정보, 상대방의 정보는 보이지 않습니다. open form이라고 볼 수 있죠. 알 수 없는 정보로 가득찬 세상에서는 오히려 문제를 단순화(APM을 제한) 하는 것이 승률이 더 높아졌다는 것입니다.
• 개발중인 서비스를 세상에 내놓았을 때 성공한다는 결과값을 미리 알려주는 방정식은 존재하지 않습니다. 그럴 때 우리가 할 수 있는 것은 모든 경우의 수를 고려하는 것이 아니라, 최대한 문제를 단순하고 빠르게 해결하는 것입니다.
• 경영자 입장에서 “타 경쟁 서비스 대비 이정도의 솔루션은 별 의미가 없어요. 더 참신한 걸 만들어야 하는거 아니에요?” 라며 더 높은 퀄리티의 솔루션을 요구할 수 있고 개발자 입장에서도 “최신화된 기술 스택을 학습하고 적용해서 만들면 더 퍼포먼스가 훌륭한 솔루션을 만들수 있어요!” 라고 하며 고도화된 기술을 써보겠다고 요구할 수 있습니다.
• 여기서 중요한 것은 누가 맞냐가 아니라, “그래서 누가 어떻게 빠르고 쉽게 결과를 확인할 수 있는데?” 입니다.

1편에서 경영자와 개발자의 차이를 짚어봤고 2편에서는 팀민트가 어떻게 그 차이를 좁혀나가고 있는지를 말씀드렸습니다. 요지는 가장 기본(대화)에 충실하고, 의견 충돌이 있을 때 지킬 수 있는 공동선을 구축해가는 것입니다. 팀민트의 공동선을 가장 잘 표현하는 문장으로 이번 내용을 마무리 하도록 하겠습니다.

가장 두려운 것은 성공도 아닌 실패도 아닌 그저 그렇게 흘러가는 것이다.
차라리 빠르게 해보고 빠르게 실패하는 것이 낫다.

팀민트 대표 한만형