[Book] 실용주의 프로그래머 정리 - 01

 구매한 지 조금 시간이 지난 책을 요즘 읽고 있습니다. 실용주의 프로그래머라는 책입니다. 이전에도 읽어보려 했는데 읽을수록 어렵다는 느낌이 들어 읽는 것을 멈추었습니다. 하지만 지금은 읽어도 좋을 것 같다는 느낌이 들어 읽기 시작했습니다. 책을 읽으며 내용을 복습할 겸 정리해보고자 합니다.

 

실용주의 프로그래머 - 교보문고

0장 서문

  서문에서도 좋은 부분이 있었습니다. 실용주의 프로그래머가 되려면 자신의 기술에 관심과 애정을 가지고 자신이 무슨 일을 하고 있는지 생각을 하면서 일을 해야 한다고 하였습니다. 또 사람의 성장 방식에 있어서 '카이젠'이라는 단어로 표현하기도 하는데, '카이젠'은 일본말로 지속적으로 조금씩 자주 개량하는 방식을 뜻한다고 합니다. 한 번에 무언가를 많이 하려고 하기보다 매일 조금씩이라도 현재의 기술을 발전시키고, 새로운 기술을 익힌다면 시간이 흘러 긍정적으로 변화한 자신을 발견할 수 있을 것이라고 이야기하고 있습니다.

1장 실용주의 철학

1. 고양이가 내 소스코드를 삼켰어요

  책임에 관한 이야기를 합니다. 무언가 일을 맡게 되었고 자신이 책임을 지고 일진행하고 있다면 무슨 일이 발생하더라도 회피하지 말고 책임을 져야 한다는 것입니다. 어떠한 일이 발생하여 일에 차질이 생겼을 때 이에 대한 어설픈 변명을 하기보다는 그에 대한 방안을 준비해서 솔직하게 제시를 하는 것이 좋다고 이야기합니다.

 

2. 소프트웨어 엔트로피

  엔트로피는 물리학 용어로 무질서한 정도를 나타냅니다. 또 물리학에 따르면 엔트로피는 시간이 흐름에 따라 증가하는 현상을 보이는데 우리가 진행하는 프로젝트도 아무런 대책이 없이 그대로 둔다면 계속해서 증가해 나갈 것(무질서 해짐)입니다.

  대체로 이렇게 무질서 해지는 프로젝트에 대해서 '깨진 창문 이론'을 예로 들어서 설명합니다. '깨진 창문 이론' 이란 멀쩡한 집은 계속해서 멀쩡하지만 깨진 창문이 있는 집은 다른 사람들로 하여금 아무에게도 관심을 받지 못하는 느낌을 주게 되어 다른 창문도 깨지고, 집 안의 물건을 어지르고 벽에 낙서를 하는 등 다른 사람들도 막대하게 되는 현상을 말합니다.

  코드도 마찬가지입니다. 진행하는 프로젝트에서 '깨진 창문'(나쁜 설계, 잘못된 결정, 형편없는 코드)을 발견한다면 바로바로 조치를 취해야 합니다. 바로 고칠 시간이 충분하지 않다면 예비 데이터를 넣어 놓거나 주석처리를 하는 등 현재 이 문제에 대해서 파악하고 있으며 조치를 취할 것 임을 알려주어야 합니다. 만약 다른 사람들과 함께 하는 프로젝트가 이처럼 깨끗한 상태를 유지하고 있다면 어떠한 사람도 자신이 먼저 이 프로젝트를 망치는 장본인이 되지 않기 위해서 주의를 기울인 작업을 할 확률이 늘어날 수 있습니다.

 

3. 돌멩이 수프와 삶은 개구리

  이번 소분류에서는 하나의 이야기로 시작을 합니다.

전쟁을 겪은 군인들이 집에 돌아가는 길에 들른 마을에서 음식을 구하고 싶었습니다.
하나 가난한 마을 사람들은 이들에게 흔쾌히 내줄 만큼의 식량을 가지고 있지 않았기에 문을 걸어 잠그고 집에 들어갔습니다. 이 군인들은 이에 여의치 않고 마을 한구석에 자리를 잡고 냄비에 물을 끓인 뒤 돌멩이를 몇 개 집어넣었습니다. 몰래 이를 지켜보던 마을 사람들 중 한 명이 궁금증에 다가와 질문했습니다.
"왜 돌멩이를 물에 넣었지요? 그것만 집어넣는 것인가요?"
그러자 군인 한 명이 말했습니다.
"당연하지요. 뭐 어떤 이들은 당근을 몇 개 집어넣으면 더 맛있다고들 하지만요."
그러자 이야기를 듣게 된 마을 사람이 당근을 몇 개 가져왔습니다. 그리고는 말했습니다.
"그럼 된 건가요?"
그러자 군인 한 명이 말했습니다.
"흠, 감자를 몇 개 더 넣으면 알맹이가 더 생기는 셈이죠."
그러자 또 마을 사람들 중 한 명이 어디론가 달려가 감자를 가져왔습니다. 시간이 흘러 이 자리에는 수많은 요리 재료들이 자리 잡았고, 군인들과 마을 사람들은 함께 둘러앉아 맛있는 수프를 먹게 되었습니다.

  이 이야기는 어떠한 교훈을 줍니다. 어떠한 일을 기획하고 이 일이 분명히 필요한 일이라는 것을 알고 있는 상황이 있습니다. 그러나 이 일을 시작하려면 주변 사람들의 동의를 구해야 하고 예산을 승인받아야 하는 등 시작 단계에서 어려움이 생길 수 있습니다. 그럴 때 위의 이야기처럼 돌멩이를 꺼내야 합니다. 다른 사람들이 무리 없이 허용할 수 있는 것을 찾아내고 그것을 가지고 남들이 보기에 괜찮은 만큼의 결과물을 낸 뒤 조금씩 그들에게 요청을 하는 것입니다. 그리고 또 새로운 성공을 통해 더 좋은 결과물을 보여주는 것 입니다. 그러케 점차 점차 진행되다보면 계속되는 성공에 남들은 합류를 결정하는 것이 쉬워 질 것 입니다.

 

  그리고 이와 유사한 이야기로 삶은 개구리 이야기가 있습니다. 개구리를 먹기 위해 끓는 물에 바로 넣으면 놀란 개구리는 튀어나오겠지만, 개구리를 차가운 물에 넣고 서서히 끓여간다면 개구리는 변화를 감지하지 못하고 그대로 있다가 삶아질 것이라는 이야기입니다. 돌멩이 수프의 이야기도 서서히 변화한다는 의미가 있지만 긍정적인 방향으로의 변화이고 개구리 이야기는 서서히 변화하지만 나쁜 방향으로의 변화입니다. 저희는 무슨 일을 진행함에 있어서 변화의 방향이 좋은 방향인지 나쁜 방향인지 항상 객관적인 시점에서 바라보며 주의를 해야 할 것입니다.

 

4. 적당히 괜찮은 소프트 웨어

  우리는 소프트웨어를 만들지만 완벽한 소프트웨어를 만들기는 불가능에 가깝습니다. 그러나 어떤 사람들은 완벽한 소프트웨어가 될 때까지 노력을 하며 이로 인해 시간과 피로를 불러냅니다. 그러나 그것은 우리를 꼭 낙담케 하지많은 않습니다.

  에드워드 요든은 위의 행동으로 인해 '적당히 괜찮은' 소프트웨어를 만들도록 단련할 수 있다고 말합니다. 단련을 통해서 자신은 더 생산적이 되며 사용자는 더 행복해할 것입니다. 여기서 '적당히 괜찮은'이라는 뜻은 너절하거나 형편없는 코드를 의미하지 않습니다. 코드는 사용자의 요구사항을 충족해야만 하기 때문입니다. 다만 우리가 생산해 낸 것이 어느 정도면 적당히 괜찮은지 결정하는 과정에 사용자가 참가할 기회를 가져야 한다는 것을 의미합니다.

  대다수의 사람들은 내년에나 완성될 수 있는 완벽한 프로그램보다 지금 당장 사용할 수 있는 조금 불편한 프로그램을 사용할 것입니다. 이처럼 사용자들에게 직접 만져볼 수 있는 것을 일찍 주고 피드백을 듣는다면 종국에는 더 나은 설루션에 도달할 수 있을 것입니다. 

 

5. 지식 포트폴리오

  지식과 경험은 매우 중요한 자산입니다. 그러나 현재 시대에는 이 지식들은 불행하지만 소진하는 자산입니다. 지금 이 순간에도 새로운 기술, 언어, 환경이 개발되고 우리가 가지고 있는 지식은 옛것이 됩니다. 우리는 금융 관련 포트폴리오를 관리하는 것과 같이 우리의 지식을 포트폴리오처럼 관리해야 합니다.

 

  - 주기적인 투자 : 지식에 주기적인 투자를 해야 합니다. 비록 소량일지라도 지식에 투자하는 습관 자체가 금액의 합계만큼이나 중요합니다.

 

  - 다각화 : 여러 가지 기술을 알아야 합니다. 기본적으로 현재 작업에 사용하는 특정 기술의 등장과 퇴장은 알아야 합니다. 또 거기서 멈추지 말고 새로운 기술을 찾아 공부하며 변화에 잘 적응할 수 있는 힘을 길러야 합니다.

 

  - 리스크 관리 : 언제 무너질지 모를 위험한 주식에 모든 돈을 투자하는 것처럼 하나의 기술만에 의지해서는 안됩니다.

 

  - 싸게 사서 비싸게 팔기 : 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 것은 저평가된 주식을 찾는 것만큼이나 어렵습니다. 그러나 자바가 처음 나왔을 때 학습한 사람들은 나름대로의 리스크가 있었겠지만 지금은 큰 이득을 얻어 그 분야의 꼭대기에 있습니다.

 

  - 검토 및 재조정 : 이 산업은 매우 동적입니다. 매우 인기 있는 새로 나온 기술이라도 금방 식어버릴 수 있으며 한동안 사용하지 않았던 기술을 복습해야 할 일이 생길 수도 있습니다. 새로운 기술과 지나간 기술에 모두 관심을 가지고 있어야 합니다.

 

  현재 시대는 새로운 기술을 공부하기 매우 좋은 시대입니다. 모르는 문제가 생기면 인터넷을 통해 찾고, 질문하고 답을 얻을 수 있습니다. 끊임없이 새로운 기술을 찾아내고 배워야 합니다. 그러나 배우기 위해서 읽고 듣는 것들에 대해서 비판적으로 생각할 수 있어야 합니다. 인터넷 검색을 통해 가장 위에 나타난다고 해서 꼭 옳은 정보일 것이라는 믿음을 가져서는 안 됩니다. 다양한 정보를 통해 비판적으로 받아들여 정확한 정보를 알아볼 수 있는 능력을 키워야 합니다.

 

6. 소통하라

  개발자는 여러 층과 소통해야 합니다. 최종 사용자의 요구를 이해하려고 노력해야 하며, 코드를 작성해서 기계에 우리의 의도를 전달해야 하기도 하고, 우리의 생각을 문서화해서 다른 개발자들에게 전달하기도 해야 합니다. 제안서와 메모를 작성하여 자원을 요청하기도 해야 하고 프로젝트의 상태를 보고하고, 새로운 접근법을 제시하기도 해야합니다. 이 처럼 다양한 소통의 상황을 겪게 되는데 이에 유용한 아이디어 목록을 모아 보았습니다.

 

- 말하고 싶은 게 무엇인지 알아라

  무엇을 말하고 싶은지 미리 계획하고 개요를 작성해보면 좋습니다. 그리고 자문하여 이것이 내가 말하고자 하는 것을 잘 전달하는지 느껴질 때까지 다듬어볼 수 있습니다.

 

- 청중을 알아라

  어떠한 사람이 이야기를 듣게 되는지에 따라서 설명하는 정도와 단어 선택이 달라질 수 있습니다. 청중에 따라 다른 이야기를 준비해야 합니다.

 

- 때를 골라라

  말하는 내용도 중요하지만 어떤 상황과 시간에 말을 하는지도 중요할 수 있습니다. 말하는 시간이 대해서 이 이야기를 하기에 적절한 때인지 한번쯤 생각해 보는 것이 좋습니다.

 

- 스타일을 골라라

  전달하는 스타일(방식)이 청중에게 어울리도록 하는 것이 좋습니다. 짧고 간략한 정리된 브리핑을 좋아하는 사람이 있을 수 있고, 보고서 형식의 문서를 좋아하는 사람이 있을 수도 있습니다. 또 어떤 사람은 간단한 메모나 이메일을 통해서 받기를 좋아하는 사람일 수도 있습니다. 어떠한 방식이 좋을지 모르겠다면 청자에게 물어보는 것도 좋습니다.

  다만 의사소통의 나머지 반쪽은 본인입니다. 청자가 간결하게 설명을 원하더라도 그 설명을 대여섯 장의 문서 이하로 줄일 수 없겠다면 사실이 그렇다고 설명하는 것이 좋습니다.

 

- 멋져 보이게 하라

  아이디어를 표현하고 싶은데 이를 위해서는 멋진 매개물이 필요합니다. 만약 아이디어를 전달한다고 하는데 메모장에 적어 놓은 텍스트 만을 보내면 이 아이디어 자체가 형편없어 보일 수도 있습니다. 현대의 워드 프로세서는 눈부신 출력물을 만들어 낼 수 있습니다. 필요한 몇 개의 명령어라도 학습하여 스타일을 꾸며보는 것이 좋습니다.

 

- 청중을 참여시켜라

  우리가 만드는 문서에 가능하다면 독자를 참여시키는 것이 좋은 방법입니다. 그들에게 의견을 묻고 피드백을 받는 등 그들도 이 문서에 참여하도록 하면 그들과 더 좋은 관계를 형성하게 될 수도 있고 더 나은 문서를 만들 수 있게 될 것입니다.

 

- 청자가 되어라

  다른 이들이 본인의 말을 경청해주길 바란다면 본인이 먼저 경청하는 것은 아주 중요한 자세입니다. 또 질문을 통해 사람들이 이야기를 즐길 수 있도록 북돋아 주는 것도 효과적인 대화의 방법입니다.

 

- 응답하라

  누군가에게 질문을 했는데 아무런 응답도 듣지 못한다면 그가 무례하다고 느끼게 될 것입니다. 마찬가지로 본인에게 요청 온 메일이나 메모에 바쁘더라도 '메일을 확인했으며 다음에 대답해 드리겠습니다.'라는 응답이라도 하는 것이 좋습니다.