🤔 Chapter 1: 실용주의 철학

🍭 Topic 1. 당신의 인생이다

당신의 인생이다. 당신의, 당신이 사는, 당신이 만드는 인생이다.

구직자에게 주도권이 있는 직업 순위를 뽑아 보면 소포트웨어 개발은 제일 윗부분에 자리잡을 것이다. 우리 기술은 수요가 많고, 우리의 지식은 지리적인 경제를 뛰어넘으며, 원격으로도 일할 수 있다. 보수도 후한 편이다. 우리는 원하는 것은 거의 무엇이든 할 수 있다.

하지만 왠지 개발자들은 변화를 피하는 것 같다. 구석에 쭈그린 채 상황이 좋아지리라 생각한다. 자신의 기술이 낡아 빠지는 것을 그저 관망하다가 회사가 교육을 시켜 주지 않는다고 투덜댄다. 이 팁이 이 책에서 제일 중요하다.

Tip 3. 당신에게는 에이전시가 있다.

당신에게는 스스로의 행동을 직접 결정할 수 있는 함이 있다. 업무 환경이 엉망인가? 하는 일이 지루한가? 문제를 고치기 위해 노력하라. 하지만 너무 오랫동안 노력하지는 말라. 마틴 파울러가 말했듯이 "당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다."

기술에 뒤쳐지는 기분이 든다면 여가 시간을 쪼개서 재미있어 보이는 것을 공부하라. 여러분 자신에게 투자하는 것이니 업무 외 시간에 하는 것이 옳다. 원격 근무를 하고 싶은가? 가능한지 물어는 보았나? 안 된다고 하면 된다는 다른 곳을 찾아라.

이 업계는 여러분에게 놀랄 만큼 다양한 기회를 준다. 주도적으로 행동해서 그 기회를 잡아라.

🍭 Topic 2. 고양이가 내 소스 코드를 삼켰어요

실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다. 자신의 경력 개발, 자신의 학습 및 교육, 자신의 프로젝트, 자신의 일상 업무에 대해서 말이다. 실용주의 프로그래머는 자신의 경력에 대해 책임을 지고, 자신의 무지나 실수를 주저 없이 인정한다.

우리는 가능한 한 전문가답게 처리하려고 노력한다. 이는 정직하고 솔직해져야 한다는 것이다. 우리는 자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점도 인정해야만 한다.

🥕 팀 내 신뢰

무엇보다 여러분의 팀이 여러분을 믿고 의지할 수 있어야 한다. 여러분도 다른 팀원 누구에게나 편하게 의지할 수 있어야 한다. 연구에 따르면 창의성과 공동 작업에는 팀 내의 신뢰가 절대적으로 필요하다고 한다. 신뢰에 바탕을 둔 건강한 환경에서는 안전하게 여러분의 생각을 말하거나 아이디어를 제안할 수 있다. 팀원에게 의지할 수도, 반대로 그 팀원이 다시 여러분에게 의지할 수도 있다.

🥕 책임지기

책임은 여러분이 적극적으로 동의하는 것이다. 뭔가 제대로 처리하겠다고 약속을 하더라도 모든 면을 반드시 직접 통제하지는 못한다. 개인적으로 최선을 다하는 것이 전부가 아니다. 여러분이 통제할 수 없는 위험 요소가 있지 않은지 상황을 분석해야 한다. 여러분에겐 불가능하거나 위험 요소가 너무 큰 상황, 또는 결과가 윤리적으로 심각하게 우려되는 상황에서는 책임을 맡지 않을 권리가 있다. 자신의 가치관과 판단에 따라 결정해야 할 것이다.

결과에 대한 책임을 지기로 했다면 나중에 그 결과를 감당해야 할 것이다. 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라.

다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 말라. 모든 문제를 외부 업체나 프로그래밍 언어, 경영진, 동료 때문이라고 떠넘기지 말라. 이들이 모두 한몫씩 했을 수 있겠지만 필요한 것은 변명이 아니다. 해결책을 찾아내야 하는 사람은 여러분이다.

Tip 4. 어설픈 변명 말고 대안을 제시하라.

변명 말고 대안을 제시하라. 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라. 코드르 지워야 하나? 지워야 한다고 말하고 리팩터링의 가치를 설명해 줘라. 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해 보라. 그래도 꼭 해야겠다면 여러분의 고양이에게 먼저 해 보라.

🍭 Topic 3. 소프트웨어 엔트로피

엔트로피는 시스템 내의 "무질서"한 정도를 가리키는 물리학 용어다. 소프트웨어의 무질서도가 증가할 때 우리는 이를 "소프트웨어 기술 부채"라고 부르기도 한다. 이를 보다 긍정적인 표현인 "기술 부채"라고 부르기도 한다. 은연중에 언젠가는 갚을 수 있다는 뉘양스를 풍기면서 말이다. 하지만 아마 갚지는 않을 것이다.

부채, 부패, 이름을 뭐라 부르든 모두 통제할 수 없을 정도로 퍼질 수 있다. 소프트웨어가 부패하는 데에는 많은 요소가 관여한다. 가장 중요한 것은 프로젝트에서 발생하는 심리학적 혹은 문화적 요소다. 심리학자들은 절망감이 전염된다는 연구를 발표했다. 가까운 동네로 퍼지는 독감 바이러스를 생각해 보라. 명백히 망가진 상황을 무시하는 것은 아무것도 고쳐지지 않을 것 같다는 생각, 아무도 신경쓰지 않는다는 생각, 망조가 들었따는 생각을 더 굳어지게 만든다. 이런 부정적인 생각이 팀원들 사이로 퍼져서 악순환을 만들 수 있다.

Tip 5. 깨진 창문을 내버려 두지 말라.

깨진 창문을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라. 불쾌한 코드를 주석 처리하거나, 아직 구현되지 않았음이라고 메시지를 표시하거나, 가짜 데이터로 대치해 놓거나 하라. 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 여러분이 상황을 잘 관리하고 있음을 보여 줘라. 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다. 엔트로피가 우리를 지배하도록 내버려 두지 말라.

🥕 우선, 망가트리지 말라

어떤 위기가 찾아왔다고 해서 부가적인 피해를 일으키지 말라. 깨진 창문은 하나로 충분하다. 깨진 창문이 꽤 있는 프로젝트에서 일할 때는 "나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐."라는 사고에 빠지기 너무 쉽다. 이 시점까지는 프로젝트가 괜찮았더라도 방심해서는 안 된다. 깨진 창문 이론이 나온 최초의 실험에서는 버려진 자동차 한 대가 일주일 동안 방치되었어도 아무도 손대지 않았다. 하지만 창문 딱 하나가 깨지자 몇 시간 만에 자동차 내부는 도난을 당했고 차체는 엉망이 되었다.

같은 맥락에서 여러분이 속한 프로젝트의 코드가 깨끗하고 아름답다면, 즉 깔끔하고 잘 설계되었으며 우아하다면, 아마도 아까 소방관들과 마찬가지로 특별히 주의를 더 많이 기울여서 엉망으로 만들지 않으려 할 것이다.

명심하라. 깨진 창문은 없어야 한다.

🍭 Topic 4. 돌멩이 수프와 삶은 개구리

무엇을 해야 하는지, 어떻게 해아 하는지 정확히 아는 경우가 있다. 전체 시스템이 눈앞에 빤히 그려지고, 여러분은 그 시스템이 옳다는 걸 안다. 하지만 일에 착수하려고 허락을 구하는 때부터, 뭔가가 지연되거나 사람들이 멍한 눈으로 여러분을 바라본다. 위원회가 생길 테고, 예산 승인이 필요하고, 일들이 복잡해지기 시작한다. 모든 사람이 각자 자신의 자원을 지키려고 할 것이다. 이걸 "시작 피로"라고도 부른다.

큰 무리 없이 요구할 수 있을 만한 것을 찾아라. 그리고 그걸 잘 개발하라. 일단 무언가 생기면 사람들에게 보여주고 그들이 경탄하게 하라. 물러나 앉아 여러분이 애초에 원했던 그 기능을 추가해 달라고 사람들이 부탁하기 시작할 때까지 기다려라. 계속되는 성공에 합류하기란 쉽다. 미래를 살짝이라도 보여 주면 사람들은 도와주기 위해 모여들 것이다.

Tip 6. 변화의 촉매가 되라.

🥕 마을 사람의 경우

소프트웨어 참사는 대부분 너무 작아 알아채기 힘들 정도의 문제에서 시작되고, 프로젝트는 대부분 어느 날 갑자기 폭주한다. 시스템은 애초에 명세와는 조금씩 조금씩 기능이 달라진다. 그러다 보면 코드에 패치가 하나둘 적용되다가 원본이 하나도 남지 않을 지경이 된다. 종종 작은 것들이 쌓이고 쌓여서 사람들의 의욕, 그리고 팀을 파괴한다.

Tip 7. 큰 그림을 기억하라.

차가운 물이 든 냄비 속에 개구리를 넣고 조금씩 물을 덥히면 개구리는 온도가 서서히 오르는 것을 감지하지 못할 것이고, 결국 삶아질 때까지 그냥 그대로 있을 것이다.

개구리 문제는 깨진 창문 이론과는 논점이 다르다는 것에 주의하라. 깨진 창문 이론에서는 다른 사람들이 아무도 주의를 기울이지 않는다는 걸 알기에 사람들이 엔트로피에 대항해 싸울 의지를 잃는다고 했다. 반면에 개구리는 단지 변화를 감지하지 못하는 것이다.

그런 개구리처럼 되지 말라. 큰 그림에 늘 주의를 기울여라. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보라.

🍭 Topic 5. 적당히 괜찮은 소프트웨어

실세계에서는 진정 완벽한 것을 만들어 내기란 불가능하다. 특히 버그 없는 소프트웨어는 더더욱, 시간, 기술, 기질 같은 것이 모두 힘을 합쳐 우리를 방해한다.
그렇지만 그게 꼭 우리를 낙담케만 하지는 않는다. 적당히 괜찮은 소프트웨어를 만들도록 자신을 단련할 수 있다. 사용자나 미래의 유지 보수 담당 아니면 자기 자신이 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 된다. 여러분은 더 생산적이 되고 사용자는 한층 더 행복해 할 것이다. 그리고 짧은 작업 기간을 고려하면 여러분의 프로그램이 실질적으로 더 낫다는 것을 알게 될 것이다.

더 나아가기에 앞서 명확하게 해 둘 것이 있다. "적당히 괜찮은"이라는 표현은 너절하거나 형편없는 코드를 의미하지 않는다. 시스템이 성공하려면 사용자의 요구 사항을 충족해야 한다. 기본적인 성능이나 개인 정보 보호, 보안 기준도 맞추어야 한다. 우리가 여기서 하고 싶은 말은 여러분이 생산해 낸 것이 적당히 괜찮게 사용자의 요구를 충족하는지 결정하는 과정이 사용자가 참여할 기회를 가져야 한다는 것이다.

🥕 타폅 과정에 사용자를 참여시켜라

소프트웨어가 얼마나 좋아야 하는지 사용자에게 물어본 적이 한 번이라도 있는가? 때로는 타협의 여지가 없는 경우도 있다. 심장 박동 조율기, 자동 항법 장치, 널리 배포될 저수준 라이브러리 같은 것을 만든다면 요구 사항은 훨씬 더 엄격하고 운신의 폭은 더 좁을 것이다.

그저 프로그램에 새 기능을 추가하거나 코드를 한 번 더 다듬기 위해서 이런 사용자의 요구 사항을 무시하는 것은 전문가답지 못하다. 그렇다고 정신없이 허둥대라는 것은 아니다. 불가능한 시간 약속을 하거나 데드라인에 맞추기 위해 기본적인 걸 빼 버리거나 하는 것 역시 똑같이 전문가답지 못하다.

Tip 8. 품질을 요구 사항으로 만들어라.

우리는 적당한 타협이 필요한 상황에 자주 처한다. 놀랍게도 많은 사용자가 멋지고 휘황찬란한 버전을 위해 일 년을 기다리느리 차차리 오늘 당장 좀 불편한 소프트웨어를 사용하고 싶어 한다. 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다.

🥕 멈춰야 할 때를 알라

완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아두라. 완벽하지 않을 수도 있다. 그래도 괜찮다. 완벽해지기란 불가능하다.

🍭 Topic 6. 지식 포트폴리오

여러분의 지식과 경혐이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다. 하지만 불행히도 이 자산은 기한이 있는 자산이다. 새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛것이 된다. 변화하는 시장 역시 여러분의 경험을 한물간 것이나 별 소용없는 것으로 만들 수 있다. 점점 빨라져만 가는 우리 기술 세계의 변화 속도를 볼 때, 유효 기한은 금세 끝나 버릴 수 있다.

여러분의 지식 가치가 점점 떨어짐에 따라 회사나 클라이언트가 보는 여러분의 가치 역시 떨어진다. 새로운 것을 배우는 능력은 여러분의 가장 중요한 전략 자산이다. 그런데 배우는 방법 자체는 어떻게 배워야 할가? 또 무엇을 배워야 할지는 어떻게 알 수 있을까?

🥕 지식 포트폴리오

일단 스스로 한 번 해본 다음, 습관을 들이는 것이다. 따라 할 절차를 만든 다음 여러분의 뇌에 각인될 때까지 반복하라. 그러고 나면 새로운 지식을 무의식적으로 빨아들이는 자신을 발견할 수 있을 것이다.

🥕 포트폴리오 만들기

주기적인 투자

금융 투자에서와 마찬가지로 여러분의 지식 포트폴리오에 소량이라도 주기적으로 투자해야 한다. 그 습관 자체가 금액의 합계만큼이나 중요하다. 그러니 방해를 받지 않을 수 있는 시간과 장소를 정기적으로 이용할 계획을 마련하라.

다각화

더 여러 가지 알수록 자신의 가치는 더욱 높아진다. 기본적으로 현재 작업에 사용하는 기술에 관해서는 속속들이 알아야 한다. 하지만 거기서 멈추지 말라. 컴퓨터 분야의 지형은 빠르게 변한다.
오늘 인기 있는 기술이 내일이면 거의 쓸모없어지거나 그 정도는 아니어도 수요가 없어지기도 한다. 더 많은 기술에 익숙하다면 변화에 더 잘 적응할 수 있을 것이다. 기술 외의 분야도 포함하여 여러분에게 필요한 다른 역량도 잊지 말라.

리스크 관리

기술은 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것에 이르기까지 다양한 스펙트럼 위에 존재한다. 어느 날 갑자기 무너질지 모르는 위험한 주식에 돈을 모두 투자하는 것은 좋은 생각이 아니지만, 그렇다고 모든 돈을 보수적으로 투자하고 호기를 놓쳐 버리는 것도 좋지 않다. 여러분의 기술 달걀을 모두 한 바구니에 담지 말라.

싸게 사서 비싸게 팔기

새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 게 저평가된 주식을 찾아내는 것만큼이나 어려울 수 있지만, 이익 또한 그만큼 클 수 있다.

검토 및 재조정

이 산업은 매우 동적이다. 지난달부터 탐구하기 시작한 인기 있던 기술이 한 달 만에 완전히 찬밥이 될지도 모른다. 한동안 사용하지 않던 데이터베이스 기술을 복습해야 할 필요가 생길지도 모른다. 혹은 다른 언어를 시도해 본 덕에 새로운 일자리를 구할 때 더 유리할 수도 있다.

이 모든 지침 중에 제일 중요한 것은 가장 간단하게 실행할 수 있는 것이다.

Tip 9. 지식 포트폴리오에 주기적으로 투자하라.

🥕 목표

매년 새로운 언어를 최소 하나는 배워라

다른 언어는 동일한 문제를 다르게 푼다. 몇 가지 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방하는 데에 도움이 된다.

기술 서적을 한 달에 한 권씩 읽어라

웹에는 짧은 글과 진위가 의심스러운 답이 넘쳐난다. 하지만 깊이 있는 지식을 원한다면 긴 글 형식의 책을 읽어야 한다. 습관이 들면 한 달에 한 권씩 읽어라. 현재 사용하는 기술을 일단 완전히 익혔다면, 가지를 쳐서 지금 하는 프로젝트와 관련 없는 분야까지 공부 범위를 넓혀라.

기술 서적이 아닌 책도 읽어라

우리는 사람들과 일하고, 사람들에게 고용되며, 사람들에게 해킹 당한다. 방정식에서 인간이라는 변을 잊지 말라. 사람을 대할 때는 완전히 다른 종류의 기술이 필요하다.

수업을 들어라

사는 지억의 대학이나 온라인 대학, 혹은 근처에서 열리는 다음번 기술 세미나나 콘퍼런스에서 흥미로운 강좌를 찾아보라.

지역 사용자 단체나 모임에 참여하라

고립은 경력에 치명적일 수 있다. 여러분이 회사 밖에서는 사람들이 어떤 일을 하는지 알아보라. 가서 가만히 듣고만 오지 말고 적극적으로 참여하라.

다른 환경에서 실험해 보라

윈도우에서만 일을 해 왔다면 리눅스를 얼마간 사용해 보라.

요즘 흐름을 놓치지 말라

현재 프로젝트에서 사용 중인 것과는 다른 기술을 다루는 뉴스와 온라인 게시물을 읽어라. 다른 사람이 그에 관해 어떤 경험을 했는지, 그들이 사용하는 특별한 전문 용어가 무슨 뜻인지 등을 배우기에 아주 좋은 방법이다.

투자를 지속하는 것이 중요하다. 한 기술의 새로운 용어나 기능에 익숙해지면 다음으로 나아가라. 또 다른 것을 배워라.

🥕 학습의 기회

답을 찾기 위한 개인적인 도전으로 생각하라. 주의에 물어보라. 웹을 검색해 보라. 사용자용 문서뿐 아니라 학술 자료도 찾아보아야 한다.

스스로 답을 찾지 못하겠거든 답을 찾아줄 수 있는 사람을 찾아라. 중단하지 말라. 다른 사람과 이야기함으로써 개인 네트워크를 구축하는 데 도움이 되기도 하고, 답을 찾는 도중에 별로 관련이 없어 보이는 문제에 대한 해답을 찾아서 놀라는 일도 생길 것이다.
이 모든 독서와 연구는 시간이 걸리고 시간은 늘 부족한 자원이다. 그래서 미리 계획해야만 한다. 다른 사정으로 비는 시간을 위해 늘 읽을거리를 준비하라.

🥕 비판적 사고

마지막으로 중요한 점은 여러분이 읽거나 듣는 것에 대해 비판적으로 생각하는 것이다. 여러분의 포트폴리오에 있는 지식을 정확히 유지할 수 있도록 하고 업체나 매체의 과대광고에 흔들리지 않아야 함을 명심하라. 자신의 도그마가 유일한 답이라고 주장하는 광신도를 조심하라. 그 답은 여러분과 여러분의 프로젝트에 맞을 수도 있고, 맞지 않을 수도 있다.

Tip 10. 읽고 듣는 것을 비판적으로 분석하라.

비판적 사고는 그 자체만으로 하나의 학문을 이룬다. 우리는 여러분이 비판적 사고에 대하여 최대한 많이 읽고 공부하기를 권한다. 일단 다음 질문들에 대하여 생각해 보는 것으로 시작하자.

왜냐고 다섯 번 묻기

질문하고 답을 구하라. "왜?"라고 물어서 더 깊이 파고들라. 철업는 다섯 살 꼬마처럼 반복하라. 아마 근본 원인에 더 가까이 다다갈 수 있을 것이다.

어떤 맥락인가?

언제 혹은 어디서 효과가 있을까?

어떤 상황에서? 너무 늦었나, 아니면 너무 이른가? 단순히 "다음에 어떤 일이 일어날까?" 같은 일차적인 사고에서 멈추지 말라. "그 이후에는 또 어떤 일이 일어날까?" 같이 그다음 단계까지 생각해 보라.

왜 이것이 문제인가?

문제의 원인이 되는 근본적인 모델이 있나? 그 모델은 어떻게 작동하나? 안타깝지만 이제 더는 단순한 해법이 없다. 하지만 광법위한 포트폴르오를 갖추고, 넘쳐나는 기술을 다룬 글을 읽을 때 비판적 분석을 적용함으로써 복잡합 해답을 이해할 수 있을 것이다.

🍭 Topic 7. 소통하라!

최고의 아이디어, 최상의 코드 혹은 아주 실용적인 발상이 있다고 해도 다른 사람들과 소통할 수 없다면 궁극적으로 아무 효용이 없다. 효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다.

개발자로서 우리는 여러 입장에서 소통해야 한다. 회의하고, 듣고 말하며 많은 시간을 보낸다. 최종 사용자의 요구를 이해하려하고 노력하며 그들과 함께 일한다. 코드를 작성하는 것은 우리의 의도를 기계에게 전달하는 것이기도 하지만, 생각을 기록하여 다음 세대의 개발자들에게 전달하는 것이기도 하다. 하루 중 많은 시간을 소통하며 보내기 때문에 이를 잘할 필요가 있다.

여러분이 의사소통에 사용하는 언어(그게 한국어든 영어든)도 또 다른 프로그래밍 언어일 뿐이라 여겨라. 사람을 위한 글을 쓰는 것도 코드를 쓰는 것과 똑같다. DRY 원칙이냐 ETC, 자동화 등을 지켜야 한다.

Tip 11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다.

🥕 청중을 알라

그저 말하는 것만으로는 부족하다. 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다. 그렇게 하기 위해서는 청중의 요구와 관심, 능력을 이해할 필요가 있다.

다른 모든 형태의 의사소통과 마찬가지로 여기서도 비결을 피드백을 모으는 것이다. 그저 질문을 기다리지 말고 먼저 물어보라. 손짓, 몸짓과 표정을 관찰하라. 신경 언어 프로그래밍의 전제 중 하나는 "당신이 한 의사소통의 의미는 당신이 받은 반응이 결정한다."는 것이다. 소통하면서 청중에 대한 지식을 쌓아 나가라.

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

의사소통에서 가장 어려운 부분은 아마도 여러분이 말하고자 하는 것이 정확히 무엇인지 생각해 내는 일일 것이다.

무엇을 말하지 미리 계획하라. 개요를 작성하라. 그리고 자문하라. 이렇게하면 내가 표현하고 싶은 것을 듣는 사람에게 통하는 방법으로 잘 전달할 수 있나? 그렇게 될 때까지 다듬어라.

문서를 작성할 때만 그런 게 아니다. 중요한 회의를 앞두고 있거나 주요 클라이언트와 대화를 해야 할 때, 의사소통하고 싶은 아이디어들을 적은 다음 제대로 전달하는 데 필요한 전략을 몇 개 세워라.

상대가 무엇을 원하는지 알았다면 원하는 것을 이루어 주자.

🥕 때를 골라라

청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다. 말하는 내용뿐 아니라 말하는 시점도 적절하게 하라. 가끔 "~에 대해 이야기할 좋은 때일까?"라는 간단한 질문을 해 보는 것으로도 충분하다.

🥕 스타일을 골라라

전달하는 스타일을 청중에 어울리도록 조정하라. 하지만 여러분이 의사소통의 나머지 반쪽이라는 사실을 기억하라. 누군가가 뭔가를 짤막하게 설명해 달라고 부탁하는데, 그 설명을 종이 대여섯 장 이하로 줄일 방법이 없다는 생각이 들면, 사실이 그렇다고 말하라. 이런 종유릐 피드백 역시 의사소통의 한 가지 형태임을 기억하라.

🥕 멋져 보이게 하라

여러분의 아이디어는 중요하다. 그러니 마땅히 청중에게 멋지게 전달하기 위한 수단을 준비해야 한다.

오늘날 형편없어 보이는 출력물을 만드는 것에 대한 변명은 용납되지 않는다. 현대의 소프트웨어는 여러분이 마크다운을 사용하든 워드 프로세서를 사용하든 상관없이 눈부신 출력물을 만들어 낼 수 있다. 맞춤법을 확인하라.

🥕 청중을 참여시켜라

가능하다면 독자가 문서 초안에 참여하도록 하라. 피드백을 받고 그들의 머릿속을 도용하라. 독자와 더 좋은 관계를 형성하게 될 것이고, 아마 그 과정에서 더 나은 문서를 만들 수 있을 것이다.

🥕 경청하라

아무리 여러분이 모든 정보를 갖고 있다 해도, 아니면 20명의 중역을 앞에 놓고 격식 있는 회의를 진행하는 경우라고 해도, 여러분이 다른 사람들의 말을 귀 기울여 듣지 않는다면 그들 역시 여러분의 말을 듣지 않을 것이다.

질문을 해서 사람들이 이야기를 하도록 북돋우거나, 토론의 내용을 그들 자신의 표현으로 다시 말해 달라고 요청하라. 회의를 대화로 바꾸면 생각을 좀 더 효과적으로 전달할 수 있을 것이다.

🥕 응답하라

누군가에게 질문을 했는데 아무런 응답도 없다면 그가 무례하다고 느낄 것이다. 하지만 여러분 자신은 사람들이 정보를 요청하거나 어떤 행동을 부탁하는 이메일 혹은 메모를 보냈을 때, 얼마나 자주 응답을 못 하는가? 하루하루 바쁜 삶 속에서 잊어버리고 살기 쉬운 법이다. 언제나 이메일과 음성 메시지에 답을 하라.

Tip 12. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.

외부와 단절된 환경에서 작업하지 않는 이상 우리는 의사소통을 해야 한다. 그 소통이 더 효과적일수록 좀 더 많은 영향력을 갖게 될 것이다.

🥕 문서화

실용주의 프로그래머는 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 받아들인다. 문서 작성은 더 쉬워질 수 있다. 노력을 중복으로 들이거나 시간을 낭비하지 말고 문서를 늘 손에 닿는 가까운 곳에 두면 된다. 바로 코드 안에 말이다. 사실 우리는 코드에 적용하는 모든 실용주의 원칙을 문서에도 적용하길 바란다.

Tip 13. 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.

API가 아닌 코드에 주석을 쓸 때는 왜 이렇게 되어 있는지, 즉 코드의 용도와 목적을 논해야 한다. 어떻게 동작하는지는 코드가 이미 보여 주기 때문에 이에 대해 주석을 다는 것은 사족이다. 게다가 이것은 DRY 원칙 위반이다. 소스 코드에 다는 주석은, 프로젝트에서 쉽게 누락되는 다른 곳에서 문서화할 수 없는 부분을 문서화하기에 최적의 기회다.

🥕 요약

• 청중을 알라.
• 말하고 싶은 게 무언지 알라.
• 때를 골라라.
• 스타일을 골라라.
• 멋져 보이게 하라.
• 청중을 참여시켜라.
• 경청하라.
• 응답하라.
• 코드와 문서를 함께 둬라.