통합 검색어 입력폼

빅데이터와 하둡, 쉽게 제대로 이해하기

조회수 2016. 8. 12. 16:47 수정
음성재생 설정

이동통신망에서 음성 재생시
별도의 데이터 요금이 부과될 수 있습니다.

번역beta Translated by kaka i
번역중 Now in translation
글자크기 설정 파란원을 좌우로 움직이시면 글자크기가 변경 됩니다.

이 글자크기로 변경됩니다.

(예시) 다양한 분야의 재밌고 유익한 콘텐츠를 카카오 플랫폼 곳곳에서 발견하고, 공감하고, 공유해보세요.

쉽게 설명하는 빅데이터와 분산 처리 플랫폼 하둡

IT 분야에서 일하지 않는 독자 입장에서는 빅데이터가 아니라 하더라도 ‘데이터는 중요하다’는 건 알겠으나 분산 처리 플랫폼이라고 하는 하둡(Hadoop)이 뭔지, 뭘 배워야 빅데이터의 무슨 기술을 어떻게 써먹을 수 있는지 같은 건 모를 것입니다.


저는 친절하므로(…) 길~~~게 설명할 수 있습니다. 설명하는 거 좋아합니다. 너무 좋아해서 탈이죠. 이 시간에 일을 좀 더 열심히 해야 하는 거 아닌가 하는 불안감이 있습니다. IT 문외한을 위해 비유를 들어 설명하고 싶지만, 평소 비유 쓰는 걸 심히 좋아해서 지적을 자주 받았습니다. 


그래도 제가 좋아하니까 그냥 비유로 가겠습니다 (…)

기존 데이터베이스 = 큰 냉장고

많은 사람들이 빅데이터 이전에는 구석기 시대였던 것처럼 얘기하곤 하는데 웬만한 회사에서는 1960년대부터 데이터를 저장하고, 처리하고, 백업하고, 보고서를 만들었다. 회사 덩치가 조금만 커도 *데이터 웨어하우스가 있었습니다.
(**)


요식업에 비유하자면, 기존 데이터 웨어하우스나 데이터베이스는 큰 냉장고로 생각하면 됩니다.

*데이터 웨어하우스: 
data warehouse 혹은 enterprise data warehouse

**: 물론 지금도 있습니다. 빅데이터에 대해서 아무리 기사가 많다고는 하지만, 기본적으로 큰 회사 메인 데이터베이스는 오라클 등의 RDBMS가 99%일 것입니다.

당신은 피자집을 운영하고, 그 피자집 부엌에서는 피자 베이스(도우)에 여러 가지 토핑을 얹어서 판다고 해보죠. 피자를 빨리 만들기 위해 토핑을 종류별로 플라스틱 그릇에 넣어서 쭉 늘어놓습니다.


매일 피자집 문 열기 전에 재료를 다듬어서 냉장고에 가지런히 정리해두고 요리 카운터 위 플라스틱 그릇에도 재료를 덜어서 쭉 늘어놓습니다. 그리고 재료가 떨어지면 냉장고에서 다시 꺼내오는 거죠. 


재료를 데이터라고 할 때, 그 재료를 다듬어서 냉장고에 넣는 과정을 ‘ETL’이라고 합니다. 필요한 자료를 뽑고(Extract) 변형해서(Transform) 로딩한다(Load)는 뜻입니다. 재료 다듬어서 필요 없는 부분은 버리고 양념을 더하거나 요리해서 냉장고에 넣는 과정이 ETL입니다. 


그중에서 금방 쓸 재료를 그릇에 담아 손이 쉽게 닿는 곳에 놓는 것은, 자주 찾는 데이터를 메모리에 로딩해 두거나 좀 더 작은 테이블에 요약정리 버전을 저장해두는 데에 비유할 수 있습니다. 하드 디스크에서 읽는 것보다는 메모리에서 읽는 것이 훨씬 빠르고, 작은 요약 테이블을 만들어 놓으면 큰 테이블에서 찾기보다 쉽기 때문입니다.

냉장고 이용하는 법은 다 비슷비슷하다

그러므로 기존 데이터 웨어하우스는 들어오는 데이터를 ETL로 처리해서 데이터베이스에 저장하고(냉장고), 파워 유저들은 그 데이터로 보고서를 만들고 그래프를 만들고 합니다. 여기서 저장하고 데이터를 준비해두는 부분까지가 데이터 웨어하우스이고, 파워유저들이 그 데이터로 보고서를 만들고 그래프를 만들고 하는 부분을 보통은 *비즈니스 인텔리전스(BI), 즉 피자 만드는 사람이라고 할 수 있습니다.


그런데 누군가 ‘피자를 만들다 보니 새로운 재료가 필요해!’, 혹은 ‘다른 방법으로 재료를 요리하는 것이 필요해!’라고 하면 데이터 웨어하우스 팀에게 그 재료를 준비해 달라고 할 수 있겠죠? 


지난 30년 동안 사실 이 노하우는 거의 정형화되어 있었습니다. 물론 데이터가 들어오는 방법은 조금씩 다를 수 있고, 냉장고 브랜드가 다를 수도 있으며, 부엌 구조나 일하는 방식이 조금씩 다를 수도 있습니다.

*비즈니스 인텔리전스(BI): 

기업에서 데이터를 수집, 정리, 분석하고 활용하여 효율적인 의사결정을 하는 방법에 대한 연구입니다.

하지만 기본적으로 냉장고 쓸 줄 아는 사람이 다른 냉장고 쓰는 법을 특별히 배워야 하는 건 아니잖아요. *SQL을 할 줄 알면, 데이터베이스마다 조금씩 다르긴 해도 기본은 똑같습니다. 오라클이 유명했던 것은 전 세계 유수 식당에 냉장고, 그러니까 데이터베이스를 왕창 팔았기 때문이죠.


자, 여기서 주의해야 할 것은, 사실 BI는 빅데이터와는 큰 상관이 없습니다. BI의 기술 개발 및 혁신은 ‘피자 만들기’이지 ‘재료 공수법’이 아니어서 빅데이터 기술을 몰라도 할 수 있는 것들입니다. 


엄청 구하기 힘든 재료로 피자를 만든다고 해보죠. 중국에서 구한 백 년 된 달걀과 알래스카에서 구한 북극에 사는 어느 새의 알, 아프리카 사자 콩팥으로 만든 피자라고 해도 결국 토핑으로 만들어진 이상은 피자 위에 올리고 굽는 건 똑같습니다. 재료 구하는 방법이 달라진 것이지 만드는 사람 입장에선 별 차이가 없죠.(**)

*SQL: 

Structured Query Language; RDBMS의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어.

**: 물론 희귀한 재료라면 다듬는 방법을 따로 배워야 할 수는 있겠습니다만.

하둡, 혼자서 못하니 제대로 나눠서 한다!

자, 그럼 이제 “다들 하둡, 하둡 하는데 하둡이 뭐예요?”라고 질문하는 분들을 위해서 설명을 해보겠습니다.


여기서부터는 다른 비유로 넘어가겠습니다. 죄송합니다. 말씀드렸듯이 제가 비유를 좀(…) 좋아합니다. 


당신을 대학의 조교라고 해보죠. 시험을 치면 채점을 해야 합니다. 지금까지는 반을 하나만 맡았기 때문에 하루 날 잡아서 시험지 50장을 채점하면 끝이었습니다. 


그런데 대학의 예산 삭감으로 당신은 갑자기 200명의 시험지를 채점해야 할 상황이 됐습니다. 다행히 당신은 아주 열심히 일하고 좀 더 빨리 채점하는 방법을 개발함으로써 200명분의 시험지도 해결할 수 있게 됐습니다. (*)


그러자 대학은 당신이 이렇게 빨리 일을 해결했으면 상을 못 줄망정, 이젠 당신에게 대학교 학생 1만 명의 시험지를 싹 다 맡기면서 이것도 채점하라고 합니다. 


그런데 더 문제는 이 시험지는 당신이 모르는 과목이 대부분입니다! 시험 형식도 다 달라요! 안타깝게도 당신은 집에 애가 넷이라서 일을 때려치울 수도 없습니다. 이것을 어떻게 해결할까요? 


이렇게 되면 혼자 채점하는 것은 완전히 불가능하고(**), 친구들 몇 명 불러서 시키는 것도 불가능합니다.(***)

*: 버티컬 스케일링(Vertical scaling)이라고 합니다. DBA들이 퍼포먼스 튜닝하는 것도 이 방법에 해당합니다. 쉽게 말해 작은 서버를 쓰다가 서버 메모리도 늘리고 하드 디스크도 늘리고 더 빠른 CPU로 바꾸는 방법입니다.

**: 서버 하나의 메모리를 추가하거나 하드 디스크 용량 늘리기, 비싼 CPU로 바꾸기 등 버티컬 스케일링이 한계에 도달했다는 뜻입니다.

***: 제대로 되지 않은 분산 처리를 말하는 겁니다.
출처: 혼자서는 하기 버거울 때 일을 체계적으로 수행할 팀과 시스템이 필요하게 됩니다.

‘체계적으로’ 시험지를 나눠서 알바생들에게 주고, 알바생들이 각각 채점해오면 그것을 정리하고 종합해서 처리하는 방법이 필요합니다.(*)

알바생이 한 50명 된다면 그들 모두가 다 성실할 수는 없을 거예요. 누군가는 아플 수도 있고, 갑자기 상을 당할 수도 있고, 실연당하고 술을 너무 마셔 하기로 한 채점을 못 할 수도 있고, 더 좋은 알바 자리를 찾아 아예 학교에 안 나올 수도 있습니다.


그러므로 ‘알바생이 펑크를 낼 경우 대체할 방법’을 미리 만들어둬야 합니다. 미리미리 시험지 복사도 해둬야 합니다. 알바생에게 시험지를 그냥 줬다가 술 처먹고 잃어버리거나 도둑맞거나 하면 안 되잖아요? 


그렇게 관리하고 처리하고 복사본도 만들어두고 혹시라도 펑크내면 수습하며 채점한 시험지를 다 모아서 결과를 보고하도록 하는 시스템이 ‘하둡’입니다. 간단히 말해, 분산처리 시스템이죠.

*: 호라이즌탈 스케일링이 필요하다는 뜻입니다.

새로운 걸 만드는 사람에겐 큰 변화, 하던 거 하던 사람은 오히려 불편

비유를 다시 냉장고와 피자로 들겠습니다 (…)


슈퍼마켓에서 재료를 사다가 다듬어서 냉장고에 넣어뒀다가 피자 토핑으로 올려서 파는 피자 가게가 보통의 패러다임이었다고 하죠. 그러다가 정말 구하기 힘든 재료를 아프리카에서 공수하고 알래스카에서 날라온 재료와 조합을 해서 섬세한 타이밍에 맞춰 이탈리아의 장인이 만든 치즈를 섞어 파는 피자를 개발한다고 해봐요. 


실제로 피자 만드는 사람 입장에서는 어쨌든 다듬어진 재료 가지고 피자 만드는 건 똑같습니다. 그렇지만 예전과 달리 타이밍 맞추고 재료 조합하고 하는 것이 더 까다로워졌습니다.

이것이 데이터 분석하는 사람들의 입장입니다. 내가 피자를 디자인하는 사람이 아닌 이상은, 예전에 하던 일과 똑같지만, 오히려 더 만들기 까다로워졌다는 것 혹은 사용하는 도구가 달라진 것밖에 못 느낄 수 있습니다.


예전에는 빠른 SQL 서버에서 잘 정리된 데이터를 분석했었는데, 이제는 느린 하이브(Hive)로 돌려야 합니다. SQL과 비슷한 것 같으면서 하이브는 훨씬 더 느리고 불편합니다. 


페이스북이 개발한 하이브의 엄청난 파워라면 바로 ‘아프리카의 재료’와 ‘알래스카의 재료’를, 동네 슈퍼에서 사는 것과 거의 비슷하게 제공한다는 것인데, 보고서 작성하는 사람이야 그게 뭔지 알 바 아니고 편하게 냉장고에서 꺼내 쓰고 싶은 사람 입장에서는 그저 불편해진 것만 보일 수 있다는 거죠.

하이브는 “재료 다듬기 방법”이라고 할 수 있습니다. 예전 방법은 SQL인데, 하이브는 SQL과 비슷해 보이지만 조금씩 다릅니다. 훨씬 더 큰 용량의 데이터를 처리할 수 있는 장점이 있지만, SQL만 돌렸던 사람이라면 훨씬 느리게 느낄 수 있습니다.

위에서 말했듯이 실제로 피자 만드는 사람(데이터 분석가) 입장에서는 툴이 좀 느려지고 복잡해진 거 외에는 별다른 점이 없을 수 있으나, 두 분야의 사람에게는 천지개벽과도 같은 미친 듯한 변화를 의미한다. 이 두 분야의 사람이란 하나는 피자 디자인하는 사람이고, 다른 하나는 재료 조달 팀입니다.


피자를 디자인하는 사람은 예전에는 슈퍼마켓에서 고르고 골라 토핑 재료를 구했다면, 이제는 전 세계에서 엄청나게 다양한 재료가 갑자기 ‘펑!’하고 생겨난 셈이라 무한한 가능성으로 정말 신나고 즐겁고 피자 메뉴를 디자인할 맛이 날 겁니다. 


그러므로 지금까지 계속 데이터로 뭔가 하려던 사람들에게 빅데이터는 엄청나게 다양한 데이터를 분석할 수 있다는 말이고, 이전에는 꿈도 못 꾸던 분석과 연구를 할 수 있다는 뜻입니다. 그렇지만 데이터를 이해하지 못하는 사람 – 그냥 주어진 자료로 윗분들이 원하시는 리포트 정도 만드는 입장에서는 빅데이터라는 게 별 의미가 없습니다.

빅데이터 엔지니어의 미래

참, ‘시각화(data visualization)’는 빅데이터에서 ‘레스토랑 인테리어’에 해당한다고 할 수 있습니다. 다양한 재료로 특이한 메뉴를 개발하면 당연히 좋겠지만, 그런 거 없어도 인테리어는 충분히 멋있게 할 수 있잖아요?


인테리어 업자가 공사할 때, 그 식당이 어떤 음식 파는지 참고는 하겠지만, 재료 조달을 어떻게 하는지, 부엌 내에서 어떻게 일 흐름을 관리하는지는 알 필요가 없죠.

시각화는 예전에도 있었습니다. 단지 인터넷·모바일의 폭발과 빅데이터 현상이 맞물리면서 온갖 툴이 쏟아졌을 뿐입니다. 안 중요하다는 건 아니고, 아주 대단한 프로그래밍 실력 없이 시각화를 잘할 수 있는 툴이 많다는 뜻입니다.


재료 조달 팀에게 빅데이터는 사실 악몽입니다. 예전에는 오토바이 타고 동네 슈퍼마켓에 가서 이것저것 산 후 가지런하게 정리·정돈만 해주면 됐는데, 이제는 온 세계로 날아가서 공수해와야 하고, 엄청난 양의 재료를 예전과 다름없이 쓸 수 있도록 해줘야 하기 때문이죠. 여기서 빅데이터의 분야가 갈라집니다. 


지난 십 년간 IT 산업의 혁명적인 변화라면 상용화된 분산처리, IT 인프라 아웃소싱과 데이터인데 이게 안 중요하다는 게 아니고, 이제는 데이터 엔지니어링과 *스케일 아웃(scale out) 엔지니어링이 다른 분야로 따로 떨어져 나가서 데이터 분석하는 사람 입장에서는, 특히 이미 데이터 엔지니어링 팀이 데이터 파이프라인/인프라를 만들어두었거나 벤더의 제품을 쓰는 회사에서는 그리 큰 기술 없이도 데이터 사용이 가능합니다.

*스케일 아웃(scale out) 엔지니어링:

서버의 수를 늘려 데이터 처리 능력을 향상하도록 하는 것. 서버의 성능을 향상하게 하는 방법은 스케일 업(scale up)이라고 한다.

그래서 빅데이터의 “빅”은 데이터 엔지니어가 걱정할 일이고 데이터 분석하는 사람은 걱정 안 해도 됩니다. 큰 회사에서는 대부분 자신만의 데이터 수집 처리 파이프라인을 만들고 있긴 한데, 이마저도 빠르게 아웃소싱 조짐을 보이고 있습니다.


(우리 팀을 포함해서) 웬만큼 큰 테크 회사에서는 특수화하지 않은 데이터 수집처리 파이프라인 서비스(generic data service)를, KPMG 같은 회사에서는 회계뿐 아니라 자신들이 운영 방식을 잘 이해하는 기업에 팔 수 있는 데이터 모델이나 컨설팅, 그 외 데이터 상품을 준비하고 있습니다. 데이터 엔지니어링이 지금 AWS 인프라 서비스만큼 상용화·표준화되는 날이 얼마 안 남았어요. 


하둡 엔지니어나 그 외 데이터 엔지니어들에게 안 좋은 소식 같지만, 딱히 그렇지도 않을 거예요. 어차피 그쪽 사람들은 거의 다 컴퓨터 사이언스 전공 기반인 사람들이었지 ‘데이터 엔지니어 학위’ 따서 온 사람은 없을 거니까요. 코딩은 그냥 코딩이고 분산처리는 앞으로도 한참 갈 거라 걱정 안 해줘도 잘 사실 것 같습니다.

다음에는 데이터 엔지니어링에 대해서 좀 더 자세히 알아보도록 하며, ‘코딩, 학원으로 되는가’, ‘컴퓨터 사이언스를 공부해야 하는가’ 등에 관해서도 설명해보도록 하겠습니다. (필자)

슬로우뉴스 좋으셨나요?

이미지를 클릭 하시면 후원페이지가 열립니다.
이 콘텐츠에 대해 어떻게 생각하시나요?