IT의 중심에서

중년 개발자가 살아 가는 IT 현장 이야기

소프트웨어를 더이상 건설로 이해하지 말자

“소프트웨어는 어떤 산업일까?”
생각보다 많은 CEO들이 소프트웨어 산업을 이해하고 있지 못합니다.
이유는 눈에 보이지 않기 때문이죠.

생태계 내부에서야 옛날 이야기 같겠지만,
조금 외곽으로 나가면 분위기가 다릅니다.

어떻게 이해를 시켜줘야 할까?
어렵습니다.

흔히 “건설”에 비유를 많이 합니다.
눈으로 볼 수 있는 대표적인 창작과정이니까요.

앞으로도 그래야 할까?
한 번 생각해봅니다.

시방서

U-City 할 때 소프트웨어 개발계획을 “시방서”로 만들더군요.
건설업계엔 익숙한 말이지만 소프트웨어 업계에선 생소한 말입니다.

시방서란 건물의 제작과정, 표준 등을 담은 문서로, 현실적으로는 “층별 설계도가 담긴 책자”처럼 만들어집니다.

앞에서부터 한장씩 넘겨가며 건물을 짓다보면, 어느새 10층짜리 건물이 만들어지는거죠.
절차적이어서 제작공정을 이해하기도 쉽고, 관리하기도 쉽습니다.

그래서 한 때는 소프트웨어개발도 그렇게 했습니다.
책장에다 빈 바인더를 여러개 꽂아놓고 앞에서부터 채워가며 프로젝트를 했죠.

하지만, 시간이 조금 흐르자 소프트웨어는 다르다는 걸 알게 됩니다.
코드를 만드는 거니까  윗층, 아랫층 구분없이 시작할 수 있습니다.
다 만든 후에 맞춰보면 됩니다.

부품, 모듈만 만드는 프로젝트도 있습니다.
절차조차 이야기하기 어렵기도 하죠.
그 모든 유형이 시방서라는 틀에 담기지 않습니다.

소프트웨어 개발은 건설과 많이 다르지만, 대부분의 젊은이가 막노동을 겪었던 시절에는 비교적 피부에 와닿는 비유였습니다.

개발방법론

“Method-1”이란게 등장합니다.
개발방법론이죠.
개발하는 방법이라는 뜻입니다.

SI 는 시스템을 구매한다는 개념에서 시작되었습니다.
하드웨어와 소프트웨어 (System)를 통합(Integration)하여 납품한다는 뜻이지요.
맞춤복 사업이니 사업이 되려면 기업들은 제작능력을 입증해야 했습니다.

양복 한벌 만드는거라면 입소문으로도 충분하겠지만, 수십억짜리 전산시스템은 그렇지 않습니다.
“훌륭한 제작공정”을 보유했음을 “공인기관”으로부터 인증받습니다.
그게 “소프트웨어 품질관리 인증”입니다.

이건 제품이 아니라, 프로세스에 대해 받는 겁니다.
좋은 생산절차를 가졌다는 뜻이지요.
그래서 한때 대형SI 회사들 사이에서 “품질인증” ISO 인증바람이 불었습니다.

“좋은 프로세스를 가지고 있으면, 좋은 제품이 나온다.”
음, 완전히 틀린 말은 아니지만, 상당부분 틀린 말이 되었습니다.
기술의 복잡도가 올라가면서 프로세스가 복잡해졌거든요.
표준화되지 않은 부분이 많아서 프로세스를 따라도 통제가 잘 안되는거죠.

제작비용은 높은데 오류가 발견되어도 이전단계로 되돌리기 어렵습니다.
그래서 “개발방법론”이 점점 힘을 잃게 됩니다.

프로젝트 관리

100억짜리 프로젝트는 단독주택이 아니라 커다란 빌딩을 올리는 겁니다.
철저한 계획을 세우고 분업계획을 짜고, 공사기한을 정한 다음 전문인부들을 고용합니다.
시방서는 설계도, 개발방법론은 시공방법 역할을 하게 됩니다.

엇, 빠진 게 있습니다.
바로 “공사관리”입니다.

안전모를 쓰고 가는지, 시멘트 트럭은 제때 오는지, 원료조달은 안 늦어지는지 체크하고 조정해야 합니다.

모든 변수에 대해 정상적인 건설진행이 되도록 공사관리를 해야 합니다.
그게 “프로젝트 관리”입니다.

소프트웨어는 건설과 달리 눈에 보이지 않기 때문에 위험예측의 필요성이 더 높습니다.
그래서 “프로젝트관리”도 전문분야가 됩니다.
자격증도 생깁니다.
PMP 자격증입니다. (Project Management Professional)

SI 에서 SM으로

SI (System Integraion)
SM (System Management)

회계를 장부로 관리하던 시절, 시스템 구축은 건축에 가까웠습니다.
맨땅에서 만들어야했고, 수작업을 컴퓨터로 바꾸는 거였습니다.
구현해야 할 기능과 목표가 명확해서 이런 접근법이 매우 효과적이었습니다.

하지만, 요즘 모든 회사에는 이미 전산시스템이 있습니다.
국세청, 은행과 작업할 걸 생각하면 수작업은 이제 불가능합니다.
IT가 모든 산업의 “인프라”가 되었습니다.
그래서 맨땅에서 개발하는 게 아니라, 운용중인 시스템을 계속 건드려야 합니다.

데이터는 바뀌면 안되고, 서비스를 중단할 순 없게 됩니다.
참조할만한 업무표준이 필요해집니다.

그런데, 건설엔 유사사례가 없죠.
“리모델링”이 전부인데, IT와 비교하면 범주와 관리방법이 많이 다릅니다.
참고사례가 되지 못합니다.

SI시장이 포화된후, SM시장이 커지자, “프로젝트 관리”도 시큰둥해집니다.
맨땅에서 맞춤형시스템을 반복개발하는 게 아니라면, “제작 프로세스”를 진화시킬 필요는 없게 되거든요.

SI시장이 사라지진 않으니까 프로젝트 관리는 여전히 중요하지만, 연구는 지지부진해집니다.

SM 에서 서비스로

서비스(Service)
고객에게 무형의 부가가치(만족감, 문제해결 등)을 제공하여 부가가치(돈)을 창출하는 영역

과거에는 은행직원이 예금이체를 했습니다.
은행에 가서 종이에 신청서를 써주면, 직원이 전산처리를 했습니다.
사람은 서비스를 제공하고, 시스템은 업무를 보조했죠.

시스템 작업을 할 때면 업무중단이 가능했습니다.
직원들에게 공지만 내리면 되거든요.
가끔씩 이체하러 갔다가 1시간씩 기다리기도 했죠.

요즘은 개인이 스마트폰앱으로 이체를 해버립니다.
24시간, 365일 서비스를 중단할 수 없게되었죠.
전세계가 금융망으로 묶여지게 되자, 더욱더 중단할 수 없게 됩니다.

이렇게 인프라가 소비자와 직접 맞딱드리게 되자, 단순운영으로는 사업을 할 수 없게 됩니다.
전산시스템 운영 = 사업경쟁력이 된거죠.
그래서 단순히 시스템을 쓸고 닦는 운영만으론 부족해집니다.

운영과 (신규기능) 개발을 함께 해야 하는거죠.
개발운영(DevOps)의 중요성이 높아집니다.

그래서 더이상 “프로세스 기반”으론 시스템을 만들고 운용하기 어렵게 됩니다.
선후 없이 우당탕탕 가야하는 상황이 된거죠.

개발문화

과제유형이 복잡해지고 난이도가 올라갑니다.
시장상황이 계속 변하자 미리 예측하고 완벽하게 만드는게 불가능해집니다.

“애자일 선언문”이 탄생합니다.
Process 가 아니라 Product 에 집중하게 되죠.
Feedback 과 개선에 집중하게 됩니다.

기존의 개발방법론은 이런 철학입니다.
“절차를 지키면 어떤 결과가 만들어진다. 그 결과는 대부분 좋다고 판단한다.”

하지만, 이제는 바뀌었습니다.
“절차를 지킨다고 해서 항상 좋은 결과가 만들어지지 않는다. 필요한 결과를 만들기 위해 필요한 모든 방법을 사용한다. 좋지 않으면 고치고 덧붙여서 좋게 만든다.”

프로세스를 만드는 것에 집중하지 않고, 여러가지 개발도구를 한 공간에 늘어놓고 필요에 따라 집어 쓰는 방식으로 개발방식이 변경된 겁니다.

분업이 아니라 역할만 정하고, 그냥 일하기 편한 방식으로 협력해서 결과를 만듭니다.
이 방식은 리더의 철학, 스타일에 따라 달라지기 때문에 “개발방법”이 아니라 “개발문화”라고 불리게 됩니다.

단점과 장점

이런 개발방식은 단점이 있습니다.
인력의존도가 커집니다.
사람에 따라 업무처리 속도와 품질이 달라집니다.
사람을 다루지 못하면 사업도 깨져버립니다.

채용이 중요해지게 됩니다.
신입사원을 기르기보다, 좋다고 증명된 사람을 뽑습니다.
인력유지가 중요해지게 됩니다.
인력유지가 사업의 지속성이 되죠.

하지만 쉽지 않습니다.
인력은 돈만으로 움직이지 않거든요.
좀 더 조직관리가 까다로워집니다.

팀이 제대로 세팅되면, 빨라집니다.
프로세스 대기시간이 사라집니다.
물론 막 날라다니진 않습니다.
하지만 확실히 소프트해집니다.

노하우, 매뉴얼, 지식이 쌓이고, 조직의 지적수준이 급속도로 올라갑니다.
프로세스형 조직들은 이런게 잘 쌓이지도 않고 잘 활용되지도 않습니다.
프로세스는 접근장벽이자 활용장벽이 되거든요.

공격받지 않기 위해 100% 완벽해야만 지식산출물이 됩니다.
만들다만 실패지식들은 버려지게 되죠.
하지만, 소프트웨어 세계에선 그런 것도 매우 중요합니다.
시행착오를 줄여주거든요.
만들다만 페이퍼도 귀중한 정보가 됩니다.

그래서 소프트웨어는 제품2.0을 만들 수 있습니다.
반면 건설은 제품 1.0만 만들고 끝이죠.
거인의 어깨를 빌려 더 높이 올라갈 수 있는 거.
그게 소프트웨어 사업의 가장 큰 장점입니다.

요즘 개발은

그런데, 개발문화…
이거 설명하기 힘듭니다.

2차산업 종사자들은 공장식 사업관리에 익숙하기 때문입니다.
프로세스 혁신, 생산성, 효율화.
이런게 다 거기에서 나온 용어죠.

요즘의 소프트웨어는 대량복제와 판매를 쉽게 해결할 수 있습니다.
생산성, 효율화가 중요하지 않죠.
오히려 효과성이 중요해집니다.
팔릴만한 제품을 만들어야 하죠.
효과없는 제품이라면 생산성이 높아봐야 적자만 늘어납니다.

그래서 고민해봅니다.
뭔가 이해하기 쉬운 비유사례가 있을까?
요즘에는 소프트웨어가 요리같습니다.
백종원의 골목식당, 집밥 백선생을 보니 그런 생각이 듭니다.

예를 들어보면 이렇습니다.
요리는 비슷한 재료를 사용해도, 사람이 다르면 맛이 완전히 달라집니다.

소프트웨어도 마찬가지입니다.
똑같은 Java Spring 으로 개발해도, 혹은 똑같은 서버개발자라 해도 사람에 따라 결과물의 차이가 큽니다.

쓰레기냐 아니냐의 차이도 있겠지만, 둘 다 고수라면 그냥 서로 다른 맛입니다.
진화하는 스타일이 달라지는거죠.

Open API, 프레임워크, 템플릿.
이런 것도 마찬가지입니다.

밤새 재료를 준비해놓고 주문이 들어오면 10분만에 음식을 내는 방법들인거죠.

요약하자면

소프트웨어 세상에서 제발 건설식  비유가 사라지면 좋겠습니다.
건설업은 시설을 중심에 놓고, 사람을 부품으로 사용하는 생산체계입니다.
매번 맨땅에서부터 시작해야 하니 그런게 이해됩니다.

하지만, 소프트웨어 세상에선 그런걸 잘했다고 돈을 더벌진 않죠.
그냥 잘팔리는 제품을 만들어야 합니다.
즉, 소프트웨어 세계에선 사람이 비용이 아니라 투자대상입니다.

요즘 친구들은 건설식 비유는 알아듣지 못합니다.
편의점 아르바이트로 컸거든요.
공사판 세대와는 차이가 큽니다.
이젠 건설식 비유는 하지 맙시다.

언어가 생각의 틀을 가두어버리거든요.

끝.

소프트웨어를 더이상 건설로 이해하지 말자”에 대한 9개의 댓글

  1. 정지영
    2020년 6월 12일

    김수보 님과 먼발치에 잠시 일한 경험이 있습니다.
    그때도 참 통찰력이 있으시다 생각 했었습니다.

    가끔 들러 글 읽으면서 공감하고, 안주하는 제 태도 반성합니다.

    건강하시고 앞으로도 좋은 글 부탁드립니다.

    • subokim
      2020년 6월 12일

      이크. 감사합니다. 기억된 모습이 부끄럽지 않았으면 좋겠네요. 감사합니다.

  2. 강명훈
    2020년 5월 28일

    결국 돈이 걸리면 개선이 되지 않나 싶습니다…

    • subokim
      2020년 5월 29일

      크. 정말 그렇긴 할 것 같습니다. :-)

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

정보

이 엔트리는 2020년 4월 13일에 님이 IT 산업이야기, 스타트업에 게시하였으며 태그가 지정되었습니다.

내비게이션

%d 블로거가 이것을 좋아합니다: