토요일, 10월 11, 2014

[끝없는 뽐뿌질] 서피스 프로 3 (1편)

거의 1년 동안 아이패드를 업무용으로 사용하려 무진장 노력했으나, 결국 백기를 들고 마이크로소프트 진영에 투항하고 말았다. 오늘은 마이크로소프트의 버전 3(이라고 쓰고 '삼세번'이라 읽는다)의 위력을 유감없이 보여주는 서피스 프로 3의 특징을 정리하겠다. 1편에서는 하드웨어를 집중적으로 살펴보고, 2편에서는 주로 윈도우 7을 사용했던 분들을 위해 윈도우 8.1의 야릇한 특성과 팁을 살펴보기로 한다.

기존에 늘 사용해왔던 아이패드(에어를 사용하지는 않았지만 무게/크기는 에어를 기준으로 삼았다)와 집중적으로 비교해보자.

  • 무게는 아이패드 에어와 비교해 다소 무겁다(서피스 800g vs 아이패드 470g).
  • 크기는 아이패드 에어에 비해 크다(서피스 292.1mm x 201.4mm x 9.1mm vs 아이패드 240mm x 169.5mm x 7.5mm). 하지만 화면 비율이 3:2이므로 크기에 비해 안정적으로 느껴지며(너무 길지 않다), 전자책을 읽거나 문서 편집이 많은 경우에 특히 유리하다(업무용에서 서피스 프로 3가 확실히 앞서는 느낌).
  • 화면 해상도는 인상적이다(서피스 2160x1440 vs 아이패드 2048 x 1535). 해상도가 이보다 더 높아질 경우 전력 소모가 커지고 12인치 화면에 표시되는 글자가 읽기 불가능해지는 문제가 있다(참고로 서피스 프로 3의 기본 화면 확대 비율은 150%로 설정되어 있으며, 업무 등 목적을 위해 100%로 바꾸는 순간 아아주우우 작은 글씨를 보게 될 것이다.).
  • 서피스 프로 3를 세울 수 있는 킥스탠드가 걸작이다. 처음에 킥스탠드를 세울 때 부서질까봐 무척 조심스러웠는데, 익숙해지니 불편함이 없게 되었다. 최대 굽힐 수 있는 각도가 예술이다. 사용자가 눈높이와 목 각도를 맞추는 대신 서피스 프로 3가 각도를 맞춰준다고 생각하면 틀림없겠다. 중간에 걸림 없이 자유롭게 각도를 정할 수 있다.
  • 35와트 전원 공급용 어댑터는 무게/크기 관점에서 만족스럽다. 특히 어댑터에 달린 여분의 USB 충전 포트는 전력 소모가 큰 외장 디스크를 장착하거나, 아이패드나 아이폰 등과 같은 추가 장비를 동시에 충전할 수 있기 때문에(서피스를 사용하면서 아이패드를 충전할 경우 상당한 시간을 요하므로 애플 12W 어댑터여 안녕이라고 선언하기는 곤란하다.) 활용도가 무척 높다. 애플의 매그세이프와 유사한 형태의 자석으로 붙는 전원 단자 설계도 마음에 든다. 하지만 8자 선 길이가 짧고 애플 어댑터처럼 선을 감을 수 있는 장치가 없으며, 애플 어댑터와 마찬가지로 케이블이 단선될 가능성이 높은 형태라서 주의 깊게 관리하지 않으면 생돈 11만원이 날아갈 것이다. T_T
  • 서피스 펜이 번들이다. (물론 전문가들 입장에서는 불만스러울 가능성이 높지만) 일반인 관점에서 쓸만한 마우스펜이 따라온다. 펜 버튼만으로 자동으로 서피스 프로 3를 구동하고 원노트를 띄워주므로 필기와 그림 작업이 많은 사람에게 도움이 된다. 물론 펜 내부에 AAAA 건전지가 들어간다는 사실을 기억해야 한다. 제일 처음 서피스 프로 3를 뜯고 나서 하는 작업이 바로 펜에 건전지 넣기라는... 한가지 힌트를 주자면, 서피스 펜을 서피스 프로 3 옆면의 전원 단자 근처에 자력으로 붙일 수 있다. 물론 일시적인 편의성을 제공하는 기능이므로 이렇게 붙인 상태에서 여행을 하면 안 된다!
  • 부팅/깨어나기 속력: 전원이 꺼진 상태에서 시작하는 콜드 부팅은 아이패드에 비해 빠르며(서피스 12~15초 vs 아이패드 28~32초), 잠들기에서 깨어나는 속도는 비슷하게 느껴진다.
  • 팬 소음: 대부분 조용하지만, (CPU를 많이 사용하는) 특정 작업을 시작하면 은근히 나오는 펜 소음이 제법 거슬린다. 아이패드의 완전 무소음에 익숙한 사용자로서는 조용한(아니 조용해야 하는) 곳에서 작업할 경우 난감할지도 모르겠다.
  • 발열: 아이패드에 비해 확실히 발열이 많이 느껴진다. 분산한다고 노력은 했지만 특정 부위가 뜨끈뜨끈해진다.
  • 스피커: 돌비 사운드 스테레오 스피커에서 나오는 소리는 크고 또렷하다. 아이패드에 비해(모노 사운드???) 월등히 좋은 느낌이다.
  • 카메라: 전후방 모두 500만화소라서 아이패드의 FaceTime HD 카메라 120만 화소에 비해 스펙상으로는 뛰어나다.
  • 속력: Core i5 제품군과 4G 메모리를 사용하는데, 웹 브라우징이나 오피스 작업 등에서 전혀 불편함을 느끼지 않는다. 한마디로 쾌적하다. 그래픽 가속기가 내장형이라 복잡한 3D 게임은 무리가 있을지도 모르겠다.
  • 배터리 수명: 웹 브라우징 시 최대 9시간이라고 하는데(이 말을 곧이 곧대로 믿기 어렵다. T_T 화면을 최대로 어둡게 쓰고 플래시가 들어 있는 페이지를 적게 보고... 등등), 아무래도 아이패드에 비하면 아쉬움이 많으리라 본다.
  • 무선 네트워크: 현재 서피스 프로 3에는 3G/LTE 버전이 존재하지 않는다. 아이패드는 LTE를 지원하는 모델이 있으므로 언제 어디서든 바로 인터넷 접속이 가능하지만, 서피스 프로 3는 와이파이를 지원하는 무선 AP나 에그 또는 테더링을 지원하는 스마트폰이 있어야 인터넷에 접속 가능하다.
  • 기타: 내장 무선 랜 모듈을 인식하지 못하거나 블루투스 마우스를 잡지 못하는 등 이해하기 힘든 돌발 상황이 벌어지는 경우가 있었다.

돈을 투자하면 삶이 편해지는 부분을 점검해보자.

  • 타이핑 커버는 물컹한 키 감이 아닌 기계식과 다소 유사한 키 감과 흔히 보조 키보드에서 볼 수 있는 요상한 작은 배열이 아닌 손가락에 맞는 키캡 크기로 인해 소형 블루투스 키보드에 실망하신 분이라면 반겨할만하다(물론 빠르게 타이핑할 경우 조금 흔들린다는 느낌이 들긴 하다). 게다가 ESC 키(ESC 없는 블루투스 키보드에 저주를!)와 근접센서를 활용한 백라이트까지 지원하므로 있을 건 다 있다고 보면 된다. 자석 연결부가 중간에 하나 더 있어서 자연스럽게 키보드 뒤가 들린 형태의 자세가 나오므로 편하게 쓸 수 있다. 타이핑 커버를 완전히 뒤로 젖힐 경우 키보드 입력이 중지되므로 타이핑 커버를 벗기지 않고서도 태블릿 형태로 사용할 수 있다(물론 조금 어색하긴 하다). 본체와 함께 공짜로 제공되었다면 초대박이었겠지만 무려 16만 4천원이나 하는 가격이 이 모든 장점을 갉아먹는다. 그럼에도 불구하고 타이핑 커버는 선택이 아니라 필수라는 사실이 우리를 울게 만든다(타이핑 커버가 없는 서피스 프로 3는 앙꼬 없는 찐빵일지도...). 서피스 펜을 넣을 수 있는 스트립이 타이핑 커버에 제공되지만 약해서 쓸만하지 못한 느낌이다. 타이핑 커버 패드는 재질이 유리처럼 느껴져서 감촉이 나쁘지 않다.
  • 옆면에 미니 디스플레이 포트가 존재한다. 따라서, 당신이 애플 애호가일 경우 집에서 뒹굴고 있는 애플 정품 또는 짝퉁 미니 디스플레이 어댑터를 재활용(응?)하면 VGA, DVI, HDMI 연결이 가능해진다. 마이크로소프트에서 서피스용 정품도 판매하지만, 40불(국내에 들어오면 5만원 넘는다에 한 표)이나 하기 때문에 굳이 이 물건을 살 이유가 있을까 싶다. HDMI 연결을 위해서라면 60불을 투자해 마이크로소프트 와이어리스 디스플레이 어댑터를 구입하면 무선으로 미러링(!)이 가능해진다.
  • 옆면에 USB3.0 포트와 뒷면에 microSD 포트가 존재하므로 (무척 아쉽게도 USB 포트가 1개이므로 제한적이나마) 확장성을 제공한다. 특히 microSD 카드의 경우 요즘 가격이 많이 떨어졌기에 class 10 UHS-I을 지원하는 녀석으로 구입해서 개인 자료 저장용으로 붙박아두면 가격 대비 성능이 아주 좋아진다. microSD 포트는 뒷면 킥스탠드 뒤에 숨겨져 있으므로 위치를 찾는 과정에서 숨바꼭질을 잘 하기 바란다. microSD 카드는 보통 FAT32로 포맷되어 있는데 exFAT으로 포맷해놓으면 여러 가지 장점이 생길 것이다(늘어난 최대 파일 크기, 맥OS X용 기계에 가져갔을 경우 호환성 강화).

결론: 기존 태블릿을 사용하면서 업무용으로 애플리케이션과 파워 부족을 심하게 느꼈거나, 노트북을 들고 다니면서 무게와 크기에 불만을 품는 사람이라면 서피스 프로 3를 조심스럽게 추천해본다(가격만 아니면 팍팍 질러라고 뽐뿌질을 하겠지만... 타이핑 커버만 16만원이 넘으니...). 서피스 프로 3는 개인용이라기 보다는 업무용에 가깝다는 사실을 다시 한번 언급하고 넘어가겠다.

EOB
작성자: 시간: 댓글 5개:
라벨:

금요일, 10월 10, 2014

[일상다반사] (Quora) 천재들이 생각하고 행동하는 패턴

Quora에 What patterns can be observed in the way geniuses think and behave?라는 글이 올라와 독자 여러분들께 소개 드리려한다. 천재들이 생각하고 행동하는 패턴은 어떤지 함께 살펴보자.

제가 만났던 가장 똑똑한 사람들(주로 교수와 대학원생)에게서 발견되는 몇 가지 패턴을 정리합니다. 재현 가능하거나 이런 조건만 충족하면 천재가 되거나하지는 않습니다. 그냥 있는 그대로 읽어주세요.

  1. 천재들은 추상화를 오르내리는 과정에서 극도로 재능을 보입니다. 천재들은 겉으로 보기에는 연관성이 없는 사실을 거의 즉시 큰 그림에 끼워 맞추고 필요한 세부 수준으로 파고드는 능력이 있어 보입니다. 학습할 경우에도 상향식이나 하향식을 추구하는 대다수 사람들과는 달리 한번에 모든 추상화 수준에서 배우려 합니다.
  2. 천재들은 많이 추정합니다. 창의적인 사고는 기존 추정을 깨야한다는 이야기를 들어왔기에 직관적이지 않아보일지도 모르겠습니다. 물론 기존의 추정을 깨어야 창의적인 사고가 나온다는 말은 사실일지도 모릅니다. 하지만 천재들은 아주 빨리 수 많은 추정을 하고 가설을 검증하고 필요하다면 아주 느리게 추정을 바꾸는 듯이 보입니다.
  3. 천재들은 정보를 압축하는 독특한 방법을 떠올립니다. 똑똑한 사람은 10단계로 연결하는 어려운 수학 공식을 볼지도 모릅니다. 반면 천재는 시각화해서 그림 한 장으로 봅니다.
  4. 천재들은 사고로부터 감정이나 외부 생각을 분리합니다. 적어도 과학에서는 천재들은 자신들의 사고에 어떤 외부적인 의미도 부여하지 않으려는 경향이 있습니다. 예를 들어, 천재들은 완전한 파괴라는 이미지로 인해 동요하지 않고서 국가를 효과적으로 침략하거나 무시무시한 무기를 사용하는 방법에 대해 생각할 수 있습니다. 이와 유사하게, 천재들은 주변 상황에 무관하게 작업에 집중할 수 있습니다. 시끄러운 소음이나 개인적인 정신적 외상에 관계 없이 말입니다.
  5. 천재들은 연관되지 않은 듯이 보이는 사물을 연결합니다. 천재는 종종 학습에서 T자형 모델을 따릅니다. 한 분야에서 전문가가 되지만 여러 분야를 파고 듭니다. 천재들은 주요 연구 분야와 무관한 사물 사이를 연결하거나 여기서 영감을 얻습니다.
EOB
작성자: 시간: 댓글 없음:
라벨:

수요일, 10월 08, 2014

[독서광] 슬로씽킹

엄청나게 바쁜 세상이다. 뭐든 빨리 빨리하지 않으면 남들보다 뒤떨어져 죽을지도 모른다는 압박감은 점점 더 심해졌으면 심해졌지 줄어들지는 않을 것 같다. 그래서 '슬로씽킹'이라는 제목의 책이 나오자마자 한 권 구입해서 천천히(응?) 읽어본 소감을 독자 여러분께 정리해드리겠다.

일단 제목은 참 잘 잡은 것 같다. 원서 제목부터 '느린 사고가 현명한 작업'이다보니 빠름을 강조하는 세상에서 '느린' 방법으로 제대로 일을 하는 방법을 기술하는 책이라는 느낌이 들지 않는가? 하지만, 이렇게 생각했으면 여러분은 낚인 거다. T_T 이 책은 뭐든 빨리 대증요법으로 처리하는 '퀵 픽스'에 대한 반작용으로 등장한 '슬로씽킹'을 설명하고 있지만, 실제 '슬로씽킹'이라는 개념이 '천천히 느긋하게 사고하기'를 벗어나기 어려운 관계상 1장 '우리는 왜 빨리빨리에 중독되었나'를 제외한 나머지 장은 '슬로씽킹'이라는 단어를 어떻게든 살리고자 끼워맞춘 듯한 행보를 보인다.

본문에 나오는 자기 잘못 인정, 문제 규정에 충분한 시간 들이기, 나무가 아니라 숲을 보기, 장기적인 관점에서 생각하기, 디테일에 집중하기, 철저한 준비와 전문성 강화, 협력과 집단 비평, 크라우드소싱, 리더십, 권한 이양, 정서적인 욕구 인정, 게임을 사용한 문제 해결이라는 각각의 주제를 보면 그럴싸하지만, '슬로씽킹'이라는 제목을 걸지 않고도 이미 여러 책에서 충분히(!) 설명되었던 내용이라 독창적인 '느림'의 미학을 기대한다면 포인트가 어긋날 가능성이 높다.

결론: 이 책은 주변에서 쉽게 찾아볼 수 있는 자기 계발서에 가깝다.

뱀다리: 서평을 쓰려 표지를 보니까... 이 책을 펴낸 출판사가 '쌤앤파커스'였다. (이하 생략)

EOB
작성자: 시간: 댓글 없음:
라벨:

월요일, 10월 06, 2014

[B급 프로그래머] 넷플릭스, AWS EC2 장애에서 원숭이 때문에 살아나다

2014년 9월 25일, 대략 10%에 이르는 AWS EC2 인스턴스가 '즉각적인 보안과 운영 업데이트'로 인해 재시동되는 상황이 벌어졌다는 사실을 애독자 여러분들은 이미 알고 계실 것이다. 넷플릭스는 여러 차례 경험을 토대로 비상시 복원 전략이 충분히 갖춰져 있었음에도 불구하고, 이런 환경적인 영향은 서비스에 심각한 영향을 미치기 마련이다. 다행히도 Chaos Monkey를 도입했기 때문에 넷플릭스는 충분한 대응을 할 수 있었던 것으로 보인다. 넷플릭스 기술 블로그에 올라온 A State of Xen - Chaos Monkey & Cassandra에서 핵심을 간추려본다.

데이터베이스는 애플리케이션 세상에서 응석받이 버릇없는 왕자로 자라왔다. 최상의 하드웨어, 풍부한 관리자 지원을 데이터베이스에 쏟아왔으며, 고의로 데이터베이스를 망치는 상황은 꿈도 꾸지 못한다. 하지만 민주화된(주목: 일베 용어 아님! 원문을 참조하시오.) 클라우드 공화국에서는 더 이상 이런 응석이 가능하지 않다. 노드 실패는 충분히 발생할 뿐더러 예상하고 있어야 한다. 따라서 실패를 견디고 계속 수행이 가능한 데이터베이스 기술이 필요하다.

넷플릭스에서 채택한 데이터베이스는 카산드라로 CAP 중에서 AP(Availability, Partition Tolerance)를 강조한다. C(Consistency)를 희생하는 관계상 궁극적으로 일관성을 유지하게 애플리케이션을 작성하는 식으로 설계 방향을 잡았다. 여러 해 동안 카산드라를 운영한 결과 실패에 상당한 내성을 발휘했다. 하지만 사람의 개입을 많이 요구했다.

2013년 실패한 카산드라 노드 복원을 자동화하기 위해 상당히 큰 투자를 결정했다. 그 결과 실패한 노드를 감지하고 파악할 수 있는 수준에 도달했다. AWS가 제공하는 클라우드 API를 사용해, 실패한 노드의 위치를 파악하고 프로그램적으로 대체 노드를 구축하고 새로운 카산드라 노드를 부트스트랩할 수 있게 되었다.

처음에는 완벽하지 않았다. 하지만 계속하다보면? 넷플릭스의 일하는 방식에 따라, 빨리 실패하고 좋은 방향으로 수정했다. 몇 달이 지나자 자동화가 더 나아졌다. 오탐 확률이 낮아졌고, 복구 스크립트는 거의 사람 손을 필요로 하지 않았다.

그리고... 9월 25일이 되었다.

EC2 재시동 소식을 듣자마자 우리는 입이 쩍 벌어졌습니다. 얼마나 많은 카산드라 노드가 영향을 받을지 알게 되자 현기증이 느 껴졌습니다. 그 때 지속적으로 수행한 Chaos Monkey 연습을 떠올렸습니다. 제 반응은 다음과 같았습니다. "한번 해보자!"(크리스토스 칼란치스)

그 주에 비상 대기 중이던 운영 요원들은 바짝 경계했고, 전체 클라우드 데이터베이스 엔지니어링 팀이 초 비상 상태가 되었다. 자동화를 믿었지만 신중한 팀은 최악을 준비하고 최상을 희망했다.

2700대 이상의 상용 카산드라 노드 중에 218개가 재시동 되었고, 22개 노드는 성공적으로 재시동되지 못했다. 따라서 문제가 생긴 노드는 온라인으로 살아나지 않았다. 자동화 시스템이 실패한 노드를 감지해 사람의 개입을 최소화하며 자동으로 교체했다. 넷플릭스의 다운타임은 0이었다.

반복적이고 주기적인 실패에 대한 연습은 모든 회사의 복원 계획의 일부가 되어야 한다. 만일 Chaos Monkey로 카산드라를 테스트하지 않았더라면, 아마 다른 이야기로 끝났을 것이다.

EOB
작성자: 시간: 댓글 2개:
라벨:

토요일, 10월 04, 2014

[B급 프로그래머] 10월 1주 소식

2014년도 100일이 남지 않은 상황이다. 아무쪼록 올 한해 마무리 잘 하시기 바라며 10월 1주 소식을 정리한다.

  1. 웹/앱 소식
  2. 개발/관리도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 없음:
라벨:

월요일, 9월 29, 2014

[B급 프로그래머] (Arstechnica) 삼성전자의 소프트웨어 인력 수는?

Arstechnica에 Samsung has more employees than Google, Apple, and Microsoft combined라는 글이 올라와 독자 여러분들께 간략하게 정리해 소개하겠다.

삼성이 "큰" 것을 사랑한다는 사실은 여러분도 다 알고 계실테다. 휴대폰도 크고, 광고비도 크고, 종업원 수도 크다. 삼성은 애플, 구글, 마이크로소프트를 모두 합한 직원 수 보다 더 많은 직원을 보유하고 있다.

27만 5천명은 구글에 비해 다섯 배다. 삼성이 기관총 스타일로 제품을 낼 수 있는 이유를 보여준다. 회사는 2014년 한 해에 스마트폰을 46종, 태블릿을 27종을 선보였다

삼성이 이 많은 사람들로 무엇을 하고 있을까? 2013년에 소프트웨어 엔지니어 수는 40,506명이다. 실제로 구글의 직원 중 18,593명만 "연구와 개발"(이라 쓰고 소프트웨어 개발이라 읽는다)을 담당하므로, 소프트웨어 엔지니어 수만 놓고 보면 삼성은 구글의 두 배다. 소프트웨어 군단은 삼성이 최근 확보한 자원이다. 소프트웨어 인력 수는 2011년 이후 45퍼센트 성장했다.

하지만 삼성의 2배 가까운 소프트웨어 엔지니어는 구글과 같은 영향력을 미치지 못한다. 터치위즈나 삼성의 중복된 안드로이드 생태계 앱들을 생각해보자. 회사는 안드로이드와 터치위즈를 만들어내는 모든 신형 스마트폰에 이식한다. 매년 70개에 이르는 디바이스를 배포하고, 2년 동안 모든 것을 지원해야 한다. 엄청나게 큰 프로젝트다.

삼성전자에는 또한 디스플레이와 SoC 부문도 있다. 엄청난 펌웨어와 드라이버를 개발해야 한다. TV, 카메라, 소형 장비 역시 소프트웨어가 필요하다. 그리고 삼성전자는 타이젠이라는 독자적인 운영체제를 만들고 있다.

삼성전자는 거대한 회사이며, 더 큰 "삼성 그룹"의 일부다. 삼성 그룹은 전화기, 테블릿, 반도체, 디스플레이, TV, 랩탑, 프린터, 카메라, 가전용품은 물론이고 삼성 그룹은 대형 컨테이너선, 신용카드, 정유 플랜트, 보험, 테마 마크, 엑스레이, 마천루 건설과 같은 다양한 분야에 다양한 제품을 만든다. 모든 부분에 모든 제품을 제공하기 위한 시도는 삼성을 전방위로 뻗어가는 회사로 만들고 있다. 반면 애플과 구글은 초점을 맞춘 라인업으로 하드웨어 전쟁 지역의 선별을 원하는 듯이 보인다.

EOB
작성자: 시간: 댓글 8개:
라벨:

토요일, 9월 27, 2014

[B급 프로그래머] 페이스북 확장에 규정은 없다

하드웨어 공학에서 몇 가지 작업 방식이 있으며, 공학도들은 심지어 필요한 경우에도 이를 어기려 들지 않기 때문에 단순히 규칙을 따른다. 하지만 페이스북은 어떨까? 오늘은 테크크런치에 When It Comes To Facebook Scale, You Can Throw Out The Rulebook라는 글이 올라와서 독자 여러분들께 간략하게 소개드린다.

페이스북은 하드웨어 상당수를 직접 만들기 시작했다. 따라서 공학도들은 일이 어떻게 진행되어야 하며, 페이스북의 확장을 위해 장비를 구축할 경우 생각을 달리할 수 있게 되었다. 창의적인 사고가 필요한 셈이다. 페이스북의 코드리는 다음과 같이 말한다. "페이스북은 도전, 비용, 운영 환경을 이해하고 있으며, 외부 업체보다 더 나은 결과를 얻어야 합니다. 우리는 페이스북에 특별히 필요한 요구 사항을 전문적으로 다룰 수 있습니다."

페이스북이 창의적인 사고를 격려하는 한 가지 방법 중 하나가 전문 분야를 건너뛰는 협업이다. 페이스북은 공학도들이 각자 일하는 대신 함께 일할 때 흥미로운 일이 벌어진다는 사실을 발견했다. 다른 회사들이 서버, 스토리지, 데이터베이스 등등으로 공학팀을 격리하지만, 페이스북에서는 통합적으로 한데 묶는다. 다양한 팀이 함께 일하면 문제를 해결하기 위한 새로운 방법을 찾을 수 있으니까.

심지어 하드웨어 제조사들도 자사 공학도들을 데이터센터로 보내 자신들이 설계한 하드웨어를 사람들이 사용하는 모습을 지켜보는 관례를 정립하지 않았다. 하지만 직접 뛰어들어 하드 드라이브를 교체하느라 스크류 6개(또는 16개)를 빼는 작업을 지켜보고, 매년 수 백번 넘게 이런 작업을 한다는 사실을 알게 되면 뭔가 더 간단한 방법이 필요하다는 사실을 깨닫게 된다.

따라서 페이스북은 디스크 어래이를 다르게 설계했다. 쉬운 유지보수를 위해 스크류가 하나도 없다. 커다란 녹색 레버를 당겨 배열을 튀어나오게 한 다음, 힌지 덮개를 당기고 하드 드라이브를 꺼내 새 하드 드라이브로 교체한다. 물론 스크류는 하나도 없다. 다른 회사의 경우에는 기술자들이 유지보수에 전혀 신경쓰지 않기에 작은 스크류와 교체가 어려운 방식을 고집한다.

새로운 기계를 다룰 경우 약간의 수고만 감수하면 되지만, 수천 대나 심지어 수 만대를 다룰 경우 이야기가 달라진다.

페이스북 공학도들이 상자 바깥으로 나와서(글자 그대로 :)) 생각하게 만드는 또 다른 방법은 서버 설계다. 공학도들은 서버 설계가 2u 랙에 맞아야 하지만, 만일 랙 제약이 없다면 어떤 식으로 서버를 설계할지 상상하라고 주문한다.

이런 제약을 버리면, 다양한 가능성이 열린다. 공학도들은 길고 좁은 박스를 만들어 왔다. 페이스북은 새로운 크기에 맞춰 랙을 설계했다. 박스는 랙 바깥으로 미끌어져 빠져 나오며, 상단을 열면(물론 스크류는 없다), 한번에 모든 부품이 눈에 들어온다. CPU 옆에 붙은 RAM처럼 관련된 부품끼리 가까이 모여있다.

독특한 하드웨어 형태를 양산할 때, 이를 오픈소스화 해서 오픈 컴퓨터 프로젝트에 공개한다. 확장 가능한 컴퓨터 문제를 해결하고 유지보수가 쉽고, 더 효율적으로 움직이고, 생명 주기 동안 비용 절감이 가능한 하드웨어를 생산하는 방법을 함께 공략하려는 시도다.

창의력과 상상력이 궁금하다면 페이스북에서 힌트를 얻기 바란다.

EOB
작성자: 시간: 댓글 2개:
라벨:

금요일, 9월 26, 2014

[B급 프로그래머] 배시 셸쇼크 버그

인터넷을 떠들썩하게 만들었던 하트블리드 버그에 이어 이번에는 더 큰 녀석이 등장했다. 셸쇼크라 불리는 카테고리 5급 버그인데... 사실상 거의 모든(99%) 리눅스/맥OS X 컴퓨터에 설치된 배시 셸의 문제이므로 회피하기가 지극히 곤란한 상황으로 보여진다. T_T

일단 여러분 컴퓨터(운영체제가 리눅스나 맥OS X)에 문제가 있는지부터 확인해보자. 배시 셸을 하나 열어 다음 명령을 수행해보자.

$ env x='() { :;}; echo vulnerable' bash -c 'echo this is a test'

"vulnerable"이 답으로 나오면 여러분 시스템은... 보안에 문제가 있다고 보면 되겠다. 문제는 바로 "() { :;};" 부분이다. 이 함수는 뒤에 (무조건 실행되는) 임의의 코드를 허용하므로, 잠재적으로 '악성' 코드를 설치할 수 있는 구멍이 활짝 열린다.

자 그렇다면 악당들은 이런 보안 문제를 어떻게 활용악용할까? 간단하게 설명하자면 HTTP 요청을 던지며 특정 문자열을 잘 조합해 원격 컴퓨터에서 실행 가능한 형태로 만들면 된다. 기술적인 토론은 What is a specific example of how the shellshock bash bug could be exploited?를 보면 되며, 실제로 DDoS 공격에 활용되었다는 소식도 들려오므로 강 건너 불 구경할 상황은 이미 넘어선 듯이 보인다.

레드햇과 우분투는 이미 패치를 발표했으며, 애플도 조만간 버그 픽스를 발표할 것으로 보인다. 물론 겉으로 드러나는 증상만 피하는 긴급 패치이므로 공격하는 쪽에서 다른 우회책을 사용할 가능성도 배제할 수 없기에 패치를 설치하더라도 100% 안전한 상태라 보기는 어렵다. 따라서 지속적인 주의가 필요하다.

핵심 요약: 엄청나게 심각한 버그이므로, 패치를 잽싸게 설치해야 한다. 한가롭게 기다릴 시간이 없다.

EOB
작성자: 시간: 댓글 11개:
라벨:

수요일, 9월 24, 2014

[B급 프로그래머] 9월 3주 소식

이번 주는 조금 늦게 소식을 전한다.

  1. 웹/앱 소식
  2. 개발/관리도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 9월 20, 2014

[독서광] 가장 인간적인 인간

그녀라는 영화를 보고난 다음 너무 마음에 들어 맥주에 통닭을 뜯으며 대본을 읽기도 했었다(참고로 이런 일은 자주 일어나지 않는다). 그런데, 트위터에서 누군가 '그녀'와 관련해 '가장 인간적인 인간'이라는 책을 추천하는 글을 읽고 나서 본능적으로 구매를 해뒀는데, 몸과 마음이 바빠 차일피일 미루다 우연이 눈에 들어와 손에 쥔 순간... 2014년도에 읽은 가장 멋진 책이 되리라 감을 잡고 말았다.

이 책은 튜링 테스트에 대한 내용을 중심으로 전개된다. 한 가지 특이한 사항이 있다면, 튜링 테스트를 통과해 '(컴퓨터인) 내가 사람이다'를 증명하는 대신 거꾸로 '(사람인) 내가 진짜 사람이다'를 증명하려는 노력이 주제라는 점이다. 막강한 계산 능력과 지금까지 축적된 공학적, 사회적인 기술을 바탕으로 사람을 위협하는 인공지능 군단에 맞서 가장 인간적인 인간이라는 사실을 심사위원들 앞에 납득시켜야만 하는 인간 연합군이 바로 이 책의 주인공이다. 인간 연합군 중에서도 특히 탁월한 기량을 발휘해 뢰브너 프라이즈에서 '가장 인간다운 인간' 상을 수상한 브라이언 크리스찬은 이 책에서 '가장 인간다움'이 무엇인지에 대해 고민에 고민을 거듭한다.

이 책의 집필 목표는 1장에서 명확하게 드러난다. 크리스찬의 의도를 같이 살펴볼까?

우리는 테니스 경기, 철차 맞히기 시합, 표준화된 각종 시험 등에 대비해 훈련을 한다. 나는 튜링 테스트도 마찬가지라 생각했다. '내가 얼마나 인간적인지'를 평가하는 것이기 때문에 이 경우에 '인간다움'이라는 것은, 그리고 자기 자신답게 행동한다는 것은, 단순히 어떤 능력을 보여주는 것 이상의 무엇을 함축하고 있는 것이다. 적어도 나에게는 그랬다.

그리고 이 '이상의 것'이 정확히 무엇인지를 밝혀내는 것이 바로 이 책의 핵심을 이룰 것이다. 이 책에서 내가 발견한 답변들은 튜링 테스트를 넘어 우리의 삶 전반에 적용될 수 있을 것이다.

그리고 나서 크리스찬은 문제의 핵심으로 돌진한다. 호프스태터가 G.E.B에서 '인지'에 대한 비밀을 찾기 위해 첫 페이지부터 마지막 페이지까지 무지막지하게 정공법으로 밀어붙이는 방식과는 정 반대로 조금은 유머러스하게(종종 망가진 자신의 모습도 보여주면서...) 생각이나 대화가 점차 컴퓨터처럼 변하고 있는(그래서 튜링 테스트에서 컴퓨터가 점점 더 유리해진다고 볼 수도 있다) 현대인의 '인간다움'을 다양한 각도에서 파헤친다. 상태 독립적 대화와 상태 의존적인 대화, 대화와 장소 적합성, 연애 전문가 동호회와 체스 슈퍼 컴퓨터, 반전문가와 전문가 체계, 이야기 도중 끼여들기와 점잖게 기다리기, 말이 이어지게 만들어주는 대화의 손잡이, 무손실 압축과 엔트로피에 대한 설명을 읽다보면 인간적인 인간이 되는 일이 결코 쉽지 않다는 사실(그래서 우리는 모두 고독한지도 모르겠다)을 깨닫게 될지도 모르겠다.

결론: 두 말할 필요 없이, 2014년에 읽은 최고의 책이다. 절판되기 전에 관심있는 독자분들께서는 서둘러 지금 당장 구매하는 편이 좋지 않을까 싶다.

EOB
작성자: 시간: 댓글 2개:
라벨:

금요일, 9월 19, 2014

[일상다반사] 전문 검색과 분석을 위한 Elasticsearch 서버: 아파치 루씬 기반의 고성능 엔터프라이즈 플랫폼

지난 4월 말에 아파치 Solr 4 구축과 관리 : 오픈소스 루씬 기반 엔터프라이즈 검색 플랫폼이라는 제목으로 독자 여러분께 번역서를 하나 소개해드린 바 있다. 오늘은 Solr와 치열한 경쟁을 벌이고 있는 루씬 기반의 또 다른 검색엔진인 일래스틱서치 출간 소식을 전해야겠다. 현재 Yes 24에서 절찬 예약판매 중인 이 책은 일래스틱서치와 관련해 바로 사용 가능한 필수적인 정보를 꽉꽉 담은 책이라 보면 틀림없겠다. 원 저자가 라팔 쿠크로 지난번 '아파치 Solr 4 구축과 관리'를 읽고 마음에 들었다면 이 책 역시 여러분 취향에 딱 맞을 가능성이 높다.

일래스틱서치는 지난 번에 소개한 Solr 4의 기능과 거의 유사한 다음 기능을 제공한다. 따라서 일래스틱서치를 사용하느냐 Solr를 사용하느냐가 가장 큰 고민거리일지도 모르겠다.

  • JSON API
  • 검색 결과 강조(highlight)
  • 패싯 검색과 필터링
  • 공간 지리 검색
  • 빠른 점진적인 갱신과 색인 복제
  • 캐시
  • 클러스터 구성(고가용성)
  • 복제
  • 분산 색인/샤딩
  • 모니터링 인터페이스

다행히도 역자 서문에 제시한 바와 같이 Apache Solr vs ElasticSearch라는 사이트에서 아파치 솔라와 일래스틱서치의 기능을 API, 색인, 검색, 플러그인, 분산 측면으로 나눠 분석하고 있다. 검색 자체 기능만 놓고 보면 대동소이한데, 일래스틱서치는 외부 시스템과 연동 측면에서 월등하다.

예를 들어, 외부에서 들어오는 로그를 쌓는다고 가정하자. Solr 4를 사용할 경우에는 애플리케이션을 작성해 연결해야 하는 반면 일래스틱서치는 Rivers 플러그인을 사용해 외부에서 들어오는 들어오는 입력을 그대로 받아 색인이 가능하다. 자체적으로 지원하는 트위터, RabbitMQ, CouchDB, Wikipedia는 물론이고, 공동체에서 지원하는 수많은 플러그인(ActiveMQ, Amazon SQS, CSV, Dropbox, Filesystem, Git, GitHub, JDBC, JMS, kafka, LDAP, MongoDB, Redis, Neo4j, Solr, RSS, Subversion, DynamoDB, IMAP/POP3 등)을 사용해 외부 소스와 연계가 가능하다. 또한 최근 일래스틱서치의 일원이 된 오픈소스 로그 관리 도구인 로그스태시를 사용할 경우, 외부에서 들어오는 자료 형식을 변환한 다음에 일래스틱서치에 저장할 수 있으므로 유연성을 극대화할 수 있다. 이게 바로 일래스틱서치의 최대 강점이다.

일단 오늘 소개한 책을 읽으며 공부하고 계시면, 후속작으로 Open Source Log Analysis with Elasticsearch를 준비해서 선보일테니 독자 여러분들의 많은 성원 부탁 드리겠다.

EOB
작성자: 시간: 댓글 없음:
라벨:

수요일, 9월 17, 2014

[독서광] 비즈니스 모델의 탄생

린 스타트업 관련 서적을 읽으며 알게 된 이 책을 구입해두고 (여러 가지 이유로 인해) 한참 동안 읽지 않았었다. 그러다가 린 분석 책을 읽는 도중에 다시 한번 비즈니스 캔버스가 떠 올라 이 책을 펼쳐보게 되었다. 비즈니스 모델 캔버스를 정리한 그림은 (독자 여러분들께서도 이미 잘 알고 계시겠지만) 다음과 같으며, 이 책의 처음부터 끝까지 일관성있게 사용되므로 유심히 봐둘 필요가 있다.

이 책의 가장 큰 장점은 편집의 아름다움이다. 보기 좋은 떡이 먹기도 좋다고 이 책의 편집은 정말로 신경 썼다는 느낌이 팍팍 오게 만든다. 원서는 물론이고 번역서 자체의 편집도 공을 들였기에 읽는 과정에서 상당한 즐거움을 느꼈다. 예쁘기만 하고 특별한 내용이 없다면 이것도 큰 문제일텐데, 출간된지 조금 시간이 흐르는 바람에 한 물 간(예: 롱테일과 블루오션 전략(으아아악) T_T) 내용이 등장함에도 불구하고 여전히 비즈니스 전략 구성에 도움을 준다는 생각이다. 요즘 뜨거운 주제가 린 스타트업이긴 하지만, 린 스타트업에서 비즈니스 모델을 설명할 때 빠지지 않고 등장하는 몇 가지 개념을 이 책에서 자세히 설명하므로 짚고 넘어갈 필요가 있겠다.

이 책은 비즈니스 모델 캔버스의 구성 요소를 설명한 다음 자주 사용되는 비즈니스 모델 패턴(언번들링, 롱테일, 멀티사이드 플랫폼, 무료 비즈니스 모델, 오픈 비즈니스 모델을 다양한 사례와 함께 소개한다. 그리고 나서 비즈니스 모델을 설계하는 다양한 기술과 도구(고객 통찰, 아이디에이션, 비주얼 씽킹, 프로토타이핑, 스토리텔링, 시나리오)를 소개한다. 다음으로 비즈니스 전략(비즈니스 모델 환경, 비즈니스 모델 평가, 블루오션 전략에 대한 비즈니스 모델 관점, 여러 비즈니스 모델 관리)에 이어 비즈니스 모델 설계 프로세스를 설명하며 마무리한다. 앞서 이미 언급했지만 이 책은 작업의 시각화를 위해 그림, 다이어그램, 표, 흐름도 등 다양한 기법을 사용하므로, 실제 비즈니스 모델을 만드는 과정에 참고할만한 손쉬운 템플릿을 확보하기 딱 좋다는 생각이 들지도 모르겠다(주의: 너무나도 당연한 이야기지만, 템플릿이 좋다고 더불어 아이디어도 좋아지지는 않는다. T_T). 예쁜 템플릿으로 끝나고 말면 허무할텐데, 다행히도 천편일률적인 예를 위한 예를 대신해 여러 기업들의 실제 사례를 소개하므로 유사한 분야에 속한 선구자들의 비즈니스 모델 수립 경험을 습득할 수 있는 기회를 제공한다.

본질적인 질문을 하나 해보자. 비즈니스 캔버스를 사용해 머리를 굴릴 경우 얻는 이익이 무엇일까? 바로 강력한 지적 능력을 사용한 사고 실험이 가능하므로 실제 사업을 벌여보기 전에 나를 알고 적을 알고 위험이 무엇인지 파악할 수 있다는 장점을 얻는다. 종이 위에서 생각을 끄적이는 행위가 현실과는 동떨어진 탁상 공론으로 생각할지도 모르겠는데("해봐야 안다" 파의 주장), 다양한 각도로 문제를 분석해 비즈니스 모델을 설계하지 않고 사업에 뛰어들며 이를 '린(lean)'으로 포장하는 전술은 요즘과 같이 복잡하고 빠르게 변하는 세상에서 자살 행위와 마찬가지다(실패도 무대포 실패가 아니라 제대로 계획된(응?) 실패여야 한다). 혁신과 변화를 추구하기 위한 토대로서 이 책을 활용하면 시행착오를 조금이라도 줄일 것이다.

책 내용과 편집이 궁금하시다면 Yes24에서 제공하는 본문 미리 보기를 읽어보시기 바란다. 또한 독자 여러분들을 위해 저자인 알렉산더 오스터왈더가 직접 만든 발표자료(물론 영어다... T_T)를 올려드린다. 책을 읽은 다음에 정리 목적으로 사용해도 좋겠다.

결론: 스타트업에 뛰어든 분이라면 기본 소양을 쌓기 위한 기초 서적으로 강력 추천한다. 최소한 내가 하는 사업의 비즈니스 모델 수립은 내가 직접 해야 하지 않겠는가?

EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 9월 13, 2014

[독서광] 린 분석: 성공을 예측하는 31가지 사례와 13가지 패턴

1년 반 전에 Running Lean: 린 스타트업이라는 책을 한 권 소개해드린 적이 있었다. 오늘은 이 책의 연장선 상에 놓인 '린 분석: 성공을 예측하는 31가지 사례와 13가지 패턴'이라는 책을 소개해드리려 한다(한빛미디어에서 선물로 보내주셨기에 감사의 말씀을 전한다).

이 책은 스타트업에서 꼭 필요한 좋은 지표가 무엇인지 정의하고, 상황에 맞춰 각 지표를 찾고 분석하는 방법을 소개한다. 그리고 나서 여러 분의 사업이 어디에 위치하며, 해당 위치에서 주의 깊게 살펴볼 지표를 제시한다. 마지막으로 이 책의 백미라고 볼 수 있는 목표 기준을 소개한다! 솔직히 처음 스타트업을 시작할 때 해보기 전에는 절대 알기 어려운 목표 기준을 업계 표준치로 정리했다는 사실 하나만으로도 이 책의 가치는 충분하리라 생각한다.

이 책에서 제시하는 구체적인 사업 모델은 전자상거래, SaaS, 무료 모바일 앱, 미디어 사이트, 사용자 제작 콘텐츠, 양면 마켓플레이스를 아우르며, 초기 IT 스타트업이 주로 채택하는 형태이므로 현실감 있게 다가올 것이다. 또한 사업 단계는 공감, 흡인력, 바이럴 효과, 매출, 확장으로 나눠 소개하므로, 현재 스타트업이 처한 상황에 맞춰 가장 중요하게 여겨 주의 깊게 살펴야하는 지표를 정의할 수 있다.

이 책의 장점은 상황별로 정리한 명확한 지침이다. 흔히 창업 관련 서적들은 뜬 구름 잡는 이야기만 하거나 희망찬 장밋빛 미래를 그리느라 정신이 없는데, 이 책은 사업 부문별로 단계에 따라 실질적으로 도움이 되는 지표와 목표 그리고 달성 방안을 제시하므로 읽는 즉시 응용 가능하다는 특징이 있다. 예를 보여드리기 위해, '무료 모바일 앱'을 기준으로 책에 나온 몇 가지 지표와 목표를 간략하게 정리해보겠다(나머지 모델에 대한 지표와 목표가 궁금하시다면 직접 책을 읽어보시라!).

  • 모바일 앱의 크기: 누구나 어디서든 앱을 쉽게 다운로드할 수 있게 하려면 '포털에 올려진' 앱 크기가 50MB 이하여야 한다.
  • 모바일 고객 확보: 다른 앱 안의 배너 광고는 일반적으로 설치 건당 1.5~4달러의 비용이 든다. 설치 건당 비용을 평균 0.5~0.75달러로 유지하는 편이 좋다.
  • 활동 모바일 사용자 비율: 사용자의 54%만이 앱을 사용하기 시작한 지 한 달 후에도 여전히 앱을 사용하며, 두 달이 지난 후에는 43%만 남고, 세 달이 지나면 35%만 앱을 사용한다고 한다. 앱 종류에 따라 크게 다르지만 사용자들은 앱을 평균적으로 하루 3.7회 사용했다.
  • 일일 활동사용자 평균 매출: 퍼즐/돌보기/시물레이션 게임은 0.01~0.05달러, 숨은 그림 찾기/어드벤처 게임은 0.03~0.07달러, 도박/포커/RPG 게임은 0.05~0.1달러
  • 모바일 사용자당 월 평균 매출: 업계 관계자들은 모바일 게임의 경우 일일 활동 게이머당 월 3달러, 즉 일 0.10 달러의 매출이 평균이라 말한다.
  • 모바일 앱의 평가 비율: 유료 앱은 평가율을 1.5% 이하로 예상하고 무료 앱은 평가율이 1%보다 훨씬 낮다고 예상하라.

위에서 정리한 내용을 보면 짐작하겠지만 지표에 대한 구체적인 수치가 등장하므로, 동종 업계를 벤치마크하는 목표 설정과 비교 과정에서 귀중한 조언을 얻을 수 있다.

혹시 책 IV부, 실무 적용에 나오는 나오는 사례 연구만 미리 읽고 싶은 분들이 계시면, Lean Analytics Book 홈페이지에 들어가서 Analytics Lessons Learned라는 무료 전자책(주의: 영어)을 받으시기 바란다. 마지막으로 'Lean Analytics' 발표자료(영어)를 올려드리니, 혹시 책을 구입하기 전에 미리 맛보기를 원하시는 독자분들께서는 간단하게 읽어보시기 바란다.

결론: 스타트업을 시작한 모든 분들께 이 책을 적극 추천한다.

EOB
작성자: 시간: 댓글 없음:
라벨:

금요일, 9월 12, 2014

[독서광] 불평등의 대가

가을을 맞이하여, 좋은 책을 집중적으로 소개하기로 마음먹었다. 1번 타자는 노벨상 수상자인 조지프 스티글리츠가 쓴 '불평등의 대가'다. 조만간 번역서로 나올 토마 피케티가 쓴 '21세기 자본'이 사람들에게 멘붕을 불러일으키겠지만, 오늘 소개하는 이 책 역시 결코 만만하지 않다. 일단 이 책을 펼치는 순간 절망이라는 깊은 심연 속으로 빨려들 가능성이 아주 높기 때문에 어지간한 강심장이 아닌 이상 주의해서 읽어야 겠다.

이 책은 상위 1%가 모든 것을 독차지해버린 미국의 불편한 현실을 집중적으로 파헤친다. 하지만 참으로 희한한 상황이 벌어지는데... 책을 읽다보면 어느새 무대가 미국이 아니라 한국으로 옮겨지는 기묘한 경험을 하게 된다. 분명히 미국 정치와 경제에 대한 논의가 진행되고 있지만, 한국 역시 만만치않은 싱크율를 자랑한다. 어떻게 보면 미국보다 더 미국스러운 한국이라는 생각이 들지도 모르겠다. T_T

책의 내용은 제목 그대로다. 불평등이 위험한 이유와, 불평등을 심화시키는 요인이 무엇인지 분석하고, 불평등을 해결하기 위한 방안을 제시한다. 정치, 경제, 사회를 넘나들며 불평등을 일으키는 주범(?)과 이들의 논리를 분석하며 어떤 문제점이 있는지를 날카롭게 파고든다. 책 내용을 기계적으로 요약하는 대신 본문에 나오는 몇 가지 뜨끔한 이야기를 들어볼까?

미국의 시장은 새로운 부를 창출하는 행위 대신에 다른 사람들에게서 부를 빼앗는 행위를 장려하는 방향으로 왜곡되어 있다.
불평등을 옹호하는 사람들은 상위 계층에게 더 많은 돈을 몰아주면 성장이 가속화되므로 모두가 그 혜택을 받게 될 거라는 반론을 펼친다. 이것이 이른바 낙수 경제 이론이다. ... 상위 계층에게 돌아가는 부는 하위 계층을 희생시킨 데서 나온 것이다.
중하위 계층의 재산은 대부분 소유 주택의 가치에 좌우되는 것이었기에 거품이 낀 주택 가격을 토대로 한 유령 재산에 지나지 않았다.
지금은 대부분의 노동자들이 확정 기여형 퇴직 연금 제도에 가입해 있다. 이 경우 사람들은 퇴직 연금 계좌를 직접 관리할 책임을 떠안아야 한다. 또한 주식 시장 변동과 인플레이션의 위험도 감수해야 한다.
가난한 사람들이 겪는 곤경을 그 사람들 탓으로 돌려서는 안 되며, 자신들은 자력으로 돈을 벌었다고 하는 상위 계층의 주장에는 귀를 기울일 필요가 없다.
정부가 시장 실패를 바로잡는 데서 상당한 성과를 올릴 때만 그 나라 경제는 번창한다.
사업가들의 주된 관심은 사회의 행복을 증진시키거나 시장 경쟁을 강화하는 데 있지 않다. 그들의 목적은 오로지 시장이 자신에게 유리한 방식으로 움직이게 만들어 자신의 수익을 끌어올리는 데 있을 뿐이다.
상위 계층의 돈벌이 수단 중 하나는 자신이 장악한 시장과 정치적 권력을 이용해서 다른 사람들을 희생시켜 자신의 소득을 늘이는 방법이다.
시장에는 승패를 식별하는 간단한 방법이 있다. 바로 그 사람이 가진 돈의 총액이다.
'지대'라는 용어는 원래 토지로 인한 수익을 이르는 말이었다.
현대적인 경제에서는 여러 가지 형태의 지대 추구가 존재한다. 첫 번째 형태는 국가 자산을 공정한 시장 가격 이하로 장악하는 방식이다. 두 번째 형태의 지대 추구는 정반대로 정부에 물건을 팔면서 시장 가격 이상을 받아 챙기는 방식이다. 세 번재 형태의 지대 추구는 공식적인 정부 보조금이나 비공식적인 보조금을 받는 것이다.
민간 부문은 자력으로 능숙하게 국민들로부터 지대를 뽑아낼 수 있다. 이를테면, 독점적인 관행을 통해서 정보와 교육의 혜택을 충분히 누리지 못하는 서민들을 수탈하는 것이다.
비유하자면, 공정한 게임을 하여 이기는 사람이 열심히 뛰어가는 사람이라면, 자신이 이길 가능성을 증대시키는 방향으로 아예 게임의 규칙을 정하는 사람은 고속철을 탄 사람이고, 심판까지 직접 고르는 사람은 제트기를 탄 사람이다.
세계화를 지지하는 사람들은 모든 사람들이 더 풍요롭게 될거라고 주장하는 걸까? 그들의 주장은 모든 사람들이 더 풍요로워질 가능성이 있다는 것뿐이다. 다시 말해서 승자가 패자에게 보상을 해줄 가능성이 있다는 이야기일 뿐, 반드시 그럴 거라는 이야기는 아니다. 승자는 대체로 그런 행동을 하지 않는다.
많은 국가들이 부실한 거시 경제 정책으로 인해서 일자리 소멸 속도가 일자리 창출 속도를 앞서가는 곤경을 맞았다.
부자들과 갑부들은 흔히 기업을 이용해서 자신을 보호하고 자신의 소득을 감춘다.
부유층에 대한 감세의 결과로 재정 적자와 국가 부채가 크게 늘어나고 있는 현실은 또 다른 측면에도 강력한 영향을 미친다. 정부는 교육, 과학 기술, 기간 시설 투자에 대한 지원을 축소해야 하는 곤경에 빠진다.
개발도상국에는 똑똑하고 부지런하고 열정이 넘치는데도 가난하게 사는 사람이 많다. 능력이 부족하거나 충분한 노력을 기울이지 않아서가 아니라 제대로 돌아가지 않는 경제에서 일하고 있기 때문이다.
신뢰가 없으면, 나중에 일이 복잡해질 거라고 판단되는 사업상의 거래는 이루어지지 않는다.
현재 언론 분야는 상위 1퍼센트에 의해 지배되고 있다. 이들은 비판적인 언론사를 매입하여 지배할 수 있는 자원을 가지고 있고, 손해를 보더라도 이런 전략을 고수할 의향이 있는 사람들도 있다.
상위 계층은 중위 계층에게 왜곡된 세계관을 심어 이들로 하여금 상위 계층의 이익에 도움이 되는 정책들이 자신의 이익에 도움이 된다고 믿게 만든다.
상위 1퍼센트가 여론을 형성하는 데 성공하고 있다는 사실은 신념의 변동성이 크다는 것을 입증한다.
문제는 물건이 시장에서 거래될 수 있듯이, 관념도 시장에서 거래될 수 있다는 점이다. 정책을 뒷받침하는 관념들은 더 말할 것도 없다.
우파는 인식 형성에서 교육이 차지하는 중요성을 알고 있다. 바로 이런 이유 때문에 우파는 각급 학교의 교육 과정 설계에 영향력을 행사하기 위해 적극적으로 활동한다.
민영화와 시장 자유화를 옹호하는 사람들은 오래전부터 이런 정책들은 지대 추구를 제한하기 위해 반드시 필요한 것이라며, 참으로 어이없는 주장을 펴왔다.
금융 부문의 혁신은 모든 미국인의 후생을 개선하는 것이 아니라 은행 경영진의 후생을 개선하는 방향으로 추진되었다.
기업들이 타인들에게 비용을 전가하고 있다는 사실은 대체로 쉽게 눈에 띄지 않는다. 기업들은 대개 지나친 위험을 추구한다. 물론 아무 사고 없이 여러 해가 흘러가기도 한다. 하지만 사고가 발생하면 수천 명이 피해를 입는다.
경제학의 기본 원칙에 따르면, 좋은 행위에 과세하는 것보다 나쁜 행위에 과세를 하는 쪽이 더 효과적이다.
최악의 신화는 예산을 긴축하면 경제가 회복되고, 정부 지출이 늘어나면 경제가 회복되지 않는다는 논리다. 이 논리에 따르면 정부의 재정 상태가 개선되면 될수록 사람들은 자신감이 붙어서 더 많은 투자를 한다는 것이다.
인플레이션율을 낮게 유지하자고 주장하는 사람들은 낮은 인플레이션이 경제 전반에 유익하다고 주장한다. 이들은 낮은 인플레이션으로 큰 혜택을 보는 채권 보유자들에 대해서는 거론하지 않는다.
많은 젊은이들이 열정과 희망을 품고 새로운 생활을 시작하는 것이 아니라 불안과 공포에 빠져 지낸다. 이들은 앞으로 힘겹게 상환해야 하고, 게다가 파산을 해도 탕감이 되지 않는 학자금 대출금이라는 무거운 짐에 짓눌린 채 침체된 시장에서 좋은 일자리를 찾아다닌다. 운이 좋아서 직장을 구한다 해도 이들이 받는 임금은 실망스러운 수준이고, 임금이 너무 적어서 독립하지 못하고 부모와 함께 사는 이들이 적지 않다.
오십 대 부모 입장에서는 자녀들도 걱정스럽고 자신의 미래도 걱정스럽다. 집을 잃지나 않을까? 압박을 견디지 못하고 조기 퇴직을 해야 하는 건 아닐까? 저축해 둔 돈이 대침체 때문에 크게 줄어들었는데 그것으로 노후 생활을 지탱할 수 있을까? 이들은 아무리 어려워도 자녀들에게 도움을 청할 수 없다는 사실을 잘 알고 있다.

본문에 나오는 내용을 보고 있으러면 눈물이 앞을 가린다. 마지막으로 이 책의 북트레일러를 보너스로 소개한다.

결론: 우리 사회가 불평등한 이유를 알고 싶은 모든 분들께 강력하게 추천한다.

EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 9월 06, 2014

[B급 프로그래머] 9월 1주 소식

독자 여러분께 즐거운 한가위 보내시기를 기원드리며, 9월 1주 소식을 정리해드리겠다.

  1. 웹/앱 소식
  2. 개발/관리 도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 3개:
라벨:

토요일, 8월 30, 2014

[B급 프로그래머] (Quora) 페이스북 아키텍처는?

Quora에 페이스북 아키텍처에 대한 질문이 올라왔기에 독자 여러분을 위해 정리해드린다.

  • 웹 프론트 엔드는 PHP로 작성되었다. 페이스북의 힙합 컴파일러는 PHP 코드를 C++ 코드로 변환하며, g++를 사용해 컴파일하므로 고성능 템플릿 엔진과 웹 논리 수행 층을 제공한다.
  • 정적 컴파일에 완전히 의존하지 못하는 제약으로 인해, 페이스북은 힙합 인터프리터 해석기와 PHP 코드를 해석해 힙합 바이트 코드로 변경하는 힙합 가상 기계를 개발하기 시작했다.
  • 비즈니스 논리는 Thrift를 사용해 서비스 형태로 만든다. 서비스는 서비스 요구 사항에 맞춰 PHP, C++, 자바로 만들어진다.
  • 자바를 사용한 서비스 구현은 일반적인 엔터프라이즈 애플리케이션 서버가 아니라 페이스북이 직접 만든 전용 애플리케이션 서버를 사용한다. 처음 보기에는 바퀴를 재발명하는 듯한 느낌이 들지도 모르겠지만, 톰캣이나 심지어 제티의 오버헤드가 페이스북의 요구 사항에 부가가치를 더하지 못하므로 대부분 Thrift를 사용한 형태로 공개되어 있다.
  • 영속적인 자료 저장은 MySQL, Memcached, 하둡 HBase를 사용한다. Memcached는 일반적인 범용 캐시 목적 뿐만 아니라 MySQL용 캐시로 사용된다. (옮긴이 주: 최근에는 SSD를 고려한 MySQL 패치로 성능 개선이 가능해져 Memcached 사용을 대폭 줄였다는 소식도 있다)
  • 오프라인 프로세싱은 하둡과 하이브를 사용해서 수행한다.
  • 로깅, 클릭, 피드와 같은 데이터는 Scribe를 사용해 전송하며, Scribe-HDFS를 사용해 HDFS에 저장된다. 맵리듀스를 사용해 후속 분석이 가능해진다.
  • BigPipe는 파이프라인 논리를 사용한 페이지 렌더링 가속 기술이다.
  • HTTP 프록시를 위해 Varnish Cache를 사용한다. 고성능 고효율로 인해 페이스북에서는 이를 선호한다.
  • 사용자가 올린 수십 억개의 사진은 Haystack을 사용해 처리한다. 저수준 최적화와 append만 존재하는 쓰기를 지원하는 전용 자체 스토리지 솔루션이다.
  • Facebook Messages는 샤딩과 동적 클러스터 관리에 기반한 독자적인 아키텍처를 사용한다. 비즈니스 논리와 영속성은 'Cell'이라는 단위로 캡슐화되어 있다. 각 셀은 사용자 일부를 처리한다. 사용자가 늘어나면 새로운 셀을 추가할 수 있다.
  • Facebook Messages의 검색 엔진은 HBase에 저장된 역 색인(inverted index)로 만들어진다.
  • 자동 완성 검색 기능은 전용 스토리지와 인출 논리를 사용한다.
  • 채팅은 Erlang으로 개발된 Epoll 서버에 기반하며, Thrift로 접근한다.
  • 적절한 복구 작업 흐름을 시작하거나 문제를 극복할 수 없을 경우 사람이 처리하게끔 감시 경고에 반응하는 자동화된 시스템을 구축했다.
  • 옮긴이 주: 페이스북이 보유한 서버는 백만대를 넘어선 것으로 추정한다. 페이스북은 최근 샌디스크로 넘어간 퓨전 아이오에서 엔터프라이즈급 고성능 SSD를 가장 많이 구매한 고객이다. MySQL 서버는 모두 SSD 기반으로 동작하고 있다고 추정한다.
  • 옮긴이 주: 최근 페이스북은 brtfs 메인테이너를 영입했다. 웹 서버의 파일 시스템부터 brtfs/SSD 조합을 사용해 성능 향상 작업을 벌이고 있는 것으로 추정한다.
EOB
작성자: 시간: 댓글 2개:
라벨:

토요일, 8월 23, 2014

[B급 프로그래머] 8월 3주 소식

금주에도 알차고 흥미로운 소식을 꽉꽉 채워서 전해드리겠다.

  1. 웹/앱 소식
  2. 개발/관리 도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 8월 19, 2014

[B급 프로그래머] 개발자를 강하게 만드는 것은 규율

Discipline Makes Strong Developers라는 글을 코딩 호러에서 읽었다. 물론 2007년 8월에 작성된 글이라 벌써 7년이 넘은 시점에서 끄집어 내는 이유가 궁금할 것이다. 간단하다. 여전히 유효하니까. 오늘은 개발자에게 규율이 중요한 이유를 정리해봤다.

스캇 쿤의 말을 한번 들어보자.

매달, 새로운 프로그래밍 언어나 방법론이 등장한다. 현신적인 추종자들이 인터넷 여기저기서 찬송가를 부른다. 생산성과 품질 향상에 대한 장미빛 전망을 약속한다. 하지만 모든 성공적인 개발자가 보유한 한 가지 특질이 존재한다. 모든 프로젝트를 성공하게 만들거나 실패하게 만드는 한기지 특질말이다.

바로 규율이다.

규율없는 개발자는 정시에 출시하지 못하며, 쉽게 유지보수 가능한 코드를 작성하지도 못한다. 규율이 잡힌 개발자는 프로젝트 성공을 이끌뿐만 아니라 다른 사람들의 생산성도 높일 것이다. 소프트웨어 아키텍트와 개발자들은 성공의 원인을 방법론으로 돌리지 않는다. 성공은 얼마나 규율이 제대로 잡혔는지로 귀결된다.

규율이 없다면, 도구나 언어가 아무리 좋아도 소용없다. 그렇다면 스티브 맥코넬의 코드 컴플리트에 나온 이야기도 살펴보자.

전산과 신입생에게 관례와 공학적인 규율이 필요한 이유를 설명하기란 어렵다. 내가 학부생이었을 때, 내가 작성했던 가장 큰 프로그램은 500행이었다. 전문가로서 500행보다 작은 유틸리티 수십 개를 만들었지만, 평균적인 프로젝트 크기는 5,000에서 25,000 행 정도였고, 500,000 행이 넘튼 프로젝트에도 참여한 적이 있었다. 소규모 프로젝트와 대규모 프로젝트에서 쓰이는 기술은 다르다. 규모가 큰 프로젝트에서는 완전히 새로운 기술 집합이 필요하다.

미항공 우주국에서 15년 동안 일한 내용을 회상하며, 맥게리와 파저스키는 사람의 규율을 강조하는 방법론이나 도구가 특히 효과적이라고 보고했다(1990). 아주 창의적인 사람들은 엄청난 수준의 규율이 잡혀있다. "형식이 해방을 이끈다"는 말도 있다. 위대한 아키텍트는 물리적인 재료, 시간, 비용이라는 제약 사항 내에서 작업한다. 위대한 예술가 역시 마찬가지다. 레오나르도 다빈치의 그림을 살펴보는 모든 사람이 잘 훈련된 세부 사항에 대한 주목을 찬양한다. 미켈란젤로가 시스티나 성당의 천장을 설계할 때, 미켈란젤로는 삼각형, 원, 사격형과 같은 기하학적 형태를 사용해 대칭적인 집합으로 구분했다. 이런 구조와 규율이 없었더라면, 300명에 이르는 인물은 예술적인 걸작품이라는 질서 정연한 구성 요소가 되기는 커녕 완전히 일대 혼란을 초래했을지도 모른다.

자 여기까지 왔으면, 규율의 중요성에 대해 독자 여러분들도 어느 정도 감을 잡으시리라 믿는다. 마지막으로 로버트 L. 글래스가 소프트웨어 크리에이티비티 2.0에서 언급한 규율에 대한 내용을 정리해보겠다.

시를 쓰는 사람들은 시 형식이 창의력을 구속하기보다 새로운 가능성을 제시한다는 사실을 안다. 운율을 맞추려고 고민하는 과정에서 (알맞은 단어가 눈에 띄기 바라는 마음으로 사전을 가나다순으로 뒤지는 등) 체계적으로 운율이 맞는 단어를 찾거나 창의적인 시어로 자신의 생각을 표현한다.

소프트웨어를 제작하는 과정도 크게 다르지 않다. 여기서도 체계와 창의력이라는 기묘한 단짝이 필수적이다. 예를 들면, 설계는 창의력이 필요하고 구현은 체계가 필요하다. 설계 방법론은 흔히 설계를 체계화된 활동으로 변환하려 들지만, 새로운 문제가 계속 쏟아지는 한 성공은 절대로 불가능하다. 물론 구현 단계에서도 창의력은 필요하다. 멍청한 컴퓨터에게 바람직한 해법을 하나하나 묘사하는 구현 단계에서는 엄청난 체계가 필요하지만, 완벽한 설계란 불가능하므로 설계에서 놓친 문제를 해결하려면 구현 단계에서도 창의력은 필수적이다.

오늘의 결론: 창의력과 규율을 조화롭게 가져가는 능력이 개발자의 필수 덕목이라는 사실을 잊지말자!

EOB
작성자: 시간: 댓글 1개:
라벨:

토요일, 8월 16, 2014

[일상다반사] 클린 코드 2쇄 임박과 특별 이벤트

작년 12월 말에 클린 코드 복간 소식을 전해드렸는데, 9개월 만에 1쇄가 다 팔려 2쇄 추가 인쇄에 들어간다는 기쁜 소식이 들어와 있다. 복간판임에도 불구하고 성원해주신 애독자 여러분 모두에게 진심으로 감사의 말씀을 전한다. 꾸벅.

여러분의 성원에 보답하기 위해, 클린 코드 발표 자료를 하나 올려드린다. 책을 읽는 과정에서 참고하면 좋겠다.

그리고, 클린 코드 2쇄 기념 특별 이벤트를 하나 준비하고 있다. 클린 코드로 그룹 스터디를 진행하려는 분들을 위해 초기 시작 단계에서 이 책을 효과적으로 읽는 방법과 핵심 포인트(상기 슬라이드 참고)를 소개해드리려 하는데(물론 특별 이벤트이므로 장소만 확보되어 있다면 당연히 무료로 진행해드린다!), 이메일(jrogue 에뜨 gmail.com)로 다음 내용을 간략하게 보내주시면 검토 후에 알려드리겠다. 꼭 필요한 분들께 기회가 가기 위해 프로 개발자분들께서는 넓은 아량으로 양보를 해주시면 감사하겠다. 신청 팀이 너무 많을 경우에는 두세 팀 정도를 선별할(아무래도 초기 단계를 타겟으로 하므로 이제 막 시작하는, 그리고 초보자들로 구성된 팀이 확실히 유리하다) 예정이다.

  • 동아리, 팀 이름(회사 소속이거나 일반 동호회거나 상관 없다)
  • 참여 인원 수
  • 클린 코드로 그룹 스터디를 시작한(할) 시점과 그룹 스터디 목표
  • 특별 이벤트를 신청한 이유와 바라는 바(구체적으로 기술하면 아주 좋다)
  • 그룹 스터디/세미나 장소

계속해서 '클린 코드'에 대한 많은 성원 부탁드리겠다.

EOB
작성자: 시간: 댓글 없음:
라벨:

목요일, 8월 14, 2014

[일상다반사] 2014년 FALinux 공개세미나 소식

오는 8월 20일 2014년 FALinux 공개세미나 소식이 있어, 혹시 자바와 IoT 관련해 관심이 있는 분들께 도움이 될까 글을 올려드리겠다. 기술 세미나 이외에 비즈니스 타임도 예정되어 있으므로 조금 색다른 만남의 장이 되지 않을까 예상한다. 참고로 블로그 주인장도 행사에 참석할 예정이며, 혹시 당일 세미나 또는 비즈니스 세션에 참석하실 애독자분이 계시면 댓글 부탁드리겠다. :)

EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 8월 12, 2014

[B급 관리자] 리더에게 가장 필요한 기술

하버드 비즈니스 리뷰 기사 중에 The Skills Leaders Need at Every Level라는 내용이 올라와서 재미있게 읽었다. 독자 여러분들께 여러 관리 위치에서 리더에게 가장 필요한 기술을 정리해드리겠다.

  1. 다른 사람들에게 영감을 주고 동기를 부여하는 능력(38%)
  2. 진실성과 정직을 보여주는 능력(37%)
  3. 문제 해결과 이슈 분석 능력(37%)
  4. 결과를 이끌어내는 능력(36%)
  5. 힘있고 왕성한 의사 소통 능력(35%)
  6. 협동과 팀워크 배양 능력(33%)
  7. 관계 형성 능력(30%)
  8. 기술적이고 전문적인 지식(27%)
  9. 전략적인 균형 감각(24%)
  10. 타인 계발(21%)
  11. 혁신 능력(16%)
  12. 변화 능력(16%)
  13. 그룹을 외부 세상과 연결하는 능력(12%)
  14. 도전적 목표 수립 능력(10%)
  15. 자기 계발 능력(9%)

사람들이 조직 상위로 올라갈수록 필요한 근본적인 기술은 급격하게 변하지 않는다. 물론 상대적인 기술의 중요도는 바뀌기 마련이라서, 중간 관리자는 문제 해결 능력이 아주 중요하다. 위로 올라가면 힘있고 왕성한 의사 소통 능력이 중요해진다.

스스로에게 현 상황에서 어떤 역량이 가장 중요한지 물어보는 이외에도 향후에 어떤 역량이 중요해지는지 물어보기 바란다. 앞으로 나갈 방향은 언제나 자기가 정하니까.

EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 8월 09, 2014

[B급 프로그래머] 기능으로 변한 버그

Software Engineering: What are the best examples of software bugs that became features (a.k.a. misbugs)?(소프트웨어 공학: 기능이 되어버린 소프트웨어 버그(소위 misbug)의 좋은 예제가 무엇일까요?)라는 재미있는 질문이 Quora에 올라와서 독자 여러분을 위해 몇 가지 재미있는 내용을 정리해드리겠다.

  1. 윙커맨드 종료 문구: 게임 중에 윙커맨드를 기억하고 계신 분이 있다면, 게임 끝날 때마다 "Thank you for playing Wing Commander!"라는 문구가 생각할지도 모르겠다. 이 문구가 출력되는 이유는 게임이 종료될 때 EMM386(!) 메모리 관리자에서 "EMM386 Memory manager error. 어쩌구 저쩌구"라는 예외가 출력되었기에 급히 출시하기 위해 메모리 관리자를 16진 편집기로 열어 오류 메시지를 수정한 결과라 한다. :)
  2. Gmail 취소 기능: 아는 사람들은 다 알고 있겠지만 Gmail에서 이메일 메시지를 처리할 때 대략 5초 정도 지연이 있다. Gmail 개발자들은 취소 옵션을 구현하는 방식으로 이 문제를 기능으로 바꿨다. 이왕 지연이 있는 김에 Gmail은 사용자에게 어떻게든 전송 전에 취소할 수 있는 버튼을 추가했다. 물론 사용자들은 이 기능을 무척 즐기고 있다.
  3. UNIX의 숨김 파일(.): 롭 파이크에 따르면 유닉스 파일 시스템에서 숨김 파일 기능은 버그였다고 한다. 오래 전 유닉스 파일 시스템이 개발될 당시에 .과 .. 항목이 등장해 탐색을 쉽게 만들었다. 하지만 ls 명령을 내릴 때, .과 ..이 나타나서, 켄과 데니스는 프로그램에 간단한 테스트를 추가했다(if (name[0] =='.') continue;와 등가인 어셈블 코드). 하지만 원칙적으로는 이름을 구성하는 모든 철자를 검사해야 마땅했다(if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;). 결국 이런 구현 때문에 점으로 시작되는 파일을 세지 못했고, 게으른 개발자(?)들은 이를 기능으로 여겨 홈 디렉터리에 안 보이는 파일이 늘어나기 시작했다. 참고로 Plan 9에는 숨김 파일이 없다.

혹시 독자 여러분들께서도 버그를 기능으로 사용하는 경우가 없는지?

EOB
작성자: 시간: 댓글 2개:
라벨:

화요일, 8월 05, 2014

[B급 프로그래머] 8월 1주 소식

8월 1주 소식을 전해드리겠다.

  1. 웹/앱 소식
  2. 개발/관리도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 8월 02, 2014

[B급 프로그래머] 이 세상에서 가장 큰 압축 파일은?

직전에 소개한 폴리글랏 프로그래밍의 '폴리글랏'을 소개하기 위해 위키피디아를 참조하다 The Polyglot List이라는 페이지를 방문하게 되었다. 여기서 퀸(Quine, /kwi:n/)이라는 단어가 나와서 GEB가 생각나고 말았다. 퀸은 출력 결과로 자신의 소스 코드와 완벽하게 동일한 텍스트를 만들어내는 프로그램이다. 잠시 예제를 볼까?

char*f="char*f=%c%s%c;main(){printf(f,34,f,34,10);}%c";main(){printf(f,34,f,34,10);}

이런 예제도 흥미롭지만, Quora를 읽다 더욱 흥미로운 질문을 발견했다. 바로 이 세상에서 가장 큰 압축 파일은 무엇일까?

정답은 42.zip이라는 ZIP 폭탄인데, 압축되면 42.374 bytes에 불과한 파일이 압축을 푸는 순간 4.503.599.626.321.920 bytes (4,5 petabytes)로 변신한다. 혹시라도 호승심에서 이 파일을 구해 압축을 푸는 순간 여러분 컴퓨터의 하드디스크가 꽉 차버린다는 사실에 주의하자. 42.zip 파일은 16개 압축된 파일로 구성되어 있으며, 각각은 다시 16개 압축된 파일로 구성되어 있으며, 다시 한번 각각은 16개 압축된 파일로 구성되어 있으며, 또 다시 한번 각각은 16개 압축된 파일로 구성되어 있으며, 또또 다시 한번 각각은 16개 압축된 파일로 구성되어 있으며, 최종적으로 4.3기가 바이트짜리 파일 하나를 포함한다. 헉헉 설명 한번 힘들다.

한 술 더 떠 Droste라는 파일은 무한히 자신을 증식하는 특성이 있다. 어떻게 이런 일이 가능할까? 바쁜 독자 여러분을 위해 미리 답을 드리자면, 퀸을 사용해 허프만 코딩에 따라오는 LZ77 명령을 복제하는 방법을 사용한다. Zip Files All The Way Down라는 글에 나온 LZ77 퀸 코드를 살펴보자.

눈치빠른 독자분들께서는 이미 짐작했을테지만, No-op을 사용해 일단 자기 자신을 그대로 복제하는 코드 작성에 성공했으므로, 여기서 앞뒤로 접두어와 접미어를 붙이는 방법만 찾아내면 경기는 끝난다. 무한히 자신의 코드를 실행하며 계속 크기를 늘일 수 있기 때문이다.

뱀다리: 이런 유형의 해킹은 재미도 있지만 함수형 언어(응?)에 대한 관심을 유도하기도 한다. Scheme을 사용해 퀸을 만들면 어떻게 될까?

((lambda (x) `(,x ',x))
'(lambda (x) `(,x ',x)))

아무리 봐도 정말 멋지다!

EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 7월 29, 2014

[독서광] 폴리글랏 프로그래밍

오늘은 한빛미디어에서 선물로 보내주신 '폴리글랏 프로그래밍'을 읽은 감상문을 올려드리겠다.

책 이해를 위해 먼저 '폴리글랏'이라는 용어부터 살펴볼 필요가 있다. wiktionary의 설명을 빌어 조금 유식하게 표현하자면 고대 그리스어인 πολύγλωττος (polúglōttos, “many-tongued, polyglot”), from πολύς (polús, “many”) + γλῶττα (glôtta, “tongue, language”)가 기원이라고 하며, 쉽게 말해 '여러 언어'를 의미한다. 사전상 정확한 발음이 [|pɑ:liglɑ:t]이라는 점이 함정이긴 하지만, 국내에서는 poly를 '폴리'라 발음하니 못 알아들을 문제는 없다. 컴퓨터 공학에서는 특정 애플리케이션을 작성할 때 여러 언어를 혼합해 사용하는 방식을 총칭하는데, 솔직히 말해 여러분들도 이미 부지불식간에 잘 활용하고 있다. 자바에서 스프링을 사용해 웹 애플리케이션 프로그램을 만들 경우 HTML, CSS, 자바스크립트, 자바, XML, SQL이라는 여섯 가지 언어를 섞어서 사용하므로 폴리글랏 프로그래밍이 낯설리 없다. 옛날에도 셸 스크립트 언어와 C 프로그래밍 언어를 섞어 애플리케이션을 만들었으니 폴리글랏 프로그래밍의 계보를 따지자면 한참을 거슬러 올라가야 한다.

하지만, 적극적인 의미에서 폴리글랏 프로그램이 가능해진 시점은 JVM이나 .Net CLR이 나오면서부터다. 과거에는 목적 파일 수준에서 링크 과정을 거쳐 서로 다른 정적인 프로그래밍 언어로 만들어진 코드를 혼합해서 사용했지만(따라서 ABI와 같은 규약을 맞추기 위해 다양한 트릭을 사용했다. Win32 프로그래머라면 C와 파스칼 호출 방식의 차이점을 아주 잘 알고 있다!), 요즘에는 부담없이 언어끼리 섞어 사용할 수 있다(C#과 VB .Net, Java와 Scala를 섞어 프로그램하는 상황을 생각해보라!). 또한 폴리글랏 프로그래밍 패러다임을 사용할 경우 동일한 런타임을 공유하는 특정 언어에서 다른 언어로 필요에 따라 속도를 조절해가며 천천히 이주가 가능하다는 장점도 생긴다. 아, 각설이 길었는데, 원래 책 내용을 간단하게 설명해야겠다.

이 책은 자바, C#, 스칼라라는 개발자들 사이에서 많이 사용하고 요즘 뜨는 프로그래밍 언어의 특징(특히 닮은 점과 다른 점)을 설명하는 책이다. 물론 본문에 코볼(!)과 같은 옛날 언어와 루비, 파이썬, 그루비와 같은 동적 (스크립트) 언어도 조연으로 등장하므로 다양한 프로그래밍 언어에 대한 차이점을 느낄 수 있다. 이 책에서 강조하는 지점은 바로 부지불식간에 요즘 거의 모든 프로그래밍 언어에 기본으로 탑재되고 있는 '함수형' 언어의 특징이다. 자바의 익명 메소드, 클로저와 람다, C# 사용자라면 감탄을 금하지 못하는 링큐(LINQ), 스칼라의 트레이드와 같은 고품격 특질이 나오게 된 배경과 의의에 대한 설명이 나온다. 개별 특성을 놓고 사람과 기술이 얽힌 이야기 식으로 내용이 전개되므로 구체적인 프로그래밍 기법을 기대한 독자라면 조금 당황할지도 모르겠다는 생각도 든다.

이 책은 자바 8이 나오기 조금 전에 초판이 출간되었기 때문에 Java 8의 람다 표현식과 메소드 참조 그리고 람다 표현식과 스트림을 활용하는 새롭고 개선된 API와 같은 내용은 자세히 언급하지 않는다. 물론 오라클이 썬을 인수한 다음부터 자바 개발이 보수적으로 움직이고 있기 때문에 함수형 언어 특질에 대한 추가가 너무 늦은데다 Is Java 8 a Functional Programming Language?라는 글에서도 밝히듯이 여전히 본격적인 함수형 언어로 사용하기에는 미묘하게 부족한 점이 많으므로 이 책이 지금 이 무렵에 나왔더라도 자바에 대한 호의적인(응?) 평가를 얻기는 어려웠으리라는 생각을 해본다.

결론: 요즘 돌아가는 프로그래밍 언어 생태계에 관심이 많고 함수형 언어의 철학에 대해 어느 정도 이해하고 있는 프로그래머가 보면 재미를 느낄 것이다. 구조적/객체지향적인 언어 세상에 익숙한 개발자들이라면 저자 서문에 나오는 '가볍고 경쾌한 내용일 거라고 믿는다'라는 표현을 믿다가는 본문 중 전개되는 내용을 읽으며 난감한 느낌(힌트: 자바를 디스한다)이 들지도 모르겠다.

EOB
작성자: 시간: 댓글 2개:
라벨:

토요일, 7월 26, 2014

[독서광] 역사 속의 소프트웨어 오류

오늘도 출판사에서 선물받은 책을 한 권 소개해드리려 한다. 전 세계적으로 문제가 되었던 소프트웨어 오류를 소개하는 '역사 속의 소프트웨어 오류'가 바로 주인공이다. 책이 출간되기 전에 이미 일부 내용을 읽고 간단한 서평을 작성했는데, 여거 다시 한번 옮겨 본다.

지금까지 나온 소프트웨어 에세이는 주로 밝은 면에 집중한다. 잘 되고 좋고 멋지고 훌륭한 소프트웨어에 대한 환상 말이다. 하지만 이 책은 실수, 실패, 그리고 그 뒤에 숨겨진 뒷 이야기를 집중적으로 다룬다. 소프트웨어 오류와 원인(일단 알고 나면 별거 아닌 듯이 보이는!)을 재미있고 이해하기 쉽게 풀어 쓰므로, 소프트웨어를 제대로 그리고 안전하게 구현하고 싶은 개발자에게 추천한다.

과연 어떤 이야기를 다루고 있을까? 패트리어트 미사일, 화성 탐사선, AT&T 장거리 전화 불통, 미국 북동부를 휩쓸었던 대정전, 함정 운용/전투 소프트웨어, 모리스 웜, 전투기 항전 소프트웨어, 게임 버그, 의료 기기 소프트웨어, 금융 소프트웨어, 상용 여객기 운항 소프트웨어, 도요타 UA(급발진)를 초래한 소프트웨어 등 다양한 분야에서 발생해 인명과 금전적인 손실(그 중 일부는 해프닝으로 끝난 경우도 있지만...)을 일으킨 소프트웨어 오류를 설명하고 있다. 소프트웨어에 필연적으로 따라다니는 버그가 연쇄 효과를 일으키며 파국으로 치닫게 만드는 이야기를 읽고 있으면 마치 한 편의 드라마를 보는 듯한 느낌을 받을지도 모르겠다.

개인적으로도 소프트웨어 오류에 관심이 많아 다양한 자료를 수집하고 분석해보는 취미가 있어서 책에서 소개하는 상당수 사례를 이미 알고 있었지만 잘 정리된 형태로 다시 한 번 읽으니 색다른 느낌이 들었다. 무미건조한 사고 분석 결과 보고서 형태가 아니라(항공기 관련 보고서를 읽으면 어떻게 이렇게 객관적으로 글을 쓸 수 있는지 궁금한 때가 많다) 사건의 역사와 배경, 추이, 결과를 이야기식으로 풀어가고 있기 때문에(그리고 중간 중간 소프트웨어 개발자를 위한 내용도 나온다) 해당 분야의 전문가가 아니더라도 어렵지 않게 읽을 수 있다.

하지만 저자가 직접 관련자들이나 전문가를 인터뷰한 내용이 아니라 이차 소스를 중심으로 정리한 내용이다 보니 아무래도 한계가 있기 마련이다. 이차 소스에 따라 각 사례에 대한 분석 깊이가 많이 차이 나므로 특정 사고의 원인을 기술적으로 깊숙히 파고들어 분석할 목적으로 이 책을 선택했다가는 낭패를 볼지도 모른다는 점을 짚고 넘어가야겠다. 그렇다고 하더라도, 전반적인 개요를 파악하기 위한 출발점으로는 나쁘지 않다.

결론: 올바른 소프트웨어 제작과 관련해 개발자들의 마음가짐을 다잡아 주는 동기부여 목적으로 이 책을 읽어보면 어떨까 생각한다. 평상시 소프트웨어 오류에 대해 관심이 많은 분들께 추천!

EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 7월 22, 2014

[독서광] Free2Play 게임 산업을 뒤바꾼 비즈니스 모델

오늘은 에이콘 출판사에서 랜덤으로 보내주신 선물인 공짜 게임 비즈니스 모델에 대한 책을 하나 소개해드리겠다.

과거와는 달리 무료로 즐길 수 있는 모바일 또는 소셜 게임이 엄청나게 많이 만들어지고 있다. 장르와 대상 고객층은 제각각이지만, 이들 게임에는 한가지 공통점이 있다. 바로 돈 걱정 말고 일단 해보시라는 유인이다. 게임을 하다가 재미를 느끼고, 더 큰 재미를 느끼기 위해 돈을 투입하는 자연스런 연결고리가 무척 중요하다. 지인이 예전에 양 키우는 국내 게임에 대해 이야기를 해줬었는데, 무료로 시작할 수 있는 게임임에도 불구하고 큰 손은 한 달에도 수십 만원을 아낌없이 투자한다는 일화를 듣고서 이게 무슨 신세계인지 갸우뚱한 적도 있었다. 이 책은 게임을 즐기는 사람뿐만이 아니라 게임을 만드는 사람에게 무료로 즐기는 게임의 이면에 숨은 비즈니스 모델을 설명한다.

책을 펼치면 F2P 모델이 비즈니스와 관련해 어떻게 동작하는지부터 설명이 나온다. 물리적인 패키지 게임과 차이점을 설명하면서 디지털 상품의 독특한 성격을 비즈니스와 부드럽게 연결하기 때문에 F2P 게임으로 돈을 버는 방식을 머리에 정리할 수 있다. 그 다음으로 사람의 심리를 이용해 지속적으로 게임에 몰두하기 위한 핵심 루프에 대한 설명을 시작으로 사용자가 언제 멈추고 언제 돌아오고 어떻게 사용자에게 동기 부여하는지를 소개한다. 그리고 나서 사용자의 지갑을 열기 위한 온갖 방법(인앱 결제를 시작으로 배너 광고, 중간 광고, 동영상 광고, 오퍼월, 제휴 링크 등등)을 설명한다. 그리고 요즘 게임 업계의 화두인 분석과 데이터 수집, 해석에 대한 이야기를 전개한다. 그리고 나서 사용자를 끌어들이기 위한 마케팅 기법으로 마무리한다.

단순한 이론과 숫자가 담긴 표가 아닌 실제 사례를 풍부하게 활용하기 때문에 현장감이 느껴졌다. 기존에 몇몇 F2P 게임을 하면서 궁금했던 점을 대다수 해소할 수 있었다는 점이 나름 성과(?)가 아닐까 싶다. 아마존 원서 서평과 판매량도 나쁘지 않게 나오는 것을 보면 F2P 게임에 대한 관심을 상당 부분 충족하기 때문이라는 생각이다. 아마존 리뷰어 중 한 명이 적은 다음 내용에 공감한다.

It's written very clearly and explains the terms that are commonly used in the industry. 이 책은 아주 명쾌하게 쓰여졌고, 업계에서 일반적으로 사용하는 용어를 설명한다.

결론: 무료 게임에 대한 비즈니스 모델이 궁금한 분이라면 기획/개발/마케팅에 무관하게 적극 추천해드린다. 이론적으로 튼튼한 설명과 함께 여러 가지 재미있는 사례를 접할 수 있을 것이다.

EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 7월 19, 2014

[B급 프로그래머] 7월 3주 소식

7월 3주 소식을 정리해드리겠다.

  1. 웹/앱 소식
  2. 개발/관리도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 7월 15, 2014

[독서광] 글로벌 소프트웨어를 말하다 (지혜)

한빛미디어에서 선물로 주셨기에 이 책을 열심히 읽었으나... 읽다가 다소 난감한 느낌이 든 책이라고 솔직히 말해야겠다. 바쁜 독자를 위해 아주 간단하게 이 책을 요약하자면, "착한 개발자들은 SRS(Software Requirement Specification)를 열심히 쓰고 소스 코드 관리(특히 merge)를 잘하고 이슈 추적 시스템을 꼼꼼하게 활용한다"로 정리할 수 있겠다. 하지만 책에 how가 없다는 점이 함정.

책에서 충격 요법을 위해 국내 개발자들을 디스하고(166페이지: "대부분의 국내 개발자들은 코딩 습관상 오픈소스 커뮤니티에서 불량배로 취급받을 확률이 크니 오픈소스에 참여하더라도 주의해야 한다.") 실리콘벨리를 추켜세우는 내용까지는 손발이 오그라들어도 그려려니 하지만(본문에서 강조하는 국내 소프트웨어 시장이 진흙탕인 사실은 충분히 이해하고 인정한다!), 코딩 작업을 아르바이트생에게 시킬 수 있다는 표현(146페이지: "모든 method를 정의하고 나면 이제는 아르바이트생에게 코딩을 맡겨도 된다. 귀중한 시간을 쉬운 코딩에 소비할 수 없다.")은 정말 아니라는 생각이다. 세상에 코딩이 쉽다니! SRS와 비교해 상대적으로 코딩이 중요하지 않다고 말하려 했을지는 몰라도 이미 물은 엎질러졌고...

이쯤에서 코딩 호러 블로그의 Dysfunctional Specifications에 나오는 리누스 토발즈 큰 형님의 명세 관련 이야기를 잠시 들어보는 편이 균형 감각 배양에 도움이 될 것 같다. 애독자 여러분을 위해 잽싸게 번역해보았다.

"명세"(spec)는 무용지물에 가깝다. 유용하면서도 정확한 명세를 본 적이 없다. 하지만 명세에 기반해 완전히 헛발질한 작업은 많이 목격했다. 명세는 소프트웨어를 작성하는 최악의 방법이다. 정의만으로 현실이 아니라 이론과 일치하기 위해 소프트웨어를 작성했음을 의미하기 때문이다. 명세를 피해야 하는 두 가지 이유는 다음과 같다:

1. 명세는 위험할 정도로 잘못되었다. 현실은 다르다. 그리고 명세가 현실을 심사숙고한다고 생각하는 사람은 누구나 커널 프로그램에서 _지금 당장_ 손을 때야 마땅하다. 현실과 명세가 충돌할 때, 명세는 아무 의미도 없다. 0. 전무. 전혀 없음. 뭐라고 할까? 과학과 비슷하다. 실험과 일치하지 않는 이론이 있다면, 당신이 해당 이론을 얼마나 좋아하는지는 중요하지 않다. 이론이 잘못되었을 뿐이다. 명세를 근사치로 사용할 수는 있지만, 어디까지나 근사치라는 사실을 _명심_해야 한다.

2. 명세는 필연적으로 글로 쓴 명세에 의미가 있는 추상화 수준과 단어 선택과 문서 정책을 수반한다. 명세에서 실제 코드를 구현하려 시도하면, 코드가 형편없는 듯이 보인다. 이런 현상의 고전적인 예는 OSI 네트워크 모델 프로토콜이다. 실제 세상과 완전히 무관한 전통적인 명세 설계말이다. 여전히 사람들은 7 계층 모델에 대해 이야기하고 있지만 대화에 편리한 모델이라서 그렇지 실제 소프트웨어 공학과는 아무 관련이 없다. 다시 말해, 명세는 사물에 대해 이야기하는 방법이지 사물을 구현하는 방법은 아니다. 그리고 이런 사실이 중요하다. 명세는 사물에 대해 이야기하는 기반이다. 하지만 소프트웨어 구현을 위한 기반은 아니다.

따라서 남들이 명세에 대해 뭐라 하든 신경쓰지 마라. 명세 때문이 아니라 명세에도 불구하고 진짜 표준은 성장하기 마련이니까.

오늘의 희한한 결론: 위대한 SRS도 작성하지 않고 만들어진 리눅스는 글로벌 소프트웨어가 아닌 모양이다.

뱀다리: 선물 받은 책임에도 불구하고 호의적인 서평을 쓰지 않은 이유는 간단하다. 열심히 일하는 개발자들을 오도할 가능성이 높은 내용이 여기저기 들어있기 때문이다. [B급 프로그래머] "‘한국의 저커버그’가 양성되기 위한 조건"에 대한 불만에서 알맹이 있는 책을 출간해 달라고 요청했지만 돌아오는 대답(아시는 분은 아시겠지만 ‘한국의 저커버그’ 글과 '글로벌 소프트웨어를 말하다' 책을 쓴 분들은 같은 컨설팅 회사 소속...)이 이 정도라면 실망이다.

EOB
작성자: 시간: 댓글 8개:
라벨:

토요일, 7월 12, 2014

[독서광] 언씽킹

이미 행동 경제학(또는 심리학)에 대한 책을 여러 권 블로그에 소개했으므로 오늘도 또(응?) 행동 심리학과 관련된 책을 소개하려니 조금 망설여지긴 했지만, 그래도 독자 여러분을 위해 간략하게 독후감을 작성하고 넘어가기로 마음먹었다. 오늘 소개할 책은 "언씽킹(unthinking)"이라는 책이다. 들어가기 전에 잠시 주의 사항 하나 언급하고 넘어가야겠다. 이 책은 정말 미국적이라 미국 문화와 역사와 언어에 익숙하지 않은 사람들이 읽을 경우 거리감이나 당혹감을 느낄 가능성이 아주 높다. 따라서, 읽기가 쉽지 않다는 점을 미리 언급해둔다.

자, 그렇다면 이 책은 무엇을 설명하고 있을까? 머리말에 가장 먼저 나오는 다음 문구가 이 책의 전반적인 내용을 설명해주는 핵심 포인트라 보면 틀림없다.

우리는 언제나 생각 없이 결정한다.

아마 말도 안 된다고 생각하시는 분이 많으시리라. 결정 하나 내리기 위해 이리 재고 저리 재고 밤에 잠도 못자고 고민하고... 누구나 중요한 결정을 위해 심사숙고하지 않는가? 하지만 이 책은 그렇지 않다고 주장한다. 책 제목부터 생각하는(thinking)에 un을 붙인 생각이 없는(unthinking)이니 손발 다 들 지경이다. 머리가 어질어질하다고? 그렇다면 이 책 목차를 보자.

  1. 우리는 하루 종일 놀고 있다
  2. 우리는 놀라움을 갈망한다
  3. 우리는 진짜 이야기를 원한다
  4. 우리는 루저를 사랑한다
  5. 우리는 눈에 띄고 싶어한다
  6. 우리는 특별한 것의 일부가 되고 싶어 한다
  7. 우리는 익숙한 것을 좋아하고, 식상한 것은 싫어한다
  8. 우리는 내일의 태양을 믿는다
  9. 우리는 눈으로 생각한다
  10. 우리는 단순한 것에 사로잡힌다
  11. 우리는 디자인 때문에 바뀐다

목차를 보면 이 책의 흐름에 대해 대충 감을 잡을 수 있을지도 모르겠다. 독자 여러분을 위해 간략하게 정리해보면, 이 책은 스타트랙의 스폭 일등 항해사가 아니라 커크 선장에 대한 이야기를 담고 있다. 이성이 아닌 감정과 직관이 앞서는 사람말이다. 문장 구성이 아니라 문장을 구성하는 단어의 운율을, 논리정연한 설교가 아니라 어릴 때부터 갈구해온 스토리를, 골리앗이 아니라 다윗을, 자기 자신에 대한 이야기가 아니라 우리에 대한 이야기를, 키가 크고 잘 생긴 사람이 아니라 우리를 닮아 키도 작고 평범하게 생긴 사람을, 익숙하면서도 식상하지 않을 정도로 새로운 것을, 염세주의 보다는 낙천주의를, 추한 것 보다는 아름다운 것을, 복잡한 것보다는 부드럽고 둥글고 단순한 것을 원하는 일반적인 사람들에 대한 이야기를 중심으로 우리가 행동에 앞서 머리 속에서 벌어지는 동작 원리(응?)를 설명하려 무지 애쓴 흔적이 보인다.

하지만, 행동 심리학을 사용해 제기한 문제의 해법이 '마케팅'으로 귀결되기에 이 책의 한계는 명확하다. 효과적인 마케팅을 위해 사람의 행동과 심리에 대한 고찰이 필요하긴 하지만, 연결을 위한 연결을 만들어내려다 보니 아무래도 책이 던지는 메시지가 명확하지 않고 산만하게 흩어져버린다는 생각이 든다.

결론: 중간 중간 재미있는 사례와 아이디어가 나오긴 하지만, 밑줄 그어가며 읽기에는 부족함이 많으므로 기존에 이 블로그에서 소개한 다른 책(독서광 태그를 선택한 다음 쏟아지는(?) 경영/경제 관련 서평을 보기 바란다)을 읽는 편을 권장한다.

EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 7월 08, 2014

[일상다반사] 피플웨어 번역서 출간 소식

프로젝트가 서쪽으로 간 까닭은에 이어 다시 한번 톰 드마르코의 고전인 '피플웨어' 번역서 출간 소식을 전한다. 원래는 역자 서문을 여기 적어서 조금이라도 손가락을 편하게 하려 했으나... 출판사에서 IT 프로젝트 관리와 팀워크 구축에 관한 통찰, 『피플웨어』라는 글에 먼저 올려주시는 바람에 지면으로 하지 못했던 뒷 이야기를 하나 풀어놓으려고 한다.

아마도 2판을 이미 읽어보신 분들도 많으실테다. 그럼에도 불구하고 굳이 3판을 다시 번역해야 했던 이유는 무엇일까? 가장 큰 이유는 3판에 추가된 몇 가지 장과 배치 변경 때문이다. 또한 용어나 사례도 현대적으로 바뀌었고, 예전 호랑이 담배피던 시절의 일화는 삭제되었다(21세기 독자들을 위한 배려라고 보면 틀림 없겠다). 그 다음 이유는 번역 품질 때문이다. 2판 번역서(위)과 3판 번역서(아래)의 1부 5장을 나란히 놓고 비교를 해볼까?(독자 여러분들께서도 재미삼아 2판 번역서와 3판 번역서를 비교해보기 바란다. 깜짝 놀랄만한 부분이 많다!)

2판: 경영 수업을 받은 적이 있는 관리자들을 만나 봤다면 당신은 그들 모두가 파킨슨 법칙과 그 법칙의 세부 이론을 집중적으로 가르치는 학교에서 교육받았을 것이라는 생각을 하게 될 것이다.
3판: 관리자들이 관리 교육이라고는 거의 받지 않는다는 사실을 몰랐더라면 모든 관리자가 파킨슨의 법칙과 그 의미를 집중적으로 공부하는 학교에 다녔다고 생각할지도 모르겠다.
2판: 심지어 그가 누군가에게 기대어야 하는 상황이 벌어지는 경우에도, 관리자는 끝까지 그의 버팀목이 되어야 한다. 물론 이런 문제는 팀 자체에서 해결하는 편이 훨씬 효과적이다. 그런데, 우리는 잘 조직된 팀의 관리자가 보조를 잘 맞추지 못하는 한 사람에게 팀 전체와 합세하여 비난하는 경우를 종종 볼 수 있다.
3판: 극히 드물게 심리적 압박이 유일한 방책인 경우도 있지만, 그럴 때라도 관리자는 심리적 압박을 가하는 최후의 일인이어야 한다. 동료 팀원들에게서 가해지는 압박이 훨씬 더 효과적이다. 잘 짜인 팀에서는 관리자가 나서기도 전에 다른 팀원들이 게으른 팀원을 먼저 혼내준다.
2판: 적절한 시기에, 명백히 옳은 결정이라는 확신을 내린 후에 벌을 주는 것은 아이에게 도움이 된다.
3판: 평소 체벌이 거의 없는 환경에 타이밍이 완벽해 아이가 쉽게 납득한다면 체벌은 효과가 있다.

2판은 문단 분리가 원서랑 다르게 되어 있었고(문단을 원서와 달리 임의로 합치고 분리해버리니까 사고의 흐름이 깨져버린다), IT 업계 표준 용어가 아닌 다른 용어를 사용했고, 일부 내용이 거꾸로(멀리 갈 필요 없다. 위 예제를 보시라) 번역되어 있었기에 아마 읽으면서 조금 이상하다는 생각이 들었을지도 모르겠다. 이제 3판을 다시 읽어보시면 기존에 뭔가 찜찜했던 기분이 사라지는 것을 느끼게 될테다.

결론: 아무쪼록 '사람 먼저'를 강조하는 '피플웨어'를 읽으며 다시 한번 '사람'의 중요성을 생각하면 좋겠다.

뱀다리: 지난번 해커스 이벤트 때 약속드린 '피플웨어' 선물도 출간되면 응모하신 분들께 바로 발송해드릴 예정이다.

EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 7월 05, 2014

[B급 프로그래머] 7월 1주 소식

2014년도 절반이 지났다. 아무쪼록 남은 절반도 보람차게 보내면 좋겠다.

  1. 웹/앱 소식
  2. 개발/관리도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리

3주에 더 흥미롭고 도움이되는 소식을 들고 찾아뵐 예정이다.

EOB
작성자: 시간: 댓글 2개:
라벨:

금요일, 7월 04, 2014

[독서광] Git을 이용한 버전 관리

이미 지난번에 강력한 Git 관련 서적인 프로 Git : 그림으로 이해하는 Git의 작동 원리와 사용법을 설명드린 바 있음에도 불구하고 오늘 또 다시 git 책을 소개하려 마음먹었다. 오늘 소개할 책은 svn과 같은 전통적인 소스 코드 관리 시스템을 한번도 접해보지 않은 상태에서 git을 사용해 간단한 소스 코드 관리가 필요한 분들에게 딱 맞는 책인 "Git을 이용한 버전 관리"다. 에이콘 출판사에 놀러갔다가 아주 얇은(본문이 200페이지 정도다) git 서적이 눈에 띄여 선물로 받은 다음에 2시간에 걸쳐 다 읽고 느낀 소감을 간단히 정리한다.

git이 쉽다고(응?) 이야기하는 분들도 계시지만, 초보자가 처음 접근하려면 진입 장벽이 상당히 높다. 거북이SVN과 같은 GUI의 존재유무가 문제가 아니다. 윈도우/맥에서 훌륭한 인터페이스를 제공하는 소스트리는 완성도가 상당히 높다. 하지만 이런 GUI도 손쉬운 git 활용을 보증하지 않는다. git만의 독특한 철학이 있기 때문이다. 그렇다면 저장소를 만들고 체크인/체크아웃하고 간단히 병합/분기하고 충돌처리를 해결하고 중앙 집중식 저장소에 밀어넣고/당기는 작업 정도만 할 수 있으려면 어떻게 해야 할까? 복잡한 git 내부 구조를 모두 파악해야 하나? 오늘 소개할 'Git을 이용한 버전 관리'는 가장 기본적인 Git 활용법에 충실한 책이다.

목차를 펼쳐보면 이 책의 추구하는 바가 확실히 드러난다. 1장은 버전 관리 시스템을 소개하며, 2장은 깃 설치 방법을 윈도우/맥/리눅스로 나눠 설명하며, 3장은 git 초기화(그리고 .gitignore 파일 설정)와 파일 추가/커밋/체크아웃을 설명하고, 4장은 분산 작업을 위한 인터넷/인트라넷/노출된 저장소 공유 방법을 설명하고, 5장은 git 로그 보기와 태깅 방법을 설명하고, 6장은 병합과 충돌을 설명하고, 7장은 분기 방법을 설명한다. 이게 전부며 이 책의 엄청난 장점(초보자용)이다. 마지막 장인 8장에서 깃의 원리를 설명하려 애를 썼지만 (참으로 어중간하게 끝나버리는 바람에) 사실상 실패로 돌아갔기 때문에 앞서 소개한 프로 Git을 읽는 편이 정신 건강에 이롭다는 주의 사항을 언급한다.

이 책의 장점은 참으로 이해하기 쉬운 예제다. 실제 프로그래밍과 100만 광년 떨어진 정말 단순한 예제라 손발이 오그라들긴 하지만, 간단하게 이해하기에는 오히려 더 적합할지도 모르겠다. 하지만 단순한 예제를 응용하는 작업이 독자 몫이므로 남기 때문에 자신이 직접 간단한 실제 프로그램을 만들면서 연습을 해봐야 나중에 실전에서 눈물을 덜 흘릴 것이다.

결론: git을 처음 배우는 분들이 처음 접하기에 적합한 책이다. 이 책에서 소개한 기초 내용을 알면 기존 파일 저장소 관점에서 svn 수준으로 작업하기에 큰 어려움이 없을 것이다.

EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 7월 01, 2014

[독서광] 경제학자도 풀지 못한 조직의 비밀: 왜 우리에게 조직이 필요한가

간만에 경제/경영 블로그답게 오늘은 '경영' 관련 양서를 하나 추천하려 한다. 오늘의 주인공은 제목이 상당히 긴 "경제학자도 풀지 못한 조직의 비밀"이다. 부제인 "왜 우리에게 조직이 필요한가"가 이 책의 특성을 가장 잘 나타내는 문구가 아닌가 싶다. 에필로그에도 나오지만 솔직히 우리가 인생의 1/3을 보내는 곳이 조직인데, 사람들은 일단 '조직'이라는 단어가 나오면 알레르기 반응부터 보이며 '정치'와 더불어 없어져야 하는 양대 악의 축으로 보는 경향이 있다. 하지만 과연 그럴까?

이 책은 바로 말도 많고 탈도 많은 '조직'에 대해 여러 가지 각도에서 바라본다. 조직의 존재 가치를 기업인 입장에서 합리화하려는 시도였다면 아마 이렇게 서평을 쓰고 있지는 않을테다(1/3 정도 읽다가 조용히 책을 쓰레기통에 넣거나, 아니면 강력한 서평(?)을 써서 독자 여러분들의 피같은 돈을 절약하게 만들었을 것이다). 이 책은 조직이 만들어지는 이유로 시작해서, 이 과정에서 일어나는 여러 가지 현상과 문제점과 (긍정적이든 부정적이든) 부작용에 대해 다양한 사례와 이론을 전개한다. 이 책에서 가장 강력한 부분은 1장 "애덤 스미스가 풀지 못한 문제: 조직은 어떻게 만들어지는가"이며, 시장의 효율성을 넘어 조직이 위력을 발휘하는 이유에 대해 명쾌하게 설명하고 있다.

애덤 스미스가 '보이지 않는 손'을 이야기하며 시장의 효율성에 대해 강조한 이후부터 많은 경제학자들을 고민에 빠지게 만든 요인은 바로 '조직'이다. '보이지 않는 손'이 모든 것을 지배한다면 그야말로 온갖 역기능을 초래하는 조직이 존재할 이유가 없지 않겠는가? 하지만 조직은 없어질 기미를 보이지 않으며, 오히려 번성하고 있다(수 많은 회사들은 물론이고 심지어 비영리단체조차도 조직 형태로 운영된다!). 이 책에서는 로널드 코스가 주장한 '거래 비용(transactional cost)'을 중심으로 조직의 중요성에 대해 합리적인 설명을 시도한다. 독자 여러분을 위해 간략히 정리하겠다. 물건 구입 비용 이외에 우리가 치뤄야할 다른 비용(가장 저렴한 상점을 찾기 위해 투자한 비용, 이 상점에서 우리가 원하는 물건이 재고로 존재한다는 사실을 알기 위해 투자한 비용)은 '보이지 않는 손'이라는 시장 이론에서 숨어 있으며, 개인 대 개인의 거래를 넘어서 기업 대 기업으로 사업을 전개하려면 이런 거래 비용이 엄청나게 커지기 때문에 필연적으로 보이지 않는 세상에 마찰과 불화가 일어나기 마련이다. 즉, 회사는 되도록 복잡하고 위험하고 돈이 많이 드는 외부 거래를 줄이고 내부에서 처리하기를 원하며, 내부 거래 비용이 외부 거래 비용을 능가하는 지점에서 시장에 굴복한다는 내용으로 정리가 가능하다. 내부에서 모든 것을 다 처리하려 들 경우 지불해야 하는 비용은 사업의 확장에 따른 인력 충원과 이런 인력을 관리하기 위한 관리자 충원과 이런 관리자를 지원하기 위한 스태프 충원이라는 연쇄 반응에서 비롯된다. 반면 외부에서 모든 것을 다 처리하려 들 경우 신뢰할 수 있는 협력 업체를 찾고 이를 관리하기 위한 비용을 지불해야 한다. 결국 기업이 내부에서 처리하느냐 외부에서 처리하느냐를 결정하는 기준은 조직 비용과 거래 비용에 달려있다.

우와, 뭔가 머리에 번개가 번쩍하지 않는가? 심지어 개인과 개인의 거래에서조차도 거래 비용이 무척 중요한 경우가 생긴다. 난생 처음 간 곳(예: 영국)에서 점심을 먹어야 한다면, 거래 비용 관점에서 맥도널드가 최선의 선택이 아닐 수 없다(나머지 다른 음식점에 용감하게 뛰어들었다면 행운을 빈다). 맥도널드와 같은 프렌차이즈 음식점은 일관된 음식 맛과 서비스 형태를 유지함으로써 사용자에게 최상은 아니더라도 균일한 경험을 제공하기에 서비스 가격이 조금 비싸더라도 거래 비용을 낮춰주는 효과가 있다.

자, 그리고 나서 이 책은 열심히 조직의 여러 가지 특징을 이리저리 뒤집기 시작한다. 조직에서 평가, 정의, 실행이 왜 이렇게 엉망진창으로 형편없이 수행되는 듯이(실제로는 최선이라는 이야기다) 보이는지, 매출을 높이기 위해 조직 형태가 어떻게 바뀌는지, 혁신과 규율이 조직 내에서 얼마나 팽팽한 긴장감을 유지하는지(조직은 혁신만 강조해도 망하고 규율만 강조해도 망한다), 돈만 먹는 듯이 보이는 고루한 관리자가 회사를 살리는 이유가 무엇인지,CEO와 평사원은 도대체 하는 일에 어떤 차이점이 있는지, 탁월한 조직을 구축하는 과정에서 문화가 얼마나 중요한지를 다양한 사례를 들어 설명하고 있다.

이 책을 꼭 읽어야 할 독자는 '조직에 대해 불평 불만이 엄청나게 많고'(음, 아주 조금 찔리는 구석이 있다. T_T), '이상적인 비전과 열의로 가득찬' 사람이라는 생각이다. 이 책 에필로그에 나오는 좋은 문구를 정리하면서 마무리하겠다.

조직의 경계는 조직 내에서 물건을 만드는 비용과 그것을 거래해서 얻는 이득의 맞교환을 통해 정의된다.
모든 변화에는 비용과 혜택이 동반된다. 공상적 비전을 추구하는 사람들은 비용에는 눈을 감은 것 같다. 그러나 조직 생활은 그런 식으로 돌아가지 않는다.
주여, 우리에게 우리가 바꿀 수 없는 것을 평온하게 받아들이는 은혜와 바꿔야 할 것을 바꿀 수 있는 용기, 그리고 이 둘을 분별하는 지혜를 허락하소서.

결론: '조직'의 부정적인 측면에 사로잡힌 분들이라면 균형잡힌 시각을 확보하기 위해 이 책을 꼭 읽어보시라(물론 직접 조직을 한번 만들어보면 이 책에서 이야기하는 내용을 넘어서 훨씬 더 현실을 제대로 알게 되겠지만...).

EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 6월 28, 2014

[B급 프로그래머] 소프트웨어 개발을 위한 우수 관례

Best Practices Ever for Software Development라는 글이 트위터에 올라와서 독자 여러분을 위해 간단하게 번역해봤다.

  1. 컴퓨터가 아니라 사람을 위해 프로그램을 작성하라.
    • 독자들에게 한번에 머리에 들어오는 사실을 넘어 더 많은 것을 기억하게 요구해서는 안 된다.
    • 이름은 일관성이 있고, 독특하고, 의미가 있어야 한다.
    • 코딩 스타일은 일관성이 있어야 한다.
    • 소프트웨어 개발의 모든 측면은 대략 한 시간짜리 과업 여러 개로 나눠야 한다.
  2. 반복적인 작업을 자동화하라.
    • 반복적인 작업을 컴퓨터에 의존하라.
    • 재사용을 위해 파일에 최근 명령을 저장하라.
    • 과학적인 작업 흐름을 자동화하기 위해 빌드 도구를 사용하라.
  3. 컴퓨터를 사용해 이력을 기록하라.
    • 계산 작업을 자동으로 추적하기 위해 소프트웨어 도구를 사용하라.
  4. 점진적인 변경을 가하라.
    • 잦은 피드백과 중간 궤도 변경을 곁들여 작은 단계로 나눠 일을 진행하라.
  5. 버전 관리 시스템을 사용하라.
    • 버전 관리를 사용하라.
    • 버전 관리 시스템을 사용하라.
    • 수동으로 생성하는 것은 뭐든지 버전 관리 시스템에 넣어라.
  6. 반복하지 마라(DRY).
    • 모든 자료는 시스템에서 단일 책임을 표현해야 한다.
    • 코드를 복사해서 붙이는 대신 모듈화하라.
    • 코드를 재작성하는 대신 재사용하라.
  7. 실수에 대한 계획을 세워라.
    • 연산을 점검하기 위해 프로그램에 assert를 추가하라.
    • 시중에 나와 있는 단위 테스트 라이브러리를 사용하라.
    • 프로그램을 테스트할 때 가능한 모든 수단을 사용하라.
    • 버그를 테스트 케이스로 전환하라.
    • 심벌릭 디버거를 사용하라.
  8. 제대로 동작하고 난 다음에야 소프트웨어를 최적화하라.
    • 프로파일러를 사용해 병목을 파악하라.
    • 가능한 고차원 언어를 사용해 코드를 작성하라.
  9. 동작 방식이 아니라 설계와 목적을 문서화하라.
    • 구현이 아니라 인터페이스와 이유를 문서화하라.
    • 동작 방식을 설명하는 대신 코드를 리펙터링하라.
    • 소프트웨어 내부에 소프트웨어 일부로 문서를 내장하라.
  10. 공동으로 작업하라.
      합치기 전에 코드 검토를 수행하라.
    • 곤란한 특정 문제를 추적하거나 새로운 신입의 속력을 높이려 할 때는 짝 프로그래밍 기법을 사용하라.
  11. 낡은 코드를 유지보수하고 개선하라.

독자 여러분들께서 추천하는 관례는 무엇인가? 공유를 위해 댓글로 달아주시면 좋겠다.

EOB
작성자: 시간: 댓글 없음:
라벨:

금요일, 6월 27, 2014

[독서광] 이것이 C언어다

개인적으로 C 프로그래밍 언어를 강의해야 가르쳐야 하는 상황이라서 교재를 고민하고 있었다. 물론 독보적인 K&R표 교과서가 존재하긴 하지만 이 책으로 진도를 뽑을 경우 처음 배우는 사람들이 떡실신할 가능성이 아아주우 높기에 욕심을 꾹 참고 국내서를 검토하고 있었다. 그러다 지난 주에 한빛미디어 사무실에 방문했다가 아주 좋은 책을 한 권 선물 받았다. 오늘 소개할 책인 "이것이 C언어다"는 무려 3년에 걸쳐 만들어졌으며 목차를 보면 알겠지만 C에 처음 입문하는 장래 개발자를 위해 변수 선언부터 포인터/배열과 동적 메모리 사용에 이르기까지 균형을 잘 맞췄다는 생각이다. 표준 C에서 다뤄야 하는 내용은 빠짐없이 다 나오며, 부록에는 표준 라이브러리에 대한 간략한 소개까지 들어있다.

사람마다 추구하는 바가 다르므로 자기가 직접 집필하기 전에는 완벽한 C 책을 기대할 수는 없지만, C 언어를 배우는 과정에 필요한 요소가 빠짐없이 들어 있고 설명이 제대로 되어 있다면 그 자체로 충분한 가치를 발휘한다는 생각이다. 이 책의 특징 중 하나는 풍부한 그림이다. 코드와 설명만 계속 나오는 대신 메모리 레이아웃이 그림으로 표현되어 있으므로 C를 처음 접할 경우 가장 난해하게 다가오는 정적/동적 메모리 레이아웃이 실행 과정에서 어떻게 바뀌는지 한 눈에 들어온다.

본문에서 실습을 위해 완전히 컴파일 가능한 예제는 물론이고 각 절마다 연습 문제가 나오므로 실력을 점검할 수 있다. 출판사 공식 페이지에 들어가보면 예제 소스도 제공하므로 타이핑이 귀찮은 분이라면 내려받아 사용하면 된다. 물론 처음 배우는 입장에서는 타이핑 연습도 할 겸 C와 친해지기 위해 직접 입력하는 방식을 권장한다. 제공되는 소스 코드와 관련해 주의할 사항이 하나 있는데, 소스 코드가 UTF-8이 아니라 윈도우 인코딩 방식을 따르므로 맥/리눅스에서 한글이 제대로 안 보이고 개행문자가 DOS 방식을 따르므로 vi 등이 불평을 늘어놓을 것이다. 또한 운영체제와 아키텍처 특성으로 인해 일부 예제에서 경고 메시지와 실행 결과가 다를 수 있으므로 '이것이 C언어'(응?)라는 사실에 다시 한번 주목하면 좋겠다.

결론: C언어를 처음 배우는 분들이 처음 접하기에 적합한 책이다. 참고로 동영상 강좌 쿠폰(12개월)도 들어 있으므로 독서와 병행해 유용하게 활용하기 바란다.

간이 설문: C언어 입문자를 대상으로 공부 방향에 대한 지침을 주제로 세미나를 하면 참석할 의향이 있는지? 설명할 내용은 C 컴파일러 개괄 + gcc/gdb 기초 중의 기초 설명 + make 기초 중의 기초 설명 + C에서 가장 어려운 배열/포인터/메모리 모델(스택, 힙)/문자열 개념 소개 + 보너스로 깃허브 등 소스 코드 저장소 간략 소개다(2시간). 다뤄야 할 내용이나 방향과 관련해 댓글로 피드백을 주시면 감사하겠다.

EOB
작성자: 시간: 댓글 7개:
라벨:

화요일, 6월 24, 2014

[독서광] The Modern Web: 웹의 미래를 책임지는 멀티플랫폼 반응형 웹 프로그래밍

초창기 웹 기술이 전파되는 시점과 요즘 시점을 비교해보면 격세지감을 느낀다. PC뿐만 아니라 스마트폰, 스마트TV, 심지어 콘솔 게임기에도 브라우저가 장착되어 있으며, 단순한 자료 검색을 넘어 쇼핑은 물론이고 문서 작업까지도 웹 브라우저에서 수행하는 세상이 되었다. '멀티플랫폼'과 '반응형'이라는 용어는 일반화되어 흔히 들을 수 있게 되었다. 한 마디로 웹 기술이 폭발적으로 발전하고 있다. 그렇다면 이렇게 빠르게 바뀌는 세상에서 길을 잃어버리지 않으려면 어떻게 해야 하나?

에이콘 출판사에서 선물로 주신 'The Modern Web'이 (완벽하지는 않지만) 좋은 해법을 제시하고 있다. 이 책은 세부 기술에 대한 방대한 레퍼런스가 목적이 아닌 현대적인 웹 기술에 대한 소개서로 보는 편이 타당하다. 따라서, 이 책 한 권으로 신형 기술을 모두 독파하리라는 기대는 접는 편이 좋다. 하지만 현대적인 웹 기술 관점에서 무엇에 신경을 써야 하고 주의해야 하는지를 파악하고 싶다면 번지 수를 제대로 찾아온 것이다.

이 책의 특징은 다음과 같은 두 항목으로 정리가 가능하다.

  • 웹 개발 기술의 범위는 매우 방대해서 이 책 한 권에서 모두를 다룰 수는 없다. 따라서 이 책에서는 다양한 기기에 걸쳐 웹 프로젝트를 구축할 때 필요하다고 여겨지는 핵심 기법이나 기술을 위주로 다루었다.
  • 이 책에 있는 내용이 모두 폭넓게 적용될 수 있는 것은 아니다. 적어도 이 책에서 설명하는 유형은 그렇지 않다. 웹은 지속적으로 발달하고 있고, 책 출판이란 특정한 한 순간을 하나의 스냅샷으로 담는다는 것을 의미한다. 몇 가지는 변화할 것이고, 몇 가지는 쇠퇴하여 사라질 것이다.

웹 기술의 범위가 무척 넓은데다 아주 빠르게 변하고 있기에 끊임없이 호기심을 품고 공부하는 사람만이 승자가 되리라는 생각이다. 이 책의 지향점을 파악하기 위해 책 목차를 함께 보자.

  1. 웹 플랫폼: 본격적으로 시작하기 앞서 웹을 플랫폼으로 바라보는 시각을 정리한다.
  2. 구조와 시멘틱: 좋은 컨텐츠는 구조부터 제대로 잡혀 있다. HTML5를 시작으로 마이크로포맷, RDFa, 마이크로데이터라는 구조와 시멘틱 관련 표준을 소개한다.
  3. 기기 반응형 CSS: 제대로 잡힌 구조 위에서 멀티플랫폼에 대응하는 CSS 작성 방식을 설명한다. 미디어 쿼리를 시작으로 '반응형'과 '적응형' 개념의 차이와 크기가 다른 화면을 인식해 내용을 배열하는 방법을 소개한다.
  4. CSS 레이아웃에 대한 새로운 접근법: 고정된 좌표에서 벗어나게 돕기 위해 CSS 레이아웃과 관련해 다중 열, 유연한 박스, 그리드 레이아웃 기법을 소개한다.
  5. 모던 자바스크립트: 자바스크립트의 새로운 기능, 중요한 라이브러리, 호환성 격차 해서(폴리필), 디버깅 기법을 설명한다.
  6. 기기 API: 스마트폰/태블릿 등에 탑재된 센서와 주변 장비를 이용하는 API를 소개한다.
  7. 이미지와 그래픽: SVG와 캔버스를 소개한다.
  8. 새로운 폼: 구식 폼 대신 다양한 자료 유형을 인식하고 클라이언트 쪽 검증이 가능한 신형 폼을 소개한다.
  9. 멀티미디어: HTML5에서 새로 추가된 미디어 요소와 대응하는 API를 소개한다.
  10. 웹 앱: 웹 앱, 하이브리드 앱, 애플리케이션 캐시를 소개한다.
  11. 향후 전망: 앞으로 기술 추이를 전망한다.

주의 사항을 하나 언급하고 넘어가겠다. 단순한 용어와 개념 제시를 넘어서 320페이지 곳곳에 실제 HTML 코드와 대응하는 화면 예제, 자바스크립트 코드와 설명이 잘 정리되어 있으므로 쉽게 생각하고 접근했다가는 애로 사항이 꽃필 가능성이 있다. HTML 코드, CSS 코드, 자바스크립트 코드를 기본적으로 읽을 수 있어야 쉽게 따라갈 수 있다. 완전히 첫 걸음을 내딛는 초보자용 도서가 아니라는 사실에 주의해야 한다.

결론: 이 책은 큰 틀에서 기술 동향을 소개하고 있으므로 웹 퍼블리셔와 개발 담당자들이 현재 웹 기술 상태를 조감하기 위한 목적으로 읽어보면 좋겠다. 추천!

EOB
작성자: 시간: 댓글 없음:
라벨:
피드 구독하기: 글 (Atom)