개발조직은 왜 ‘돈 먹는 하마’로 보일까?
개발조직은 왜 ‘돈 먹는 하마’로 보일까? 관련
<SI 초보자를 위한 Q&A 모임>을 기획하여 함께 진행한 김수보 님이 올린 페이스북 글이 제 관심사를 직격했습니다. 글의 제목은 “개발조직은 돈 먹는 하마”였는데, 프라이머를 운영하시는 권도균 님의 글에서 출발한 주제였습니다.
우선 제 관심을 불러일으킨 내용을 살펴보겠습니다. 먼저 아래는 권도균 님의 글입니다.
IT회사 CEO들 사이에는 “개발조직은 돈 먹는 하마”라는 이야기가 돌고 있어요. 도대체 개발팀들은 맨날 바쁘다, 밤샌다고 하는데 시스템 완성은 매번 늦어져요. 이유가 뭔지 모른 채 엄청난 개발조직 인건비를 지불하고 있어요.
IT회사 CEO들이 개발조직에 들어가는 인건비가 합리적으로 쓰이고 있는지 알 수 없는 현실을 문제 삼고 있는 듯합니다. 이제 이를 인용한 김수보 님의 글을 찾아보겠습니다.
“개발팀은 돈 먹는 하마”라는 이야기는 CEO들 사이에서 꽤 오래전부터 나왔는데 거의 진전이 없는 분야죠. 반면 이게 IT산업의 부정 경험을 확산시키고, 자본의 유입을 꽤 방해하고 있습니다. 꽤 훌륭한 개발자 친구들도 임원이 되고 나선, “흑화”되어 버리더라고요. 이걸 “생산성의 문제”로 정의하고, 일반적으로 “관리∙통제”로 접근하는데, 경험상 실타래를 더 얽어 버리더라고요.
소위 개발조직이 ‘돈 먹는 하마’로 보이는 현상이 과거 이들이 ‘전산실’이라 불리던 시절부터, 웹과 클라우드의 발전 그리고 AI 혁신이 세상을 시끄럽게 하는 요즘까지도 별 차이가 없다는 이야기입니다. 깊이 공감하는 문제이고, 이 글을 쓰게 된 계기이자 곧 주제이기도 합니다.
10년도 넘게 마음에 담고 있는 문제 의식
필자 역시 비슷한 문제 의식을 마음속에 담고 있었습니다. 다만 입장은 달랐습니다. 개발자로 출발하여 IT 컨설턴트 생활을 오래 했던 경력 때문이죠. 개발조직을 위해 일했던 입장이니 CEO보다는 그들의 편에 설 수밖에 없는 것이죠. 그래서, 20년 가까운 기간 개발에 대한 투자가 ‘합리적’이고, 어떤 ‘효과’를 주는 지를 클라이언트 혹은 고객사에 설명하는 일이 제 중요한 임무가 되기도 했습니다.
그중 10여 년 전에 고객사 주요 임원들이 모두 참여하는 회의에 참석해 직접 제안한 내용도 떠오릅니다. 당시 고객사 임원들 사이에서 “애자일이 뭐냐? 우리에게 도움이 되는 것이냐?” 하는 화두가 돌고 있을 때였습니다. 그때 저는 유럽 DevOps 커뮤니티 행사 자료에서 발췌한 이미지를 차용하여 개념적인 설명을 하고, 1년 이상 결과 없이 진행하는 프로젝트를 하나로 품의하여 비용을 집행하는 대신에 중간중간 결과를 확인하며 투자를 진행하는 방식을 제안했던 일이 있습니다.
점진적인 비용 집행에 대해서는 합의가 이뤄졌다 생각했지만, 다수의 이해관계자로 구성된 고객사에서는 각자 경험과 역할에 따라 전혀 다른 입장에서 본다는 사실을 배울 수 있었습니다. 특히 연간 계획과 이를 근거로 한 평가가 이루어지는 탓에 불확실한 계획에 대해서는 대다수가 거부감을 보였습니다. 그래서 실제로는 굉장히 험난한 일이 되었습니다. 시간이 한참 지난 지금도 그 점에 대해서는 업계에 그다지 진전이 없어 보입니다.
그렇기에 다시 한번 화두로 제시하고, 제 생각을 글로 표현합니다.
왜 “돈 먹는 하마”인가?
먼저 개발조직이 돈 먹는 하마에 비유되는 이유를 살펴보겠습니다. 멀리 갈 것도 없이 다시 한번 권도균 님의 글을 살펴보겠습니다.
개발팀들은 맨날 바쁘다, 밤샌다고 하는데 시스템 완성은 매번 늦어져요. 이유가 뭔지 모른 채 엄청난 개발조직 인건비를 지불하고 있어요.
화제의 보편성을 확인하기 위해서 ‘돈 먹는 하마’를 키워드로 구글링을 해 보았더니 굉장히 부정적인 만평들이 이미지 요약 상단에 다수 등장했습니다.
소프트웨어 개발에 인건비가 쓰이는 이유는 당연합니다. 돈은 지식 노동의 연료입니다. 그리고 ‘먹는 일’은 나쁜 일도 아닌데, 왜 ‘돈’과 ‘먹는’을 합치면 부정적인 어감으로 쓰일까요?
앞서 인용한 글을 투입 대비 효용의 관점으로 다시 기술하면 문제를 이렇게 쓸 수 있습니다.
- (개발 조직은) 뭘 하는지 모르겠다.
- (개발 조직이) 제대로 하고 있는지 신뢰할 수 없다.
그리고 이는 구글 검색 결과로 드러난 이미지와도 그대로 일치한다고 할 수 있습니다. 겉으로 드러나는 효용성이 없으면 경제적 합리성을 의심받는 일은 비단 개발 조직에 국한된 일은 아닙니다.
아마도 큰돈을 쓰는 조직이라면 어떤 방식으로든 내부에서 설명을 시도하고 있을 듯합니다. 다만 서로의 시각과 입장이 달라서 실질적인 소통이 일어나지 못한다는 것이 제 주장입니다.
소프트웨어는 두 가지 방식으로 가치를 만든다
제가 최근에 켄트 벡의 글을 번역하는 과정에서 ’소프트웨어는 두 가지 방식으로 가치를 만든다’는 사실을 배웠습니다. 소프트웨어는 외부 관찰자 즉, 사용자나 고객 그리고 경영자도 볼 수 있는 동작 변경과 개발자만 볼 수 있는 설계 혹은 구조 개선을 통해 가치를 창출합니다.
참고 글: 소프트웨어는 두 가지 방식으로 가치를 만든다
그런데 만약 결과가 드러나지 않는 설계 업무에 긴 시간이나 높은 인건비가 투여된다면 경영자는 어떻게 느낄까요? 아마 경영자가 직접 개발에 참여하는 경우가 아니라면 너무 큰 인내심을 요구하는 상황이 되고, 그러한 요구는 갈등과 긴장으로 표출될 것입니다. 결과적으로 지속 가능한 방법이 아닙니다.
경영자에게 투자의 효용성이 적절하게 설명되는 사건이나 절차가 있고 이 과정이 충분히 납득되지 않는다면, 어느 순간 개발조직이 ‘돈 먹는 하마’처럼 느껴지는 일은 너무나 당연할 듯합니다.
사업 성과와 동기화하기
2016년에는 중국 고객사의 IT책임자와 합리적인 개발 비용 투자에 대해 이야기를 나눈 일이 있습니다. 패션 분야에서 종사하던 분이었는데, 매출과 연계한 개발 관련 투자가 가능하다면 경영자의 투자에 대한 부담이 줄어든다는 논리를 그래프로 그려 설명하셨습니다.
우선 그분은 경영자에게 IT 투자의 합리성을 설명하는 일이 너무 어렵다며 해결책을 찾고 있었습니다. 그분과 함께 이를 설득할 방법을 찾다 보니 한 가지 아이디어를 얻었습니다. 간단히 말하면 투자와 비례해 매출이 오른다면 경영자들이 상세 내용을 이해하지 못해도 납득할 수 있다는 것이죠.
사업 성과와 개발조직의 인건비 사용이 동기화되지는 못하더라도 인건비 사용은 사업 성과와 대응되어야 범용적으로 받아들일 수 있습니다. 이른바 사업 성과와 비용을 동기화하는 형태는 산업 전체로 보면 이미 벌어지고 있다고 할 수 있습니다. 특히 클라우드 전환이 일어나면서 성과에 따른 수수료나 구독료 형태로 지출 비용의 모양이 바뀌고 있습니다. 하지만 조직 내부에서 그러한 흐름을 인지하고 있지 못할 수도 있고, 다른 일들에 우선순위가 밀려서 간과된다고 할 수도 있습니다.
‘개발조직’이라는 개념은 적절한가?
다시 10년쯤 전에 제가 IT 컨설팅 회사를 다닐 때의 일화를 인용합니다. 당시 시스템 운영을 총괄하던 팀장님은 1년 운영비가 사옥 건축비랑 비교된다며, 대표이사에게 올해 뭐했냐는 질문을 받을 때 답하는 일이 가장 힘들다고 말씀하셨습니다. 역시나 개발조직이 ‘돈 먹는 하마’로 보이는 장면이라 할 수 있습니다.
10년 정도 지나자 당시에는 보지 못했던 부적합이 분명하게 보입니다. 당시 고객사의 IT운영팀은 기존 기업의 기능을 돕는 경영지원의 하부 조직이었습니다. 그 시점에 팀을 이끌어가는 임원은 ‘우리 회사는 이제는 개발조직이다’라고 주장하셨는데, 돌아보면 이는 굉장한 혁신이었습니다. 그때 고객사의 구성원 입장에서는 전산 혹은 IT가 생산 부서처럼 돈을 많이 쓰는 일은 상상하기 힘든 일이었기 때문입니다. 이제 막 혁신을 시도하는 초기였기에 IT 개발팀 직원들조차 자신들이 무언가 생산을 한다는 인식은 부족했습니다.
제 지난 이야기를 꺼낸 이유는, 사업 성과와 비용을 동기화하려면 기업 입장에서 ‘개발조직’의 정체성이나 의미를 명확하게 해야하기 때문입니다. 과거에 ‘전산실’과 같은 이름으로 부르거나 경영지원팀 산하에 있을 때는 개발조직이 지원 조직의 성격을 띕니다. 그렇지만 만약 일반 식음료 제품 회사에 이커머스가 도입되면 어떨까요? 외주로 개발하던 응용 프로그램이 고객 경험을 결정하는 서비스이자 제품이 됩니다. 바로 생산 부서로 바뀌는 것이죠. 엄청난 변화이지만 10여 년 전에는 그러한 공감이 없었고, 저 역시 당시는 그런 변화에 대한 인식이 부족했습니다.
스타트업 영역에서는 이미 소프트웨어를 제품이라고 부르는 일이 흔합니다. 실리콘 밸리 제품 개발 문화에서 차용한 역할들, 이를테면 프로덕트 매니저나 프로덕트 오너 같은 표현 역시 쓰고 있습니다. 각 기업의 전환 여부를 떠나서 사회적으로는 전환이 일어나고 있습니다.
마치며
이제 이야기를 정리해 보겠습니다. 앞서 개발 조직이 돈 먹는 하마로 보이는 일은 서로의 시각과 입장이 달라서 실질적인 소통이 일어나지 못하기 때문이라는 주장을 했습니다. 저는 한때 피터 드러커가 무려 1988년에 쓴 아티클을 보고 놀란 후에 제 생각을 정리해 글로 쓴 일이 있습니다. 이른바 ‘새로운 제조업 이론’에 대한 것이었습니다.
아티클에서는 지식 노동에 걸맞은 제조 회계 방법을 설명합니다. 그중에 일부를 인용해 볼까요?
원가 회계의 강점은 측정 가능한 것에 집중하면서 객관적인 답을 제공한다는 점이다. <중략> 자재를 경제적 만족으로 전환하는 과정이 곧 제조라고 정의 내리면 한 가지는 분명해진다. 제품이 공장을 떠날 때 생산활동이 멈추는 것이 아니라는 점이다.
피터 드러커는 지식 노동 사회에서는 소비자가 경제적 만족을 느낄 때까지를 통합해 제품 프로세스로 보아야 하고, 그에 맞는 원가 회계를 시도하라고 조언합니다. 이 교훈을 제가 들고 온 개발 조직에 해당한 문제로 범위를 좁혀 다시 기술해 보겠습니다. 기업은 개발 조직의 인건비가 고객이나 사용자가 얻는 경제적 만족과 연결되도록 회계 방식을 개선해야 합니다. 그래야만 객관적인 비용 지출에 대해 측정이 가능해지고, 경영자는 불안과 불편에서 벗어날 수 있습니다.
물론 이런 생각은 경영의 그루로 불리는 피커 드러커가 그린 이상향에 대한 해석입니다. 다만 저는 대체로 그러한 방향을 바라보며 지금 할 수 있는 일을 해야 한다고 주장합니다.
독자님들 입장에서는 막연할 수 있으니 가벼운 마음으로 예를 들어 보겠습니다. 최소한 우리가 일주일 이상 개발을 하게 된다면, 먼저 개발자와 개발 결과에 영향을 받는 이해관계자 사이에서 무엇을 기대할 수 있는지 이야기를 나눠 봅시다. 서로의 입장 차이보다 “한 팀”이 될수 있도록 그 “기대값을 정교하게 할 방법”을 찾아 나갈 수 있습니다. 이런 일들은 당장 효과가 나지 않고 눈에 보이지 않지만, 한 팀으로 지속 가능한 투자가 벌어지게 하기 위해서는 꼭 필요한 일이 될 것입니다.
