(12) 가트너의 Hype Cycle을 아시나요?

[IT의 중심에서] (12) 가트너의 Hype Cycle을 아시나요?

1532
SHARE
GettyImages

소프트웨어 개발자 김수보님의 글을 모비인사이드에서 소개합니다.

가트너의 “하이프 싸이클”. 신규 구축을 주로 하는 컨설팅이나 SI 업체들은 대부분 잘 알고 계신데, 주로 개발 일만 하는 분들은 잘 모르시더라고요. 당장 자신과 관련이 없는 일이기도 하고…

라고 생각하지만, 이게 시장이 기술인력을 구하는 트렌드이기 때문에 이직, 창업, 정부 프로젝트 수요 등과 관련이 깊습니다. 그래서 간단히 정리해 봅니다.

“가트너”란?

1979년 세워진 미국의 정보기술 자문회사입니다. 쉽게 말하면 IT 컨설팅 회사. 하지만, 시장조사, 연구조사를 열심히 하기 때문에 세계적으로도 인지도가 높은 회사입니다.

 

“Hype Cycle”이란?

가트너사가 처음 만든 개념입니다. Hype란 과장되거나 부풀려진 어떤 것을 말합니다. Hype Cycle이란 직역하면 과장 곡선 정도가 됩니다. 내용은 기술에 대한 시장의 기대가 어떻게 변하는지 경험적으로 정리한 것입니다.

실험적 과학적으로 증명된 것은 아니어서 지나고 보면 빗나간 예측도 많습니다. 하지만, 크게 보면 경험적으로 대략 일치하기 때문에 전략을 수립할 때 많이 참고되는 자료입니다.

X축이 시간이고 Y축이 시장의 기대입니다. 1990년대 인터넷이 뜨면서 수많은 미디어가 수많은 예측을 쏟아냈는데, 대부분 틀린 것이 많았습니다. 덕분에 왜 그런 예측들이 빗나갔을까 하는 연구들이 이어지면서 이 곡선이 탄생하게 되었습니다.

 

어떤 영향을 미치나?

시스템을 신규로 구매/구축하려는 사람은 가능하면 뜨는 기술을 써보고 싶어 합니다. 그래서 뜨는 기술이 뭔지 궁금합니다.

일반 조직은 어떤 문제를 해결해준다는 신기술이 궁금합니다. 들어 보니 우리 회사에도 그런 문제가 있는 것 같습니다. 그래서 신기술 도입을 통해 그 문제를 풀어 보고 싶어 합니다.

정부는 혁신 견인 차원에서 같은 값이면 신기술을 도입해 보고싶어 합니다. 또는 사회 경쟁력 강화 차원에서 신기술 연구개발을 지원하고자 합니다.

(기술) 창업자는 가능하면 신기술을 사용하는 것이 아무래도 시장의 주목 효과가 높아집니다.

위 네 가지 케이스가 시장에서 기술자나 기술회사를 찾는 수요를 높여줍니다. 즉, 시장의 이직기회가 높아지고, 기술가격이 높아지게 됩니다. 즉, 개발자 개인에게는 취업 시장과 맞닿아 있습니다.

 

자세히 살펴 보면

Hype Cycle 은 5단계로 움직입니다. 위키피디아를 참조했습니다.
※ 링크 : Hype cycle 

(1) 기술촉발 Technology Trigger

기술이 관심을 받는 시기입니다. 하지만, 아직 상용제품은 없습니다. 가설과 소설만 있습니다. 이 시기는 미디어가 견인을 합니다. 즉, 미디어가 세상이 바뀔 것처럼 떠들면 사람들이 관심을 가지는 시기입니다.

(2) 기대 거품의 정점 The Peak of Inflated Expectations

선도 업체에 의해 성공스토리와 실패스토리가 나오기 시작하는 시점입니다. 일부 기업들은 사업에 착수하기도 하지만, 대부분의 기업은 관망을 합니다.

(3) 환멸의 계곡 Trough of Disillusionment)

대부분의 도전들이 실패합니다. 그리고 많은 기업들이 사업화를 포기합니다. 살아남은 업체들만 투자를 계속합니다.

(4) 깨우침의 단계 (Slope of Enlightenment)

수익모델 사례가 생기면서 시장이 이해를 합니다. 아, 이 기술은 저렇게 쓰는구나. 버전도 2.0 이나 3.0 정도 됩니다. 그래서 기술에 투자를 해 보는 기업들이 조금 더 늘어납니다. 하지만, 보수적인 기업은 여전히 관망을 합니다.

(5) 생산성의 안정기 (Plateau of Productivity)

기술이 시장에서 자리를 완전히 잡습니다. 사업적 생존가능성에 대한 평가 기준도 명확해집니다. 해외시장 진출에 대한 적정성 및 타당성이 높아지면서 성공을 거두기도 합니다.

 

이 곡선의 단점과 교훈

경험적으로 오랫동안 관찰된 사실로 정리된 곡선이라 틀릴 수 있습니다. 돌이켜 보면 뜨다가 만 기술도 있고, 환멸의 계곡에 빠졌다가 사라져 버린 것도 많습니다. 그리고 무엇보다 저 사이클기간이 기술마다 다릅니다. 성과가 날 때까지 한 호흡이 긴 기술도 있고, 아닌 기술도 있습니다.

하지만, 매년 가트너가 저 곡선을 그리는 걸 보면 대략 1년 후 피크, 2년 후 하락, 3년 후 환멸의 계곡, 이렇게 되는 것 같습니다. 곡선 주기가 기술의 성숙도보다는 사업성 평가주기에 의존성이 높은 것 같습니다.

그래서 뜨는 기술을 보고 취업전략, 이직전략을 세우면 망할 수도 있습니다. 참고로, 꾸준히 시장에서 요구되는 응용기술은 여기 안 나옵니다. 디자인, 웹, DB, 서버 엔지니어링 등은 꾸준히 요구되는 셈입니다. 대신 사람이 많아서 경쟁이 치열합니다.

 

우리나라는 실리콘밸리와 다르다.

Web2.0, 위성통신, 사물인터넷 등… 미디어나 IT 사업가들은 새로운 수요를 자극하기 위해 계속해서 새로운 이야기를 합니다. 그러면 사업 전략과 계획이 수립되고 예산이 책정되는 것은 미국과 우리나라가 비슷합니다.

하지만 (4), (5) 단계를 거치면서 우리나라는 미국과 달라집니다. 시장이 달라 미국에서 성공한 기술도 우리나라에서 실패하기 때문입니다.

기술은 노하우를 축적하고 이슈를 선점해야 시장을 선도할 수 있는데 그게 잘 안되는 것입니다. 우리나라는 대부분 (3) 단계를 넘지 못하고 (4), (5) 단계에서 미국에서 개발된 것을 사다 쓰게 됩니다. SI 같은 IT 아웃소싱이 발달하는 이유입니다.

물론, 간혹 성공 케이스가 나오는데 많지 않습니다. 주류가 되려면 복제 가능해야 하는데 어렵습니다. 즉, 그 사례에만 기대서는 산업 발전이 어려운 것입니다.

 

그래서…? (1)

산업발전은 너무 큰 주제입니다. 전, 개인 개발자 관점만 이야기해봅니다.

뜨는 기술을 따라 다녀 보니까 생각보다 체력이 많이 필요합니다. 체력이 필요하다는 것은 누군가에게 보여주거나 입증해줘야 하는 경우가 많다는 뜻입니다. 오류나 장벽에 많이 부딪힌다는 뜻입니다. 뜻대로 잘됩니다. 깡도 필요하고 시간도 많이 투자해야 합니다. 야근도 잦고 공부도 열심히 해야 한다는 뜻입니다.

뜨는 기술이 곧 사업적 성공을 의미하는 것은 아닙니다. 많은 기업들이 (2) 단계나 (3) 단계에서 피봇이나 다른 기술로 많이 갈아탑니다. SI 기업들은 특히 그렇습니다. (4), (5) 단계쯤 가 있는 기업들은 기술 하나만 파지 않습니다. 두세개 정도의 주력 기술군을 가지고 있습니다.

그리고 기술이 잘 뜨려면, 응용기술이나 일반기술들이 잘 받쳐줘야 합니다. 그런 기술들은 핵심기술들을 소비자에게 잘 보여주기 위한 전달기술(?)이기 때문입니다. API 같은 인프라 기술이 아니라면, 디자인은 어디에나 중요한 상품화 기술입니다.

 

그래서…? (2)

시스템 개발은 팀이 하는 일이고, 팀은 곧 사람입니다. 그리고, 기술이 상용제품이 되려면 꽤 많은 장애해결이력 (Trouble Shooting Knowledge base)과 관련 사업 경험자들을 보유해야 합니다. 그래서 기술 기업은 이런 사람들을 길러내고 유지하는데 꽤 많은 투자를 합니다.

Hadoop은 2013년 빅데이터라는 화두로 주목받기까지 약 7년 정도의 성장 기간이 있었습니다. 구글, 네이버 등에서는 이미 쓰고 있었지만, 구매 가능한 IT 요소기술로 거론되기까지는 시간이 걸린 것입니다. 개인적으로는 지금도 시장에 잘 안착했다고 보진 않습니다.

Hadoop 초반에는 관련 개발자들의 몸값이 천정부지로 치솟았습니다. 그래서 사정을 잘 모르는 사람들은 그것만으로 부러워했습니다. 하지만, 그 시간은 얼마 가지 못했습니다.

요약하자면, 트렌드를 잘 읽어야 하지만 그것이 자만과 오만이 아니었으면 좋겠습니다. 간혹, 개발자의 자만을 믿고 사업을 벌였다 실패한 분들을 적지 않게 보았습니다.

그리고 이런 실패경험이 “IT 사업은 어렵다. 실패율이 높다. 꽤 돈이 많이 드는 사업이다.”라는 시장 인식으로 이어지는 것 같아 마음이 불편했습니다. 서로 윈윈하는 경우가 많았으면 좋겠습니다.

 

[IT의 중심에서] 시리즈

(11) DevOps 란 무엇일까?
– (10) 개발상식1. 콘웨이의 법칙
– (9) 스타트업 개발자
– (8) 개발자 역할의 변화
– (7) 스타트업, 서비스 개발자가 되자

 

 

Comments