물과 기름같은 개발자와 경영자 관점에 대한 이야기 1편
창업은 절벽에서 뛰어내린 채 비행기를 조립하는 일과 같다.
뛰어내린 뒤에야 조립 순서를 모른다는 것을 알게 된다
링크드인 공동 창업자 리드 호프먼
스타트업의 시작은 누군가가 절벽에서 뛰어내리자고 소리를 치며 시작됩니다. 대게는 그 사람이 대표가 되며 경영의 길로 들어서게 되죠. 어떤 비행기를 만드느냐에 따라 다르겠지만 IT 스타트업의 경우, 개발자는 가장 빠르게 확보되어야 하는 KeyMan입니다. 그 둘 사이의 관계가 어떻게 형성되냐에 따라 비행기가 외형을 갖춰가며 성장을 할 수도 있고 추락할 수도 있습니다.
오늘은 스타트업에서 개발자와 경영자의 관계에 대해서 한번 생각해보며
1편: 어떠한 점에서 본질적인 차이를 보이는지
2편: 어떻게 해야 상호보완적인 관계를 형성할 수 있을지
정리해보고자 합니다. 특히 요즘은 개발자 Base의 경영자가 많은만큼 완벽하게 배타적으로 경계를 나눌 수 없는 경우도 많지만, Tech 이해도가 낮은 경영자와 사업경험이 없는 개발자들의 이야기로 생각하면서 읽어봐주시면 좋겠습니다.
1편: 왜 경영자와 개발자는 물과 기름 같을까?
A. 구름 위를 떠다니는 경영자, 땅에 발을 붙이고 있는 개발자
- 개발은 가장 현실적인 것들의 집합체입니다. 어떠한 감정의 동요도 없이 조건과 input에 따라 output이 결정됩니다. 개발자는 땅에 발을 붙인 채 현실적인 것을 고민하는 사람이라 볼 수 있습니다.
- 반면에 경영자는 자꾸 안되는 걸 하자고 하죠. 어디서 새로운 아이디어를 가져오구요. 개발자 입장에서는 5살 아이가 와서 할 것 같은 쌩뚱맞은 질문을 합니다.
새는 어떻게 날아요?
- 질문 자체가 두루뭉술해서 답하기 어려울 때도 있고 질문은 명확하나 이해하는 사람의 수준으로 어떻게 답을 해야 할지 난해해서 어렵습니다.경영자는 자꾸만 현실과 동떨어진 미래의 것, 손에 잡히지 않는 것에 대해서 줄줄 늘어놓습니다.
- 이들이 각각 뿌리 내리고 있는 현실과 꿈 사이의 괴리만큼 서로를 이해하기 어렵게 됩니다.
B. 어떻게 두가지 일을 동시에 하죠? (Context Switching 능력의 차이)
- 컴퓨터 관련 전공자들에게 가장 악명높은 수업은 단연 OS(Operating System)일 것입니다. 쉽게 말해서 컴퓨터 자원을 효율적으로 관리하기 위한 시스템을 의미하는데요. OS에서는 CPU가 여러가지 업무를 수행하기 위해서 반드시 기존의 프로세스 상태를 저장하고 다음 프로세스의 값으로 교체하는 작업이 발생하는데 이를 Context Switching이라고 합니다.
- 이를 업무환경에 적용해보면 성격이 다른 형태의 업무로의 전환을 Context Swiching이라고 볼 수 있습니다.
- 경영자들의 Context Switching은 시시각각 발생하며 대부분은 이를 빠르게 대처하는 편입니다.(물론 아닌 경우도 매우 많습니다만) 맡고 있는 업무의 범위가 넓을 뿐만 아니라, 많은 사람과 소통해야 하고 대외적인 채널을 대부분 담당하기 때문에 필연적으로 발생하고 이를 자의적으로든 타의적으로든 극복하며 Swiching 비용을 절감하는 법을 터득하게 됩니다.
- 반면에 개발자들은 Context Switching에 많은 에너지를 소비하게 됩니다. 여기서 많은 오해가 생길 수 있습니다. 어차피 개발이라는 범주 안에서의 업무끼리 전환하는 것인데, 왜 Switching이 더 어렵다는 것일까요?
개발이란 수 많은 변수명과 함수들, 논리적 흐름 전개와 이를 추상적으로 구현해놓은 알고리즘 등 필요한 정보를 생성한 다음 몰입을 하며 이를 구현해가는 과정입니다.
- 개발과정에서 단 하나의 오타가 전반적인 시스템에 영향을 미치기도 합니다. 그렇기에 더더욱 집중력을 위해 몰입하는 환경을 요구하는 것이 개발자입니다. 이러한 몰입 과정이 누군가의 방해로 깨지게 되면 알코올처럼 한순간에 증발하기도 합니다.
- 따라서 외부의 환경에 의해 발생하는 인터럽트(interrupt)에 굉장히 취약하고, 훈련도 덜 되어 있는 편입니다.
C. 왜 만들어야 하는지 알려주세요!
- 대게는 경영자에게 동기부여가 더 빠르고 강하게, 그리고 자주 발생합니다. 끓는점이 낮은 경영자는 하루 빨리 프로덕트가 완성되었으면 하고, 느릿느릿한 개발자가 답답하기만 하죠.
- 반면에 개발자는 끓는점이 높습니다. 스타트업에서 본인의 역할을 제대로 하는 유능한 개발자의 경우 특히 “왜 이 일을 해야 하는지”에 대해 설득을 요하는 경우가 많습니다. 도대체 왜 만들어야 하는건지를 경영자가 더욱 섬세하게 알려주기를 바라지만 서로의 온도 차이를 좁히기가 그리 쉽지는 않습니다.
- 그러다보면 같은 비전과 목표를 바라보고 있음에도 불구하고 어느새 서로의 전문 영역을 침범하며 신경전을 벌이기도 하고, 수직적인 관계가 표면 위로 떠오르면서 만들라고 해서 만들어야 하고, 하라고 해서 해야 하는 상황이 벌어집니다.
- 또한 반대의 경우도 발생하는데, 완벽함을 추구하는 개발자의 경우 향후 발생할 수 있는 오류 상황에 대비하거나 확장성을 고려하며 개발을 진행하다가 왜 프로젝트의 방향성에서 엇나가고 있냐는 경영자의 질타를 받기도 합니다.
- 일을 하다 보면 어느 순간 우리가 같은 프로덕트를 만들고 있는게 맞나 싶은 의문이 들 때도 있습니다. “답답하면 니들이 뛰던가” 라는 말을 한켠에 떠올리는 순간이 몇번씩 찾아옵니다.
D. 생산성 측정의 어려움
- 모든 경영자는 생존을 걱정합니다. 생존이란 결국 당장 먹고 살 수 있는 돈이 있는가와 그 돈을 써가며 만드는 프로덕트가 미래에 먹거리를 가져다 줄 것인지에 따라 결정됩니다. 정말 운이 좋게 전폭적인 지원을 받으며 팀이 결성되는 경우도 있지만, 대부분은 한정된 자원(돈과 비용)으로 시작하기에 보릿고개 같은 궁핍함은 한겨울의 칼바람같이 경영자에게 다가옵니다.
- 어느정도 보릿고개를 넘어서 팀의 규모가 갖춰질 때도 마찬가지입니다. IT 스타트업에서 대부분의 비용은 인건비에 해당하므로, 과연 이 팀을 이 비용으로 운영하는게 과연 적절한지에 대해 끊임없이 고민하게 됩니다.
- 필자는 증권사 프론트에서 퀀트로 일한 적이 있는데, 거기서는 대부분의 사람이 오후 4시 PL(Profit & Loss)이 찍히게 되기에 정확한 퍼포먼스 측정이 가능합니다. 그 사람의 비용인즉슨 연봉이고, 오후 4시가 될때마다 얼마를 벌었는지가 명확하게 찍히기 때문입니다. 반면에 개발자의 경우 생산성을 하나의 지표로 표현하기 쉽지 않습니다. 단순 생산성으로 보자면 형상관리에서 볼 수 있는 다양한 숫자가 있지만, 코드의 양이나 처리하는 issue, PR 만으로 절대 객관화 할 수 없기 때문입니다.
- 가장 좋은 것은 애초에 측정이 필요없는 최고의 인재들로 팀을 꾸리는 것이지만, 그런 사람을 찾기도 어렵고 해야 하는 업무가 많아지면 자연스럽게 팀 규모가 증가하고 개발자간 생산성 차이가 발생하게 됩니다.경영자는 이렇게 쉽지 않은 문제를 본인들의 노하우나 관점으로 측정하려 하고, 명확하지 않은 축을 기반으로 한 생산성 측정에는 서로간 오해할 수 있는 여지가 충분히 존재하게 됩니다.
결론
- 지금까지 여러팀을 경험해 보면서 개발자를 완벽하게 이해해주는 경영자 혹은 경영자를 완벽하게 만족시켜주는 개발자란 유니콘 같은 존재인 것 같습니다.
- 같은 회사에서 동일한 목표를 바라보고 함께 일을 하지만 개발자와 경영자의 본질적인 차이에 대해서 서로 명확하게 깨달아야 합니다.
- 세상에는 수 많은 팀이 있기에, 훨씬 더 많은 경우의 수로 서로 다름이 존재할 것입니다. 하지만 정확한 병명을 알아야 치료를 할 수 있듯이, 본인이 속한 팀이 어떠한 이유로 이질적인 면을 보이는지 명확한 사실인지만이 협업의 길로 나아갈 수 있습니다. 더 나아가서는 힘을 합쳐 원팀이 되어야만 험난한 스타트업의 세상에서 생존할 수 있습니다.
- 팀민트에서 겪은 개발자/경영자의 입장 차이와 커뮤니케이션 문제를 어떻게 극복해나가가고 있는지, 어떻게 서로 보완해가고 있는지 다음 편에서 정리해보도록 하겠습니다.
