Docs: 박승훈 9장 (#80)

9장/박승훈.md

@@ -0,0 +1,304 @@
+## Topic 49 : 실용주의 팀
+
+> "개인이 혼자 실용주의를 따라도 이점이 있지만, 그 개인이 실용주의 팀에서 일한다면 그 이점이 몇 배로 더 커진다."
+
+<br />
+
+### 실용주의 팀은 작다.
+
+- 작고 안정적인 팀을 유지하라.
+- 구성원은 대략 10~12명 이하여야 한다.
+- 구성원이 추가되거나 빠지는 일은 드물어야 한다.
+- 모두가 서로 잘 알고, 신뢰하며, 의존해야 한다.
+
+<br />
+
+### 깨진 창문을 없애라.
+
+> "품질은 팀의 문제다."
+
+- 팀 전체가 깨진 창문을 용납하지 않아야 한다.
+- 사소한 결점을 아무도 고치지 않고 놔두어서는 안 된다.
+- 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다.
+
+<br />
+
+> 나의 생각
+
+- 리팩토링은 계속 개발과 함께 겸해야 한다는 말과 일맥상통하다고 느꼈다.
+- 팀원들의 눈에 그리 띄지 않는 사소한 부분을 고치는 것은 생각보다 어렵다. 중요한 부분의 결함은 당장 고쳐진다. 방치되는 결함은 그만큼 시선 밖의 일이다. 시간과 노력을 들여 고치더라도 누구도 알아주지 않을 것이라 생각했고 실제로도 많은 부분이 그랬다. 이런 부분을 그냥 넘어가지 않기 위해서는 개발 문화적인 성숙도나 작은 일을 중요하게 여기는 분위기가 필요하다고 생각한다.
+
+<br />
+
+### 삶은 개구리
+
+> "팀은 개인보다 삶은 개구리가 되기 쉽다."
+
+- 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라.
+- 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다.
+- 일어난 변화를 거부하는 것이 아닌, 그런 일이 벌어지고 있다는 것을 파악하고 있으면 된다.
+
+<br />
+
+> 나의 생각
+
+나는 보통 그러려니 하는 무던한 성격, 어쩌면 둔한 성격인데 이런 기질을 벗고 보다 더 예민하게 감지할 수 있도록 노력해야겠다.
+
+<br />
+
+### 지식 포트포리오를 계획하라.
+
+> "시간이 나면 그때 하겠다는 것은 '영원히 하지 않겠다'는 것이다."
+
+- 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다.
+- 새로운 기능을 만드는 것 외에도 해야 할 들이 있다.
+
+<br />
+
+- 구형 시스템 유지 보수
+  - 반드시 수행하라.
+  - (구형 시스템에서 개발을 해야 하면 떨어진 DX에 불평만 했던 나는 반성하게 된다.)  
+
+- 프로세스 회고와 개선
+  - 지속적인 개선이 일어나려면 주위를 둘러보고 무엇이 잘 되고 그렇지 않았는지 확인해야 한다.
+  - 그런 다음 변화를 일으킬 시간이 있어야 한다.
+  - 너무나 많은 팀이 물을 퍼내기에 급급해서 물이 새는 곳을 고칠 틈이 없다.
+  - (비유가 너무 적절한 것 같다. 물이 새는 곳을 고치자.)  
+
+- 새로운 기술 탐험
+  - 새로운 것을 시도해보고 결과를 분석하는 업무를 일정표에 추가하라.  
+
+- 학습 및 기술 갈고 닦기
+  - 개인적으로 배우고 역량을 키우는 것은 좋은 시작점이다.
+  - 하지만 많은 기술이 팀 전체로 퍼졌을 때 더 효과적이다.
+  - 팀원들을 전도할 계획을 세워라.
+  - (내가 개인적으로 해보고 전도할 수 있도록 개인적으로 많이 파보자.)
+
+<br />
+
+### 반복하지 말라.
+
+- 여러분은 팀 동료에게 질문을 하고 거의 즉각적으로 답을 받을 수 있어야 한다.
+- DRY를 지키려면 서로 관심을 유지하라.
+
+<br />
+
+### 자동화
+
+- 자동화는 모든 프로젝트 팀에게 필수 불가결한 요소이다.
+- 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라.
+
+<br />
+
+> 나의 생각
+
+CI/CD나 인프라 부분, 아니면 개발 부분에서도 팀의 기반이 되는 지식이 부족한 것 같다. 순수 프론트엔드 개발 외적으로 이런 주변 지식과 기반 기술을 많이 익힐 수 있도록 해보자.
+
+<br />
+
+## Topic 50 : 코코넛만으로는 부족하다.
+
+> "형식만 흉내내고 내용이 빠지면 결국 도달할 수 없다."
+
+눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망한다.
+
+<br />
+
+### 만병통치약은 아무 병도 못 고친다.
+
+- 소프트웨어 개발 방법론의 목표는 **사람들이 함께 일하는 것을 돕는 것**이다.
+- 기존의 규칙 너머를 보고 개선의 여지를 찾아내는 능력이 필요하다.
+
+<br />
+
+> 나의 생각
+
+- 만병통치약은 아무 병도 못 고친다는 비유가 뭘 의미하는지 감이 잘 안 오는 것 같다.
+- 기존의 규칙 너머를 보고 개선의 여지를 찾아내는 것. 비판적이고 날카로운 사람들이 잘하는 일인데 무딘 나에게는 부족한 능력이라 더 키우고 싶다. 더 주의를 기울이고 노력해보자.
+
+<br />
+
+## Topic 51 : 실용주의 시작 도구
+
+### 가차 없고 지속적인 테스트
+
+> "우리는 지금 당장 버그를 찾아 나서도록 자신을 몰아세우지만, 덕분에 나중에 다른 사람이 자기 버그를 발견하게 되는 상황을 피할 수 있다."
+
+많은 개발자들이 무의식적으로 코드가 어디에서 깨지는지 파악하고서는 약한 지점을 피해 다니면 살살 테스트하려 한다. 하지만 우리는 달라야 한다.
+
+<br />
+
+### 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
+
+> "모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다."
+
+- 코드를 작성하자마자 테스트해야 한다. 작은 버그는 꽤 빨리 자라난다.
+- 테스트 코드를 만들기 위해 들이는 시간에는 그 노력만큼의 가치가 있다.
+- '진짜 상황 테스트'를 목표로 하는 것이 중요하다.
+- 테스트 환경은 실제 환경과 최대한 비슷해야 한다.
+
+<br />
+
+**단위 테스트**
+
+- 하나의 모듈을 테스트하는 코드
+- 다음 단계로 넘어가기 전 모든 모듈의 단위 테스트가 반드시 통과해야 한다.
+
+<br />
+
+**통합 테스트**
+
+- 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다.
+- 시스템에서 버그가 가장 많이 나오는 부분이 모듈을 통합하는 부분인 경우가 많다.
+
+<br />
+
+**유효성 평가 및 검증**
+
+- 정말 사용자들이 필요로 하는 것인가?
+- 시스템의 기능적 요구 사항을 충족하는가?
+
+<br />
+
+**성능 테스트**
+
+- 소프트웨어가 실세계 조건에서 성능 요구 사항들을 준수하는지 자문해 보라.
+- 부하를 현실적으로 시뮬레이션 하기 위해 특화된 테스트용 하드웨어나 소프트웨어가 필요할 수도 있다.
+
+<br />
+
+**테스트를 테스트하기**
+
+- 어떤 버그를 감지해 내는 테스트를 작성한 후에, 그 버그가 의도적으로 생기도록 하라.
+- 그리고 테스트가 경보를 울리는지 확인하라.
+
+<br />
+
+> 나의 생각
+
+테스트 코드의 테스트를 고려해본 적은 없는 것 같다. 더 철저한 검증 수단을 위해 테스트 코드 개발을 하게 된다면 고려해 봐야겠다.
+
+<br />
+
+### 그물 조이기
+
+> "버그는 한 번만 잡아라."
+
+- 버그가 기존 테스트의 그물을 빠져나갔다면 다음번에는 그걸 잡아낼 수 있도록 새 테스트를 추가해야 한다.
+- 한번 인간 테스터가 버그를 잡았아면 더는 인간 테스터가 그 버그를 만나서는 안 된다.
+
+<br />
+
+> 나의 생각
+
+테스트에 대해서 반신반의하는 생각들을 많이 가지고 있었는데, 이 책의 전반적인 내용들에서 테스트 코드의 중요성과 운영 방법들에 대해 끊임없이 언급하고 강조한다. 그러다보니 세뇌되듯이 필요한 게 맞는 것 같다며 생각이 들었다. 테스트를 슬슬 현업에 접목해보는 게 괜찮을지도...
+
+<br />
+
+## Topic 52 : 사용자를 기쁘게 하라.
+
+> "개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다."
+
+나는 이 대목을 보며 어쩌면 기획자가 이 기쁨을 주는 1차적인 대상이라고 생각이 들었다.
+
+<br />
+
+### 사용자들이 기대하는 것을 아는 방법
+
+> "이 프로젝트가 끝나고 우리가 성공했는지 어떻게 알 수 있을까요?"
+
+- 대답은 예상 범위 내일 수도, 예상을 한참 벗어난 의외일 수 있다.
+- 소프트웨어 프로젝트 자체가 아니라 (의외의) 성공 척도가 진짜로 의미 있는 사업 가치다.
+- 소프트웨어는 이런 목적을 달성하기 위한 수단일 뿐이다.
+
+<br />
+
+### 사용자의 기대를 충족시키는 방법
+
+- 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라.
+  - (선택장애에게 도움이 되는 말이었다. 물론 어려운 게 사실이다.)
+- 사용자 요구사항을 비판적으로 분석하라.
+  - 요구사항은 비전문가의 구현 계획일 뿐이다.
+  - 요구사항을 바꿔서 더 쉽게 해결할 수 있다면 제안하라.
+- 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.
+  - (프로젝트의 본질을 잃지 말라는 말 같다.)
+  - (개발자로서, 기술자로서 기술에 매몰될 때가 많다. 사업적 가치와 사용성을 잃지 말자.)
+
+<br />
+
+### 고객을 기쁘게 하고 싶다면
+
+- 고객이 문제를 풀 때 적극적으로 도와줄 수 있는 관계를 구축하라.
+- 진정한 여러분의 직함은 "문제 해결사"다.
+- 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다.
+- 우리는 문제를 해결한다.
+
+<br />
+
+> 나의 생각
+
+프로그래머는 문제를 해결하는 사람이라는 말을 이 책에서 언급됐는지 어디서 들었는지 모르겠다. 하지만 아무튼 코드를 멋지게 짜는 것만이 다가 아니라, 기술 외적인 부분에서 개발자로서의 역할과 능력을 보일 수 있는 부분을 제안한 것 같다. "우리는 문제를 해결한다." 라는 한 문장으로 토픽을 마친 게 꽤나 멋진 마침표였다고 생각했다.
+
+<br />
+
+## Topic 53 : 오만과 편견
+
+> "자신의 작품에 자신 있게 서명하라."
+
+- 실용주의 프로그래머는 책임을 회피하지 않는다.
+- 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다.
+
+<br />
+
+> 나의 생각
+
+코드리뷰를 앞두거나 코드적인 피드백을 받을 때, 좋은 성장의 기회로 여기면서도 어떤 말로 내가 정곡을 찔릴지, 아쉬운 실력에 대한 피드백을 받을지 두렵기도 했다. 실제로 지금도 부족하다고 생각하고 더 좋은 코드를 위해 고민하고 노력하고 있는 것 같다. 언젠가 내 작품에 자신 있게 서명할 수 있도록 좋은 개발 실력과 경험을 쌓아가고 싶다.
+
+<br />
+
+### 함께 일하기
+
+- 다른사람의 코드를 존중해야 한다.
+- 개발자 사이에 황금률("남에게 대접받고자 하는 대로 너희도 남에게 대접하라.")과 상호 존중이라는 기반이 필요하다.
+
+<br />
+
+> 나의 생각
+
+마지막 토픽은 큰 내용은 없지만 잔잔한 울림을 주는 것 같다. 결국 함께 일하기 위해 겸손하고 남을 존중할 것, 그리고 자신 있게 내 것을 만들기 위해 떳떳하고 당당하게 개발에 임할 것. 프로그래머로서의 자세를 다시 한 번 되돌아보게 하는 짧은 토픽이자 책의 마침표였다.
+
+<br />
+
+## 맺는말
+
+> "우리 개발자들은 엄청난 특권을 가졌다. 우리가 진짜로 미래를 빚고 있다."
+
+- 이건 놀라울 정도로 큰 힘이다. 그리고 이 힘에는 비상한 책임이 따른다.
+- 의도치 않은 이 힘의 대가로 우리는 늘 경각심을 가져야 한다. 우리의 행동이 사람들에게 영향을 준다.
+- 우리가 내놓은 모든 코드마다 두 가지 질문을 던질 책임이 있다.
+  1. 사용자를 보호했는가?
+  2. 나라면 이것을 쓸까?
+
+<br />
+
+> 나의 생각
+
+개발자가 현대 사회에 가지는 무궁한 영향력에 대해서는 크게 체감한다. 일례로 내가 몸담고 있는 채용사이트와 지원서 개발은, 개발적인 허점으로 한 회사의 채용 공고 전체를 날려버릴 수도 있고, 수 천 명의 지원 내용을 통채로 날려버릴 수도 있다. 더 사악하게는 한 사람의 지원 내용이 누락될 수도 있다. 개발자의 입장에서는 작은 버그일 수 있지만, 구직자 한 사람에게는 인생을 가르는 큰일이 되기도 한다. 나는 이런 점에 무거운 책임감, 한편으로는 큰 두려움을 가지고 개발에 임하고 있다. 이 책을 통해 개발자로서의 책임과 자세에 대해 다시 한 번 생각하게 되었다.
+
+<br />
+
+### 여러분이 원하는 미래를 상상하라.
+
+- 우리 모두가 살고 싶은 미래를 만드는 것이 여러분의 책무다.
+- 이런 이상과 반대되는 일을 하고 있다면 "아니요!"라고 말할 수 있는 용기를 가져라.
+- 우리가 가질 수 있는 미래를 그리고, 실제로 그런 미래를 만들어 내는 용기를 가져라.
+
+<br />
+
+> 나의 생각
+
+책 스터디는 사실 1장부터 시작해서 9장으로 마치게 되어있다. 하지만 서문에서 의외의 울림을 얻었던 경험으로부터 맺음말은 꼭 보고 책을 마쳐야겠다는 생각을 하고는 있었다. 역시나 맺음말에서는 프로그래머로서의 자세와 책무를 강조하며 우리가 미래 세대에 줄 수 있는 상당한 영향력에 대한 강조와 당부를 남기며 또 한 번 울림을 주었다.
+
+<br />
+
+책에서 기술적인 스킬들과 일종의 핵을 느끼고 싶어했던 초반의 나에게는 모호하고 추상적인 내용이 많고 실무에 적용하기 힘든 방법론들이 많았던 책이기도 하지만 한편으로는 마인드셋과 과거 세대의 프로그래머가 미래에 남기는 메시지로써의 가치가 큰 책이었다. 좋은 마무리였고, 시간이 조금 지나 또 다시 읽어보고 싶은 책이었다.