Skip to content
Snippets Groups Projects

Master

Open Jiwon Kim requested to merge Jiwoney/the-cathedral-and-the-bazaar:master into master
1 file
+ 36
31
Compare changes
  • Side-by-side
  • Inline
+ 36
31
@@ -103,116 +103,121 @@ This is the story of that project. I'll use it to propose some aphorisms about e
(강윤지)Since 1993 I'd been running the technical side of a small free-access Internet service provider called Chester County InterLink (CCIL) in West Chester, Pennsylvania. I co-founded CCIL and wrote our unique multiuser bulletin-board software—you can check it out by telnetting to locke.ccil.org. Today it supports almost three thousand users on thirty lines. The job allowed me 24-hour-a-day access to the net through CCIL's 56K line—in fact, the job practically demanded it!
1993년 나는 펜실베니아 주, 서 체스터(West Chester) 시의 자그마한 무료 ISP인 체스터 카운티 인터링크 (Chester County InterLink : CCIL) 에서 기술적인 측면을 담당하고 있었다. (나는 CCIL 의 공동설립자였으며 우리만의 멀티유저 게시판 소프트웨어를 작성했다 - locke.ccil.org에 telnet 으로 접속하면 볼 수 있으며 지금은 19회선으로 3000 여명의 사용자를 지원한다) 이 일 덕분에 나는 하루 24시간 내내 CCIL의 56K 회선을 통해 네트워크에 접속해 있을 수 있었다 -- 사실, 그렇게 해야만 하는 상황이었다.
1993년부터 나는 펜실베니아 주, 서 체스터(West Chester) 시의 소규모 무료 ISP인 체스터 카운티 인터링크 (Chester County InterLink : CCIL) 에서 기술적인 측면을 운영하고 있었다. 나는 CCIL 의 공동설립자였으며 우리만의 멀티유저 게시판 소프트웨어를 작성했다 - locke.ccil.org에 telnet 으로 접속하면 볼 수 있으며 지금은 30개의 회선으로 3000 여명의 사용자를 지원한다 이 일 덕분에 나는 하루 24시간 내내 CCIL의 56K 회선을 통해 네트워크에 접속해 있을 수 있었다 - 사실, 그렇게 해야만 하는 상황이었다.
I had gotten quite used to instant Internet email. I found having to periodically telnet over to locke to check my mail annoying. What I wanted was for my mail to be delivered on snark (my home system) so that I would be notified when it arrived and could handle it using all my local tools.
그래서 나는 바로바로 배달되는 인터넷 이메일에 매우 익숙해져 있는데 몇가지 복잡한 이유들로 인해 내 집의 컴퓨터 (snark.thyrsus.com) 과 CCIL 사이에 SLIP 연결을 하기가 꽤 힘들었다. 마침내 성공하고 나자, 주기적으로 locke 에 접속해 메일이 왔는지 체크해 보는 것이 매우 귀찮은 일이라는 것을 알게 되었다. 내가 원하는 것은 내 메일이 snark 로 배달되어 도착하는 즉시 내가 그것을 알 수 있고, 내 컴퓨터의 도구들을 이용해 메일을 다룰 수 있게 되는 것이다.
그래서 나는 즉시 전송되는 인터넷 이메일에 익숙해져 있는데, 메일을 확인하기 위해 주기적으로 텔레넷에 연결해야 하는 것은 성가신 일이라는 것을 알게 되었다. 내가 원하는 것은 내 메일이 snark(my home system)로 배달되어 도착하는 즉시 통보받고 내 컴퓨터의 도구들을 이용해 메일을 다룰 수 있게 되는 것이다.
The Internet's native mail forwarding protocol, SMTP (Simple Mail Transfer Protocol), wouldn't suit, because it works best when machines are connected full-time, while my personal machine isn't always on the Internet, and doesn't have a static IP address. What I needed was a program that would reach out over my intermittent dialup connection and pull across my mail to be delivered locally. I knew such things existed, and that most of them used a simple application protocol called POP (Post Office Protocol). POP is now widely supported by most common mail clients, but at the time, it wasn't built in to the mail reader I was using.
sendmail을 이용해 단순히 포워드시키는 것은 소용이 없었다. 내 개인 컴퓨터 항상 네트워크에 연결되어 있는 것도 아니고 고정적인 IP 어드레스를 가지고 있지도 않았다. SLIP 연결이 되면 내 메일을 가져와 내 컴퓨터 안에서 배달해주는 프로그램이 필요했다. 그런 프로그램이 몇 개 있었고, 대부분은 프로토콜로 POP(Post Office Protocol)을 사용했다. 물론, locke 의 BSD/OS 운영체제에는 POP3 서버가 포함되어 있었다.
인터넷의 기본 메일 전송 프로토콜인 SMTP(Simple Mail Transfer Protocol)는 컴퓨터가 항상 연결되어 있을 때 가장 잘 작동하는 반면, 내 개인 컴퓨터 항상 인터넷에 연결되어 있는 것도 아니고, 고정 IP주소를 가지고 있지 않기 때문에 맞지 않을 것이다. 나는 간혈적인 전화 접속 연결을 통해 내 메일을 가져와 배달해주는 프로그램이 필요했다. 그런 프로그램이 몇 개 있었고, 대부분은 간단한 응용 프로토콜로 POP(Post Office Protocol)을 사용했다. POP은 현재 대부분의 일반적인 메일 클라이언트에 의해 널리 지원되고 있지만, 그 당시에는 내가 사용하던 메일 reader에 내장되어 있지 않았다.
(김지원)
I needed a POP3 client. So I went out on the Internet and found one. Actually, I found three or four. I used one of them for a while, but it was missing what seemed an obvious feature, the ability to hack the addresses on fetched mail so replies would work properly.
하지만 내게 필요한 것은 POP3 클라이언트다. 그래서 네트워크를 뒤져 하나를 찾아냈다. 사실 서너개를 찾아내긴 했다. 잠시동안은 pop-perl을 사용했지만 기본적인 기능이 빠져 있었다. 가져온 메일에서 발신인의 주소를 제대로 처리하지 못해 답장을 보낼 수가 없었던 것이다.
나는 POP3 클라이언트가 필요했다. 그래서 인터넷 상에서 하나를 찾다. 사실 3, 4개 정도를 찾았다. 그 중 하나를 한 동안 사용했지만, 원래 메일에서 주소를 가져와 답장이 제대로 전달될 수 있도록 하는 중요한 기능이 빠져있었다.
The problem was this: suppose someone named `joe' on locke sent me mail. If I fetched the mail to snark and then tried to reply to it, my mailer would cheerfully try to ship it to a nonexistent `joe' on snark. Hand-editing reply addresses to tack on <@ccil.org> quickly got to be a serious pain.
문제는 이런 것이다. locke 사용자 중에 `joe' 라는 사람이 나에게 메일을 보냈다고 해보자. snark 로 메일을 가져와서 그 메일에 답장을 하려고 하면 메일 프로그램은 snark 에는 있지도 않은 `joe' 에게 답장을 보내려고 시도한다. 그래서 손으로 `@ccil.org'를 답장 받는 사람의 주소 뒤에 붙여주어야 했는데, 이것은 곧 매우 피곤한 일이 되어버렸다.
문제는 이런 것이다. locke 사용자인 ‘joe라는 이름의 사람이 게 메일을 보냈다고 하자. 내가 snark로 메일을 가져와 답장을 하려고 하면, 이 메일 프로그램은 snark에 없는 ‘joe에게 답장을 보내려 하는 것이다. 일일이 <@ccil.org>를 답장 받는 사람의 주소에 쓰는 것은 금방 귀찮아진다.
This was clearly something the computer ought to be doing for me. But none of the existing POP clients knew how! And this brings us to the first lesson:
이런 일은 분명 컴퓨터가 해주어야 하는 일이다. 하지만 이미 있는 POP 클라이언트에서는 어느것도 이 일을 해주지 못했다. 여기에서 첫 번째 교훈을 얻을 수 있다.
분명 컴퓨터가 나를 위해서 해줘야 하는 일이다. 그러나 현존하는 POP 클라이언트 중 어느 것도 어떻게 하는지 몰랐다. 이것이 바로 첫 번째 교훈을 우리에게 선사한다.
1. Every good work of software starts by scratching a developer's personal itch.
1. 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다. (Every good work of software starts by scratching a developer's personal itch)
1. 1. 소프트웨어가 하는 모든 좋은 일은 개발자의 가려운 곳을 긁어주는 것으로부터 시작된다.
Perhaps this should have been obvious (it's long been proverbial that ``Necessity is the mother of invention'') but too often software developers spend their days grinding away for pay at programs they neither need nor love. But not in the Linux world—which may explain why the average quality of software originated in the Linux community is so high.
명확해 보이는 교훈이긴 하지만 (``필요는 발명의 어머니'' 라는 오래된 속담이 있지 않은가) 소프트웨어 개발자들은 너무나 자주, 단지 돈 때문에 그들이 필요로 하지도 않고 좋아하지도 않는 프로그램을 만들어 내는데 시간을 쓰고 있다. 하지만 리눅스 세계에그렇지 않다 - 아마도 이것이 왜 리눅스 공동체에서 만들어진 소프트웨어의 평균적인 품질이 그렇게나 좋은지를 설명해줄 것이다.
(‘필요성은 발명의 어머니라는 오 속담이 있듯이) 이 교훈은 명확히 되어져야만 했지만, 소프트웨어 개발자가 돈 때문에 필요하지도 않고 좋아하지도 않는 프로그램을 만는데 시간을 보내는 경우는 너무 많았다. 그러나 이는 리눅스 세계에는 해당되지 않으며, 리눅스 커뮤니티가 만든 소프트웨어의 평균 퀄리티가 매우 높은 이유를 설명해주기도 한다.
So, did I immediately launch into a furious whirl of coding up a brand-new POP3 client to compete with the existing ones? Not on your life! I looked carefully at the POP utilities I had in hand, asking myself ``Which one is closest to what I want?'' Because:
래서 내가 이미 있는 POP3 클라이언트들과 경쟁하는 새로운 프로그램을 곧바로 코딩하기 시작했을까? 천만에. 나는 이미 가지고 있는 POP 유틸리티들을 조심스럽게 살피면서 스스로에게 물었다. ``내가 원하는 것과 가장 가까운 프로그램이 것일까?'' 그 이유는
렇다면 현존하는 POP3 클라이언트들과 경쟁시키기 위한 새로운 POP3 클라이언트를 내가 바로 만들었을까? 전혀 아니! 나는 갖고 있는 POP 유틸리티를 신중하게 살펴보며, 내 자신에게 ‘내가 원하는 것과 가장 근접한 것은 것일까?’라는 질문을 했다. 왜냐하면:
(선준영)2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
2. 좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 (그리고 재사용해야 할 지) 안다.
2. 좋은 프로그래머들은 무슨 프로그램을 야 할 지 안다. 위대한 프로그래머들은 무슨 프로그램을 다시 야 할 지 (그리고 재사용해야 할 지) 안다.
While I don't claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it's almost always easier to start from a good partial solution than from nothing at all.
내가 위대한 프로그래머라는 은 아니지만 흉내내려고는 다. 위대한 프로그래머의 중요한 특 중 하나는 건설적인 게으름이다. 그들은 들인 노력으로가 아니라 결과로 평가받는다는 것을 알고 있으며 완전한 무에서 시작하는 것보다 부분적으로나마 좋은 해결책에서 시작하는 것이 거의 항상 더 쉽다는 것을 알고 있다.
내가 위대한 프로그래머라고 주장하은 아니지만, 그런 부류를 흉내내려고는 다. 건설적인 게으름은 위대한 프로그래머의 중요한 특 중 하나이다. 그들은 노력이 아닌 결과좋은 평가를 받는다는 것을 알고 있고, 맨손으로 시작하는 것보다 부분적으로라도 좋은 해답을 지닌 채 출발하는 것이 대개 더 쉽다는 것을 다.
Linus Torvalds, for example, didn't actually try to write Linux from scratch. Instead, he started by reusing code and ideas from Minix, a tiny Unix-like operating system for PC clones. Eventually all the Minix code went away or was completely rewritten—but while it was there, it provided scaffolding for the infant that would eventually become Linux.
리누스 토발즈 를 예로 들자면 그는 맨바닥에서 Linux를 만들어 내려고 하지 않았다. 대신 그는 386 기계를 위한 Unix 비슷한 소형 OS, Minix 코드와 아이디어 재사용하는 것으로부터 시작했다. 결국 모든 Minix 코드는 사라지거나 새로 쓰여졌다 -- 하지만 Minix 코드가 남아있 동안 그 코드는 나중에 Linux 가 될 어린 아기의 발판 역할을 했다.
예를 들어, Linus Torvalds는 실제로 맨땅에서 리눅스를 만들어 내려고 하지 않았다. 그는 대신 유닉스와 유사한, PC 클론 전용 소형 운영체제인 Minix로부터 코드와 아이디어들을 재사용 하는 것으로 시작했다. 최종적으로 모든 Minix 코드는 없어지거나 완전히 새로 쓰여졌지만 Minix 코드가 남아있 동안 그 코드는 장차 리눅스가 될 초기상태에 발판이 되어 주었다.
In the same spirit, I went looking for an existing POP utility that was reasonably well coded, to use as a development base.
같은 생각으로 나는 이미 있는 POP 유틸리티 중 코딩이 잘 되어있는 것을 찾아 개발용하려 했다.
같은 정신으로, 나는 코딩이 잘 되어 있는 기존의 POP 유틸리티를 찾아 개발 기반으용하려 했다.
The source-sharing tradition of the Unix world has always been friendly to code reuse (this is why the GNU project chose Unix as a base OS, in spite of serious reservations about the OS itself). The Linux world has taken this tradition nearly to its technological limit; it has terabytes of open sources generally available. So spending time looking for some else's almost-good-enough is more likely to give you good results in the Linux world than anywhere else.
Unix 세계의 소스 공유하는 전통은 언제나 코드 재사용에 대해 호의적이었다. (GNU 프로젝트가 Unix 자체에 대한 심각한 의혹에도 불구하고 Unix 를 기본 OS 로 선택한 것도 바로 이런 이유에서였다) 리눅스 세계는 거의 기술적 한계에 다다를 때까지 이 전통을 받아들였다. 일반적으로 찾아볼 수 있는 오픈된 소스가 수 테라바이트에 달하는 것이다. 그래서 리눅스 세계에서는 다른 어느 곳에서보다 누군가의 거의 완성된 소스를 찾아보는데 시간을 들이는 것이 좋은 결과를 가져다 줄 가능성이 높다.
유닉스 세계의 소스 공유 전통은 항상 코드 재사용에 호의적이었다. (이는 GNU 프로젝트가 유닉스 운영체제 자체와 관련된 심각한 의혹에도 불구하고 유닉스를 기본 운영체제로 선택했던 이유였다.) 리눅스 세계는 거의 (일반적으로 수 테라바이트에 달하는 오픈소스들을 가용하게 하는) 기술적 한계에 이르기까지 이 전통을 받아들였다. 그래서 다른 어느 곳보다도, 리눅스 세계에서는 누군가의 거의 완성된 소스를 찾아보는데 시간을 투자하는 것이 좋은 결과로 이어질 가능성이 높다.
And it did for me. With those I'd found earlier, my second search made up a total of nine candidates—fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail and upop. The one I first settled on was `fetchpop' by Seung-Hong Oh. I put my header-rewrite feature in it, and made various other improvements which the author accepted into his 1.9 release. (선준영)
And it did for me. With those I'd found earlier, my second search made up a total of nine candidates—fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail and upop. The one I first settled on was `fetchpop' by Seung-Hong Oh. I put my header-rewrite feature in it, and made various other improvements which the author accepted into his 1.9 release.
나에게도 역시 그랬다. 예전에 찾아놓은 것에다가 두 번째 검색결과를 더하니 모두 아홉 개의 후보가 생겼다. fetchpop, PopTart, get-amil, gwpop, pimp, pop-perl, popc, popmail, 그리고 upop 이었다. 내가 제일 먼저 정착한 프로그램은 오승홍 씨의 fetchpop 이었다. 헤더 재작성 기능과 더불어 몇몇 개선사항을 추가했고, 저자가 릴리즈 1.9 에 그것을 수용했다.
나에게도 마찬가지였다. 일찍이 내가 찾아놓은 것에 두 번째 검색결과를 더하 fetchpop, PopTart, get-amil, gwpop, pimp, pop-perl, popc, popmail, 그리고 upop 으로 총 아홉 개의 후보가 생겼다. 그 중 처음으로 설정한 것은 오승홍 씨의 fetchpop 이었다. 헤더 재작성 기능과 더불어 여러 기타 개선사항을 추가했고, 저자는 이를 그의 1.9 배포판에 수용했다.
(2조 이민하)A few weeks later, though, I stumbled across the code for popclient by Carl Harris, and found I had a problem. Though fetchpop had some good original ideas in it (such as its background-daemon mode), it could only handle POP3 and was rather amateurishly coded (Seung-Hong was at that time a bright but inexperienced programmer, and both traits showed). Carl's code was better, quite professional and solid, but his program lacked several important and rather tricky-to-implement fetchpop features (including those I'd coded myself).
몇 주 후 나는 Carl Harris 가 만든 popclient 코드를 들여다 보다가 문제점을 발견했다. fetchpop 에는 훌륭한 독창적인 아이디어가 들어 있었지만 (daemon 모드 같은 것) POP3 만을 처리할 수 있었고, 아마추어 티가 나는 코딩이었다. (승홍 씨는 똑똑하기는 하지만 경험이 부족한 프로그래머였으며 그 가지 특징 모두를 코딩에서 볼 수 있었다) Carl 의 코드는 전문가가 만든 탄탄하면서 더 나은 코드였으나 몇가지 중요하면서도 구현하기 위해서는 약간의 잔머리가 필요한 fetchpop 기능들이 (내가 추가한 기능들을 포함해서) 빠져 있었다.
몇 주 후 나는 Carl Harris가 만든 popclient 코드를 우연히 보게 되었고, 문제가 있다는 것을 발견했다. fetchpop에는 좋은 독창적인 아이디어들이 있었음에도 불구하고 (예를 들어 background-daemon mode), 오로지 POP3만 다룰 수 있 아마추어 같은 코딩이었다. (승홍은 당시 똑똑하지만 경험이 부족한 프로그래머였고, 그의 코드에서 두가지 특징 모두 볼 수 있었다). Carl의 코드는 더 나았다. 조금 더 전문적이고 견고했다. 하지만 그의 프로그램은 몇개의 중요하고 기술을 요하는 fetchpop의 특징들이 빠져 있었다(내가 코딩한 것들을 포함해서).
Stay or switch? If I switched, I'd be throwing away the coding I'd already done in exchange for a better development base.
머물러 있을 것인가, 옮겨갈 것인가? 옮겨간다면 더 나은 개발기반을 위해 이미 해놓은 코딩을 포기해야만 했다.
그대로 둘 것인가, 바꿀 것인가? 만일 바꾼다면, 내가 이미 만들어 놓은 코드는 더 나은 개발기반을 위해 버려야 한다.
A practical motive to switch was the presence of multiple-protocol support. POP3 is the most commonly used of the post-office server protocols, but not the only one. Fetchpop and the other competition didn't do POP2, RPOP, or APOP, and I was already having vague thoughts of perhaps adding IMAP (Internet Message Access Protocol, the most recently designed and most powerful post-office protocol) just for fun.
옮겨가는데 실질적인 동기가 되었던 것은 다중 프로토콜 지원 여부였다. POP3 우체국 서버 프로토콜에서 가장 널리 쓰이는 것이긴 했지만 유일한 프로토콜은 아니다. fetchpop 을 비롯하여 다른 경쟁자들은 POP2, RPOP, 또는 APOP 지원하지 않았고, 나는 당시에 재미삼아서 IMAP(Internet Message Access Protocol, 가장 최근에 고안되었으며 가장 강력한 우체국 프로토콜) 을 지원해 볼까 하는 생각을 가지고 있었다.
바꾸기 위한 실질적인 동기 다중-프로토콜 지원 여부였다. POP3 우체국 서버 프로토콜에서 가장 흔하게 사용되는 것이지만, 유일한 프로토콜은 아니다. fetchpop 다른 경쟁자들은 POP2, RPOP, APOP 지원하지 않았고, 나는 막연하게, 단지 재미로 IMAP(Internet Message Access Protocol, 가장 최근에 설계되고 강력한 우체국 프로토콜)을 지원하는 생각을 이미 하고 있었다.
But I had a more theoretical reason to think switching might be as good an idea as well, something I learned long before Linux.
하지만 옮겨가는 것이 좋은 생각이라는 좀 더 이론적인 이유도 가지고 있었다. 리눅스를 알기 오래전에 배운 교훈이었다.
하지만 바꾸는 것이 더 좋을 것이라는 (리눅스 이전에 배운) 더 이론적인 이유도 고 있었다.
3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)
3. ``가지고 있는 것을 버릴 계획을 세우라 ; 언젠가는 버리게 될 것이다 (Plan to throw one away; youu will anyhow)'' (Fred Brooks, ``The Mythical Man-Month'', Chapter 11)
3. **버릴 계획을 하라; 어찌됐건 그렇게 할것이다.** (Fred Brooks, The Mythical Man-Month, Chapter 11)
Or, to put it another way, you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once [JB].
다른 말로 하자면, 첫 번째 해결책을 구현할 때까지도 진짜 문제가 무엇인지 이해하지 못하는 경우가 종종 있다는 것이다. 두 번째 되어어떻게 하는 것이 옳은 것인지 충분히 게 될 수 있다. 따라서 만일 올바른 방법을 찾고 싶다면 최소한 번은 처음부터 다시 시작할 준비를 해 두어야 한다.
다른 방식으로 말하면, 첫 번째 솔루션을 구현하기 전까지는 문제를 제대로 이해하지 못하는 경우가 다. 두 번째 되어야 그것을 올바르게 해낼 수 있을 정도로 충분히 이해하게 될 것이다. 따라서 제대로 이해하려면 적어도 한번은 다시 시작할 준비를 해한다.
Well (I told myself) the changes to fetchpop had been my first try. So I switched.
그래, fetchpop을 고친 것은 첫 번째 시도였어, 하고 스스로에게 말하고 나서 나는 popclient 옮겨갔다.(2조 이민하)
'그래, fetchpop을 고친 것은 첫 번째 시도였어'라고 내 자신에게 말했다. 그리고 나는 popclient로 바꾸게 되었다. (2조 이민하)
(2조 장재욱) After I sent my first set of popclient patches to Carl Harris on 25 June 1996, I found out that he had basically lost interest in popclient some time before. The code was a bit dusty, with minor bugs hanging out. I had many changes to make, and we quickly agreed that the logical thing for me to do was take over the program.
1996년 6월 25일에 Carl Harris 에게 내 첫 번째 popclient 패치를 보낸 후, 나는 그가 popclient 에 대한 흥미를 이미 잃었다는 것을 알게 되었다. 코딩이 좀 지저분했고, 자잘한 버그들이 널려있었다. 내가 수정해야 할 것이 많았고, Carl 과 나는 곧 내가 프로그램을 넘겨받는 것이 합리적이라는 데에 동의하게 되었다.
내가 1996년 6월 25일에 Carl Harris에게 내 첫 번째 popclient 패치 세트를 보낸 후, 나는 그가 얼마 전에 popclient에 기본적으로 흥미를 잃었다는 것을
알게 되었다. 코딩에는 사소한 버그들이 있어 좀 지저분했다. 나는 수정해야 할 것이 많았고, 우리는 그 프로그램을 인수받는 것이 나에게 합리적이라는 것에 빠르게 동의하게 되었다.
Without my actually noticing, the project had escalated. No longer was I just contemplating minor patches to an existing POP client. I took on maintaining an entire one, and there were ideas bubbling in my head that I knew would probably lead to major changes.
내가 알아차리지 못하는 새에 프로젝트가 차츰 궤도에 오르기 시작했다. 나는 이미 존재하고 있는 POP 클라이언트의 마이너 패치를 생각하는 것이 아니었다. 클라이언트 하나를 통채로 관리하고 있었으며 내 머리에서는 커다란 변화가 될 아이디어들이 솟아나고 있었다.
실제로 내가 알아차리지 못하는 사이에 프로젝트는 확대되었다. 나는 더이상 POP 클라이언트에 있는 사소한 패치들을 고려하지 않고 있었다.
나는 클라이언트 하나를 통채로 관리하고 있었고, 큰 변화를 이끌지도 모른다는 아이디어들이 내 머리속에 자리잡고 있었다.
In a software culture that encourages code-sharing, this is a natural way for a project to evolve. I was acting out this principle:
코드 공유를 장려하는 소프트웨어 문화에서런 방식으로 프로젝트가 진화하기 마련이다. 이렇게 말할 수 있다.
코드 공유를 장려하는 소프트웨어 문화에서,것은 프로젝트가 진화하는데 자연스러운 방법이다. 나는 이런 원칙을 실천하고 있었다:
4. If you have the right attitude, interesting problems will find you.
4. 적절한 태도를 가지고 있으면 흥미로운 문제가 당신을 찾아갈 것이다.
4. 올바른 태도를 가지고 있으면, 당신에게 흥미로운 문제가 주어질 것이다.
But Carl Harris's attitude was even more important. He understood that
하지만 Carl Harris 의 태도가 훨씬 더 중요했다. 그는 것을 이해하고 있었다.
하지만 Carl Harris의 태도가 훨씬 더 중요했다. 그는 것을 이미 이해했다.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
5. 프로그램에 흥미를 잃다면 프로그램에 대한 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다. (When you lose interest in a program, your last duty to it is to hand it off to a competent successor)
5. 당신이 프로그램에 대한 흥미를 잃다면, 유능한 후임자에게 프로그램을 넘겨주는 것이 당신의 마지막 의무이다.
Without ever having to discuss it, Carl and I knew we had a common goal of having the best solution out there. The only question for either of us was whether I could establish that I was a safe pair of hands. Once I did that, he acted with grace and dispatch. I hope I will do as well when it comes my turn.(2조 장재욱)
토론할 필요 없이 Carl 과 나는 우리가 가장 좋은 해결책을 찾고 있다는 것을 알고 있었다. 우리에게 남아있는 한가지 문제는 내가 적임자라는 것을 입증할 수 있느냐 하는 것이었다. 내가 그것을 증명하자 그 기꺼이, 그리고 신속하게 행동했다. 내가 그렇게 행동할 차례가 되었을 때 나도 그만큼 잘 할 수 있기를 바란다.
더 이상의 의논도 필요 없이, Carl과 나는 최고의 해결책을 찾는 것이 공동 목표라는 것을 알다. 우리에게 남은 유일한 질문은 자신이 적임자라는 것을 입증할 수 있느냐 하는 것이었다. 일단 내가 그것을 증명하자 그 기꺼이 신속하게 행동했다. 자신의 차례가 오면 자신 또한 그만큼 잘 할 수 있기를 나는 희망한다.
## The Importance of Having Users
Loading