코딩 호러의 이야기, 그리고 한국 오픈소스 개발자들 이야기

 

코딩 호러의 이펙티브 프로그래밍

 

지은이: 제프 앳우드

옮긴이: 임백준

출판사: 위키북스

출판일: 2013-03-29

 

스택오버플러우 개발자로 유명한 제프 앳우드의 블로그에 있는 글을 책으로 정리했다.

제프 앳우드는 평범하지 않고, 괴상하며, 불친절하고, 타인의 마음엔 신경 쓰지 않는 전형적인 개발자스러움을 보여준다. 그러면서도 사용자의 이야기에 집중하라고 하고, 인간 관계가 중요하다고 하고, 인문학적인 소양을 키우기 원하며, 글 작성하는 방법을 익혀야 한다고 하는 등 한때 유행했던 자기개발서적류의 주장을 펼치는 복합적인 인물이다.

개발자들과 개발 조직에 생생한 느낌을 주는 글도 있고, 좀 시간이 지나서 이제는 식상해진 이야기도 있지만, 전체적으로 블로그 글에, 에세이식으로 편하게 가벼운 마음으로 읽어 보길 권한다.

 

* 프로그래머 8단계 : 죽은 프로그래머, 성공적인 프로그래머, 유명한 프로그래머, 일하는 프로그래머, 평균적인 프로그래머, 아마추어 프로그래머, 알려지지 않은 프로그래머, 나쁜 프로그래머

 

... 일하는, 평균적인, 알려지지 않은 까지... 단계가 너무 많잖아. 유명한 까지는 아니어도 평균 이상은 하고 싶은데 이래서는 평균 혹은 알려지지 않은 프로그래머에 만족해야 할 듯하다ㅡㅡ

 

* 그저 그런 그룹에게 좋은 아이디어를 제공하면 그들은 아이디어를 망쳐버릴 것이다. 하지만 훌륭한 그룹에게 그저 그런 아이디어를 제공하면 그들은 아이디어를 멋진 무엇으로 구현할 것이다. 혹은 그저 그런 아이디어를 밖으로 내던지고 뭔가 다른 것을 만들어 낼 것이다.

 

* 엘리베이터 테스트를 통과하기 위한 프로젝트 비전 모델 : (핵심 고객을) 위해, 누구 (필요성 혹은 기회에 대한 설명), (제품명)은 (제품 카테고리)에 속한다, 그것(핵심 이익, 구입해야 하는 설득력 있는 이유), (주요 경쟁 업체와) 다른 점, 우리의 제품(핵심적인 차이에 대한 설명)

 

* 우리는 어떤 방식으로 도움을 얻길 원하는가? 나는 동정을 받는 듯이 도움을 받을 마음이 없다. 어떤 이기적인 동기에 의해 도움을 받고 싶은 마음도 없다. 이러한 상황에서 도움을 주는 사람은 하나의 인간으로서 나에게 아무런 관심이 없기 때문이다. 내가 다른 사람이 나에게 가졌으면 하고 바라는 태도는 나를 사랑하는 것이다. 물론 로맨틱한 사랑을 말하는 것이 아니라, 다른 인간에 대한 보편적인 사랑을 의미하는 것이다.

 

* 썩은 사과의 효과가 놀랄 정도로 강력하다는 사실을 보여주는 사회학적 실험을 수행한 월 펠프스 교수. 썩은 사과를 포함한 그룹은 사람들이 서로 논쟁을 벌이고, 싸우고, 서로의 정보를 공유하지 않았으며, 의사소통의 양도 더 적었다. 더 나쁜 것은 다른 팀원들이 썩은 사과의 성격을 따라서 행동하기 시작했다는 점이다. ... 최악의 팀원을 살펴보는 것은 해당 팀이 어느 정도의 성적을 거둘 것인가에 대한 최고의 척도가 된다는 사실이다.

 

* 우리는 때로 AWS 안에 존재하는 네플릭스 소프트웨어 아키텍처를 우리의 람보 아키텍처라고 불렀다. DVD를 추천하는 시스템이 다운되며, 우리가 고객에게 제공하는 응답의 질은 낮아지겠지만 여전히 전체적인 서비스는 계속 응답한다. 우리의 엔지니어들이 AWS에서 구축한 첫 번째 시스템은 무질서한 원숭이Chaos Monkey라고 불리는 시스템이다. 무질서한 원숭이의 역할은 우리의 아키텍처 내에 존재하는 서비스 인스턴스를 무작위로 다운시키는 것이다.

 

* 사용성 테스트 : 한달에 한번 정도. 최대 3명이나 4명. 컴퓨터를 사용할 수 있는 사람이라면 아무나. 사용자 한 사람 당 45분에서 1시간 정도가 적당하다. 간결함을 유지하고, 범위를 작게 유지해라. 테스트는 사무실이나 회의실, 방해가 없는 방 아무 곳에서나 가능하다. 단지 어느 정도 참을성이 있고, 차분하며, 열정적이고, 남의 말을 잘 경청하는 사람이 좋다. 참여자가 테스트 과정동안 참조할 수 있는 짧은 스크립트를 준비하라. 결과의 해석은 같은 날 점심시간에 개발 팀과 다른 관심 있는 사람들에게 설명한다.

 

* 누군가를 몰래 정지시키는 방법 : 완전금지(드루팔 케이브), 느린금지, 에러금지(드루팔 미저리)

 

코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기

 

지은이: 제프 앳우드

옮긴이: 임백준

출판사: 위키북스

출판일: 2013-11-28

 

* 나는 마치 정신 나간 저장강박증 환자처럼 완료되지 않은 업무가 산처럼 쌓여가는 근본적인 원인을 착각한다. 저장강박증 환자는 언제나 물건을 보관할 장소가 부족한 것이 문제라고 느낀다. 사실은 물건을 '버리지 못하는 것'이 문제인데 말이다. 나는 나에게 주어진 하루 24시간이라는 시간이 너무 부족하다는 타임푸어 현상을 고민한다.

 

* 진정으로 더 나은 프로그래머가 되고 싶다면 프로그래밍 주변에 있는 다른 모든 것들에 열정을 쏟아야 한다.

 

* 그래서 어쩌면 우리는 어쩔 수 없이 아주 사소한 일에도 목숨을 걸 수밖에 없는 존재일 것이다.

 

* 그렇기 때문에 혹시라도 어느 프로그래머가 업계를 떠나는 것을 고려한다는 말을 농담이라도 입 밖에 낸다면 아마도 그는 업계를 떠나는 것이 여러 사람에게 도움이 되는 사람일 것이다. 그렇다고 해서 진로를 놓고 고민하는 사람에게 못되게 굴어도 좋다는 것은 아니다.

 

* 인터넷이 출현하기 이전의 초창기 컴퓨터 세계는 고독한 행위 그 자체였다. M.U.L.E의 저자인 대니 베리는 다음과 같은 유명한 인용구를 남겼다. "죽음을 맞이하면서 '세상에, 컴퓨터를 더 많이 이용했어야 했는데.'라고 말하는 사람은 없다." ... 프로그래밍을 진지하게 생각한다면 반드시 다른 동료와 함께 일하는 환경을 고집해야만 한다.

 

* 코드를 체크인하기 전에 동료가 코드를 간단하게나마 검토할 수 있게 하라. 코드의 내용을 설명할 수 있겠는가? 코드가 제대로 작성됐는가? 깜빡 잊은 것은 없는가?

 

* 웹 사이트의 첫 페이지가 어마어마하게 매력적이어야 한다는 사실이다. ... 어쩌면 사용자가 보는 것은 바로 그 첫 페이지에 국한될 수도 있기 때문이다.

- 페이지가 상당히 빠르게 로드돼야 한다.

- 애플리케이션이 해결하고 있는 문제가 무엇이고, 다른 사람들이 왜 그러한 문제에 신경을 써야 하는지 정확하게 설명하는 것이다. 첫 페이지에서는 일종의 엘리베이터 토크가 필요한 것이다.

- 구체적인 예를 제시한다.

- 장애물이 없는 명확한 동작이 가능하게 하라.

- 일부 사용자를 포기하는 것을 의미할지라도 자신에게 진짜로 의미 있는 사용자를 놓치지 않도록 노력하라.

 

* 그런 기능을 모두 더하는 것은 별로 아름답지 않습니다. 혁신이라는 것은 모든 것에 대해 '예'라고 대답하는 것이 아닙니다. 가장 결정적인 기능을 제외한 나머지 모두에 대해 '아니오'라고 대답하는 것이 혁신입니다.

 

* 유연성이 확장되는 것은 그들이 실수를 저지르거나 해서 검색이 실패할 확률을 낮춰주는 것이 아니라 오히려 높인다. 그들은 자신이 수행할 일을 더 단순하게 만들 수만 있다면 불필요한 복잡성, 통제, 그리고 동작 방식에 대한 이해를 기꺼이 포기할 준비가 돼 있다. ... 호모로지쿠스는 사물이 어떻게 동작하는가를 알고 싶어 하는 참을 수 없는 욕망을 느낀다. 이와 반대로 호모사피엔스는 성공을 위한 강력한 욕망을 느낀다. 프로그래머도 성공을 원하긴 하지만 그들은 이해라는 성취를 위해 실패라는 비용을 지불하는 것을 받아들인다.

 

* 사람들은 '오직 자기 엄마만 읽을' 블로그를 작성하는 사람을 조롱한다. 하지만 아무도 실행하지 않을 코드를 작성하는 수많은 프로그래머는 어떤가?

 

* 사용자들이 할 거라고 말하는 것과 그들이 실제로 하는 일은 완전히 다른 두 개의 존재다. 그렇기 때문에 사용성이라는 관점에서 봤을 때 사용자에게 직접 필요한 것을 묻는 것은 거의 아무런 의미가 없다. 대신 그들이 실제로 하는 행동을 관찰해야 한다. 사용성 테스트는 바로 그것을 의미한다. ... 묻지 않고 관찰하는 것이다.

 

꾸준히, 자유롭게, 즐겁게 - 한국 오픈 소스 개발자들 이야기

 

지은지: 송우일

출판사 : 인사이트

출판일 : 2013-10-10

한국의 오픈소스 생태계가 척박하고, 글로벌하게 기여하는 문화가 없다는 지적이 많다고 생각하는 한편, 어떻게 오픈소스 개발을 시작하고, 꾸준하게 기여할 수 있는지는 잘 모르겠다.

 

이 책은 한국에서 오픈소스 개발을 진행하고 있는 분들의 인터뷰 모음집이다.

읽기 전에는 한국에서 오픈소스 개발자가 된다는 것은 어떤 의미일까? 어떻게 시작하게 되었을까? 왜 포기하지 않고 꾸준하게 할까?하는 등의 의문이 생겼다.

다 읽고 난 후에도 깔끔하게 이해가 되진 않는다. 여전히 왜 하는지 잘 모르겠고, 나와는 먼 이야기기라고 생각이 되고, 실제로 발을 담그기가 주저된다.

 

그래도 제목처럼 꾸준히, 자유롭게, 즐겁게 오픈소스 개발을 하고 있는 여러~분들의 생생한 이야기를 들을 수 있어 좋다.

 

* 공개 후 유지 보수할 수 있는지 검토해 봐야 합니다. 그냥 소스만 공개해 놓고 내버려두면 추진력을 얻기가 쉽지 않거든요. 소스를 공개해서 회사도, 자신도 이득을 얻고 사용자도 혜택을 받으려면 최소한 프로젝트가 특정 궤도에 오르기까지 잘 관리해야 하고 또 크게 발전할 수 있도록 회사 외부 사람이 기여하더라도 차별 같은 게 없어야 합니다. ... 그렇게 하지 않고 소스만 공개하고 말면 이미지만 나빠질 수도 있습니다.