[한상호] 5,6장: 영웅, 선의 그리고 프로페셔널리즘 & 동작하는 소프트웨어

5장/한상호.md

@@ -0,0 +1,21 @@
+# 🔖 Ch5. 영웅, 선의 그리고 프로페셔널리즘
+
+> 작성 일자 : 2024.10.31 / 작성자 : 한상호
+## 💫 기억에 남는 문구
+- `p.105` : 프로젝트는 전형적인 폭포수 방식으로 진행되었다. 이 프로젝트에서 일했던 2년 반 동안 나는 고객을 한 번도 만난 적이 없다.
+- `P.107` : 우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다. 고객을 만날 수도 없기는 했지만, 요구사항에 대해서 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다. 그때는 그것이 프로페셔널이라고 생각했다.
+- `p.108` : 우리는 전혀 프로답지 못했다. 한번도 '아니오'라고 말하지 않았기 때문이다.
+- `p.113` : 이미 불가능하다고 알고 있는 것에 대해 '해보겠다'고 말하지 말았어야 했다.
+- `p.115~116` : 언뜻 보기에는 긍정적인 사고방식같지만, 그 이면에는 대단히 이기적인 욕구가 숨어 있다. '네'라고 말할 때 사람들은 그 말을 믿고 그에 의존해서 계획을 짠다는 것을 반드시 기억해야 한다. (중략) 프로페셔널리즘은 나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다.
+- `p.117` : 우리가 '아니오'라고 대답해야 하는 상황에서도 항상 '네'라고 말할 방안을 탐색해야 한다.
+- `p.118` : 아무리 나쁜 상황에서도 우직한 정직함을 보여줄 수 있다면 프로페셔널의 조건 중 하나를 갖춘 것이다.
+- `p.122` : 왜냐하면 문제를 숨기지 않고 드러내는 태도는 모두가 하나의 팀으로서 공동의 목표를 위해 일하고 있다는 징표이기 때문이다.
+
+## 💡 느낀 점
+1. 이전에 개발자들이 받았던 취급을 보면서 마음이 아팠다...모든 개발자들이 그렇지는 않았겠지만, 이전에는 지금과 같이 개발자들이 인정 받지는 못 했을 것이다. 우리나라도 IT 산업이 발전하고, 개발자들이 IT 회사를 창업하며 개발자들이 중요한 인력이라는 인식이 생긴 것 같다. 몇십년 전부터 이 길을 걸어온 선배 개발자들을 향해 존경하는 마음이 드는 부분이었다. 
+2. 주변을 보면 개발자들의 취업이 너무 어려워졌다고, 예전과 너무 달라서 힘들다는 친구들이 많다. 물론 이 또한 사실인 것은 맞다. 경기가 어려워 취업 문이 좁아지기도 했고, 개발자들의 실력이 상향평준화 되며 신입 개발자들의 수준이 많이 올라갔다. 하지만 이 또한 이유가 있다고 생각하는데, 이전보다 훨씬 개발자로서 학습하기가 쉬워졌기 때문이다. 이전에는 지금과 같이 AI와 함께 개발하는 것을 상상이나 할 수 있었을까? 지금은 구글에만 검색해봐도 관련한 레퍼런스가 수백 개가 나오는데, 이전에는 직접 이런저런 방법으로 트러블 슈팅을 했을 것이다.
+3. 중요한 것은 취업 시장, 주변 동료들의 실력이 아니고 순수한 '내 실력'인 것 같다. 나만의 가치를 만들기 위해 끊임없이 노력한다면 분명 누군가는 알아줄 것이고, 좋은 개발자가 될 수 있을 것이라고 생각한다. 취업을 한다고 모든 것이 끝나는 것이 아님을 알면 마음이 한결 편해진다. 어차피 취업해서도 계속해서 학습하고 성장해나가야한다. 그렇기에 나는 길게 보고 꾸준히 달릴 수 있는 마인드를 갖는 것이 더 중요하다고 여긴다.
+4. 큐시즘 29기 프로젝트를 할 때, 나는 정말 개발자로서 많이 부족하다고 느꼈기 때문에 순수하게 '노력'만 했다. 어떤 기능을 구현해달라고 했을 때 전혀 의문을 가지지 않았고, 중간에 요구사항이 변경되거나 일정 상 무리한 요구가 있어도 무조건 '해보겠다'고 말했다. 물론 이 과정 속에서 나의 한계를 넘어 보기도 하고 강제로 많은 학습을 할 수 있었지만, 결론적으로 '앞으로 이렇게 프로젝트를 하면 안되겠다'는 걸 느꼈다.
+5. 일정 내로 모든 걸 완수했을 때 정말 뿌듯했다. 하지만 열심히 만든 기능이, 유저들에게는 전혀 납득되는 기능이 아니었음을 깨닫았을 때 큰 허탈감을 느꼈다. 그때 나는 '이제 다음부터는 꼭 기획 단계부터 목소리를 내야겠다'라는 생각을 하게 되었다.
+6. 다행히 이번 30기 기업 프로젝트에서는 이를 적용할 수 있었던 것 같다. 초기부터 우리가 만들고자 하는 것이 무엇이고, 이것이 왜 필요한지를 충분히 이해하고 시작했다. 의문점이 있을 때는 빠르게 질문했고, 진행상황은 최대한 빠르게 공유하려고 노력했다. 또한 할 수 있는 한 최선은 다하되, 불가능해 보이는 것에 대해서는 '아니오'라고 말했다. 그 결과 팀으로써 함께한다는 느낌을 받으며 프로젝트를 성공적으로 마무리할 수 있었고, 과정 속에도 많은 걸 배울 수 있었다.
+7. 최근 이러한 경험을 했었기 때문에, 이번 5장의 내용에 많이 공감이 되고 확실히 이해할 수 있었던 것 같다.

6장/한상호.md

@@ -0,0 +1,17 @@
+# 🔖 Ch6. 동작하는 소프트웨어
+> 작성 일자 : 2024.10.31 / 작성자 : 한상호
+## 💫 기억에 남는 문구
+- `p.128` : 코드는 기계장치라기보다는 유기물이다.
+- `p.132` : 코드 구현에 사용된 용어들이 비즈니스 용어들과 따로 놀고 있었다. 그 기능을 구현하는 것과 전혀 상관 없는 코드들도 눈에 보였다. 그리고 테스트 코드가 없었다.
+- `p.132` : 백로그에 기술적 부채를 더하는 행위는 개발자가 코딩을 하던 당시에 아무런 죄책감 없이 잘못된 코드를 그대로 반영했다는 것밖에는 설명이 안된다.
+- `p.133` : 우리는 압박을 받는다고 느낄 때 중심을 잃고 고만고만해진다. 게으른 탓이 아니다. 더 빨리 해야 한다고 느끼기 때문에 그렇게 한다. 비즈니스에서 필요로 하는 기능을 최대한 빨리 끝내는 것이 개발자로서 미덕이라고 느끼고 있다.
+- `p.137` : 자동화된 테스트를 만들고 활용하는 데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다.
+- `p.138` : 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다.
+- `p.142` : 아무리 한탄하고 불평하고 저주해보았자 삶이 쉬워지거나 나아지지 않는다는 점이다. 무언가 나아지길 원한다면 그에 맞는 행동을 취해야 한다.
+- `p.144` : 이때 우리는 두 가지 관점 중 하나를 선택할 수 있다. 하나는 지금 하고 있는 일을 고통스런 전생의 업보로 보는 것이고 다른 하나는 재미있고 도전적인 문제로 바라 보는 것이다.
+
+## 💡 느낀 점
+1. 이전에는 코드를 작성해서 돌아가는 기능을 만드는 것에 많은 초점을 두었었다. 지금에서야 그 당시를 떠올리면 아쉽고 부끄럽지만, 다시 돌아가도 똑같은 행동을 했을 것 같다. 실력이 부족하기 때문에 넓게 볼 여유가 없었고, 그래서 당장 만들어야 하는 것만 쳐내기도 벅찼기 때문이다. 하지만 이제는 타협할 수 없다고 생각한다.
+2. 이번 30기 밋업 프로젝트를 하며 테스트 코드를 작성하고 있다. TDD는 아니지만 그래도 테스트코드를 작성하고 있음에 의미를 두고 있다. 앞으로는 테스트 코드까지 작성하고 테스트 완료가 되었을 때에만, 기능 구현이 완료되었다고 여겨야겠다는 생각이 들었다.
+3. 나도 '나중에 해결해야지, 나중에 리팩토링해야지' 하며 일을 자주 미뤘던 것 같다. 당연히 나중에 실제로 한 적은 거의 없었다. 그렇기에 문제가 있다면 시간을 내서라도 바로바로 해결하려는 자세를 가져야겠다.
+4. 아무리 한탄하고 불평해봤자 달라지지 않는다는 점에 크게 공감한다. '피할 수 없다면 즐겨라'라는 말이 그냥 있는 것이 아니라고 생각한다. 어떠한 문제가 생겼다면, 너무 고통스러워하지말고 오히려 인생에 재미있는 이벤트가 하나 생겼다고 여기며 즐기는 마인드가 좋은 것 같다.