diff --git "a/_posts/blog/posts/\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270/2024-07-14-\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270 1\354\236\245 \354\213\244\354\232\251\354\243\274\354\235\230 \354\262\240\355\225\231.md" "b/_posts/blog/posts/\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270/2024-07-14-\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270 1\354\236\245 \354\213\244\354\232\251\354\243\274\354\235\230 \354\262\240\355\225\231.md"
index bcde90072..8706c263b 100644
--- "a/_posts/blog/posts/\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270/2024-07-14-\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270 1\354\236\245 \354\213\244\354\232\251\354\243\274\354\235\230 \354\262\240\355\225\231.md"	
+++ "b/_posts/blog/posts/\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270/2024-07-14-\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270 1\354\236\245 \354\213\244\354\232\251\354\243\274\354\235\230 \354\262\240\355\225\231.md"	
@@ -4,6 +4,10 @@ author: 신성일
 date: 2024-07-14 16:13:54 +0900
 categories: study, 실용주의프로그래머
 tags:
+  - "#study"
+sr-due: 2024-07-18
+sr-interval: 3
+sr-ease: 250
 ---
 
 ## Topic 1 - 당신의 인생이다
@@ -50,7 +54,7 @@ tags:
 > 변화의 촉매가 되라
 
 - 어떤 시스템을 개발하려고할 때 `시작 피로`에 빠지기 쉽다. 이때는 개발에 필요한 자원을 얻기 위해 사람들을 설득하는 것은 쉽지 않다.
-- 하지만 작은 것을 잘 개발하여 사람들에게 보여주고, 사람들로 하여금 조금씩 추가해달라고 할떄까지 기다려라
+- 하지만 작은 것을 잘 개발하여 사람들에게 보여주고, 사람들로 하여금 조금씩 추가해달라고 할때까지 기다려라
 - 계속되는 성공에 합류하기는 쉽고, 미래를 살짝이라도 보여주면 사람들은 도와주기 위해 모여들 것이다
 
 > 큰 그림을 기억하라
@@ -65,7 +69,7 @@ tags:
 너무 완벽한 소프트웨어를 만들려하지말고, 적당히 괜찮게 만드는 것이 중요하다. 하지만 이때 `적당히 괜찮은`은 기본적인 성능, 보안, 요구조건을 만족해야한다.
 
 **타협과정에 사용자를 참여시켜라**
-소프트웨어가 얼마나 좋아야하는지 사용자에게 물어라. 좋은 소프트웨어를 위해 요구조건을 무시하거나, 요구조건을 위해 기본적인 것을 빼는 것 모두 전문가 잡지 못하다.
+소프트웨어가 얼마나 좋아야하는지 사용자에게 물어라. 좋은 소프트웨어를 위해 요구조건을 무시하거나, 요구조건을 위해 기본적인 것을 빼는 것 모두 전문가답지 못하다.
 
 > 품질을 요구사항으로 만들어라.
 
diff --git "a/_posts/blog/posts/\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270/2024-07-14-\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270 2\354\236\245 \354\213\244\354\232\251\354\243\274\354\235\230 \354\240\221\352\267\274\353\262\225.md" "b/_posts/blog/posts/\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270/2024-07-14-\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270 2\354\236\245 \354\213\244\354\232\251\354\243\274\354\235\230 \354\240\221\352\267\274\353\262\225.md"
new file mode 100644
index 000000000..5c1b481c6
--- /dev/null
+++ "b/_posts/blog/posts/\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270/2024-07-14-\354\213\244\354\232\251\354\243\274\354\235\230\355\224\204\353\241\234\352\267\270\353\236\230\353\250\270 2\354\236\245 \354\213\244\354\232\251\354\243\274\354\235\230 \354\240\221\352\267\274\353\262\225.md"	
@@ -0,0 +1,333 @@
+---
+title: 2024-07-14-실용주의프로그래머 2장 실용주의 접근법
+author: 신성일
+date: 2024-07-15 21:15:49 +0900
+categories: study, 실용주의프로그래머
+tags:
+  - "#study"
+---
+
+## Topic 8 - 좋은 설계의 핵심
+
+> 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
+
+**ETC(Easy To Change)는 규칙이 아니라 가치**
+
+가치란 결정을 내릴때 도움을 주는 것이다. ETC는 가치로서 내제화되어야하며, 의식적으로 방금 한 일이 ETC 한지 항상 물어봐야한다.
+일반적으로 상식선에서 추측이 가능하다. 하지만 결정하기 어려울때가 있는데, 이럴땐 다음 두가지 방법이 있다.
+- 코드가 교체되기 쉬워야한다. (결합도를 낮추고 응집도를 높여라)
+- 직관적으로 선택하고, 그 이유에 대해 기록해둬라. 그리고 추후 변경이 실제로 발생했을때 다시보며 피드백하라.
+---
+
+## Topic 9 - DRY : 중복의 해악
+
+소프트웨어를 신뢰성 높게 개발하는 유일한 길, 유지보수를 쉽게 만드는 유일한 길은 DRY 원칙을 따르는 것이다.
+
+> DRY : 반복하지 말라
+
+DRY를 따르지 않으면 똑같은 것이 두 군데 이상 표현될 것이다. 그러면 하나를 바꾸면 나머지를 바꿔야하는데, 언제 잊어버릴지 모른다.
+
+**1) DRY는 코드 밖에서도**
+
+DRY는 똑같은 개념을 다른 곳에서 표현하면 안된다는 것이다. 코드의 어떤 부분을 바꿔야할때 문서도 바꿔야하는가? 그럼 DRY를 위반한 것이다.
+
+
+**2) 모든 코드 중복이 지식의 중복은 아니다**
+
+요구조건) 연령과 주문 수량은 모두 숫자이고, 0보다 커야한다
+```pseudo
+def validate_age(value):
+	validate_type(value, :integer)
+	validate_min_integer(value, 1)
+
+def validate_quantity(value):
+	validate_type(value, :integer)
+	validate_min_integer(value, 1)
+```
+
+이때 두 함수가 표현하는 지식은 다르다. 다만 우연히 규칙이 같은 것일 뿐이다. 이건 우연이지 중복이 아니다.
+
+**3) 문서화 중복**
+
+과도하게 많은 주석은 함수의 의도를 두번 설명하게 한다. 이는 추후 함수를 변경해야할때 주석도 변경해야한다. 따라서 함수명, 변수명 등으로 코드로서 의도를 표현하는 것이 제일 좋다.
+
+**4) 데이터의 DRY 위반**
+
+자료구조 내에서 중복된 의미의 데이터가 포함될 수 있다.
+- ex) line 이라는 클래스에 `start`, `end`, `length` 변수가 있는 경우 -> `length`를 계산하는 메서드를 만들어라
+
+하지만 계산로직이 복잡한 경우 캐싱을 위해 포함할 수도 있는데, 중요한 것은 자료구조 외부로 드러내지 않는 것이다. 
+- ex) line 클래스 생성 시 `start`, `end`만 받고, `length`는 자동으로 계산되게
+
+**5) 표현상의 중복**
+
+다른 라이브러리나 API와 연결할때 해당 API에 표현된 지식들(스키마, 에러코드 등)을 우리 코드도 알아야한다. 이러한 중복은 다음과 같이 완화될 수 있다.
+
+- 내부 API에서 생기는 중복
+	- 언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾아라 (ex : swagger 등)
+	- 모든 API 정의를 하나의 중앙 저장소에 넣어두고 여러 팀이 공유할 수 있으면 좋다.
+- 외부 API에서 생기는 중복
+	- 외부 API는 엄밀한 문서화가 되어있는 경우가 많다.
+- 데이터 저장소와의 중복
+	- 영속성 프레임워크 등을 통해 데이터 스키마로부터 객체를 바로 생성해낼 수 있도록 한다.
+	- 또는 JS 객체처럼 키-값 데이터 구조에 밀어넣는 것도 좋다. (이때는 간단한 데이터 검증 도구는 필요하다)
+
+**6) 개발자 간의 중복**
+
+같은 기능을 여러 개발자가 각자 개발할 수도 있다. 이러한 것을 발견하려면 소통과 코드리뷰가 중요하다.
+
+> 재사용하기 쉽게 만들어라
+
+기존의 것을 찾아내고, 재사용하기 쉬운 환경을 조성해야한다. 재사용이 어려우면 중복의 위험을 감수해야한다.
+
+---
+## Topic 10 - 직교성
+
+컴퓨터 과학에서 직교성은 결합도 줄이기를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다. 잘 설계가 되어있다면 데이터베이스 코드가 바뀌어도 사용자 인터페이스는 바뀌지 않을 것이다.
+
+
+**직교성의 장점**
+
+> 관련 없는 것들 간에 서로 영향이 없도록 하라
+
+컴포넌트들이 각기 격리되어있으면 어느 하나를 바꿀 때 나머지를 걱정하지 않아도 된다. 직교성은 다음 두가지 큰 장점이 있다.
+
+- 생산성 향상
+	- 변화를 국소화해서 개발 시간과 테스트 시간을 줄일 수 있다. 
+	- 직교성은 재사용하기도 쉽다
+	- 직교적인 컴포넌트들을 결합하면 생산성 향상을 얻을 수 있다. 하나의 컴포넌트로 다양한 일을 할 수 있기 때문이다.
+- 리스크 감소
+	- 직교성은 감염된 코드를 격리시켜준다.
+	- 변경이 발생해도 시스템이 잘 깨지지 않는다.
+	- 각각의 컴포넌트들을 테스트하기가 쉬워진다
+	- 특정 제품, 플랫폼에 덜 종속적이 된다.
+
+**설계**
+
+설계가 직교적인지 확인하는 쉬운 방법은 '특정 기능에 대한 요구사항이 대폭 변경되었을때 몇개의 모듈이 영향을 받는가?'를 자문하는 것이다.  정답은 하나여야한다.
+
+또한 현실 세계의 변화와 설계 사이의 결합도를 얼마나 줄였는지도 확인해야한다. 자신의 힘으로 제어할 수 없는 속성에 의존하면 안된다.
+- ex) 전화번호를 고객 식별자로 사용할 경우 -> 법이 변경되면 식별자를 모두 바꿔야한다.
+
+**툴킷과 라이브러리**
+
+같은 팀이 작성한 것이라도 라이브러리의 도입이 코드에 수용해서는 안될 변화를 가져오고, 직교성을 해친다면 도입하면 안된다.
+
+EJB의 데코레이터 패턴이 좋은 라이브러리 예시이다.
+
+**코딩**
+
+코딩을 할 때 직교성을 유지할 수 있는 몇가지 기법이 있다.
+
+- 코드의 결합도를 줄여라
+	- 불필요한 것은 다른 모듈에 보여주지말고, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라
+	- `데메테르 법칙`을 따르려 노력해보자
+	- 객체의 상태를 바꿔야하면, 객체가 직접 상태를 바꾸도록 해보자. (상태를 변경하는 메서드를 만들라는 뜻인듯...?)
+- 전역 데이터를 피하라
+	- 전역 데이터를 읽기 전용으로 사용한다해도 전역 데이터가 변경되면 사용하는 모든 모듈에 영향이 간다
+	- 필요한 컨텍스트를 모듈에 전달하는 식으로 해야 유지보수가 쉽다.
+	- 싱글턴 객체를 일종의 전역 데이터로 남용하여 불필요한 결합을 만들 수 있다.
+- 유사한 함수를 피하라
+	- 유사해보이는 함수를 여러개 구현해야할 수 있다. (ex : 시작과 끝은 같지만 중간이 다른 함수)
+	- 이러한 함수는 전략 패턴을 사용하여 더 낫게 구현할 수 없을지 확인하라
+
+기회가 있을 때마다 리팩터링하여 직교성을 개선하기 위해 노력하라.
+
+**테스트**
+
+직교적으로 설계된 시스템은 테스트하기가 더 쉽다. 통합 테스트보다 단위 테스트가 훨씬 쉽기 때문이다.
+
+단위테스트를 작성하는 행위 자체가 직교성을 테스트할 수 있는 기회이다. 단위 테스트를 작성할 때 많은 모듈을 불러와야하면 결합도가 높다는 뜻이다.
+
+버그 수정을 할 때에도, 하나의 모듈만 고치면 되는지 전체를 다 고쳐야하는지 점검해보아라.
+
+
+**더 알아보기**
+
+함수형 프로그래밍에서도 결합이 발생할 수 있는데, 한 함수의 결과를 다른 함수의 입력으로 사용하는 경우이다. 
+- 이때는 함수 결과를 일반적인 포맷으로 하면 완화할 수 있을거 같음
+- 타입스크립트 사용도 도움이 된다고 함
+
+---
+## Topic 11 - 가역성
+
+프로젝트에서 정답은 하나가 아니다. 중요한 결정이 추후 변경될 수 있고, 큰 비용을 치뤄야하는 경우가 발생한다.
+
+### **가역성**
+이 책에서 추천하는 방법들 (DRY 원칙, 결합도 줄이기 등)을 따른다면 중요하면서도 되돌릴 수 없는 결정의 수를 가능한한 줄일 수 있다.
+
+> 최종 결정이란 없다
+
+### 유연한 아키텍처
+코드 뿐만이 아니라 아키텍처, 배포, 외부 제품과의 통합 영역도 유연하게 유지하여야한다. 
+아키텍처는 항상 변화하며 할 수 있는 것은 바꾸기 쉽게 만드는 것 뿐이다. 외부의 API를 추상화 계층 뒤로 숨기고, 코드를 여러 컴포넌트로 쪼개라.
+
+> 유행을 좇지 마라.
+
+어떤 미래가 펼쳐질지는 알 수 없으며, 코드 스스로 유연하게 대처 가능하도록 해야한다.
+
+--- 
+## Topic 12 - 예광탄
+
+프로젝트를 진행할때 마치 예광탄처럼 즉각적인 피드백을 얻는 것은 매우 중요하다. 
+
+프로젝트를 진행할때 우리는 미지의 것을 마주한다. 애매모호한 요구사항, 처음보는 라이브러리, 기술 등. 이럴때 전형적인 반응은 시스템을 극도로 명세화하는 것이다. 환경을 제약하고, 요구사항을 일일히 항목으로 만들어서 명세서를 만든 후 맞기를 기도한다.
+
+하지만 실용주의 프로그래머는 소프트웨어 판 예광탄을 선호한다.
+
+### 어둠 속에서 빛을 내는 코드
+
+예광탄이 효과적인 이유는 **일반 탄환과 동일한 환경 및 제약 조건에서 발사**되기 때문이다. 코딩에서 동일한 효과를 얻으려면 우리를 요구사항으로부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게 반복적으로 도달하게 해줄 무언가를 찾아야한다.
+
+시스템을 정의하는 중요한 요구사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.
+
+> 목표물을 찾기 위해 예광탄을 써라.
+
+예시들
+- 프로젝트를 세팅할때 `hello world` 를 작성한 후 컴파일, 실행 해보는 것
+- 프로젝트 전체 아키텍처를 거치는 간단한 로직을 먼저 구현해보는 것
+
+예광탄 코드는 여러 장점이 있다.
+- 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
+	- 사용자는 자신의 시스템에 진전이 있음을 보게 되어 기쁠 것이고, 점점 직접 기여하기 시작할 것이다.
+	- 각 반복 주기마다 얼마나 목표에 가까워졌는지도 알려줄 것이다.
+- 개발자가 들어가서 일할 수 있는 구조를 얻는다
+	- 무에서 유를 만드는 것은 어렵다. 따라서 일단 애플리케이션의 모든 요소간 상호 작용을 만들면, 이후 추가하는 것은 쉽고 일관성도 촉진된다.
+- 통합 작업을 수행할 기반이 생긴다.
+	- 한번 시스템의 모든 요소를 연결하고 나면 새로 작성한 코드를 시스템에 붙이기가 쉬워진다. 
+- 보여줄 것이 생긴다.
+- 진행상황에 대해 더 정확하게 감을 잡을 수 있다.
+
+### 예광탄 코드 대 프로토타이핑
+
+프토로타입은 최종 시스템의 어떤 특정한 측면을 탐사해보는 것이 목표이다. 따라서 프로토타입 방식을 따른다면 실험 이후 모두 버려야한다. 그리고 프로토타입을 통해 얻은 교훈으로 코드를 새로 작성한다.
+
+프로토타입은 일종의 예시를 사용자에게 제시하고, 이후 최종 목표환경을 위한 코드로 다시 작성한다.
+
+예광탄 코드는 애플리케이션이 전체적으로 어떻게 연결되는지 알려주고, 사용자에게는 애플리케이션의 요소들이 어떻게 상호작용하는지 보여주고 개발자에게는 아키텍쳐의 골격을 제시한다.
+
+정리하면 프로토타입은 나중에 버리는 코드를 만들고, 예광탄 코드는 기능은 별로 없지만 완결된 코드이며 최종 시스템 골격 중 일부가 된다. 프로토타입은 예광탄을 발사하기 전에 먼저 수행하는 정찰 같은 것이다.
+
+---
+## Topic 13 - 프로토타입과 포스트잇
+
+프로토타입은 반드시 코드로 만들 필요는 없다. 그림이나 인터페이스 빌더 등을 통해 만들어 볼 수 있다. 
+
+프로토타입은 제한된 몇가지 질문에 답하기 위한 것이기에 세부 사항을 무시하고 실제 제품보다 매우 적은 비용으로 만들 수 있다. 만약 세부 사항을 포기하지 못하는 상황이라면 프로토타입을 만들고 있는 것이 맞는지 자문하라. 이럴때는 예광탄 코드가 적합할 수 있다.
+
+### 프로토타입 대상
+
+프로토타입으로 조사할 대상은 **위험을 수반하는 모든 것**이다. 이전에 해본 적 없는 것, 최종 시스템에 매우 중요한 것, 의심이 가는 것 등이 모두 대상이다. 
+
+- 아키텍처
+- 기존 시스템에 추가할 새로운 기능
+- 외부 데이터의 구조 혹은 내용
+- 외부에서 가져온 도구나 컴포넌트
+- 성능 문제
+- 사용자 인터페이스 설계
+
+프로토타입의 가치는 프로토타입 자체가 아니라 이를 통해 배우는 교훈에 있다.
+
+> 프로토타이핑으로 학습하라
+
+
+### 프로토타입을 어떻게 사용할 것인가?
+
+프로토타입을 만들 때 무시해도 좋은 세부사항은 무엇일까?
+
+- 정확성 : 적절히 가짜 데이터 사용 가능
+- 완전성 : 제한된 방식으로만 동작해도 됨
+- 안정성 : 오류 검사를 무시해도 됨
+- 스타일 : 주석이나 문서가 많지 않아야함
+
+
+---
+
+## Topic 14 - 도메인 언어
+
+프로그래밍 언어로 사고방식이 제한될 수 있다. 따라서 도메인의 어휘를 사용하여 프로그래밍 하는 방식으로 좀 더 그 도메인에 가깝게 설계할 수 있다
+
+> 문제 도메인에 가깝게 프로그래밍하라.
+
+예시 : 
+- 내부 도메인 언어 : RSpec, 피닉스라우터
+	- 컴파일하고 실행할 수 있는 코드로, 실제 코드 안에 들어감
+	- 호스트언어의 기능을 쓸 수 있다는 장점이 있지만, 호스트 언어의 문법과 의미론을 따라야한다
+- 외부 도메인 언어 : 큐컴버, 앤서블
+	- 다른 언어나 데이터 구조로 변환하여 실행함
+	- 호스트 언어에따른 제약은 없지만, 파서를 만들기에 리소스가 소비된다.
+
+하지만 우리가 도메인 언어로 코드를 짠다해도 기획자는 읽지 않는다. 스스로 무엇을 원하는지 정확히 모르기 때문이다. 이때는 실제로 동작하는 것을 보여주면 스스로 원하는 것을 말할 것이다.
+
+도메인언어를 사용하며 절약되는 시간보다 더 많은 시간을 쏟지마라. 기본적으로는 통용되는 yaml, json, csv 같은 외부 언어를 사용하라. 다만 외부언어 도입은 사용자가 직접 도메인 언어로 코드를 작성하는 경우에만 추천한다.
+
+---
+## Topic 15 - 추정
+
+### 얼마나 정확해야 충분히 정확한가?
+
+모든 답은 추정치이다. 따라서 질문자의 원하는 것이 정확한 답을 요구하는지 큰 그림을 요구하는지 먼저 파악해야한다.
+
+사용하는 단위에 따라서 답의 정확도 해석이 달라질 수 있다. 예를들어 130일이 걸린다고 하면 정확히 130일이라는 느낌이 들지만, 대략 6달이라고하면 5~6개월로 해석된다. 아래 단위를 추천한다. (ex : 125일이 걸릴 거 같으면 대략 6달이라고 말하자)
+
+- 1 ~ 15일 -> 일
+- 3~6주 -> 주
+- 8 ~ 20주 -> 달
+- 20주 이상 -> 추정치를 말하기 전에 다시 한번 생각해보자
+
+
+### 추정치는 어디에서 나오는가?
+
+모든 추정치는 문제의 모델에 기반한다. 그런데 모델을 작성하기 전에 그 일을 해본 사람에게 물어봐라. 다른 사람의 경험을 바탕으로 성공적인 추정치를 낼 수 있다.
+
+**무엇을 묻고있는지 이해하라**
+
+어떤 추정을 하건 상대방이 무엇을 묻고 있는지 먼저 이해해야한다. 도메인에 존재하는 조건에 대해서도 알아야한다. 상대방이 말해줄 때도 있지만 말하지 않더라도 미리 조건을 생각해보는 습관이 있어야한다.
+
+**시스템의 모델을 만들어라**
+
+의뢰인의 요청을 이해한 후에는 간단하게 모델을 만들어보라. 모델을 만듦으로써 표현에 드러나지 않은 패턴이나 프로세스를 발견할 수 있고, 초기 질문과는 다른 제안을 할 수도 있다. 
+
+모델이 정교해질수록 추정은 정확해지지만, 정확히 비례하진 않는다. 따라서 적절한 수준을 골라야한다.
+
+**모델을 컴포넌트로 나눠라**
+
+다 만든 모델을 컴포넌트로 분해하여 서로 어떻게 상호작용하는지 수식으로 기술해야한다. 각 노드 별로 전체 시스템에 얼마나 기여하는지 매개변수를 찾을 수 있을 것이다.
+
+**각 매개 변수에 값을 할당하라**
+
+가장 큰 영향을 미치는 매개변수를 찾아서 이 매개변수의 값을 최대한 정확하게 산출해내라. 
+ex) 대기열시스템에서는 실제 시간당 요청수를 측정하거나, 비슷한 시스템을 찾아봐라
+
+**답을 계산하라**
+
+주요 매개변수들의 값을 변경시켜가며 여러 번 계산해보고 어느 것이 가장 잘 들어맞는지 찾아내라. 이때 너무 정확한 값이 나오면 아마 잘못계산한 것이다.
+
+**여러분의 추정 실력을 기록하라**
+
+계산한 추정치를 기록하고 나중에 얼마나 잘 들어맞는지 평가해봐라. 
+
+### 프로젝트 일정 추정하기
+
+**PERT 기법**
+
+> 아무 문제 없다면 10시간, 현실적으로는 18시간, 날씨가 나쁘면 30시간 정도 걸릴거 같습니다.
+
+낙관적 추정치와 가장 가능성 높은 추정치, 비관적 추정치를 갖는다. 과업은 의존성에 따라 네트워크 형태로 배열한 후, 간단한 통계 기법으로 전체 프로젝트의 예상 최소 및 최대 소요 시간을 계산한다.
+
+단순히 값을 부풀리는 것보다, 범위로 추정하는 것이 오류를 피할 수 있는 좋은 방법이다. PERT 속의 통계가 범위로 표현한 불확실성을 분산시켜주고, 전체 프로젝트에 대하여 더 나은 추정치를 얻을 수 있다.
+
+**코끼리 먹기**
+
+기능을 매우 작은 단위로 나누어 다음과 같은 방식으로 개발하면 추정치는 점점 더 정확해질 것이다.
+
+- 요구사항 확인하기
+- 위험 분석 후 위험도가 높은 부분을 우선 하기
+- 설계, 구현, 통합
+- 사용자와 함께 검증하기
+
+한 iteration이 끝났을때 리뷰를 거쳐 총 몇번의 iteration이 필요할 지, 각 iteration 마다 뭘할지 추측할 수 있을 것이다. 
+
+이 방법은 경영진에게 인기는 없지만 더 정확한 일정을 전달할 수 있다.
+
+
diff --git a/_posts/blog/template/{{date}}-template.md b/_posts/blog/template/{{date}}-template.md
index 059352142..74ce0ac74 100644
--- a/_posts/blog/template/{{date}}-template.md
+++ b/_posts/blog/template/{{date}}-template.md
@@ -2,6 +2,7 @@
 title: "{{title}}"
 author: 신성일
 date: "{{date}} {{time}} +0900"
-categories: 
+categories: study
 tags:
+  - "#study"
 ---
diff --git a/_posts/blog/tracked_files.json b/_posts/blog/tracked_files.json
new file mode 100644
index 000000000..c943051c6
--- /dev/null
+++ b/_posts/blog/tracked_files.json
@@ -0,0 +1 @@
+{"queue":[0],"repeatQueue":[],"items":[{"nextReview":1720959776742,"fileIndex":0,"timesReviewed":0,"timesCorrect":0,"errorStreak":0,"data":{"ease":2.5,"lastInterval":0,"iteration":1}}],"trackedFiles":[{"path":"posts/실용주의프로그래머/2024-07-14-실용주의프로그래머 1장 실용주의 철학.md","items":{"file":0}}],"lastQueue":1720959776742,"newAdded":1}
\ No newline at end of file