실용주의 철학

코드 얘기가 아니야. 프로그래머로서 어떤 태도를 가져야 하는지, 어떤 마인드셋으로 일해야 하는지를 다루는 챕터거든. 20주년 기념판에서 가장 많이 보강된 부분이기도 하지. 기술은 바뀌어도 철학은 남으니까.

저자들이 제일 먼저 하는 말: 당신에게는 에이전시(agency)가 있다. 회사가 싫으면 바꿔. 기술 스택이 마음에 안 들면 배워. 환경 탓하지 말고 직접 움직여.

이게 단순한 자기계발 얘기가 아닌 이유가 있지. 소프트웨어 업계는 다른 분야에 비해 직업적 자유도가 높은 편이잖아. 원격 근무, 프리랜싱, 오픈소스 기여 등 선택지가 넓은데도 불만만 갖고 아무것도 안 바꾸는 사람이 많다는 거야.

핵심 메시지: 변화를 기다리지 마. 너의 인생이니까 너가 바꿔야 해.

제목이 웃기지만 진지한 내용이야. 핵심은 책임을 져라는 것.

뭔가 잘못됐을 때 변명하지 마. "고양이가 숙제를 먹었어요" 같은 변명을 프로그래머 버전으로 하지 말라는 거지. 디스크가 날아갔어요, 요구사항이 바뀌었어요, 테스트할 시간이 없었어요 — 다 변명이야.

저자들이 제안하는 방법:

• 변명 대신 대안을 제시하라
• "안 됩니다" 대신 **"이렇게 하면 됩니다"**를 말하라
• 말하기 전에 거울 앞에서 리허설해봐. 상대방이 뭐라고 할지 예상해보고

팁 하나 — 변명을 늘어놓기 전에 상대방 입장에서 그 변명을 들어봐. 납득이 안 되면 다른 방법을 찾아야 하는 거지.

깨진 창문 이론이 나오는 유명한 절이야.

건물에 깨진 창문 하나를 방치하면, 곧 다른 창문도 깨지고, 낙서가 생기고, 결국 건물 전체가 망가지잖아. 소프트웨어도 마찬가지야. 나쁜 설계 하나, 잘못된 결정 하나, 엉성한 코드 하나를 방치하면 "어차피 이 코드는 이미 엉망이니까" 하는 마인드가 퍼져.

반대 사례도 있어. 아무리 좋은 코드베이스라도 깨진 창문 하나를 허용하면 순식간에 무너지거든.

저자들의 조언: 깨진 창문을 발견하면 즉시 고쳐라. 시간이 없으면 최소한 "여기 문제가 있다"는 주석이라도 달아. 판자를 대서라도 창문을 막아놓으라는 거야.

두 가지 비유가 나와.

돌멩이 수프: 세 병사가 마을에 도착해서 "돌멩이로 수프를 끓이겠다"고 하지. 마을 사람들이 호기심에 하나둘 재료를 보태고, 결국 맛있는 수프가 완성돼. 변화의 촉매(catalyst)가 되라는 얘기야. 큰 걸 한번에 요청하면 거절당하지만, 작은 것부터 시작해서 사람들을 끌어들이면 되거든.

삶은 개구리: 개구리를 끓는 물에 넣으면 바로 뛰쳐나오지만, 미지근한 물에 넣고 서서히 온도를 올리면 알아채지 못하고 죽잖아. 프로젝트도 마찬가지야. 서서히 나빠지는 걸 못 느끼고 있다가 어느 날 보면 재앙이 돼 있지.

교훈: 변화를 이끌 때는 돌멩이 수프 전략을, 위험을 감지할 때는 삶은 개구리가 되지 않도록 큰 그림을 항상 기억해야 해.

완벽을 추구하다 아무것도 못 내놓는 것보다, 충분히 좋은 소프트웨어를 제때 내놓는 게 낫지.

여기서 "적당히 괜찮은"이 "대충 만든"이라는 뜻이 아니야. 사용자의 요구사항을 충족하고, 기본적인 품질 기준을 만족하며, 향후 개선할 여지가 있는 소프트웨어를 말하는 거거든.

저자들의 핵심 포인트:

• 사용자에게 직접 물어봐. 어느 정도면 충분한지는 사용자가 결정하는 거야
• 완벽한 소프트웨어는 존재하지 않아. 충분히 좋은의 기준을 명확히 하는 게 중요하지
• 품질을 요구사항으로 만들어. 암묵적 기대 말고 명시적 합의

"적당히 괜찮은"의 함정도 경고하거든. 이걸 변명으로 쓰지 말라는 거야. 의도적으로 품질 수준을 정하는 것과 귀찮아서 대충 하는 건 다르잖아.

이 절의 비유가 끝내줘. 지식을 금융 투자처럼 관리하라는 것.

투자 포트폴리오처럼:

• 정기적으로 투자하라 — 매년 새로운 언어를 배워. 매달 기술 서적을 읽어
• 다양화하라 — 한 가지 기술에 올인하지 마. 그 기술이 사라지면 너도 사라져
• 리스크를 관리하라 — 안정적인 기술(검증된 것)과 고수익 기술(새로운 것)의 균형
• 싸게 사서 비싸게 팔아라 — 유행하기 전에 미리 배워두면 나중에 가치가 올라가지
• 주기적으로 리밸런싱하라 — 시장(업계)이 변하면 포트폴리오도 조정

구체적인 제안들:

• 매년 새로운 언어 하나 배우기
• 분기마다 기술 서적 한 권 읽기
• 비기술 서적도 읽기
• 수업 듣기
• 지역 사용자 모임 참가
• 다른 환경 실험해보기 (Windows 쓰면 Linux도 해보고)
• 트렌드 따라가기

그리고 비판적 사고를 강조하지. 뭔가 읽거나 들었을 때 무조건 수용하지 말고 "왜?", "누구에게 이득인가?", "맥락이 뭔가?", "언제 어디서 작동하는가?", "왜 이게 문제인가?"를 물어봐야 해.

아무리 좋은 아이디어도 전달 못 하면 소용없잖아.

저자들이 제시하는 소통 원칙:

• 청중을 알라 — 같은 내용도 CEO한테 할 때와 개발자한테 할 때가 다르지. WISDOM 약어: What(뭘 배우길 원하나), Interest(관심사가 뭔가), Sophisticated(얼마나 전문적인가), Detail(얼마나 디테일을 원하나), Own(누가 정보를 소유하길 원하나), Motivate(뭘 들으면 동기부여가 되나)
• 때를 골라라 — 금요일 오후에 아키텍처 변경 제안하지 마
• 스타일을 골라라 — 어떤 사람은 긴 보고서를, 어떤 사람은 슬랙 한 줄을 원해
• 멋지게 보이게 하라 — 형식도 중요해. 잘 정리된 문서가 설득력 있지
• 청중을 참여시켜라 — 초안 단계에서 피드백을 받아
• 경청하라 — 소통은 양방향이야
• 되돌아오라 — 질문에 항상 응답해. "나중에 알려드릴게요"라도

마지막으로 문서화에 대해서도 언급하거든. 코드 안에 문서를 넣어. 외부 문서는 코드와 괴리가 생기기 마련이야. 코드 코멘트는 "왜"를 설명해야지 "무엇을" 설명하면 안 돼.

---

정리

1장 읽고 기억할 거 세 가지:

1. 변명하지 말고 대안을 제시해. 프로 개발자의 첫 번째 덕목은 책임감이야
2. 깨진 창문을 방치하지 마. 작은 방치가 전체를 무너뜨리거든
3. 지식은 투자 포트폴리오야. 다양하게, 정기적으로, 비판적으로 관리해야 해