토요일, 9월 29, 2018

[B급 프로그래머] 9월 4주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

(오늘의 짤방: How tech writing ruined me as a letter writer via @PPd3nfDj0oPBAaO https://www.reddit.com/r/funny/comments/4dmufm/how_tech_writing_ruined_me_as_a_letter_writer/)
  1. 개발/관리도구
  2. 고성능 서버/데이터베이스
보너스: Effort matters. via @ValaAfshar
EOB

금요일, 9월 28, 2018

[독서광] 레버리지

오늘 2번 타자로 소개드릴 책은 작년에 인기를 끌었던 책인 레버리지다. 뒤늦은 감은 없지 않지만 바쁜 독자 여러분을 위해 핵심을 정리하려고 한다.

책 내용을 소개하기 전에 먼저 레버리지의 사전적인 의미부터 살펴보는 편이 좋겠다. 캠브리지 온라인 사전에 따르면 다음과 같다:

  • 새롭고 더 나은 뭔가를 달성하기 위해 이미 들고 있는 뭔가를 활용하기
  • 투자나 사업을 위해 빌린 돈을 사용하기
  • 더 많은 돈을 얻기 위해 돈을 사용하기

이 정도면 레버리지가 무엇인지 감을 잡았을 것이다. 이 책은 사람들이 왜 그렇게 많은 시간을 사용(!)하면서 늘 불만스러운 삶을 사는지에 대한 이유와 해법을 제시하고 있다. 개인의 인내와 희생과 헌신이 성공을 가져다주는 원동력이라는 세간의 주장과는 반대로 이 책은 '최소 노력의 법칙'을 활용해 남이 아닌 자신을 위해 일해야 부를 얻을 수 있다고 주장한다. 잠깐 본문의 일부를 볼까?

그러나 많은 자영업자가 자신이 만들어낸 일에만 몰두한다. 그들은 아무도 자신만큼 일을 잘할 수 없다고 생각하고, 자신이 직접 일을 함으로써 돈을 절약할 수 있다고 믿기 때문에 다른 사람에게 업무를 맡기지 않는다. 허울만 자영업자고 실상은 스스로에게 고용된 노동자이자 자신의 노예로 전락하는 것이다.

그렇다면 레버리지를 일으키는 일과 그렇지 않은 일을 어떻게 구분할 것인가? 저자는 다음과 같은 소득 창출 가치(IGV)라는 공식을 제안한다.

IGV = 한 주 동안 버는 소득/55시간

일주일에 대략 80만원을 번다면, IGV는 약 14,500원이다. 시간 당 14,500원을 번다는 말이다. 그렇다면 어떤 일을 할 때 시간 당 14,500보다 많은 수익을 거둘 수 있는가? 그렇다면 당신이 해야한다. 그렇지 않다면 남에게 위임한다. 초과 근무를 아무리 많이해도 IGV를 넘기지 못하면 말짱 꽝인 셈이다. 부자들은 낮은 가치의 일은 남에게 시키고 IGV보다 적은 비용을 지불하기 때문에 계속해서 돈을 더 벌 수가 있게 된다.

그렇다면 한 가지 문제가 발생한다. 누구나 IGV보다 많은 비용을 벌고 싶지만 어떻게 여기 부합되는 일을 찾을까? 유감스럽게도 이 책에서는 비밀을 밝히지 않는다(어차피 사람마다 특기와 환경이 다르므로 왕도가 있을리도 없다. T_T). 대신 몇 가지 힌트를 제시하고 있으므로 이를 눈여겨 보면 도움이 될 것이다. 개인적인 실천법도 있고 조직적인 실천법도 있으므로 신경써서 읽어보면 도움이 될만한 내용을 찾을 수 있을 것이다.

본문에 나오는 몇 가지 실천 방안을 살펴볼까?

  • 책을 읽거나 오디오 프로그램을 듣는다.
  • 강좌나 워크숍, 세미나에 참석한다.
  • 코치나 멘토를 활용한다.
  • 현명한 사람들과 네트워크를 만든다.
  • 전기나 다큐멘터리를 본다.
  • 전문가들의 블로그, SNS를 방문한다.

결론: 자신이 하는 일에 매몰되어 허우적거리고 있다면 잠시 멈춘 다음에 이 책을 가볍게 읽어보면 좋을 것 같다. '열심히'가 만병 통치약은 아니니까.

EOB

토요일, 9월 22, 2018

[B급 프로그래머] 9월 3주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문)

(오늘의 짤방: 팀에 맞지 않는 리더의 특성이 재미있음 via @jhnha)
  1. 빅데이터/인공지능
  2. 암호화폐/블록체인
  3. 읽을거리
보너스: Game of Life - Universal Turing Machine
EOB

금요일, 9월 21, 2018

[독서광] 로지코믹스

독서의 계절인 가을을 맞이해서 그 동안 밀린 독후감 숙제를 시작하려고 한다. 오늘은 1번 타자로 버트란드 러셀의 일대기를 만화(!)로 그린 로지코믹스를 소개하겠다.

위키 백과에 따르면 버트란드 러셀은 영국의 수학자, 철학자, 수리논리학자, 역사가, 사회 비평가로 나온다. 노벨 문학상까지 받았으니 천재 중에 천재라고 볼 수 있는 인물이다. 하지만 위키 백과에도 소개되긴 하지만 러셀의 삶은 결코 순탄하지 않았다. 로지코믹스는 복잡다난한 러셀의 개인적인 삶을 풀어내면서 슬쩍 수학의 이론을 끼워넣는 방식을 사용해서 어려운 내용을 알기 쉽게 풀이하는 데 성공했다.

로지코믹스 저자(글)인 아포스톨로스 독시아디스는 그가 미친 단 하나의 문제, 골드바흐의 추측에서 골드바흐의 추측 문제를 재미있으면서도 완성도 높게 그려내었기에 유심히 기억하고 있었는데, 우연히(다음 서평에 소개하겠다) 버트란드 러셀에 대한 책을 찾다가 레이더 망에 걸려서 두번 고민하지 않고 바로 구입해서 단숨에 읽고 말았다. 그림체도 독특하고, 등장 인물도 개성이 풍부하고 입체적인 수학자들이며, 내용도 이해하기 쉽지만 충실하므로 수학에 관심이 많은 어른을 위한 만화책이라고 볼 수 있다.

초반 부 암울했던 러셀의 어린 시절, 중간 중간 나오는 여러 수학자들과 벌이는 난투극(옛날에 자신의 믿음을 놓고 총 들고 결투하는 수학자들이 이해가 가기 시작했다. T_T), 후반 부 논리철학 전쟁에 끼어든 신인들인 비트겐슈타인과 괴델(괴델은 수학원리를 처음부터 끝까지 다 읽은 거의 유일한 사람이라고 한다...)의 강력한 이론적인 공격은 책에 자연스런 리듬을 부여하면서 고대 그리스의 비극처럼 카타르시스를 느끼게 만들어준다. 당대 최고의 수학자들이 여러 가지 이유로 무너저내리는 가운데, 러셀이 어떻게 자신의 운명을 바꿔나가는지에 초점을 맞춰서 읽어봐도 좋을 것 같다. 러셀은 화이트헤드와 함께 뉴톤의 자연철학의 수학적 원리에 버금가는 결정론적 세계관의 끝판왕인 수학원리를 집필했다는 사실은 너무나도 잘 알려졌는데, 결국 러셀이 엄청나게 유명하게 된 계기가 된 동시에 자기 발목을 잡을 러셀의 역설을 발표하면서부터 겪는 고뇌와 갈등을 어떻게 풀어내는지 저자들 뒤에 숨어서 졸졸 따라가다보면 어느 새 마지막 페이지를 넘기고 있을 것이다.

결론: 버트란드 러셀의 삶이 궁금하거나, 수학과 철학과 컴퓨터 과학의 토대를 알고 싶으면 이 책을 읽어보시면 좋겠다. 강력 추천.

EOB

토요일, 9월 15, 2018

[B급 프로그래머] 9월 2주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

(오늘의 짤방: Five Linux stats for stat and FOSS nerds via @nixcraft)
  1. 개발/관리도구
  2. 고성능 서버/데이터베이스
보너스: kubernetes via @coolished
EOB

목요일, 9월 13, 2018

[독서광] 클라우드 네이티브 인프라스트럭처

최근에 들어와서 계속 클라우드 관련 서적을 읽고 검토하게 되었는데, 우연히 시기가 맞아서 오라일리의 Cloud Native Infrastructure(한국어 제목: 클라우드 네이티브 인프라스트럭처, 부제: 진정한 클라우드 네이티브 컴퓨팅 시대를 위한 아키텍처 패턴과 설계)를 감수하였고, 그 결과로 Yes24교보등 주요 인터넷 서점에서 예판이 시작되었다.

소프트웨어를 서비스로 제공하기 시작하면서 웹앱이 인기를 끌게 되었는데, 12요소 애플리케이션이라는 방법론이 개발자들 사이에서 좋은 반향을 불러일으켰다. 그렇다면 클라우드로 이전하는 과정에서 인프라스트럭처 자체에 대한 아키텍처 패턴에 대한 지침은 없을까? 바로 '클라우드 네이티브 인프라스트럭처'가 만들어진 이유라고 보면 된다. 이 책은 클라우드 시대에 적합한 인프라스트럭처를 구성하기 위한 소프트웨어 즉, 애플리케이션 중심의 아키텍처 구성과 패턴을 제시하고 있다. 본문 중에 여러 가지 흥미로운 개념과 사례가 등장하는데, 모두 소개하기에는 지면이 부족하므로... 독자 여러분을 위한 예고편 맛보기로 감수의 글을 써봤다(약간의 게으름으로 인해 책 본문에서 그대로 옮겨본다).

--- 감수자 글---

학창 시절 1990년대 초반에 워크스테이션이 가득 찬 연구실에서 근무할 때, 모든 서버 전면에는 이름과 IP 주소가 적힌 명패가 붙어 있었다. 만화 영화 주인공, 행성, 보석 등에서 아이디어를 얻은 멋진 서버 이름은 심지어 다른 학교에서도 알고 있을 정도였다(아, 그 당시는 겁도 없이 공인 IP로 인터넷에 접속하던 시절이라서 DNS 이름이 서버의 진짜 별명이었다). 장애가 발생하면 서버로 달려가서 하드웨어에는 문제가 없는지, 경우에 따라서는 리부팅이 필요한지 꼼꼼하게 콘솔 앞에서 진단하고 문제를 해소한 다음에 결과 보고서의 가장 상단에 문제가 된 서버 이름을 기입했다.

강산이 두 번 바뀌어 2010년 이후 퍼블릭 클라우드가 본격적으로 시장을 공략하기 시작하면서 서버 관리자도, 서버 이름도 소리소문없이 사라지기 시작했다. 누구나(관리는 클라우드 업체에서 담당하므로 실제 업무를 맡은 개발자일 확률이 높겠지만) 클라우드 콘솔에 들어가서 버튼만 누르면 인스턴스가 바로 만들어지고 사라지는 상황에서 그까짓 이름 따위가 무슨 소용이 있겠는가? 인스턴스 ID만 알면 API로 서버를 관리할 수 있기에 서버 이름은 물론이고 심지어 클라우드 데이터 센터의 물리적인 위치나 표준 시간대에 맞춘 운영 시간도 관심에서 멀어지기 시작했다. 어차피 인스턴스는 SLA 범위 내에서 멈춰버리거나 심지어 다른 물리 서버로 옮겨지는 상황이 불가피하므로 애지중지 관리할 필요가 없다.

2013년 글렌 베리(Glenn Berry)가 SQLPASS 2013 컨퍼런스에서 Scaling SQL Server 2012라는 제목으로 발표하는 중에 '수직 확장 대 수평 확장'이라는 내용을 소개하면서, 수직 확장은 서버를 애완 동물처럼 취급하는 반면에 수평 확장은 가축으로 취급한다는 마이크로소프트 빌 베이커가 설명한 비유를 보고 들은 사람들은 엄청난 충격에 휩싸인다. 전통적인 서버는 이름을 붙이고 고장이 나지 않은지 계속 살피며 문제가 생기면 건강하게 치료하지만, 클라우드 네이티브 서버는 숫자만 세고 있다가 아프면 바로 죽여버린다는 상당히 비정한 설명 때문이었다. 클라우드 환경을 접하고 나서 문화적인 충격을 느꼈다면 아마 어느 랙의 어느 하드웨어 서버에 들어있는지도 모르는 수많은 인스턴스들의 익명성 때문인지도 모르겠다.

엄청나게 빠른 속도로 사회가 바뀌고 있으므로 사업의 승부는 속도와 확장성에 달려 있고, 이를 위해 컴퓨팅 환경을 뒷받침하는 인프라스트럭처도 발전해왔다. '클라우드 네이티브 인프라스트럭처'는 바로 이런 시대의 변화에 부응하는 최신 기술이며, 아키텍처 수립부터 설계와 구현을 거쳐 테스트에 이르기까지 소프트웨어 엔지니어링 부문에서 여러 가지 개념을 빌려와 인프라스트럭처를 소프트웨어처럼 취급할 수 있게 만든다. 명세를 문서화하고 싶은가? 코드로 만들면 된다. 명세를 실 환경에 반영하고 싶은가? 코드를 빌드해서 수행하면 된다. 이력을 관리하고 싶은가? 코드이므로 깃과 같은 분산 관리 시스템으로 추적하면 된다. 제대로 동작하는지 테스트하고 싶은가? 코드이므로 단위 테스트와 통합 테스트를 돌리면 된다.

하지만 현실로 돌아와 보면 상황은 생각보다 훨씬 더 복잡하다. 퍼블릭 클라우드, 가상화 기술, 마이크로서비스, 셰프나 퍼핏과 같은 구성 관리 도구, 컨테이너, 쿠버네티스와 같은 오케스트레이터, Go와 같은 최신 프로그래밍 언어, 스프링 프레임워크와 같은 클라우드 네이티브 프레임워크를 비롯해 여러 가지 기술들이 현기증이 들 정도로 사방에서 쏟아져 나오고 있지만, 이런 기술들을 무작정 도입해 사용한다고 해서 클라우드 네이티브가 되지는 않는다는 사실이 클라우드로 이전하는 가장 큰 걸림돌이 되고 있다.

어떤 상황에서도 사업을 최대로 지탱하는 인프라스트럭처를 고도화하고 싶은 우리에게는 클라우드 애플리케이션의 새로운 시대를 연 12요소 애플리케이션과 같은 지침이 필요하며, 다행스럽게도 바로 이 책이 클라우드 네이티브한 인프라스트럭처의 아키텍처를 수립하고 설계하는 데 도움이 되는 패턴과 지침을 제공한다. 이 책은 우선 클라우드 네이티브 인프라스트럭처 개요부터 클라우드 네이티브 도입 시점, 클라우드 네이티브 배포 방식의 진화를 다루고, 본론으로 들어가서 인프라스트럭처 애플리케이션 설계와 개발과 테스트와 관리 방법을 다룬다. 마지막으로 애플리케이션을 보호하고 클라우드 네이티브 인프라스트럭처를 구현하는 내용으로 마무리한다. 네트워크 회복성을 위한 패턴과 락인에 대한 조언, 그리고 박스(Box) 사의 쿠버네티스 도입을 정리한 부록도 실용적인 도움을 준다.

모자이크와 넷스케이프로 인터넷 업계의 지형도를 완전히 바꾸는 데 성공한 마크 앤드리슨(Marc Andreessen)은 2011년 8월 무렵 월스트리트 저널에 기고한 왜 소프트웨어가 세상을 먹어치우고 있는가?라는 글에서 제조업은 물론이고 기존 소프트웨어 대기업까지 새로운 소프트웨어의 물결에 휩쓸려 경쟁력이 급격하게 떨어지고 있는 현실을 정확하게 분석했다. 데이터 센터에서 상면을 빌리고 랙을 설치하고 전용선을 끌어들이며 서버를 구매하고 CD로 소프트웨어를 설치하는 시대는 서서히 저물어가고 있다. 업계 전체가 소프트웨어로 인해 흔들리는 판국에 소프트웨어를 움직이는 인프라스트럭처가 소프트웨어가 되지 말라는 법이 있는가?

이 책 본문에서 인프라스트럭처가 애플리케이션이며, 다시 애플리케이션이 인프라스트럭처가 된다는 설명을 읽으면서 장자의 '호접지몽'이 떠올랐다. 영화 매트릭스의 가상 세계 만큼이나 클라우드 세계는 거의 모든 것이 소프트웨어로 움직이므로 너무나도 적절한 설명이 아닐까 싶다. 이 책을 통해 클라우드 네이티브 인프라스트럭처 세상에 들어오신 독자 여러분을 환영한다.

--- 감수자 글---

결론: 전통적인 서버 운영 환경에서 프라이빗 또는 퍼블릭 클라우드로 이주하고 싶다면 이 책을 읽어보면 큰 틀에서 네이티브 클라우드를 달성하기 위한 접근 방향에 대해 깨달음을 얻을 수 있을 것이다. 레거시에 발목이 잡혀 전통적인 서버 환경을 그대로 사용해야만 하는 경우에도 이 책을 읽어보면 고민거리를 제법 많이 해소할 수 있을 것이다. 클라우드다운 인프라스트럭처의 아키텍처 수립에 대해 고민하는 모든 분들께 강력 추천한다.

EOB

토요일, 9월 08, 2018

[B급 프로그래머] 9월 1주 소식(빅데이터/인공지능, 암호화폐/블록체인, 읽을거리 부문)

(오늘의 짤방: p-values are easy to calculate, but have little to do with the truth. We look for keys under streetlights, instead of where we dropped them. via @thattai)
  1. 빅데이터/인공지능
  2. 암호화폐/블록체인
  3. 읽을거리
보너스: Why cancer is much harder for AI than Go or self-driving cars. via @Meaningness
EOB

토요일, 9월 01, 2018

[B급 프로그래머] 8월 5주 소식(개발/관리도구, 고성능 서버/데이터베이스 부문)

(오늘의 짤방: "Make it work, make it right, make it fast." via @utilforever)
  1. 개발/관리도구
  2. 고성능 서버/데이터베이스
EOB