[번역] ZeroMQ설계자: 세계를 구원하라

  • 번역: coolspeed

이 글은 ZeroMQ설계자가 지은 책이며 ZeroMQ의 “바이블”이라 불리는 ZGuide 의 머리말이다.

이 책은 다양한 프로그래밍 언어 예시 버전의  PDF, epub 등 이북 포맷으로 다운로드도 가능하고[1], 한글 번역도 온라인에서 읽을 수 있다. 당연히 그속에는 이 머리말의 한글번역도 포함되어 있었다. 다만 번역이 만족스럽지 못해 필자가 직접 번역했다.


ZeroMQ 100 자 요약

ZeroMQ (ØMQ, 0MQ, or zmq 라고도 표기함) 는 임베드블 네트워킹 라이브러리처럼 생겼는데 실제론 컨커런시 프레임웤처럼 작동한다. ZeroMQ 는 원자적으로 메시지를 배송하는 소켓을 제공하는데 그 배송수단으로는 스레드간 통신, 프로세스간 통신, TCP 그리고 multicast 등 다양하다. 당신은 ZeroMQ 소켓을 N-to-N 방식으로, fan-out, pub-sub, task distribution, 그리고 request-reply 등 패턴으로 사용할 수 있다. 이것은 클러스터 제품들의 뼈대로 사용하기에 전혀 문제 없는 높은 성능을 가지고 있다. 이것의 비동기 I/O 모델은 당신이 message-passing task처럼 짜여진, 확장성 있는 멀티코어 애플리케이션을 만들 수 있게 해준다. 언어 API 만큼 고득점을 갖고 있으면서 거의 모든 OS에서 돌아간다. ZeroMQ 는 iMatix 에서 개발했으며 LGPLv3 라이센스로 소스가 오픈되어있다.

 

세상을 구원하다

ZeroMQ 요놈은 정말 좋은데. 어떻게 말로 표현할 방법이 없네.  ZeroMQ의 가치를 설명하기 위해, 일부 사람들은 요놈이 제공하는 모든 훌륭한 기능들을 나열하는 것으로 부터 시작하려고 한다:

  • 이놈은 스테로이드를 처먹은 소켓이야.
  • 이놈은 라우팅 기능이 있는 우편함으로 비유할 수 있지.
  • 존나 빠름.

다른 일부 사람들은 ZeroMQ에서 느꼈던 법열을 통하여 설명을 시도한다:

  • 고사끝에 베일에 숨겨져 있던 것들이 드디어 모습을 드러낼 때 패러다임 체인지의 법열을 느꼈을 때 그 짜릿함.
  • 그냥 말이 필요없음. 복잡함은 다 도망가고, 모든 것이 심플해졌음.
  • 이것은 계몽적이었다.

또 일부 사람들은 비교를 통하여 ZeroMQ를 설명하려고 한다:

  • 보다 작고, 심플하지만 여전히 당신이 익숙한 그 방식이다.

개인적으로 나도 왜 우리가 ZeroMQ를 만들었는지를 명기했으면 하여 그 여정을 적어보기로 한다. 왜냐면 지금도 독자 여러분은 우리가 처음 길에 오른 그 역 근처에 머물고 있을지 모르니까.

프로그래밍은 과학이다. 다만 예술인양 코스플레이 하고 예술 행세를 하고 쳐돌아다닐 뿐이지 과학이다. 우리중 다수는 소프트웨어의 물리학을 잘 모르고 있다. 이 학문은 가르치는 곳이거의 없다. (아예 없다고 해야 하나..) 소프트웨어의 물리학은 알고리즘이나, 자료 구조, 프로그래밍 언어나 추상화 등이 아니다 — 이런 것들은 다만 우리가 그냥 만들어내고 사용하고 버리는 툴들일 뿐이다 — 소프트웨어의 진정한 물리학은 인간의 물리학이다 — 특히 복잡성 앞에서의 인간의 한계, 그리고 우리의 협력을 통하여 거대한 문제를 작은 조각들로 쪼개서 해결하려고 하는 노력, 등이다.

이것이야말로 프로그래밍 과학이라고 감히 정의하겠노라: 사람들이 쉽게 이해하고 쉽게 사용할 수 있는 빌딩블록들을 만들어냄으로써, 사람들이 그걸 이용하여 위대한 문제들을 해결하게끔 도와주는 것.

우리는 얼기설기 연결된 세상속에 살고 있다. 그리고 모던 소프트웨어들은 이러 세상속을 항행할 수 있어야 한다. 따라서 미래의 거대한 솔루션들을 위한 빌딩블록들은 반드시 서로 연결되어야 하며 대규모 병렬적이여야 한다. 예전처럼 프로그램이 그냥 “강하고 침묵” 하기만 하면 되던 그런 시대는 지났다. 코드는 이젠 코드와 대화해야 한다. 코드는 수다스러워야 하고 사교적이여야 하며 웰 커넥티드여야 한다. 코드는 반드시 인간의 두뇌처럼 작동해야 하고, 수조개의 뉴런들이 서로에게 메시지를 던지듯이, 중앙 통제가 없는 대규모 병렬 네트워크여야 한다. 그래야 단일 장애점 (Single Point Of Failure, SPOF) 이 없을 수 있다. 그러면서도 극도로 어려운 문제들을 해결할 수 있어야 한다. 뿐만아니라 코드의 미래가 인간의 두뇌처럼 생길 것이라는 것은 거의 확정이다. 왜냐면 그 어떤 네트워크도 결국에는 말단에서 인간의 두뇌에 연결되며, 그 어떤 네트워크의 진화 종착점도 인간의 두뇌이니까.

당신이 만약 스레드, 프로토콜, 또는 네트워크와 싸워봤다면 당신은 이것이 얼마나 불가능에 가까운 일인가를 알 것이다. 이건 꿈이야. 몇개의 프로그램들을 몇개의 소켓을 통해 연결시키는 것만 해도 얼마나 고약하고 추잡스러운가를 느꼈을 것이다, 그것이 리얼 세계의 상황들을 케어해야 하게 되는 시점부터 말이다. 수조개? 장난이냐? 그 코스트는 상상도 할 수 없을 정도일거야. 컴퓨들을 연결시키는게 얼마나 어려운 일이였으면, 그걸 해주는 소프트웨어와 서비스들은 각각 심심찮게 수십억 달러짜리의 사업이였다. (Dropbox 의 시가총액을 생각해봐라)

그래서 결국 우리는 이러한 세상에서 살게 되였다: 인터넷 속도와 보급정도 자체는 사실 상당히 발달되어있는데, 우리의 그것을 제대로 활용하는 능력은 몇년이나 뒤쳐져있다. 이 업계에서는 1980년대에 한차례 소프트웨어 위기를 겪었다. 이 소프트웨어 위기가 무슨 말이냐면, 그때 Fred Brooks 를 포함한 일부 세계 탑 엔지니어들이 업계에 대한 관찰을 토대로,

“소프트웨어 업계에서 생산성, 신뢰성, 간단성 이 세가지 척도중 그 어느 한 방면에서도 한개 수량급 정도의 진보를 이루는 것” 에는 “은총알이 존재하지 않는다” 고 주장한 것이다.

Brooks 가 놓쳤던 것은 무료이고 자유롭게 이용이 가능하며 오픈소스인 소프트웨어들이었다. 그리고 결국 오픈소스란 현상의 용솟음으로 우리는 서로 효율적으로 지식을 공유할 수 있게 되었고, 이번 소프트웨어 위기는 이렇게 해결되었다.

하지만 오늘날 우리는 다른 한차례의 소프트웨어 위기에 직면해있다. 다만 이번에는 이걸 얘기하는 사람이 별로 많지 않았을 뿐이다. 그것은 바로 —— 오로지 대기업들, 가장 크고 가장 부유한 대기업들만이 “연결된 프로그램” 을 만들 수 있다는 점이다. 물론 요즘에는 클라우드가 있다. 하지만 클라우드는 사적 소유인거다. 우리의 데이터와 우리의 지식은 우리의 개인 컴퓨터에서 점점 사라지고, 우리가 접근할 수 없고 우리가 그걸 상대로 경쟁조차 펼칠 수 없는 클라우드로 흘러들어가고 있다. 생각해봐라, 우리의 소셜 네트워크를 누가 쥐고 있는가? 이것은 대형컴퓨터에서 PC 로의 전환 혁명, 의 역혁명인 셈이다.

우리는 이런 정치철학 내용은 다른 한 권의 책 에서 제대로 다뤄야 할 것이다. (이 책도 ZeroMQ설계자가 지은 책이다. 링크내 무료로 읽을 수 있고 PDF나 기타 흔히 사용되는 전자책 포맷으로 다운로드 받을 수도 있다. — 옮긴이) 여기서 말하고자 하는건, 인터넷이 대규모 연결 프로그램의 잠재력을 제공하고 있음에도 불구하고, 현실은 이것을 충분히 이용할 수 있는 사람은 극히 드물다는 점이다. 그러므로 거대하고 흥미로운 (건강 의료, 교육, 경제, 물류 등 분야들의) 문제들은 해결되었어야 하는 부분들조차도 해결되지 못하고 있다는 점이다 — 우리가 코드들을 효과적으로 연결을 못하고 있고, 그러므로 원래는 협력하여 함께 문제를 해결할 수 있었던 두뇌들을 연결시키지 못해서.

연결된 코드의 도전 문제를 해결하기 위한 시도들도 많이 있었다. 예를 들어 수천가지의 IETF 규격들, 그것들은 각각 퍼즐의 일부만 해결한다. 애플리케이션 개발자에게 있어서 HTTP 는 아마도 한가지 충분히 간단하고 효과도 괜찮은 해결책이였을 것이다. 하지만 반면에 HTTP 는 상황을 더욱 악화시키기도 했다. HTTP 는 개발자들로 하여금 거대한 서버와 얇삭하고 바보같은 클라이언트로 구성된 아키텍처를 더욱 생각하고 선호하게 했으니까.

그래서 결과적으로 오늘날에도 사람들은 여전히 UDP, TCP , 사적소유의 프로토콜, HTTP 와 Websocket 등을 raw  하게 사용하고 있다. 여전히 고통스럽고 굼뜨고 확장이 어려우며 대체적으로 중앙화되어있다. 분산식 P2P 아키텍처도 존재하긴 하지만, 대부분 노는 일에만 기여하지 생산력에는 도움이 안된다. Skype 나 비트토렌트로 데이터를 주고받는 사람이 얼마나 되려나?

이 모든 현실은 다시 우리를 최초의 프로그래밍 과학에 대한 문제로 되돌려보낸다. 세상을 구원하기 위해 우리는 두가지 일을 해야만 했다:

  1. 첫째, 일반적인 문제인 “어디서나, 임의의 코드를 임의의 코드에 연결시킬 방법이 뭐가 있을까?”
  2. 둘째, 이 모든 대책을 하나의 최대한 심플하고 사람들이 이해하기도 사용하기도 쉬운 빌딩 블록으로 포장시키기.

말도 안되게 간단한 소리다. 그리고 정말로 그럴지도 모른다. 하지만 이것이 바로 이 책의 전부 요점이다.

References:

[1] The ZeroMQ Guide, Electronic downloads: C PDF, EPub — Python PDF, EPub — Lua PDF,EPub — PHP PDF, EPub — Haxe PDF, EPub

 


옮긴이의 말

사실 저는 RabbitMQ + Go 를 더욱 선호한다. 지구상 가장 분주한 전자상거래 시스템에서도  broker가 있는 MQ 인 RocketMQ 를 사용한다. ZeroMQ 의 no broker 방식은 궁극적인 방향은 맞는데, 아직은 RabbbitMQ 나  RocketMQ 같이 중앙집중적이며 클러스터링과 fault-tolerance 가 잘 되어있는 솔루션이 관리가 편하다고 생각한다. (물론 클라-클라 P2P통신으로 게임을 하려면 ZeroMQ나 되겠지. 하지만 이것은 MQ 로서의 ZeroMQ가 아니라 추상 소켓과 비동기 네트워크 통신 라이브러리로서의 ZeroMQ가 작용을 한거겠지.)

심지어 미학적으로도:

  1. 동기적으로 마구 사용할 수 있는 Go.
  2. Erlang 의 무상태 hub.

등이 나에게는 훨씬 감동적으로 다가왔다. Erlang 이 혁명을 일으킬 것이라고 했을 때 반신반의 했었는데, 이런 식으로 Erlang 의 창조적 혁명이 성공을 할줄이야, 그 어디 꿈에서도 생각이나 했으랴.

Haskell  monad 의 pure 한것과 더러운 것을 분리하는 철학도 현업에서 그 정확성을 드디어 증명해냈다, 고 보는 것은 너무  멀리 간걸까?

 

Advertisements

One thought on “[번역] ZeroMQ설계자: 세계를 구원하라

  1. Pingback: [펌] ZeroMQ | Site Title

댓글 남기기

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s