글로벌 칼럼 | 우리는 하둡에 대해 아는 게 거의 없었다
OSS
게시글 작성 시각 2016-11-18 10:07:13
2016년 11월 18일 (금)
ⓒ ITWorld, Matt Asay | InfoWorld
하둡이 빅데이터의 대명사로 여겨지며 모든 기업에 빅데이터 바람을 일으킨 것은 그다지 오래된 일이 아니다.
![](http://files.idg.co.kr/itworld/image/2016/10/hadoop.jpg)
그런데 이제는 오범(Ovum) 분석가 토니 베어가 말했듯이 "하둡의 정점(peak Hadoop)"에 이르렀다는 뚜렷한 징후들이 있다. 그러나 가장 명백한 신호는 아마도 '하둡'에 아무런 하둡도 남아 있지 않다는 사실일 것이다.
또는 인포월드의 앤드류 올리버의 표현대로 "하둡에 대해 알아야 할 가장 중요한 점은 더 이상 하둡이 아니라는 것"이다. 이는 다른 무엇보다 최신 클라우드 워크로드에서 하둡 대신 스파크(Spark)와 같은 더 참신한 옵션이 많이 사용된다는 데서 가장 잘 드러난다.
기업 IT의 다른 많은 부분과 마찬가지로 클라우드가 하둡을 죽인 것이다. 또는 하둡이 너무 빠르게 움직인 탓에 하둡을 죽였다고 볼 수도 있다. 어떻게 된 일인지 살펴보자.
'하둡'은 이제 과거의 유산?
물론 하둡이 완전히 추락한 것은 아니다. 베어가 말했듯이 하둡의 데이터 관리 기능은 아직 스파크를 비롯한 다른 전용 빅데이터 클라우드 서비스가 따라잡지 못한 부분이다. 게다가 스파크를 사용한 메모리 내 실시간 분석에 집중하기 때문에 하둡을 사용하지 않는다 해도 결국 여기저기서 하둡의 조각들을 사용하게 된다는 것이 올리버의 설명이다.
그러나 전반적으로 하둡은 지금과 같은 클라우드 시대에 확실히 과거의 기술로 보인다. 하둡 벤더들도 떠나는 중이다. 물론 클라우데라(Cloudera)는 여전히 클라우데라 엔터프라이즈가 "아파치 하둡" 기반이라고 말한다.
그러나 클라우드 아키텍처의 구성 요소를 살펴보면 그 면면은 하둡이 아니다. IBM은 빅인사이트(BigInsights) 제품군 내부에 여전히 하둡을 사용하지만 최신의 왓슨 데이터 플랫폼(Watson Data Platform)에서는 하둡을 찾아볼 수 없다.
이유는 물론 클라우드다
이런 면에서 "IBM이 클라우드 기반 빅데이터 협업 허브를 만든다는 사실은 스파크 대 하둡의 문제라기보다는 클라우드 대 하둡의 문제"라는 베어의 말은 정곡을 찌른다.
하둡은 '빅데이터'를 가리키는 마케팅 유행어로 여전히 브랜드 가치를 지니고 있지만 애플리케이션이 클라우드에 상주하는 경우가 증가함에 따라 그 구성 요소(HDFS, 맵리듀스(MapReduce), 얀(YARN))들은 대부분 더 새롭고 더 빠른, 클라우드 친화적인 대안을 찾아 하둡을 떠나고 있다.
변화는 끊임없지만 그래야 할까?
하둡을 만든 더그 커팅은 끊임없이 변화해야 한다고 주장한다. 커팅은 하둡이 스파크로 대체되었거나 관련성을 잃었다는 주장에 대해 코웃음을 쳤지만 그 역시 소프트웨어 진화에서 비롯되는 힘을 인정한다.
클라우데라의 클라우드 스택에 더 이상 하둡 요소가 없다는 지적에 대해 커팅은 트위터를 통해 "오픈소스 플랫폼이 더욱 빠르게 진화하고 개선된다는 증거다. 10년 내에 전체 스택이 교체된다! 경이로운 일"이라고 말했다.
이 말이 내포한 힘을 간과하기 쉽다. 커팅이 일반적인 기업용 소프트웨어 벤더 창업자였다면 자신이 낳은 하둡이 못 생겼다는, 그래서 대체해야 한다는 암시적 비난을 인정하지 않음은 물론, 고객을 자사의 제품 안에 가두기 위해 가능한 모든 수단을 동원했을 것이다.
소프트웨어 벤더들은 시장이 이미 지나갔다 해도 과거의 기술을 곧잘 팔아 치운다. 장기적인 계약에 묶인 고객은 시장만큼 빠르게 움직일 수도 없고 움직이고자 하지도 않는다.
그러나 하둡과 같은 오픈소스 프로젝트는 진화에 거부감이 없다. 사실 그 반대다. 가끔은 시장이 소화할 수 없을 만큼 너무 빠르게 움직인다는 점이 오픈소스의 큰 문제가 될 정도다.
역설적이지만 하둡에서도 일정 부분 이러한 현상이 나타났다. 1년 반 전, 가트너는 하둡에 대한 미디어의 큰 관심에도 불구하고 하둡의 도입이 "미적지근하다"고 지적했다. 스파크, 몽고DB, 카산드라, 카프카와 같은 다른 빅데이터 인프라는 빠른 속도로 하둡을 지나쳐 행진했다.
그러나 기술적 발전이 전부는 아니다. 하둡의 시장 도입이 빈약했던 이유 가운데 하나는 그 복잡성에 있다. 하둡 기술은 항상 하둡 요구를 따라가지 못했다.
이런 복잡성은 빅데이터 스택의 빠른 발전 속도로 인해 더욱 악화됐다. 물론 스파크와 같은 일부 구성 요소는 사용하기 쉬운 편이지만 끊임없이 변화하는 다른 온갖 구성 요소와 결합해야 한다면 이야기는 달라진다.
그렇게 보면 리눅스와 같이 하둡의 유효 기간이 좀더 길었다면 좋았을 것이다. 리눅스에서도 모듈은 끊임없이 변화한다. 그러나 리눅스에는 "리눅스 관리"라는 말이 수십년 이상 실질적 의미를 가질 수 있게 해주는, 시스템 레벨의 충실도가 있다.
반면 다양한 빅데이터 프로젝트를 일일이 따라가기란 훨씬 더 어려운 일이다. 간단히 말해 하둡의 빠른 발전 속도는 그 유연성의 증거이기도 하고, 우려의 원인이 되기도 한다.
![](http://files.idg.co.kr/itworld/image/2016/10/hadoop.jpg)
그런데 이제는 오범(Ovum) 분석가 토니 베어가 말했듯이 "하둡의 정점(peak Hadoop)"에 이르렀다는 뚜렷한 징후들이 있다. 그러나 가장 명백한 신호는 아마도 '하둡'에 아무런 하둡도 남아 있지 않다는 사실일 것이다.
또는 인포월드의 앤드류 올리버의 표현대로 "하둡에 대해 알아야 할 가장 중요한 점은 더 이상 하둡이 아니라는 것"이다. 이는 다른 무엇보다 최신 클라우드 워크로드에서 하둡 대신 스파크(Spark)와 같은 더 참신한 옵션이 많이 사용된다는 데서 가장 잘 드러난다.
기업 IT의 다른 많은 부분과 마찬가지로 클라우드가 하둡을 죽인 것이다. 또는 하둡이 너무 빠르게 움직인 탓에 하둡을 죽였다고 볼 수도 있다. 어떻게 된 일인지 살펴보자.
'하둡'은 이제 과거의 유산?
물론 하둡이 완전히 추락한 것은 아니다. 베어가 말했듯이 하둡의 데이터 관리 기능은 아직 스파크를 비롯한 다른 전용 빅데이터 클라우드 서비스가 따라잡지 못한 부분이다. 게다가 스파크를 사용한 메모리 내 실시간 분석에 집중하기 때문에 하둡을 사용하지 않는다 해도 결국 여기저기서 하둡의 조각들을 사용하게 된다는 것이 올리버의 설명이다.
그러나 전반적으로 하둡은 지금과 같은 클라우드 시대에 확실히 과거의 기술로 보인다. 하둡 벤더들도 떠나는 중이다. 물론 클라우데라(Cloudera)는 여전히 클라우데라 엔터프라이즈가 "아파치 하둡" 기반이라고 말한다.
그러나 클라우드 아키텍처의 구성 요소를 살펴보면 그 면면은 하둡이 아니다. IBM은 빅인사이트(BigInsights) 제품군 내부에 여전히 하둡을 사용하지만 최신의 왓슨 데이터 플랫폼(Watson Data Platform)에서는 하둡을 찾아볼 수 없다.
이유는 물론 클라우드다
이런 면에서 "IBM이 클라우드 기반 빅데이터 협업 허브를 만든다는 사실은 스파크 대 하둡의 문제라기보다는 클라우드 대 하둡의 문제"라는 베어의 말은 정곡을 찌른다.
하둡은 '빅데이터'를 가리키는 마케팅 유행어로 여전히 브랜드 가치를 지니고 있지만 애플리케이션이 클라우드에 상주하는 경우가 증가함에 따라 그 구성 요소(HDFS, 맵리듀스(MapReduce), 얀(YARN))들은 대부분 더 새롭고 더 빠른, 클라우드 친화적인 대안을 찾아 하둡을 떠나고 있다.
변화는 끊임없지만 그래야 할까?
하둡을 만든 더그 커팅은 끊임없이 변화해야 한다고 주장한다. 커팅은 하둡이 스파크로 대체되었거나 관련성을 잃었다는 주장에 대해 코웃음을 쳤지만 그 역시 소프트웨어 진화에서 비롯되는 힘을 인정한다.
클라우데라의 클라우드 스택에 더 이상 하둡 요소가 없다는 지적에 대해 커팅은 트위터를 통해 "오픈소스 플랫폼이 더욱 빠르게 진화하고 개선된다는 증거다. 10년 내에 전체 스택이 교체된다! 경이로운 일"이라고 말했다.
이 말이 내포한 힘을 간과하기 쉽다. 커팅이 일반적인 기업용 소프트웨어 벤더 창업자였다면 자신이 낳은 하둡이 못 생겼다는, 그래서 대체해야 한다는 암시적 비난을 인정하지 않음은 물론, 고객을 자사의 제품 안에 가두기 위해 가능한 모든 수단을 동원했을 것이다.
소프트웨어 벤더들은 시장이 이미 지나갔다 해도 과거의 기술을 곧잘 팔아 치운다. 장기적인 계약에 묶인 고객은 시장만큼 빠르게 움직일 수도 없고 움직이고자 하지도 않는다.
그러나 하둡과 같은 오픈소스 프로젝트는 진화에 거부감이 없다. 사실 그 반대다. 가끔은 시장이 소화할 수 없을 만큼 너무 빠르게 움직인다는 점이 오픈소스의 큰 문제가 될 정도다.
역설적이지만 하둡에서도 일정 부분 이러한 현상이 나타났다. 1년 반 전, 가트너는 하둡에 대한 미디어의 큰 관심에도 불구하고 하둡의 도입이 "미적지근하다"고 지적했다. 스파크, 몽고DB, 카산드라, 카프카와 같은 다른 빅데이터 인프라는 빠른 속도로 하둡을 지나쳐 행진했다.
그러나 기술적 발전이 전부는 아니다. 하둡의 시장 도입이 빈약했던 이유 가운데 하나는 그 복잡성에 있다. 하둡 기술은 항상 하둡 요구를 따라가지 못했다.
이런 복잡성은 빅데이터 스택의 빠른 발전 속도로 인해 더욱 악화됐다. 물론 스파크와 같은 일부 구성 요소는 사용하기 쉬운 편이지만 끊임없이 변화하는 다른 온갖 구성 요소와 결합해야 한다면 이야기는 달라진다.
그렇게 보면 리눅스와 같이 하둡의 유효 기간이 좀더 길었다면 좋았을 것이다. 리눅스에서도 모듈은 끊임없이 변화한다. 그러나 리눅스에는 "리눅스 관리"라는 말이 수십년 이상 실질적 의미를 가질 수 있게 해주는, 시스템 레벨의 충실도가 있다.
반면 다양한 빅데이터 프로젝트를 일일이 따라가기란 훨씬 더 어려운 일이다. 간단히 말해 하둡의 빠른 발전 속도는 그 유연성의 증거이기도 하고, 우려의 원인이 되기도 한다.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.itworld.co.kr/news/102168]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 316120 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 305718 | 2020-10-27 |
5921 | 밸브, 스팀VR 리눅스와 macOS 버전 곧 내놓는다 | 4398 | 2016-11-22 |
5920 | MS 개발자에 손 내민 삼성전자, “타이젠에 닷넷 도입” | 3888 | 2016-11-22 |
5919 | 파이어폭스, 데뷔 12년만에 정식 50버전 도달 | 4404 | 2016-11-22 |
5918 | 리눅스 전환한 뮌헨시, 다시 윈도 쓰나 | 4064 | 2016-11-22 |
5917 | 실리콘밸리 개발자들 트럼프 싫다면 中 오라 | 3773 | 2016-11-22 |
5916 | IDG 블로그 | 리눅스용 SQL 서버가 제일 중요한 이유 | 3679 | 2016-11-22 |
5915 | 윈도10 대안 리눅스?…'조린OS' 12 정식판 공개 | 4035 | 2016-11-22 |
5914 | 새 우분투 리눅스 노트북, 4K 해상도에 엔비디아 파스칼 GPU 탑재 | 4114 | 2016-11-22 |
5913 | 리눅스에 더 몰입하는 MS…"클라우드 때문에" | 3640 | 2016-11-22 |
5912 | 글로벌 칼럼 | 우리는 하둡에 대해 아는 게 거의 없었다 | 3748 | 2016-11-18 |
0개 댓글