From d4ecdfec7d4f4dea24191c831ffc341fc10d55fc Mon Sep 17 00:00:00 2001
From: bbbang105 <2018111366@dgu.ac.kr>
Date: Sun, 20 Apr 2025 15:41:08 +0900
Subject: [PATCH 1/2] =?UTF-8?q?6=EC=9E=A5=20=ED=95=9C=EC=83=81=ED=98=B8?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\355\225\234\354\203\201\355\230\270.md"   | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 "6\354\236\245/\355\225\234\354\203\201\355\230\270.md"

diff --git "a/6\354\236\245/\355\225\234\354\203\201\355\230\270.md" "b/6\354\236\245/\355\225\234\354\203\201\355\230\270.md"
new file mode 100644
index 0000000..f73815c
--- /dev/null
+++ "b/6\354\236\245/\355\225\234\354\203\201\355\230\270.md"
@@ -0,0 +1,18 @@
+# 🔖 Ch6. 아이디어는 일찍 그리고 자주 검증하라
+
+> 작성 일자 : 2025.04.19 / 작성자 : 한상호
+
+## 💫 기억에 남는 문구
+
+- `p.164` : 무언가 제대로 작동하지 않는다는 혹독한 비평은 사용자보다 동료에게 미리 받는 것이 낫다.
+- `p.166` : "소프트웨어 개발은 단체 경기다."
+- `p.167` : "어떤 의사 결정을 내리든 이를 위한 피드백 과정이 있어야 합니다. 피드백 과정이 없으면 그냥... 추측하는 겁니다."
+- `p.169` : 1인 프로젝트를 할 때는 정기적으로 피드백을 구할 방법을 찾아라.
+
+## 💡 느낀 점
+
+1. 문제가 없다고 배포를 한 이후에, 서비스를 이용하는 사용자로부터 버그 제보를 받은 적이 있었다. 그 때부터는 머리가 많이 복잡해지고, 불안정한 서비스를 제공했다는 생각에 마음이 불편해진다. 이럴 때면 '조금만 더 꼼꼼히 보았다면..' 이라는 생각이 많이 드는 것 같다. 때문에 이후로는 QA를 조금 더 확실히, 여러 상황에서 하기 위해 노력하고 있다.
+2. 개발을 하면 할수록, 협업 능력이 중요함을 느낀다. 정답이 없어서 그런 것 같기도 하다. 
+3. 만약 정해진 정답이 있었다면, 개발 천재 혼자서 하는 게 가장 빠르고 좋지 않을까? 누구한테 피드백을 받고 수정할 시간도 들지 않으니 말이다.
+4. 하지만 내 생각에 개발은 정답이 없고, 늘 더 나은 방향을 위해서 고민하고 나아가는 것뿐이다. 때문에 좋은 팀, 소통 능력, 피드백 과정이 중요한 것 같다.
+5. 원타임 백엔드 개발을 혼자 하면서 느낀 장단점들이 잘 나오는 장이었던 것 같다. 빠르게 개발하고 배포할 수 있었지만, 기존에 익숙했던 나의 스타일대로 코드를 작성하게 되었고 비효율적인 구조로 설계를 하였더라도 이를 알기 어려웠다. 때문에 나중에는 1명을 영입해서 함께 해도 좋을 것 같다는 생각이 든다. 현재로써는 코드 래빗과 같은 코드리뷰 툴들을 활용해보아야겠다. 

From 9b1e4e12360a1e4f90179dc1e48c0cf27bd537c6 Mon Sep 17 00:00:00 2001
From: bbbang105 <2018111366@dgu.ac.kr>
Date: Sun, 20 Apr 2025 15:41:17 +0900
Subject: [PATCH 2/2] =?UTF-8?q?7=EC=9E=A5=20=ED=95=9C=EC=83=81=ED=98=B8?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\355\225\234\354\203\201\355\230\270.md"  | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 "7\354\236\245/\355\225\234\354\203\201\355\230\270.md"

diff --git "a/7\354\236\245/\355\225\234\354\203\201\355\230\270.md" "b/7\354\236\245/\355\225\234\354\203\201\355\230\270.md"
new file mode 100644
index 0000000..8d815f1
--- /dev/null
+++ "b/7\354\236\245/\355\225\234\354\203\201\355\230\270.md"
@@ -0,0 +1,24 @@
+# 🔖 Ch7. 프로젝트 추정 기술을 향상시켜라
+
+> 작성 일자 : 2025.04.19 / 작성자 : 한상호
+
+## 💫 기억에 남는 문구
+
+- `p.176` : 작업을 더 잘게 나눌수록 예상치 못 한 하위 작업이 나중에 슬그머니 나타날 가능성이 줄어든다.
+- `p.176` : 어떤 기능을 6주 이내에 완성하겠다고 말하기보다 "이 기능을 지금부터 4주 이내에 완성할 가능성이 50%고, 8주 이내에 완성할 가능성은 90% 입니다." 라고 말하는 것이 좋다.
+- `p.178` : 한 여성이 아홉 달 안에 아이를 낳을 수 있다고 해서 9명의 여성이 한 달 안에 아이를 낳을 수 있는 것은 아니다.
+- `p.182` : 하지만 대개 재난을 일으키는 것은 토네이도가 아니라 흰개미 떼다.
+- `p.184` : 일정을 설정할 때 예기치 못 한 방해 요소를 고려해서 여유 시간을 추가하라.
+- `p.187` : "해결하려는 문제가 정확히 무엇인지 아주 명확히 해둔 것이 프로젝트 범위에 속하는 것과 그렇지 않은 것을 구분하는데 도움이 되었습니다."
+- `p.195` : "두 번째 시스템은 인간이 설계한 가장 위험한 시스템이다. ... 일반적으로 두 번째 시스템은 첫 번째 시스템에서 조심스럽게 피했던 모든 아이디어와 장식을 사용해 과하게 설계하는 경향이 있다."
+- `p.199` : 초과 근무 시 생산성이 빠르게 감소한다는 것을 알아냈다. 지친 근로자는 실수하기 시작하고 생산량의 단기적 증가는 그 이후 생산량을 희생시켰다.
+- `p.203` : 가장 위험한 작업을 먼저 하라. ... 프로젝트 초반에 하기 쉬운 일에 집중해 놓고 일이 잘 진행되고 있다고 착각하지 마라.
+
+## 💡 느낀 점
+
+1. 나도 일정을 짤 때 나의 체력이나 다른 방해 요소들을 고려하지 못 하고 했던 것 같다. 즉, "5개의 일이 있다면 각각 1시간씩 걸릴테니.. 5시간이면 되겠군!" 과 같은 식이다. 각 일을 시작할 때까지의 준비 시간, 전환 비용, 방해 요소, 체력적인 문제 등을 전혀 고려하지 않았던 것이다.
+2. 때문에 무리한 일정을 잡게 되고, 이는 계속해서 다음 날로 밀리며 결국에는 밤을 새면서 해결했던 적이 많았다. 그럴 때면 어떻게든 해냈다는 승리감과 뿌듯함이 있기는 했지만, 이는 점점 내 몸을 갉아먹었던 것 같다. 정말 다행히 아직 쓰러지거나 몸에 큰 문제가 있었던 적은 없으나.. 요즘 들어 오래 앉아있어서 그런지 허리나 무릎 등이 조금씩 아픈 듯하다. 그리고 잠을 많이 자지 못한 날이면 효율성도 많이 떨어짐을 느꼈다.
+3. 이러한 부분들을 느낀 이후로는 너무 늦은 시간까지 일을 하려 하지는 않고, 미룰 수 있다면 미루려고 한다. 나의 체력적인 한계나 능력 부족 등을 인정을 하고, 다음 날에 좀 더 나은 컨디션으로 작업을 하는 것이 낫다는 것을 깨닫는 요즘이다.
+4. "일단" 프로젝트에 투입되면서, 기존에 있는 코드를 기반으로 작업을 진행해왔다. 처음에는 전부 다 리팩토링을 진행하여 나의 스타일대로 맞추고 싶었다. 하지만 시간 부족으로 인해 그렇게 하지는 못 했고, 지금은 점차 바꿔나가며 안정화 되고 있다.
+5. 책을 읽으며 "나의 생각이 많이 위험했구나" 라는 것을 느꼈다. 실제로 리팩토링을 하면서 새롭게 적용해 보고 싶은 부분들이 많았기 때문이다. 만약 이를 시작했다면 얼마나 오랜 시간이 걸렸을지 가늠하기가 어렵다. 아마 IOS 출시까지도 어려웠을 듯하다.
+6. 그렇기에 지금은 조금씩 리팩토링을 하며 개선하는 것이 목표이다. 현실적인 요소도 있고, 이렇게 작업해 보는 경험도 나에게 좋을 것 같아서 결정하게 되었다.