diff --git a/README.md b/README.md
index 88e22f5af6127119411791781cadc7957ca11afc..6818213873afd844b6a1b1541acc16e639926d19 100644
--- a/README.md
+++ b/README.md
@@ -542,7 +542,7 @@ When your code is getting both better and simpler, that is when you know it's ri
 
 It was time for the name change. The new design looked much more like a dual of sendmail than the old popclient had; both are MTAs, but where sendmail pushes then delivers, the new popclient pulls then delivers. So, two months off the blocks, I renamed it fetchmail.
 
-이름을 바꿀 때가 된 것이다. 새로운 설계는 예전의 popclient 보다는 sendmail 과 비슷해 보였다. 둘다 MTA였으나 sendmail은 푸시(push) 후에 메일을 배달했고 새로운 popclient 는 풀(pull) 후에 메일을 배달했다. 해서 두 달 후에 나는 popclient 의 이름을 fetchmail로 바꾸었다.
+이름을 바꿀 때가 된 것이다. 새로운 설계는 예전의 popclient 보다는 sendmail 과 비슷해 보였다. 둘다 MTA였으나 sendmail은 push 후에 메일을 배달했고 새로운 popclient 는 pull 후에 메일을 배달했다. 해서 두 달 후에 나는 popclient 의 이름을 fetchmail로 바꾸었다.
 
 There is a more general lesson in this story about how SMTP delivery came to fetchmail. It is not only debugging that is parallelizable; development and (to a perhaps surprising extent) exploration of design space is, too. When your development mode is rapidly iterative, development and enhancement may become special cases of debugging—fixing `bugs of omission' in the original capabilities or concept of the software.