7조 Merge Request

README.md

@@ -462,90 +462,96 @@ Actually, when I revised in late May 1997 I found the list was beginning to lose
 
 ## Popclient가 Fetchmail이 되다.
 
+(김민건)
 The real turning point in the project was when Harry Hochheiser sent me his scratch code for forwarding mail to the client machine's SMTP port. I realized almost immediately that a reliable implementation of this feature would make all the other mail delivery modes next to obsolete.
 
-fetchmail 프로젝트에서 큰 전환이 일어났던 것은 해리 호흐하이저(Harry Hochheiser) 가 클라이언트 머신의 SMTP 포트로 메일을 포워딩하는 대략적인 코드를 보내준 때였다. 보자마자 이 기능을 안정적으로 구현한다면 다른 모든 배달 방법은 구식이 되리라는 것을 깨달았다.
-(김민건)
+fetchmail 프로젝트에서의 전환점은 해리 호츠하이저가 클라이언트 머신의 SMTP 포트로 메일을 보내기 위해 스크래치 코드를 내게 보냈을 때였다. 나는 이 코드를 보자마자, 이 기능을 안정적이게 구현한다면 그 외 모든 전송 방식들은 쓸모없게 된다는 것을 깨달았다.
 
 For many weeks I had been tweaking fetchmail rather incrementally while feeling like the interface design was serviceable but grubby—inelegant and with too many exiguous options hanging out all over. The options to dump fetched mail to a mailbox file or standard output particularly bothered me, but I couldn't figure out why. (If you don't care about the technicalia of Internet mail, the next two paragraphs can be safely skipped.)
 
-여러 주 동안 나는 fetchmail을 조금씩 뜯어고치고 있었는데, 인터페이스 설계가 작동하긴 하지만 지저분하다고 느끼고 있었다. 우아하지도 않고 몇 안되는 옵션들이 너무 여기저기 흩어져 있었다. 가져온 메일을 메일박스 파일에 부어놓을 것인지, 표준출력으로 내보낼 것인지 결정하는 옵션이 특히 골치거리였지만 왜 그런지 확실히 깨닫지는 못했다.
+몇 주동안 나는 fetchmail을 조금씩 뜯어고치고 있었는데, 인터페이스 디자인이 쓸만하지만 지저분하고, 너무 많은 쓸데없는 옵션들이 사방에 널려있는 것처럼 느꼈다. 그 중에서도 가져온 메일을 우편함 파일에 담을 지, 표준 출력으로 내보낼 것인지 선택하는 옵션이 특히 골치거리였지만, 왜 그런지 알 수가 없었다. (만약 인터넷 메일의 기술력에 대해 관심이 없다면, 다음 두 단락을 건너뛰세요.)
+
+
 
 What I saw when I thought about SMTP forwarding was that popclient had been trying to do too many things. It had been designed to be both a mail transport agent (MTA) and a local delivery agent (MDA). With SMTP forwarding, it could get out of the MDA business and be a pure MTA, handing off mail to other programs for local delivery just as sendmail does.
 
-SMTP 포워딩을 생각하자 그동안 popclient 가 너무 많은 것을 해내려고 했다는 것을 알게 되었다. poopclient 는 MTA (Mail Transport Agent) 와 MDA (Mail Delivery Agent)의 기능을 모두 가지도록 설계되었다. SMTP 포워딩만 할 수 있다면 MDA 기능을 없애 순수한 MTA 가 될 수 있었다. sendmail 과 마찬가지로 최종적인 메일 배달은 다른 프로그램에게 맡기면 되는 것이다.
+내가 SMTP 전송에 대해 생각할 때 깨달은 것은 여태까지 popclient가 너무 많은 것을 해내려 했다는 것이었다. popclient는 MTA (Mail Transport Agent)와 MDA (Mail Delivery Agent)의 역할을 모두 할 수 있도록 설계되었다. 하지만 SMTP 전송을 사용한다면 MDA 사업에서 벗어나 순수한 MTA가 될 수 있었고, sendmail이 그렇듯 최종적인 메일 전송은 다른 프로그램들에게 맡기면 되는 것이다.
 
 Why mess with all the complexity of configuring a mail delivery agent or setting up lock-and-append on a mailbox when port 25 is almost guaranteed to be there on any platform with TCP/IP support in the first place? Especially when this means retrieved mail is guaranteed to look like normal sender-initiated SMTP mail, which is really what we want anyway. (Back to a higher level....)
 
-TCP/IP를 지원하는 플랫폼이라면 거의 어디에나 25번 포트가 기다리고 있는데 무엇 때문에 복잡한 MDA 기능을 설정하거나 메일박스를 잠그고 덧붙이는 (lock-and-append) 문제를 가지고 고생을 하는가? 더구나 포워딩을 사용하면 가져온 메일이 평범한 SMTP 메일처럼 보일 것이고, 우리가 원하는 것이 바로 그것이었는데 말이다.
+TCP/IP를 지원하는 플랫폼이라면 25번 포트가 있을텐데, 왜 MDA를 설정하는 복잡한 일이나 메일박스를 잠그고 덧붙히는 기능(lock-and-append)을 만드는 데 시간을 허비해야 하는가? 더군다나 이는 회수된 메일이 일반적인 SMTP 메일처럼 보이게 할 것이고, 그게 바로 우리가 원하던 것인데 말이다.
 
-(201620633 박영도) Even if you didn't follow the preceding technical jargon, there are several important lessons here. First, this SMTP-forwarding concept was the biggest single payoff I got from consciously trying to emulate Linus's methods. A user gave me this terrific idea—all I had to do was understand the implications.
+(박영도) Even if you didn't follow the preceding technical jargon, there are several important lessons here. First, this SMTP-forwarding concept was the biggest single payoff I got from consciously trying to emulate Linus's methods. A user gave me this terrific idea—all I had to do was understand the implications.
 
-몇가지 배울 점이 있었다. 먼저, SMTP 포워딩에 대한 아이디어는 내가 리누스의 방법을 모방하려고 의식적으로 노력한 것에 대한 가장 큰 보답이었다. 사용자 한 명이 내게 끝내주는 아이디어를 주었으며 내가 해야했던 일은 그 의미를 이해하는 것 뿐이었다.
+당신이 선행되는 기술적 용어들을 이해하지 못했더라도, 몇가지 중요한 교훈들이 있었다. 먼저 SMTP 전송 개념은 내가 Linus의 방법들을 모방하고자 노력한 것에 대한 가장 큰 성과였다. 한 사용자가 나에게 굉장한 아이디어를 줬고, 내가 해야했던 일은 그 의미를 이해하는 것 뿐이었다.
 
 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
 
-11. 좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다. (The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better)
+11. 좋은 아이디어들을 가지는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어들을 깨닫는 것이다. 때로는 후자가 더 나을 수 있다.
 
 Interestingly enough, you will quickly find that if you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you as though you did every bit of the invention yourself and are just being becomingly modest about your innate genius. We can all see how well this worked for Linus!
 
-흥미롭게도 만일 당신이 얼마나 다른사람에게 빚을 많이 지고 있는지를 자기 비하라고 느껴질 정도로까지 솔직하게 털어놓는다면 대개의 사람들은 당신이 혼자서 거의 모든 일을 해내고서 천재성에 대해서 겸손해 하는 것처럼 대한다는 것을 곧바로 알게 될 것이다. 리누스의 경우를 보라! 
+흥미롭게도, 만약 당신이 자신을 낮추어 다른 사람들로부터 많은 도움을 받았는지에 대해 솔직하게 말한다면, 대부분의 사람들은 당신이 혼자 모든 일들을 이루고서 천재성에 대해 겸손한 것처럼 대한다는 것을 알게 될 것이다. 이 경우는 Linus를 보면 잘 알 수 있다.
 
-(When I gave my talk at the first Perl Conference in August 1997, hacker extraordinaire Larry Wall was in the front row. As I got to the last line above he called out, religious-revival style, ``Tell it, tell it, brother!''. The whole audience laughed, because they knew this had worked for the inventor of Perl, too.)
+(When I gave my talk at the first Perl Conference in August 1997, hacker extraordinaire Larry Wall was in the front row. As I got to the last line above he called out, religious-revival style, **Tell it, tell it, brother!**. The whole audience laughed, because they knew this had worked for the inventor of Perl, too.)
 
-(1997년 8월, Perl 컨퍼런스에서 이 글을 발표할 때 래리 월이 첫 번째 줄에 앉아 있었다. 바로 윗 줄에 도달했을 때 그는 부흥사라도 된 것처럼 외쳤다. ``형제여, 이야기 하시오, 이야기를!'' 청중들 모두가 이것이 Perl을 만든 래리에게도 적용된다는 것을 알았기 때문에 웃음을 터뜨렸다.)
+(1997년 8월 Perl 컨퍼런스에서 이 글을 발표할 때 뛰어난 해커인 Larry Wall이 첫 번째 줄에 앉아 있었다. 마지막 줄에 도달했을 때 그는 종교를 부흥하듯이 외쳤다. **말하시오, 말하시오, 형제여!**,청중들 모두 이 말이 Perl을 만든 Larry 적용된다는 것을 알았기 때문에 웃음을 터뜨렸다.)
 
 After a very few weeks of running the project in the same spirit, I began to get similar praise not just from my users but from other people to whom the word leaked out. I stashed away some of that email; I'll look at it again sometime if I ever start wondering whether my life has been worthwhile :-).
 
-똑같은 정신으로 프로젝트를 몇 주 진행해 나가자 나는 사용자들 뿐 아니라 이야기를 전해들은 다른 사람들로부터 비슷한 칭송을 받기 시작했다. 나는 그런 email 중 몇몇을 따로 보관해 두었다. 나중에 내 삶이 가치있는 것이었는지 의심스러워질 때 그 메일들을 다시 꺼내볼 생각이다. :-)
+프로젝트를 같은 설계 방식으로 몇 주 진행한 뒤, 나는 사용자들 뿐만 아니라 이야기를 전해 들은 다른 사람들로부터 비슷한 칭찬들 받기 시작했다. 나는 그런 email들 중 몇개는 따로 보관해 두었다. 나중에 내가 삶을 가치있게 보냈는지 궁금해질 때 그 메일들을 다시 꺼내볼 것이다. :-)
 
 But there are two more fundamental, non-political lessons here that are general to all kinds of design.
 
-모든 종류의 설계에 대해서 적용될 수 있는 두가지 더 기본적이며 비정치적인 교훈이 있다.
+하지만 모든 종류의 설계에 대해 더 기본적이고 비정치적으로 적용될 수 있는 교훈들이 있다.
 
 12. (양수훈)Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
 
-12. 종종 가장 충격적이고 혁신적인 해결책은 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못되어 있다는 것을 깨닫는 것에서 나온다. (Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong)
+(양수훈) 당신이 알고 있던 개념이 잘못 되었다는 것을 깨달음으로써 가장 충격적이면서 혁신적인 해결책이 종종 나오기도 한다.
 
 I had been trying to solve the wrong problem by continuing to develop popclient as a combined MTA/MDA with all kinds of funky local delivery modes. Fetchmail's design needed to be rethought from the ground up as a pure MTA, a part of the normal SMTP-speaking Internet mail path.
 
-나는 popclient를 MTA/MDA 기능을 다 갖추고 복잡한 지역배달모드들까지(local delivery modes) 갖춘 것으로 개발해 나가면서 틀린 문제를 풀려고 노력하고 있었다. fetchmail의 설계는 가장 기초적인 것부터 재고하여 SMTP 포트로 메일을 배달하는 인터넷 메일 경로의 한 부분인 순수 MTA 가 되어야 했다.
+(양수훈) 
+ 나는 popclient를 MTA/MDA가 결합된 여러 파격적인 로컬 전달 모드(local delivery modes)를 조합하여 계속 개발하고 잘못된 문제를 해결하려 하고 있었다. Fetchmail의 설계는 처음부터 SMTP를 이야기하는 통상적인 인터넷 메일 경로의 일부인 순수한 MTA로서 재고할 필요가 있었다.
 
 When you hit a wall in development—when you find yourself hard put to think past the next patch—it's often time to ask not whether you've got the right answer, but whether you're asking the right question. Perhaps the problem needs to be reframed.
 
-개발 도중에 벽에 부딪친다면 - 다음번 패치 후에 무엇을 해야 할 지 모르겠다면 - 그때는 정답을 가지고 있는지 생각할 것이 아니라 질문이 올바른 것인지 의문을 가져보아야 하는 경우가 종종 있다. 아마도 문제의 틀을 다시 잡아야 할 것이다.
+(양수훈)
+ 개발의 벽에 부딪혔을 때, 즉 다음 패치에 대해 생각하는 것이 곤란해졌을 때, 대부분의 경우 올바른 답을 얻을 수 있었는지 여부가 아니라 올바른 질문을 하고 있는지 여부를 물을 때이다. 아마도, 문제를 재구성해야 할 필요가 있다.
 
 Well, I had reframed my problem. Clearly, the right thing to do was (1) hack SMTP forwarding support into the generic driver, (2) make it the default mode, and (3) eventually throw out all the other delivery modes, especially the deliver-to-file and deliver-to-standard-output options.
 
-그래서, 나도 내 문제의 틀을 다시 잡았다. 분명히 제대로 일을 진행하려면 (1) SMTP 포워딩 지원 기능을 일반 드라이버에 포함시키고, (2) SMTP 포워딩을 기본모드로 만들고 (3) 최종적으로는 다른 배달모드들, 특히 `파일로 배달하기' 와 `표준출력으로 배달하기'를 제거해야 했다.'
+(양수훈)
+ 나는 내 문제를 재구성했다. 분명히 잘 한 부분은 (1) SMTP 전송 서포트를 범용 드라이버에 해킹하고, (2) 디폴트 모드로 하고, (3) 최종적으로는 다른 전달 모드, 특히 '파일로 전달하기' 옵션과 '표준출력으로 전달하기' 옵션을 모두 폐기하는 것이었다.
 
 I hesitated over step 3 for some time, fearing to upset long-time popclient users dependent on the alternate delivery mechanisms. In theory, they could immediately switch to .forward files or their non-sendmail equivalents to get the same effects. In practice the transition might have been messy.
 
-나는 단계 (3)에서 조금 머뭇거렸는데, 이유는 오랫동안 popclient 를 써오면서 다른 배달모드에 의존하고 있을 사용자들의 심기를 불편하게 만들고 싶지 않았기 때문이다. 이론적으로는 그들 모두 즉시 .forward 파일이나 sendmail 외의 비슷한 프로그램으로 전환하여 동일한 결과를 얻을 수 있었다. 실제로는 전환 자체가 큰 일이 될 것이었다.
+(양수훈)
+ 나는 한동안 대체 전달 메카니즘에 의존하는 장시간의 popclient 유저를 화나게 하는 것을 두려워하여 스텝(3)을 망설이고 있었다. 이론적으로 봤을 때는, 그들은 동일한 효과를 얻기 위해 바로 .forward 파일이나 sendmail이 아닌 비슷한 프로그램으로 전환할 수 있었다. 그렇지만 실제로 전환은 혼란스러웠을지도 모른다.
 
 (이성모) But when I did it, the benefits proved huge. The cruftiest parts of the driver code vanished. Configuration got radically simpler—no more grovelling around for the system MDA and user's mailbox, no more worries about whether the underlying OS supports file locking.
 
-하지만 단계 (3)을 실행하고 나자 이점이 매우 큰 것으로 나타났다. 드라이버 코드 중 가장 힘든 부분이 사라졌다. 설정이 엄청나게 간단해졌다 - 시스템의 MDA 와 사용자의 메일박스를 일일이 찾아다니며 굽실거릴 필요도 없어졌고, OS 가 파일 잠금을 지원하는지 걱정할 필요도 없어졌다.
+그러나 내가 3단계를 실행해봤을 때 그 이점은 엄청났다. 드라이버 코드의 가장 힘든 부분이 사라졌으며 설정이 엄청나게 간단해졌다. 시스템 MDA와 사용자의 메일박스를 더 이상 찾아 헤매지 않고, OS가 파일 잠금을 지원하는지에 대해 걱정할 필요가 없어진 것이다.
 
 Also, the only way to lose mail vanished. If you specified delivery to a file and the disk got full, your mail got lost. This can't happen with SMTP forwarding because your SMTP listener won't return OK unless the message can be delivered or at least spooled for later delivery.
 
-게다가 메일을 잃어버릴 한가지 가능성도 사라졌다. `파일로 배달하기'를 선택했을 때 디스크가 꽉 차 있으면 메일이 사라져 버렸던 것이다. SMTP 포워딩에서는 SMTP 리스너가 메시지 배달이 가능하거나 나중에 배달할 수 있도록 스풀해 놓기 전에는 OK를 돌려주지 않을 것이기 때문에 이런 일이 일어날 수가 없다.
+게다가 메일을 잃어버릴 유일한 가능성도 사라졌다. 만약 당신이 파일로 배달하기를 선택했을 때 디스크가 가득 차 있다면 당신의 메일은 사라져버린다. 그러나 SMTP 전송에서는, SMTP 리스너가 메시지를 배달하거나 최소한 나중에 배달될 수 있도록 스풀링하지 않는 한 SMTP 수신기가 OK를 반환하지 않기에 이런 문제가 발생하지 않는다.
 
 Also, performance improved (though not so you'd notice it in a single run). Another not insignificant benefit of this change was that the manual page got a lot simpler.
 
-성능도 향상되었다(한두번 실행시켜서는 느끼지 못하겠지만). 또 변경에 따르는 그다지 중요하지 않은 이익이라면 매뉴얼 페이지가 훨씬 간단해 졌다는 것이다. 
+단번에 알아차리지는 못했지만 성능도 향상 되었는데, 이 변화에 의한 큰 이점은 아니지만 메뉴얼 페이지가 훨씬 간단해진 것이다.
 
 Later, I had to bring delivery via a user-specified local MDA back in order to allow handling of some obscure situations involving dynamic SLIP. But I found a much simpler way to do it.
 
-나중에 나는 사용자가 지정한 지역 MDA를 통해 배달하는 기능을 다시 넣어야 했다. 동적인 SLIP를 포함하여 몇몇 애매한 상황을 다루어야 했기 때문이다. 하지만 처음보다 훨씬 간단한 방법을 찾아낼 수 있었다.
+나중에 나는 사용자 지정 로컬 MDA 를 통해 배달하는 기능을 다시 넣어야 했다. 동적 SLIP 와 관련된 일부 애매한 상황을 처리할 수 있도록 해야했기 때문이다. 그러나 처음보다는 훨씬 간단한 방법을 찾을 수 있었다.
 
 The moral? Don't hesitate to throw away superannuated features when you can do it without loss of effectiveness. Antoine de Saint-Exupéry (who was an aviator and aircraft designer when he wasn't authoring classic children's books) said:
 
-교훈이라면? 낡아서 사용할 수 없는 기능이라면 효율을 떨어뜨리지 않고 제거할 수 있을 때는 망설이지 말고 제거해 버리라. 앙뜨완 드 생떽쥐뻬리는 (아동서적 작가였으며 남는 시간에는 비행기 조종과 설계를 했던) 이렇게 말했다.
+교훈은? 바로 낡아서 쓸모없는 기능을 효율의 저하 없이 제거할 수 있을 때 망설이지 말라는 것이다. 고전 아동 서적 작가이자 남는 시간에 비행기 조종과 설계를 겸한 Antoine de Saint-Exupéry 는 이렇게 말했다.
 
-13. (정우택) ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.'' 
+13. (정우택) **Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.** 
 
-13. ``(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. (Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away)''
+13. (설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. 
 
 When your code is getting both better and simpler, that is when you know it's right. And in the process, the fetchmail design acquired an identity of its own, different from the ancestral popclient.
 
@@ -553,12 +559,16 @@ 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.
 
+ SMTP 전송이 어떻게 fetchmail로 됐는지에 대해 더 일반적인 교훈이 있다. 병렬화할 수 있는 것은 디버깅 뿐만이 아니라, 개발이나(아마 놀라울 정도로) 디자인 공간의 탐색도 가능하다. 개발 모드가 빠르게 반복될 경우, 개발과 확장은 디버깅의 특별한 경우가 될 수 있다. 즉, 소프트웨어 본래의 기능이나 개념에서의 '생략 버그'를 수정하는 것이다.
+
 Even at a higher level of design, it can be very valuable to have lots of co-developers random-walking through the design space near your product. Consider the way a puddle of water finds a drain, or better yet how ants find food: exploration essentially by diffusion, followed by exploitation mediated by a scalable communication mechanism. This works very well; as with Harry Hochheiser and me, one of your outriders may well find a huge win nearby that you were just a little too close-focused to see.
 
+더 높은 수준의 디자인이더라도 많은 공동 개발자들이 본인의 제품에 대해 여러 관점으로 신경을 쓰는 것이 매우 중요하다. 웅덩이가 배수구를 찾아내는 방법이나 개미들이 어떻게 더나은 먹이 찾기 방법을 찾아내는지 생각해 보라. 기본적으로 확산을 통한 탐사와 확장성있는 의사소통의 영항을 받은 개발에 의한 탐사인데, 이는 매우 효과적이다. 나와 Harry Hochheiser과 마찬가지로, 당신의 앞장서는 태도는 기존에 보기에는 너무나도 가까웠던 그 근처에서 커다란 성공을 이뤄낼 수 있을 것이다.
+
 ## Fetchmail Grows Up
 
 ## Fetchmail 의 성장