IT의 중심에서

기술은 사람을 행복하게 할 때 가장 가치가 크다.

적정기술 3.개발자 역할의 변화

#연재글 #적정기술 #재개발방법론 #실용기술

system_evolve

서비스 플랫폼의 발전 과정

지난 글 [02. IT산업의 변화]의 후속글입니다. IT아웃소싱 보다는 스타트업 분야에 해당되는 글입니다. 현실 사례는 훨씬 더 복잡하고 다양하게 얽혀 있습니다. 하지만, 앞으로 풀어갈 주제를 명확히 하기 위해 초점을 몇 군데 맞추었습니다. 이 글에서 주장하고 싶은 말은 세 가지입니다.

  • 새로운 영역에서 개발자들의 역할은 점점 더 넓어지고 있다. 그래서 개발자들이 과거 역할에만 갇혀 있어서는 안된다. 사업이 안된다.
  • 실리콘밸리라고 해서 선진 문명이고 우리는 후진 문명이고 그런 것이 아니다. SW산업은 격차가 없다. 그래서 해결책의 도입에 기대기 보다 자체적인 문제 해결 능력의 확보가 더 중요하다.
  • 기술이 좀 더 쉬워져서 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 시스템이 [원가절감 설비]가 되느냐, [상품]이 되느냐 하는 것은 매우 큰 차이다. 전자는 1회성 투자로 끝나고 전문가에게 맡길수록 유리하다. 그러나 후자는 아마추어라도 반드시 회사와 운명을 같이 해야 한다. 즉 주인정신이 없으면 상품이 만들어질 수 없기 때문이다.

그리고, 전자는 외주 생산이므로 공정과 절차가 중요하지만 후자는 사람이 중요하다. 사람이 상품을 만드는 기술 원료이기 때문에 회사는 이 사람들을 활용해서 상품을 만드는 생산 시스템(체계, 문화)를 가지고 있어야 한다. 그런데 이 문화는 위키나 칸반보드 같은 것을 의미하지 않는다. 그런 것은 도구에 불과하다. 중요한 것은 대화와 듣기, 의사결정 과정, 일 나누기 등이다. 즉 훈련된 사람이 만들어 내는 협업 과정이 문화가 인터넷 서비스의 생산 공정인 것이다.

그래서 정성 들여 사람을 뽑고 생산성을 높일 수 있게 조직 훈련을 해야 한다. 지속적으로 좋은 팀웍이 유지 되도록 자극도 해야 한다. 인터넷 사업은 사람 관리 비용이 특히 높은 사업이다.

문제 인식과 개발자의 숙제

개인적으로 전통적인 산업영역은 크게 관심이 없다. 구축경험이 시장에 축적되었기 때문에 딱히 연구할만한 주제가 없기 때문이다. 많은 분들이 잘 알아서 하고 있고, 앞으로도 잘 할 것이다.

하지만, 인터넷 서비스 영역은 그렇지 않다. 많은 기업들이 도전하지만 성공하기 쉽지 않다. 다양한 원인이 있겠지만 IT 사업을 어떻게 다룰지 노하우가 거의 공유되고 있지 않다.* 융복합 사업이라면 난이도는 더 높아진다. 물론 개인은 답답하지 않다. 쉬운 사업을 하면 되니까.

문제는 국가 관점이다. IT기술의 가장 큰 장점은 [다양한 부가가치 창출 능력]인데 우리나라는 [인프라형 비용절감 산업]에 머물러 있다. 즉 산업 자생력이 엄청 낮다는 것이다. 자생력을 높이려면 시장에 다양한 자금이 흘러 다니고, 독립 고객층이 형성되어야 하는데 이 문제는 꽤 어려운 숙제다.

그런데, 조직 및 프로젝트 관리 문제는 보통 컨설팅 영역에서 다루어진다. 대부분 CEO나 회사 임원의 숙제이기 때문에 어느 정도 투자가 되고 있다. 하지만, 개발 방법론이나 기술 문제는 그렇지 못하다. 이 영역은 SW 개발자의 숙제인데 풀이가 매우 더디다. 잉여 시간이 많지도 않고 투자 여력도 없기 때문이다.

정해진 틀은 없다.

그래서 아직까지는 실리콘밸리의 성공 사례를 연구, 도입하고 있다. 최근의 대표 사례가 [애자일]이다. 기존의 폭포수 개발방식으로는 인터넷 사업에서 대응하기 힘들게 되자 도입한 것이다. 그러나 애자일은 일하는 방식에 대한 변화(가치 생산 방식)일 뿐 사람의 문제나 기술의 문제를 해결해 주지는 않는다. 그래서 기술 문제를 해결하기 위해 최근 주목 받는 것이 [마이크로 서비스 아키텍쳐]다.

그런데, [애자일]이나 [마이크로 서비스 아키텍쳐]가 생각해 보면 하늘에서 떨어진 특별한 것이 아니다. 단지 직면한 문제에 대해 개발자들이 해결책과 진화 방향을 스스로 고민한 것 뿐이다. 따라서 직면한 문제가 다르면 해결책도 달라지게 된다. 이 두 가지 사례에 대해 우리가 알아야 할 것은 이런 것들이다.

  • 실리콘밸리가 겪고 있는 조직적 기술적 문제가 우리 보다 앞서 있지 않다. 즉, 우리도 당장 현장에서 겪고 있는 문제이다. 적어도 SW산업 분야는 ‘선진국의 기술 수준이 10년 이상 뒤쳐져 있어요.’라는 멘트는 해당하지 않는다. 앞서 있다 아니다의 개념이 아니라, 다르다고 말하는 것이 맞다. 그래서 베끼는 것이 아니라 이해하고 배워서 응용을 해야 한다.
  • 우리의 실무 조직은 누군가 정해 주고 지시해주길 바라는 경향이 크다. 반면 실리콘밸리는 스스로 문제를 정의하고 함께 해결책을 찾는데 익숙하다. 즉, 우리도 능동적인 태도를 갖추게 되면 보다 빠르게 우리의 문제를 풀 수 있다는 뜻이다.
  • 개발자의 문제는 개발자들이 해결의 주체이어야 한다. 그리고 개발자의 문제란 상품을 잘 만들기 위해 필요한 외연의 것들도 함께 포함한다. 성공적인 해결 사례들을 더 많이 공유했으면 좋겠다.

(다음에 계속)

※ 주석 :

  • * 개발방법론 : 그냥 좋을 개발을 위해 지켜야 할 방법 이론 같은 거라고 느슨하게 정의.
  • * 노하우 공유 : 디캠프, 스타트업 얼라이언스 등이 좋은 프로그램들을 하고 있지만 전체 시장에 대한 절대량은 매우 부족하다. 특히 지방 창업의 경우는 지식 습득의 기회가 거의 없다.

※ 이전글 : 02. IT산업의 변화.
※ 졸저 소개 : IT 인프라 시대의 대한민국 IT (yes24, ebook)

Advertisements

답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중

정보

이 엔트리는 2017년 2월 1일에 님이 IT 산업이야기, 적정기술에 게시하였으며 , , , 태그가 지정되었습니다.

내비게이션

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