소프트웨어 개발자김수보님의 글을 모비인사이드에서 소개합니다.
[IT산업의 변화]의 후속 글입니다. IT아웃소싱 보다는 스타트업 분야에 해당하는 글입니다. 현실 사례는 훨씬 더 복잡하고 다양하게 얽혀 있습니다. 하지만, 앞으로 풀어갈 주제를 명확히 하기 위해 초점을 몇 군데 맞추었습니다. 이 글에서 주장하고 싶은 말은 세 가지입니다.
1. 새로운 영역에서 개발자들의 역할은 점점 더 넓어지고 있다. 그래서 개발자들이 과거 역할에만 갇혀 있어서는 안 된다. 사업이 안 된다.
2. 실리콘밸리라고 해서 선진 문명이고 우리는 후진 문명이고 그런 것이 아니다. SW산업은 격차가 없다. 그래서 해결책의 도입에 기대기보다 자체적인 문제 해결 능력의 확보가 더 중요하다.
3. 기술이 좀 더 쉬워져서 IT 산업에 많은 자금이 유입될 수 있도록 개발자들이 소명 의식을 가져야 한다.
전통산업군에서의 IT
제조업, 유통업 등 전통적 산업의 고민은 뭐니 뭐니 해도 원가절감이다. 이것은 회사의 영업이익과 직결되기 때문이다. 그래서 IT의 핵심가치가 원가절감, 생산성 강화, 효율 향상에 있었다. 이것은 IT의 역할을 반복 업무의 자동화에 한정 지었다.
그래서 과거에는 검증된 SW 패키지를 공급받아 이 문제를 해결하려 했다. 하지만, 사업환경 변화가 빠른 곳에서는 대규모의 개발자를 이용해서 더욱 빠르게 업무를 전산화하는 것이 중요했다. (특히 통신)
그래서 과거의 SW 공학은 어떻게 하면 10년 이상 안정되게 돌아가게 할 것인가(Tolerant), 어떻게 하면 한 번 만들어서 여기도 쓰고 저기도 쓰게 할 것인가(Flexibility)에 집중해왔다. 그래서 크고 복잡한 Enterprise Architecture 를 처음부터 염두에 두는 것이 매우 중요했다. IT 시스템의 구축비용조차도 절감해야 했기 때문이다.
하지만, IT 인프라가 발달하면서 사업 환경의 변화도 점점 더 빨라졌다. 그래서 이를 따라잡기 위한 대규모 프로젝트가 끊임없이 만들어졌다. 하지만, 더욱 빠르게 업무를 전산화하는 것은 원가절감이 아니라 오히려 높은 IT 시스템 유지비용과 변경비용으로 이어지고 말았다.
또, 대규모 프로젝트의 남발은 기일에 맞춘 개발자 채용을 해야 했고, 분업화를 위한 개발공정은 개발자를 소모품처럼 사용하게 만들었다. 그리고, 이것은 다단계 하청구조를 만들어 내는 원인이 되었다.
물론, 지금도 전통산업에서 업무의 전산화는 중요하다. 그런 산업들은 대부분 기반산업이기 때문에 IT가 본연의 상품이 아니기 때문이다. 그래서 Enterprise System을 만들고 유지보수하는 SW 개발방법론과 프로젝트 관리방법은 사라지지 않을 것이다.
문제는 이 분야의 중점사항이 ‘안정된 Process Function’ 들을 만들어 내는 데 있다는 것이다. ‘Data’는 거래 Transaction의 근거로서 존재할 뿐이다. 즉 Data를 보존할 뿐 이용하지는 않는다.
인터넷 서비스에서의 IT
하지만, IT 시스템이 상품이 되는 영역에서는 논리가 좀 다르다. 예를 들면 앱 서비스는 스마트폰을 통해서 돈을 번다. 즉 IT 시스템의 핵심이 원가절감이 아니다. 고객들에게 돈을 받을 수 있는가 하는 상품성이 핵심이다. 그래서 IT의 역할이 ‘돈으로 치환될 수 있는 부가 가치를 제공하고 있는가?’ 하는 효과성을 충족시키는 데 있다.
따라서 고객의 니즈를 읽고 돈을 받을 수 있는 무형의 상품을 만들어내려는 방법이 중요해졌다. 즉, 사업을 시작할 때 만들어야 하는 업무 발굴이 SW 개발의 영역으로 들어온 것이다. 기존의 SW 개발방법론이 개발명세서를 만들기 위해 분석, 설계부터 시작한다면, 이 분야에서는 효과성을 시험, 확인하기 위한 작업부터 시작된다.
그래서 이 분야의 SW 공학은 어떻게 하면 효과적인 상품을 만들 수 있는가에 집중한다. 그리고, 효과성을 빠르게 확인하기 위해 짐을 최대한 가볍게 한다. 이미 공개된 플랫폼과 소스, 서비스를 활용한다. 그리고 작고 가벼운 Architecture를 선택한다.
이 분야는 기존 산업과 비교하면 비즈니스 룰을 새로 만들어 가는 과정과 정확히 일치한다. 그런데 온라인 사업은 이 과정의 상당 부분에 개발자가 참여해야만 한다. SW 개발자의 역할이 확대된 것이다. 그리고, 이 역할은 토론, 갈등, 분쟁 등을 만들어 낸다. 그래서 협업과 조정, 리더쉽과 팔로워십이 더욱 중요하게 되었다. 참고로 애자일은 이 문제를 해결하기 위한 선택지 중의 하나이다.
이 분야의 중점사항은 안정된 Function Process보다 가치있는 데이터의 축척과 활용이다. 인터넷은 주로 사용자의 정보 욕구를 채워주거나 정보 불균형을 해소시켜 주는데 강점이 있기 때문이다.
문제는 이 분야에 개발방법론(‘좋은 개발을 위해 지켜야 할 방법 이론’)이라 할 만한 것이 없다는 것이다. 그래서 기술부채가 상대적으로 빠르게 증가하다가 어느 순간 사업의 확장성을 저해하기 시작하는데 이를 해결할 방법이 요원하다. 따라서 적절한 시점에 기술부채를 털어낼 수 있도록, 누적 속도를 낮추도록 설계되거나 개발되어야 하는데 아직 정리된 연구가 많지 않다. 사업 성공률도 높지 않고 성공적 기술 사례도 적어서 그런 것이 아닐까 싶다.
두 산업의 중요한 차이점
IT 시스템이 원가절감 설비가 되느냐, 상품이 되느냐 하는 것은 매우 큰 차이다. 전자는 일회성 투자로 끝나고 전문가에게 맡길수록 유리하다. 그러나 후자는 아마추어라도 반드시 회사와 운명을 같이 해야 한다. 즉 주인 정신이 없으면 상품이 만들어질 수 없기 때문이다.
그리고, 전자는 외주 생산이므로 공정과 절차가 중요하지만, 후자는 사람이 중요하다. 사람이 상품을 만드는 기술 원료이기 때문에 회사는 이 사람들을 활용해서 상품을 만드는 생산 시스템(체계, 문화)를 가지고 있어야 한다. 그런데 이 문화는 위키나 칸반보드 같은 것을 의미하지 않는다. 그런 것은 도구에 불과하다. 중요한 것은 대화와 듣기, 의사결정 과정, 일 나누기 등이다. 즉 훈련된 사람이 만들어 내는 협업 과정이 문화가 인터넷 서비스의 생산 공정인 것이다.
그래서 정성 들여 사람을 뽑고 생산성을 높일 수 있게 조직 훈련을 해야 한다. 지속적으로 좋은 팀웍이 유지 되도록 자극도 해야 한다. 인터넷 사업은 사람 관리 비용이 특히 높은 사업이다.
문제 인식과 개발자의 숙제
개인적으로 전통적인 산업영역은 크게 관심이 없다. 구축경험이 시장에 축적되었기 때문에 딱히 연구할만한 주제가 없기 때문이다. 많은 분들이 잘 알아서 하고 있고, 앞으로도 잘 할 것이다.
하지만, 인터넷 서비스 영역은 그렇지 않다. 많은 기업들이 도전하지만 성공하기 쉽지 않다. 다양한 원인이 있겠지만 IT 사업을 어떻게 다룰지 노하우가 거의 공유되고 있지 않다. (디캠프, 스타트업 얼라이언스 등이 좋은 프로그램들을 하고 있지만 전체 시장에 대한 절대량은 매우 부족하다. 특히 지방 창업의 경우는 지식 습득의 기회가 거의 없다.) 융복합 사업이라면 난이도는 더 높아진다. 물론 개인은 답답하지 않다. 쉬운 사업을 하면 되니까.
문제는 국가 관점이다. IT기술의 가장 큰 장점은 다양한 부가가치 창출 능력인데 우리나라는 인프라형 비용절감 산업에 머물러 있다. 즉 산업 자생력이 엄청 낮다는 것이다. 자생력을 높이려면 시장에 다양한 자금이 흘러 다니고, 독립 고객층이 형성되어야 하는데 이 문제는 꽤 어려운 숙제다.
그런데, 조직 및 프로젝트 관리 문제는 보통 컨설팅 영역에서 다루어진다. 대부분 CEO나 회사 임원의 숙제이기 때문에 어느 정도 투자가 되고 있다. 하지만, 개발 방법론이나 기술 문제는 그렇지 못하다. 이 영역은 SW 개발자의 숙제인데 풀이가 매우 더디다. 잉여 시간이 많지도 않고 투자 여력도 없기 때문이다.
정해진 틀은 없다.
그래서 아직은 실리콘밸리의 성공 사례를 연구, 도입하고 있다. 최근의 대표 사례가 애자일이다. 기존의 폭포수 개발방식으로는 인터넷 사업에서 대응하기 힘들게 되자 도입한 것이다. 그러나 애자일은 일하는 방식에 대한 변화(가치 생산 방식)일 뿐 사람의 문제나 기술의 문제를 해결해 주지는 않는다. 그래서 기술 문제를 해결하기 위해 최근 주목받는 것이 마이크로 서비스 아키텍처다.
그런데, 애자일이나 마이크로 서비스 아키텍쳐가 생각해 보면 하늘에서 떨어진 특별한 것이 아니다. 단지 직면한 문제에 대해 개발자들이 해결책과 진화 방향을 스스로 고민한 것뿐이다. 따라서 직면한 문제가 다르면 해결책도 달라진다. 이 두 가지 사례에 대해 우리가 알아야 할 것은 이런 것들이다.
실리콘밸리가 겪고 있는 조직적 기술적 문제가 우리보다 앞서 있지 않다. 즉, 우리도 당장 현장에서 겪고 있는 문제이다. 적어도 SW산업 분야는 ‘선진국의 기술 수준이 10년 이상 뒤처져 있어요.’라는 멘트는 해당하지 않는다. 앞서 있다 아니다의 개념이 아니라, 다르다고 말하는 것이 맞다. 그래서 베끼는 것이 아니라 이해하고 배워서 응용을 해야 한다.
우리의 실무 조직은 누군가 정해 주고 지시해주길 바라는 경향이 크다. 반면 실리콘밸리는 스스로 문제를 정의하고 함께 해결책을 찾는 데 익숙하다. 즉, 우리도 능동적인 태도를 갖추게 되면 더욱 빠르게 우리의 문제를 풀 수 있다는 뜻이다.
개발자의 문제는 개발자들이 해결의 주체이어야 한다. 그리고 개발자의 문제란 상품을 잘 만드는 데 필요한 외연의 것들도 함께 포함한다. 성공적인 해결 사례들을 더 많이 공유했으면 좋겠다.
[IT의 중심에서] 이전글
– (7) 스타트업, 서비스 개발자가 되자
– (6) 페이스북은 어떻게 성장했을까
– (5) 유니콘 기업들의 핵심 경쟁력, 채용전략
[fbcomments url=”http://ec2-13-125-22-250.ap-northeast-2.compute.amazonaws.com/2017/08/24/engineer-role-subokim/” width=”100%” count=”off” num=”5″ countmsg=”wonderful comments!”]
