※ 「[당신은 소프트웨어를 잘 모른다] 1. 소프트웨어를 모르는 대한민국 기업의 위기」를 읽지 않으신 분은 이를 함께 읽어주세요.
얼마 전 주 52시간 근로 제도 논쟁[1]이 있었습니다. 그중에서 특별히 ICT 업종은 예외를 인정해준다는 정부의 방침이 기사화되면서 페친들의 비난이 줄을 이었습니다.
사회생활 초기부터 늘 스스로 야근을 했던 제 입장에서는 근로 시간에 대한 규정은 관심 밖의 영역이지만, 소프트웨어 업계에서 근로 시간이 쟁점이 된다는 사실은 씁쓸하기 이를 데 없습니다. 그래서, 이 글에서 소프트웨어 가치에 대해 근로자의 노동 시간을 기준으로 산정하는 방식이 비상식적인 일인지를 설명하고자 합니다.
소프트웨어 개발에 어울리지 않는 건설업 참조의 폐해
결론부터 말하면 소프트웨어 개발자[2]는 전형적인 지식 노동자이고, 지식 노동자의 생산성을 시간으로 측정하는 일은 그다지 알맞은 수단이 아닙니다. 솔직히 말해, 소프트웨어 개발이 어떤 일인지 조금이라도 아는 분이라면 얼마나 한심하고 구차한 방법이라 여길 일입니다.
우리의 두뇌는 오랜 시간 똑같은 품질의 결과물을 내놓지 않습니다. 그러면 어떻게 측정해야 할까요? 글을 쓰고 음악을 만드는 사람이 하는 활동을 저작 활동이라고 합니다. 소프트웨어를 바로 봄에 있어서도 이와 비슷한 관점이 필요합니다. 소프트웨어 제작 역시 자신이 알고 있던 지식과 의뢰받은 일을 통해 새로 배운 사실을 토대로 코드를 작성합니다.
하지만, 그러한 한심한 방식이 진지하게 논의되는 현실은 엄연히 존재합니다. 이는 소프트웨어 산업의 발전 과정에서 원인을 찾을 수 있습니다. 소프트웨어 산업은 주로 발주에 의한 제품 생산 방식으로 발전했습니다. 초기 소프트웨어 개발이 대부분 프로그래머와 계약을 통해 만들어지는 식이었습니다. 그 과정에서 대규모 프로그램 제작을 의뢰받은 업체들이 수익성 위주로 사업을 진행하다 보니 건설업의 하청 모델을 본 뜬 방식이 널리 퍼졌습니다. 그러한 일들이 기업화 되면서 일해보기 전에는 알 수 없는 실력을 대상으로 객관적 평가를 해야 하는 입찰 방식의 본질적인 모순 탓에 고착화 한 문제라고 할 수 있습니다.
그래서, 프로그래머의 연차로 대가를 산정하는 황당한 방식에 더하여 맨먼스(Man-Month)와 같은 근무 시간으로 대가를 산정하는 방식이 표준인양 쓰이고 있습니다. 그로 인해 발생하는 커다란 사회적 낭비 또한 고착화된 부분이 있습니다. 대표적인 사례가 바로 대부분 실패로 끝나는 차세대 프로젝트 악순환입니다.
하지만, 한발 떨어져서 역사적 시각 즉, 긴 호흡으로 바라보면 신흥 산업에서 필연적으로 일어나는 시행착오라고 여겨봅시다. 소프트웨어 선진국인 서방에서도 이런 현상을 깨달은 선각자들이 2001년 이른바 애자일 소프트웨어 개발 헌장을 내놓고 계몽 활동을 펼쳐 온 역사가 있기도 합니다. 그리고, 가장 선두를 달리고 있는 미국은 거대한 자본을 기반으로 발주 따위가 없어도 소프트웨어를 통해 가치를 창출하고 투자자들에게 부를 분배하는 방식을 개발했습니다. 실리콘밸리라고 일컬어지는 일련의 현상이 바로 그것이죠.
한편, 우리 사회에서도 소프트웨어 역할이 커졌습니다. 거의 대부분의 국민들이 스마트폰을 들고 다니니까요. 그리고, 개발자도 늘어나고 그들에 대한 수요와 처우 역시 과거와는 비교할 수 없을 정도가 되었습니다. 그리고, 한국의 실리콘밸리라며 모방하는 일도 의미 있는 결과를 만들어내고 있습니다.
이제는 지속적으로 소모적인 사회적 비용을 쏟아붓는 낙후된 기업용 프로그램 개발 영역에서는 다른 접근이 필요합니다.
소프트웨어는 소비자 눈에는 경계가 보이지 않는 제품
본질적인 질문을 한번 던져봅니다. 소프트웨어란 말에 대해서 여러분은 어떤 정의를 내리고 있나요? 사전적 정의 말고 여러분이 갖고 있는 생각이나 느낌을 말로 표현해보신 분이 있나요?
필자는 이 분야에서 20년 가까이 일해오고 있는데도 비교적 최근에 소프트웨어가 무엇인지를 진지하게 생각하기 시작했습니다. 그 전에는 굳이 설명할 필요성을 못 느껴서 방치했는데, 나이와 경험이 쌓이고 자연스럽게 고위 경영진과 만나게 되면서 무척 중요한 결정을 하는 분들이 놀라울 정도로 IT와 소프트웨어에 대해 무지하다는 사실에 놀란 일이 있습니다.
그분들의 결정에 따르는 파급효과가 크기 때문에, 피해를 최소화하기 위해 기회가 되면 보다 정교하게 표현해보려고 시도하고 있습니다. 이 곳에 쓰는 글 상당수는 그에 대한 실천이자 연습 결과물입니다.
아무튼 그런 노력 과정에서 제가 현재 설명할 수 있는 소프트웨어에 대한 구어체 정의는 아래와 같습니다.
소프트웨어는 소비자 눈에 보이는 경계가 거의[3] 없다. 작성하는 이가 구분지은 모양 그대로 만들어지는 제품이다.
그렇습니다. 만드는 이 눈에는 수많은 경계가 보이지만 소비자는 이를 인식할 방법이 거의 없습니다. 그러한 소프트웨어를 발주해서 만드는 경우를 생각해보죠. 내가 원하는 것을 프로그래머에게 맡겨 개발하는 상황입니다. 당연히 그에게 의존해야 합니다.
그리고, 잘 만들고 싶다면 더욱 정확하게 의사소통 하는데 최선을 다해야 합니다. 계약서 따위로 의사소통이 잘 되리라고 생각한다면 100% 실패를 맛보게 됩니다.
프로그래머와 소통할 수 있는 의뢰인의 중요성
앞서 소프트웨어 개발자는 전형적인 지식 노동자라고 했습니다. 글을 쓰고 음악을 만드는 사람이 하는 바로 그 저작 활동을 합니다. 만일 여러분이 화가에게 자화상을 그려달라고 부탁하는 의뢰인이라면 어떻게 의사소통을 하시겠습니까?
소프트웨어 저작과 그림을 다르다고 말하는 분이 있겠지만, 닮은 부분이 많습니다. 무엇보다 전적으로 그들의 손에 의해서 모양이 만들어진다는 점이 똑같습니다. 그래서, 그들에게 ‘어떻게 하라’로 구체적인 요구를 하기보다는 ‘무엇을 바라는지’를 설명하는 방식이 효과적입니다.
기업용 프로그램 제작으로 대상을 좁히면, 프로그래머가 다수의 공동작업을 필요로 하는 경우가 많습니다. 여기서 어려운 과제가 하나 등장합니다. 필자의 경험상 대체로 프로그래머와 의뢰인이 소통하는 일은 쉬운 일이 아니란 점입니다. 프로그래머와 소통에 있어 곤혹스러운 경험을 한 의뢰인은 어렵지 않게 만나볼 수 있습니다. 앞서 설명한 애자일 헌장이 발표될 즈음에 의사소통을 제1가치로 여기는 XP가 등장한 배경도 거기에 있습니다.
또한, 최근 협업도구의 약진 몇 가지만 살펴보아도 이쪽 업계가 의사소통과 협업 문제를 얼마나 중시하고 있는지 여기저기서 쉽게 눈치챌 수 있습니다. 개발자라면 모두 아는 슬랙Slack은 애초에 게임회사였지만, 게임으로 돈을 번 것이 아니라 내부 의사소통 도구로 사업 방향을 전환하며 성공한 사례가 있습니다. 그리고, 한화 8조 원 상당에 팔린 github이 본질적으로 개발자 협업도구란 사실이 또 다른 증거입니다. 필자의 개인 경험으로 좁히면, 저에게 메일보다 훨씬 자주 쓰는 도구는 국내에서 빠르게 성장하는 Dooray라는 개발자와 기획자를 아우르는 범용 협업도구입니다.
의사소통 문제는 모든 사회적 활동에서 반드시 넘어야 할 산입니다. 의사소통을 계약과 협상을 잘하는 것으로 대신할 수는 없는 일입니다. 물품 구매 계약과 소프트웨어 제작 계약을 비슷한 수준으로 바라보는 일은 엄청난 착각입니다.
애자일 소프트웨어 개발 헌장에도 해당 내용이 있습니다.
고객 협업이 계약 협상에 우선한다 Customer Collaboration over contract negotiation
소프트웨어 가치 산정에 대해 다시 생각해볼 때
많이 늦었습니다. 아직도 금융권에서 차세대 프로젝트를 하고, 또 계획하는 뉴스가 나옵니다. 늦었다고 생각할 때가 가장 빠른 때인지도 모릅니다. 이제는 다시 생각해볼 필요가 있습니다.
물품 계약하는 일과 소프트웨어를 의뢰한 후에 돌려받는 일이 같은 방식으로 처리할 수 있을까요? 그리고, 아무리 계약을 잘한다고 해서 좋은 소프트웨어를 만들 수 있나요? 그렇다면 어떻게 해야 할까요?
여기서 제 경험과 지식 안에서 일반론으로 해결책을 제시하고 싶지는 않습니다. 그러기에는 수많은 사람들에게 너무나도 중요한 일이고, 우리 사회의 미래가 달려있기 때문입니다. 그래서, 오래간만에 아래 이미지를 띄웁니다. 진지하게 고민하시는 분은 메일 주세요.
원문: Pop it
[1] “불가피한 경우 특별 연장근로를 인가받아 활용할 수 있도록 구체적 방안을 강구하겠다”며 “특히 ICT 업종에서 서버다운ㆍ해킹 등 긴급 장애 대응 업무는 특별 연장근로가 가능하도록 조치하겠다”고 강조했다. 기업에 특별한 사정이 있는 경우 고용노동부 장관의 인가를 얻어 연장 근로시간(주 12시간)을 초과해 근로를 시킬 수 있도록 하겠다는 뜻이다. / 출처: 김동연 “ICT 업종 특별 연장근로 가능케 하겠다”
[2] 이 글에서 개발자와 프로그래머는 같은 뜻으로 구분 없이 함께 사용합니다.
[3] 화면이나 메뉴에 일부 경계가 나타나지만 소프트웨어를 구획 짓는 수많은 경계(함수, 파일, 모듈, 배포 파일 등등)에 비하면 미미한 수준이라 ‘거의’라고 표현했습니다.
