TOC
- 참고
- Topic 1 : 당신의 인생이다
- Topic 2 : 고양이가 내 소스 코드를 삼켰어요
- Topic 3 : 소프트웨어 엔트로피
- Topic 4 : 돌맹이 수프와 삶은 개구리
- Topic 5 : 적당히 괜찮은 소프트웨어
- Topic 6 : 지식 포트폴리오
- Topic 7 : 소통하라!
- 총평
참고
본 내용은 실용주의 프로그래머 를 읽고 정리한 내용입니다. 책의 내용과 함께 개인적인 의견과 생각을 담아 작성하였습니다.
Topic 1 : 당신의 인생이다
스스로의 행동을 직접 결정하라. 업무 환경이 엉망이라면? 하는 일이 지루하거나 불만족스럽다면? 문제를 고치기 위해 노력하라. 하지만 오래 노력해도 안 된다면 내 환경을 바꾼다. "당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다." 업계는 놀랄만큼 다양한 기회를 제공한다. 주도적으로 행동해서 기회를 잡아라.
Topic 2 : 고양이가 내 소스 코드를 삼켰어요
실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다. 우리는 정직하고 솔직해져야 한다. 자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점도 인정해야 한다.
팀 내 신뢰
팀이 여러분을 믿고 의지할 수 있어야 한다. 신뢰에 구멍이 뚫리면 원상복구가 어렵다.
책임지기
최선을 다하는 게 전부가 아니다. 결과에 대한 책임을 지기로 했다면 결과를 감당해야 할 것이다. 다른 사람 혹은 무언가를 비난하거나 변명을 만들지 마라. 필요한 것은 변명이 아니라 해결책을 찾는 것이다. 이를 위해 통제할 수 없는 위험 요소가 없는지 상황을 면밀히 분석해야 한다. 만약 불가능하거나 위험 요소가 너무 큰 상황, 혹은 윤리적으로 우려되는 상황에서는 책임을 맡지 않을 권리가 있다. 가치관과 판단에 따라 결정하라.
중요한 것은 변명이 아니라 대안을 제시하는 것이다. 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라. 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력하라.
모르는 것은 인정하되, 거기에 그치지 말라
"잘 모르겠어요."라고 말했다면, 꼭 바로 이어서 "하지만 알아볼게요."라고 말하라. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다.
Topic 3 : 소프트웨어 엔트로피
엔트로피는 시스템 내의 '무질서'한 정도를 가리키는 물리학 용어인데, 소프트웨어도 마찬가지다. 소프트웨어의 무질서도가 증가할 때 이를 '소프트웨어의 부패'라고 일컫는다. 긍정적인 표현으로는 '기술 부채'라고 부르는데, 은연중에 언젠가는 갚을 수 있다는 뉘앙스를 풍기지만 아마 갚지는 않을 것이다.
깨진 창문을 내버려 두지 말라
기술 부채는 깨진 창문으로부터 시작한다. 깨진 창문을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라. 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다. 엔트로피가 우리를 지배하도록 내버려 두지 말라.
- 불쾌한 코드 주석 처리
- '아직 구현되지 않았음'이라고 메시지 표시
- 가짜 데이터(dummy)를 사용한 대치
우선 망가트리지 말라
어떤 위기가 찾아왔다고 해서 부가적인 피해를 일으키지 말라. 깨진 창문을 수리하기 위해 온 집안을 더럽히지 말라. 상황을 냉정하게 평가하고 불필요한 피해를 최소화하라.
깨진 창문 관리하기
명심하라. "깨진 창문은 없어야 한다." 깨진 창문이 이미 있다면 창문을 몇 개 고른 뒤, 동료들과 함께 문제의 원인과 해결을 위한 노력에 대해 토론하라. 만약 창문이 먼저 깨졌을 때 목소리를 낼 수 있을지 생각해보라. 누군가의 결정 혹은 명령에 의한 것이라면 무엇을 할 수 있을지 생각해보라.
Topic 4 : 돌맹이 수프와 삶은 개구리
변화의 촉매가 되어라. 처음부터 큰 요구는 받아들여지지 않을 수 있지만, 큰 변화를 위한 작은 요구는 받아들여질 수 있다. 그리고 그닥 중요하지 않은 척 하면서 다음 요구를 추가하라. 계속되는 성공에 합류하는 건 쉽다.
큰 그림에 늘 주의를 기울여라. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보라. 찬물에 개구리를 담그고 물을 점차 끓이면 개구리는 스스로 삶아지는 줄도 모르고 죽는다. 이런 개구리가 되지 말고 시야를 더 넓혀 주변과 큰 상황을 함께 살펴라.
Topic 5 : 적당히 괜찮은 소프트웨어
사용자나 미래의 유지 보수 담당, 아니면 자기 자신이 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 된다. 다만 '적당히 괜찮은'이라는 표현은 너절하거나 형편없는 코드를 의미하지 않는다. 사용자의 요구 사항을 충족해야 시스템이 성공한다. 가능하면 적당히 괜찮게 사용자의 요구를 충족하는지 결정하는 과정에서 사용자가 참여할 기회를 가져야 한다.
품질을 요구사항으로 만들어라
오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다. 사용자가 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있다.
멈춰야 할 때를 알라
완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아두라. 완벽하지 않을 수도 있다. 그래도 괜찮다. 완벽해지기란 불가능하다.
Topic 6 : 지식 포트폴리오
새로운 것을 배우는 능력은 가장 중요한 전략 자산이다. 그런데 배우는 방법 자체는 어떻게 배워야 할까? 또 무엇을 배워야 할지는 어떻게 알 수 있을까?
지식 포트폴리오
지식 포트폴리오는 투자 포트폴리오 관리와 매우 유사하다. 지식 포트폴리오는 다음과 같은 요소로 구성된다.
- 주기적으로 투자한다.
- 장기적인 성공의 열쇠는 '다각화'다.
- 보수적인 투자와 위험이 크지만 보상이 높은 투자 사이에 균형을 맞춘다.
- 싸게 사서 비싸게 판다.
- 주기적으로 재검토하고 재조정한다.
목표
- 매년 새로운 언어 1개 이상 배우기
- 기술 서적 월당 1권 읽기
- 기술 서적이 아닌 책도 읽기
- 수업 듣기
- 지역 사용자 단체나 모임에 참여하기
- 최신 트렌드 따라가기
학습의 기회
누군가 질문을 할 때 답을 전혀 알지 못하는 경우 거리낌 없이 그걸 인정하라. 단, 이에 그치지 말고 답을 찾기 위한 개인적인 도전으로 생각하라. 스스로 답을 못 찾겠다면 답을 찾아줄 수 있는 사람을 찾아라. 어떻게든 중단하지 말라. 답을 찾는 과정에서 개인 네트워크 구축에 도움이 되기도 하고, 별로 관련이 없는 다른 문제를 해결하게 될 수도 있다. 또한 포트폴리오는 그 사이에 계속 커진다.
비판적 사고
읽고 듣는 것을 비판적으로 분석하라. 아래에 대해 생각해보는 것으로 시작하자.
- 왜냐고 다섯 번 묻기
- 누구에게 이익이 되는가?
- 어떤 맥락인가?
- 언제, 어디서 효과가 있을까?
- 왜 이것이 문제인가?
Topic 7 : 소통하라!
개발자로서 우리는 여러 입장에서 소통해야 한다. 하루 중 많은 시간을 소통하며 보내기에 이를 잘할 필요가 있다. 의사소통을 위한 언어도 또다른 프로그래밍 언어로 여겨라. 사람을 위한 글을 쓰는 것도 코드를 쓰는 것과 같다. DRY 원칙, ETC, 자동화 등을 지켜야 한다.
청중을 알라
그저 말하는 것만으로는 부족하다. 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다. 그렇게 하기 위해서는 청중의 요구와 관심, 능력을 이해할 필요가 있다. 비결은 피드백을 모으는 것이다. 그저 질문을 기다리지 말고 먼저 물어보라. 손짓, 몸짓과 표정을 관찰하라. 신경 언어 프로그래밍의 전제 중 하나는 "당신이 한 의사소통의 의미는 당신이 받은 반응이 결정한다."는 것이다.
말하고 싶은 게 무언지 알라
무엇을 말할지 미리 계획하라. 개요를 작성하라. 그리고 자문하라. "이렇게 하면 내가 표현하고 싶은 것을 듣는 이에게 통하는 방법으로 잘 전달할 수 있나?" 그렇게 될 때까지 다듬어라. 상대가 무엇을 원하는지 알았다면 원하는 것을 이루어 주자.
때를 골라라
청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다. 말하는 내용뿐 아니라 말하는 시점도 적절하게 하라. '이야기하기 좋은 때인가?'라는 질문을 스스로 해보는 것으로 충분하다.
스타일을 골라라
전달하는 스타일을 청중에 어울리도록 조정하라. 뭐가 좋을지 모르겠거든 물어보라. 그리고 그에 맞춰라. 하지만 여러분이 의사소통의 나머지 절반이라는 사실을 기억하라. 누군가 짧게 설명해주길 바라는데 그럴 수 없다면, 사실이 그렇다고 말하라. 이런 종류의 피드백 역시 의사소통의 한 가지 형태이다.
멋져 보이게 하라
아이디어는 중요하다. 그러니 마땅히 청중에게 멋지게 전달하기 위한 수단을 준비해야 한다. 모양새에 신경 쓰지 않으면 뼈 빠지게 일한 노력이 헛수고가 될 수 있다는 것을 기억하라.
경청하라
다른 사람이 여러분의 말을 경청해주길 바란다면 그들의 말을 먼저 경청하라.
- 질문을 해서 먼저 이야기하도록 복돋움하라.
- 토론의 내용을 그들 자신의 표현으로 다시 말해 달라고 요청하라.
응답하라
누군가에게 질문을 했는데 아무런 응답이 없다면 무례하게 느껴질 것이다. 바쁜 중에도 시간을 내어 응답하라. 하다못해 "다음에 답해 드리겠습니다."라는 응답만이더라도 좋다. 이를 통해 상대는 여러분에게 조금 더 관대해질 것이고, 아직 사항을 잊지 않았다고 느끼게 할 것이다.
문서화
문서 작성은 쉬워질 수 있다. 노력을 중복으로 들거나 시간을 낭비하지 말고, 문서를 늘 손에 닿는 가까운 곳에 둔다. 바로 코드 안에 말이다.
외부로 노출하는 경우 주석을 달라
모듈, 또는 외부에 노출하는 함수, 혹은 API의 경우 주석을 다는 것을 추천한다.
모든 코드에 주석을 달지 말라
기계적인 주석은 오히려 코드 유지 보수를 어렵게 만든다. 수정 시 코드와 주석 모두 수정이 필요하기 때문이다. 어떻게 동작하는지 코드가 이미 보여주고, 가독성이 좋은 경우 주석을 다는 것은 사족이다. 그리고 DRY 원칙 위반이다.
이런 경우 주석을 달자
프로젝트에서 쉽게 누락되거나 다른 곳에서 문서화할 수 없는 부분을 문서화할 때 소스 코드에 주석을 달자. 예를 들어 기술적인 절충점, 어떤 결정의 이유, 폐기한 다른 대안 등이다.
총평
이 장은 사실 첫 장이기도 해서 개발적인 깊이보다는 전체적인 내용에 대해 넓게 살펴본 느낌이었다. 오히려 소통과 처세에 대한 이야기가 크게 서술되었다고 느꼈다. 하지만 프로그래머로서 가져야 하는 개발과 개발 주변의 일에 대한 것까지 모두 살펴주니, 개발 서적과 자기계발서를 동시에 읽는 느낌을 받기도 했다. 또, 서문에서 의외로 얻어가는 내용이 있던 것처럼 느끼고 배워가는 내용도 많았던 장이다.
먼저 처세에 대해서는 책임지기 부분이 상당히 인상 깊었는데, 듣는 이의 입장에서는, 결과에 대한 변명이 아니라 대안을 제시하는 것을 더 원한다라는 것이 최근 팀장님과의 면담에서 '생각에 그치는 것이 아니라 구체적인 실행 계획과 행동으로 옮겨야 된다'는 교훈을 얻었던 개인적인 경험과 일맥상통하다고 느껴졌다. "감정에 휩싸이지 않고, 그러면 난 어떻게 해야하지?라는 생각으로 대응하라" 이것이 다시 한 번 나를 더 책임감 있는 사람으로 이끄는 마인드셋이 될 것이다.
한편 모르는 것은 인정하되, 배움의 기회로 삼으라는 대목에서는 동료와의 코드리뷰에서 사용한 CSS 속성의 디테일한 기술적인 부분을 물어봤는데, 제대로 대답하지 못했다가 이틀 후에 개인적으로 설명을 해주던 사례가 생각이 났다. 이미 그날의 기억이 인상적이어서 나도 그렇게 되어야 겠다고 인사이트를 얻었는데, 또 관련된 내용이 나와 반가웠다. 나 역시 모르는 것을 인정하고, 이를 배움의 기회로 삼아야겠다고 생각했다.
비판적으로 바라봤던 부분은 적당히 괜찮은 소프트웨어 부분이었다. 물론 저자도 '적당히 괜찮은'이라는 형용사에 대한 우려로 부연 설명을 많이 달은 것 같지만, 중점은 빠른 결과로 사용 대상과의 피드백을 주고 받으며 더 나은 방향으로 가져가는 것이 완벽한 결과물을 위해 많은 시간을 허비하는 것보다 나은 방법이라는 것이다. 이런 경우 피드백에 따라 변경되는 방향에 대한 대응이 보다 유연하겠지만, 개발적으로는 기반과 설계가 필요한 작업에 대해서도 프로토타입만을 위해 불도저처럼 밀고 나간다면, 기반을 다시 다지기 위해 되돌아왔을 때 앞서 다져지지 않은 광야가 너무 넓어 불필요한 리소스를 썼던 경험이 다수 있었다. 이럴 때는 어떻게 타협해야 할 지 책의 내용과 내 개인적인 경험 사이에서 고민이 되는 것도 같다.
7번 토픽에서 중점으로 다뤘던 것은 소통면이었는데, 그중에서도 멋져 보이게 하라는 점이 유독 공감이 되었다. 개인적으로는 현재 팀에서 거의 1년이라는 기간이 필요한 대형 프로젝트를 진행중인데, 애자일 방식으로 2~3주 간격으로 스프린트를 잘게 나눠 시연 중심으로 개발을 하고 결과를 보여주고 있다. 이럴 때 간혹 오랫동안 공들여 개발한 내용이 시연에서 제대로 보여지지 않으면 마치 스프린트의 개발 사항이 물거품이 된 기분을 종종 받았는데, 이런 일이 없도록 무언가 보여져야 할 때 임팩트를 확실히 주고 멋지게 마무리해야 노력이 보여진다는 사실을 마음에 새겼다.
또한 청중의 수준과 요구를 고려하라는 점 역시 크게 와닿았다. 소통은 혼자 하는 것이 아니고, 소통의 상대가 나와의 소통에서 무엇을 얻고자 하는지를 파악한 뒤, 소통을 시작하는 것이 중요하다는 내용이었다. 이 또한 팀장님과의 면담에서 얻은 교훈이 있는데, 소통은 '질문하기'가 중요하다고 하셨다. 소통의 기저에 깔린 나의 생각은 걷어내고 상대의 생각을 들어야 소통을 바람직하게 끌고 나갈 수 있다는 것이다. 이를 다시금 되새기게 되었다.
마지막으로 주석 처리에 대한 노하우가 나왔는데, 한때는 주석을 많이 달 때도 있었고, 주석은 고이고 썪는다는 말에 주석을 달지 않아도 파악이 되는 코드를 작성하겠다고 설칠 때도 있었다. 그런데 주석을 달기 좋을 때와 지양해야 하는 때를 비교해주니 더욱 명확해진 느낌을 받았다.
기술 부채 해결과 주석에 대한 노하우를 간단하게라도 맛보니, 이후 장부터는 개발적인 노하우를 더 알려줄 수도 있겠다는 생각이 들었다. 이 책을 마쳤을 때 개발적으로 더 성장해 있기를 바라본다.
