[독서]실용주의 프로그래머 - 1장. 실용주의 철학
2월부터 시작한 에프랩 프론트엔드 멘토링 수업에서 멘토님께서 '실용주의 프로그래머' 책을 읽기를 추천하셨다. 왜 추천하셨을지, 나는 이 책에서 무엇을 얻어가기 위해 읽으려는지 확실히 하고자 1장을 읽고 느낀점을 정리해본다.
1장. 실용주의 철학
"이 20년이란 세월 동안 상식은 전혀 변하지 않았다. 기술은 바뀌었을지 모르나 사람은 바뀌지 않았다. 20년 전에 유용했던 실천 방법이나 접근 방식은 여전히 유용하다."
-실용주의 프로그래머 2판 서문
"실용주의 프로그래머는 무엇이 다른가? 우리는 문제와 해법에 접근하는 태도와 방식, 철학에 차이가 있다고 생각한다. 실용주의 프로그래머는 직면한 문제 너머를 고민한다. 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다. 사실 이런 더 큰 맥락 없이 어떻게 실용적일 수 있겠는가? 어떻게 현명한 절충안을 내고, 정확한 사실을 바탕으로 결정을 내릴 수 있겠는가?"
-실용주의 프로그래머 p 1
처음엔 "실용주의라면서 너무 이상적인 이야기 아닌가, 현실세계에서의 개발은 그렇게 아름답게 해나갈 순 없는것 아닌가?" 라는 생각이 들었다. 하지만, 개발 커리어를 이어가면서 내가 앞으로 내리게 되는 많은 의사결정들에서 먼저 이 길을 걸어간 시니어들의 지혜를 바탕으로 무엇이 장기적인 관점에서 옳은 방향인가를 알면 "에라 모르겠다" 식의 결정 대신 현재 여건에서 최적의 선택이 무엇일지 근거와 선택 이후의 상황들에 대한 대략적인 예측이 가능해질 수 있을 것으로 생각이 들었다. 프레임워크가 아무리 빠르게 변해도 컴퓨터 자체는 변하지 않은 것처럼 일을 잘 하기 위한 방법도 변하지 않는 내용들이 있다고 느꼈다. 그래서, 이 책은 실용적이다. 모든 토픽마다 마지막에 관련있는 다른 토픽의 목차와, 실제로 해 봄으로서 체화해볼 수 있는 도전 과제가 주어져 있다. 무엇이던지 실력을 키우려면 의도적으로 난이도를 점진적으로 키워가며 쌓아 나가야 하는데, 책에서 말하는 여러 접근법을 따름으로써 더 효율적으로 경험을 쌓고, 생산성을 증가시키고, 전체 개발 과정을 더 깊이 이해하고, 더 좋은 소프트웨어를 작성하게 되기를 바라며 이 책을 읽어나가려고 한다.
Topic 1. 당신의 인생이다
자기계발, 코칭, 심리학 관련 유튜브나 책들을 보면 "남 탓, 환경 탓 하지 말고 스스로의 행동에 책임질 것, 내가 바꿀 수 있는 부분에 집중할 것" 과 같은 공통적인 내용을 보게 되는데, 역시 진리는 보편적인것 같다. 항상 머리로는 알지만 일상에 파묻혀 잊어버리곤 하는 것들. Topic 1의 내용도 당신의, 당신이 사는, 당신이 만드는 인생이므로, 문제를 느낀다면 문제를 고치기 위해 움직이던지, 환경이 문제라면 환경을 바꾸기를 촉구한다. 내가 나의 에이전시처럼 행동해야 한다. 현재 업무에 갖혀 있다고 느끼거나, 기술의 변화를 쫒아가지 못한다고 느끼거나, 자신의 성과를 몰라준다고 느끼거나, 월급이 너무 적은 것 같다고 느끼거나, 팀이 안 맞다고 느끼거나, 해외나 재택으로 근무해보고 싶다거나, 등등 이러한 문제들도 내 커리어고 내 인생이니 내가 적극적으로 움직여야 하는 것임을 다시금 상기해볼수 있었던 토픽이었다.
Topic 2. 고양이가 내 소스 코드를 삼켰어요
일을 전문가답게 처리하기 위해선 정직하고 솔직해져야 한다. 결과에 대한 책임을 지고 결과를 감당해야 한다. 우리는 누구나 실수를 할 수 있다. 하지만 실수에 대해서 외부 업체, 언어 문제, 경영진, 팀워크의 문제 등 타인이나 상황의 탓으로 변명을 만들어 내선 안된다. Topic 2에서는 어설픈 변명 대신 대안을 제시할 것을 제안한다. 무턱대고 안된다고 하기 전에 생각해보아야 한다. 리팩터링이 필요한 상황이라면 리팩터링의 가치를 설명하거나, 최선의 방법을 결정하기 위해 프로토타입을 만들거나, 테스트나 자동화를 도입해야 할 상황인지 확인해야 한다. 또는 자원이 더 필요한 상황인지, 기술을 더 깊이 있게 배워야 하는 상황인지, 책에서 저자는 부탁을 어려워 하지 말고 도움이 필요하다면 도움을 구하기를 권한다. 나의 팀이 나를 믿고 의지할 수 있어야 하고, 나도 다른 팀원 누구에게나 편하게 의지할 수 있는 서로를 신뢰하는 팀이 되어야 한다. 변명거리를 없애기 위한 이러한 모든 노력 끝에도 남아있다면, 우리집 고양이 탓으로 돌려보라는, 유머러스한 제목이지만 무거운 내용의 토픽이었다. 개발 커리어 초반부인 지금 이 시절에 반드시 이러한 습관을 들여놓아야겠다고 느낀다. 변명 이전에 상황을 개선할 방법을 찾자.
Topic 3. 소프트웨어 엔트로피
"소프트웨어의 무질서도가 증가할 때 우리는 이를 '소프트웨어의 부패'라고 일컫는다. 이를 보다 긍정적인 표현인 '기술 부채'라고 부르기도 한다. 은연중에 언젠가 갚을 수 있다는 뉘앙스를 풍기면서 말이다. 하지만 아마 갚지는 않을 것이다."
-실용주의 프로그래머 p 8
이번 토픽은 조악한 설계의 코드, 형편없는 경영상의 결정 등의 "깨진 창문을 그대로 방치해두지 말 것, 또한 어떠한 위기가 찾아왔다고 해서 이를 해결한다고 다른 창문을 또 깨지 말것" 을 말한다. 하지만 아직 경험이 많지 않은 나로선 구린 냄새가 나는 어떠한 상황이 "현재 여건과 가용한 자원에서의 최선"으로 보아야 할 지, 당장 치워야 할 깨진 창문인지 판단하기는 쉽지 않을것 같다고 느껴진다. 이 책을 더 읽어나가면서 적당히 괜찮은 소프트웨어와 깨진 창문 치우기의 밸런스를 유지하면서 나아가는 방법을 더 알아갈 수 있을까? 이 독후감을 쓰는 시점에선 아직은 어려운 주제인것 같다. 물론, 당장 고칠 시간이 없다면 일단 깨진 창문을 판자로 덮는 것 만이라도 할 것, 즉 불쾌한 코드를 주석 처리 하거나, '아직 구현되지 않았음'의 메세지를 표시하거나, 더미 데이터로 대치해 놓거나 하는 등의 조치는 취해 두라는 내용은 유익하다. 앞으로 프로젝트를 진행하면서 냄새나는 곳이 생기지 않게 관리를 해나가려면 어떻게 하면 좋을 지 생각해보아야겠다.
Topic 4. 돌멩이 수프와 삶은 개구리
돌멩이 수프 이야기를 간단하게 우선 요약하고 글을 이어간다.
가진 건 돌멩이 뿐인 한 사람이 마을에 나타나서, "나에게 큰 솥 하나를 주면 세상에서 가장 맛있는 수프를 끓일 수 있다"고 말한다.
큰 솥에 단지 돌멩이만을 넣고 끓이는 모습에 호기심을 가진 마을 사람들이 하나 둘 씩 나타나서 그것만 가지고 되겠냐고 물으며, 각자 쇠고기, 파, 소금, 허브 등 자신이 가지고 있는 식재료 하나씩을 건네준다.
마을 사람들이 한 명씩 식재료를 제공해주게 되니 결국 큰 솥 가득 맛있는 수프를 끓이게 되었다. 처음에 넣었던 돌멩이는 솥에서 꺼내고, 모두가 맛있는 수프를 먹게 되었다.
책에서 이 일화를 설명하면서 소프트웨어 개발에서도 이 일화의 '돌멩이'처럼 큰 무리 없이 요구할 만한 것을 찾아 그것을 잘 개발하라고 한다. 무엇을 어떻게 해야 하는지 나는 명확하게 아는데, 허락을 구하려니 사람들의 반응이 시큰둥할 때, 일단 보여줄 무언가를 만들고, 사람들에게 "~를 추가하기만 하면 더 나아질 것 같네요" 라고 말하면서 그다지 중요하지 않은 척 가장한다. 그리고 결국 사람들이 애초에 내가 원했던 그 기능을 추가해 달라고 부탁하기 시작할 때 까지 기다린다. 결국 계속되는 성공의 흐름을 보여주어 다른 사람들이 도와주기 위해 모여드는 변화의 촉매로 만들수 있는 것임을 저자는 말하고 있다. 그러나, 이전에 돌멩이 수프 일화에서 사람들은 돌멩이에 대해서 생각하느라 다른 일들에 대해서는 까맣게 잊어버렸다. 우리는 큰 그림을 기억하고, 주변에서 무슨 일이 벌어지는지 늘 살피면서 내가 천천히 뜨거워지는 솥 안에 있는 개구리가 되지 않도록 주의해야 한다고 저자는 말한다.
Topic 5. 적당히 괜찮은 소프트웨어
"'적당히 괜찮은'이라는 표현은 너절하거나 형편없는 코드를 의미하지 않는다. 시스템이 성공하려면 사용자의 요구 사항을 충족해야 한다. 기본적인 성능이나 개인 정보 보호, 보안 기준도 맞추어야 한다."
-실용주의 프로그래머 p 16
이전에 깨진 유리창을 방치하지 말라고 하는 내용과 좀 상충되는 내용이지 않나 생각했는데, 독후감을 쓰면서 다시 읽다 보니 적당히 괜찮다는 기준은 너절하거나 형편없는 코드를 의미하는게 아니라는걸 보고 내적인 기준점을 잡는데 있어 조금 더 실마리를 얻게 되는것 같으면서도 마음이 약간 무거워진다. 그래도 천천히 한걸음씩 나아가면 조금씩 가벼워져 가겠지?
타협 과정에 사용자를 참여시켜라
어찌 보면 참으로 당연한 건데, 회사에서 하는 개발은 다른 사람을 위한 제품이다. 사용자가 원하는게 무엇인지, 그리고 기능의 완성도는 "어느 정도까지 좋아야 하는지"는 내가 아니라 '사용자'의 요구사항을 가용한 타임라인에서 최우선으로 삼아야 하는게 맞지 않을까?
"우리는 적당한 타협이 필요한 상황에 자주 처한다. 놀랍게도 많은 사용자가 멋지고 휘황찬란한 버전을 위해 일 년을 기다리느니 차라리 오늘 당장 좀 불편한 소프트웨어를 사용하고 싶어 한다(게다가 사실 1년 뒤면 원하는 것이 완전히 달라질 것이다)."
-실용주의 프로그래머 p 17
심장 박동 조율기, 자동 항법 장치, 널리 배포될 저수준 라이브러리 같은 제품들은 명확하고 엄격한 반드시 지켜야 하는 요구사항들이 있지만, 그런 제품이 아니라면 완벽하지 않더라도 빨리 출시하고 피드백을 통해 개선해 나가는게 머리속으로 상상했던 내 기준의 완성보다 더 명확하고 현실적으로 개발해나갈 수 있을 것이라고 느꼈다. 3D 뷰어 MVP 개발 당시 한번 이 늪에 빠질 뻔 했다. 지금 기능이나 외관이나 너무 모자란 부분만 보이고 완성도와 기능 추가를 위해 좀 더 개발기간을 늘려야 하지 않을까 생각했었다. 그러다 MVP 개발 방법론을 다시 보면서 필수 기능을 충족한다면 빨리 출시하고 실사용자의 피드백을 통해 개선해나가는게 맞다고 느끼고 MVP로서의 필수 기능 구현에 집중할 수 있었다.
멈춰야 할 때를 알라
이 내용을 읽으면서 옛날에 미대입시를 준비하던 시절의 기억이 떠올랐다. 미대입시에서 실기시험은 한정된 시간 안에 그림을 완성시켜야 한다. 이 때 부분 부분의 묘사와 완성도에 집착하면 절대 시간내에 완성할 수 없다. 강조할 주제 부위에 빡세게 묘사하고 화려한 색을 넣지만, 배경과 주변 환경 또한 주제보다는 눈에 띄지 않지만 전체 그림의 분위기를 잡아주어야 한다. 여기서 '완성'의 기준은 박물관에 걸 수준이 아니라 제한 시간 안에 하나의 '그림'이다라고 부를 수 있는 수준이다. 현실에서 '완벽한' 무언가란 절대 없다. 뒤에 7장에서 이런 불완전한 현실에서 코드를 개발하기 위한 철학을 다룬다고 하니 나중에 해당 파트를 읽으면서 더 이해도를 높일 수 있겠다.
Topic 6. 지식 포트폴리오
토픽 6에서는 지식 자산을 관리하는 것과 투자자들의 포트폴리오 관리는 "주기적인 투자, 다각화, 리스크 관리, 싸게 사서 비싸게 팔기, 검토 및 재조정" 관점에서 유사한 특성이 있으므로 투자자의 포트폴리오 관리처럼 지식 또한 관리하기를 제안한다. 이번 토픽을 읽고 나의 지식 자산 관리를 위해 다시 블로그를 시작하게 되었다.
지식 포트폴리오 만들기
주기적인 투자 : 새로운 언어 배우기, 기술 서적 읽기, 기술 서적이 아닌 책으로 소프트 스킬 기르기, 수업 듣기, 모임 참여하기, 다른 개발 환경 써보기, 트렌드에 주의를 기울이기 등
다각화 : 기본적으로 현재 작업에서 사용하는 기술은 제대로 알되, 더 나아가서 다른 플랫폼이나 새로운 프레임워크 같이 기술 역량과 비기술 역량을 다각화하여 변화에 더 잘 적응하도록 만들기
리스크 관리 : 기술 달걀도 한 바구니에 담지 말라고 한다. 특정 도메인이나 플랫폼에 올인하지 말라는 뜻으로 이해했다.
싸게 사서 비싸게 팔기 : 신기술이 인기를 끌기 전에 미리 알고 학습하는 것 = 유망주 저점매수 (물론 주식처럼 이게 오를지 아닐지는 모르는 것이지만)
검토 및 재조정 : 지금 인기있는 기술이 불과 한달만에 찬밥이 될 수도, 한동안 사용하지 않던 기술을 복습해야 할 필요성이 생기기도 한다. 시장 흐름에 귀기울이고 계속해서 재조정해나가야 한다.
비판적 사고
다만, 저자는 내가 읽거나 듣는 것에 항상 비판적으로 분석할 것을 강조한다. 요즘 한국 유튜브에선 성공팔이들의 추악한 실체가 화제가 되고 있는데, 그럴것 같다 싶던 사람이 결국 그렇더라인 케이스도 있었지만 이 사람은 진실된 이야기를 하는구나라고 생각했는데 아니었던 케이스들도 있었고, 속았다는 생각에 기분이 좋지 않았다. 비판적 사고 자체만으로도 하나의 학문이 되는 방대한 영역이지만, 저자는 아래 5가지 질문을 생각해 보는 것으로 일단 시작해보기를 제안한다.
왜냐고 다섯 번 묻기 : 질문하고 근본 원인에 다가갈 때 까지 파고 들기
누구에게 이익이 되나? : 돈의 흐름을 살피고 결론적으로 누가 이익을 얻는지 분석한다. 그리고 내 이익과 합치하는지 아닌지 따져본다.
어떤 맥락인가? : 만병통치약은 없다. 어떤 맥락에서 이게 효과가 있는건지 따져본다.
언제, 어디서 효과가 있을까? : 지금 늦은건가, 이른가, 이 다음엔 무슨 일이 일어나나 를 넘어서서 그 이후에는 또 어떤 일이 일어날것인가, 즉 더 다음의 단계까지 생각해본다.
왜 이것이 문제인가? : 문제의 원인이 되는 근본적인 모델이 있는지, 그것은 어떻게 작동하는지 (하지만 이것은 단순한 해법이 없고, 짬바의 영역으로 그간의 지식 포트폴리오와 비판적 분석으로 답을 찾아야 한다고 설명)
Topic 7. 소통하라!
TPO에 맞게 소통하고, 문서화에 신경쓰라는 내용의 토픽이다. 우리가 의사소통에 사용하는 언어 또한 또 다른 프로그래밍 언어라고 여기고, 사람을 위한 글을 쓰는 것도 코드를 쓰는 것처럼 DRY 원칙이나 ETC, 자동화 등을 적용할 수 있으므로 문서화에도 실용주의 원칙을 적용하기를 저자는 권한다.
청중을 알라 : 전달하려는 내용을 제대로 전달하려면 청중의 요구와 관심, 능력을 이해할 필요가 있다.
말하고 싶은 게 무언지 알라 : 무엇을 말할 지 미리 계획하고, 개요를 작성하고, 자문하고, 다듬기
때를 골라라 : 지금 저 사람한테 이 이야기를 하는게 과연 좋은 타이밍일까?
스타일을 골라라 : 상대가 어떤식의 브리핑을 선호하는지, 상대의 기술 수준이나 경험이 어떤지, 생각해서 모르겠으면 상대한테 직접 어떤 식으로 의사소통하길 원하는지 물어보기
멋져 보이게 하라 : 포장지가 별로면 내용물도 별로처럼 느껴진다. 문서 스타일 시트, 양식, 맞춤법 등에도 신경쓰기
청중을 참여시켜라 : 이 문서를 실제로 읽을 사람에게 피드백을 받고, 가능하면 문서 초안에도 참여하도록 하기
경청하라 : 다른 사람들이 내 말을 경청하기를 바란다면 내가 다른 사람들의 말을 경청해야 한다.
응답하라 : 이메일, 메세지 답변해주기
문서화 : 문서는 나중에 넣으려고 하지 말고 문서를 애초부터 포함한다. 모듈과 외부로 노출하는 함수나, 기술적인 절충점, 결정의 이유, 폐기한 다른 대안 등을 소스 코드에 주석으로 남기는 것은 프로젝트에서 쉽게 누락될 수 있는 문서화할 수 없는 부분에 대한 문서화의 좋은 기회가 됨.