2020.05.28

글로벌 칼럼 | 레디스가 바꾼 DB 시장, SW 혁신은 '가려운 곳'에서 시작된다

Matt Asay | InfoWorld
굳이 새 데이터베이스를, 특히 2009년 당시 지배적인 데이터베이스 클래스 관점에서 전혀 무의미했던 인메모리 데이터베이스를 만든 이유가 무엇이었을까? 사실 살바토레 산필리포는 그런 것에는 관심이 없었다. 데이터베이스에 대한 다른 사람의 생각을 바꾸려 한 것이 아니라, 단지 실시간 분석 엔진을 확장해야 했는데 마이SQL은 비용 효율적이지 않았을 뿐이다. 그래서 탄생한 것이 바로 레디스(Redis)였고 이후 데이터베이스 시장은 완전히 바뀌었다.
 
© Getty Images Bank

지난 몇 주 동안 산필리포 같은 오픈소스 프로젝트 설립자와 대화하면서 놀란 점도 이것이었다. 특정한 한 가지 필요(오픈소스 용어로 '가려운 곳(itch)')에 대한 답을 찾고자 시작한 오픈소스 프로젝트가 결과적으로 해당 제품의 범주 자체를 바꿔 놓는 경우가 많다는 사실이다. 그들은 유용한 뭔가를 만들고자 했을 뿐이지만 결과적으로 '혁신적인 뭔가'를 만들어 버렸다. 궁금증이 생겼다. 여러분의 기업이 혁신을 위한 새로운 방법을 찾는 중이라면, 혹시 직원에게 오픈소스에 더 깊이 참여하도록 독려한 적이 있는가?
 

새로운 것 탐색하기

우리는 레거시 기술의 익숙한 루틴에 머무르는 경우가 있다. 산필리포는 "트위터 대화에서 모든 문제가 해결된 것처럼 보여도, 특정 소프트웨어 영역에서는 새로운 것을 탐색하는 것이 가능하다"라고 말했다. 실제로 관계형 데이터베이스(RDBMS) 시장은 수십 년 동안 정체 상태였다. 새로운 기능이 등장하고 새로운 훌륭한 오픈소스 데이터베이스도 나왔지만(마이SQL, 포스트그레SQL), 여전히 행과 열에 이것저것을 집어넣는 방식이었다. 그것이 데이터를 다루는 '올바른 방법(right way)'이었기 때문이다.

그러나 어쩌면 '올바른' 방법이 아니었을 수도 있다. 대부분은 맞았을 수 있지만 항상 그런 것은 아니었다. 예를 들어 일부 데이터는 관계형 모델에 적합하다. 특히 ERP 시스템과 같은 레코드 시스템이 그렇다. 하지만 세계가 인게이지먼트(engagement) 시스템으로 옮겨가면서 정형/반정형 데이터의 비중은 크게 줄어들었다. 관계형 모델에서는 데이터를 2차원 테이블 구조로 바꿔야 한다. 반면 몽고DB(MongoDB) 같은 문서 데이터베이스는 현대 프로그래밍 언어의 객체 구조와 더 잘 어울리는 다채로운 동적 데이터 모델을 제공한다.

이 데이터베이스가 저 데이터베이스보다 더 낫다고 말하려는 것이 아니다. 각자 더 잘 맞는 작업이 있고, 우리가 비정형 데이터를 관계형 형식으로 억지로 밀어 넣느라 오랜 시간을 낭비하고 있었던 것일지도 모른다는 것이다. 산필리포가 말했듯 데이터베이스가 '해결된' 문제라고 판단했고 그 실수의 대가로 많은 생산성을 잃었다(이런 실수는 비단 데이터베이스만의 문제는 아니다).
 

모방에서 혁신으로

오픈소스의 초창기에 리눅스, 마이SQL과 같이 비교적 잘 알려진 일부 프로젝트는 유닉스나 오라클 등 각각 대응하는 값비싼 독자 규격 제품의 기능을 모방하기 위해 노력했다. 그러나 시간이 지나면서 모방이 아닌 혁신을 추구하게 됐다. 동시에 새로운 영역을 개척하거나 기존 영역을 새로운 방식으로 접근해 사용자 기반을 크게 확대한 프로젝트가 등장했다. 대표적인 예가 레디스다.

이러한 프로젝트는 한 사람의 '가려움'에서 시작된 경우가 많다. 예를 들어 다니엘 스텐버그는 다른 IRC 사용자를 위해 환율 정보를 다운로드해서 전송할 방법이 필요해 컬(Curl)을 만들었고, 현재 수십억 명이 컬을 사용하고 있다. 우리가 모르는 사이 매일 컬을 사용하고 있을 가능성이 크다.

사이먼 윌리슨은 더 가디언(The Guardian)에서 일할 당시 새로운 방식으로 데이터를 쿼리해, 정적 데이터 집합을 웹에 쉽게 게시할 방법이 필요했다. 그는 (그의 표현을 빌리면) '울분을 발산'하기 위해 데이터셋(Datasette)을 오픈소스화했다. 이 과정에서 퍼블릭 도메인 라이선스가 부여된 SQLite를 채택해 애플 워치 같은 기기까지 포함해 어디에서나 데이터를 게시할 수 있게 했다. 현재 그는 자신의 독 쉽(Dog Sheep) 프로젝트를 통해 데이터 쿼리(개인적인 분석)를 테스트하고 있다.

드리스 보이타르트는 친구가 ADSL 연결을 공유할 수 있도록 '소소한 웹사이트'를 하나 만들었다. 이것은 오픈소스 콘텐츠 관리 시스템(CMS)으로 발전해 드루팔(Drupal)이 됐다. 현재 드루팔의 기여자는 매년 1만 명에 육박한다. CMS는 드루팔 전에도 있었고 이후에도 있었지만 특유의 유연함 덕분에 수많은 기여자가 원하는 방식으로 활용할 수 있었고, 결과적으로 폭넓은 수요에 부응하는 혁신이 가능했다.

리눅스 커널의 오랜 기여자이자 리눅스 I/O 스택 유지관리 담당자인 젠스 액스보는 재현하기가 쉽지 않은 특이한 워크로드를 실행하는 사용자로부터 지속해서 버그 리포트를 받았다. 그래서 워크로드가 하는 일을 대략 재연하는 플렉서블 I/O(Flexible I/O) 테스터, 즉 피오(Fio)라는 툴을 만들었다. 15년이 지난 지금 피오는 스토리지 워크로드 모델링을 위한 업계 표준이 됐다.
 

오픈 소서러를 주목하라

기술의 미래를 보고 싶다면, 깃허브(GitHub), 깃랩(GitLab) 및 기타 오픈소스 코드 리퍼지토리에서 명확하게 확인할 수 있다. 팀 오라일리는 사람들은 미래에 기술이 어디로 갈지 알기 위해 '알파 긱(alpha geek)'을 주목한다고 종종 말했다. 오픈소스 세계 어디에선가 항상 이들 알파 긱이 레디스, 피오, 컬, 드루팔, 데이터셋과 같은 새로운 아이디어를 내놓고 있다.

여러분 기업의 직원이 관료주의에 질려 윌리슨의 표현대로 그 '울분을 발산'하고 법무팀의 간섭 없이 순수한 생산성의 즐거움을 얻고자 오픈소스 프로젝트를 만들 수도 있다. 여러분 기업 내에 이런 미래가 잘 자리 잡도록 하려면 개발자가 오픈소스에 깊이 개입하도록 독려해야 한다. 그러면 다른 곳이 아닌 기업의 방화벽 내에서 또는 회사의 깃허브 내에서 기술의 미래가 펼쳐지게 될 것이다. editor@itworld.co.kr


2020.05.28

글로벌 칼럼 | 레디스가 바꾼 DB 시장, SW 혁신은 '가려운 곳'에서 시작된다

Matt Asay | InfoWorld
굳이 새 데이터베이스를, 특히 2009년 당시 지배적인 데이터베이스 클래스 관점에서 전혀 무의미했던 인메모리 데이터베이스를 만든 이유가 무엇이었을까? 사실 살바토레 산필리포는 그런 것에는 관심이 없었다. 데이터베이스에 대한 다른 사람의 생각을 바꾸려 한 것이 아니라, 단지 실시간 분석 엔진을 확장해야 했는데 마이SQL은 비용 효율적이지 않았을 뿐이다. 그래서 탄생한 것이 바로 레디스(Redis)였고 이후 데이터베이스 시장은 완전히 바뀌었다.
 
© Getty Images Bank

지난 몇 주 동안 산필리포 같은 오픈소스 프로젝트 설립자와 대화하면서 놀란 점도 이것이었다. 특정한 한 가지 필요(오픈소스 용어로 '가려운 곳(itch)')에 대한 답을 찾고자 시작한 오픈소스 프로젝트가 결과적으로 해당 제품의 범주 자체를 바꿔 놓는 경우가 많다는 사실이다. 그들은 유용한 뭔가를 만들고자 했을 뿐이지만 결과적으로 '혁신적인 뭔가'를 만들어 버렸다. 궁금증이 생겼다. 여러분의 기업이 혁신을 위한 새로운 방법을 찾는 중이라면, 혹시 직원에게 오픈소스에 더 깊이 참여하도록 독려한 적이 있는가?
 

새로운 것 탐색하기

우리는 레거시 기술의 익숙한 루틴에 머무르는 경우가 있다. 산필리포는 "트위터 대화에서 모든 문제가 해결된 것처럼 보여도, 특정 소프트웨어 영역에서는 새로운 것을 탐색하는 것이 가능하다"라고 말했다. 실제로 관계형 데이터베이스(RDBMS) 시장은 수십 년 동안 정체 상태였다. 새로운 기능이 등장하고 새로운 훌륭한 오픈소스 데이터베이스도 나왔지만(마이SQL, 포스트그레SQL), 여전히 행과 열에 이것저것을 집어넣는 방식이었다. 그것이 데이터를 다루는 '올바른 방법(right way)'이었기 때문이다.

그러나 어쩌면 '올바른' 방법이 아니었을 수도 있다. 대부분은 맞았을 수 있지만 항상 그런 것은 아니었다. 예를 들어 일부 데이터는 관계형 모델에 적합하다. 특히 ERP 시스템과 같은 레코드 시스템이 그렇다. 하지만 세계가 인게이지먼트(engagement) 시스템으로 옮겨가면서 정형/반정형 데이터의 비중은 크게 줄어들었다. 관계형 모델에서는 데이터를 2차원 테이블 구조로 바꿔야 한다. 반면 몽고DB(MongoDB) 같은 문서 데이터베이스는 현대 프로그래밍 언어의 객체 구조와 더 잘 어울리는 다채로운 동적 데이터 모델을 제공한다.

이 데이터베이스가 저 데이터베이스보다 더 낫다고 말하려는 것이 아니다. 각자 더 잘 맞는 작업이 있고, 우리가 비정형 데이터를 관계형 형식으로 억지로 밀어 넣느라 오랜 시간을 낭비하고 있었던 것일지도 모른다는 것이다. 산필리포가 말했듯 데이터베이스가 '해결된' 문제라고 판단했고 그 실수의 대가로 많은 생산성을 잃었다(이런 실수는 비단 데이터베이스만의 문제는 아니다).
 

모방에서 혁신으로

오픈소스의 초창기에 리눅스, 마이SQL과 같이 비교적 잘 알려진 일부 프로젝트는 유닉스나 오라클 등 각각 대응하는 값비싼 독자 규격 제품의 기능을 모방하기 위해 노력했다. 그러나 시간이 지나면서 모방이 아닌 혁신을 추구하게 됐다. 동시에 새로운 영역을 개척하거나 기존 영역을 새로운 방식으로 접근해 사용자 기반을 크게 확대한 프로젝트가 등장했다. 대표적인 예가 레디스다.

이러한 프로젝트는 한 사람의 '가려움'에서 시작된 경우가 많다. 예를 들어 다니엘 스텐버그는 다른 IRC 사용자를 위해 환율 정보를 다운로드해서 전송할 방법이 필요해 컬(Curl)을 만들었고, 현재 수십억 명이 컬을 사용하고 있다. 우리가 모르는 사이 매일 컬을 사용하고 있을 가능성이 크다.

사이먼 윌리슨은 더 가디언(The Guardian)에서 일할 당시 새로운 방식으로 데이터를 쿼리해, 정적 데이터 집합을 웹에 쉽게 게시할 방법이 필요했다. 그는 (그의 표현을 빌리면) '울분을 발산'하기 위해 데이터셋(Datasette)을 오픈소스화했다. 이 과정에서 퍼블릭 도메인 라이선스가 부여된 SQLite를 채택해 애플 워치 같은 기기까지 포함해 어디에서나 데이터를 게시할 수 있게 했다. 현재 그는 자신의 독 쉽(Dog Sheep) 프로젝트를 통해 데이터 쿼리(개인적인 분석)를 테스트하고 있다.

드리스 보이타르트는 친구가 ADSL 연결을 공유할 수 있도록 '소소한 웹사이트'를 하나 만들었다. 이것은 오픈소스 콘텐츠 관리 시스템(CMS)으로 발전해 드루팔(Drupal)이 됐다. 현재 드루팔의 기여자는 매년 1만 명에 육박한다. CMS는 드루팔 전에도 있었고 이후에도 있었지만 특유의 유연함 덕분에 수많은 기여자가 원하는 방식으로 활용할 수 있었고, 결과적으로 폭넓은 수요에 부응하는 혁신이 가능했다.

리눅스 커널의 오랜 기여자이자 리눅스 I/O 스택 유지관리 담당자인 젠스 액스보는 재현하기가 쉽지 않은 특이한 워크로드를 실행하는 사용자로부터 지속해서 버그 리포트를 받았다. 그래서 워크로드가 하는 일을 대략 재연하는 플렉서블 I/O(Flexible I/O) 테스터, 즉 피오(Fio)라는 툴을 만들었다. 15년이 지난 지금 피오는 스토리지 워크로드 모델링을 위한 업계 표준이 됐다.
 

오픈 소서러를 주목하라

기술의 미래를 보고 싶다면, 깃허브(GitHub), 깃랩(GitLab) 및 기타 오픈소스 코드 리퍼지토리에서 명확하게 확인할 수 있다. 팀 오라일리는 사람들은 미래에 기술이 어디로 갈지 알기 위해 '알파 긱(alpha geek)'을 주목한다고 종종 말했다. 오픈소스 세계 어디에선가 항상 이들 알파 긱이 레디스, 피오, 컬, 드루팔, 데이터셋과 같은 새로운 아이디어를 내놓고 있다.

여러분 기업의 직원이 관료주의에 질려 윌리슨의 표현대로 그 '울분을 발산'하고 법무팀의 간섭 없이 순수한 생산성의 즐거움을 얻고자 오픈소스 프로젝트를 만들 수도 있다. 여러분 기업 내에 이런 미래가 잘 자리 잡도록 하려면 개발자가 오픈소스에 깊이 개입하도록 독려해야 한다. 그러면 다른 곳이 아닌 기업의 방화벽 내에서 또는 회사의 깃허브 내에서 기술의 미래가 펼쳐지게 될 것이다. editor@itworld.co.kr


X