더 나은 프로그래머 되는법 5주차 - 권태형

2025/Becoming a Better Programmer/taehyoung/34.md

@@ -0,0 +1,15 @@
+# ch34. 사람의 힘
+
+# 논의 내용
+
+- [질문]
+    - 회사에 기술적으로 혹은 경험적으로 훌륭한 프로그래머가 없다고 가정할 때, 훌륭한 프로그래머를 찾기 위해서 이직을 하는 것은 옳은 선택으로 볼 수 있을까?
+- [질문에 대한 개인 의견]
+    - `훌륭한 프로그래머 주변에 의도적으로 머물라` 라는 팁에 동의하면서도, 최근에는 훌륭한 프로그래머와 같이 일하는 것에 너무 집착할 필요는 없다는 생각을 가지고 있다.
+    - 그 이유는 어떤 환경이든 나 스스로가 훌륭한 프로그래머가 되는 것을 고민하고 실천하는 것 그 자체가 더 중요하다고 생각하기 때문 이다. (현재 기준은 그러한데, 아마도 입사한 지 얼마 안 된 분들을 기준으로는, 환경도 중요하고, 훌륭한 프로그래머와 같이 일하는게 더 도움이 될 수 있다는 생각도 들긴하네요)
+    - 훌륭한 프로그래머와 같이 일하고 싶어하는 욕망 자체가 사실 본질적으론 나 스스로 훌륭한 프로그래머가 되고 싶다는 욕망을 실현 시켜줄 수단에 불가한 것이기에 이에 집착해선 안된다고 생각하는 편 이다. 
+    - 그렇다고 해서, 훌륭하지 않은 프로그래머와 일하는게 좋다는 말은 아닙니다. '훌륭하다'라고 하는 게 대개의 경우는 기술적 역량, 많은 경험 등을 말하는데, 이런 조건을 갖춘 동료와 같이 일하고 싶은 욕구가 저에게도 있습니다. 다만, 흔한 경우에 서비스 규모가 크고 유명한 회사에 갈수록 위 조건이 충족된다고 믿는 경우가 있는데, 저는 그렇게 생각하지 않는 편입니다.
+
+# 내 생각
+
+- 내 개인적으로는 훌륭한 프로그래머 동료와 같이 일하는 것을 매우 선호한다.(다만 집착하진 않는다 과거에는 집착했지만 지금은 그렇지 않다) 여기서 내가 정의하는 훌륭한 프로그래머의 정의는 처음 회사에 들어갔을 때와 지금 기준이 다른데, 처음 회사 들어갔을 때는 기술적 역량이 뛰어난 사람이었고, 지금은 나와 소통이 잘 되고, 본인 스스로 발전하려고 하는 사람이다. 그래서 지금 면접을 보게 되면, 연차와 상관없이 위 조건을 만족하는 사람과 같이 일하는 것을 선호한다(물론 위 조건에 더하여 기술적 역량까지 매우 뛰어나다면 너무 좋다)

2025/Becoming a Better Programmer/taehyoung/35.md

@@ -0,0 +1,11 @@
+# ch35. 생각이 중요하다
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 책에서 말하는 `의무감` 은 `주인의식` 으로도 볼 수 있을 것 같다.
+- 책에서 말한 기준의 경우, 나는 인수조건을 기준으로하고 있다. 인수조건은 일종의 체크리스트로 볼 수 있다. 내가 이 프로젝트의 작업을 완료를 했다는 최종적인 체크리스트이고, 이는 고객향으로 작성이 되어야 하며, 고객의 입장에서 체크가 되어야 한다
+- 마치며에는 나오는 `프로그래머 상호 간의 의무감을 위해서는 일정 수준 이상의 용기가 있어야한다. 비판을 기꺼이 받아들여야 한다` 에 매우 동의하는 바이다. 내가 여태까지 겪은 한국사회는 비판을 피드백이 아닌 비난(blame)으로만 생각하는 경향이 많은 것 같다. 아이러니 하게도 코드에서는 이런 경향이 덜한데, 개인적으로 매우 올바른 방향으로 보고, 코드에서 적용한 것처럼 여러 분야에도 적용해볼 수 있을 것이라 생각한다

2025/Becoming a Better Programmer/taehyoung/36.md

@@ -0,0 +1,13 @@
+# ch36. 말하기!
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 명백하고 애매모호하지 않게 코드를 작성한다는 얘기는 코드에 작성자의 의도가 잘 드러난다는 뜻과 같다고 할 수 있고, 그 역도 성립한다고 생각한다
+- 책에서 코드 작성보다 더 자주 읽히기 때문에, 코드 작성을 읽기에 최적화 해야한다라는 말에 나는 반대한다 그 이유는 이 읽기에 최적화 해야한다는 말을 오해해서, 본인 스스로 생각했을 때 혹은 특정 책에서 주장하는 읽기 좋은 코드 라는 애매모호한 기준을 적용하는 경우를 많이 경험 하였기 때문이다.
+    - 면접 전 지원자의 이력서를 보면, 본인이 클린코드와 읽기 좋은 코드를 지향한다고 하는데, 실제로 구체적으로 어떤 것인지 물어볼 때, 구체적으로 답변을 주는 지원자를 제 기준에선 아직 한명도 못 봤는데 개인적으로 아쉬운 부분입니다
+- 내 개인적으로, 가장 중요한 것은 작성자의 의도와 유지보수성 이다. 의도를 이해할 수 있다면, 사실 상세 구현은 그게 클린코드의 어떤 기법을 따랐는지, 아닌지는 별로 중요하진 않은 것 같다 또한 대개의 경우는 유지보수가 필연적이기 때문에 유지보수성은 중요하다고 생각한다
+- 의사소통의 경우도 코드와 마찬가지인데, 명백하고 애매모호하지 않게 의도가 잘 드러나게 해야한다 라는 관점에서는 큰 차이는 없다고 생각한다

2025/Becoming a Better Programmer/taehyoung/37.md

@@ -0,0 +1,10 @@
+# ch37. 선언문
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 개인적으로 선언문 이라는게 그렇게 중요한지에 대해선 잘 공감하진 못하는 편이다. 참고자료 정도로는 볼 수 있을 것 같다.
+- 회사에서도 비슷한 것이 있는데, 주로 우리 회사에서 추구하는 가치와 관련된 내용들이였다. 근데 문제는 탑다운으로 정해지고 직원들에게 공유가 되었고, 개수도 많다보니 일단 무엇이 있었는지 잘 기억도 안나고, 저런 선언문, 회사에서 정한 5대가치 이런 것들이 제대로 실천 조차 안된다면, 사실 있으나 마나 한것이라고 생각하는 입장이다. 현재 회사에서도 사실상 있으나 마나한 것으로 되어버린 상황이다보니, 더 공감이 잘 되지 못하는게 아닐까 생각된다

2025/Becoming a Better Programmer/taehyoung/38.md

@@ -0,0 +1,11 @@
+# ch38. 코드 찬가
+
+# 논의 내용
+
+- 나와 같이 일하는 동료와의 업무역량의 차이가 있을 때, 본인은 어떻게 하시는지에 대해서 얘기해보면 좋을 것 같습니다(본인의 역량이 좋든, 혹은 나쁘든)
+    - 본인 > 동료
+    - 본인 < 동료
+
+# 내 생각
+
+- 내 기준으로는 무언가 업무를 잘 수행하기 위해서, 코드도 잘 정리되고, 구조화될 수 있도록 노력하는 반면에, 그것에 동의하지 못하거나 혹은 동의는 하나, 역량이 따라오지 못하는 동료들도 분명히 있다. 이런 동료들을 대하는 태도는 두가지로 나뉠 수 있는데, 그저 비판적으로 대하면서, 불평불만을 말하는 것과 어떻게든 더 좋은 방향으로 이끌기 위해서 노력하는 것이다. 사람의 본능상 내 마음대로 되지 않았을 때, 짜증이 나는 것은 어쩔 수 없는 것 같다. 현재 주어진 상황이 쉽지 않더라도, 이 상황을 어떻게 해결할 수 있을지를 고민하고 시도하는게 더 옳은 방향이라고 생각하기 때문에, 나의 경우는 어떻게든 더 잘 될 수 있는 방향으로 시도해보는 편이다. 다만, 내가 아무리 노력하더라도, 상대의 마음이 변하지 않는다면 이는 어쩔 수 없는 것이기 때문에, 만약 잘 안되더라도 내가 마음의 상처를 입거나 스트레스를 받을 필욘 없다고 생각하고, 이런 경우는 상위 직책자에게 말을 해서, 문제를 해결하던지, 그대로 문제를 해결하지 못한다면, 그냥 어쩔 수 없는 것이라고 생각하는 방법 밖에 없을 것 같다

2025/Becoming a Better Programmer/taehyoung/39.md

@@ -0,0 +1,11 @@
+# ch39. 태도가 핵심이다
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 사실상 이 책에서 가장 중요한 부분이 아닐까 싶고, 작가가 의도적으로 맨 마지막에 배치한게 아닐까? 라는 생각이다
+- 꼭 프로그래밍이 아니더라도, 태도는 매우 중요하다. 태도는 마음가짐으로도 말할 수 있는데, 아무리 능력이 좋더라도, 마음가짐이 제대로 정립되어있지 않다면, 올바르게 나아가기 어렵기 때문이다.
+- 초심으로 돌아가야한다라는 말도 같은 맥락에서 이해할 수 있다 사람의 마음가짐은 대개 시간이 지날 수록 익숙해지면서, 느슨해 지는데, 초심을 다진다는 말은 이 느슨해지는 마음가짐을 다시 챙기겠다는 의지표현이다

2025/Becoming a Better Programmer/taehyoung/부록-1.md

@@ -0,0 +1,10 @@
+# 미래 기술의 열쇠, 생성형 AI를 활용한 프로그래머
+
+# 내 생각
+
+- 저자는 결론적으로 변화하는 환경에 맞춰서 최적의 결과를 내는 사람이 되어야한다고 말을 하는데, 구체적으론, 설계 역량의 중요성을 말하고 있고, 그 외의 구체적인 코드 구현은 AI에게 맡겨야한다고 주장하고 있다
+- 동작하는 코드, TDD 등을 언급하며, AI는 구체적인 코드를 작성하는데에 집중하고, 핵심적인 설계 부분은 인간이 담당해야함을 말한다
+- 이부분에 대해서는 굉장히 동의하는 바이다. 앞으로 LLM 모델이 발전하면 할수록, AI 코드 구현 능력은 점점 더 발전할 것이기 때문이다.
+- 그래서, 개발자들이 AI 때문에, 직업을 잃을 것이라는 전망은 일부 설계역량이 떨어지는 코드 작성 자체만 하는 개발자들이지 않을까 생각된다. 외국에도 보면, 외주 SI 업체들이 많은데, 그 인력들이 아마도 AI 로 대체되지 않을까 라는 생각이다
+- 반대로, 전체 큰그림을 보고, 설계를 할 수 있는 개발자이면서, 혼자서 AI를 다뤄서 개발할 수 있는 역량까지 있다면, 굳이 회사에서 일을 하지 않고, 개인단위의 1인 사업자들도 많이 생기지 않을까? 하는 예상이다
+- 나의 경우도 올해의 목표가 앱을 출시해서, 1달러벌기 인데, 생각보다 바이브코딩의 질이 좋아서 매우 놀랐었다

2025/Becoming a Better Programmer/taehyoung/부록-2.md

@@ -0,0 +1,17 @@
+# 훌륭한 프로그래머이자 팀플레이어 되는 법
+
+# 논의 내용
+
+[질문]
+
+- 직군 간에 사일로 현상 없이, 팀워크가 갖춰진 팀을 구성하는 본인만의 방법 혹은 경험이 있다면 말해보면 좋을 것 같습니다.
+
+[질문에 대한 개인 답변]
+
+- 제 경험을 공유드리자면, 저는 환경적인 요인이 중요하다고 생각하는데요, 여러 직군을 한 팀으로 묶어서 일하도록 하는 것입니다. 흔히 크로스 펑셔널 팀이라고 부르는데, 이렇게 팀을 구성하는 것의 장점은 직접 경험해보지 않고서는 알 수가 없을 정도인데요, 그냥 한 팀으로, 자리도 붙여서 앉고 하는 것 정도의 환경을 만드는 것만으로도, 신기하게 직군 간 사일로 없이 일을 더 수월하게 한 경험이 있습니다.
+- 현재는 조직구조가 개편되어서, 크로스 펑셔널 팀에서 기능조직(직군 끼리 팀을 조직함)으로 변경 되었는데, 지금 조직구조가 예전에 비해서 좋아졌다고 말하는 사람을 저는 단한명도 보질 못할정도다 보니.. 저도 신기한데요 아무튼 간에 저에게는 크로스펑셔널 팀의 경험이 매우 좋았었습니다
+
+# 내 생각
+
+- 이 글의 작성자가 여러가지 화두를 던졌는데, 결국에 하고 싶은 말은 문제와 원인을 잘 인지해서, 본질적인 해결책을 적용해야한다 라는 것이라고 생각한다. 인간이라면 본능적으로 나에게 쉽고 빠르게 해결할 수 있는 어떤 편한 것을 원하게 되는데, 이 방향으로 갈 수록 본질과는 멀어진다고 봐야하지 않을까 생각된다. 대개의 경우 본능적인 행동들이 문제 해결을 위한 본질적인 행동과는 반대되기 때문이다.
+- 여기에 더해서 내가 추가로 말하고 싶은 부분은 팀워크와 관련된 부분이다. 1인 개발자가 아닌 이상, 회사에서 일하는 개발자라면, 개발자가 아닌 직군이더라도, 최소한 1~2명은 같이 일을 할 수밖에 없다. 결국 하나의 팀으로써, 목표를 잘 수행해 나가는 것 자체가 목표가 되어야 한다. 그러나, 위에서 말한 본능적인 부분에 의해서, 나는 내꺼만 하면된다 나의 일이 아닌 것은 관심을 끊는 등의 팀워크를 해치는 경우를 심심찮게 보는 것 같다. 저자는 이 맥락에서도 좀 더 주변의 동료들을 잘 케어해서 팀으로써, 결국에 목표를 달성할 수 있게끔하는 행동들을 제안하고 있는데 나도 매우 동의하는 바이다.

2025/Becoming a Better Programmer/taehyoung/부록-3.md

@@ -0,0 +1,6 @@
+# 개발자의 학습, 성장에 관하여
+
+# 내 생각
+
+- 이 장을 작성한 개발자분이 말씀주신 것 중에 제일 와닿는 부분은 문제 해결을 위한 학습부터 시작하는 것이다. 상세한 방향성 부분은 좀 다른데, 작성자는 본인의 개인프로젝트나 학습, 회사 업무를 포함한 모든 작업을 기준으로 말하고 있다. 나의 경우는 위와같이 문제해결의 관점에서는 회사 업무에 비중이 많이 치우쳐져 있다. 회사에서 발생하는 문제들과 장애들은 어떻게 보면 나에게는 가장 순도 높은, 현실세계의 실무 문제들이기 때문에 우선순위에서 가장 높을 수밖에 없다고 생각한다.
+- 내가 아쉽다고 생각되는 부분은 회사 업무들은 크게 신경쓰지 않으면서, 그 외 문제들에 먼저 접근하는 것이다. 책을 보면서, 스터디 하기도 하고 개인프로젝트도 하곤 하는데, 이것은 학습의 영역 정도 밖에 커버할 수 없다. 현실의 실제 상황이 아닌, 가상의 상황이고 학습의 목적이기 때문에, 리얼하지 않다는 단점이 있다 과연 어떤 문제들이 내 성장에 더 도움을 줄 수 있을지에 대해서는 다시 한번 생각해보면 좋을 것 같다

2025/Becoming a Better Programmer/taehyoung/부록-4.md

@@ -0,0 +1,7 @@
+# 개발자로서 지속적인 성장과 성공을 위한 전략
+
+# 내 생각
+
+- 크게 와닿을 만한 부분은 없었다. 말씀해주신 내용 중에서 틀렸다고 말할 부분은 없는 것 같다 누구나 아는 정답을 그대로 쓴것 처럼 보였는데, 개인의 사례 같은게 있었다면 더 좋았을 텐데라는 아쉬움이 있다.
+- 사례가 없어서 아쉬운 이유는 본인의 주장만있고, 그 근거는 없기 때문에 이분이 말씀하는 내용을 본인은 제대로 하고 있는게 맞는것인지? 라는 의문이 들기 때문이다
+- 그래서, 앞에 있던 글들과 많이 비교가 되었고, 흥미로운 글은 아니였던것 같다

2025/Becoming a Better Programmer/taehyoung/부록-5.md

@@ -0,0 +1,6 @@
+# 결국 해내는 개발자
+
+# 내 생각
+
+- `주변 상황에 끌려 다니지 않고 자신 만의 길을 묵묵히 걸어가며 문제 해결에 집중하는 사람` 이 목표라고 말하고 있고, 이러한 사람이 결국 해내는 개발자가 되고, 이런 개발자가 훌륭한 개발자라고 말한다. 나 또한 이분의 말에 매우 동의하는 바이다
+- 글이 억지로 늘려놓은느낌도 들고, 장황해서 아쉬웠다 다른분들은 어떻게 보셨는지 궁금하다

2025/Becoming a Better Programmer/taehyoung/부록-6.md

@@ -0,0 +1,9 @@
+# 개발자 커리어에서 한 번쯤 생각해보면 좋은 5가지
+
+# 내 생각
+
+- 이분이 제시한 5가지는 실제로도 꼭 커리어 중에 생각해볼만한 5가지로 볼 수 있을 것 같다. 읽으면서 매우 공감이 되었다
+- 커뮤니케이션과 관심 파트에서 작성자가 주장하는 바는 여러 직군 간의 업무 커뮤니케이션을 더 잘하기 위한 방법은 개발자 스스로 본인이 개발하는 비즈니스 도메인에 대한 관심을 가지고, 소통에도 적극적이고, 코드 작성에도 적극적으로 적용해보자는 것이다. 나는 이 의견에 매우 동의한다. 개발자는 본인이 개발하는 도메인에 대해서 잘 알아야만 한다. 모르면 타직군과의 소통도 힘들어지고, 이걸로 인해서 버그도 생산되게 된다.
+- 기획자(PO)는 디테일 보단 상대적으로 추상적인 스케치에 좀 더 집중하는 편이라고 생각한다. 개발자와는 이부분에서 충돌을 하는데, 개발자는 추상적인 스케치 바탕 하에서, 디테일이 매우 중요하다. 만약 인수조건 case 1개를 놓쳤는데, 매우 크리티컬한 버그였다면?.. 소통 오류로 코드 한줄이 반대로 동작하는 문제가 발생 했다면? 개발자들은 이런 모든 버그가 발생할 수 있는 경우의 수를 최대한 고려해서 코드가 논리적으로 설계한 의도 대로 동작하도록 심여를 기울여야한다 그래서 디테일이 중요하다
+- 근데, 이 디테일을 기획자(PO)가 채워줄 수 없기 때문에, 개발자 스스로가 이 디테일을 챙길 수 밖에 없는데 결국 디테일을 챙기려면 비즈니스 도메인에 대한 이해 있어야만 한다. DDD의 전략적 설계에서의 개발자의 역할과도 비슷한 부분이라고 볼 수 있을 것 같다
+- 나머지 4가지에 대해서도 본인의 사례를 적절히 첨부해서, 본인이 겪었던 어려움을 바탕으로 잘 작성해주었고, 글을 읽으면서 나 자신에 대해서 돌아보는 계기가 되어서 좋았다

2025/Becoming a Better Programmer/taehyoung/부록-7.md

@@ -0,0 +1,7 @@
+# 글로벌 리더쉽을 가진 프로그래머 되기
+
+# 내 생각
+
+- 책에서 글로벌 리더쉽에 대해서 처음 얘기를 꺼낼 때 들었던 기대 만큼의 적절한 키워드를 제시해줬다고 생각하고, 본인의 경험이 묻어있는 글이고, 나도 관심있는 부분이다보니 재미있게 잘 읽었다.
+- 특히, 의사소통에서 개발자로써 효과적인 의사소통을 위해서 해야할 구체적인 것들을 제시하는데, 이건 어디 책에서 본게 아니라, 진짜 본인의 찐 경험에서 나온 것들을 적은 것처럼 느껴졌다. 나도 비슷한 고민을 지금도 매일 하고 있기 때문에 더 와닿았다
+- 그 외의 부분은 내용이 조금 아쉬웠지만, 그래도 글로벌 리더쉽과 관련된 핵심적인 키워드과 내용을 본인의 경험을 기반으로 적절히 제안해주었다고 생각해서 도움이 되는 글이였다고 생각한다