개발자가 모자라요(펌)

펌주소 : http://blog.wishket.com/514/

원본 출처 : http://goo.gl/ALAUU
원본 작성자 박영록씨의 동의 후 게재된 글입니다.

개발자가 모자라요

 

개발자라는 직업 특성상(?) 다양한 회사들을 만나고 다니다보니 꽤나 자주 들려오는 이야기가 있다. 개발자가 모자라요. 근데 이것도 크게 보면 두 가지 종류가 있다. 스타트업이 개발자를 제대로 구하지 못해서, 혹은 구한 개발자를 붙들어두지 못해서 개발자 공백 상태가 되는 경우. 그리고 또 하나는 개발팀을 그런대로 확보해놓았지만 그 개발팀의 생산성이 만족스럽지 않은 경우. 두 경우의 공통점도 있는데, 그건 개발자가 모자라는 것이 현상이지 원인이 아니라는 것이다. 그래서 https://twitter.com/pakyoungrok/status/296225395940921344 이런 트윗도 날렸었고. 근데 이 트윗에 대한 반응을 보면 주로 전자 쪽에 집중되는 것 같다. 물론 전자도 이미 SNS에서 여러 사람의 글로 화제가 되었고 심각한 문제임은 틀림 없지만, 이미 많은 사람들이 다루었으니 나는 오늘 후자 쪽에 초점을 맞춰보려고 한다.

좀 풀어서 설명하면 이런 경우다. 회사가 투자를 받거나, 혹은 매출을 내거나 해서 그럭저럭 유지가 되는 상황이라 개발자들 월급도 제대로 줄 수 있고, 개발자도 적지 않게 뽑아놓았다. 개발자의 머리 수는 적지 않다. 그런데, CEO를 비롯한 많은 부서에서 쏟아내는 요청들을 개발팀이 다 감당하지 못해서 여러 부서에서 한 목소리로 “개발팀이 안 받쳐줘서 아무 것도 못해요”라고 외친다. 개발팀도 매일매일 바쁘게 일하지만 밀려드는 일을 감당하지 못해 일을 해결하는 속도보다 쌓여가는 속도가 훨씬 높고, 개발 속도도 덩달아 점점 느려진다. 다른 부서들은 개발팀을 비난하고, 개발팀은 점점 방어적으로 변해간다.

이런 일은 회사 규모와 상관 없이 일어난다. 내가 아는 바로 6명 짜리 회사도 겪고 있고, 500명 짜리 회사도 겪고 있는 문제다. 사실 개발자 품귀현상 문제도 이 문제와 관련이 있다. 이런 회사는 개발자를 붙들어둘 수도 없고, 좋은 개발자를 데려올 수도 없기 때문이다. 다른 부서로부터 매일같이 비난의 눈초리를 받는 개발팀에 오래 머물고 싶은 사람이 누가 있겠는가? 밥줄 때문에 버티고 있는 것 뿐이지.

 

 

 

더 골(The Goal)

 

그럼 이 문제는 왜 일어나는가? 그리고 이 문제는 해결 가능한 문제인가?

물론 해결 가능하다. 이 문제는 이미 인류의 지성이 정복한 바 있는 문제다. 다만, 그 지성이 아직 충분히 확산되지 않았기 때문에 해결하지 못한 조직이 많은 것이다. 아, 그렇다고 이게 당신의 조직이 해결할 수 있는 문제라는 뜻은 아니다. 페르마의 정리는 이미 수학자들이 정복한 문제지만, 그렇다고 니가 그 문제를 풀 수 있는 건 아니지 않은가. 이 문제는 비록 해법이 쉽고 단순하지만 정말로 이걸 실행할 수 있는 조직은 극히 드물다. 뭐 그렇다고 실행 난이도가 엄청 높다거나 그런 건 아니고, 대개의 경우 CEO가 이런 변화를 받아들이지 못하기 때문이다. 에시당초 CEO가 이 문제에 대한 개념이 있으면 이런 문제는 발생하지도 않겠지.

그럼 그 쉽고 단순하다는 해답은 무엇인가? 더 골이다. 옛날 같으면 링크 걸어줬으니 책 읽어보셈, 하고 끝냈겠지만, 오늘은 시간이 많으니 좀 상세히 적어보려고 한다.

핵심은 병목자원 관리다. 병목자원이란 최종 제품으로 나오는 공정 중에서 생산성이 가장 낮은 공정이다. 이런 병목자원이 있을 때는 병목 자원을 중심으로 프로세스를 짜야 한다. 요는 병목자원에서의 시간 낭비를 제거하는 것이다. 낭비를 제거하는 건 당연하잖아 할 수도 있는데, 중요한 건 병목자원의 시간 낭비만 제거하는 것이다. 심지어 다른 공정에는 시간을 더 낭비하게 되더라도 상관 없다. 아니, 병목자원의 시간 낭비를 제거하려고 하면 거의 필연적으로 다른 공정에서는 낭비가 발생한다. 하지만 그래도 해야 한다.

낭비 제거의 포인트는 크게 두 가지. 하나는 병목자원이 대기하는 시간이 생기지 않도록 하는 것이고, 다른 하나는 병목자원에서 불필요한 일을 처리하지 않는 것이다. 이 두 가지를 충분히 해놓고 나서 병목자원의 생산성을 높이는 방안을 강구해야 한다. 이 두 가지가 안되면 병목자원을 확장해도 대개 소용 없다.

이 문제를 개발팀 문제로 치환해보자. 일단 개발팀이 안 받쳐준다는 이야기가 나온다는 것은 개발팀이 병목자원이라는 뜻이다. 사실 개발팀이 얽혀야 하는 대부분의 조직에서 병목자원은 개발팀이다. 개발자가 10명이든 100명이든 개발팀이 병목이 아닌 회사는 드물고, 또 개발팀이 병목이 아니라면 그 회사는 더 큰 문제가 있는 건지도 모른다. 그래서, 개발팀을 병목자원이라고 놓고 다시 문제를 보자.

 

 

병목자원의 시간을 어떻게 낭비하게 되는가

 

우선 개발팀이 어떤 식으로 시간을 낭비하게 되는지를 보자. 위의 두 가지 중 첫번째를 개발에 대입하면, 개발하기에 필요한 정보가 충분치 않아서 개발자가 개발을 진행할 수 없어서 답변을 기다리면서 대기하는 상태이다. 디자인이 늦게 오거나, 세부기획에 빠진 부분이 있거나, 요구사항이 불명확하거나 등등. 이 문제를 한 마디로 설명한다면 “완벽한 기획서가 존재하지 않기 때문”이다. 개발자의 책상 앞에 기획서를 수북히 쌓아놓지만 개발자는 그 기획서만으로 개발할 수 없다. 디테일은 늘 빠져있게 마련이다. 그럼 개발하면서 계속 이 기획을 낸 사람과 커뮤니케이션을 해서 필요한 정보를 공급 받아야 한다. 그런데, 그 기획자가 이 프로젝트만 하고 있고, 개발자 옆에 딱 붙어 있어서 필요할 때 바로바로 의문을 해결해줄 수 있으면 되는데, 그런 경우는 드물다. 기획이 CEO에서 나오는 경우도 있고, 기획만 전담하는 사람이 아니라 다른 핵심 업무가 있는 부서에서 나오는 경우도 많기 때문이다. 이를테면 영업 부서에서 영업에 필요한 기능을 개발팀에 요청한 경우를 보자. 영업팀의 요청사항이 자세할 리는 없다. 개발자가 보고 개발하다보면 계속 영업팀에 물어봐야 한다. 그런데, 영업팀이니까 영업하느라 바빠서 개발자의 질문에 바로바로 답해주지 못한다. 그럼 그만큼 개발이 늦어지는 것이다.

기획 전담팀이 있어도 마찬가지다. 개발팀의 생산성 문제가 대두된 상황이니만큼 기획자가 만든 기획서는 바로바로 개발되지 않을 것이다. 그럼 기획자는 시간이 남으니까 새로운 기획을 또 하게 되고 개발자의 책상에는 또 새로운 기획서가 쌓인다. 그럼 개발자 앞에 쌓인 재고가 늘어나니까 다른 부서의 요청들은 더 대기시간이 길어진다.

이런 문제를 제대로 이해하고 있는 사람은 드물다. 이를테면 이런 식이다. 개발자는 지금 주어진 기획서를 개발하느라 여념이 없다. 근데 기획서에는 지금 검색조건을 입력하는 인터페이스에 대한 설명이 부족하다. 그래서 개발자가 그 부분에 대한 설명을 기획자에게 요청하려는데 기획자는 다른 일 하느라고 답이 늦어져서 개발이 지체된다. 기다리다 못한 개발자는 다른 업무로 잠시 전환했는데, 그러느라 컨텐스트 전환 비용이 소모된다. 근데 그런 찰나 기획자가 찾아온다. 그래서 필요한 정보를 물어보려는데 기획자가 이미 개발된 기능 중에 하나를 다르게 바꿔달라고 한다. 어, 아직 유저한테 deploy되지도 않은 기능인데? 기획자가 생각이 바뀌었댄다. 온 김에 기획자에게 검색조건 인터페이스를 물어보려고 하니 그건 놔두고 일단 자기가 지금 요청한 거 먼저 해달라고 한다.

자, 여기서 기획자는 무슨 짓을 저지른 것일까? 일단 병목자원의 가동을 멈추게 만들었다. 개발자가 1시간 기다리면 전체 일정이 1시간 늦어진다. 기획자는 1시간을 놀든 하루를 놀든 개발자에게 필요한 정보만 제 때 주면 일정에는 영향을 미치지 않는다. 하지만 기획자는 자기가 개발되길 기다리는 시간이나 개발자가 필요한 정보를 얻기 위해 기다리는 시간이나 같은 가치라고 생각한다. 동등한 사람인데 시간의 가치는 같겠지. 하지만 두 사람의 시간의 가치는 같지 않다. 개발에 필요한 정보를 제때 공급하는 것이야말로 생산성의 핵심이다.

이것만이 아니다. 기획자는 아직 제품화되지 않은 기능의 수정을 요청했다. 제품화는 되지 않았지만 개발이 완료된 기능은 다른 말로 하면 병목자원을 한 번 통과한 기능이다. 그런 기능을 수정한다는 것은 앞서 병목자원을 통과한 시간을 그냥 낭비했다는 것이다. 제품화되서 사용자의 검증도 받기 전에 바꿔버렸다는 것은 불필요한 재고를 생산했다는 것이다. 심지어 그 재고를 생산하기 위해 병목자원의 시간까지 썼으므로 이 기획자가 낭비한 시간은 엄청난 것이다. 이것은 병목자원 낭비의 두번째 케이스다. 덤으로 새로운 재고까지 쌓아서 다른 재고의 리드 타임마저 떨어뜨렸다.

이처럼 별 것 아닌 것 같은 일상적인 기획자의 행동이 개발팀의 생산성을 크게 낭비한다. 이것이 “개발팀이 제 때 제 때 개발해주지 않아요”라고 불평하는 조직에서 일상적으로 일어나는 일이다.

 

 

병목자원의 시간을 낭비하지 않게 일하는 법

 

그럼 어떻게 일해야 병목자원, 곧 개발팀의 시간을 낭비하지 않게 할 수 있는가? 제일 중요한 것은 개발자는 기다리는 시간이 없어야 한다는 것이다. 이게 온전히 가능하려면 어쩔 수 없이 다른 사람이 기다려야 한다. 예를 들어, 기획팀이 A 프로젝트의 기획서를 개발팀에 넘겨준 상태라고 가정해보자. 개발팀은 다른 할 일들이 쌓여 있으니 이 기획서를 당장 수행할 수 없다. 그럼 기획팀은 손이 빈다. 이 때 손이 빈다고 다른 프로젝트를 시작하면 악몽의 시작이다. 이게 중요하다. 개발팀이 A 프로젝트를 시작하기 전까지 아무 것도 하지 말아야 한다. 설령 뭔가를 하더라도 개발팀의 작업 리스트에 또다른 리스트를 올려놓아서는 안된다.

그럼 개발팀이 A 프로젝트를 이제 시작했다고 해보자. 그럼 기획팀은 무엇을 해야 하는가? 마찬가지다. 아무 것도 하지 말아야 한다. 해야 하는 일은 단 하나, 개발팀의 요청에 신속하게 응대하는 것이다. 개발팀이 A 프로젝트를 개발하는데 도움이 되는 일 외에는 아무 것도 하지 말아야 한다. 물론 그러면 기획팀의 시간은 낭비된다. 하지만 이건 상관 없다. 전체 생산성에 영향을 주지 않기 때문이다. 전체 일정에 영향을 주는 요소는 오로지 병목자원의 시간이다. 이것이 핵심이다.

영업팀이나 CEO, 고객지원팀 등에서 요청하고 싶을 때는 어떨까? 마찬가지다. 개발팀이 개발을 시작하면 영업하러 나가지 말고 대기해야 한다. 안 그러면 당신이 요청한 기능은 영원히 완성되지 않을 것이다. 근데 여기서 하지 말아야 할 것 하나는 요청한 사람이 개발자를 재촉하러 오는 것이다. 개발자의 생산성을 심각하게 떨어뜨린다. 자신이 급할 때 개발자에게 가지 말고, 개발자가 필요할 때 가야 한다. 쉽게 말해서 개발팀에 기능을 하나 요청했고, 개발팀이 일단 그 기능을 개발하기로 OK했다면, 그 다음부터는 개발자가 호출할 때까지 얌전히 대기해야 하고, 개발자가 호출하면 즉시 응답해줘야 한다. 이게 제대로 되어야 병목자원 관리를 제대로 하는 팀이라고 할 수 있다.

아니 같은 인간인데 왜 개발자의 시간만 중요하냐고 항변할 수도 있겠다. 정치적으로 모든 사람의 시간은 동등한 가치가 있고, 경제적으로는 각자의 수입과 비례하는 기회비용으로 따질 수 있겠지만, 프로젝트의 관점에서는 병목자원의 시간은 비병목자원과 100배 이런 차이가 아니라 1과 0의 차이다. 비병목자원 수백 명의 시간보다 병목자원 한 명의 시간이 더 중요하다.

 

 

비병목자원의 활용

 

병목자원 관리의 첫번째 포인트가 대기시간의 제거라면, 두번째 포인트는 병목자원에서 불필요한 일을 제거하는 것이다. 불필요한 일은 두 가지다. 하나는 아예 할 가치가 없는 일이고, 또 하나는 프로젝트에는 필요한 일이지만 병목자원을 통과하지 않고 처리할 수 있는 일이다. 여기서 첫번째 아예 할 가치가 없는 일은 사실 해보기 전엔 알 수 없으므로 초점을 맞춰야 하는 것은 병목자원을 통과하지 않아도 되는 일을 식별해내는 것이다. 그러니까, 개발자가 안해도 되는 일은 최대한 다른 팀에서 처리해야 한다는 것이다. 이것도 두 가지 포인트를 잡을 수 있는데, 하나는 개발자가 어드민 시스템을 잘 만들어줘서 되도록 어드민 작업을 개발자의 도움 없이 할 수 있게 해주는 것이다. 물론, 개발자가 이런 어드민 시스템을 만들 시간은 줘야겠지. 또 하나는, 개발자가 하고 있는 업무 중에서 일반인(?)이 할 수 있는 업무는 최대한 다른 팀이 가져가는 것이다. 이건 창의력이 좀 필요하다.

전에 소셜커머스에서 일할 때의 예를 들면 이런 것이다. 소셜커머스에서 대개는 하나의 딜에 하나의 상품이 있지만, 여러 개의 상품이 있는 경우도 있고, 상품별로 가격은 다르게 책정할 수 있다. 그런데, 부가 옵션은 상품별로 붙일 수 없다. 그러면 이 딜은 현재 시스템으로 소화할 수 없고, 상품별로 옵션을 붙일 수 있는 기능을 개발해야 한다. 하지만 이런 종류의 딜은 드물기 때문에 이 딜 하나를 위해 시스템을 개발하기엔 다른 더 중요한 일이 너무 많고, 데이터베이스 설계도 유연하게 되어 있지 않아서 변경 비용이 크다. 이런 경우에 보통의 회사라면 그래도 개발자가 이 기능을 추가로 개발하도록 만들 것이다. 하지만, 그 때 내가 선택한 방법은 딜을 여러 개로 분리하는 것이었다. 아예 분리된 별개의 딜인 것처럼 올려서 처리해버리면 어드민에서 입력하는 사람은 좀더 일이 많아지겠지만, 개발 비용은 추가로 들어가지 않는다. 상품별로 링크를 걸어두면 되니까 딜 판매량에도 영향을 주지 않는다. 아마도 각 회사의 업무에 따라 이런 식으로 개발이 필요한 일 같지만 개발하지 않고 넘길 수 있는 경우가 아주 많을 것이다. 이런 방법을 찾아내는 것도 개발팀이 아니라 다른 팀에서 해주면 더욱 좋고.

이런 복잡한 일만 있는 건 아니다. 사소한 일도 도와줄 수 있다. 이를테면 기획팀이 할 일이 없다면 개발팀에 와서 개발자들이 하고 있는 잡무를 도와줄 수도 있다. 어찌되었건 비개발자가 1시간을 들여서 개발자의 1분을 절약해줄 수 있는 일이라면 뭐든지 팀에 보탬이 되는 것이다. 물론, 이렇게까지 할 수 있는 팀웍을 갖춘 팀은 매우 드물겠지.

 

 

일거리의 선별

 

자, 그럼 개발자의 시간 낭비를 최소한으로 줄이는데 성공했다. 다른 부서들도 모두 개발팀을 중심으로 사고하는데 익숙해졌고, 프로세스는 개발팀을 중심으로 돌아가기 시작했다. 그러면 산처럼 쌓여 있던 많은 일들이 착착 진행될까? 아닐 것이다. 여기서 하나 더 생각해야 할 것이 있다. 어떠한 개발자도 생각하는 속도보다 더 빠르게 개발할 수는 없다는 것.

이게 왜 중요할까? 그런 조직이 겪는 문제 중에 중요한 것은 개발팀이 할 일의 분량 자체가 너무 많다는 것이다. 부서마다 다 자신들의 아이디어를 쏟아내서 개발팀의 작업 큐에 쌓아버리면 어떤 개발팀도 감당할 수 없다. 생각의 속도는 엄청나게 빠른 반면, 개발 속도는 생각하는 속도의 수백 배에서 수백만 배로 느리기 때문이다. 그 어떤 개발자도 생각의 속도를 온전히 작업 속도에 반영할 수 없다.

그러므로 마인드 자체가 생각나는 아이디어를 모두 실행한다가 아니라 고도로 필터링하고 정제된 아이디어를 실행하는 것으로 바뀌어야 한다. 문제는 이것이 스타트업의 문화와 안 맞는 것으로 보이기 쉽다는 것이다. 스타트업에는 실행이 가장 중요하다. 떠오르는 아이디어를 열심히 정제하는 것보다 바로바로 실행에 옮겨서 반응을 보는 게 중요한 것도 사실이다. 그리고, proof of concept에 성공한 스타트업들도 아이디어를 정제하는데 많은 시간을 쓰기보다 바로바로 실행에 옮기는 것을 중시했다. 그럼 어떻게든 개발팀은 모든 부서의 아이디어를 실현할 수 있도록 병목자원의 생산성을 증가시켜야 하는 것 아닐까?

이것이 바로 proof of concept에 성공한 스타트업의 착각이다. 이런 말이 있다. 기업에서 가장 위험한 것은 왜 성공했는지 모르고 성공하는 것이라고. 떠오르는 아이디어를 바로 실행에 옮기는 것이 스타트업의 핵심 성공 요인임은 분명하다. 그러나, 그것만이 아니다. 그게 효과를 볼 수 있었던 것은 떠오르는 아이디어의 종류가 적었고, 모든 멤버들이 그 아이디어를 실행하는데 집중할 수 있었기 때문이다. 초기에는 모든 사람이 한 가지 핵심에 집중하게 마련이다. 그런 상황에서 나오는 아이디어 역시 잘 포커싱되어 있다. 그런데, proof of concept가 되고 매출을 성장시키기 시작한 회사에도 이 방식이 들어맞을 것인가? 당연히 불가능하다. 이제 사람 수도 많고 부서도 많고, 이해관계도 복잡하다. 당연히 이 많은 사람들에게서 나오는 요구들은 핵심에 잘 집중되어 있지도 않고, 아이디어의 종류도, 개수도 많다. 이 모든 것을 소화할 수 있는 개발팀을 구축하는 것은 이미 물리적으로 불가능한 상황이 된 것이다.

이런 상황에서 개발팀이 예전처럼 요청을 다 소화해주기를 바라는데 개발팀은 그렇게 할 수 없으니 “개발팀이 안 받쳐줘서 아무 것도 못해요” 같은 소리가 나오는 것이다. 개발팀이 안 받쳐주면 개발팀이 받쳐주는 만큼 일을 주어야 한다. 아니, 사실은 그보다 더 적게 주어야 한다. 그래야 스스로를 개선해가면서 개발 속도를 올릴 수 있기 때문이다. 그런데, 그런 점은 감안하지 않고 모든 부서에서 중구난방으로 개발팀에 요청을 쏟아내면 개발팀은 중요한 일을 구분할 수 없게 되고 점점 중요하지 않은 일에 시간을 소비하면서 중요한 일을 해내는 속도는 더 느려지는 것이다. 그러니까, 개발팀이 아무 것도 할 수 없게 만드는 건 바로 무작위로 요청을 쏟아내는 다른 팀들인 것이다.

그래서 정말 proof of concept 전처럼 기민하게 움직이고 싶다면 그때처럼 충분히 핵심에 집중할 수 있는 상황도 같이 만들어줘야 한다. 아이디어를 무작정 쏟아낼 게 아니라 잘 정제해서 꼭 필요한 일들만 병목자원을 통과시켜야 한다.

안타까운 일이지만 proof of concept도 하기 전의 스타트업들도 이런 식으로 무작위적인 아이디어를 쏟아내는 경우가 많다. 마치 개발자를 CEO의 아이디어를 실현해주는 사람 취급을 하는 것이다. CEO가 머리 속으로 이것저것 떠오르는대로 다 개발자에게 전달하면 아주 작은 팀도 위와 같은 문제를 그대로 발생시키게 된다. 아니, 사실 이 경우는 훨씬 심각하다. 성공할 가능성 자체를 낮춰버리기 때문이다.

린 스타트업도 기민하게 움직이기를 요구하지만 아무 아이디어나 생각나는대로 실행하라는 게 아니다. 치밀하게 가설을 세우고, 그 가설을 검증할 수 있는 작업만 하는 것이 린 스타트업이다. 가설을 검증하는데 도움이 되지 않는 일은 1그램도 하지 말아야 한다. 이런 린 스타트업의 방식을 유지할 수 있다면 기업이 작든 크든, proof of concept를 해냈든 아니든 기민하게 움직일 수 있다.

 

 

 

기능조직의 문제

 

그런데, 여기서 이런 일이 일어나는 좀더 근본적인 원인을 파고들어보고 싶다. 왜! 다른 조직들은 마치 개발팀의 생산성을 저하시키는 게 목표라도 되는 것처럼 행동하는가? 그들은 나쁜 사람들이라서? 아니면 머리가 나빠서? 단지 더 골을 읽지 않았기 때문에? 난 그렇게 생각하지 않는다. 역량의 차이가 크지 않은 팀의 경우에도 개발팀과 매우 조화롭게 협업해내는 경우가 많이 있다. 그리고 나는 개발팀이 안 받쳐줘서 아무 것도 못한다고 투덜대는 모든 회사들에게서 아주 강력한 공통점을 발견했다. 그것은 기능조직이라는 것이다. 더 많이 세분화된 기능조직일수록 이 현상은 더 심하다.

기능조직의 문제는 크게 두 가지다. 하나는 포커스가 안된다는 것. 기능별로 분리되어 있으니 개발팀은 여러 가지 업무를 맡게 될 수 밖에 없다. 한 개발자가 여러 업무를 맡게 되는 것도 이런 조직에선 자연스럽다. 그러니 개발자는 당면 프로젝트에 집중하기 어렵고, 개별 프로젝트에 대한 이해도도 떨어진다. 업무를 요청한 쪽도 마찬가지로, 개발팀이 지금 어떤 업무들을 하고 있는지 모르니까 자신들의 요청을 우선적으로 처리해달라고 요청할 수 밖에 없다. 그러니까 모든 부서가 다 자신들의 일을 최우선으로 해달라고 요구하게 되고, 그 중에 어딘가는 낮은 우선순위를 배정받을 수 밖에 없으니 개발팀의 퍼포먼스에 불만이 생기게 마련이다.

사실 기능조직은 회사의 규모와 상관 없이 지식노동을 하는 조직에는 적합하지 않다. 기능조직의 우수성이 입증된 사례도 거의 존재하지 않고, 이론적인 장점도 없는, 그냥 틀린 방식이다. IT 회사가 기능조직으로 일을 하고 있다면 경영진의 역량 부족이다.

목적조직에선 위에서 언급한 많은 문제가 저절로 해결된다. 영업부서에서 개발팀에 요청하는 게 아니라 영업부서에 개발자 한 명이 배치되어 있다고 생각해보자. 그리고 그 개발자는 영업부서의 업무만 처리한다. 그럼 이 개발자에게 과도한 업무가 쌓일 일도 없고, 서로 간에 업무 이해도도 높아지므로 개발자가 정보를 얻기 위해 대기해야 하는 시간도 줄어든다. 늘 붙어 있으니까 서로 기민하게 대응할 수 있다. 물론 이렇게 하면 개발자가 일이 없는 순간이 생길 수 있다. 그렇지만 그게 무슨 문제인가. 일이 없어서 노는 건 병목자원이 아니라는 이야기고 이건 문제 없다.

기획팀이 따로 존재하는 것이야말로 인간이 생각해낼 수 있는 최악의 조직 구조다. 마케팅 부서에서 새로운 마케팅을 한다고 가정해보자. 마케팅 부서에 담당 개발자가 있다면 그냥 그 개발자랑 계속 커뮤니케이션하면서 만들어가면 된다. 근데 기획팀이 따로 있으면 마케팅 부서에서 기획팀에 요구사항을 넣고 기획팀은 그 요구사항을 바탕으로 기획안을 만들어서 개발자에게 전달한다. 그러면 그 개발자는 개발하다가 의문사항이 생기면 또 기획자에게 물어보고 기획자는 다시 마케팅에 물어본다. 이런 복잡한 과정을 거쳐서 생산성이 날 리가 없지 않겠는가.

작은 스타트업에서도 이런 현상은 나타난다. 대기업에서 기능조직으로만 일해온 사람들은 5~6명 짜리 스타트업에서도 같은 방시으로 일하면서 기능조직의 문제점을 그대로 노출한다. 5명인데 팀으로 동작하는 게 아니라 따로따로 논다면 그 팀이 성공할 리 있겠는가.

기능조직은 당장 폐기해야 할 구시대의 잔재다. 설령 당장 바꿀 수 없다 해도 경영진이 의식을 가지고 외형적인 구조는 기능조직이더라도 목적조직처럼 일할 수 있게 서포트해야 한다.

 

 

 

개발자는 도구가 아니다

 

하지만 기능조직도 근본 원인은 아니다. 앞서 말한 것처럼 작은 스타트업도 기능조직처럼 일하는 경우가 많다. 왜 이런 현상이 생길까? 내가 보는 이유는, 개발자를 자신의 아이디어를 실현해주는 도구로 보기 때문이다. 개발자를 함께 회사를 이끌어나가는 동반자로 보느냐, 그저 내 아이디어를 실현해주는 사람으로 보느냐에 따라 일하는 방식이 결정된다. 개발팀이 안 받쳐줘서 뭘 못한다고 생각하는 것 자체가 개발팀은 자신을 받쳐줘야 되는 존재라고 보는 것이다. 그들은 개발팀이 겪고 있는 문제에 관심이 없다. 단지 자신이 요청을 실행해주느냐 아니냐에 따라 판단할 뿐이다.

병목자원 이론, 일거리 선별, 기능조직 등 구체적인 방안들을 이야기하긴 했지만, 사실 더 중요한 것은 개발자를 동반자로 보고 함께 머리를 맞대고 고민하는 것이다. 개발팀을 진정 동반자로 본다면 일거리가 산처럼 쌓여 있는 개발팀에 가서 자기 요청 안해준다고 투정부리고 있겠는가? 개발팀을 신뢰한다면 수시로 가서 해달라고 조르겠는가? 제대로 된 팀이라면 더 골 같은 거 안 읽어도 저런 문제들 안 생긴다. 팀이 붕괴되면 어떤 방안도 다 소용 없는 법이다.

이번 글에서는 “개발자가 모자라요”의 두번째 문제만 다루지만, 첫번째 문제, 스타트업이 개발자를 못 구하는 경우도 사실 마찬가지다. 말로는 기술 중심의 회사니 해커 문화니 떠들고, 함께 성장하는 회사를 말하지만, 사실은 그냥 내 아이디어를 실현해줄 사람을 찾는 경우가 대부분이다. 그런데 그런 마인드를 개발자가 눈치 못 챌 리 없다. 그러니까 개발자를 못 구하는 것이다. 특히 제일 웃긴 이야기는 “개발자만 있으면 이 사업 성공시킬 수 있는데”라는 말이다. 이건 “여자만 있으면 장가갈 수 있는데”라는 말이랑 똑같다. 뭐, 둘다 ASKY지.

 

 

 

개발자는 모자라지 않다.

 

개발자가 모자란 것은 원인이 아니라 결과다. 원인은 개발자들이 제대로 일할 수 있는 문화가 갖춰지지 않았기 때문이다. 문화가 갖춰지면 개발자들의 생산성은 몰라보게 올라갈 것이고, 뛰어난 개발자도 저절로 모여든다. 개발자가 모자란다고 불평하기 전에, 우리 회사는 왜 개발자가 생산성을 낼 수 없는지 고민하는 것이 우선이다. 그런 고민 없이 아무리 개발자 늘려봐야 소용 없다.