diff --git a/readme.kr.md b/readme.kr.md
index f2f9084..ad1c940 100644
--- a/readme.kr.md
+++ b/readme.kr.md
@@ -273,7 +273,7 @@ it("관리자 요청이 들어오면 정렬된 관리자 목록만 결과에 포
 class ProductService{
     // 이 method 는 내부에서만 사용됩니다.
     // 이 이름을 변경하면 테스트가 실패합니다.
-    calculateVAT(priceWithoutVAT){
+    calculateVATAdd(priceWithoutVAT){
         return {finalPrice: priceWithoutVAT * 1.2};
         // 결과 형식이나 키 이름을 변경하면 테스트가 실패합니다.
     }
@@ -407,6 +407,7 @@ it("더 나은 것: 유효한 제품이 추가된다면, 성공을 얻는다.",
 
 :white_check_mark: **이렇게 해라:** 우리는 일반적으로 적은 수의 인풋 샘플 데이터를 가지고 테스트를 합니다. 심지어 인풋 데이터 형식이 실제 데이터와 비슷할 때에도 다음과 같이 제한된 인풋 조합으로만 테스트를 커버합니다.(method(‘’, true, 1), method(“string” , false” , 0)) 하지만, 운영시에는 5개의 파라미터를 가지는 API는 수 천 개의 다른 조합의 파라미터로 호출 될 수 있고, 이 중 하나가 우리의 시스템을 다운시킬 수도 있습니다. 그렇다면 만약 1000 가지 조합의 인풋값을 자동으로 생성하고 올바른 응답을 반환하지 못하는 인풋값을 찾아내는 단위 테스트를 작성할 수 있다면 어떨까요?
 프로퍼티 기반 테스트는 단위 테스트에 모든 가능한 인풋 조합을 사용하여 생각하지 못 한 버그를 찾을 확률을 높여줍니다. 예를들어, 다음의 메소드가 주어졌을 때 — addNewProduct(id, name, isDiscount) — 프로퍼티 기반 테스트 라이브러리들은  다양한 파라미터 (number, string, boolean) 조합으로  - (1, “iPhone”, false), (2, “Galaxy”, true) - 이 메소드를 호출합니다. [js-verify](https://github.com/jsverify/jsverify) 나 [testcheck](https://github.com/leebyron/testcheck-js) (much better documentation) 같은 라이브러리를 지원하는 테스트 러너들 (Mocha, Jest, etc) 중 당신이 가장 선호하는 방법을 통해 프로퍼티 기반 테스트를 할 수 있습니다. 
+
 업데이트 : Nicolas Dubien가 코멘트를 통해 더 많은 부가적인 기능들을 제공하고 활발하게 유지보수되고 있는 라이브러리 [fast-check](https://github.com/dubzzz/fast-check#readme)를 추천해 주었습니다. 
 
 <br/>