From d7316e9107f14219a74c56da86c06f81ef195d0a Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Tue, 17 Jun 2025 18:13:19 +0900
Subject: [PATCH 1/9] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 "3\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/3\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
new file mode 100644
index 0000000..6f0fdd5
--- /dev/null
+++ "b/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -0,0 +1,69 @@
+# 3장. 함수
+
+## 함수를 잘 만드는 법을 소개
+
+### 한 가지만 해라!
+
+> p.79
+> 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
+
+### 함수 내 섹션
+
+> p.80
+> 순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.
+
+### 위에서 아래로 코드 읽기: 내려가기 규칙
+
+> p.81
+> 위에서 아래로 TO 문단을 읽어내려 가듯이 코드를 구현하면 추상
+
+### Switch 문
+
+> p.82
+> 화 수준을 일관되게 유지하기가 쉬워진다.
+
+### 오류 코드보다 예외를 사용하라!
+
+> p.92
+> 오류 코드보다 예외를 사용하라! 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다.
+> 자칫하면 if 문에서 명령을 표현식으로 사용하기 쉬운 탓이다.
+>
+> ```java
+> if (deletePage(page) == E_OK) {
+>   if (registry.deleteReference(page.name) == E_OK) {
+>     if (configKeys.deleteKey(page.name.makeKey()) == E_OK) {
+>       logger.log("page deleted");
+>     } else {
+>       logger.log("configKey not deleted");
+>     }
+>   } else {
+>     logger.log("deleteReference from registry failed");
+>   }
+> } else {
+>   logger.log("delete failed");
+>   return E_ERROR;
+> }
+> ```
+>
+> 반면 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.
+>
+> ```java
+> try {
+>   deletePage(page);
+>   registry.deleteReference(page.name);
+>   configKeys.deleteKey(page.name.makeKey());
+> } catch (Exception e) {
+>   logger.log(e.getMessage());
+> }
+> ```
+
+### 오류 처리도 한 가지 작업이다
+
+> p.94
+> 오류 처리도 한 가지 작업이다. 함수는 '한 가지' 작업만 해야 한다.
+> 오류 처리도 '한 가지' 작업에 속한다.
+> 그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다.
+>
+> 함수에 키워드 try가 있다면 함수는 try 문으로 시작해 catch/finally 문으로 끝나야 한다는 말이다.
+
+## 💭 느낀 점

From 955e6ed643ae1b33f2484ce11e35f347d2511eba Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Tue, 17 Jun 2025 18:25:06 +0900
Subject: [PATCH 2/9] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 117 ++++++++++++++++++
 1 file changed, 117 insertions(+)
 create mode 100644 "4\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/4\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/4\354\236\245/\354\265\234\354\204\234\355\235\254.md"
new file mode 100644
index 0000000..2bf7f74
--- /dev/null
+++ "b/4\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -0,0 +1,117 @@
+# 4장. 주석 
+
+## 📌 인상 깊은 내용
+
+### 나쁜 코드에 주석을 달지 마라. 새로 짜라.
+>**p.103**  
+
+### 주석은 나쁜 코드를 보완하지 못한다
+>**p.104**  
+>표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가,  
+복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다.  
+자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에  
+그 난장판을 깨끗이 치우는 데 시간을 보내라!
+
+### 코드로 의도를 표현하라!
+>**p.105**  
+>많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다.
+
+### 수로 만들어 표현해도 충분하다. 좋은 주석
+>**p.105**  
+
+### 법적인 주석
+>**p.105**  
+
+### 정보를 제공하는 주석
+>**p.106**  
+>가능하다면, 함수 이름에 정보를 담는 편이 더 좋다.
+
+### 의도를 설명하는 주석
+>**p.106**  
+
+### 의미를 명료하게 밝히는 주석
+>**p.107**  
+
+### 결과를 경고하는 주석
+>**p.108**  
+
+### TODO 주석
+>**p.109**  
+
+### 중요성을 강조하는 주석
+>**p.110**  
+
+### 공개 API에서 Javadocs
+>**p.110**  
+
+### 나쁜 주석
+>**p.110**  
+
+### 주절거리는 주석
+>**p.111**  
+>주석을 달기로 결정했다면 충분한 시간을 들여  
+최고의 주석을 달도록 노력한다.
+
+### 같은 이야기를 중복하는 주석
+>**p.112**  
+
+### 오해할 여지가 있는 주석
+>**p.114**  
+
+### 의무적으로 다는 주석
+>**p.115**  
+>모든 함수에 Javadocs를 달거나  
+모든 변수에 주석을 달아야 한다는 규칙은 어리석기 그지없다.
+
+### 이력을 기록하는 주석
+>**p.115**  
+
+### 있으나 마나 한 주석
+>**p.116**  
+>너무 당연한 사실을 언급하며  
+새로운 정보를 제공하지 못하는 주석이다
+
+### 무서운 잡음
+>**p.118**  
+
+### 함수나 변수로 표현할 수 있다면 주석을 달지 마라
+>**p.119**  
+
+### 위치를 표시하는 주석
+>**p.119**  
+
+### 닫는 괄호에 다는 주석
+>**p.120**  
+>중첩이 심하고 장황한 함수라면 의미가 있을지도 모르지만  
+(우리가 선호하는) 작고 캡슐화된 함수에는 잡음일 뿐이다.  
+
+>닫는 괄호에 주석을 달아야겠다는 생각이 든다면  
+대신에 함수를 줄이려 시도하자.
+
+### 공로를 돌리거나 저자를 표시하는 주석
+**p.121**  
+>위와 같은 정보는 소스 코드 관리 시스템에 저장하는 편이 좋다.
+
+### 주석으로 처리한 코드
+>**p.121**  
+
+### HTML 주석
+>**p.122**  
+
+### 전역 정보
+>**p.123**  
+>주석을 달아야 한다면 근처에 있는 코드만 기술하라.  
+코드 일부에 주석을 달면서 시스템의 전반적인 정보를 기술하지 마라.
+
+### 너무 많은 정보
+>**p.123**  
+
+### 모호한 관계
+
+### 함수 헤더
+>**p.124**  
+
+### 비공개 코드에서 Javadocs
+>**p.125**  
+
+## 💭 느낀 점

From 54057e2e2b6261ef518146463c9acd0f052dd948 Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Tue, 17 Jun 2025 18:25:32 +0900
Subject: [PATCH 3/9] =?UTF-8?q?Update=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 "3\354\236\245/\354\265\234\354\204\234\355\235\254.md" | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git "a/3\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
index 6f0fdd5..622139e 100644
--- "a/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
+++ "b/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -1,6 +1,6 @@
 # 3장. 함수
 
-## 함수를 잘 만드는 법을 소개
+## 📌 인상 깊은 내용 - 함수를 잘 만드는 법을 소개
 
 ### 한 가지만 해라!
 

From b53345a3eb91655d7c3f2c1838f9f6bbce76f3b7 Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Wed, 23 Jul 2025 22:43:27 +0900
Subject: [PATCH 4/9] =?UTF-8?q?Update=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 128 +++++++++---------
 1 file changed, 63 insertions(+), 65 deletions(-)

diff --git "a/3\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
index 622139e..24a49df 100644
--- "a/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
+++ "b/3\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -1,69 +1,67 @@
 # 3장. 함수
 
-## 📌 인상 깊은 내용 - 함수를 잘 만드는 법을 소개
-
-### 한 가지만 해라!
-
-> p.79
-> 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
-
-### 함수 내 섹션
-
-> p.80
-> 순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.
-
-### 위에서 아래로 코드 읽기: 내려가기 규칙
-
-> p.81
-> 위에서 아래로 TO 문단을 읽어내려 가듯이 코드를 구현하면 추상
-
-### Switch 문
-
-> p.82
-> 화 수준을 일관되게 유지하기가 쉬워진다.
-
-### 오류 코드보다 예외를 사용하라!
-
-> p.92
-> 오류 코드보다 예외를 사용하라! 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다.
-> 자칫하면 if 문에서 명령을 표현식으로 사용하기 쉬운 탓이다.
->
-> ```java
-> if (deletePage(page) == E_OK) {
->   if (registry.deleteReference(page.name) == E_OK) {
->     if (configKeys.deleteKey(page.name.makeKey()) == E_OK) {
->       logger.log("page deleted");
->     } else {
->       logger.log("configKey not deleted");
->     }
->   } else {
->     logger.log("deleteReference from registry failed");
->   }
-> } else {
->   logger.log("delete failed");
->   return E_ERROR;
-> }
-> ```
->
-> 반면 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.
->
-> ```java
-> try {
->   deletePage(page);
->   registry.deleteReference(page.name);
->   configKeys.deleteKey(page.name.makeKey());
-> } catch (Exception e) {
->   logger.log(e.getMessage());
-> }
-> ```
-
-### 오류 처리도 한 가지 작업이다
-
-> p.94
-> 오류 처리도 한 가지 작업이다. 함수는 '한 가지' 작업만 해야 한다.
-> 오류 처리도 '한 가지' 작업에 속한다.
-> 그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다.
->
-> 함수에 키워드 try가 있다면 함수는 try 문으로 시작해 catch/finally 문으로 끝나야 한다는 말이다.
+## 인상 깊은 내용 - 함수를 잘 만드는 법을 소개
+
+- **한 가지만 해라!**
+
+  함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
+  단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.
+
+- **위에서 아래로 코드 읽기: 내려가기 규칙**
+
+  위에서 아래로 TO 문단을 읽어내려 가듯이 코드를 구현하면 추상화 수준을 일관되게 유지하기 쉬워진다.
+
+- **오류 코드보다 예외를 사용하라!**
+
+  오류 코드보다 예외를 사용하라! 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다.
+  자칫하면 if 문에서 명령을 표현식으로 사용하기 쉬운 탓이다.
+
+  > ```java
+  > if (deletePage(page) == E_OK) {
+  >   if (registry.deleteReference(page.name) == E_OK) {
+  >     if (configKeys.deleteKey(page.name.makeKey()) == E_OK) {
+  >       logger.log("page deleted");
+  >     } else {
+  >       logger.log("configKey not deleted");
+  >     }
+  >   } else {
+  >     logger.log("deleteReference from registry failed");
+  >   }
+  > } else {
+  >   logger.log("delete failed");
+  >   return E_ERROR;
+  > }
+  > ```
+
+  반면 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.
+
+  > ```java
+  > try {
+  >   deletePage(page);
+  >   registry.deleteReference(page.name);
+  >   configKeys.deleteKey(page.name.makeKey());
+  > } catch (Exception e) {
+  >   logger.log(e.getMessage());
+  > }
+  > ```
+
+- **오류 처리도 한 가지 작업이다.**
+
+  오류 처리도 한 가지 작업이다. 함수는 '한 가지' 작업만 해야 한다.
+  오류 처리도 '한 가지' 작업에 속한다.
+  그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다.
+
+  함수에 키워드 try가 있다면 함수는 try 문으로 시작해 catch/finally 문으로 끝나야 한다는 말이다.
 
 ## 💭 느낀 점
+
+  가장 인상 깊었던 부분은 단연 **"한 가지만 해라!"** 라는 원칙이다.
+  최근 한 현직자에게 컴포넌트 분리 기준에 대해 물어본 적이 있었는데, 그분도 같은 이야기를 했다.
+
+  "하나의 파일이나 컴포넌트가 두 가지 이상의 역할을 하면 나눠야 한다."
+
+  이 원칙은 단순히 함수에만 적용되는 게 아니다.
+  **코드 전체의 구조, 설계, 나아가 팀의 개발 문화까지 관통하는 핵심 철학**이라고 느꼈다.
+
+  함수가 명확하면 모듈이 명확해지고, 모듈이 명확하면 시스템 전체가 깔끔해진다.
+  그래서 이 원칙은 가장 단순하면서도 가장 강력한 원칙이라고 생각한다.

From bef936ce66c98fb930668937aa7dbea2de16a12d Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Wed, 23 Jul 2025 23:11:00 +0900
Subject: [PATCH 5/9] =?UTF-8?q?Update=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 183 +++++++-----------
 1 file changed, 69 insertions(+), 114 deletions(-)

diff --git "a/4\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/4\354\236\245/\354\265\234\354\204\234\355\235\254.md"
index 2bf7f74..ca5c2fe 100644
--- "a/4\354\236\245/\354\265\234\354\204\234\355\235\254.md"
+++ "b/4\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -1,117 +1,72 @@
-# 4장. 주석 
+# 4장. 주석
+
+## 인상 깊은 내용
+
+- **나쁜 코드에 주석을 달지 마라. 새로 짜라.**
+
+- **주석은 나쁜 코드를 보완하지 못한다.**
+  표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다.
+  자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에, 그 난장판을 깨끗이 치우는 데 시간을 보내라!
+
+- **코드로 의도를 표현하라!**
+  많은 경우, 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다.
+
+- **좋은 주석**
+
+> 1. **법적인 주석**
+   회사 정책이나 법적 요구에 따라 파일 상단에 들어가는 저작권, 소유권 정보 등은 타당하고 필요하다.
+> 2. **정보를 제공하는 주석**
+   가능하다면 함수 이름에 정보를 담는 편이 더 좋지만, 꼭 필요한 경우 주석으로 보완한다.
+> 3. **의도를 설명하는 주석**
+> 4. **의미를 명료하게 밝히는 주석**
+   인수나 반환값이 외부 라이브러리에 속해 있어 변경할 수 없다면, 명료한 주석이 도움이 된다.
+> 5. **결과를 경고하는 주석**
+> 6. **TODO 주석**
+   당장 구현할 수 없는 작업을 기록한다.
+   예: 삭제 예정 기능, 리팩터링 요청, 추후 이벤트 대응 등
+   단, TODO가 시스템에 나쁜 코드를 남기는 핑계가 되어선 안 된다.
+   → **주기적으로 점검하고 제거하라.**
+> 7. **중요성을 강조하는 주석**
+> 8. **공개 API에서의 Javadocs**
+
+- **나쁜 주석**
+
+> 1. **주절거리는 주석**
+   주석을 달기로 했다면, 제대로 써야 한다. 대충 써놓고 넘기지 말 것.
+> 2. **같은 이야기를 중복하는 주석**
+> 3. **오해할 여지가 있는 주석**
+> 4. **의무적으로 다는 주석**
+   모든 함수에 Javadocs, 모든 변수에 주석을 강요하는 규칙은 비효율적이다.
+> 5. **이력을 기록하는 주석**
+> 6. **있으나 마나 한 주석**
+   너무 당연한 이야기를 반복하며 새로운 정보를 주지 못하는 주석
+> 7. **무서운 잡음**
+   때로는 Javadocs도 잡음이 된다.
+> 8. **함수나 변수로 표현할 수 있다면 주석을 달지 마라**
+> 9. **위치를 표시하는 주석**
+> 10. **닫는 괄호에 다는 주석**
+    중첩이 심한 구조에서 의미가 있을 수 있지만, 작고 명확한 함수에는 불필요하다.
+    닫는 괄호에 주석을 달고 싶다면, **함수를 더 작게 쪼개는 걸 먼저 고려하라.**
+> 11. **공로를 돌리거나 저자를 표시하는 주석**
+    이런 정보는 소스 코드 관리 시스템(Git 등)에 맡기는 게 낫다.
+> 12. **주석으로 처리한 코드**
+> 13. **HTML 주석**
+> 14. **전역 정보**
+    주석은 가능한 한 근처의 코드만 설명하라.
+    시스템 전체를 설명하려는 주석은 혼란을 키운다.
+> 15. **너무 많은 정보**
+> 16. **모호한 관계**
+    주석과 그 주석이 설명하는 코드 사이의 연결이 명확해야 한다.
+> 17. **함수 헤더**
+    짧고 명확한 함수는 긴 헤더 주석 없이도 충분하다.
+> 18. **비공개 코드에서의 Javadocs**
+    공개 API가 아니라면, Javadocs는 불필요한 경우가 많다.
+
+---
 
-## 📌 인상 깊은 내용
-
-### 나쁜 코드에 주석을 달지 마라. 새로 짜라.
->**p.103**  
-
-### 주석은 나쁜 코드를 보완하지 못한다
->**p.104**  
->표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가,  
-복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다.  
-자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에  
-그 난장판을 깨끗이 치우는 데 시간을 보내라!
-
-### 코드로 의도를 표현하라!
->**p.105**  
->많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다.
-
-### 수로 만들어 표현해도 충분하다. 좋은 주석
->**p.105**  
-
-### 법적인 주석
->**p.105**  
-
-### 정보를 제공하는 주석
->**p.106**  
->가능하다면, 함수 이름에 정보를 담는 편이 더 좋다.
-
-### 의도를 설명하는 주석
->**p.106**  
-
-### 의미를 명료하게 밝히는 주석
->**p.107**  
-
-### 결과를 경고하는 주석
->**p.108**  
-
-### TODO 주석
->**p.109**  
-
-### 중요성을 강조하는 주석
->**p.110**  
-
-### 공개 API에서 Javadocs
->**p.110**  
-
-### 나쁜 주석
->**p.110**  
-
-### 주절거리는 주석
->**p.111**  
->주석을 달기로 결정했다면 충분한 시간을 들여  
-최고의 주석을 달도록 노력한다.
-
-### 같은 이야기를 중복하는 주석
->**p.112**  
-
-### 오해할 여지가 있는 주석
->**p.114**  
-
-### 의무적으로 다는 주석
->**p.115**  
->모든 함수에 Javadocs를 달거나  
-모든 변수에 주석을 달아야 한다는 규칙은 어리석기 그지없다.
-
-### 이력을 기록하는 주석
->**p.115**  
-
-### 있으나 마나 한 주석
->**p.116**  
->너무 당연한 사실을 언급하며  
-새로운 정보를 제공하지 못하는 주석이다
-
-### 무서운 잡음
->**p.118**  
-
-### 함수나 변수로 표현할 수 있다면 주석을 달지 마라
->**p.119**  
-
-### 위치를 표시하는 주석
->**p.119**  
-
-### 닫는 괄호에 다는 주석
->**p.120**  
->중첩이 심하고 장황한 함수라면 의미가 있을지도 모르지만  
-(우리가 선호하는) 작고 캡슐화된 함수에는 잡음일 뿐이다.  
-
->닫는 괄호에 주석을 달아야겠다는 생각이 든다면  
-대신에 함수를 줄이려 시도하자.
-
-### 공로를 돌리거나 저자를 표시하는 주석
-**p.121**  
->위와 같은 정보는 소스 코드 관리 시스템에 저장하는 편이 좋다.
-
-### 주석으로 처리한 코드
->**p.121**  
-
-### HTML 주석
->**p.122**  
-
-### 전역 정보
->**p.123**  
->주석을 달아야 한다면 근처에 있는 코드만 기술하라.  
-코드 일부에 주석을 달면서 시스템의 전반적인 정보를 기술하지 마라.
-
-### 너무 많은 정보
->**p.123**  
-
-### 모호한 관계
-
-### 함수 헤더
->**p.124**  
+## 💭 느낀 점
 
-### 비공개 코드에서 Javadocs
->**p.125**  
+이번 장에서는 **좋은 주석과 나쁜 주석**을 구분해 구체적으로 설명해줘서 매우 유용했다.
+앞으로 주석을 달아야 할 일이 생긴다면, 이 기준을 참고해 더 신중하게 작성할 것이다.
 
-## 💭 느낀 점
+가장 핵심적인 포인트는, **"코드만으로 설명할 수 있다면 주석을 달지 않는 것이 최선"** 이라는 점이다.

From 2529007ce15d716790f225b5c701833c88a81059 Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Wed, 23 Jul 2025 23:42:24 +0900
Subject: [PATCH 6/9] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 54 +++++++++++++++++++
 1 file changed, 54 insertions(+)
 create mode 100644 "5\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/5\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/5\354\236\245/\354\265\234\354\204\234\355\235\254.md"
new file mode 100644
index 0000000..2d45f94
--- /dev/null
+++ "b/5\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -0,0 +1,54 @@
+# 5장. 형식 맞추기
+
+## 인상 깊은 내용 
+
+- **형식을 맞추는 목적**
+
+ 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.
+ 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.
+ 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바귀어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.
+
+- **적절한 행 길이를 유지하라**
+
+  일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.
+
+- **신문 기사처럼 작성하라**
+
+  이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다.
+
+- **개념은 빈 행으로 분리하라**
+
+  너무도 간단한 규칙이지만 코드의 새로 레이아웃에 심오한 영향을 미친다. 빈 행은 새로운 개념을 시작한다는 시각적 단서다. 코드를 읽어 내려가다 보면 빈 행 바로 다음 줄에 눈길이 멈춘다.
+
+- **세로 밀집도**
+  줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다.
+
+- **수직 거리**
+  서로 밀접한 개념은 세로로 가까이 둬야 한다.
+
+  같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리고 연관성을 표현한다. 여기서 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도다. 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다.
+  변수 선언, 변수는 사용하는 위치에 쵀ㅣ대한 가까이 선언한다. 우리가 만든 함수는 매우 짧으므로 지역 변수는 각 함수 맨 처음에 선언한다.
+
+- **가로 형식 맞추기**
+  가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.
+
+- **들여쓰기**-
+  범위로 이뤄진 계층을 표현하기 위해 우리는 코드를 들여쓴다.
+  한 행에 범위를 뭉뚱그린 코드는 피해야한다.
+
+- **팀 규칙**-
+  개개인이 따로국밥처럼 맘대로 짜대는 코드는 피해야 한다.
+  스타일은 일관적이고 매끄러워야 한다. 한 소스 파일에서 봤던 형식이 다르 소스 파일에도 쓰이라는 신뢰감을 독자에게 줘야 하낟. 온갖 스타일을 뒤섞어 소스 코드를 필요 이상으로 복잡하게 만드는 실수는 반드시 피한다.
+
+## 💭 느낀 점
+최근 프로젝트를 진행하면서, 초반에는 팀 규칙을 철저히 따랐다.
+코드 리뷰도 꼼꼼히 진행했고, 항상 `develop` 브랜치로 병합하기 전에 충분한 검토를 거쳤다.
+
+하지만 마감 기한이 다가올수록 이런 원칙들이 하나둘 무너지기 시작했다.
+서로 리뷰 없이 코드를 밀어넣거나, 스타일 가이드를 무시한 채 급하게 작업을 끝내는 일이 점점 많아졌다.
+
+또한 **“어차피 다음 스프린트에서 또 수정할 테니 지금은 이 정도면 괜찮겠지”** 라는 생각으로 여러 부분을 임시로 처리한 적도 있었다.
+하지만 그런 임시방편은 결국 **엄청난 리팩터링 부담**으로 되돌아왔다.
+
+이번 장을 읽으며 그때의 선택들이 자연스레 떠올랐고, 스스로를 돌아보게 되었다.
+그리고 다시금 깨달았다. **작은 원칙 하나를 끝까지 지키는 힘이, 결국 전체 시스템의 품질을 결정한다.**

From 69a045fe92b8c6f69bd866d682e481846f887dd2 Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Wed, 23 Jul 2025 23:50:40 +0900
Subject: [PATCH 7/9] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 "6\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/6\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/6\354\236\245/\354\265\234\354\204\234\355\235\254.md"
new file mode 100644
index 0000000..62e5e6c
--- /dev/null
+++ "b/6\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -0,0 +1,30 @@
+# 6장. 객체와 자료 구조
+
+## 인상 깊은 내용
+
+* 객체는 **동작을 공개하고 자료를 숨긴다.**
+  그래서 기존 동작을 변경하지 않으면서 새로운 객체 타입을 추가하기는 쉽다.
+  하지만 기존 객체에 새로운 동작을 추가하는 것은 어렵다.
+
+* 반대로 자료 구조는 **자료를 공개하고 동작은 숨긴다.**
+  그래서 기존 자료 구조에 새로운 동작을 추가하는 것은 쉽지만,
+  기존 함수에 새로운 자료 구조를 적용하기는 어렵다.
+
+---
+
+## 💭 느낀 점
+
+이번 장은 **자바를 기반으로 설명된 내용이 많아**,
+프론트엔드를 준비하고 있는 나로서는 이해하기가 조금 어려웠다.
+
+객체와 자료 구조의 차이를 언급하는 내용은 중요하다고 느꼈지만,
+아직은 내 개발 맥락과 직접적으로 연결되지 않아 완전히 와닿지는 않았다.
+
+그래서 프론트엔드 관점에서도 이 개념이 어떻게 적용될 수 있는지
+React와 상태 관리 라이브러리(Zustand, Redux 등)에서의 예제를 찾아보며 추가로 공부했다.
+
+예를 들어, **상태 관리 객체에 메서드를 함께 정의하는 방식**은 객체 지향적인 구조이고,
+반대로 **순수한 데이터와 액션을 분리해 처리하는 Redux 같은 패턴**은 자료 구조 중심 설계에 더 가깝다는 걸 알게 됐다.
+
+비록 처음엔 어려웠지만,
+앞으로 **상태 모델링, 커스텀 훅 설계, 컴포넌트 추상화**를 할 때 이 개념들이 실제로 도움이 될 거라고 느꼈다.

From 6e75251988cdd4850e4d4da5a9a724d6ef81d32d Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Thu, 24 Jul 2025 00:15:05 +0900
Subject: [PATCH 8/9] =?UTF-8?q?Delete=205=EC=9E=A5/=EC=B5=9C=EC=84=9C?=
 =?UTF-8?q?=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 54 -------------------
 1 file changed, 54 deletions(-)
 delete mode 100644 "5\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/5\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/5\354\236\245/\354\265\234\354\204\234\355\235\254.md"
deleted file mode 100644
index 2d45f94..0000000
--- "a/5\354\236\245/\354\265\234\354\204\234\355\235\254.md"
+++ /dev/null
@@ -1,54 +0,0 @@
-# 5장. 형식 맞추기
-
-## 인상 깊은 내용 
-
-- **형식을 맞추는 목적**
-
- 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.
- 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.
- 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바귀어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.
-
-- **적절한 행 길이를 유지하라**
-
-  일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.
-
-- **신문 기사처럼 작성하라**
-
-  이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다.
-
-- **개념은 빈 행으로 분리하라**
-
-  너무도 간단한 규칙이지만 코드의 새로 레이아웃에 심오한 영향을 미친다. 빈 행은 새로운 개념을 시작한다는 시각적 단서다. 코드를 읽어 내려가다 보면 빈 행 바로 다음 줄에 눈길이 멈춘다.
-
-- **세로 밀집도**
-  줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다.
-
-- **수직 거리**
-  서로 밀접한 개념은 세로로 가까이 둬야 한다.
-
-  같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리고 연관성을 표현한다. 여기서 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도다. 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다.
-  변수 선언, 변수는 사용하는 위치에 쵀ㅣ대한 가까이 선언한다. 우리가 만든 함수는 매우 짧으므로 지역 변수는 각 함수 맨 처음에 선언한다.
-
-- **가로 형식 맞추기**
-  가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.
-
-- **들여쓰기**-
-  범위로 이뤄진 계층을 표현하기 위해 우리는 코드를 들여쓴다.
-  한 행에 범위를 뭉뚱그린 코드는 피해야한다.
-
-- **팀 규칙**-
-  개개인이 따로국밥처럼 맘대로 짜대는 코드는 피해야 한다.
-  스타일은 일관적이고 매끄러워야 한다. 한 소스 파일에서 봤던 형식이 다르 소스 파일에도 쓰이라는 신뢰감을 독자에게 줘야 하낟. 온갖 스타일을 뒤섞어 소스 코드를 필요 이상으로 복잡하게 만드는 실수는 반드시 피한다.
-
-## 💭 느낀 점
-최근 프로젝트를 진행하면서, 초반에는 팀 규칙을 철저히 따랐다.
-코드 리뷰도 꼼꼼히 진행했고, 항상 `develop` 브랜치로 병합하기 전에 충분한 검토를 거쳤다.
-
-하지만 마감 기한이 다가올수록 이런 원칙들이 하나둘 무너지기 시작했다.
-서로 리뷰 없이 코드를 밀어넣거나, 스타일 가이드를 무시한 채 급하게 작업을 끝내는 일이 점점 많아졌다.
-
-또한 **“어차피 다음 스프린트에서 또 수정할 테니 지금은 이 정도면 괜찮겠지”** 라는 생각으로 여러 부분을 임시로 처리한 적도 있었다.
-하지만 그런 임시방편은 결국 **엄청난 리팩터링 부담**으로 되돌아왔다.
-
-이번 장을 읽으며 그때의 선택들이 자연스레 떠올랐고, 스스로를 돌아보게 되었다.
-그리고 다시금 깨달았다. **작은 원칙 하나를 끝까지 지키는 힘이, 결국 전체 시스템의 품질을 결정한다.**

From b7d18d3526fac180974d5da0ef6e048128b65d90 Mon Sep 17 00:00:00 2001
From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com>
Date: Thu, 24 Jul 2025 00:16:29 +0900
Subject: [PATCH 9/9] =?UTF-8?q?Delete=206=EC=9E=A5/=EC=B5=9C=EC=84=9C?=
 =?UTF-8?q?=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 30 -------------------
 1 file changed, 30 deletions(-)
 delete mode 100644 "6\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/6\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/6\354\236\245/\354\265\234\354\204\234\355\235\254.md"
deleted file mode 100644
index 62e5e6c..0000000
--- "a/6\354\236\245/\354\265\234\354\204\234\355\235\254.md"
+++ /dev/null
@@ -1,30 +0,0 @@
-# 6장. 객체와 자료 구조
-
-## 인상 깊은 내용
-
-* 객체는 **동작을 공개하고 자료를 숨긴다.**
-  그래서 기존 동작을 변경하지 않으면서 새로운 객체 타입을 추가하기는 쉽다.
-  하지만 기존 객체에 새로운 동작을 추가하는 것은 어렵다.
-
-* 반대로 자료 구조는 **자료를 공개하고 동작은 숨긴다.**
-  그래서 기존 자료 구조에 새로운 동작을 추가하는 것은 쉽지만,
-  기존 함수에 새로운 자료 구조를 적용하기는 어렵다.
-
----
-
-## 💭 느낀 점
-
-이번 장은 **자바를 기반으로 설명된 내용이 많아**,
-프론트엔드를 준비하고 있는 나로서는 이해하기가 조금 어려웠다.
-
-객체와 자료 구조의 차이를 언급하는 내용은 중요하다고 느꼈지만,
-아직은 내 개발 맥락과 직접적으로 연결되지 않아 완전히 와닿지는 않았다.
-
-그래서 프론트엔드 관점에서도 이 개념이 어떻게 적용될 수 있는지
-React와 상태 관리 라이브러리(Zustand, Redux 등)에서의 예제를 찾아보며 추가로 공부했다.
-
-예를 들어, **상태 관리 객체에 메서드를 함께 정의하는 방식**은 객체 지향적인 구조이고,
-반대로 **순수한 데이터와 액션을 분리해 처리하는 Redux 같은 패턴**은 자료 구조 중심 설계에 더 가깝다는 걸 알게 됐다.
-
-비록 처음엔 어려웠지만,
-앞으로 **상태 모델링, 커스텀 훅 설계, 컴포넌트 추상화**를 할 때 이 개념들이 실제로 도움이 될 거라고 느꼈다.