From d5226361621cc0d59b1b3cd3ef58a5427ce0bc42 Mon Sep 17 00:00:00 2001
From: choihooo <hochoi8621@naver.com>
Date: Thu, 10 Apr 2025 20:48:27 +0900
Subject: [PATCH 1/2] =?UTF-8?q?6=EC=9E=A5=20=EC=B5=9C=ED=98=B8?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

diff --git "a/6\354\236\245/\354\265\234\355\230\270.md" "b/6\354\236\245/\354\265\234\355\230\270.md"
new file mode 100644
index 0000000..58c116e
--- /dev/null
+++ "b/6\354\236\245/\354\265\234\355\230\270.md"
@@ -0,0 +1,34 @@
+# Part 2: 실행, 실행, 실행
+
+## Ch 6. 아이디어는 일찍 그리고 자주 검증하라
+
+### 인상 깊었던 내용
+> 반복적인 접근법은 손실이 큰 오류를 줄이고 반복 주기 사이에 데이터를 모으고 경로를 수정할 기회를 제공한다. 각 반족 주기가 짧을수록 실수에서 더 빨리 배울 수 있다.
+
+-> 반복주기를 짧게 만든다. -> 검증을 더 많이 할 수 있다. -> 좋은 지표를 찾을 수 있다?
+
+> 노력을 일부 할애해서 지금 내가 하는 작업이 효과가 있을지 데이터를 모으고 검증할 수 있을까? 계획에 대한 자신감 때문에 간접 비용을 10% 추가하는 것조차 망설일 때가 많다. 이 10%의 비용이 꼭 유용한 통찰이나 재사용 가능한 작업을 산출하리란 보장이 없는 것도 사실이다. 그러나 계획상 큰 결함이 발견되면 나머지 90%의 노력이 낭비되는 것을 막아준다.
+
+-> 계획에 대한 자신감이 있는 것은 좋지만, 계획에 대한 검증의 필요성에 대해 다시 한 번 고민해볼 필요가 있겠다. 생각했다.
+
+> 우리 모두가 스타트업 제품을 만드는 것은 아니지만, 적은 노력으로 작업을 검증한다는 원칙은 많은 엔지니어링 프로젝트에서 유효하다.
+
+-> 꼭 제품을 출시하는 것만 검증할 필요도 없고 검증이라고 해서 대단한 노력을 기울여야한다는 것도 아니다.
+
+> A/B 테스트에서는 변경사항이나 새로운 기능을 임의의 일부 사용자에게만 노출하고 대조군에 속하는 다른 모든 사용자에게는 노출하지 않는다. 
+
+> A/B 테스트는 출시할 변경사항을 정할 때만 도움 되는 것이 아니다. 특정 변경사항이 지표를 개선할 거라고 절대적으로 확신하는 상황에서도 유용하다. 그 변형이 실제 얼마나 더 나은지 알려주기 때문이다.
+
+-> A/B 테스트는 앞선 장에서 말한 좋은 지표를 정할때도 유용할까? 유용하다면 어떤 방식으로 체크해야할까
+
+> 1인 프로젝트에서 피드백을 받는 절차에 마찰이 생기는 것은 문제다. 자신이 작업한 내용이 제대로 작동할지 검증하려면 피드백이 필요하다. 그런데 리뷰어가 한 팀에 있어서 프로젝트의 맥락을 이해하고 있지 않은 한 코드 리뷰에서 좋은 피드백을 받기 어렵다.
+
+-> 1인 프로젝트를 진행하면서 코드 리뷰를 받을 기회가 많이 없었는데 많이 요청해야겠다고 생각했다.
+
+> 코드를 일찍 자주 커밋하라.
+
+-> 항상 작은 구현은 커밋을 안하고 넘어갔었는데, 결함이 발생했을때 어디까지 돌려야할지 난감했던적이 많았다. 스스로 명심해야할 문장인것 같다.
+
+> 코드에 에너지를 쏟기 전에 설계 문서를 공유하라.
+
+-> 요새 코딩하면서 제일 고민하고 있는 문제이다. 어떻게 해야 문서를 잘 작성할 수 있을까 궁금하다. 다른 프론트 개발자들은 어떻게 설계 문서를 작성할까? 프로젝트에 관련된 모든 문서라도..
\ No newline at end of file

From 275184308420309bd0ed06bc66f8b0831366a26a Mon Sep 17 00:00:00 2001
From: choihooo <hochoi8621@naver.com>
Date: Fri, 11 Apr 2025 11:15:18 +0900
Subject: [PATCH 2/2] =?UTF-8?q?7=EC=9E=A5=20=EC=B5=9C=ED=98=B8?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

diff --git "a/7\354\236\245/\354\265\234\355\230\270.md" "b/7\354\236\245/\354\265\234\355\230\270.md"
new file mode 100644
index 0000000..4c51566
--- /dev/null
+++ "b/7\354\236\245/\354\265\234\355\230\270.md"
@@ -0,0 +1,48 @@
+# Part 2: 실행, 실행, 실행
+
+## Ch 7. 프로젝트 추정 기술을 향상시켜라
+
+### 인상 깊었던 내용
+
+> 프로젝트 추정은 이펙티브 엔지니어가 익혀야할 어려운 기술 중 하나다. 그러나 숙달하는 것이 중요하다. 기업이 제품에 대해 장기적인 계획을 세우려면 정확한 추정이 필요하다. 프로젝트 추정의 정확성을 높이고 변화하는 요구 조건에 적응하는 능력을 키워야 프로젝트 계획을 성공적으로 세울 수 있다.
+
+> 좋은 추정이란 프로젝트 현실을 명확히 보여주는 추정으로 프로젝트 리더가 프로젝트를 통하제하고 목표를 달성하는 좋은 방법을 결정할 수 있게 한다. 프로젝트에 드는 시간과 작업량에 관한 최선의 추측을 반영하는 **추정**과 사업적 지향점을 나타내는 **목표**를 구분한다. 개발자는 추정, 관리자와 경영자는 목표를 설정한다.
+
+-> 나의 기술적 역량을 객관적으로 인지하고, 해결하는데 드는 시간과 작업량을 잘 추정할수 있는 사람이 되어야겠다.
+
+> 1. 프로젝트를 더 작은 작업으로 분리해라.
+> 2. 원하는 작업시간 말고, 작업에 실제로 드는 시간을 기준으로 추정하라.
+> 3. 추정을 최상의 시나리오가 아닌 확률 분포로 생각해라.(4주 이내에 완성할 가능성이 50%고, 8주 이내에 완성할 가능성은 90%입니다.)
+> 4. 실무 업무 담당자가 추정하게 하라.
+
+-> 항상 몇일까지 되요, 될것 같아요라는 말을 자주 했었는데 확률 분포로 말하라는게 좋은 아이디어라고 생각한다. 물론 8주 이내에 90% 가능성이라고 해서 데드라인을 8주로 생각하고 달리는 것은 좋지 않은것 같다.
+
+> 추정하지 못하고 했던 변수들:
+>
+> 1. 새로운 코드베이스를 위한 단위 테스트 장치를 개발하고 테스트용 자체 모의 라이브러리 작성하기
+> 2. 일련의 코드 스타일 가이드라인을 위해 코드 작성전에 가이드라인을 개발해야한다는것
+> 3. 우선순위가 높은 일부 고객에 대응하느라 작업 중단하기
+
+> 이상적인 1일차 엔지니어링 업무를 일상적인 방해 요소를 감안해서 근무일 2일로 계산
+
+-> 여러 방해 요소들을 생각하지 않고 하루에 8시간은 집중할수 있다고 생각했었는데 반성한다.
+
+> 경각심을 높일 수 있게 프로젝트 계획에 원래 포함되지 않았는데 쓴 시간을 명시적으로 추적하라.
+
+> 잘 정의해둔 목표는 작업 목록에서 꼭 해야 할 일과 하면 좋은 일을 구분하는 중요한 필터가 된다. 목표가 구체적일 수록 기능을 구별하는데 도움이 된다.
+
+-> 목표를 정의해두고 그 목표를 이루기 위한 리스트를 작성할때에는 목표에만 집중하자.
+
+> 목표 달성을 위해 측정할 수 있는 마일스톤을 세우는 것이다.
+
+-> 이번 프로젝트에서 깃허브 마일스톤 활용해보기.
+
+> 가장 위험한 영역부터 처리하면 이와 관련된 추정 오류를 찾아내는데 도움이 된다. 첫째, 여러 조각을 이어줄 접학제와 각 조각 간의 상호작용 방식에 관해 더 생각해야하므러, 동합 관련 추정을 다듬고 프로젝트 위험을 줄이는데 도움이 된다. 둘째, 개발중에 무언가 종단간 시스템을 망가뜨리더라도 조기에 발견할 수 있어서 훨씬 적은 코드 복잡성을 다루게 된다. 셋째, 통합 비용을 개발 프로세스 전반으로 분할할 수 있어서 실제로 통합 작업이 얼마나 남아 있는지 더 정확하게 인식하는데 도움이 된다.
+
+> 원래 버전에 이미 익숙하기 때문에 새로운 영역을 맡을때보다 재작성 프로젝트를 크게 과소평가하는 경향이 있다.
+
+-> 리팩토링할때 꼭 명심하자.
+
+> 성공적으로 리팩토링한 개발자들은 대규모 리팩토링을 소규모 프로젝트로 변환하여 진행한다. 작은 단계를 밟아가며 진행하면 오류 발생의 위험이 줄어든다. 구조를 재구성하는 동안 시스템의 손상도 피할 수 있다. 그러면 장기간에 걸쳐 시스템을 점진적으로 리팩터링 할 수 있다.
+
+> 시스템을 점진적으로 재작성하는 것은 레버리지가 높은 활동이다.