https://www.youtube.com/watch?v=th7n1rmlO4I

1. 이건 꼭 알아야 한다[^1]

[? 질문] ‘클린 코드’ 같은 유명한 코딩 책의 규칙을 그대로 따르면 정말 코드가 더 좋아지는가[^2]
[= 답] 책에는 분명 배울 점이 많지만, 규칙을 종교처럼 절대화해서 무조건 적용하면 오히려 가독성/유지보수성/재사용성을 망칠 수 있으니, 상황에 맞게 비판적으로 적용해야 한다.[^2][^7]

[? 질문] “함수는 짧아야 한다/주석 달지 말라/중복 제거하라” 같은 조언은 언제 유효하고 언제 위험한가[^4]
[= 답] 테스트 용이성 같은 장점은 있지만, 짧은 코드까지 과도하게 쪼개면 읽기 어려워지고[^6], 프레임워크/자유도/커스터마이징 정도에 따라 주석이 더 도움이 되며[^14][^15], 중복도 ‘즉시 추상화’가 아니라 ‘변화 가능성’까지 보고 결정해야 한다.[^23][^25]

[? 질문] 학습할 때 가장 경계해야 할 태도는 무엇인가[^26]
[= 답] ‘책 하나만 읽은 것’이 아니라, 책/영상 내용을 과장된 규칙처럼 떠받들고 전도하는 태도가 문제이며, 무엇이든 직접 생각하고 의심하면서 여러 자료를 함께 보는 방식이 더 안전하다.[^26][^27][^28]

---

2. 큰 그림[^1]

이 콘텐츠는 코딩애플이 로버트 C. 마틴의 **클린 코드(Clean Code)**를 예로 들며, 유명한 개발 서적의 조언을 “정답”처럼 받아들이는 문화에 경고를 주는 영상이다.[^1][^2] “클린 코드 규칙”을 맹목적으로 적용할 때 생기는 실제 부작용(가독성 악화, 과도한 추상화, 주석 금지의 오해 등)을 구체 항목별로 짚고, 결국 개발 학습의 태도(비판적 수용)를 강조한다.[^7][^26]

• 유명 규칙도 맥락을 무시하면 독이 된다: 함수 쪼개기/인자 줄이기 등이 항상 가독성을 보장하진 않는다.[^4][^7]
• 주석 금지는 오해되기 쉽고, 환경에 따라 주석이 오히려 이해를 돕는다(특히 자유도 높은 구조/커스터마이징 많은 코드).[^10][^15]
• 중복 제거도 강박적으로 하면 미래 변경 요구에서 분기/파라미터가 늘어 “읽기 싫은 코드”가 될 수 있으니, 필요성을 따져야 한다.[^23][^25]

---

3. 하나씩 살펴보기[^1]

3.1 ‘클린 코드’ 책과 ‘전도 문화’에 대한 문제 제기[^1][^2]

화자는 영상 시작부터 “클린 코드라는 책이 있다”고 소개한 뒤, 그 책을 “종교처럼” 따르며 신입 개발자에게 전도하듯 강요하는 사람들에게 “제발 그러지 말라”고 말한다.[^1][^2] 여기서 핵심은 책 자체를 부정하는 것이 아니라, 읽어보면 “좋은 점/배울 점”도 많지만 “이상한 점”도 섞여 있고, 그 이상한 점까지 무비판적으로 규칙화하면 문제가 생긴다는 관점이다.[^3]

• [h 책을 읽는 것 자체는 유익할 수 있다] 하지만 “잘 보면 이상한 점들도 많이” 있다는 전제를 둔다.[^3]
• [c 문제는 ‘책의 내용’이 아니라 ‘책을 절대화하는 태도’]라는 방향으로 논지를 잡고 시작한다.[^2][^26]

3.2 1장: 네이밍(이름 짓기)은 대체로 동의—여기까진 좋다[^4][^5]

화자는 책의 첫 챕터가 이름 짓는 관습을 알려준다고 설명한다.[^4] 예로 든 조언들은 다음과 같다.[^5]

• 이상한 축약(화자는 “이상한 축계”라고 표현)이나 장난스러운 단어로 변수명을 쓰지 말 것[^5]
• 변수명에 불필요한 프리픽스를 넣지 말 것[^5]
• 함수/메소드에는 동사가 들어가야 한다는 식의 네이밍 규칙[^5]

여기까지는 “좋다”고 평가하며, 네이밍 파트는 일반적으로 타당한 개선점으로 받아들인다.[^5]

[!TIP] 네이밍 조언을 받아들이는 방식[^5]
“이상한 축약 금지, 장난 금지, 프리픽스 남발 금지, 동사 포함” 같은 가이드는 팀 합의 규칙으로 삼기 쉽고, 코드 이해 비용을 즉시 줄이는 효과가 있다(화자의 평: 여기까진 좋다).[^5]

3.3 2장 이후: 함수 규칙의 ‘절대화’가 가독성을 망칠 수 있다[^6][^7]

화자는 “둘째 챕터부터 좀 이상한 소리”가 나온다고 말하며, 책이 강조하는 함수 작성 규칙들을 나열한다.[^6]

• 함수는 무조건 하나의 일만 해야 한다[^6]
• 함수는 사이드 이펙트가 없어야 한다[^6]
• 함수 길이는 아주 짧게: “두 줄에서 네 줄 이하가 좋다”[^6]
• 함수의 인자(argument)는 없을수록 좋고, “세 개 이상이면 좋지 않다”는 식으로 말한다[^6]

화자는 이런 규칙들이 테스트를 쉽게 하는 등 장점이 “있긴” 하다고 인정한다.[^7] 그러나 이걸 “종교처럼 받아들이면서 항상” 적용하려고 “코드를 자르면”, 코드가 클린해질지는 몰라도 가독성은 쓰레기가 될 수 있다고 강하게 경고한다.[^7]

3.3.1 책의 ‘최종 예시’ 방식(함수로 전부 쪼개기)에 대한 반박[^8][^9]

화자는 책에서 “최종 예시”로 보여주는 스타일을 언급한다: 기존 코드를 전부 “이런 식으로 함수로 바꿔서 쓰는 게 좋다”고 제안한다는 것이다.[^8] 하지만 화자 본인은 “예전 코드가 더 나은 것 같다”고 말한다.[^9]

그 이유는, 몇 줄짜리 코드를 읽기 위해 “여기저기를 왔다 갔다” 해야 해서 오히려 “훨씬 읽기 어려워” 보인다는 점이다.[^11] 즉, 함수 분리가 원칙적으로 나쁘다기보다, 짧고 단순한 코드까지 지나치게 분해해버리면 독자가 맥락을 따라가기 위해 점프해야 하는 비용이 더 커진다는 주장이다.[^11]

• [h 코드가 짧으면 한 곳에 두는 게 가독성에 나쁠 것만은 아니다] 짧은 로직은 그대로 두는 편이 읽기 쉬울 수 있다고 말한다.[^12]
• [h ‘함수 쪼개기’는 함수 수 증가로 이어진다] 인자 줄이기/짧게 만들기 목표를 달성하려면 함수가 “필연적으로 늘어나게” 된다고 지적한다.[^13]

3.3.2 함수가 많아지면 재사용도 어려워질 수 있다—존재 의도 상실[^13]

화자는 “그런 식으로 코드를 짜면 함수를 재사용하기도 어려울 것 같다”고 말한다.[^13] 재사용이 어려우면 “함수의 존재 의도(의미)가 없어지는 것” 같다고 덧붙인다.[^13]

여기서 논리 흐름은 다음과 같다.[^13]

1. 규칙(짧게/인자 적게/단일 책임)을 기계적으로 맞추려 한다
2. 그 결과 함수가 지나치게 세분화되고 수가 많아진다
3. 각 함수가 맥락 의존적이 되어 재사용이 애매해진다
4. 재사용성까지 잃으면 ‘함수로 만든 이유’가 약해진다

따라서 화자는 “항상 클린하다고 가독성도 좋아지는 게 아니”니 이런 점을 고려하라고 정리한다.[^13]

[!IMPORTANT] ‘클린함’과 ‘읽기 쉬움’은 동일하지 않을 수 있다[^13]
규칙을 충족해 구조적으로 ‘깨끗해 보이는’ 코드가, 실제 독자에게는 더 많은 점프(이동)를 요구해 읽기 어려울 수 있다는 것이 화자의 핵심 문제의식이다.[^11][^13]

3.4 3장: “주석 달지 말라”의 도발과 그 오해—결국 ‘상황론’[^14][^15]

화자는 “셋째 챕터부터 사람이 폭주하기 시작한다”며, 책에서 “코드에 주석을 달지 말래요”라고 말하는 대목을 소개한다.[^14] 이 발언은 매우 자극적이라 화자는 저자가 “어그로를 되게 잘 끄는 것 같다”고 평하고, 오늘날 유튜브 환경이라면 “골드 버튼”도 쉽게 땄을 것 같다고 농담한다.[^16] 또한 화자 자신도 책에서 “영상 제목 같은 걸 자극적으로 작성하는 법을 많이 배웠다”고 말하며, 메시지 전달을 위한 과장/도발의 장치를 메타적으로 언급한다.[^17]

3.4.1 책이 주석을 싫어하는 이유: 주석은 거짓말을 한다[^18][^19]

화자는 책의 논리를 요약해 설명한다.[^18] 책이 주석을 달지 말라고 하는 주된 이유는:

• 주석은 “거짓말을 하는 경우가 많기” 때문에, 안 쓰는 게 좋다[^18]
• 코드를 잘 짜면 주석이 “아예 필요가 없다”[^19]

즉 주석이 코드와 동기화되지 않으면 오히려 잘못된 정보를 퍼뜨릴 수 있고, 이상적으로는 코드 자체가 의도를 드러내야 한다는 철학을 소개하는 셈이다.[^18][^19]

3.4.2 화자의 반론: ‘코드를 매우 잘 짜는 경우에만’ 성립—대부분은 주석이 필요[^20][^21]

화자는 이 주장이 “여러분들이 코드를 매우 잘 짜는 경우에만 맞는 소리”라고 선을 긋는다.[^20] 그리고 “대부분의 경우엔 그냥 주석을 쓰는 게” (필요할 수 있다/나을 수 있다)고 말하며, 현실에서는 주석이 도움이 되는 상황이 많다는 쪽에 무게를 둔다.[^21]

또한 주변에서 “주석 쓰지 말라는 개발자들이 가끔” 있는데, 그런 사람들은 “이런 책 보고 하는 소리”일 가능성이 높다고 말한다.[^21]

3.4.3 ‘절대 주석 금지’는 책을 끝까지 안 읽은 오해일 수 있다[^21][^22]

화자는 더 읽어보면 책에서도 “좋은 주석의 조건”을 찾아볼 수 있고, 그런 주석들은 “쓰는 게 좋대요”라고 말한다.[^22] 따라서 “주석을 절대 쓰지 말라는 사람들”은 “책의 목차만 읽은 분들” 같다고 꼬집는다.[^22]

여기서 화자의 핵심 메시지는 다음처럼 정리된다.[^22]

• 책의 자극적인 한 문장(주석 달지 마라)을 떼어내 절대 규칙으로 만들지 말 것
• 책 안에서도 ‘좋은 주석’은 인정한다는 맥락이 있다
• 그러니 “주석 금지”를 교리처럼 전파하는 건 오독/과잉해석일 수 있다

3.4.4 주석 필요성은 프레임워크/자유도에 따라 달라진다[^23][^24]

화자는 주석 여부가 “본인이 쓰는 프레임워크에 따라서” 중요하다고 말한다.[^23] 예로 **스프링부트(Spring Boot)**처럼 “진짜 틀에 맞춰서 딱 개발해야 되는 경우”에는 주석이 없어도 이해가 잘 되는 경우가 많다고 한다.[^24]

• 애너테이션(Annotation)과 변수명 정도만 봐도 역할이 “바로 이해”될 수 있다는 설명이다.[^24]

반대로, “자유도가 되게 높은 프레임워크”를 쓰거나 “커스터마이징을 되게 많이 하는 경우”에는 사람의 코딩 의도/패턴을 파악하기 어려워서, “코드 잘 짜는 것보다 주석 잘 쓰는 게 훨씬 도움”이 된다고 주장한다.[^25]

[!NOTE] 주석 논쟁의 결론은 ‘도구/환경 의존’[^24]
규약이 강한 환경(스프링부트 등)에서는 구조가 의도를 대신 설명하는 영역이 커서 주석 없이도 읽히는 반면, 자유도가 큰 환경에서는 코드만으로 의도를 복원하기 어려워 주석의 가치가 커진다고 말한다.[^24][^25]

3.4.5 주석 대신 ‘길고 복잡한 변수명’도 만능이 아니다(언어 역량 이슈 포함)[^25]

화자는 “클린 코드 한다고 주석 대신 길고 복잡한 변수명”을 쓰는 사람들을 언급한다.[^25] 그런데 영어를 잘 못해서 문법/어순을 틀리게 쓰면 오히려 혼동을 주는 경우가 있다는 것이다.[^25] 그런 상황이라면 차라리 “그냥 주석 다는 게 좋은 것 같다”고 결론낸다.[^25]

이 대목은 “코드 자체가 설명서가 되어야 한다”는 이상론이, 실제 팀의 언어 능력/커뮤니케이션 능력에 따라 역효과를 낼 수 있다는 현실적 지적이다.[^25]

3.5 클래스 파트: 전반적으로 좋은데, ‘단일 책임’의 과대해석을 경계[^25][^26]

화자는 클래스와 관련해서는 책에 “좋은 얘기들이 많다”고 평가한다.[^25] 예로 드는 조언들은 다음과 같다.[^26]

• 클래스를 너무 크게 만들지 말아라[^26]
• 클래스 하나에는 **싱글 리스폰서빌리티(Single Responsibility)**가 있어야 한다[^26]
• 클래스 안에 너무 많은 변수를 집어넣지 말아라[^26]
• **커플링(coupling)**을 줄여라[^26]

화자는 이런 것들이 “다 제너럴(일반적)하고 맞는 소리”라고 한다.[^26] 다만 문제는 이를 “과대 해석”하는 사람들이다.[^26] 즉, “클래스 하나마다 싱글 리스폰서빌리티”를 지나치게 문자 그대로 받아들여, “작은 하나하나의 기능들을 다 쪼개서 클래스로 만들어 보관하는 이상한 사람들”이 있는데, 책이 말하는 의도는 그 정도의 과잉 분해가 아니라며 “그러라는 소리가 아니”라고 못 박는다.[^26]

[!WARNING] SRP를 ‘모든 기능은 클래스 하나’로 오해하지 말 것[^26]
단일 책임 원칙을 핑계로 지나치게 잘게 클래스를 쪼개면 구조가 복잡해지고 추적 비용이 올라가는 ‘이상한 설계’가 될 수 있다는 경고다.[^26]

3.6 중복 코드: ‘발작’할 정도의 강박적 제거가 오히려 해롭다[^26][^27]

화자는 책이 “중복되는 코드를 최대한 제거하라”고 말한다고 소개한다.[^26] 그런데 이 조언 때문에 “중복된 코드만 보면 발작하는 사람들”이 가끔 있다고 한다.[^27]

여기서 화자의 핵심 주장은 명확하다.[^27]

• “짧은 코드 덩어리가 두 번 세 번 정도 반복되는 건 아무 문제 없습니다”[^27]

즉, DRY(Don’t Repeat Yourself)를 절대 규칙으로 만들어, 모든 반복을 즉시 추상화 대상으로 보는 태도를 비판한다.[^27]

3.6.1 중복을 보자마자 함수로 싸매 추상화하면 ‘나중에 읽기 싫어질’ 수 있다[^27][^28]

화자는 반복을 발견하자마자 “강박적으로 함수로 싸매거나 해서 추상화”를 시작하면, 나중에 코드를 읽기 싫어질 거라고 경고한다.[^28] 즉, 당장의 중복 제거가 장기적으로는 더 복잡한 간접참조(함수 호출), 더 많은 맥락 이동, 더 많은 조건 분기로 이어질 수 있다는 맥락을 깐다.[^28]

3.7 중복 제거의 구체 예시: HTML 생성 코드 3회 등장—함수화의 이면 비용[^28][^29]

화자는 예시를 든다: “html 간단하게 생성해 주는 자바스크립트 코드”가 소스에 “세 번” 등장하면 어떻게 할 거냐는 질문이다.[^29]

[? 질문] 같은 HTML 생성 코드가 코드베이스에 3번 반복되면 어떻게 할까[^29]
[= 답] 함수로 빼서 재사용하면 당장은 중복을 줄일 수 있다.[^30]

화자는 여기까지는 누구나 떠올리는 “중복 줄이기”의 표면적 이점을 인정한다.[^30] 하지만 곧바로 “나중에 변경 사항이 생기면 어쩔 거예요”라고 반문하며, 유지보수 국면에서의 문제를 제기한다.[^31]

3.7.1 변경 요구가 갈라질 때: 한 곳은 A 추가, 다른 곳은 B 추가[^31][^32]

화자는 상황을 구체화한다.[^31]

• 어떤 사용처에서는 “요런 코드를 추가해야 되고”[^32]
• 다른 사용처에서는 “요런 코드를 추가해야” 한다면?[^32]

즉, 처음엔 동일했던 요구가 시간이 지나며 서로 다른 방향으로 진화하는 흔한 케이스를 상정한다.[^32]

3.7.2 해결하려면 분기/파라미터가 늘고, 그게 ‘읽기 싫은 코드’가 될 수 있다[^33][^34][^35]

그때 개발자는 보통 다음 중 하나를 하게 된다고 말한다.[^33]

• 함수 내부에 if문/스위치문을 추가하거나[^34]
• 파라미터를 추가해 호출부에서 옵션을 넘기거나[^34]

하지만 이런 로직을 “하나 둘씩 추가하기 시작하면” 코드가 “쓸데없이 길어지고” (복잡해져) “읽기 싫은 코드가 될 수도” 있다고 결론 낸다.[^35]

즉, 중복 제거를 위해 만든 ‘추상화 계층’이 변화에 대응하면서 조건/옵션이 누적되어, 원래의 단순한 3군데 복사보다 더 이해하기 어려운 덩어리가 되는 역전 현상을 경고하는 것이다.[^35]

[!TIP] 중복 제거 판단 기준(화자의 제안) — “꼭 필요한지” 먼저 생각[^36]
중복이 보이면 자동으로 추상화하지 말고, 그 중복이 앞으로도 같은 방향으로 함께 바뀔지(변경의 결합도), 혹은 사용처별로 갈라질지까지 고려하라는 메시지다.[^36]

3.8 결론: 무서운 건 ‘책 하나’가 아니라 ‘책을 종교처럼 떠받드는 사람’[^26][^27]

화자는 결론적으로 “책 하나만 읽은 사람이 무서운 게 아니라, 책 하나만 읽고 책을 종교처럼 떠받드는 사람이 무섭다”고 말한다.[^26] 그리고 책이나 유튜브 영상은 “작은 걸 크게 과장하고 제목으로 어그로 끌고”를 잘하기 때문에, 화자가 말하는 것조차 “그대로 받아들이지 말고” 항상 직접 생각하고 의심하라고 권한다.[^27]

마지막으로, 클린 코드 말고도 코드를 깔끔하게 짜는 데 도움 되는 “다양한 책들이 많기 때문에” 그런 것들도 살펴보라고 제안하며 영상이 끝난다.[^28]

---

4. 핵심 통찰[^2]

1. [c 규칙의 효용은 ‘상황’에서 결정되고, 규칙의 해로움은 ‘절대화’에서 커진다.] 화자는 클린 코드의 조언을 전면 부정하지 않지만, 맹목적 적용이 가독성과 유지보수를 악화시킬 수 있음을 반복해서 경고한다.[^3][^7][^26]

   • 실행: 팀 규칙/개인 체크리스트를 만들 때 “예외 조건(언제 적용하지 않는가)”까지 함께 문서화하라.[^13][^36]

2. [h 함수 쪼개기는 테스트에는 유리할 수 있으나, 짧은 코드까지 과도 분해하면 독해 비용이 증가한다.] “여기저기 왔다 갔다” 하는 비용이 생기면 오히려 읽기 어려워진다는 현실 감각을 강조한다.[^11][^12]

   • 실행: 코드 리뷰에서 “이 함수 분리가 독자에게 실제로 이득인가?”를 질문으로 추가하라.[^11]

3. [h ‘주석 금지’는 자극적 문구일 뿐, 실제론 좋은 주석이 존재하며 프레임워크 맥락이 중요하다.] 스프링부트처럼 규약이 강한 환경과 자유도가 높은 환경을 대비시키며 주석의 효용을 상황론으로 정리한다.[^24][^25]

   • 실행: “주석을 쓰지 말자”가 아니라 “주석이 거짓말이 되지 않게 관리(갱신)하자”로 정책을 바꿔라.[^18]

4. [h 중복 제거는 ‘변경이 함께 일어나는가’가 관건이다.] 지금 동일해 보이는 코드가 미래에 서로 다른 요구로 갈라지면, 추상화는 분기/파라미터 누적으로 더 복잡해질 수 있다.[^31][^34][^35]

   • 실행: 중복을 발견하면 즉시 리팩터링하기 전에 “변경 가능성 시나리오”를 1~2개만 써보고 결정하라.[^31][^36]

5. [c 학습의 핵심은 ‘권위 추종’이 아니라 ‘의심과 사고’다.] 책/영상은 과장과 어그로가 섞일 수 있으니, 무엇이든 그대로 믿지 말고 직접 생각하라는 메타 메시지가 영상의 종착점이다.[^27][^28]

---

5. 헷갈리는 용어 정리[^6]

사이드 이펙트(side effect): 함수가 외부 상태를 변경하거나(전역 변수 수정, DB 기록 등) 외부와 상호작용하여, 같은 입력이어도 실행 시점/환경에 따라 결과나 주변 상태가 달라질 수 있는 효과를 말한다(영상에서는 “함수는 … 사이드 이펙트가 없어야 된다”는 책의 주장으로 등장).[^6]

아규먼트(argument): 함수에 전달하는 입력값(매개변수/인자). 책에서는 “없을수록 좋고”, “세 개 이상이면 좋지 않다”는 식으로 제안한다고 소개된다.[^6]

싱글 리스폰서빌리티(Single Responsibility): 클래스(또는 모듈)가 하나의 책임/역할에 집중해야 한다는 원칙으로, 영상에서는 과대해석(기능을 과도하게 쪼개 클래스 남발)하는 사례를 경계한다.[^26]

커플링(coupling): 모듈/클래스 간 결합도. 낮출수록 변경 영향 범위가 줄어드는 경향이 있으며, 영상에서는 책의 “맞는 소리”로 언급된다.[^26]

---

---

참고(콘텐츠 정보)[^1]

• 제목: 코딩 책 한 권만 읽으면 일어나는 일[^1]
• 채널: 코딩애플[^1]
• 길이: 5분 27초[^1]
• 링크: https://www.youtube.com/watch?v=th7n1rmlO4I[^1]
• 키워드(제공): 개발자, 취업, 코딩, 프로그래밍, 자바스크립트, javascript, 백엔드, 프론트엔드, 자바, oop[^1]

---

[^1]: 콘텐츠 메타데이터(제목/채널/길이/링크/키워드) 및 전체 맥락: "코딩 책 한 권만 읽으면 일어나는 일" / 코딩애플 / 5:27 / https://www.youtube.com/watch?v=th7n1rmlO4I
[^2]: @[00:05] "클린 코드… 종교처럼 따르고 신입 개발자한테 전도… 제발 그러지 마시고요"
[^3]: @[00:11] "읽어 보면 좋은 점 배울 점도 많은데… 이상한 점들도 많이 있어서"
[^4]: @[00:16] "첫 챕터는 이름 짓는 관습"
[^5]: @[00:22] "이상한… 변수명… 프리픽스… 장난… 함수나 메소드에는 동사가 들어가야"
[^6]: @[00:35] "함수는 무조건 하나의 일… 사이드 이펙트… 두 줄에서 네 줄 이하… 아규먼트… 세 개 이상이면"
[^7]: @[00:48] "종교처럼… 코드를 자려고 하시면… 가독성은… 쓰레기"
[^8]: @[01:05] "책에서 이런 최종 예시… 전부 다… 함수로 바꿔서"
[^9]: @[01:08] "전 솔직히 예전 코드가 더 나은 거 같습니다"
[^10]: @[01:46] "사람이 폭주"
[^11]: @[01:14] "여기저기를 왔다 갔다… 훨씬 읽기 어려워"
[^12]: @[01:16] "코드가 짧으면… 쓰는 것도 가독성 측면에서 나쁘지"
[^13]: @[01:22] "알몬트 줄이고… 함수 개수… 늘어나… 재사용하기도 어려울… 존재 의도 없어지는" + @[01:38] "항상 클린… 가독성도 좋아지는게 아니"
[^14]: @[01:51] "코드에 주석을 달지 말래요"
[^15]: @[02:52] "자유도가… 커스터마이징… 의도와 패턴 파악… 주석 잘 쓰는게 훨씬 도움"
[^16]: @[01:55] "어그로를… 요즘 시대… 골드 버튼"
[^17]: @[01:59] "영상 제목… 자극적으로 작성하는 법"
[^18]: @[02:03] "주석은 거짓말을 하는 경우가 많기 때문에"
[^19]: @[02:14] "코드만 잘 짜면 주석이 아예 필요가 없으니까요"
[^20]: @[02:18] "코드를 매우 잘 짜는 경우에만 맞는 소리"
[^21]: @[02:22] "대부분… 주석… 주석 쓰지 말라는 개발자들… 책 보고 하는 소리"
[^22]: @[02:27] "좋은 주석의 조건… 이런 주석들은 쓰는게 좋대요… 목차만 읽은"
[^23]: @[02:35] "프레임웍에 따라서 주석 여부도"
[^24]: @[02:41] "스프링부트… 주석이 아예 없어도… 애너테이션… 변수명"
[^25]: @[03:03] "주석 대신… 길고 복잡한 변수명… 영어… 문법… 그럴 바엔 주석" + @[02:58] "주석 잘 쓰는게 훨씬 도움"
[^26]: @[03:16] "클래스… 싱글… 커플링" + @[03:44] "기능들 다 쪼개… 클래스로… 그러라는 소리 아니" + @[05:01] "책 하나만 읽고… 종교처럼… 무서운"
[^27]: @[03:56] "중복… 발작… 짧은 코드 덩어리 두 번 세 번… 아무 문제 없습니다" + @[05:10] "작은 걸 크게 과장… 그대로 받아들이지 마시고… 의심"
[^28]: @[04:11] "강박적으로 함수로… 읽기 싫어질" + @[05:20] "클린 코드 말고도… 다양한 책"
[^29]: @[04:22] "html… 생성… 세 번… 등장"
[^30]: @[04:26] "함수로 빼서… 중복을 줄일 수"
[^31]: @[04:29] "나중에 변경 사항이 생기면 어쩔 거예요"
[^32]: @[04:33] "여기서는… 추가… 여기서는… 추가"
[^33]: @[04:39] "여러분들이… 추가하든"
[^34]: @[04:39] "if문 아니면 스위치문… 파라미터를 추가"
[^35]: @[04:49] "로직을… 추가… 코드가… 길어지고… 읽기 싫은 코드"
[^36]: @[04:54] "중복이 보이면… 항상 추상화… 꼭 필요한지… 생각"