컴퓨터 vs 책

토요일, 1월 28, 2017

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

(오늘의 짤방: Toru Iwatani shows his original drafts for Pac-Man. via @HistoryInPix)

마무리

신년 맞이 보너스 via @JeffreyLuke

EOB

토요일, 1월 21, 2017

2017년도 새해를 기념해서 첫 책을 소개해드리겠다. 놀랍게도 오늘은 '요리책'이 아닌 '요리책'이다. '레시피보다 중요한 100가지 요리 비결'이라는 제목이 붙은 이 책은 요리를 잘 하기 위한 기본기를 소개한다는 면에서 상당히 특이하다. 일반적인 요리책은 조리법에 집중을 하기 때문에 재료나 준비 과정에 있어 필요한 각종 지식은 건너 뛰기 마련이다. 하지만 사소하다면 사소하다고 볼 수 있는 이런 배경 지식이 요리의 완성도를 극대화하기 때문에 이 책에서 제시하는 여러 가지 팁을 허투루 취급해서는 곤란하다는 생각이다.

주제는 크게 야채/과일, 육류, 해산물, 계란(!), 밥/빵/면류에 대한 비결, 밑준비, 요리 준비, 간, 조리 도구 식재료 선택/저장/보관에 대한 비결로 나뉘어진다. 다음에 소개하는 몇 가지 비법에 대한 제목만 봐도 도움이 될 것이다.

감자를 통째로 익힐 때에는 찬물에서부터 넣어서 삶는다
고기를 익히거나 가열하기 전에 칼집을 넣는다
햄버그스테이크는 센 불에서 시작하여 약 불에서 익힌다
흰 살 생선은 단시간에, 붉은 살 생선은 시간을 들여 조린다
계란 지단을 부칠 때에는 기름을 부은 뒤 팬을 한 번 닦아낸다
샌드위치를 만들 때에는 빵 한쪽 면에 버터를 바른다
파스타를 삶는 시간은 표준보다 약간 짧게
양파를 자를 때 눈물이 나지 않게 하는 방법
토막을 낸 고기나 생선은 물에 씻지 않는다
샌드위치에 넣을 야채는 키친타월로 수분을 제거한다
고기와 야채는 센 불에 빨리 볶아낸다
만두를 팬에 구울 때에는 기름을 넣기 전에 물부터 넣는다
볶는 요리의 재료는 팬 크기의 절반 이하로 한다

"조림 요리는 만든 뒤에 식혀 두는 시간을 갖는다"에 나오는 설명을 가져와봤다. 이 책 본문이 어떤 방식으로 서술되었는지 감이 올 것이다.

조림은 대체로 끓어오른 뒤 4~5분 정도가 되면 양념을 넣어 간을 맞춥니다. 그런데 ‘조림은 한 번 식혀 두고 난 후에 맛이 속까지 잘 배어든다’라는 말을 들어보신 적이 있을 거예요. 이것은 조림이 끓고 잇을 때에는 재료의 내부에서 수분이 증발하고, 온도가 내려가면 외부보다 내부의 압력이 낮아지기 때문입니다. 그러면 수분이 빠져나간 만큼 국물을 빨아들이기 때문에 빨리 맛이 배어드는 것이지요. 따라서 무 등의 야채를 두툼하게 썰어서 조리할 때 맛을 잘 스며들게 하고 싶으면 조린 뒤에 일단 불을 꺼서 잠시 그대로 식혀 두도록 합니다.

결론: 집에서 요리를 하는 과정에서 뭔가 부족함을 느끼는 분들께 적극 추천!

EOB

토요일, 1월 14, 2017

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

(오늘의 짤방: "When a noob or junior is given root access." via @leafriend)

마지막 마무리

EOB

토요일, 1월 07, 2017

[일상다반사] 좋은 질문을 하려면?

줄리아 에반스가 작성한 How to ask good questions라는 글을 읽다보니 독자 여러분께 소개하고픈 생각이 들어 본문 내용을 정리해봤다. 개발자로서 훌륭하게 성장하려면 질문을 잘해야 한다는 에반스의 의견에 적극 동의하는데, 비단 개발뿐만 아니라 사람들과 함께 뭔가를 해내기 위한 필수 조건이라는 생각이다.

우선 좋은 질문이 무엇일까? 대답하기 쉬운 질문이다. 당연한 듯이 들리겠지만, 어떻게 질문하느냐에 따라 완전히 상황이 바뀌기 때문에 그렇게 쉽지는 않다. 대답하기 쉬운 질문을 하기 위한 방법은 다음과 같다.

무엇을 아는지 언급하라. 지금까지 주제에 대해 연구한 바를 언급한 다음에 "제가 이해한 내용이 맞습니까?"라고 물어보자(B급 프로그래머 생각: 어떤 경우에는 질문을 위해 여러 가지 복잡한 사안을 정리하다가 답을 스스로 구하는 경우도 많다. :)).
정답이 사실인 질문을 하라. '어떻게'가 들어가면 경우의 수가 너무 많아져서 곤란하므로, 문제 범위를 좁혀서 참인지 거짓인지를 알 수 있는 질문 형태로 만드는 편이 시간을 절약할 수 있다(B급 프로그래머 생각: 조금 구체적인 질문이 좋다. 너무 범위가 넓으면 어디서부터 답을 해줘야할지 대답하는 사람도 당황스럽다).
이해하지 못하는 사실에 대해서도 기꺼이 말하라. 설명을 듣는 도중에 잘 모르는 용어나 개념이 나오면 추가로 질문을 해야 한다. 이렇게 해야 질문자의 지식 범위를 대답자가 갸늠할 수 있다.
이해하지 못하는 용어를 확인하라. X가 이런저런 내용이 맞습니까? 이런 식으로 질문하면 나중에 대답할 때 용어 이해 수준을 고려해 진행할 수 있다.
질문하기 전에 연구를 해보자. 구글 등을 검색하기 전에 무작정 질문을 던지지 마라(B급 프로그래머 생각: 대부분 구글 검색으로 해결되는 경우가 많다는 사실을 기억하자. 구글에 안 나오면 아주 어렵거나 너무 당연해서 질문이 안 나오거나 둘 중 하나일 가능성이 높다).
누구에게 질문할지를 생각하라. 적절한 질문자를 대상으로, 질문자가 대답하기 편한 시간에 맞춰, 적절한 분량의 질문을 하자.
명백하지 않음을 보여주는 질문을 하라. 고급 질문은 숨겨진 가정을 잘 드러내는 특성이 있다. 숨겨진 정보를 공유하는 방식은 상당히 효과가 있다(B급 프로그래머 생각: 아주 뻔한 질문이지만 완전히 어려운 사안으로 바뀌는 경우가 있다. 예를 들어, 엔디안을 예로 들면 x86-64 아키텍처에서는 너무나 명백한 사안이 ARM 아키텍처에서는 고민 거리를 던져준다).

훌륭한 질문이 엄청난 기여를 하는 경우도 있다. 질문하는 행위 자체에 너무 겁먹지 말자!

EOB

월요일, 1월 02, 2017

[B급 프로그래머] 코딩 실력을 개선하기 위한 확실한 방법: 코드 읽기

프로그래머라면 누구나 자신의 코딩 실력을 개선하고 싶어한다. 코딩 실력을 개선하기 위한 아주 손쉬운 방법은 없지만 노력하면 성공 가능한 방법은 존재한다. 오늘은 One Sure-Fire Way to Improve Your Coding에 나온 몇 가지 코드 읽기와 관련된 힌트를 정리해드리겠다.

코딩을 잘하려면 많이 작성해보면 된다. 이는 거의 확실한 진리지만 함정이 하나 있다. 엉터리로 코드 수 만 줄을 작성해봐야 소용이 없으며, 오히려 제대로 된 코드 수 천 줄을 작성하는 편이 훨씬 바람직하다. 제대로 된 코드를 만들려면? 답은 간단하다. 남이 만든 제대로 된 코드를 많이 읽어보면 된다. 그러면 코드를 읽기 위한 힌트가 없을까? 제로드 산토는 다음과 같은 방법을 제시한다(추가로 괄호 안에 B급 프로그래머의 경험을 추가했으므로 참고하기 바란다).

무엇을 읽을까?
1. 여러분이 의존하는 코드를 읽어라: 이미 사용 중인 라이브러리나 플러그인으로 시작하자. 예로 워드프레스 플러그인, 루비 젬, jQuery 플러그인을 고려해보자.
2. 감명 깊은 소프트웨어 코드를 읽어라: 오픈소스 프로젝트 중에서 아키텍처가 잘 잡혀 있고 문서화가 잘 된 코드부터 시작하면 된다(B급 프로그래머: 스프링 소스 코드 일부를 읽어보고 사용자(개발자!)를 배려하는 치밀함에 정말 놀란 적이 있다.
3. 존경하는 사람이 만든 소프트웨어 코드를 읽어라: 오픈소스를 이끄는 사람 중에서 존경하는 개발자가 있다면 거기서 출발하자(B급 프로그래머: 클린코드에서 작성한 로버트 C. 마틴이 작성한 코드 사례를 추천한다).
4. 실제 다룰 수 있는 코드를 읽어라: 처음부터 너무 욕심내어 대규모 프로젝트를 구성하는 코드를 읽으면 혼란에 빠진다. 전체 논리를 한 번에 머리에 넣을 수 있는 작은 프로젝트부터 읽어보자(B급 프로그래머: 되도록 초기 버전을 권장한다. 버전이 올라갈수록 복잡도는 기하급수적으로 증가하기 때문이다. 피보탈에서 만든 Cloud Foundry도 초기 버전은 정말 읽고 이해할만 했다. 이 코드 덕분에 루비 실전 기술을 몇 가지 배웠다.).
어떻게 읽을까?
1. 큰 그림을 보자: 개별 단위 함수부터 파고드는 대신 웹 사이트, 튜토리얼, 문서, 코드 이외 다른 참고 자료부터 살펴보자. 프로젝트 구조 파악이 우선이다. 코드 계층 구조를 파악하고 어떤 코드가 어떤 코드를 import 하는지, namespace는 어떻게 명명되어 있는지를 살펴보자(B급 프로그래머: 코드 내부에서 함수는 헤더 파일에 대한 교차 참조를 걸어주는 여러 가지 도구를 사용하면 시간을 절약할 수 있다).
2. 찾아낸 사실을 문서로 만들자: 코드 읽기는 수동적인 활동이 아니다. 찾아낸 사실을 문서로 만들고 프로그램 흐름에 맞춰 가정과 결론을 나중에 찾아볼 수 있게 주석으로 달아놓자.
3. 테스트를 사용하라 루크!: 아마도 테스트 코드가 프로젝트 내에 포함되어 있을 것이다. 테스트는 출발점으로 아주 좋다. 코드가 어떻게 동작하고 어떤 가정을 내포하는지를 설명하기 때문이다. 실제로 코드 읽기에 앞서 테스트를 돌려서 환경이 제대로 구성되어 있는지 확인할 필요가 있다(B급 프로그래머: 테스트에 앞서 일단 빌드부터 성공해야 한다. 컴파일 언어에 대한 환경 구성이 확실히 어렵긴 하지만 스크립트 언어인 경우에도 의존성 맞추느라 고생할 가능성이 상당히 높다. 충격에 대비하라!).
4. 실행하고, 변경하고, 다시 실행하자: 일단 모든 것을 분해했다 다시 조립하면서 이해도를 높이자. 정말 멋진 기능을 하나 추가해서 테스트가 통과하는지 살펴보자. 다양한 코드 상태를 확인할 수 있게 로그 수준을 높여보자(B급 프로그래머: 이 과정에서 디버거를 사용해 흥미로운 부분에 중단점을 걸어 내부 상태를 파악하기도 한다).
어디서 시작할까? 깃허브와 같은 공개 소스코드 저장소에서 출발하자. git clone 만으로 손쉽게 코드를 복제해서 시작할 수 있다.

EOB

토요일, 12월 31, 2016

[B급 프로그래머] 12월 4주 소식 정리

2016년도 한 해 동안 블로그를 사랑해주신 애독자 여러분들께 다시 한 번 감사 말씀드린다. 올해 마지막 소식(TL;DR) 정리하면서 새해 인사 드리겠다. 2017년도는 모든 분들께서 행복하게 지낼 수 있기를...

(오늘의 짤방: “All that beautiful hardware suspended in the void” via @shdyun)

(리눅스 성능 60초만에 파악하기 via ‏@vanadium23) EOB

토요일, 12월 24, 2016

[독서광] 스타일과 목적을 살리는 웹글쓰기

개인적으로 블로그를 운영하는 경우는 물론이고 회사에서 전담으로 블로그를 운영하거나 서비스 페이지를 만들고 내용을 구성하는 경우에 늘 부딪히는 문제는 사용자 경험을 극대화하며 스토리가 풍부한 웹페이지 동선 구성과 콘텐츠 제작이다. 온라인으로 연결된 특성으로 인해 전파력과 상호대화성이 높기 때문에 고려해야 할 사항이 많지만 늘 뭔가 부족하다는 아쉬움을 느끼기 마련이다. 오늘 소개할 책은 웹(홈페이지, 블로그, 이메일, 전자상거리 서비스 페이지)에서 어떻게 하면 효과적으로 콘텐츠를 작성할 수 있는지를 알려주는 '웹글쓰기'이다.

본격적인 책 소개에 들어가기 전에 제목이 오해를 불러일으킬 소지가 있다는 점부터 짚고 넘어가겠다. 제목만 보면 시중에 흔히 나와 있는 작문서를 연상하기 마련이다. 특정 주제를 제시한 다음에 어떤 식으로 효과적으로 글을 쓰는지 다루는 책 말이다. 하지만 이 책은 조금 다른 접근 방법을 택한다. 바로 고객/독자와 의사소통 과정에서 어떻게 마케팅 문구, 블로그, 이메일, 오류 메시지, 법률 조항 등을 제대로 기획하고 만들어내느냐에 초점을 맞춘다.

본문 내용 중에서 특히 흥미로웠던 부분은 자신만의 보이스 찾고 톤을 조정하는 원칙이다. 본문에 나오는 내용을 일부 가져오겠다.

사람들은 흔히 보이스와 톤을 같은 의미로 사용하지만 엄밀하게 말하면 둘은 다르다. 보이스는 바로 그 기업의 공공 개성이며 때에 따라 크게 달라지지 않는다. 개인이 지닌 인격과 마찬가지로 조직의 개성인 보이스는 모든 콘텐츠에서 스며 나오며 기업에 대한 인상을 좌우한다. 반면, 톤은 상황에 따라 바뀔 수 있다. 보이스는 웹에 글을 쓰는 여러분이나 여러분이 속한 기업과 관련이 깊지만 톤은 고객이나 고객이 느끼는 감정과 밀접한 연관이 있다. 보이스와 톤이 하나가 되어 글의 스타일을 완성한다.

보이스를 찾아 톤을 적용해 글을 쓴다는 원칙만 제대로 적용해도 생생하면서도 상황에 맞는 컨텐츠 제작이 가능하다. 이 책은 분량이 얇음에도 불구하고 이런 핵심을 잘 짚어준다. 다음으로 흥미로웠던 부분은 언뜻 보기에는 글 쓰기와 무관한 듯이 느껴지는 플로우 만들기다. 플로우는 사용자가 동작을 하나씩 행하면서 거쳐 가는 일련의 화면을 말하는데, UX에 관심이 많은 분이라면 UX와 글쓰기를 어떻게 잘 연결할지에 대한 고민을 해봤을 것이다. 다시 한번 본문에 나오는 내용을 일부 가져오겠다.

웹 사이트는 사용자에게 사적인 질문을 던지고 시간을 어떻게 활용할지 알려주며, 사이트를 이리저리 돌아보는 사람에겐 구체적인 방향을 제시해준다. 또한 친절하고 신중한 태도로 고객이 현명한 결정을 내리도록 도와야 한다. 플로우란 명확한 목표를 향해 순조롭게 진행하는 것이며 웹 라이터는 고객이 그 플로우를 탈 수 있도록 도와주는 역할을 해야 한다.

조금 더 명확해졌다. 보이스를 찾고 톤을 적용해 플로우에 맞는 글을 쓰면 고객/독자의 만족도를 높일 수 있다!

결론: 웹에서 글을 제대로 쓰고 싶은 분들께 이 책을 추천한다.

EOB

토요일, 12월 17, 2016

[B급 프로그래머] 12월 2주 소식 정리

오늘의 짤방: 파채 썰기 (via @BT_ol207)

EOB

토요일, 12월 10, 2016

[B급 프로그래머] 12월 1주 소식 정리

(오늘의 짤방: 직원들의 몰입과 상사와의 관계 via @bluepygmi)

EOB

토요일, 12월 03, 2016

[B급 프로그래머] DigitalOcean vs Amazon LightSail

이번 AWS re:ivent 행사에 소리소문없이 갑자기 등장한 서비스가 하나 있다. 바로 AWS의 VPC(가상 사설 호스팅) 서비스인 LightSail이다. 그런데 LightSail 홈페이지에 들어가자 마자 기시감이 느껴졌는데, 다름 아닌 평소에 잘 사용하고 있던 DigitalOcean이 떠올랐다.

개발자 전용 서비스를 표방한 디지털오션이 갑자기 만족도를 확인하는 사용자 설문조사 이메일을 보내왔는데, 그만큼 경쟁자 출현에 긴장하고 있다고 봐도 틀림이 없겠다. 두 서비스는 너무나도 비슷해서 치열한 경쟁이 필연적일 수 밖에 없는 상황이다. 특히 가격대를 한번 비교해보자(위: 라이트세일, 아래: 디지털오션).

아직 디지털오션이 일부 가격대에서 더 좋은 서비스를 제공하고 있긴 하지만 AWS 특성상 조만간 가격 인하 또는 성능 개선이 이뤄질 것 같다. 물론 디지털오션이 훨씬 더 큰 사양(최대로 1달에 1680불이면 224GB 메모리/32코어/500G SSD/10T 네트워크 전송 가능)까지 서비스하고 있고, 서비스 지역도 다양하므로 아직 북미 버지니아 리전에서만 서비스하는 라이트세일에 비해 우위에 있긴 하다.

가격 이외에 여러 가지 기능적인 측면을 살펴보면 디지털오션이 앞서있다. 추가 SSD 블록 스토리지 구매도 가능하고 지원하는 애플리케이션 유형도 훨씬 더 많고 네트워크 지원도 더 좋고 팀 지원도 뛰어나다. 하지만 AWS 정식 서비스 중에서 점차 라이트세일에 포함되는 범위가 넓어지게 된다면 디지털오션도 결코 방심하기 어렵다는 생각이 든다. 라이트세일은 VPC 피어링을 통해 AWS 서비스에 접근할 수 있는 통로를 열어 뒀기 때문에 완전 통합은 아니지만 AWS 서비스와 연결 고리는 이미 만들어진 셈이다. 그리고 AWS 계정으로 라이트세일에도 접근 가능하다는 장점도 무시할 수 없다. 반면에 디지털오션이 AWS에 비해 확실히 우위를 점하는 분야는 커뮤니티다. 상당히 오랜 기간 동안 개발자 친화적으로 이미지를 쌓아왔으며, 1500여 개에 이르는 다양한 튜토리얼이 개발자에게 많은 도움을 주고 있다.

강력한 경쟁자가 등장한 만큼 앞으로 개발자를 사로잡기 위한 불꽃튀는 전투가 예상된다. 이 와중에서 누가 살아남을지 정말 궁금해진다.

팁 하나 더!: 2시간 정도 짧게 무료(!)로 서버를 대여하고 싶다면 dply도 고려해보기 바란다.

EOB