실용주의 프로그래머라는 책을 읽으며, 삼색볼펜 독서법을 적용. 줄 친 내용에 대한 단상을 정리합니다.
삼색볼펜 스터디란? 책에서 중요하다고 생각되는 문장을 빨강 > 파랑 > 검정 순으로 줄을 치며 공부하는 방식.
🔴 가장 중요한 문장
🔵 그래도 꽤 중요한 문장
⚫ 그럭저럭 내 마음에 와닿은 문장
🤔 짧은 생각 (단상은 단상일뿐!!)
볼드체 중요한 문장은 아니지만 단락 구분 표시
1장. 실용주의 철학
🔴 실용주의 프로그래머는 직면한 문제 너머를 고민한다. 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다.
🤔 실용주의 프로그래머가 뭔지 말해주는 문장. 실용주의의 반댓말은 이상주의인데, 그렇다면 실용주의 프로그래머는 이상적이고 원론적인 것들을 따르지 않고, 실질적인 서비스 개발에 집중하는 프로그래머가 아닐까 생각했는데, 그 실용적이란 범주에 문제를 보는 큰 그림이 포함되는 게 의외다.
🔵 실용주의 프로그래머는 책임감이 있기 때문에 프로젝트가 방치된 채로 끝장나는 걸 가만히 옆에 앉아서 지켜보고만 있지 않는다.
🤔 이 부분이 결국 내가 생각한 느낌의 실용주의 프로그래머이지 않을까 싶다. 이상적인 프로그래머라면 처음부터 완벽한 모습을 추구할 테지만, 실용주의 관점이면 어떻게든 마침표를 찍는걸 목표로 할테니.
Topic 1. 당신의 인생이다.
🤔 당신의 일, 당신의 인생이니 타인에게 기대지 말고 당신이 직접 행동해라 라는 주제.
🔴 왜 직접 바꾸지 않습니까?
🤔 그러게요.
직접 행동하기엔 현재 업무가 과도하다는 핑계일 수도 있고, 단순한 게으름일 수도 있겠지…
⚫ 당신은 당신의 조직을 바꾸거나. 당신의 조직을 바꿀 수 있다.
🤔 당신의 ‘조직’을 변화시키거나, 이직하거나 라는 소리. 둘 다 쉽지 않은 길. 현재 조직을 바꾸기에는 먼저 조직의 구성원들의 공감대가 우선되어야 하기 때문에, 하나 하나 설득하는 길이 멀고 지난할 것이다. 우선 나부터가 남의 말을 듣고 잘 듣는 편은 아닌 거 같아서... 용케도 설득이나 협박 등을 통해 공감대가 이루어진다 한들, 윗 사람들을 또 설득하고, 결국 시스템적인 변화를 일으키는 것 또한 쉽지가 않다. 그래서 비교적 쉬운 길인 이직을 대부분 선택하는 듯 하다.
⚫ 기술에 뒤쳐지는 기분이 든다면 여가 시간을 쪼개서 재미있어 보이는 것을 공부하라. 여러분 자신에게 투자 하는 것이니 업무 외 시간에 하는 것이 옳다.
🤔 이 또한 쉽지 않다...업무 시간에 어느 정도의 스터디는 해도 되지 않을까! 라는 생각이 들면서도 지나친 스터디는 회사 업무에 지장이 될 수도 있겠단 생각도 든다. 그 적정선은 무엇일까
총평
🤔 어느 회사에 몸을 담고 있던, 불평 불만은 나올 수 밖에 없다. 회사의 비즈니스 모델이나 노사 문제를 두고 불평할 수도 있겠지만, 개발자들은 특히나 회사가 추구하는 기술적인 비전이나 기술 문화에 대해 아쉬운 점을 토로할 때가 많다. 휴.. 하필이면 첫 토픽이 이런거라니… 너무 불평만 하지 말고 할 수 있는 데로 최선을 다해보고, 그래도 안되면 직장을 옮기라는 따끔한 한마디. 게으름과 안일함에 취한 나에게 하는 팩폭같기도 하다.
Topic 2. 고양이가 내 소스 코드를 삼켰어요.
🤔 본인이 한 일에 책임을 지라 라는 주제
🔵 실용주의 프로그래머는 자신의 경력에 대해 책임을 지고, 자신의 무지나 실수를 주저 없이 인정한다.
🤔 이게 실용주의랑 무슨 상관이지? 응당 그래야하는거 아닌가?! 하지만 안타깝게도 책임없는 쾌락을 누리려는 개발자들이 종종 보이는게 현실이다
⚫ 우리는 자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점도 인정해야만 한다.
🤔 언제든 실수하고 틀릴 수 있음을 인정하라는 말로 들린다. 감정적으로 어려울 수 있지만 그게 가능하기 위해선…
🔴 팀 내 신뢰
🤔 책임을 질 수 있도록 하는 전제조건이자 분위기. 이게 아주 상당히 매우 중요하다. 자신의 실수를 인정하지 않은 큰 이유 중 하나가, 실수를 용납하지 않는 팀 분위기일 수 있기 때문...
책임지기
⚫ 실수를 저지르거나(누구나 실수를 한다) 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라.
🤔 이것 또한 사실 팀 내 신뢰가 밑바탕이 되어야 한다. 사실 개인의 책임이란 존재하지 않는다고 생각한다. 팀에 합류한 지 얼마 되지 않았다거나, 팀이 새롭게 조직되어서 히스토리를 아는 사람이 혼자뿐이라던가, 그런 특수한 상황만 아니라면 팀 모두의 책임이다. 그러기 위해서 코드 리뷰와 작업 공유는 반드시 되어야 할 것!
🔵 해결책을 찾아내야 하는 사람은 여러분이다.
🤔 맞다. 아무리 개인의 책임을 팀의 책임으로 분산한다고 하더라도, 본인이 관여한 이슈에는 본인이 직접 해결책을 찾는게 맞다. 실제로 적합한 해결책을 찾는 건 다른 사람일 수도 있지만, 해결책을 찾는 행동은 무조건 해야한다. 그것이 책임감이니깐.
🔵 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해보라.
🤔 다시 한번 말하지만, 변명이 나오지 않게 만드는 팀 분위기가 중요하다. 변명 대신 성찰과 회고가 이루어지는 팀 분위기가 만들어지길...
도전
⚫ 여러분이 “잘 모르겠어요.”라고 말했다면, 꼭 바로 이어서 “하지만 알아볼게요.” 라고 말하라. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다.
🤔 아직 나에게도 어려운 일이지만, 무지를 인정하되 포기하지 않는 정신머리를 가지도록 노력 중
총평
🤔 자신의 행동에 대해 책임을 지는 게 어른이니만큼, 이 Topic은 비단 프로그래밍이라는 직업적 관점에서만 들여다봐야할 내용은 아닌 거 같다. 언뜻 자기계발서 내용같은 단락이긴 했는데, 어떻게 보면 개발 영역이 성역은 아니라는 점을 시사한다. 개발자라고 책임을 회피할 명분은 없다!
Topic 3. 소프트웨어 앤트로피
🔵 ‘깨진 창문’을 고치지 않은 채로 내버려 두지 말라.
🤔 윽…너무 찔리는 말이다. 이미 깨진 유리창같은 시스템이니, 마음의 가책을 느끼지 말자라고 스스로 되뇌이는게 어디 한두번이가. 물론 그렇다고 코드를 어지럽히고 있지는 않지만…이미 깨진 유리창은 어쩔 수 없지! 라는 생각이 아직 확고하다.
🔵 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라.
🤔 그…그래도 판자는 덮고 있다. 기존 코드에 영향이 없는 정도의 간단한 리팩토링 (메소드 추출이나 리네이밍)은 하거나, 주석정도는 달고 있으니…
적절히 고칠 시간이 부족하다기 보단, 기존 운영 코드를 고쳤다가 사이드이펙트가 생겨나는 걸 두려워하는것 같다. 흠…이걸 방지하기 위해선 적절한 테스트코드들이 필요할텐데… 요 대목에서야 시간이 없다. 라는 이유가 들어맞는다. 사실 핑계지.
도전
⚫ 창문이 처음 깨졌을 때 목소리를 낼 수 있겠는가? 여러분의 반응은 무엇인가?
🤔 이게 맞나..? 이래도 되나…? 지금은 일단 이렇게 해도 되지 않을까? 두 번째 깨졌을때 뭔가 행동을 하면 되지 않을까? 라는 식으로 주저하곤 한다. 사실 두 번째 깨졌을 떄 행동하는게 나쁘지 않을지도 모른다. 실제 창문이 깨진다면 누구나 그 사실을 알겠지만, 소프트웨어에서는 때때로 이게 정말 깨진건지, 깨진것처럼 보이는 디자인인지, 불가피하게 깨뜨린건지 애매할 때가 있으니...
총평
🤔 자연 세계에서 엔트로피는 항상 증가하는 것 처럼, 지금 개발하고 있는 코드의 대부분은 무질서도가 증가한다. 하지만 개발자의 역량과 관심에 따라, 그 무질서도가 늘어나는 속도가 줄어들수도 있고, 심지어 되돌려질 수도 있다. 하지만 쉽지 않다.
'성장의 흔적 > 실용주의 프로그래머를 읽고' 카테고리의 다른 글
| [실용주의 프로그래머]를 읽고 #2. 1장. 실용주의 철학. Topic 4 ~ 5. (1) | 2025.01.28 |
|---|
