토요일, 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
작성자: 시간: 댓글 없음:
라벨:

토요일, 6월 21, 2014

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

금주에도 풍성한 소식을 전해드려서 무척 기쁘다.

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

화요일, 6월 17, 2014

[독서광] 창문 넘어 도망친 100세 노인

1990년대 중반에 개봉한 포레스트 검프라는 영화를 알고 계신 분이 많으실테다. 우연히 20세기 미국 역사의 격변기마다 얼굴을 내미는 주인공(톰 행크스)의 이야기인데, 소설을 영화로 만들어 흥행과 비평 양쪽으로 공전의 히트를 쳤다. 그런데, 할배판 '포레스트 검프'라는 평을 듣고 있는 책이 있어 6월 연휴를 틈타 번개처럼 읽어봤다. 세계 각국에서 인기를 끌었으며 영화로도 만들어진 "창문 넘어 도망친 100세 노인"이 오늘 소개할 책이다.

이 책의 가장 큰 특징은 100세 노인의 현재 기행과 과거 경험이 절묘하게 교차 편집되며 20세기를 관통하는 데 있다. 포레스트 검프 못지 않게 알란 칼손(100세 노인)도 세계 역사의 격변기마다 얼굴을 내밀며 예상치 못한 흐름을 창조해낸다. 검프가 지능 지수가 낮다는 핸디캡이 있다면 칼손은 가족 사정상 아홉살 때 학업을 중단하고 고달픈 노동의 현장으로 뛰어들었다는 핸디캡이 있다. 하지만 특유의 낙천적이면서 질러놓고 보는 성향으로 인해 칼손은 여기저기서 사랑(응?)을 받아 수 많은 역경을 해쳐나간다.

아무래도 한국사람이다 보니 가장 흥미로웠던 부분은 한국의 김일성과 김정일을 만나는 과정에서 절대절명의 위기에 처하는 장면이었다. 북한에서 이 책이 확실히 금서로 지정될 것 같다는 생각이 들었다(스포일러 방지를 위해 자세한 설명은 생략).

마침 한국에서는 2013년 말에 만들어진 동명의 영화까지 개봉한다는 소식이 있다. 며칠 전 서점에 가보니 책 표지가 모두 영화 포스터처럼 바뀌었다는...

결론: 개인적인 일이 있어 마산에 다녀왔는데, 버스 안에서 시간 가는 줄 모르고 읽었다. 여름 휴가에 최적의 친구라는 생각!

뱀다리: 책 표지 종이를 펼쳐보기 바란다. 꼼꼼함에 놀랄지도!

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

토요일, 6월 14, 2014

[B급 프로그래머] (Quora) 정말로 코드 작성을 "좋아하지" 않더라도 전산을 전공해야 하나요?

Quora에 다음과 같은 질문이 올라왔다.

Should I major in computer science if I don't really "love" writing code?

한글로 번역하자면, "정말로 코드 작성을 "좋아하지" 않더라도 전산을 전공해야 하나요?"

인기를 끈 대답을 정리해보았다

당연합니다. 다음과 같이, 배울 수 있는 수 많은 지식이 존재합니다.

저도 코드 작성은 좋아하지 않지만, 전산과에 들어와서 기쁘답니다. 위에서 열거한 모든 지식을 배우게 도와주었기 때문입니다.

위에 소개한 내용이 궁금해지기 시작했는가? 그렇다면 작년에 소개한 [독서광] 미래를 바꾼 아홉 가지 알고리즘을 읽어보기 바란다. 아주 재미있고 알찬 내용이 들어있음을 보증한다.

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

화요일, 6월 10, 2014

[독서광] Sublime Text 따라잡기

워낙 vi에 익숙하다보니(vim도 아니고 오리지널 vi!), 솔직히 급할 때 운영체제에 기본으로 설치된 텍스트 편집기 이외에 다른 텍스트 편집기를 잘 사용하지 않는다(아, 딱 한 가지 예외로... 김성동님이 만드신 acroedit는 윈도우에서 종종 쓰곤 했었구나...). 하지만 서브라임 텍스트라는 프로그래머용 텍스트 편집기가 있다는 이야기를 듣고 맥에 설치를 했으나... 사실상 vi에 밀려 먼지만 덮어쓰고 있었다. 하지만 이제 슬슬 vi를 대신해 vi와 함께 사용하는 텍스트 편집기를 찾아봐야겠다는 생각이 들기도 한다. 이런 와중에서 출판사 놀러갔다가 선물 받은 Sublime Text 따라잡기라는 책을 번개처럼 읽은 소감을 정리해보겠다.

Sublime Text 따라잡기는 130페이지라는 짧은 분량으로 '서브라임 텍스트'라는 요즘 뜨는 편집기에 접근하기 위한 기초 지식을 빠짐없이 전달하기에 진입 장벽을 낮춰준다는 생각이 들었다. 목차를 잠시 볼까?

  1. 서브라임 텍스트 설치: 프로그램 설치에 필요한 필수적인 설명(특히 데이터 디렉터리와 패키지 컨트롤 설치하기에 주목하자)
  2. 코드 편집: 찾기와 바꾸기, 컬럼과 다중 선택, 필수 플러그인 소개, 단축키 소개(Goto Anything에 주목하자)
  3. 스니펫과 매크로, 키 바인딩: 코드 조각을 자동으로 채워넣는 스니펫, 반복 작업을 단순하게 만들어주는 매크로, 그리고 자주 쓰는 명령을 단축 키에 할당하는 키 바인딩 소개
  4. 사용자 설정과 테마 개발: 사용자 설정과 관련한 기초 지식 소개
  5. 빈티지 모드 사용: 서브라임 텍스트를 vi처럼 사용하는 방법 소개
  6. 코드 테스트: PHP, 파이썬, 루비에서 단위 테스트 수행 방법 소개
  7. 디버깅: PHP, 자바스크립트, C/C++ 디버깅 방법 소개
  8. 플러그인 개발: 간단한 루이 온 레일스 플러그인 개발

목차를 보면 알겠지만, 서브라임 텍스트를 사용하기 위해 필요한 최소한의 지식을 담고 있으므로 공력이 높은 고급 개발자가 아니라 도대체 서브라임 텍스트가 어떤 편집기인지 맛을 보고 싶은 개발자에게 적합하다. 일단 이 책을 읽고나면 LISP 해석기가 내장된 emacs 대신 파이썬 해석기가 내장된 서브라임 텍스트를 어떻게 확장하고 활용할지 감이 오리라는 생각이다. 추가로 몇 가지 유용한 정보를 공유하니 서브라임 텍스트에 관심이 많다면 읽어보면 좋겠다.

깜짝 반전: 이 글을 쓰는 시점에서 서브라임 텍스트는 공짜가 아니다. 다운로드해서 평가할 때까지만 공짜이며 계속 사용하려면 돈을 내야 한다. 따라서 회사에서 서브라임 텍스트를 사용하려는 분들께서는 각별히 주의하시기 바란다.

Sublime Text may be downloaded and evaluated for free, however a license must be purchased for continued use. There is no enforced time limit for the evaluation.
EOB
작성자: 시간: 댓글 6개:
라벨:

토요일, 6월 07, 2014

[B급 프로그래머] (Quora) 페이스북에서 '고급' 소프트웨어 엔지니어란?

Quora에 다음과 같은 질문이 올라왔다.

What does it take to be a "Senior" Software Engineer at Facebook?

한글로 번역하자면, "페이스북에서 '고급' 소프트웨어 엔지니어란?"

인기를 끈 대답을 정리해보았다

페이스북에서 아주 영향력이 큰 끝내주는 엔지니어를 만날 때, 몇 가지 공통적인 특질을 목격했다. 이런 엔지니어들은 더 많은 자율성으로 더 많은 영향력을 미칠 만한 능력이 있는 사람으로 압축된다.

  • 남들이 풀 생각도 풀 능력도 없는 기술적인 문제를 풀 수 있다.
  • 특정 분야를 아주 깊게 파고드는 지식이 있거나 특정 영역에서 다른 영역을 건너 다니며 쉽게 문제와 씨름하며 남들과 함께 일한다.
  • 자신들의 문제를 해결할 뿐만 아니라 다른 팀이나 회사 내 더 큰 부서가 빠르고 제대로 문제를 풀 수 있게 해법이나 프레임워크를 만들어낸다(자신들의 영향력을 크게 높이는 방법을 알고 있다).
  • 씨름할 가치가 있다고 밝혀질 때까지 어려운 문제를 여러 달이나 심지어 여러 해 동안 잡고 있어도 부끄러워하지 않는다.
  • 대다수 사람들이 자신의 인생 경력에 위험이 된다고 생각하는 범위를 벗어나며 개인적인 업무 평가에 연연하지 않는다.
  • 이런 엔지니어 중 많은 사람들은 정말 뛰어난 의사 소통자이자 조직화에 능숙한 사람이지만, 의사 소통과 친밀감이 필수 요구 사항은 아닌 듯이 보인다. 몇몇 사람은 정말로 뛰어나서 분야가 좁고 어려운 문제를 혼자 푸는 역량을 갖추고 있기 때문이다.

위에서 설명한 특질은 페이스북에서 일반적으로 볼 수 있으며, 다른 첨단 기술 회사도 마찬가지다. 계속해서 사람의 성장 관점에서 독특한 페이스북 문화를 소개한다.

  • 모호하고 바뀌는 요구 사항에 재대로 대응한다. 우리 핵심 가치 중 하나는 빠르게 움직이는 것이며, 이는 여러 회사가 자신들이 어떤 일을 해야할지 문서로 만들어 내느라 여러 달을 소비하는 동안, 우리는 프로토타입으로 넘어가 반복해서 개선함을 의미한다.이는 프론트엔드 개발자들이 여러 플랫폼(웹, 안드로이드, 아이폰, 태블릿 등)에 다양한 버전을 유지할 수 있는 능력을 갖춰야 함을 의미한다. 우리가 만드는 모든 제품은 첫날부터 바로 확장 가능해야 하므로, 벡엔드 엔지니어는 새로운 제품을 빠르게 수용할 수 있는 기반 구조나 프레임워크를 만들거나 확장 가능한 해법을 잽싸게 내놓으며, 계속해서 소프트웨어가 조금씩 바뀌어 나간다는 사실을 이해해야 한다.
  • 주고받는 피드백 관점에서 직설적이다. 페이스북의 열린 문화는 어느 누구도(어느 누구라는 단어를 사용할 때 마크 주커버그도 해당한다) 일방적으로 피드백을 주기만 하지 않는다. 열리고 솔직한 피드백은 사람들이 성장하게 만든다. 최고의 엔지니어는 피드백에 기반해 성장할 영역을 인식하는 사람들이다. 권위에 붙잡혀 있는 사람들은 가까워지기 어려우며, 피드백도 제대로 받아들이지 못한다.

덧붙이자면, 비록 가끔 이 용어를 사용해야만 하는 어쩔 수 없는 상황도 있긴 하지만, 나는 "고급(senior) 엔지니어"라는 용어를 정말 싫어한다. "고급 엔지니어"라는 용어는 기술 수준과 시간이라는 함수가 연관을 맺고 있음을 암시하기 때문이다. 하지만 솔직히 말해 페이스북에는 2년도 지나지 않아 회사를 위해 가장 중요하고 도전적인 몇 가지 작업을 수행하는 사람들도 있다.

언급하고 싶은 또 다른 주제가 있다. 많은 고급 엔지니어들이 죽치고 앉아서 "여기서 최고 엔지니어가 되려면 무엇을 해야할까?"라고 생각하며 지낸다고 믿지 않는다. 대부분은 정말 공부밖에 모르는 겸손한 사람이며, 어려운 문제들이 자신들의 관심을 끌기에 늘 깨어 있다. 보통 사람들이 잠자고 있을 때 열심히 일하고 노력하며, 뭔가 잘못되었을 때 초점을 잃지 않고, 자신들의 해법에 만족할 때까지 결코 포기하지 않는다.

만일 당신이 끝내주는 엔지니어/관리자/디자이너/PM/등이 되고 싶으면, 바로 가까이에 있는 문제에 뛰어들고, 더 큰 문제에 부딪힐 수 있게 정열과 아이디어를 집중하고, 당신이 최고로 잘하는 분야가 아닌 이상 현실에 안주하지 말기 바란다.

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

수요일, 6월 04, 2014

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

애플 WWDC가 있어 금주는 조금 빨리 정리된 소식을 올려드리겠다.

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

흥미로운 소식으로 3주에 찾아뵙겠다.

작성자: 시간: 댓글 4개:
라벨:

토요일, 5월 31, 2014

[독서광] 역사상 가장 영향력 있는 고양이 100

정말 간만에 책 한 권 소개해드리려 한다. (특히 트위터에서) 사람들의 혼을 쏙 빼놓는 고양이에 대한 책이라고 해서 냉큼 사서 읽어보았다.

책 내용은 인류의 문화와 문명에 영향을 끼친 여러 고양이에 대한 짧은 일화를 담고 있다. 자연/과학, 정치/역사, 예술/문학, 대중 문화, 용감 무쌍이라는 다섯 분야에 걸쳐 맹활약한 고양이들이 100마리나 등장하므로 멍멍이에 비해 상대적으로 푸대접을 받은 야옹이들의 지위 개선에 조금이라도 도움이 될 듯이 보인다. 개인적으로는 예술/문학 분야의 고양이들이 가장 놀라웠다. 주로 뮤즈가 나타나려면 술의 힘을 빌어야 한다고 생각했었는데, 고양이도 장난이 아니다(최근 모 교수님의 책 표지에 키우는 고양이가 등장해 화제가 되었었는데, 충분히 이해가 간다. ㅋㅋ).

책에 나온 고양이들도 무척 흥미롭지만... 아직도 기억에 생생하게 남는 일화는 바로 대부의 돈 꼴레오네 무릎 위에 올라간 고양이다. 언제부터 영화속 악당들은 고양이를 쓰다듬게 되었을까?에서 가져온 사진을 한번 보자.

Vito's cat에도 숨겨진 일화가 나오지만, 고양이의 가르렁거리는 소리 때문에 대부의 목소리가 잘 안 들리는 문제가 생겼음에도 불구하고 용케 편집에서 잘리지 않고 살아남은 모양이다(프란시스 포드 코플라 감독님이 장면이 잘 나와서 봐주신 듯.). 고양이가 대부의 숨겨진 표정 뒤에 숨어있는 발톱을 상징한다고 생각하면 아찔한 생각이 들지도 모르겠다. 실제 재개봉 당시 영화관의 큰 화면에서 고양이를 봤을 때 깜짝 놀란 기억이 아직도 생생하다(좁아터진 티비에서 볼 때는 잘 모르고 넘어갔었다. T_T). 보너스로 잠시 재미있는(!) 동영상을 하나 감상해보자(자막 보면 포복절도...).

고양이랑 노는 장면이 예사롭지 않다는 분들께 말론 브란도가 엄청난 애묘가라는 사실을 살짝 귀띔해드린다.

초 간단 결론: 이 책은 고양이 애호가들에게 추천!

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

수요일, 5월 28, 2014

[B급 프로그래머] (Quora) 나쁜 소프트웨어 엔지니어의 특성은?

Quora에 다음과 같은 질문이 올라왔다.

What are the characteristics of a bad software engineer?

한글로 번역하자면, "나쁜 소프트웨어 엔지니어의 특성은?"

인기를 끈 대답을 정리해보았다

  1. StackOverflow 봇: 이 친구는 오류를 만나면 잽싸게 구글 검색을 열어 발견한 첫째 대답을 적용한다. 여기서 문제는 스택오버플로우에서 복사하는 행위가 아니다. 어떤 참조 문헌이나 매뉴얼보다 스택오버플로우에 많은 해법이 있다고 생각한다. 오해하지 말기 바란다. 스택오버플로우는 최고는 아니지만 좋은 자원이니까. 문제는 추이를 생각하지 않고 복사기처럼 행동하는 데 있다. 현재 풀려는 문제에 적용할 수 있을지 맥락을 완전히 이해하지 않은 상태에서 섣부르게 응용하면 문제가 생긴다. 종종 직접 확인한 내용이 아니라 온라인 포럼에서 본 내용을 더 신뢰하는 사람들을 목격해왔다.
  2. 저는 테스터가 아닙니다: 코드를 테스트할 필요가 없으며, 이런 작업은 테스터 몫이다. 성숙한 애자일 방법론의 시대에도 이런 태도가 줄어든다고 생각하지 않는다. 여전히 코드를 테스트하는 작업에 대항하는 타성이 존재한다. 테스트 환경 설정에 무관심하거나 테스팅에 대한 논리 정연한 지식 부족 때문이라 생각한다(개발 공통체에서 테스터에게 뒤집어 씌운 오명도 일부 원인이긴 하다).
  3. 문서화를 싫어합니다: 몇몇 개발자들은 코드 문서가 문학이라 믿기에 이런 기술이 부족하다고 생각하며, 따라서 자신들의 일이 아니라 여긴다. 내 의견에 따르면 이런 생각은 지속적인 소프트웨어의 주적이다. 훌륭한 소프트웨어는 백만 가지에 이르는 좋은 기능을 제공하는 데 있지 않다. 훌륭한 소프트웨어는 많은 사람들이 일관성있게 사용 가능한 몇 가지 좋은 기능을 많은 개발자들이 읽고/수정하고/갱신할 수 있어야 한다. 이런 훌륭한 소프트웨어 개발자들은 기술적인 의사소통 보다는 정확하고 상세한 문서화가 회사의 성공에 가장 큰 버팀목이 되리라 믿는다.
  4. 동작하지만 보기 흉한 코드: x, flag, str, arr과 같은 변수 이름, 모든 것을 다 넣은 거대한 메소드, 코딩 관례나 스타일의 일관성 부재, 들여쓰기 부재, 전역 변수(다이아몬드 목걸이가 타이타닉 잔해에 묻혀 있다면, 어느 누구도 찾지 못하고, 깨끗하게 씻지 못하고, 착용하지 못하고, 사용하지 못할 것이다.)
  5. 단기 투자가: 코드를 만들고 배포하고 다음으로 넘어간다. 문제를 배우려는 시도는 없다. 업무 영역에는 관심도 없다. 단순히 코드만 주면, 밤새 묵묵하게 일한 다음 완성해서 넘길 것이다. 소프트웨어를 수정하고 만든다. 여기서 어떤 업적도 달성하지 못한다. 종종 개발자의 이기적인 태도가 중요하지만, 마감일 뿐만 아니라 개발 과정에서 무엇을 얻을지도 신경써야 한다.
  6. 시위자: "저는 이 일은 안 합니다.", "나쁘게 보이네요.", "제 문제가 아닙니다." "제 수정과 관련이 없고, 저기 누군가 실수를 했습니다.", "싫다구요!(하루에 10번 이상 반복한다)", "이 문제는 제가 수정할 수 없습니다. 만든 사람에게 시키세요."
  7. 독재자: "협조하거나 꺼지거나"가 모토다. "자신들의 아이디어"와 "당신의 아이디어"만 있고 "프로젝트 아이디어"는 없다. "자신들의 해법"이거나 "당신의 해법"뿐이다. 이런 사람은 생산성에 있어 큰 병목이며, 압력하에 바스러지거나 남을 비난하기 시작할 첫 사람이다. 개발자로서 경험이 있고 좋을지는 몰라도 함께 일하는 팀에 있어 좋은 사람은 아니다.
  8. 지나치게 조심하는 개발자: 파이썬 스크립트를 작성해야 한다는 사실을 알았을 때 멘붕이 온 자바 개발자가 있다. 레지스트리 변경이 필요하다는 사실을 알았을 때 공포에 질린 개발자가 있다. 데이터베이스에 뭔가를 입력해야 한다는 사실에 당혹해하는 개발자가 있다. 이런 개발자들은 안락한 영역에서 벗어나지 않기 위해 뭐든 할 것이다. 이런 개발자들에게는 시스템의 특정 영역을 건드리는 작업과 관련해 기묘한 미신이 있다. 개인적인 경험에서 보면 새로운 개발자에게 흔히 보이는 현상이며, 좋은 개발자들은 탐구 과정에서 차근차근 이런 안락한 영역으로부터 벗어나려는 경향을 보인다.
  9. 부주의: 백업과 스냅샷에 신경쓰지 않으며, 코드를 여러 작업 디렉터리에 분산하며, System.out.println을 상용 코드에 남겨 둔다. 새로운 개발자에게 흔히 보이는 현상이며, 전문적인 환경을 접하면 나아진다.
  10. 게으른 가짜 해커: 시스템을 동작하게 만드는 트릭에 자부심을 느낀다. 완벽한 해법을 위한 마법을 찾는다. 경험에 따르면 이는 십중 팔구 빚좋은 개살구다. 가짜 해킹은 나쁘며, 조만간 망가지며, 수습에 더 많은 비용과 시간이 든다.

자, 그렇다면 여러분들이 뽑은 나쁜 소프트웨어 엔지니어의 특성은 어떤가? 댓글로 공유하면 감사하겠다.

작성자: 시간: 댓글 13개:
라벨:

토요일, 5월 24, 2014

[번역은 즐거워] 바꿀 수 있는 사안에 대한 걱정(링크드인 펄스 블로그에서)

오늘은 걱정에 대한 글을 번역해 소개하겠다.

당신은 걱정을 달고 사는 사람인가? 작은 일, 큰 일, 모든 일을 걱정한다는 사실을 걱정하는가? 문제는 걱정이 시간과 에너지를 많이 소비한다는 점이다. 이를 다른 곳에 더 좋게 사용할 수 있으므로 가능하면 걱정을 떨쳐버리기 바란다.

걱정은 결과가 불확실하거나 통제권이 없는 상황에서 뭔가 사건이 터질 경우 일어나는 인간의 공통적인 감정이다. 잠시 통제에 대해 생각해보자.

통제 역시 걱정의 대상이다. 문제에 대해 통제력이 있는가? 문제를 바꿀 수 있는가? 걱정하는 바를 전혀 통제하지 못하며, 변경할 수도 없다면 걱정하지 마라.

모든 것을 통제할 수 있어야 한다고 생각하면, 누가 당신에게 우주를 관리하는 임무를 맡겼을까?

사건이나 다른 사람을 통제하지 못할지도 모른다. 하지만 당신은 당신의 감정을 통제할 수 있다. 걱정을 통제할 수 있고, 원한다면, 걱정을 인생에서 지울 수도 있다. 그러니 걱정 마시라.

아무 걱정이 없다는 생각이 당신을 걱정하게 만드는가?

아마도 당신은 염려와 걱정이 시간을 소비하고 당신이 무엇을 하든 아무 가치도 부가하지 않는다는 사실을 이미 알고 있을 것이다. 그렇다면 걱정을 왜 하는가?

일과 관련된 사항만 걱정하는가 아니면 염려가 개인적인 삶에도 영향을 미치는가? 건강이나 결혼과 같은 특정 사안에 대한 걱정에 시달리는가 아니면 당신이 영향력을 미치지 못하는 온갖 종류의 일에 대해 '자유롭게 떠돌아 다니는 염려'에 시달리는가 아니면 일반적인 사안에 대해 걱정하는가? 내가 여기서 제시할 수 있는 범위를 넘어서 더 많은 도움이 필요할지도 모른다는 사실을 자각하고 있을지도 모르겠다. 지금부터는 당신의 계속되는 사소한 걱정을 누그러뜨리고 걱정하는 경향을 통제하는데 도움을 주는 내용을 정리한다.

만일 당신이 걱정하고 있다면, 원인이 무엇일까?

컬럼비아 대학교의 딘 호키스 학장은 "결정의 근거가 되는 충분한 지식을 갖추기 전에 결정을 내리려 시도하는 사람들이 세상 걱정의 절반을 일으킨다"라고 말한 적이 있다.

그는 아주 설득력 있는 논점을 제시했다. 따라서 사실을 수집하고 경중을 따져 결정을 내리자. 일단 결정을 내린 다음에 해야 할 가장 중요한 작업은 실천이다. 질질 끌지 마라. 잘못될 수 있는 일에 대해 걱정하느라 시간을 낭비하지 마라. 그대신 긍정적인 면을 보고 거기에 초점을 맞춰라. 문제에 대해 걱정하려는 유혹에 빠지기 앞서 문제를 다시 한 번 신중하게 생각하고 다음 질문을 스스로에게 해보라.

  • 문제가 무엇인가?
  • 문제를 초래한 원인이 무엇인가?
  • 가능한 해법이 있는가?
  • 최상의 해법이 무엇인가?

초기의 '걱정'이 얼마나 단순해지며, 얼마나 쉽게 풀릴 수 있는지에 놀랄 것이다.

만일 이런 접근 방법이 통하지 않는다면, 한 단계 더 나가 최악의 상황에 영합할 수도 있다. 최악의 시나리오를 받아들이자. 다음 세 가지 질문을 스스로에게 해보자.

  • 일어날 수 있는 절대적인 최악의 상황은 무엇인가?
  • 실제로 이런 최악의 상황이 일어날 수 있는 가능성은 얼마인가?
  • 이런 최악의 상황이 벌어졌을 때, 당신이 해야 하거나 할 수 있는 일이 무엇인가?

최악의 시나리오를 생각할 때, 여기에 대한 해법을 마음 속에 그려보고 찾는 작업은 불안을 다루기 위한 가장 좋은 방법 중 하나다. 일어날 수도 있는 최악의 상황이 해결하지 못하는 문제가 아니라는 사실을 발견할지도 모른다. 아니면, 실제로 상황을 조감할 때 당신의 걱정이 얼마나 우스꽝스러운지 알고 웃을지도 모르겠다.

  • 잭: 하느님 맙소사! 장모님 생일 잔치를 잊어버렸구나. 나는 이제 죽었다! 집에 갈 수도 없는데, 이제 어떻게 해야 하나?
  • 질: 일어날 수 있는 최악의 상황이 무엇이에요?
  • 잭: 장모님은 저랑 다시 이야기도 안 하실지도 몰라요!
  • 질: 그게 최악의 상황이네요. 장모님이 말도 안 건넨다.
  • 잭: 맞아요. 잠시만 아니에요. 그건 그렇게 나쁘지 않아요.
  • 질: 좋아요. 그렇다면 뭐가 최악의 상황이에요?
  • 잭: 제 마누라가 저를 죽일지도 몰라요.
  • 질: 정말 그래요? 어떻게 부인이 당신을 죽일까요?
  • 잭: 고통스럽게. 아 어떻게라고 말했나요? 음. 잠시만 기다려봐요. 그게 말이에요.

해법에 초점을 맞추자. 당신의 기업가적인 창의성은 심지어 가장 험한 시나리오에 대한 해법도 찾아낼 수 있을 것이다. 이런 연습은 당신의 가장 치명적인 공포를 편안하게 다스리게 도와주며, 더 중요하게 이에 대한 실질적인 해법을 제공할 것이다. 일단 일어날 수 있는 가장 최악의 상황을 밝혀내는 계획을 수립하고 나면, 문제와 불확실성은 최소로 줄어든다. 이게 가능하면 전진할 수 있다.

최악의 시나리오를 고려한 다음에, 만일 여기에 대해 할 수 있는 일이 없다는 사실을 발견하면, 확실성을 받아들여라. 선택의 책임에서 벗어나며, 불가피함을 감수할 수 있다. 만일 뭔가 일어나고 있고 바꿀 수 없다면, 이를 감수하라! 할 수 있는 다른 일이 없다면 여정과 학습을 즐겨라.

또 다른 공통적인 문제는 과거에 대한 걱정이다. 한창 잘 나가던 시절에 아주 똑똑한 사람들을 만나왔다. 하지만 과거로 돌아갈 수 있는 누군가를 만나지는 못했다. 지나간 과거에 대한 걱정으로 시간을 낭비하지 마라. 이에 대해 할 수 있는 일은 딱히 없다. 과거에서 배워 미래를 향해 전진할 수 있을 뿐이다. 도움이 되지 않는 감정은 과거에 원래 있던 곳에 남겨두자. 무엇이 일어났는지를 반성하자. 일어난 일에 대해 무엇을 배웠는지 반성하자. 미래에 어떻게 다르게 행동할지 결정하자. 위대한 학습의 기회로 포용하고 앞으로 나가자.

긍정적인 정신적 태도를 계발하자. 우리가 걱정하는 뭔가를 고치거나 문제에 대해 조치를 취하려면 시간과 노력이 많이 필요하다. 물론 여기에 대해 걱정을 하더라도 시간과 노력이 많이 필요하다. 앉아서 걱정하는 대신, 뭔가를 실행하고 정리하자!

걱정은 당신의 삶에 아무런 가치도 부가하지 않는다. 만일 어쨌든 걱정을 꼭 해야겠다면, 시간에 제약을 두고 걱정하는 시간을 최소로 줄이는 프로세스를 만들자. 좋다, 여기에 대해 5분만 걱정하고 다음으로 넘어간다. 결론에 도달하거나 해법을 찾거나 현실을 받아들일 때까지 체계적으로 걱정하자. 5분 안에 말이다!

무엇보다, 상황을 바꿀 수 있는 당신의 역할을 인식하자. 뭔가 할 수 있다면, 정말 멋지다. 당장 실천하자.

만일 그럴 수 없으면, 여기에 대해 생각하느라 에너지를 낭비하지 말기 바란다. 당신이 할 수 있는 긍정적인 면을 생각하라. 인생은 너무나도 짧다!

추천도서:

  • Feel the Fear and Do it Anyway by Susan Jeffers (Amazon Link UK, US)
  • The Power of Now by Eckhart Tolle (Amazon Link UK, US)
  • How to Stop Worrying and Start Living by Dale Carnegie (Amazon Link UK, US)

저자: 마크 윈

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

토요일, 5월 17, 2014

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

금주에도 푸짐한 소식으로 여러분들을 찾아뵐 수 있어서 뿌듯하다.

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

수요일, 5월 14, 2014

[번역은 즐거워] 신뢰: 모든 것이 만들어지는 초석(링크드인 펄스 블로그에서)

신뢰가 무너진 사회가 어떤 모습인지 지난 몇 주 동안 충분히 목격하고 있다. 관련있는 주제라고 생각되어 '신뢰'에 대한 글을 하나 번역해 올려드린다.

성공적인 관계, 팀, 조직을 이끄는 가장 중요한 원동력을 하나만 찍어 달라고 요청 받으면, 신뢰를 선택하겠다. 신뢰는 다른 모든 것이 구축되는 토대다.

신뢰는 "누군가 혹은 뭔가의 안정성, 진실, 능력, 힘에 있어 확고한 믿음"이다. 단순하게 들릴지도 모르겠다. 하지만 신뢰를 쌓기란 어렵지만, 잃어버리기는 놀랄 만큼 쉽다. 이런 중요성에도 불구하고, 신뢰를 육성하거나 신뢰에 초점을 맞추는 경우가 드물다.

신뢰가 중요한 이유는?

  1. 신뢰는 투명성을 이끈다. 동반자 관계나 조직을 위해 마음 속으로 최선을 다한 당신의 언급이 액면 그대로 받아들여질 것이라 신뢰하지 못하면, 의도하지 않은 결과에 공포를 느낄 것이다. 당신은 아무 말도 하지 않는다. 투명성 없이는 "다섯 가지 팀의 기능 장애"라는 책에서 패트릭 렌시오니가 적었듯이, 당신은 마음을 연 상태에서 정직한 논쟁을 벌이거나, 최적화된 해법, 책임감, 뒤따르는 약속에서 이익을 얻지 못한다. 투명성이 없다면, 짚고 넘어가야 할 문제는 그대로 남아있게 되며, 토론이나 주장 역시 찾아볼 수 없다.
  2. 신뢰는 자율성을 이끈다. 개인이 스스로의 말을 지키는 모습을 더 많이 보여줄수록, 관리자들은 방해가 안 되게 비켜나서 전문성이 빛나게 만들며, 책임질 영역을 점점 더 많이 이양한다. 모든 사람이 승자가 된다. 다니엘 핑크가 "추진력: 우리에게 동기를 유발하는 놀라운 진실"에서 밝히듯 자율성은 동기를 유발하는 가장 큰 기여 요소다.
  3. 신뢰는 관계를 강화한다. 누군가 뭔가를 말한 다음 말을 바꾸면, 향후에 관계를 유지하고 싶지 않을 것이다. 문제는 다음과 같다. 조직 내 팀은 상호 의존성이 매우 강하므로, (특히 고위 직급에서) 연결이 깨진다면, 균열을 회피할 목적으로 차선의 경로를 택한 모든 개인에게 엄청난 영향을 미친다.

아주 좋다. 이제 감을 잡았다. 신뢰는 중요하다. 그렇다면 신뢰를 구축하기 위해 우리는 어떻게 해야할까?

  1. 신뢰를 규범으로 확립한다. 신뢰가 중요한 이유를 설명하고, 팀 사이에서 이를 공유하게 만든다. 안전한 토론을 위한 한도와 함께 새로운 표준을 수립한다. 동반자 한 명이든 다섯 명으로 구성된 작업 팀이든, 천 명 짜리 조직이든 이런 작업을 누구와 하든 상관 없다. 당신에게는 남들과 다른 차이를 만들어 내는 능력이 있다.
  2. 투명해져라. 모든 사람이 볼 수 있게 카드를 테이블에 펼쳐라. 모든 사람이 이해하는 내용이 일치하게 기대치를 명확히 밝혀라. 솔직히 말하고, 존중하고, 골치 아픈 문제에 대해 결코 입을 닫고 있지 마라. 편안해야 할 필요는 없으나 정직해야 할 필요는 있다.
  3. 무엇을 하려는지 말하라. 약속하고, 명확하게 기대치를 설정하고, 실행하기만 하면 된다. 상황이 바뀌어, 최선을 다하더라도 더 이상 약속을 지키지 못하게 되면, 정직하게 바뀐 상황을 관련자들에게 초기에 전달한다.
  4. 다른 사람들에게 책임을 지우라. 일단 새로운 규범을 전달했으면, 이를 지키지 않을 경우 뭐가 잘못되었는지 자신과 다른 사람들에게 질문하고 언제 문제가 생겼는지 사람들이 인식할 수 있게 알릴 필요가 있다.

신뢰를 구축하기 위한 방법에 초점을 맞춰 주의를 기울인 결과, 나는 신뢰가 팀의 성공을 이끄는 아주 강력한 원동력일 뿐만이 아니라, 개인적인 진실성과 원칙의 핵심 구성요소라는 사실을 알게 되었다.

신뢰와 관련해 여러분의 경험을 듣고 싶다. 댓글로 공유하면 좋겠다.

저자: 케빈 사이먼

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

토요일, 5월 10, 2014

[B급 프로그래머] (Quora) 1~2주일만에 가능한 흥미로운 코딩 프로젝트는?

Quora에 다음과 같은 질문이 올라왔다.

What are some interesting coding projects that I can complete in 7-14 days to build my resume for a summer internship?

한글로 번역하자면, "방학 인턴으로 이력서에 올릴만한 1~2주일만에 끝낼 수 있는 흥미로운 코딩 프로젝트는 무엇일까요?"

여기 대해 좋은 대답이 올라와서 간단하게 정리해봤다.

  • 기존보다 더 잘 끝낼 수 있다고 생각하는(또는 의도에 잘 맞다고 생각하는) 스마트폰/컴퓨터용 앱을 작성한다.
  • 구글 스프레드시트나 애버노트와 연동되는 할일 목록(API 사용)
  • 스타트업 아이디어를 잽싸게 기록해 놓았다 목록(또는 일부 목록)을 친구와 공유하게 만들어주는 "아이디어 추적" 모바일 앱. 구글 스프레드시트와 연동이 핵심 포인트다.
  • 대화 중에 "가지"를 치게 허용하는 챗 위젯. 대화하는 도중에 누군가 끼여들어 다른 주제를 제시하는 경우 어떻게 해야할까? 새로운 대화로 가지를 치면 어떨까?
  • 오픈 테이블에서 Yelp 후기를 겹쳐 보여주는 크롬 확장
  • "동적으로 생성하는 포럼": 링크를 보내기만 해도 동적으로 포럼을 잽싸게 만드는 프로그램. 대화 스레드를 지원한다.
  • 소셜 북 추천기: 직전에 무엇을 구매했는지 아마존 영수증을 스캔해 이메일로 보내거나 아마존의 과거 구매 내용을 스크린샷으로 잡아 보내면, 친구가 가장 많이 구입한 책이 무엇인지 보여준다.

그렇다면 여러분의 추천 프로젝트는 무엇인가? 댓글로 공유해주면 좋겠다.

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

토요일, 5월 03, 2014

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

많은 분들께서 프로그래밍 소식지에 관심을 보여주셨기에 감사드린다. 여느 때와 마찬가지로 개발 관련 각종 소식을 정리해보았다.

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

목요일, 5월 01, 2014

[번역은 즐거워] 가상 현실의 미래(오큘러스 블로그에서)

분위기도 쇄신할 겸 정말 몇 년 만에 블로그에 새로운 카테고리를 만들어봤다. '[번역은 즐거워]'라는 표제로 시작하며, 독자 여러분들께 도움이 될만한 글들을 번역해 올려드리겠다. 오늘은 1번 타자로 오큘러스 블로그에 실린 The Future of Virtual Reality라는 글을 소개하겠다.

나는 늘 게임을 좋아했다. 게임은 우리에게 환상적인 여행이 가능하게 만드는 세상으로 이끄는 창이었다. 가상 현실 분야에 들어가려는 시도는 게임 경험을 강화하고 환상적인 세상으로 이끄는 창이 아니라 도구를 만들어 환상적인 세상으로 실제로 들어가려는 욕구에서 출발했다. 시간이 지남에 따라, 가상 현실 기술은 가능성을 넘어서 거의 주류로 뛰어들 준비가 된 상태라는 사실을 자각했다. 정말 필요한 것은 제대로 된 추진력이었다.

우리는 가상 현실을 일반화하고 접근성을 높여 누구나 불가능을 경험하게 만든다는 비전으로 오큘러스 VR을 시작했다. 믿기 힘든 공동체의 도움 덕분에 전 세계 게임 개발자, 컨텐트 제작자, 예술가들로부터 7만 5천에 이르는 개발 킷을 주문 받았다.

페이스북이 처음 동반자 관계를 모색하려 접근했을 때, 나는 회의적이었다. 하지만 페이스북과 페이스북의 비전에 대해 더 많이 이해하게 되고 마크와 이야기를 나누면서, 동반자 관계는 실현 가능성을 넘어 가상 현실을 모든 사람에게 전달하는 명백하고 확실한 경로가 되었다. 페이스북은 세상을 더욱 연결된 장소로 만든다는 비전으로 설립되었다. 가상 현실은 예전에 결코 가능하지 않았던 방식으로 다른 사람들과 경험을 공유하게 만드는 매체다.

페이스북은 오큘러스 문화와 보조를 맞추는 개방된 방식으로 운영된다. 지난 10년 동안, 마크와 페이스북은 개방형 소프트웨어와 하드웨어 분야에서 챔피언이 되어 왔고, 전체 기술 업계를 대상으로 혁신의 한계를 초월했다. 페이스북이 성장함에 따라, 페이스북은 오픈 컴퓨터 프로젝트와 같은 노력에 투자했다. 오픈 컴퓨터 프로젝트는 업계 전반에 걸쳐 컴퓨터 기반에 투입되는 비용을 줄이고 창의력을 이끌어낼 목적으로 시작되었다. 용감하게 미래에 판돈을 건 팀이었다.

결국 나는 우리가 오큘러스에서 매일 자문했던 질문으로 돌아갔다. 가상 현실의 미래를 위한 최선의 노력은 무엇일까? 마크와 페이스북 팀과 동반자 관계를 맺는 기회는 특별하고 강력하다. 동반자 관계는 우리의 비전을 가속화하며, 가장 창의적인 아이디어를 실천에 옮기게 도와주며, 동반자 관계가 아니면 불가능한 위험을 짊어지게 만들어준다. 한 가지 더 중요한 사실이 있다. 동반자 관계는 우리의 기대치보다 훨씬 빨리 훨씬 적은 타협으로 오큘러스 리프트를 더 좋게 만들어준다는 사실을 의미한다.

우리가 올바른 팀을 구축하기 위해 상당히 많은 자원을 투입했음에도 불구하고 오큘러스의 일상은 거의 변화가 없었다. 컴퓨터 비전, 그래픽, 입력 장치, 오디오와 관련해 어려운 문제를 풀기 원한다면 언제든 오큘러스에 지원하라!

게임 업계에 특별한 순간이 왔다. 오큘러스의 다소 불투명한 미래가 수정처럼 맑아졌다. 가상 현실이 다가오고 있으며, 그 결과 우리가 게임하는 방식을 영원히 바꿀 것이다.

나는 가상 현실에 푹 빠져 있었다. 낮에는 일을 추진하며, 밤에는 우리가 가는 목적지를 꿈꿨다. 심지어 무모한 꿈속에서조차 그렇게 멀리 그렇게 빨리 목적지에 도달하리라고는 결코 상상하지 않았다.

이런 공동체 일원이 되어 자랑스럽다. 가상 현실과 게임 사업 추진에 도움을 주고 제품 출시에 대해 신뢰를 보여준 모든 분들께 감사한다. 우리는 여러분들을 실망시키지 않을 것이다.

– 팔머 럭키, 창립자, 오큘러스

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

수요일, 4월 30, 2014

[일상다반사] 원칙 없는 사회

트윗을 읽다가 다음과 같은 아주 핵심을 찌르는 @HyeYunLee님의 글이 눈에 띄여 소개한다.

오늘 미국에서 오래 거주한 한국인과의 대화. "미국은 안 되는건 안 되는데. 한국은 안 되는걸 되게 하거나 될 수도 있게 하는 것이 가장 문제" 세월호 뿐만이 아니라 한국사회 전반적으로 깔려있는 원칙을 어기고 일을 진행하는 것이 능력으로 포장된건 아닌지

이 글을 읽다보니 몇 년 전에 미국에서 오래 거주한 지인(한국 사람이다)이 해준 비슷하지만 조금 다른 이야기가 생각나서 간략하게라도 정리하고 넘어가지 않을 수 없다.

미국에 가보면(뭐 예상하겠지만... EU에 속해 좀 잘 나간다 하는 유럽 국가도 마찬가지다), 공항, 상점, 음식점, 공공기관, .... 등에서 현장 직원들의 서비스 수준에 놀랄 때가 많을 것이다. 외국에 나가서 융통성이라고는 정말 개미 눈꼽만큼도 없는 서비스를 받으며 속이 터진 경험을 누구나 한번씩 해봤을 것이니 여기서 다양한 사례는 과감하게 생략하고 바로 본론으로 들어가겠다. 여기서 현상을 탓하지 말고 이유를 생각해보자. 왜 그럴까? 왜 선진국은 한국처럼 서비스를 번개처럼 멋지게(커피 나오셨습니다?) 하지 못할까?

지인이 분석한 결과는 너무나도 흥미로웠다. 지인의 주장에 따르면, 미국은 철저하게 능력 중심으로 승진이 일어나기 때문에(물론 안 그런 경우도 있지만 일반적으로 그렇다는 말이다) 정말 똑똑하고 싹싹하고 뛰어난 친구들은 승진에 승진을 거듭해 조직의 위쪽에 올라가 있기 때문에 현장에서 볼 수 없기 때문이란다. 이런 능력있는 친구들은 자신들이 아는 바를 총동원해 아주 평범하고 일반적인 사람도 고민하지 않고 일을 할 수 있게 원칙과 절차를 만드는 작업에 투입되므로 융통성을 희생하더라도 어떻게든 일은 진행되는 시스템을 구축할 수 있게 된다. 일을 처리하면서 예상하지 못했던 예외는 예외대로 모아 별도의 전문가(말 그대로 전문가)에게 위임해버리는 방법을 사용한다. 하지만 한국은 미국과 정반대로 현장의 아르바이트 직원은 아무리 똑똑하고 싹싹하고 뛰어나더라도 승진을 기대하지 못한다(아주 드물게 점장까지 하는 사람도 있지만... 창업주의 일가 친척이 아닌 이상 조직이라는 사다리의 꼭대기로는 절대 올라가지 못한다). 생존을 위해 융통성을 극대화하고 필요에 따라서는 규칙과 원칙도 과감하게 위반해야 한다. 그 결과 역설적으로 한국에 살고 계신 여러분들은 (원칙이니 규칙을 잘 지키는지는 아무 관심 없고...) 현장에서 똑똑한 사람들이 제공하는 융통성이 극대화된 최상의 서비스를 받을 수 있는 것이다. T_T

와, 정말 그럴싸한 이야기가 아닐까? 하지만, 여기서부터 파생되는 결과가 더 중요하다. 미국은 일선 직원들에게 매뉴얼에 명기된 권한과 책임을 명확하게 부여한다. 한국은 좋은 것이 좋은 것이므로 권한과 책임을 명확하게 구분하지 않는다. 그 결과 평상시에는 미국보다 한국이 월등히 높은 효율을 낼 수 있다. 현장에서 실행하는 사람들의 수준에서 차이가 날뿐더러 규칙과 원칙대로 하다보면 아무래도 시간도 오래 걸리고 사람도 많이 필요하게 되는 등 간접 경비(overhead)가 커지기 마련이니까. 자, 그렇다면 평상시가 아니라 비상시가 되면 어떻게 될까? 가용한 모든 자원을 집중하기 위해 적극적인 리더십이 필요한 상황이라면 어떻게 될까? 몇몇 똑똑한 비정규직 직원만으로 방어가 가능할까? 피해를 줄이거나 사전에 위험을 최대한 회피할 수 있을까? 답은 이미 우리 모두가 알고 있다. 연일 뉴스와 신문에서 대문짝만하게 사고 소식을 보도하고 있으므로 여기서 더 이상 언급하지 않겠다.

합리적인 선을 넘어서 원칙적으로 안 되는 것을 되게 만든 영웅담이 회자(아니 미화)되지만 정작 이로 인해 심각한 문제가 생겨 누군가 책임질 상황이 닥치면 미개한(응?) 아래 것들만 주리를 틀어 책임을 떠넘기며 꼬리를 자르고 도망가는 행태가 반복되는 상황에서 무엇을 더 기대할 수 있을지 모르겠다. 이번 사고 후에 별의별 희한한 온갖 종류의 대책이 다 나올텐데 백약이 무효라는 데 한 표 던진다. 향후 문제점이 개선될 가능성은 그리 높지 않으며 유사한 재난은 앞으로도 반복되리라는 사실이 사람들을 더욱 암울하게 만드는 진짜 이유다. 원칙대로 해도 융통성 없는 병신이라는 소리를 듣지 않는 사회가 되어야만 제대로 풀릴 문제다. 어떻게 보면 몇 푼 아끼느라, 조금이라도 빨리 하기 위해, 나 하나 편하자고 원칙 없는 사회를 만드는데 직간접으로 일조한 우리 모두가 자초한 결과다. 정말 부끄럽다.

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

화요일, 4월 29, 2014

[일상다반사] 아파치 Solr 4 구축과 관리 : 오픈소스 루씬 기반 엔터프라이즈 검색 플랫폼

해 님께서 열심히 작업해주신 덕분에 번개처럼 무사히(!) 번역을 끝낸 아파치 Solr 4 구축과 관리 : 오픈소스 루씬 기반 엔터프라이즈 검색 플랫폼이 절찬리에 예약 판매 중이다. 사회 초년생 때 검색 엔진 팀에 속해 KMS(지식 관리 시스템) 등을 만들고 나서 거의 10년 만에 검색 엔진 관련 서적을 손에 쥐니 기술의 발전사를 온 몸으로 느낄 수 있었다. 기존에 루씬을 사용한 경험이 있다면, 엔터프라이즈에 적합하게 기능과 확장성이 강화된 Solr에 한번 쯤 관심을 보이면 의외의 수확을 거둘 수 있을 것이다.

Solr는 톰캣, Jetty와 같은 서블릿 컨테이너로 배포가 가능하므로, 프로그래밍 지식이 크게 필요하지 않다는 점에서 프로그래밍이 필요한 루씬과 결정적인 차이점을 보인다. 루씬이 엔진이라면, Solr는 자동차다. 검색 기능이 필요한 단독형 애플리케이션을 제작한다면 루씬이 적합하지만, 엔터프라이즈용 검색 기능을 서비스에 추가한다면 Solr가 정답이다. 루씬을 사용할지 Solr를 사용할지 고민하는 분들이라면 답을 정해드리겠다. 십중팔구 여러분이 원하는 해법은 Solr다.

자, 그렇다면 Solr는 루씬에 어떤 기능을 더 추가했을까? 간략하게 추가된 기능을 정리하면 다음과 같다(세부 기능이 궁금하다면 공식 Apache Solr 페이지를 방문하기 바란다).

  • XML/HTTP와 JSON API
  • 검색 결과 강조(highlight)
  • 패싯 검색과 필터링
  • 공간 지리 검색
  • 빠른 점진적인 갱신과 색인 복제
  • 캐시
  • ZooKeeper를 사용한 클러스터 구성(고가용성)
  • 복제
  • 분산 색인/샤딩
  • 모니터링 인터페이스와 AJAX 기반 웹 관리도구

'아파치 Solr 4 구축과 관리'에서는 위에서 소개한 기능에 대해 빠르고 쉽게 접근하는 지름길을 제시한다. 책에 대한 역자의 간략한 소개는 역자 소개를 살펴보시고(분량상 소개는 생략한다), 상세 목차는 목차를 살펴보시면(역시 분량상 정리는 생략한다) 이 책이 추구하는 방향을 알 수 있을 것이다. 아무쪼록 이 책이 Solr 4를 탐험하는 데 있어 도움이 되기를 바란다.

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