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

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

@@ -0,0 +1,9 @@
+# ch14. 소프트웨어 개발이란
+
+# 논의 내용
+
+- 해당 챕터에서 말하는 예술작품으로써의 소프트웨어 개발이 자칫 회사에서 소프트웨어 개발을 해야하는 본질적인 이유인 비즈니스 가치를 창출 보다 더 중요한 가치처럼 여겨 질 수 있지 않을까 하는 우려점이 있습니다. 제 개인적으로는 비즈니스 가치를 창출할 수 있는 제대로 동작하는 코드, 유지보수성과 확장성을 고려하는 것을 전제한 상태에서, 이후에 코드의 미적인 가치, 가독성 등을 고려하는게 맞지 않나 라는 생각인데요(미적 가치라는 것이 주관적인 영역에 가깝다고 생각하기 때문에) 이에 어떻게 생각하시는지 의견을 나눠보면 좋을 것 같습니다
+
+# 내 생각
+
+- 해당 챕터에서는 소프트웨어 개발를 예술과 과학, 스포츠 등등 빗대어서 본인의 의견을 제시하고 있다. 그중에서 개인적으론 과학 > 스포츠 > 집안일 >>>>> 예술 > 놀이 순으로 중요도를 따질 수 있을 것 같다. 이렇게 순위를 매긴 이유는 기본적으로 개발자들의 대부분이 회사에서 고용되어서, 비즈니스 가치를 창출하는 제품을 만드는 일을 하고 있기 때문이고, 대부분 혼자가 아닌 여러 팀원들과 함께 일하기 때문이다. 만약에 내가 회사에 고용된 개발자가 아닌, 오늘 당장 해커톤에 참가해야하는 개발자라면, 그때 작성되는 코드에서는 이와 반대로, 놀이와 예술이 더 높은 순위가 될 수 있을 것 이다. 즉, 나의 현재 상황에 따라서, 어떤 것이 더 중요한지 여부는 변경될 수 있다 이점을 잘 인지하고 코드를 작성할 수 있어야할 것 같다

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

@@ -0,0 +1,16 @@
+# ch15. 규칙 가지고 놀기
+
+# 논의 내용
+
+- 현재 일하고 있는 회사에서, 납득하기 힘든 혹은 잘 지켜지지 않는데도 유지되고 있는, 팀의 규칙 혹은 개발자 컨벤션이 있을까요? 있다면, 그것이 무엇이고, 본인의 생각엔 어떻게 바꾸는게 좋다고 생각하는지 얘기해보면 좋을 것 같습니다
+- 개인적으로, 규칙을 추가하는 것은 관리자를 기준으로한 탑다운이 아니라, 실무자들을 기준으로한 바텀업이 되어야한다고 생각합니다. 다른 분들의 의견은 어떠한가요?
+    - 이유는 제 경험 하에서, 관리자는 본능적으로 실무자들의 통제를 목적으로 규칙을 추가하려고 하는데, 애초에 효율성 보다는 통제의 목적이 강하기 때문에, 추가는 쉽게 생각하고 삭제는 보수적으로 생각했었던것 같습니다. 이로 인해서, 현상황에서 굳이 불필요한 규칙들이 계속 없어지지 앉고 남아서 실무자들에게 괜한 불편함을 줬던 경험들이 있습니다
+
+# 내 생각
+
+- 개인적으로는 규칙이 많은 것을 좋아하지 않습니다. 코드 작성 때도 그렇고, 팀으로 일 할 때도 그렇습니다. 룰이 많다는 것은 그만큼 제약사항이 많다는 것이고, 계속 신경을 써야하는 것인데, 너무 많은 규칙들에 신경쓰다가, 본질적인 것에 집중을 못할 가능성이 높기 때문 입니다. 그래서 제가 리딩을 하는 경우에는 가능하면, 최소한으로만 유지하려고 하고, 자동화할 수 있는 부분은 자동화하고(코드 포맷팅 등) 그외 정말 문제가 되는 부분에 한해서만, 규칙을 만들어두는 편 입니다.
+- 제가 규칙이 많은 것을 좋아하지 않는 이유는 인간의 심리적인 관성 때문인데요. 규칙이 늘어난다는 것은 어떤 프로세스가 추가되고 늘어난다는 것인데, 제가 경험하에서, 관리자 레벨에서는 프로세스 추가는 쉽게 하고, 삭제는 신중하게 생각하는 경향이 있다보니, 이 프로세스가 현 상황에서 필요하지 않은 상황에서도 쉽게 없애지 못하는 것 같습니다
+- 이러한 프로세스들이 적용되는 것은 대개 관리자보단 실무자이다보니, 제가 실무자 입장에선 굳이 필요 없는 프로세스들이 계속 추가되는게, 불필요하다고 느낌에도 불구하고, 없애지 못하는게 답답한 경우가 많았던 것 같습니다.
+- 오히려 제 생각에는 어떤 룰을 추가하는데 더 고민이 필요하고, 삭제는 더 과감하게 해야하는데, 주로 반대로 나타나다 보니 안타까운 것 같습니다
+- 규칙 추가에는 꼭 필요한 경우에만, 보수적으로 추가하고, 불필요한 규칙은 과감하게 없애자
+- 코드와 관련된 규칙들, 예를 들면 포맷팅, 코딩 스탠다드 등은 가능하면 자동화시키는게 좋다고 생각합니다 파이썬이든 자바든 모두 이를 자동화할 수 있는 수단이 있는 것으로 알기 때문에, 불필요한 논쟁보다는 자동화하는 것으로 하면 가장 좋다고 생각됩니다

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

@@ -0,0 +1,10 @@
+# ch16. 간결하게 하기
+
+# 논의 내용
+
+- 간결성을 지키고, 간결하게 한다가 저는 주관적영역에 해당한다고 생각하기 때문에, 개인 마다 구체적인 실천사항들도 차이가 있을 것이라고 생각합니다. 본인이 최근에 실천한 간결성과 관련된 것이 있다면 공유해보면 좋을것 같습니다
+
+# 내 생각
+
+- 책에서 나온 것 처럼 간결한 코드의 의미가 사람마다 다르게 받아들여질 수 있다. 가독성 처럼 주관적 영역에 가깝다고 볼 수 있을 것 같다. 나도 간결성에 대해서는 매우 동의하는 편인데, 코드의 간결성도 중요하지만(사람 마다 기준은 다르겠지만), 무엇보다 문제 해결 영역에서의 간결성이 중요하다고 생각한다. 이 문제를 가장 쉽고 간단하게 푸는 방법이 무엇일까? 에 대한 것이다. 이 해결의 영역을 기준으로 보면, 꼭 개발적으로 풀지않아도 풀 수 있는 문제들도 있고, 결국에는 개발자 공수가 전혀 들지 않고도 문제를 해결 할 수 있는 것들이 있다. 개인적으로, 엔지니어로써, 개발자 역량은 문제를 잘 정의하고, 가장 간단하고 쉽게 문제를 해결할 수 있는 해결책을 제안 할 수 있느냐에 달렸다고 생각한다
+- 너무 이른 최적화를 피하기 위해선, 현재의 상태가 어느정도까지 커버가 될지에 대한 판단을 잘 할 수 있어야한다. 예를 들어서, 대규모데이터에서 DB 조회를 해야하는 상황일 때, 인덱스는 언제 어떻게 생성해야할까? 에 대해서 개인적으로는 어느정도 풀스캔으로 커버된다고 판단되면, 굳이 미리 인덱스를 생성할 필요는 없다고 생각한다. 물론, 상황에 따라서, 요구사항에 따라서, 더 많은 것들을 고려해서 결정해야겠지만 일반적으론 그러하다. 이런 판단을 할 수 있게 된 것은 그동안의 경험이 쌓여서, 어느정도 선으로 데이터가 늘어나지 않는다면, 그냥 풀스캔 만으로도 서비스를 운영하는데 문제가 없다는 것을 인지했기 때문이다. 아무튼 이러한것은 직접적인 본인의 경험을 통해서만 얻을 수 있기 때문에, 많은 장애상황 혹은 여러가지 상황들을 직접 겪고 문제를 해결해보는 경험을 많이함으로써, 이른 최적화도 피하고, 적절한 시기에 적절한 최적화를 할 수 있을 것 이라 생각한다

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

@@ -0,0 +1,11 @@
+# ch17. 머리쓰기
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 코드 작성할 때는 생각해야한다는 어찌보면, 당연한 것인데, 본인 작업에 대한 설계 없이 그저 코드 작성에만 열중하는 개발자들을 보면, 실무에서도 그다지 잘 지켜지지 않는 것 처럼 보이기도 한다.
+- 또한 코드 작성의 의도를 물었을 때, 의도 없이 작성 하였거나, 이렇게 하는게 더 좋은것 같다(?)는 마땅한 작성 근거 없이 코드를 작성하는 것도 문제라고 생각한다 해당 챕터에서는 이러한 것들을 주의하길 원하는 것으로 이해 하였다
+- 코드를 작성할 때는 작성 전에 설계를 하고(대충이라도 좋다), 작성을 하는데, 내가 코드를 작성하는 의도가 잘 드러나도록, 작성을 하자

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

@@ -0,0 +1,10 @@
+# ch18. 변하지 않는 것은 없다
+
+# 논의 내용
+
+- 책 내용에서 코드에 두려움을 가짐으로써, 수정하지 못하고, 방치하는 상황은 피해야하지만, 반대로, 이런 두려움 타파를 위해서, 대담하게 수정하라는 말은 조금 책임 없는 말처럼 들립니다. 물론, 암묵적으로 롤백 가능성에 대해서도 언급을 하고 있고, 수정을 잘하기위해서, 어떤 식으로 설계해야할지에 대한 얘기도 나옵니다만, 제 개인적으로는 좀 더 명시적으로 모든 케이스에 대해서 살펴보고, 혹시나 문제가 생겼을 때, 어떻게 대응을 해야한다고 말하는게 현실성 있는 답변이 아닐까 하는 비판을 해봅니다. 다른 분들은 이부분을 읽고 어떻게 느끼셨는지 궁금하네요
+
+# 내 생각
+
+- 책에서 말하는 용감한 수정의 경우는 일반론적인 입장에선 이해할 수 있지만, 특정 상황에선 매우 위험할 수 있는 부분이라고 생각된다. 결제, 정산, 혹은 주문 등등으로 금전적인 문제와 관련된 코드의 경우는 사실 용감하게 수정을 해보라는 조언 만 가지고, 무언가 시도하기엔 회사에 금전적인 피해를 줄 수 있기 때문에, 오히려 용감한 마음을 가지고 대담하게 수정하길 시도하기 보다는 더 이성적으로 발생할 수 있는 경우의 수를 전부 따져서 최대한 문제가 없게 어떻게 할 것인지를 더 고민해야한다고 생각한다. 그런 의미에서 책의 주장을 자칫 오해하는 경우에 큰 문제가 발생할 수 있지 않을까 하는 걱정이 든다
+- 수정하기 부분 외 이후에 나오는 내용들은 내용적으로 딱히 틀린 부분은 없지만, 저자가 말하는 대응이라고 하는 것이 실무에 더 밀접하거나, 구체적이지 않은 부분은 아쉽다.

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

@@ -0,0 +1,12 @@
+# ch19. 코드 재사용 사례
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- 기본적으로는 복사/붙여넣기 방식이 책에서 말한 것과 같이 해선 안될 안티패턴임을 인정하지만, 개인적으론 테스트 코드 작성할 때, 복사/붙여넣기를 하기도 한다. 즉, 필요하면 쓰되, 중복이 생기는 것에 대한 의도를 확실히 드러나게 해야할 필요가 있다고 생각한다
+- 스택오버플로우 같은 곳에서 가져온 코드를 내가 이해를 했다는 전제하에서는 가져와서 사용하는게 아무 문제 없다고 생각하고, 그것도 능력이라고 생각한다.
+- 재사용을 위한 설계 부분은 이 책에서 거의 제일 공감되는 부분이다. 개인적인 경험에서 봤을 때, 정말로 확장될 부분이 확실해서 확장성을 고려해야하는 것이 아니라면, 최대한 확장성을 고려하지 않고 현재 요구사항을 충실하게 수행할 수 있는 코드를 만드는게 낫다고 생각한다. 그 이유는 확장성을 고려하던, 고려하지 않던, 요구사항은 바뀌는데, 그 요구사항의 변경은 상상을 초월하기 때문이다. 애초에 요구사항을 보고 확장성을 고려하더라도, 기대대로 확장이 안되는 경우에는 다시 갈아엎고 설계를 해야하는데, 오히려 이전 요구사항 기준으로 설계한것을 갈아엎는게 더 공수가 들었던 것 같다. 라이브러리의 경우도 마찬가지 인데, 미리부터 공통으로 사용할 코드들 부터 미리 전부 만들어두는게 정말로 효율적인 판단인지 모르겠다고 생각한 이유는 그 공통 코드에 예외가 생기는 순간 공통 코드를 수정해야하는 이슈가 생기기 때문이다. 공통 코드들의 경우는 의존하는 코드 모두를 커버할 수있도록 설계가 되어야 하기 때문에, 미리 부터 그 설계 가능성을 모두 고려하기 보다는, 어느정도 프로젝트가 성숙해서 중복적으로 발생하는 부분이 생길 때 하는게 낫다고 생각한다
+- 좋은 도구를 잘 선택해서 사용하는 것도 능력이라고 생각한다. 물론 필요한 기능을 직접 구현해서 사용하는 것도 좋은 방법이다. 하지만, 모든 결정에는 장점과 단점이 존재한다. 엔지니어링의 관점에서 어떤 문제 해결을 위한 적절한 해결책을 선택하기 위해서 트레이드오프를 잘 따져서 결정할 수 있도록 하자.

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

@@ -0,0 +1,11 @@
+# ch20. 효과적인 버전관리
+
+# 논의 내용
+
+- 없음
+
+# 내생각
+
+- 책이 쓰여질 당시에는 git이 많이 보급되지 않았던 시기이다보니, git의 학습 곡선 얘기가 나오는 것 같은데, 현재 기준으로 개인적으로 생각하기에 git이 학습곡선이 높다고는 생각이들진 않는다. 학습곡선이 높다기 보다는 이걸 협업에 어떻게 활용해야할지? 에 대한 것을 명확하게 정의하기가 좀 힘들었다? 가 맞지 않을까 생각된다
+- 예전에는 좋은 커밋 메세지에 대한 글에 공감을 하기도 하였고, 그런 좋은 관습들에 대해서 실천을 많이 해보기도 했던 것 같다. 하지만 요즘 느끼는 것은 좋은 커밋 메세지라는 것도 상황에 따라서 필요한 상황과 굳이 필요하지 않은 상황이 있는게 아닌가 라는 생각이다.
+- 추가로, 정말로 좋은 커밋 메세지를 쓰고 싶다면, 내가 작성한 코드에 좋은 커밋 메세지를 어떻게 작성할지를 고민하기 보다는 반대로, 좋은 커밋 메세지를 먼저 작성한 다음에 그 메세지에 맞게 내 코드를 작성하는 방법이 더 현명한 방법이 아닐까 라고 생각된다.

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

@@ -0,0 +1,10 @@
+# ch21. 골키퍼 있다고 골 안 들어가랴
+
+# 논의 내용
+
+- 책의 내용과는 조금 동떨어지지만, `오류 보고서를 개인적으로 받아들이지 마라. 개인적 모욕이 아니다` 라는 말은 꼭 이 경우만 쓸 수 있진 않은 것 같습니다. 예를 들면, 그 대상이 오류 보고서가 아니라, 내가 작성한 코드 일 수 도 있고, 내가 회사에서 했던 업무, 업무 태도 같은 것들이 될 수 있다고 생각합니다. 개인적 모욕을 위한 것이 아니라는 전제하에서는 이런 모든 나에게 부정적 피드백을 줄 수 있는 것들이 오히려 나에게 개선할 수 있는 좋은 기회라고 저는 생각하는데, 다른 분들은 어떻게 생각하시는지 궁금하네요
+
+# 내 생각
+
+- 내가 생각하는 QA의 역할은 제품의 최종 품질 관리자의 역할이고, 사용자가 제품을 사용하면서 발생할 수 있는 여러가지 예상못한 행동들을 미리 예상하고 실행해봄으로써, 시스템의 결점을 미리 확인하는 것이라고 생각한다. 하지만, 내 생각과는 다르게 대개의 경우는 그냥 개발자 대신에 수동 테스트를 해주는 역할로 더 많이 인지하고 있는 것 같다. 그러다보니, 개발자가 본인이 구현한 코드의 테스트는 온전히 QA에게만 맡기고, 검증해보지 않는 혹은 검증은 테스트코드로 만 하고 아예 신경을 끄는 경우가 있는데, 개인적으로는 매우 잘못된 행동이라고 생각한다. 책에서 말하는 것 처럼 개발자와 QA 간의 단절이 발생하지 않고, 시너지를 내기 위해서는 개발자든 QA 든 나는 개발만 하는 사람이야, 나는 테스트 검증만 하면 되지 의 생각을 가지기 보다는 하나의 제품을 모든 사람이 힘을 합쳐서 잘 만들어보자가 되어야한다고 생각한다. 그러기 위해선 일단 제품의 기획 단계에서부터, 밀접하게 개발자와 QA 모두 깊게 참여하여야한다고 생각하고, 그 과정에서 예상할 수 있는 경우의 수를 모두 같이 고려함으로써, 도메인에 대한 이해도를 높일 수 있고, 결국에는 높은 도메인 이해도가 소통에도 도움을 주고, 좋은 제품을 만드는데 분명히 도움을 준다고 생각한다
+- 백엔드 개발자의 많은 수가 단위 테스트 만으로 문제가 없을것이라 암묵적으로 인지를 한다. 이보다 조금 더 발전하면, 통합테스트 혹은 API 테스트 만으로 문제가 없을 것이라 인지한다. 하지만 결국엔 제품을 사용하는 일반 고객이 있다고 했을 때, 일반 고객이 제품을 직접 접하는 클라이언트를 직접 테스트 해보지 않으면, 아무리 백엔드 시스템 만 테스트를 자동화했다고 해서 버그가 없어지진 않는다고 생각한다. 백엔드 개발자가 작성하는 테스트 코드 또한 매우 중요하지만, 그 이상으로 내가 기여하는 제품의 클라이언트 앱, 웹에도 관심을 가지면 좋을 것 같다

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

@@ -0,0 +1,11 @@
+# ch22. 프리징된 코드의 신기한 사례
+
+# 논의 내용
+
+- 코드 프리징을 어떻게 관리할 것인가? 에 대한 얘기는 결국에 어떤 기준을 가지고 코드 배포를 할 것인가? 라는 말로 치환할 수있을 것 같습니다. 회사에서 배포 프로세스가 어떻게 되어있는지 공유해보면 좋을 것 같습니다
+    - 저희 회사의 기준에서는 지라 티켓을 기준으로 개발,리뷰,QA까지 완료된 이후에 `Ready To Deploy` 상태가 되면, 배포 준비가 완료된 것이고, 일 2회(오전, 오후) 배포를 진행하고 있습니다. `Ready To Deploy` 상태가 된 상태에서는 아주 크리티컬한 문제가 없는 이상은 일단은 배포를 내보내는 것으로 하고 있고, 마이너한 문제들의 경우는 후속 티켓으로 대응하도록 하고 있습니다. 그 이유는 코드 수정을 할 경우, 리뷰, QA 까지 과정을 다시 거쳐야하기 때문에 마이너하다면, 후속 티켓으로 진행해도 문제 없기 때문 입니다.
+
+# 내 생각
+
+- 책에서 말하는 코드 프리징은 완료기간과 출시일 사이 기간동안을 말하는데, 용어 자체가 그렇게 와닿는 것 같진 않다.  저자가 말한 것 처럼 프리징은 모든 테스트가 끝나고, 배포 준비가 완료된 시점이 기준이 되어야 한다고 생각하고, 이 코드는 가능한 빠르게 배포가 되어야한다고 생각한다. 이 중간에 무언가 기능을 추가하기 위해서 코드를 수정하는 것은 정말로 크리티컬한 경우가 아니면, 그 다음 릴리즈에 진행하는 것으로 해야한다고 생각한다
+- 현재 회사에서느 코드 프리징 책에서의 의미와는 조금 다르게, 사용하는데, 긴 연휴 2~3일 전을 코드 프리징 기간으로 설정해서, 새 피쳐가 배포하지 못하도록 한다. 이 이유는 새로운 피쳐가 배포됨으로써, 문제가 발생하면, 연휴 때 대응을 해야하기 때문이다. 그러면에서는 이 책에서 말하는 코드프리징 용어와는 맥락이 조금 다르다고 볼 수 있다.

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

@@ -0,0 +1,10 @@
+# ch23. 제발 저를 출시해주세요
+
+# 논의 내용
+
+- 없음
+
+# 내 생각
+
+- ch22 에서 말하는 코드 프리징과 이어지는 내용으로 보인다 배포와 관련해서 어떤 절차와 준비들이 필요하고, 구체적으로 브랜치 관리는 어떻게 해야하는지에 대한 내용을 말한다
+- 구체적인 방법인 조금씩은 다르지만, 책에서 말하는 대부분의 조언에 맞게 현재 회사에서는 배포관리를 하고 있다 그러다보니, 챕터에 나오는 내용을 이해하는데 어렵진 않았다.