소프트웨어를 모르는 대한민국 기업의 위기

몇 주전 개발자들 사이에서 가장 시끄러웠던 뉴스 중 하나는 마이크로소프트가 깃헙_github을 인수했다는 소식입니다. 개발자들은 보통 그 사건에 대해 자기 생각을 갖고 있습니다. 반면에 경영자를 비롯해 대한민국 기업을 이끄는 수많은 사람들은 그게 무슨 의미인지 알지 못합니다. 소프트웨어가 기업에서 차지하는 비중이 상당^[1]하지만 그 문제를 인식하지 못하는 이들이 많습니다. 최근 4차산업혁명을 외치며 새로운 돌파구를 말하는 이들을 보면, 우리사회 전반의 소프트웨어에 대한 무지^[2]가 깊다는 사실을 깨닫습니다.

이 글은 소프트웨어의 중요성에 대해 잘 모르는 분들에게 작은 파문이라도 던져 행동 변화를 이끌기 위해 쓰는 글입니다. 소프트웨어에 대해 잘 모르는 경영자나 관리자분들이 이 글을 읽고, 소프트웨어는 단순히 돈을 주고 사면 된다는 생각을 바꿀 수 있다면 글 쓴 보람이 있겠습니다.^[3]

마이크로소프트가 개발자 전용 서비스를 인수한 사건

요즘 개발자 중에 깃헙이라는 서비스를 모르는 사람은 거의 없지만, 개발자가 아니라면 깃헙을 잘 모를 수 있습니다. 하지만, 개발자가 아니라도 마이크로소프트라는 회사는 모두 아시리라 생각합니다. 그 유명한 마이크로소프트_{이하 MS}가 최근에 깃헙을 우리돈 약 8조원에 인수합니다. MS의 깃헙 인수를 보는 시각을 둘로 나눠볼 수 있을 것 같습니다. 먼저 하나는 과거 오픈소스를 적대시하던 대표적인 회사 MS가 오픈소스 개발자들이 가장 좋아하는 곳을 인수했다는 점에서 생기는 논란^[4]입니다.

그 이슈는 여기서 다루지 않습니다. 저는, 탁월한 장사꾼인 MS가 오로지 개발자를 위한 도구를 8조원에 사들였다는 사실에 대해 글을 쓰고자 합니다. 저는 8조원이 얼마나 큰 돈인지 감이 오지 않습니다. 그래서, 검색해보니 과거 MS의 노키아 인수 가격도 8조원에 미치지 못했다는 사실을 발견했습니다. 개발자들만을 위한 소스 코드 저장소가 한때나마 세계 최고의 위치에 있던 핸드폰 회사보다 비싸다는 사실이 놀랍지 않습니까?

또 다른 비교 대상이 있습니다. 대형 유통 체인 홈플러스의 인수 가격이 8조원으로 거론 되던 기사들도 찾아볼 수 있었습니다. 개발자가 아니라면 그 의미를 모르는 코드 보관소가 노키아나 홈플러스 가격에 팔리는 일이 우리에게 무엇을 시사할까요? 저 스스로에게 했던 질문을 여러분에게도 던져봅니다. MS의 깃헙 인수 가격은 적절한 것일까요? 적절하다면 혹은 그렇지 않다면 그 이유는 무엇인가요?

코드 보관소가 8조에 팔리던 날

과거부터 프로그램은 미디어에 담고 박스에 잘 포장하여 판매했습니다. 소프트웨어 특성상 눈에 보이지 않기 때문에 단순한 물리적인 포장에 그치지 않는 경우도 있습니다. 특히 가격이 비싼 기업용 프로그램의 경우 구매를 결정하는데 상당한 시간이 걸리기도 합니다.^[5]

그런데 언젠가부터 오픈소스 형태의 프로그램이 인기를 끌기 시작했습니다. 오픈소스란 아무나 프로그램을 볼 수 있는 형태로 노출하여 제공하는 프로그램입니다. 판매 방식은 여타 기업용 프로그램과는 사뭇 다릅니다. 보통 바로 돈을 받는 대신에 자신이 만든 코드를 널리 퍼뜨리고, 이후에 잡지를 구독하는 형식과 비슷하게 수입을 취하는 식입니다. 하지만, 소프트웨어 세계를 잘 모르는 분들을 위해 간단하게 설명하면 프로그램 코드를 눈에 보이는 형태로 판매하는 식이라고 말할 수 있습니다. 그런 일을 통해 과거에 명성을 쌓고, 상당한 돈을 모았던 로드 존슨^{Rod Johnson}이라는 사람이 있습니다. 그가 최근에 쓴 블로그 글에 다음과 같은 글을 썼습니다.

My career has revolved around the belief that code should be celebrated as central to IT. Back in the early 2000s, in the dark days of J2EE, there were two major schools of thought as to how to fix the platform’s productivity problems: The “draw pretty pictures” camp, which aimed to generate nasty code from a non-code representation (for example, MDA); and the “let’s make the code sane” camp led by Spring and Hibernate. The “draw pretty pictures” camp was briefly dominant, along with the idea that “forward engineering” from UML was superior to writing code. (I was once publicly dressed down by a colleague for writing Java code rather than generating it from Rational Rose. Dark days indeed.)

We all know which camp won. Rails, Node, and Spring Boot continued the code-centric journey, making it a pleasure to build today’s business applications out of readable code focused on expressing business logic rather than wrestling with infrastructure problems.

출처: https://bit.ly/2JwrGbb

뒤에서 글을 조금 더 풀어 보기로 하구요. 간단히 말해 그는 깃헙 인수를 통해 자신의 과거에 대한 소회를 남겼습니다. 이는 2000년부터 시작한 그럴싸한 그림을 그리면_{draw pretty pictures} 코드가 자동으로 만들어진다고 주장하던 진영과 코드를 제대로 짜려는_{let’s make the code sane} 진영과의 경쟁 구도를 말합니다. 결과적으로 코드를 중시하는 진영의 승리했고, 자신이 만든 스프링 이외에도 코드를 중시하는 다른 제품들인 레일즈_Rails와 노드_Node 등을 예로 들고 있습니다. 레일즈나 노드 역시 스프링처럼 개발자를 위한 도구로 널리 쓰이는 대표적인 제품^[6]인데 마찬가지로 코드가 눈에 보이는 형태입니다.

그 승리에 확실한 마침표를 찍는 사건이 바로 한화 8조원 상당에 팔린 깃헙입니다. 깃헙은 말 그대로 코드 저장소이고 코드를 보관하고, 코드 작성에 필요한 게시판이나 그외 개발자를 위한 편의기능을 제공하는 서비스이기 때문이죠. MS가 깃헙에 8조원을 투자했다는 사실이 말해주는 바는 세상에 존재하는 코드를 작성하는 사람들(즉, 개발자나 프로그래머)이 MS의 사업에 적어도 8조원 이상의 이익을 제공해줄 가능성이 높다는 MS의 판단입니다.

개발자가 아닌 독자가 있다면, 여기까지 몇 분이나 따라오셨을지 모르겠네요. 프로그램을 작성하는 이들, 즉 개발자들이 MS에 큰 이득을 줄 것이라고 보고 MS가 깃헙에 투자했다는 해석을 이해하십니까? 동의하실 수 있나요?

이번에는 이와 비슷한 시기에 벌어진 전혀 다른 사건을 소개하겠습니다.

그런데 왜 한국에서는 코드가 자동으로 만들어진다고 ...

얼마전에 한국에선 다음과 같은 기사가 올라왔습니다. 메이저 미디어가 아니터라 페친 담벼락에서 봤습니다.

이젠 ‘코딩’ 대신 ‘모델기반개발(MDD)’시대다- LG CNS, 전문인력 100명 양성 위해 전주대와 M0U 맺어

소프트웨어 업계에 오래 몸담은 분이라면 쉽게 알 수 있는 시대착오적인 홍보 기사인데, 문제는 소프트웨어에 대해 잘 모르는 분들은 현혹되기 쉽다는 점입니다. 그래서, 왜 그런지 이제 설명을 드리겠습니다.

먼저 위 기사가 왜 시대착오적인지는 위에 인용한 로드 존슨의 글을 통해 설명하겠습니다.

Back in the early 2000s, in the dark days of J2EE, there were two major schools of thought as to how to fix the platform’s productivity problems: The “draw pretty pictures” camp, which aimed to generate nasty code from a non-code representation (for example, MDA); and the “let’s make the code sane” camp led by Spring and Hibernate. ^[7] 2000년대 초반으로 거슬러올라가면 J2EE^[8]가 고전하던 시절 생산성 문제 개선을 위해 2가지 견해가 다른 진영이 있었습니다. 하나는 MDA등과 같이 코드를 직접 작성하지 않고 (UML 등으로) 그림을 그리면 코드를 자동으로 만들어내려는 쪽이고, 다른 한쪽은 스프링과 하이버네이트^[9]_Hibernate가 주도하던 코드를 잘 만들려는 쪽이었습니다.

지금으로부터 약 20~15년쯤 전에는 코드를 자동으로 만드는 방식으로 생산성을 높이려는 시도들이 있었습니다. 그러나, 로드 존슨의 말대로 자바 프로그래밍 언어를 쓰는 개발자 커뮤니티에서는 코드 자동 생성 도구로 큰 이익을 노리는 대기업에 대항해 코드를 잘 짜서 이를 공개하는 이들이 있었습니다. 공개한 코드를 보고 의견을 나누고 협업하는 프로그래머 공동체를 만드는 식으로 성공한 제품이 스프링이나 하이버네이트 같은 것이었는데, 이들은 코드 자체를 노출하며 제품의 기능을 함께 발전시키고 결함을 줄여가는 엄청나게 활발한 대규모 공동체를 세상에 보여주었습니다. 사실 이후에 빅데이터 열풍을 만든 하둡_Hadoop류도 그 방식에 있어 크게 다르지 않습니다. 영미권은 그렇게 공통체가 함께 배워왔습니다. 요약하면 대기업 위주로 코드 자동생성을 하던 방식은 시장에서 패자가 된지 오래입니다. 선진 IT기업조차 오픈소스 즉, 코드가 공개되고 함께 코드를 보며 협업하는 시대입니다. 그러다 보니 코드 공개와 코드를 이용한 협업에 쓰이는 가장 편리한 서비스 깃헙이 8조원의 가격에 팔린 것입니다.

그렇다면, 우리는요? 우리나라에서는 어땠을까요? 요즘 소프트웨어 업계 52시간 논쟁^[10]을 보면서 정책입안자의 무지와 경쟁력 없는 소프트웨어 관련 기업의 구태를 확인합니다. 이를 이해하려면 우리의 역사를 알아야 합니다.

인터넷 기업만이 개발을 이해하다

제가 개발을 시작하던 90년말 ~ 2000년초까지는 인터넷 기업은 숫자도 적고 대부분 규모가 작은 벤처기업인 경우가 많았습니다. 그러한 기업들은 차근차근 소프트웨어 개발 역량과 인터넷 서비스 역량을 키워왔으리라 짐작합니다. 제가 직접 경험하지는 않아^[11] 잘 모르지만 신흥 기업이고 업종도 생소해서, 말 그대로 모험의 시간을 보냈으리라고 생각합니다. 하지만, 그들은 코드를 작성하기 때문에 소프트웨어에 대해 아주 잘 이해하는 기업으로 성장해왔을 것입니다. 시장에서 생존하기만 했으면 말이죠.

그 외의 기업은 어땠을까요? 한국에서 IMF 위기를 지나자마자 벤처 열풍이 불었고, 그와 비슷한 시기에 웹이 널리 쓰이기 시작합니다. 당시 기업 전산실에서 웹을 이해하는 분들이 거의 없었습니다. 그렇다보니 외부 회사나 전문 인력에게 일을 맡기는 아웃소싱이 널리 행해집니다. 또한 비슷한 시기에 서버 기계와 운영체제를 보다 유연한 제품으로 바꾸는 일이 당시 '다운사이징'이란 이름으로 널리 행해졌습니다. 결과적으로 경험이 없는 기업 전산실에서는 이를 직접할 수는 없고, 주로 외국계 컨설팅회사나 엔지니어 주도로 전산 시스템을 바꾸는 일이 대대적으로 벌어집니다. 곧이어, 이러한 일을 전담하는 국내 대기업들이 등장하는데, 이들을 시스템을 통합_{System Integraion}하는 회사라고 하여 SI 회사로 부르죠.

필자가 확인한 초창기 이들 회사 프로그래머의 실력은 상당했습니다. 무엇보다 (한국에 들어온 외국계 소프트웨어 업계에 비해) 후발이지만, 도전적이고 밤샘을 마다하지 않는 열정이 있었죠. 그러나, 그 회사의 경영자들은 무능했거나 도전정신이 부족했던 것으로 기억합니다. 왜냐하면 구축 사업에서 수익을 내는데 무게를 싣는 사업관리 위주의 변화를 과하게 추진하느라 훌륭한 프로그래머를 모두 떠나 보냈기 때문입니다. 좋은 엔지니어들은 전부 인터넷 기업으로 떠나가거나 외국산 소프트웨어 파는 일에 참여하는 외국계 기업으로 떠나갔습니다. 10년이 더 지난 이야기인데, 그러한 결과로 우리나라에는 인터넷 기업외에는 기술적인 면과 문화적인 면 모두에서 소프트웨어 개발에 대해 낙후되었다고 볼 수 있습니다.

특히나 외주 개발을 맡기는 기업들, 부서 이름으로 정보기획이나 ITO라는 표현을 쓰는 곳 등은 이미 위기를 맞은 곳으로 봐도 크게 틀리지 않다고 생각합니다. 길게 얘기할 것없이 깃헙인수라는 사건과 영업용 구호로 철지난 MDD라는 구호를 외치는 현상을 비교해보면 대략 서구와 10년 이상의 격차가 벌어져 있음을 확인할 수 있습니다.

맺음말

소프트웨어가 필수적인 시대가 되었습니다. 최근에 2년 넘게 클라우드 서비스 개발을 하면서 90년대 쓰이던 유틸리티 컴퓨팅^[12]이란 말을 언젠가 많은 사람들이 더 실감하겠구나 생각했습니다. 요즘 인터넷 연결 없이 하루도 못 버티는 사람이 많습니다. 인터넷 연결이 이미 수도나 전기와 같은 역할을 하고 있습니다. 인터넷에 접속해서 일상을 보내는 수많은 사람들의 눈과 귀와 손과 머리를 이끄는 것은 모두 소프트웨어입니다.

그 중에 여러분의 회사와 관계된 것은 얼마나 될까요? 고개를 갸웃하게 된다면, 그 회사의 미래는 밝다고 할 수 없습니다.

만일 여러분의 회사에 프로그램을 작성하는 사람들이 없다면, 얼른 채용해야 합니다. 쉽지 않지만 말이죠. 그리고, 현재 프로그램을 작성하는 사람이 회사에 직원으로 있다면, 프로그램 작성과 상관없는 일들에 대해서도 그들의 이야기를 들어야 합니다. 기업의 미래를 위해서 말이죠. 물론, 프로그래머가 아닌 사람이 프로그래머와 이야기하는 일이 쉽지는 않습니다. ^^

쓰고 나니 명쾌하지 않은 느낌입니다. 주로 개발자를 위한 글을 써오던 터라 아직은 익숙하지 않네요. 부족하더라도 이런 메시지에 관심이 있는 독자분이 있다면 지적과 관심을 보여주세요. 더 노력하겠습니다. 그래서, 프로그래머가 아닌 분들도 소프트웨어를 올바르게 이해하고, 그들과 잘 어울려 소프트웨어를 제대로 사용하는데 기여할 수 있었으면 하는 바램입니다.

주석

[1] IT는 갈수록 그 위세를 떨치고 있다. 전통 산업을 보조하던 것에서 전 산업의 중심으로 이동했다.  - 출처: 진짜로 혁신하려거든 IT에 부탁하라

[2] 최근 한글 기사 하나와 영문 블로그 하나가 제 머릿속에서 극명한 대비를 이뤘습니다. 한글 기사는 코딩 대신 모델 기반... 운운하는 MDD 성과를 홍보하는 글이었습니다. 기업에서 사용할 소프트웨어 개발을 전적으로 외주에 맡기는 회사들을 대상으로 하는 글이죠. 아마 기사를 읽는 대상이 소프트웨어 개발에 대해 어느 정도 식견이 있다면 이런 기사에 흥미를 보이기는 어렵습니다.  두번째 영문 기사는 스프링 프레임워크라고 하는, 자바 개발자들의 필수적인 도구라고 할 만큼 널리 퍼진 오픈소스 제품 최초 개발자가 쓴 글입니다. 어쩌면 영어로 쓰인 이 글을 통해서 대한민국 기성 기업의 소프트웨어에 대한 무지를 깨닫고 내일이라도 다른 선택을 할 수 있는 분이 한 분이라도 생길 수 있다는 희망으로 이 글을 씁니다.

[3] 사실 글을 쓰고 싶은 충동에 시작했는데, 아무에게도 득이 되지 않는 글이 될 수 있어서 여러 번 검토하면서 글 쓰는 이유를 좁혔습니다.

[4] 마이크로소프트의 과거 행적을 아는 많은 개발자들은 깃헙의 미래도 부정적으로 보기도 합니다. 긍정적인 해석은 MS가 조직의 정체성을 바꾸기 위한 노력의 일환으로 깃헙을 인수했다는 시각도 있습니다.

[5] 그러다보니  기업용 프로그램은 설명서를 포함하는 데에서 지니지 않고, 대개는 영업사원이 접근해서 설명해주고 기술지원 인력이 설치를 해주곤 합니다. 다양한 방식으로 소프트웨어 자체가 아닌 다른 포장(?) 혹은 부대 서비스가 필요했던 것이죠. 이후 설명하는 오픈소스라는 혁신의 등장도 이러한 기업용 프로그램 판별의 어려움에서 기인한 면이 있지만, 이에 대해서는 간단히 설명할 수 없어 여기서 다루지는 못합니다.

[6] 레일즈나 노드를 도구나 제품으로 묘사하는 내용이 개발자분들께는 어색할 수 있지만, 이 글을 개발을 모르는 분들에게 읽히기를 기대하고 쓰는 글입니다.

[7] 오역이 있을 수 있어 영한 병기합니다.

[8] 기업용 자바 프로그래밍 표준 도구의 이름입니다.

[9] 기업용 자바 프로그래밍 표준 도구의 개선 과정에서 스프링과 유사한 역할을 한 제품입니다.

[10] 조만간 이 문제에 대해서도 글을 한편 쓸 생각입니다.

[11] 필자의 경력 대부분은 대기업을 고객으로 하는 외주 개발환경에서 IT 컨설팅을 해왔기에 인터넷 서비스 기업에 대한 직접 경험은 없습니다.

[12] 유틸리티 컴퓨팅이란 전력·수도·도시가스등 유틸리티 산업에서 소비자별로 사용량을 검침하고 그 사용량만큼 요금을 부과하는 요금정책 및 고객서비스방식을 IT분야에 적용한 기술. 예컨대 유틸리티컴퓨팅 환경에서는 고객이 서버나 소프트웨어(SW)를 직접 구매, 소유하지 않고 임대해 쓰면서 사용한 만큼의 비용을 지불하면 된다. - 출처: http://www.zdnet.co.kr/news/news_view.asp?artice_id=00000010032914