성당과 시장.

성당과 시장

by Eric S. Raymond
$Date: 1998/05/13 17:29:31

리눅스의 역사에 의해 제시된 소프트웨어 엔지니어링의 놀라운 이론의 신중한 테스트로 실행된 성공적인 오픈소스 프로젝트, fetchmail을 분석한다. 이 이론들을 두 개의 근본적으로 다른 개발 스타일의 용어들로 논할 것이다. 두가지 스타일이란 상업용 소프트웨어의 “성당” 모델과 리눅스 세계의 “시장” 모델이다. 이 모델들은 소프트웨어 디버깅 작업의 본질에 대한 서로 대립되는 가설들로부터 파생되었다는 것을 보일 것이다. 그리고 나서 리눅스의 경험으로부터 “충분히 많은 사람이 있다면, 찾을 수 없는 버그란 없다” 는 일관된 주장을 펴고, 다른 이기적인 에이전트들의 자가수정 시스템과의 생산적인 비유를 제시한 다음, 소프트웨어의 미래를 위해 이 통찰이 가지는 의미에 대한 탐구로 마무리짓는다.



순서

  1. 성당과 시장
  2. 메일은 배달되어야만 한다
  3. 사용자가 있다는 것의 중요성
  4. 일찍 발표하고, 자주 발표하라
  5. 장미가 장미다우려면
  6. Popclient 가 Fetchmail 이 되다
  7. Fetchmail 의 성장
  8. Fetchmail에서 배울 점
  9. 시장 스타일의 개발에 필요한 선행조건들
  10. 오픈소스 소프트웨어의 사회적 문맥
  11. 감사의 말
  12. 읽어볼 만한 글들
  13. 후기 : 넷스케입이 시장스타일을 받아들이다!
  14. 버전과 변천사


1. 성당과 시장

리눅스는 파괴적이다. 파트타임으로 해킹을 하면서 인터넷이라는 가느다란 선만으로 연결되어 있는 전세계 수천명의 개발자들에 의해 세계적인 수준의 운영체제가, 마치 마술로 된 것처럼 만들어질 수 있었으리라고 5년 전에 누가 상상이나 할 수 있었을까? 나는 분명 상상하지 못했다. 1993년 초, 리눅스가 내 레이다 화면에 잡혔을 때 나는 이미 유닉스와 오픈소스 개발을 10년 동안 해오고 있었다. 1980년대 중반에 GNU 에 공헌한 첫 번째 사람들 중 한명이었다. 나는 네트워크 상에 꽤 많은 오픈소스 소프트웨어를 발표했고, 지금도 널리 사용되고 있는 몇몇 프로그램을 개발중이거나 공동개발하고 있었다. (네트핵, Emacs VC 와 GUD 모드, xlife, 등등) 나는 프로그램이 어떻게 개발되어야 하는지 알고 있다고 생각했다.

리눅스는 내가 알고 있다고 생각한 것을 많은 부분 뒤집어 버렸다. 몇 년 동안이나 나는 작은 도구, 빠른 프로토타이핑, 그리고 진화적인 프로그래밍을 여러 해 동안 유닉스의 복음으로 설교해 오고 있었다. 하지만 나는 어떤 종류의 매우 중요한 복잡성이 있어서 거기에는 더 집중되고 선험적인 접근방법이 필요하다고 믿고 있었다. 가장 중요한 소프트웨어 (운영체제나 Emacs 같이 대단히 커다란 커다란 도구들) 은 성당을 건축하듯이, 즉 찬란한 고독 속에서 일하는 몇 명의 도사 프로그래머나 작은 그룹의 뛰어난 프로그래머들에 의해 조심스럽게 만들어지고 베타버전도 필요없이 발표되어야 한다고 생각했던 것이다.

리누스 토발즈의 개발 스타일은 – 일찍, 그리고 자주 발표하며 다른 사람들에게 위임할 수 있는 것은 모두 위임하고, 뒤범벅이 된 부분까지 공개하는 그런 스타일 – 나에게 놀라움으로 다가왔다. 고요하고 신성한 성당의 건축방식은 여기에서 찾아볼 수 없었다. 대신, 리눅스 공동체는 서로다른 의견과 접근방법이 난무하는 매우 소란스러운 시장같았다. (리눅스 아카이브 사이트가 이것을 적절히 상징하고 있다. 이곳에는 누/구/나/ 파일을 올릴 수 있다) 이런 시장바닥에서 조리있고 안정적인 시스템이 나온다는 것은 연속된 기적으로만 가능한 것처럼 보였다.

시장 스타일이 매우 효과적이라는 사실은 분명히 충격이었다. 리눅스 공동체에 익숙해 가면서 나는 개개의 프로젝트에만 열심이었던 것이 아니라 왜 리눅스 세계가 혼란속에 갈라지지 않을 뿐 아니라 성당건축가들이 간신히 상상만 할 수 있는 속도로 갈수록 강해지는지 이해하려고 애썼다.

1996년 중반에야 이해가 되기 시작했다. 내 이론을 시험해 볼 수 있는 완벽한 기회가 오픈소스 프로젝트의 형태로 찾아왔다. 여기에서 나는 의식적으로 시장 스타일을 시도해 볼 수 있었고, 큰 성공을 거두었다.

이 글의 나머지 부분에서는 그 프로젝트에 대해 이야기하고 효과적인 오픈소스 개발에 대한 격언들을 제시할 것이다. 내가 이 모든 것을 리눅스 세계에서 배운 것은 아니지만 리눅스 세계가 이 격언들에게 특별한 요점을 가질 수 있게 해주었다. 만일 내가 옳다면, 독자들은 이 격언들로부터 리눅스 공동체가 훌륭한 소프트웨어를 만들어내는 원천이 될 수 있었던 이유를 이해할 수 있을 것이며, 독자 자신들도 더 생산적으로 될 수 있을 것이다.

2. 메일은 배달되어야만 한다.

1993년에 서 펜실베니아 주, 서 체스터(West Chester) 시의 자그마한 무료 ISP 인 체스터 카운티 인터링크 (Chester County InterLink : CCIL) 에서 기술적인 측면을 담당하고 있었다. (나는 CCIL 의 공동설립자였으며 우리만의 멀티유저 게시판 소프트웨어를 작성했다 – locke.ccil.org 에 telnet 으로 접속하면 볼 수 있다. 지금은 19 회선으로 3000 여명의 사용자를 지원한다) 이 일 덕분에 나는 하루 24시간 내내 CCIL 의 56K 회선을 통해 네트워크에 접근할 수 있었다. 사실, 그렇게 해야만 하는 상황이었다.

그래서 나는 즉시 배달되는 인터넷 이메일에 매우 익숙해졌다. 복잡한 이유로 인해 내 집의 컴퓨터 (snark.thyrsus.com) 과 CCIL 사이에 SLIP 연결을 하기가 힘들었다. 마침내 성공하고 나자, 주기적으로 locke 에 접속해 메일이 왔는지 체크해 보는 것이 매우 귀찮은 일이라는 것을 알게 되었다. 나는 내 메일이 snark 로 배달되었을 때 바로 알 수 있고, 내 도구들을 가지고 메일을 다룰 수 있게 되는 것을 원했다.

sendmail을 이용해 단순히 포워드시키는 것은 소용이 없었다. 내 개인 컴퓨터가 항상 네트워크에 연결되어 있는 것도 아니고 고정적인 IP 어드레스를 가지고 있지도 않았다. SLIP 연결이 되면 내 메일을 배달해주는 프로그램이 필요했다.

그런 프로그램이 몇 개 있었고, 대부분은 프로토콜로 POP (Post Office Protocol)을 사용했다. 물론, locke 의 BSD/OS 운영체제에는POP3 서버가 포함되어 있었다. 내게 필요한 것은 POP3 클라이언트였다. 그래서 네트워크를 뒤져 하나를 찾아냈다. 사실은 서너개를 찾아내긴 했다. 잠시동안은 pop-perl을 사용했지만 기본적인 기능이 빠져있었다. 가져온 메일에서 발신인의 주소를 제대로 처리하지 못해 답장을 보낼 수가 없었다. locke 의 사용자 중에 joe 라는 사람이 나에게 메일을 보냈다고 해보자. snark 로 메일을 가져와서 그 메일에 답장을 하려고 하면 메일 프로그램은 snark 에는 있지도 않은 joe 에게 답장을 보내려고 시도한다. 그래서 손으로 ‘@ccil.org’를 뒤에 붙여주어야 했는데, 곧 매우 성가시게 느껴졌다.

이것은 분명히 컴퓨터가 해주어야 하는 일이었다. 하지만 이미 있는 POP 클라이언트들 중 어느것도 이 일을 해주지 못했다. 여기에서 첫 번째 교훈을 얻을 수 있다.

1) 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다. (Every good work of software starts by scratching a developer’s personal itch)

명확해 보이는 교훈이긴 하지만 (“필요는 발명의 어머니” 라는 오래된 속담이 있지 않은가)소프트웨어 개발자들은 너무나자주, 단지 돈 때문에 그들이 필요로 하지도 않고 좋아하지도 않는 프로그램을 만들어 내는데 시간을 쓰고 있다. 하지만 리눅스 세계에서는 그렇지 않다 – 아마도 이것이 리눅스 공동체에서 만들어진 소프트웨어들의 평균적이 품질이 그렇게나 좋은지를 설명해줄 것이다.

그래서 내가 이미 있는 POP3 클라이언트들과 경쟁하는 새로운 프로그램을 곧바로 코딩하기 시작했을까? 천만에. 나는 이미 가지고 있는 POP 유틸리티들을 조심스럽게 살피면서 스스로에게 물었다. “내가 원하는 것과 가장 가까운 프로그램이 어느 것일까?” 그 이유는

2) 좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 (그리고 재사용해야 할 지) 안다. (Good programmers know what to write. Great ones know what to rewrite(and reuse))

내가 위대한 프로그래머라는 말은 아니지만 흉내내려고는 했다. 위대한 프로그래머의 중요한 특징 중 하나는 건설적인 게으름이다. 그들은 들인 노력으로가 아니라 결과로 평가받는다는 것을 알고 있으며 완전한 무에서 시작하는 것보다는 부분적으로나마 좋은 해결책에서 시작하는 것이 거의 항상 더 쉽다는 것을 알고 있다.

리누스 토발즈 (http://www.earthspace.net/~esr/faqs/linus)를 예로 들자면 그는 맨바닥에서 Linux를 써내려고 하지 않았다. 대신 그는 386 기계를 위한 Unix 비슷한 OS, Minix 의 코드와 아이디어를 재사용하는 것으로부터 시작했다. 결국 모든 Minix 코드는 사라지거나 새로 쓰여졌다 — 하지만 Minix 의 코드가 남아있을 동안 그 코드는 나중에 Linux 가 될 어린 아기의 발판 역할을 했다.

똑같은 생각으로 나는 이미 있는 POP 유틸리티 중 코딩이 잘 되어있는 것을 찾아 개발의 기초로 사용하려 했다. Unix 세계의 소스를 공유하는 전통은 언제나 코드를 재사용하는데 호의적이었다. (GNU 프로젝트가 Unix 자체에 대한 심각한 의혹에도 불구하고 Unix 를 기본 OS 로 선택한 것도 바로 이런 이유에서였다) 리눅스 세계는 거의 기술적인 한계에 다다를때까지 이 전통을 받아들였다. 일반적으로 찾아볼 수 있는 오픈된 소스가 수 테라바이트에 달하는 것이다. 그래서 누군가의 거의 완성된 소스를 찾아보는데 시간을 들이는 것이 다른 어느 곳에서보다 리눅스 세계에서는 좋은 결과를 가져다 줄 가능성이 높다. 나에게도 역시 그랬다. 예전에 찾아놓은 것에다가 두 번째 검색결과를 더하니 모두 아홉 개의 후보가 생겼다. fetchpop, PopTart, get-amil, gwpop, pimp, pop-perl, popc, popmail, 그리고 upop 이었다. 내가 제일 먼저 신경을 집중한 것은 오승홍 씨의 fetchpop 이었다. 헤더 재작성 기능과 더불어 몇몇 개선사항을 그 안에 추가했고, 저자가 릴리즈 1.9 에 그것을 수용했다.

몇 주 후에 나는 Carl Harris 가 만든 popclient 의 코드를 들여다 보다가 문제점을 발견했다. fetchpop 에는 훌륭한 독창적인 아이디어가 들어 있었지만 (daemon 모드 같은 것) POP3 만을 처리할 수 있었고, 아마추어 티가 나는 코딩이었다. (오승홍 씨는 똑똑하기는 하지만 경험이 부족한 프로그래머였으며 그 두 가지 특징 모두를 코딩에서 볼 수 있었다) Carl 의 코드는 탄탄한 프로페셔널의 더 나은 코드였으나 몇가지 중요하면서도 구현하기 위해서는 약간의 잔머리가 필요한 fetchpop 의 기능들이 (내가 추가한 기능들을 포함해서) 빠져 있었다.

머물러 있을 것인가, 옮겨갈 것인가? 옮겨간다면 더 나은 개발기반을 위해 이미 해놓은 코딩을 포기해야만 했다. 옮겨가는데 실질적인 동기가 되었던 것은 다중프로토콜 지원 여부였다. POP3 가 우체국 서버 프로토콜 중에서 가장 널리 쓰이는 것이긴 했지만 유일한 프로토콜은 아니었다. fetchpop을 비롯하여 다른 경쟁자들은 POP2, RPOP, 또는 APOP를 지원하지 않았고, 나는 당시에 재미삼아서 IMAP (Internet Message Access Protocol; http://www.imap.org; 가장 최근에 고안되었으면 가장 강력한 우체국 프로토콜) 을 지원해볼까 하는 생각을 가지고 있었다.

하지만 옮겨가는 것이 좋은 생각이라는 좀 더 이론적인 이유도 가지고 있었다. 오래전에 리눅스에서 배운 교훈이었다.

3) “가지고 있는 것을 버릴 계획을 세우라 ; 언젠가는 버리게 될 것이다 (Plan to throw one away; youu will anyhow)” (Fred Brooks, “The Mythical Man-Month”, Chapter 11)

다른 말로 하자면, 첫 번째 해결책을 구현할 때까지도 진짜 문제가 무엇인지 이해하지 못하는 경우가 종종 있다는 것이다. 두 번째가 되어서야 어떻게 하는 것이 옳은 것인지 충분히 알게 될 수 있다. 따라서 만일 올바른 방법을 찾고 싶다면 최/소/한 한 번은 처음부터 다시 시작할 준비를 해 두어야 한다. 그래, fetchpop을 고친 것은 내 첫 번째 시도였어, 하고 스스로에게 말하고 나서 나는 popclient 로 옮겨갔다.

1996년 6월 25일에 Carl Harris 에게 내 첫 번째 popclient 패치를 보낸 후, 나는 그가 popclient 에 대한 흥미를 이미 잃었다는 것을 알게 되었다. 코딩이 좀 지저분했고, 자잘한 버그들이 널려있었다. 수정을 많이 가했고, Carl 과 나는 곧 내가 프로그램을 넘겨받는 것이 합리적이라는 데에 동의하게 되었다. 내가 알아차리지 못하는 새에 프로젝트가 차츰 궤도에 오르기 시작했다. 나는 이미 존재하고 있는 POP 클라이언트의 마이너 패치를 생각하는 것이 아니었다. 클라이언트 하나를 통채로 관리하고 있었으며 내 머리에서는 커다란 변화가 될 아이디어들이 솟아나고 있었다.

코드공유를 장려하는 소프트웨어 문화에서는 이런 방식으로 프로젝트가 진화하기 마련이다. 이렇게 말할 수 있다.

4) 적절한 태도를 가지고 있으면 흥미로운 문제가 당신을 찾아갈 것이다. (If you have the right attitude, interesting problems will find you)

하지만 Carl Harris 의 태도가 훨씬 더 중요했다. 그의 태도는

5) 프로그램에 흥미를 잃었다면 프로그램에 대한 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다. (When you lose interest in a program, your last duty to it is to hand it off to a competent successor)

토론할 필요도 없이 Carl 과 나는 가장 좋은 해결책을 찾아낸다는 목표를 가지게 되었다. 우리에게 남아있는 한가지 문제는 내가 적임자라는 것을 입증할 수 있느냐 하는 것이었다. 내가 그것을 증명하자 그는 기꺼이, 그리고 신속하게 행동했다. 내가 그렇게 행동할 차례가 되었을 때 나도 그만큼 잘 할 수 있기를 바란다.

3. 사용자가 있다는 것의 중요성

그래서 내가 popclient를 넘겨받았다. 내가 popclient 의 사용자들을 넘겨받았다는 것도 그에 못지않게 중요하다. 사용자들이 있다는 것은 매우 좋은 일이다. 당신이 누군가의 필요를 충족시켜주고 있으며 일을 잘 해나가고 있다는 것을 보여주기 때문만은 아니다. 적절하게 유도해 준다면 사용자들을 공동개발자가 될 수 있다.

유닉스의 전통이 가지고 있는 또하나의 강점, 즉 많은 수의 사용자들이 동시에 해커이기도 하다는 것을 리눅스는 좋은 의미로서의 극단까지 밀어붙였다. 소스코드가 공개되어 있기 때문에 그들은 효/과/적/인/ 해커가 될 수 있었다. 이것은 디버깅 시간을 줄이는 데 엄청난 도움이 되었다. 조금만 격려해주면 사용자들은 문제를 분석하고 해결책을 제시하며, 도움없이 혼자 일할 때보다 훨씬 빨리 코드를 개선시키도록 해준다.

6) 사용자들을 공동개발자로 생각하면 코드가 다른 어떤 방법보다도 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다. (Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging)

이 효과의 위력은 과소평가되기 쉽다. 사실, 오픈소스의 세계의 우리들조차 시스템의 복잡도에 대항하여 많은 수의 사용자가 얼마나 힘이 되는지를 리누스 토발즈가 보여주기 전까지 과소평가하고 있었다. 실제로 나는 리누스의 가장 영리하고 가장 중요한 해킹은 리눅스 커널을 만들었다는 점이 아니라 리눅스 개발모델을 만들었다는 점이라고 생각한다. 리누스에게 이 의견을 말해 주었더니 그는 씨익 웃고서 조용히 여러번 하던 말을 되풀이했다. “난 기본적으로 매우 게으른 사람이라서 실제로는 다른 사람들이 해놓은 일을 가지고 공로라고 인정받곤 해요.” 여우처럼 게으르군. 로버트 하인라인이라면 실패하기에는 너무 게으르다고 말했을 것이다.

되돌아 보면, 리눅스의 성공과 방법론은 GNU Emacs Lisp 라이브러리와 Lisp 코드 아카이브에서 그 선례를 찾아볼 수 있다. Emacs C 코어와 다른 대부분의 FSF 도구들의 성당건축 스타일과는 대조적으로 Lisp 코드 풀의 진화는 유동적이었고, 사용자가 주도한 것이었다. 아이디어와 프로토타입 모드들은 안정적인 최종형태를 갖추기까지 종종 서너번씩 다시 쓰여졌다. 느슨하게 묶인 공동작업이 인터넷으로 인해 가능해졌고, 리눅스에서는 매우 자주 일어나는 일이 되었다. 사실 fetchmail 이전에 내 자신의 가장 성공적인 해킹은 아마 Emacs VC 모드였을 것이다. 세 명의 사람들과 email을 통해 리눅스와 비슷한 협동작업을 했고, 그 셋 중의 한 명 (리차드 스톨만:Richard Stallman. Emacs 의 저자이면서 FSF 의 설립자) 만을 지금까지 만나고 있다. VC 모드는 SCCS, RCV 와 CVS 를 위한 Emacs 내의 프론트엔드였고, “원터치” 버전컨트롤 기능을 제공했고, 누군가 만들어 놓은 작고 조악한 sccs.el 모드로부터 진화한 것이었다. VC 의 개발은 Emacs 와는 다르게 Emacs List 코드가 발표/테스트/개선의 주기를 매우 빨리 반복할 수 있었기 때문에 성공했다. 코드를 GPL 에 법적으로 묶어두려던 FSF 의 정책은 한가지 예기치 못한 부작용을 가져왔다. FSF 는 20줄 이상의 개인적인 공헌에 대해서 저작권을 받아야 한다고 생각하기 때문에 시장모드를 사용하는 절차가 어려워졌다는 것이다. 이것은 GPL 의 코드가 저작권법 하에서 도전받는 것을 방지하기 위한 정책이다. BSD 와 MIT 의 X 콘소시엄 라이센스를 사용하여 저작권을 얻는사람은 이런 문제를 겪지 않는다. 그들은 누군가가 도전할 동기를 가질만한 권리를 가지려 하지 않는다.

4. 일찍, 그리고 자주 발표하라

일찍, 그리고 자주 발표하는 것은 리눅스 개발모델의 중요한 부분이다. 대부분의 개발자들은 (필자를 포함하여) 아주 사소한 프로젝트가 아니라면 이런 정책은 나쁜 것이라고 생각한다. 초기버전들은 예외없이 버그가 많고, 개발자라면 사용자들의 인내심을 시험하고 싶어하지 않기 때문이다. 이런 믿음이 성당건축 스타일의 개발을 더 선호하게 만들었다. 만일 가장 중요한 목표가 사용자들로 하여간 가능한 한 적은 버그를 발견하게 만드는 것이라면 6 개월에 한 번씩, 혹은 그보다 더 늦게 발표하면서 그동안 죽어라고 일하는 편이 나을 것이다. Emacs C 코어는 이런 식으로 개발되었다. Lisp 라이브러리는 그렇지 않았다. Emacs 의 발표주기와 관계없이 언제든 새로운 개발 코드 버전을 찾을 수 있으며, FSF 의 통제권 밖에 있는 Lisp 라이브러리들이 있었기 때문이다. 이들 중 가장 중요한 아카이브는 오늘날 대형 리눅스 아카이브들의 정신과 많은 기능들을 이미 가지고 있었던 오하이오 주 elisp 아카이브였다. 하지만 우리가 하고 있는 일에 대해, FSF 의 성당건축 개발모델의 문제점들에 대해 그 아카이브의 존제가 무엇을 제시하는지에 대해 우리들 중 소수만이 진지하게 생각하고 있었다. 나는 1992년에 오하이오 코드를 모다 공식적인 Emacs Lisp 라이브러리로 만들려는 시도를 했으나 정치적인 문제에 부딪쳤고, 큰 실패를 겪었다.

1년 후에, 리눅스가 널리 알려지기 시작했고, 무언가 다르면서도 훨씬 바람직한 일이 일어나고 있다는 것이 확실해 보였다. 리누스의 열린 개발정책은 성당건축과 완전히 반대되는 것이었다. 선사이트와 tsx-11 아카이브가 싹트고 있었고, 다중배포방식이 퍼지기 시작했다. 그리고 이 모든 것이 이전의 어느 소프트웨어보다 자주 릴리즈되는 코어시스템에 의해 주도되고 있었다. 리누스는 가장 효과적인 방식으로 사용자들을 공동개발자라고 여겼던 것이다.

7) 일찍 발표하고 자주 발표하라. 그리고 사용자들의 소리에 귀를 기울이라. (Release early. Release often. And listen to your customers)

리누스의 혁신은 그가 이렇게 했다는 점 보다는 (오랫동안 유닉스 세계의 전통이었던 것처럼) 그가 개발하고 있던 리눅스 커널의 복잡성에 비견될만한 수준으로까지 끌어올렸다는 데 있다. 초기에 (1991년 경에) 그는 하/루/에 한 번 이상 새로운 커널을 발표하기까지 했다. 리누스가 공동개발자들이라는 자신의 기반을 잘 만들었고, 인터넷이라는 지렛대를 이용하여 누구보다도 열심히 협동작업에 몰두했기 때문에 이런 방식은 성공했다. 하지만 어/떤 과정을 거쳐 성공했을까? 내가 재현할 수 있는 것일까, 아니면 리누스 토발즈만의 천재성이 필요한 것일까?

그렇게 생각되지는 않았다. 리누스가 매우 뛰어난 해커라는 점은 인정한다. (우리중에 상업용 제품 못지 않은 운영체제의 커널을 만들어낼 수 있는 사람이 몇이나 될까?) 하지만 리눅스는 놀랄만한 개념적 전진을 이루어내지는 않았다. 리누스는 리차드 스톨먼이나 제임스 고슬링 (NeWS 와 자바를 만든) 과 같은 혁신적인 설계를 이루어내는 천재는 (적어도 지금까지는) 아니없다. 대신 리누스는 공학의 천재인 것으로 보인다. 버그와 개발의 막다른 골목을 피하는 육감, 그리고 A 점에서 B 점까지 가는데 최소노력경로를 찾아내는 요령을 갖추고 있었다. 실제로 리눅스의 전반적인 설계는 이런 특성을 바탕으로 하고 있으며 리누스의 본질적으로 보수적이고 단순한 설계 방식을 반영하고 있다. 따라서 빠른 릴리즈와 인터넷을 매체로 사용하는 것은 우연히 이루어진 것이 아니라 리누스의 공학에 대한 천재성의 일부분으로 최소노력경로에 대한 통찰력으로 된 것이라면 그가 최대화 하고 있는 것은 무엇이었을까? 기계에서 무엇을 뽑아내었던 것일까?

해답은 질문 안에 있다. 리누스는 그의 해커/유저들에게 지속적인 자극과 보답을 제공했다. 리눅스 개발에 참여함으로써 자기만족을 얻으리라는 전망에 자극받았고, 그들이 하는 일이 계속해서 (어떤 때는 날/마/다) 향상되고 있다는 것이 보답이 되었다. 리누스는 코드의불안정성과 만일 처리하기 곤란한 심각한 버그가 발견되면 사용자들이 떨어져 나갈 것을 무릅쓰고 디버깅과 개발에 투입되는 공수(the number of person-hours)를 최대화 하는 것에 목표를 두었다. 리누스는 다음과 같은 신념을 가지고 있는 것처럼 행동했다.

8) 충분히 많은 베타테스터와 공동개발자가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다. (Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone)

덜 형식적으로 말하자면, “눈알이 충분히 많으면 찾지 못할 버그는 없다”. 나는 이것을 “리누스의 법칙” 이라고 부른다.

내 원래의 공식적인 서술은 모든 문제는 “누군가에게는 간단할 것이다” 였다. 리누스가 문제를 이해하고 고치는 사람이 그 문제를 처음 파악한 사람과 항상 같은 것이 아니라 오히려 다를 경우가 더 많다고 이의를 제기했다. 리누스 말로는 “누군가 문제를 발견합니다. 그리고 또/다/른 누군가가 그 문제를 이해하지요. 문제를 발견해 내는 것이 더 중요한 일이라고 분명히 말할 수 있습니다.” 하지만 가장 중요한 점은사람이 충분히 많을 경우 이 두 가지가 모두 매우 빨리 일어나는 경향이 있다는 것이다.

내 생각에는 여기에 성당건축과 시장 스타일의 핵심적인 차이점이 있다. 프로그래밍의 성당건축가의 관점에서 보자면 버그와 개발 문제는 어렵고, 까다로우며 심오한 현상이다. 문제를 해결하려면 헌신된 소수의 사람이 몇 달이고 정밀한 검사를 수행해야 모두 끝났다는 확신을 가질 수 있다. 따라서 발표 사이의 기간이 길어지고, 오랫동안 기다린 릴리즈가 완벽하지 않을 때는 필연적으로 실망이 따른다. 반면, 시장의 관점에서는 버그가 보통 쉽게 해결할 수 있는 것이라고 본다 – 최소한 새로운 릴리즈가 나올때마다 그것과 씨름하는 수천의 열정적인 공동개발자들에게 알려진다면 금방 쉽게 해결할 수 있는 문제로 바뀐다. 따라서 더 많이 교정을 받고 싶다면 자주 발표해야 하며 덤으로 서투른 부분이 드러나더라도 덜 창피하게 되는 이점이 있다.

바로 이것이다. 이것으로 충분하다. “리누스의 법칙” 이 틀렸다면 리눅스 커널과 같이 복잡한 시스템은 어떤 것이라도 수많은 손들에 의해 해킹되면서 일찍이 볼 수 없었던 나쁜 상호작용과 발견되지 못한 “심오한’ 버그들에 의해 어느 시점에선가 붕괴되고 말았을 것이다. 반면에, 만일 그 법칙이 옳다면 그 법칙만으로도 리눅스의 상대적으로 적은 버그를 설명할 수 있다.

그리고 이 법칙이 옳다는 점에 대해서는 너무 놀라지 않았어야 할 것이다. 수년 전, 사회학자들은 비슷하게 전문적인 (혹은 비슷하게 무지한) 관찰자들로 이루어진 대중의 평균적인 의견이 그 관찰자 중 무작위로 뽑은 한 명의 의견보다 더 신뢰할 만하다는 점을 발견했다. 사회학자들은 이것을 “델파이 효과” 라고 부른다. 리누스가 보여준 것은 이 효과가 운영체제를 디버깅하는 데에도 적용될 수 있다는 점이다. 델파이 효과는 OS 커널만큼 복잡한 개발까지도 다룰 수 있는 것이다.

고맙게도 제프 덧키(Jeff Dutck) 는 리누스의 법칙을 “디버깅은 병렬처리가 가능하다” 는 말로 표현할 수 있음을 지적해 주었다. 제프는 디버거들이 디버깅을 하려면 의사소통을 조정해주는 개발자가 필요하지만 디버거들 사이에는 그다지 조정이 필요하지 않다고 진술한다. 따라서 개발자를 추가하는데서 생기는 기하급수적인 복잡성과 관리의 어려움이 디버깅에는 짐이 되지 않는다.

실제로 리눅스 세계에서는 디버거의 작업이 중복됨으로써 생기는 이론적인 효율의 저하가 거의 문제되었던 적이 없는 것으로 보인다. “빨리, 그리고 자주 발표하는 정책” 의 효과 중 하나는 피드백 되어오는 수정사항을 빨리 전파함으로써 중복이 최소화된다는 것이다. 브룩스(Brooks)는 제프의 진술과 관련하여 즉석에서 다음과 같은 말을 했다. “널리 사용되는 프로그램의 유지보수에 들어가는 비용은 보통 개발시 드는 비용의 40 퍼센트나 그 이상입니다. 놀랍게도 이 비용은 사용자의 수에 큰 영향을 받습니다. 더/많/은 사/용/자/들/이 더/많/은 버/그/들/을 찾/아/냅/니/다.” (필자의 강조) 사용자들이 많아지면 프로그램을 시험해보는 방법이 더 늘어나기 때문에 버그를 더 많이 잡아낼 수 있다. 이 효과는 사용자들이 공동개발자들일 때 더욱 커진다. 각 사람들이 버그를 찾아낼 때 조금씩 다른 개념의 집합과 분석 도구들을 사용하여 문제의 다른 각도에서 접근하기 때문이다. “델파이 효과” 는 바로 이런 편차에서 비롯되는 것으로 보인다. 또한 디버깅이라는 특정한 환경에서 이 편차는 노력의 중복을 줄여주는 경향이 있다.

따라서 더 많은 베타테스터를 가지는 것은 개/발/자/의 관점에서 현재의 “가장 심오한” 버그의 복잡성을 줄여주지는 않을 테지만, 누군가의 도구가 문제에 딱 들어맞아 그 버그가 그/사/람/에/게/는 쉽게 잡을 수 있는 것이 될 가능성을 높여준다. 리누스도 물론 할 일이 있었다. 심각한 버그가 있/을 경우에 대비해 리눅스 커널 버전은 잠재 사용자들이 최종적으로 “안정된” 버전을 사용할 수도 있고 새로운 기능을 사용하기 위해 최신의 버그가 있을 수 있는 버전을 사용할 수도 있게 번호가 붙여졌다. 이 전술은 아직까지 대부분의 리눅스 해커들이 따라하지는 않고 있지만 아마도 따라하게 될 것이다. 두 가지 선택이 가능하다는 사실이 양쪽 모두를 더 매력적으로 보이게 한다.

5. 장미가 장미다우려면

리누스의 행동을 연구하고 그것이 왜 성공적이었는지에 대한 이론을 만든 후, 나는 이 이론을 내 새로운 프로젝트 (물론 훨씬 덜 복잡하고 덜 야심적인 프로젝트) 에 적용해 보기로 했다.

그러나 내가 가장먼저 한 일은 popclient를 더 재조직화하고 단순화한 것이었다. 칼 해리스 (Carl Harris) 의 구현방식은 매우 건강한 것이었지만 많은 C 프로그래머들에게서 볼 수 있었던 것처럼 일종의 불필요한 복잡성을 보여주고 있었다. 그는 코드를 중심적인 것으로, 자료구조는 코드를 받쳐주는 것으로 취급했다. 그 결과 코드는 아름답지만 자료구조는 임시변통으로 설계되었고, 보기에 좋지 않았다. (최소한 옛 LISP 해커의 높은 기준에서 보자면 말이다) 그리고 코드와 자료구조를 개선하는 것 말고도 나는 또다른 목적을 하지고 있었다. popmail을 내가 완전히 이해하는 무엇인가로 진화시키고 싶었다.

이해하지 못하는 프로그램의 버그수정책임을 맡는 것은 괴로운 일이다. 처음 한달 정도가 지날 동안 나는 그저 칼의 기본적인 설계가 어떤 의미를 가지고 있는지 따라다니기만 했다. 내가 처음으로 중요한 수정을 가한 것은 IMAP 지원이었다. 프로토콜 머신을 일반적인 드라이버와 세가지 메소드 테이블 (POP2, POP3, IMAP을 지원하는) 로 재조직했다. 이것과 그 이전의 변경들은 프로그래머들이 기억해 둘만한 일반적인 원리를 보여준다. 특히 C 와 같이 즉흥적으로 프로그램하기 힘든 언어에서는.

9) 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다. (Smart data structures and dumb code works a lot better than the other way around)

브룩스의 책 9 장(Chapter 9) 에 이렇게 쓰여있다. “내게 [코드]를 보여주고 [자료구조]를 숨긴다면 나는 계속 어리둥절할 것이다. 자료구조를 보여준다면 코드는 볼 필요도 없이 뻔한 것이다.” 사실 브룩스는 “흐름도” 와 “테이블” 이라고 이야기했다. 하지만 30년간 변해온 용어들과 문화를 고려한다면 거의 똑같은 말이라고 할 수 있다.

이 시점에서 (1996년 9월 초, 일을 시작하고 6 주가 지난 후) 나는 이름을 바꿀 때가 되었다고 생각하기 시작했다. 이 프로그램은 더 이상 POP 클라이언트만이 아니었다. 하지만 설계상에 정말 새로운 것이 들어가 있지 않았기 때문에 머뭇거리고 있었다. 내가 만든 popclient 는 아직 스스로의 정체성을 확립하지 못하고 있었다.

fetchmail 이 어떻게 SMTP 포트로 가져온 메일을 포워드 시켜야 하는지 알고 난 후에는 상황이 급변할 것이었다. 잠시 후면 그렇게 될 것이 분명했다. 하지만 그보다 먼저, 앞서 나는 리누스 토발즈가 옳은 방법으로 일을 해냈다는 내 이론을 시험하기 위해 이 프로젝트를 수행하기로 했다고 말했다. 어떻게 시험을 했을까? 다음과 같은 방법을 사용했다.

(1) 일찍, 자주 발표했다. (발표간격이 10일을 넘는 경우는 거의 없었으며 개발에 몰두해 있을 때는 하루에 한번씩 발표했다)
(2) fetchmail 에 대한 일로 나와 접촉하는 사람은 누구든지 베타테스터 목록에 올렸다.
(3) 새로 발표할 때마다 베타테스터들에게 떠들썩하게 발표를 알리며 사람들이 참여하도록 격려했다.
(4) 그리고 그들의 이야기를 들었다. 설계 결정에 대해 투표를 하기도 했고 패치나 피드백을 보내올 때마다 베타테스터들을 구슬렀다.

이 단순한 방법들은 즉각 효력을 나타냈다. 프로젝트를 시작할 때부터 개발자들이라면 학수고대할 만한 버그 리포트를, 때로는 훌륭하게 수정된 코드를 받을 수 있었다. 사려깊은 비판과 팬 메일, 기능제안들을 받았다. 이것은

10) 베타테스터들을 가장 중요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어준다. (If you treat your beta-testers as if the’re your most valuable resource, they will respond by becoming your most valuable resource)

fetchmail 의 성공을 재는 재미있는 척도 중 하나는 프로젝트 베타테스터 메일링리스트인 fetchmail-friends 의 크기이다. fetchmail을 개발하고 있을 때 목록에는 249 명이 있었고 1주일에 2-3 명이 추가되었다. 1997 년 5월말 경에 수정을 했을 때 목록은 300명 가까이 되었고, 멤버들이 흥미로운 이유 때문에 조금씩 줄기 시작했다. 몇몇 사람들이 구독을 중단하면서 fetchmail 이 잘 작동하기 때문에 더 이상 메일링리스트를 보고 있을 이유가 없다고 말했다. 아마 이것이 성숙한 시장 스타일의 프로젝트가 가지는 일반적인 라이프사이클 중 하나일 것이다.

6. Popclient가 Fetchmail이 되다

fetchmail 프로젝트에서 큰 전환이 일어났던 것은 해리 호흐하이저(Harry Hochheiser) 가 클라이언트 머신의 SMTP 포트로 메일을 포워딩하는 대략적인 코드를 보내준 때였다. 보자마자 이 기능을 안정적으로 구현한다면 다른 모든 배달 방법은 구식이 되리라는 것을 깨달았다. 여러 주 동안 나는 fetchmail을 조금씩 뜯어고치고 있었는데, 인터페이스 설계가 작동하긴 하지만 지저분하다고 느끼고 있었다. 우아하지도 않고 몇 안되는 옵션들이 너무 여기저기 흩어져 있었다. 가져온 메일을 메일박스 파일에 부어놓을 것인지, 표준출력으로 내보낼 것인지 결정하는 옵션이 특히 골치거리였지만 왜 그런지 확실히 깨닫지는 못했다.

SMTP 포워딩을 생각하자 그동안 popclient 가 너무 많은 것을 해내려고 했다는 것을 알게 되었다. poopclient 는 MTA (Mail Transport Agent) 와 MDA (Mail Delivery Agent) 기능을 모두 가지도록 설계되었다. SMTP 포워딩만 할 수 있다면 MDA 기능을 없애 순수한 MTA 가 될 수 있었다. sendmail 과 마찬가지로 최종적인 메일 배달은 다른 프로그램에게 맡기면 되는 것이다.

TCP/IP를 지원하는 플랫폼이라면 거의 어디에나 25번 포트가 기다리고 있는데 무엇 때문에 복잡한 MDA 기능을 설정하거나 메일박스를 잠그고 덧붙이는 (lock-and-append) 문제를 가지고 고생을 하는가? 더구나 포워딩을 사용하면 가져온 메일이 평범한 SMTP 메일처럼 보일 것이고, 우리가 원하는 것이 바로 그것이었는데 말이다.

몇가지 배울 점이 있었다. 먼저, SMTP 포워딩에 대한 아이디어는 내가 리누스의 방법을 모방하려고 의식적으로 노력한 것에 대한 가장 큰 보답이었다. 사용자 한 명이 내게 끝내주는 아이디어를 주었다. 내가 해야했던 일은 그 의미를 이해하는 것 뿐이었다.

11) 좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다. (The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better )

흥미롭게도 만일 당신이 얼마나 다른사람에게 빚을 많이 지고 있는지를 자기비하라고 느껴질 정도로까지 솔직하게 털어놓는다면 대개의 사람들은 당신이 혼자서 거의 모든 일을 해내고서 천재성에 대해서 겸손해 하는 것처럼 대한다는 것을 곧바로 알게 될 것이다. 리누스의 경우를 보라! (1997년 8월, Perl 컨퍼런스에서 이 글을 발표할 때 래리 월이 첫 번째 줄에 앉아 있었다. 바로 윗 줄에 도달했을 때 그는 부흥사라도 된 것처럼 외쳤다. “형제여, 이야기 하시오, 이야기를!” 청중들 모두가 이것이 Perl을 만든 래리에게도 적용된다는 것을 알았기 때문에 웃음을 터뜨렸다)

똑같은 정신으로 프로젝트를 몇 주 진행해 나가자 나는 사용자들 뿐 아니라 이야기를 전해들은 다른 사람들로부터 비슷한 칭송을 받기 시작했다. 나는 그런 email 중 몇몇을 따로 보관해 두었다. 나중에 내 삶이 가치있는 것이었는지 의심스러워질 때 그 메일들을 다시 꺼내볼 생각이다. 🙂

모든 종류의 설계에 대해서 적용될 수 있는 두가지 더 기본적이며 비정치적인 교훈이 있다.

12) 종종 가장 충격적이고 혁신적인 해결책은 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못되어 있다는 것을 깨닫는 것에서 나온다. (Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong)

나는 popclient를 MTA/MDA 기능을 다 갖추고 복잡한 지역배달모드들까지 (local delivery modes) 갖춘 것으로 개발해 나가면서 틀린 문제를 풀려고 노력하고 있었다. fetchmail 의 설계는 가장 기초적인 것부터 재고하여 SMTP 포트로 메일을 배달하는 인터넷 메일 경로의 한 부분인 순수 MTA 가 되어야 했다. 개발도중에 벽에 부딪친다면 – 다음번 패치 후에 무엇을 해야 할 지 모르겠다면 – 그때는 정답을 가지고 있는지 생각할 것이 아니라 질문이 올바른 것인지 의문을 가져보아야 하는 경우가 종종 있다. 아마도 문제의 틀을 다시 잡아야 할 것이다.

그래서, 나도 내 문제의 틀을 다시 잡았다. 분명히 제대로 일을 진행하려면 (1) SMTP 포워딩 지원 기능을 일반 드라이버에 포함시키고, (2) SMTP 포워딩을 기본모드로 만들고 (3) 최종적으로는 다른 배달모드들, 특히 ‘파일로 배달하기’ 와 ‘표준출력으로 배달하기’를 제거해야 했다.

나는 단계 (3)에서 조금 머뭇거렸는데, 이유는 오랫동안 popclient를 써오면서 다른 배달모드에 의존하고 있을 사용자들의 심기를 불편하게 만들고 싶지 않았기 때문이다. 이론적으로는 그들 모두 즉시 .forward 파일이나 sendmail 외의 비슷한 프로그램으로 전환하여 동일한 결과를 얻을 수 있었다. 실제로는 전환 자체가 큰 일이 될 것이었다.

하지만 단계 (3)을 실행하고 나자 이점이 매우 큰 것으로 나타났다. 드라이버 코드 중 가장 힘든 부분이 사라졌다. 설정이 엄청나게 간단해졌다 – 시스템의 MDA 와 사용자의 메일박스를 찾아다니며 굽실거릴 필요도 없어졌고, OS 가 파일 잠금을 지원하는지 걱정할 필요도 없어졌다.

게다가 메일을 잃어버릴 한가지 가능성도 사라졌다. ‘파일로 배달하기’를 선택했을 때 디스크가 꽉 차 있으면 메일이 사라져 버렸던 것이다. SMTP 포워딩에서는 SMTP 리스너가 메시지 배달이 가능하거나 나중에 대발할 수 있도록 스풀해 놓기 전에는 OK를 돌려주지 않을 것이기 때문에 이런 일이 일어날 수가 없다.

성능도 향상되었다(한두번 실행시켜서는 느끼지 못하겠지만). 변경에 따르는 그다지 중요하지않은 이익이라면 매뉴얼 페이지가 훨씬 간단해 졌다는 것이다. 나중에 나는 사용자가 지정한 지역 MDA를 통해 배달하는 기능을 다시 넣어야 했다. 동적인 SLIP를 포함하여 몇몇 애매한 상황을 다루어야 했기 때문이다. 하지만 처음보다 훨씬 간단한 방법을 찾아낼 수 있었다.

교훈이라면?낡아서 사용할 수 없는 기능이라면 효율을 떨어뜨리지 않고 할 수 있을 때는 망설이지 말고 제거해 버리라. 앙뜨완 드 생떽쥐뻬리는 (아동서적 작가였으며 남는 시간에는 비행기 조종과 설계를 했던) 이렇게 말했다.

13) “(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. (Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away)”

코드가 더 나아지고 간단해 지고 있을 때가 바로 일이 제대로 되어가고 있다는 것을 “알게 되는” 때다. 그리고 그 과정에서 fetchmail 의 설계는 조상격인 popclient 와 다른, 자신만의 정체성을 획득했다. 이름을 바꿀 때가 된 것이다. 새로운 설계는 예전의 popclient 보다는 sendmail 과 비슷해 보였다. 둘다 MTA 였으나 sendmail 은 푸시(push) 후에 메일을 배달했고 새로운 Popclient 는 풀(pull) 후에 메일을 배달했다. 해서 두 달 후에 나는 Popclient 의 이름을 fetchmail 로 변경했다.

7. Fetchmail 의 성장

이제는 깔끔하고 혁신적인 설계, 매일 사용하므로 잘 작동하는 것을 알고 있는 코드, 발전하고 있는 베타테스터의 목록을 가지고 있었다. 더이상 내가 하고 있는 일이 몇몇의 사람에게 유용할 수도 있는 사소하고 개인적인 해킹은 아니라는 생각이 서서히 들기 시작했다. 내가 가지고 있는 것은 유닉스 박스와 SLIP/PPP 메일 연결을 가지고 있는 모든 해커들이 정말로 필요로 하는 프로그램이었다.

SMTP 포워딩 기능으로 fetchmail 은 경쟁에서 멀찍이 앞서나와 “카테고리 킬러,” 그러니까 해당분야의 다른 프로그램들은 아예 잊혀져 버릴 만한 경쟁력을 갖추고 자신의 지위를 확고하게 하는 고전적인 프로그램이 될 수 있는 능력을 갖추었다.

이런 결과를 계획하거나 목표로 가질 수는 없으리라고 생각한다. 아주 강력한 설계상의 아이디어로 그런 결과가 불가피하고, 자연스러우며 운명적인 것으로 보이게 함으로써 그런 결과에 도달해야 한다. 그런 아이디어를 구체화해 볼 수 있는 유일한 방법은 수많은 아이디어를 가지는 것이다. 아니면 다른 사람들의 좋은 아이디어를, 원래 생각되었던 것보다 더 멀리 이끌고 가서 구체화 시켜보는 방법이다.

앤드류 타넨바움 (Andrew Tanenbaum) 은 교습도구로 사용하기 위해 386용으로 간단한 네이티브 유닉스를 만들려는 원래의 아이디어를 가지고 있었다. 리누스 토발즈는 이 미닉스의 개념을 앤드류가 생각했던 것보다 더 멀리 밀고 나갔다. 그래서 리눅스는 굉장한 것이 되었다. 똑같은 방식으로 (더 작은 스케일이었지만) 나는 칼 해리스와 해리 호흐하이저의 아이디어들을 가져와 강하게 밀어붙였다. 리누스나 나나 사람들이 천재들이 그러하리라고 생각하는 낭만적인 의미에서 ‘독창적’ 인 것은 아니었다. 하지만 통념과는 반대로 대부분의 과학과 공학과 소프트웨어 개발은 독창적인 천재, 해커의 전설에 의해서 이루어지지 않는다.

결과물은 똑같이 매우 사람을 흥분시키는 것들이다 — 사실, 모든 해커들은 이런 종류의 성공을 얻기 위해 살아간다! 거기에는 내가 기준을 더 높이 잡아야 한다는 의미도 들어있다. fetchmail을 최상의 것으로 만들기 위해 나는 내자신의 필요뿐 아니라 나와는 상관없지만 다른 사람들에게는 필수적인 기능을 포함시키고 지원해야했다. 게다가 프로그램을 단순하고 튼튼하게 유지시키면서 그런 일을 해야 했다.

이것을 깨닫고 나서 내가 추가한 매우 중요한 첫 번째 기능은 멀티드롭(multidrop) 기능이었다. 그룹이나 사용자들의 메일을 한꺼번에 가지고 있는 메일박스에서 메일을 가져와 각 메일들을 개인 수신자에게 라우트(route) 시켜주는 기능이었다.

멀티드롭 기능을 추가하기로 한 데는 몇몇 사용자들이 원한다는 것도 있었지만 가장 큰 이유는 어드레싱을 완전히 구현함으로써 싱글드롭 코드에 있는 버그들을 잡아낼 수 있으리라고 생각했기 때문이다. 그리고 그렇게 되었다. RFC822(http://www.internic.net/rfc/rfc822.txt) 의 파싱을 제대로 구현하는 것에 매우 오랜 시간이 걸렸는데, 각각의 조각이 어려웠기 때문이 아니라 각각이 서로 의존하고 있으며 세심하게 신경을 써야 하는 사항들이었기 때문이다. 하지만 멀티드롭 어드레싱 역시 매우 훌륭한 설계상의 결정이었던 것으로 드러났다. 다음과 같은 교훈을 얻을 수 있었다.

14) 어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만 정말 위대한 도구는 사용자가 전혀 기대하지 않았던 용도에 알맞게 된다. (Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected)

미처 생각하지 못했던 멀티드롭 fetchmail 의 용도는 메일링리스트를 그대로 유지한 채, 알리아스 확장이 된 채로 SLIP/PPP로 연결된 클/라/이/언/트 쪽에서 메일링리스트를 운영하는 것이었다. 개인의 컴퓨터로 ISP 계정을 통해 접속하는 사람이 ISP 의 알리아스 파일에 지속적으로 접근하지 않고도 메일링리스트를 운영할 수 있다는 것을 의미한다.

베타테스터들이 요구한 중요한 변경사항중 또 하나는 8비트 MIME 오퍼레이션이었다. 이것은 내가 코드를 8비트에 대비하여 계속 유지시켜왔기 때문에 매우 쉬운 일이었다. 이런 기능에 대한 요구를 미리 예측해서 그랬던 것은 아니다. 다음과 같은 규칙을 따르려고 해서였다.

15) 어떤 종류든 게이트웨이 소프트웨어를 만들려고 한다면 데이터스트림에 가능한 한 최소한의 조작만 가하라 — 그리고 수신자가 강제로 하게 하지 않는다면 정보를 *절대로* 잘라버리지 말라. (… the data stream as little as possible — and *never* throw away informtion unless the recipient forces you to!)

이 규칙을 따르지 않았다면 8비트 MIME 지원은 매우 어려웠을 것이며 많은 버그를 만들어 냈으리라. 규칙을 따랐기 때문에 내가 해야 할 일은 RFC 1652 (http://www.internit.net/rfc/rfc1652.txt)를 읽고 헤더생성 로직을 약간 수정하는 것 뿐이었다.

유럽의 몇몇 사용자들은 한 세션에서 가져올 수 있는 메시지의 수를 제한하도록 옵션을 추가해달라고 요구해왔다. (전화 네트워크의 비싼 비용을 조절할 수 있도록 해달라는 말이다) 오랫동안 여기에 저항했고, 아직도 완전히 수긍하지 못했다. 하지만 세계를 상대로 프로그램을 만든다면 고객들의 소리에 귀를 기울여야 한다 — 그들이 돈을 지불하지 않는다고 해도 마찬가지다.

8. Fetchmail에서 배울 점

일반적인 소프트웨어공학의 주제로 돌아가기 전에 fetchmail 의 경험으로부터 배울 점이 몇 가지 더 있다. rc 파일의 구문은 선택사항으로 ‘noise’ 라는 키워드를 포함하는데 이것은 파서에 의해 무시된다. rc 파일에서 허용하는 영어와 비슷한 구문은 잘라낼 것을 모두 잘라낸 후에 얻는 전통적이고 간명한 키워드-밸류 짝에 비해 훨씬 알아보기 쉽다.

이것은 내가 rc 파일의 선언들이 명령형 소언어 (imperative minilanguage)를 얼마나 많이 닮아가기 시작했는지 알아차리고 나서 한밤중의 실험으로 시작되었다. (popclient 의 ‘server’ 라는 키워드를 ‘poll’ 로 바꾼 이유도 이것이다)

명령형 소언어를 더 영어처럼 만들면 사용하기 쉬울 것으로 보였다. 지금은 내가 비록 Emacs 나 HTML, 그리고 많은 데이터베이스 엔진에서 볼 수 있듯이 설계를 할 때 “언어처럼 만드는” 파의 일원이긴 하지만 “영어와 비슷한” 구분을 가지는 것에 대해서는 그다지 달가와 하지 않는다.

전통적인 프로그래머들은 정확하고 짧으며 중복을 허용하지 않는 제어구문을 선호하는 경향이 있다. 이것은 컴퓨팅 자원이 비싸서 파싱하는 단계가 최대한 싸고 간단해야 했을 때부터 내려온 문화적 유산이다. 영어는 대략 50% 정도의 중복을 허용하므로 대단히 부적절한 모델인 것으로 보인다.

이것이 내가 영어와 비슷한 구문을 보통 피하는 이유는 아니다. 이 문제를 언급한 이유는 그런 관습을 없애기 위해서다. 사이클과 코어의 값이 싸졌는데도 간명함은 저절로 없어지지는 않았다. 최근에는 언어가 컴퓨터의 관점에서 싼 가격이라는 점 보다는 사람에게 편리한가 하는 점이 더 중요하다.

물론 조심해야 할 충분한 이유는 있다. 한가지는 파싱하는 단계의 복잡성에 대한 비용이다 — 파싱하는 단계를 버그가 우글거리는 데다가 사용자로 하여금 그 자체만으로 혼란을 일으키게 만들고 싶지는 않을 것이다. 또 하나의 이유는 언어의 구문을 영어와 비슷하게 만들려고 노력하면 그 “영어” 가 심각하게 왜곡되어 자연어와의 피상적인 유사점이 전통적인 구문만큼이나 혼란스럽게 되는 경우가 많다는 점이다. (소위 “4세대” 언어와 상업용 데이터베이스 질의어에서 이런 경우를 많이 볼 수 있다)

fetchmail 제어구문은 이런 문제를 피하려고 했다. 언어의 영역이 매우 제한되어 있었기 때문이다. 일반적인 목적의 언어와는 거리가 멀었다. 언어가 표현하는 것이 별로 복잡하지 않았기 때문에 영어의 일부분에서 실제 제어언어로 옮겨가는데 혼란을 일으킬 가능성이 적었다. 더 넓은 의미의 교훈을 여기에서 얻었다.

16) 언어가 튜링-컴플리트하지 않다면 구문상의 유연성이 필요하다. (When your language is nowhere near Turing-complete, syntactic sugar can be your friend)

또하나의 교훈은 불투명함에 의한 보안에 대해서이다. fetchmail 의 사용자 중에는 스누퍼들이 우연히 패스워드를 보지 못하도록 rc 파일에 있는 패스워드를 암호화하여 가지고 있게 하자고 이야기하는 사람들이 있었다.

나는 그 이야기를 받아들이지 않았는데, 그렇게 한다고 해서 보안이 강화되는 것이 아니기 때문이다. rc 파일의 읽기 퍼미션을 얻은 사람이라면 사용자와 마찬가지로 fetchmail을 실행시킬 수도 있는 것이다 — 그리고 그들이 패스워드를 원하는 것이라면 패스워드를 얻기 위해 fetchmail 코드에서 디코딩하는 코드를 뽑아낼 수도 있다.

fetchmail 의 패스워드를 암호화 했다면 사람들은 그리 심각하게 생각하지도 않고 보안에 대해 잘못된 관념을 가지게 되었을 것이다. 여기서 알 수 있는 일반적인 규칙은 다음과 같다.

17) 보안시스템은 그것이 보호하려고 하는 비밀만큼만 안전하다. 가짜 비밀들에 주의할 것. (A security system is only as secure as its secret. Beware of pseudo-secrets)

9. 시장 스타일의 개발에 필요한 선행조건들

이 글을 초기에 검토해준 사람들과 시험적으로 청중이 되었던 사람들은 계속해서 성공적인 시장 스타일의 개발을 위한 선행조건이 무엇인지 물었다. 여기에는 공동개발자의 공동체를 만들기 위해 프로젝트가 공개되는 시점에 리더의 자질과 코드가 어떤 상태인지가 포함된다.

아예 처음부터 시장스타일로 개발할 수 없다는 것은 자명하다. 테스트, 디버그, 그리고 개선은 시장 스타일로 할 수 있다. 하지만 프로젝트를 시/작/할/때/ 시장 스타일로 시작하기는 매우 어렵다. 리누스는 그렇게 하지 않았다. 나도 마찬가지. 개발자들의 공동체는 초기에 실행시키면서 테스트할 수 있는 장난감이 필요하다.

공동체를 만들기 시작할 때 제시할 수 있어야 하는 것은 그럴듯한 장래성이다. 프로그램이 특별히 잘 작동할 필요는 없다. 조잡하거나, 버그투성이여도 되고, 완성되지 않고 문서가 형편없어도 상관없다. 하지만 한가지 확실하게 해야할 것은 잠재적인 공동개발자들에게 이것이 머지 않은 미래에 정말 괜찮은 무언가로 진화할 수 있다는 것을 납득시키는 일이다.

리눅스와 fetchmail 둘 다 강력하고 매력적인 기본설계를 가지고 공개되었다. 내가 시장모델에 대해 이야기하자 많은 사람들이 이것을 중요하다고 생각했고, 높은 수준의 설계에 대한 직관과 영리함이 프로젝트의 리더에게는 필수적인 것이라고 지레짐작으로 결론을 내려버렸다.

하지만 리누스는 그의 설계를 유닉스에서 따왔고 나는 기본적으로 popclient에서 가져왔다. (물론 나중에 많은 것이 바뀌긴 했지만 리눅스는 그보다 훨씬 더 바뀌었다). 그렇다면 시장스타일의 리더/조정자에게 정말 특별한 설계의 재능이 필요한 것일까, 아니면 다른 사람들이 가진 설계의 재능을 이끌어 내는 것이 필요한 것일까?

나는 조정자가 특별하게 영리해서 독창적인 설계를 만들어낼 수 있는지의 여부가 중요하다고 생각하지 않는다. 하지만 조정자가 다/른/사/람/의 좋/은/ 설/계/를 알/아/볼 수 있는지는 절대적으로 중요하다.

리눅스와 fetchmail 프로젝트는 이에 대한 증거를 보여주고 있다. 리누스는 (앞서 논했듯이) 대단히 독창적인 설계자라고는 할 수 없으나 좋은 설계를 알아보는 대단한 요령을 보여주었고, 그것을 리눅스 커널에 통합해 넣었다. 앞서 fetchmail에서 가장 강력한 설계상의 아이디어 하나 (SMTP 포워딩) 가 다른 누군가로부터 온 것이라고 설명한 바 있다.

이 글의 초기 청중들은 내가 설계상의 독창성을 과소평가하는데 내가 그런 독창성을 가지고 있기 때문에 당연한 일로 생각한다고 주장하며 내게 경의를 표시했다. 어느 정도는 사실이다. 설계는 분명히 (코딩이나 디버깅에 비해서) 내가 가장 잘하는 일이다.

하지만 소프트웨어 설계에 있어서 똑똑하고 독창적이라는 것의 문제점은 그게 버릇이 되어버린다는 점이다 — 설계를 강력하고 단순하게 유지해야 할 때 그렇게 하지 않고 계속해서 일을 멋지고 복잡하게 만들기 시작한다. 이전의 프로젝트에서 나는 그런 성향 때문에 실패한 적이 있었다. fetchmail 에서는 간신히 그것을 이겨냈다.

그래서 나는 fetchmail에서

Embedded 참고 사이트

임베디드 리눅스 관련 사이트 목록

목차

1부. 임베디드 시스템과 리눅스

1장. 임베디드 시스템

2장. 리눅스

3장. 임베디드 리눅스

4장. 실시간 운영체제

5장. 윈도우 시스템

2부. 임베디드 리눅스 개발 방법론

6장. 제품 기획 단계에서 고려할 사항

7장. 타겟 보드 선정 방법

8장. 장치 선정과 드라이버 구현

9장. 임베디드 리눅스 이식 절차

10장. 임베디드 리눅스 환경에서 응용 프로그램 개발 절차

11장. 개발 후 상용 제품을 위한 패키징

3부. 리눅스 개발 환경 구축과 이식

12장. 교차 개발 환경 구축

13장. 네트워크와 디버깅 환경 구축

14장. 부트 스트랩 로더 이식

15장. 리눅스 커널 환경 설정과 컴파일

16장. 루트 파일시스템 구축

17장. 실시간 리눅스 커널 이식

18장. 윈도우 시스템 환경 이식

19장. 부팅과 설치 확인

20장. 상용 제품을 위한 패키징

1부. 임베디드 시스템과 리눅스

1장. 임베디드 시스템

□ 『C, C++로 작성하는 임베디드 시스템 프로그래밍』, 마이클 바 저, 이석주 역, 한빛미디어, 2000

C 와 C++ 프로그래밍 언어를 사용하여 임베디드 시스템을 제작하는 방법을 기술하고 있다. 아쉽게도 이 책에 나오는 보드를 국내에서 구하기가 어렵기 때문에 본격적인 실습이 불가능하다는 단점이 있다. 하지만 임베디드 시스템에 대한 개념을 단기간에 잡기에는 적당하다.

□ 『네트워크 프린팅』, 토드 레이더마커, 매튜 개스트 저, 박재호, 이영미 역, 한빛미디어, 2001

리눅스와 유닉스를 서버로, 윈도우, 맥, 넷웨어를 클라이언트로 구성한 네트워크 환경에서 인쇄하는 방법을 기술한다. BOOTP, DHCP와 같은 네트워크 프로토콜을 사용해 프린터를 부팅하는 방법도 소개한다.

http://wombat.doc.ic.ac.uk/foldoc/index.html

FOLDOC 컴퓨터 용어 전문 사전이다.

■ http://www.linuxdevices.com/articles/AT4936596231.html

임베디드 리눅스를 탑재하고 있는 임베디드 장치를 소개하는 페이지이다. PDA를 제외한 여러 장치를 종류별로 제시하고 있다.

■ http://www.linuxdevices.com/articles/AT8728350077.html

임베디드 리눅스를 탑재했거나 탑재할 수 있는 PDA를 소개하는 페이지이다.

■ http://www.linuxdevices.com/articles/AT4313418436.html
임베디드 리눅스를 탑재할 수 있는 SOC(System-On-Chip)을 소개하는 페이지이다.

■ http://www.classicgaming.com/
고전 게임을 소개하는 페이지이다. MSX와 애플을 비롯한 각종 플랫폼을 흉내낸 애뮬레이터와 게임용 롬 이미지를 다운로드할 수 있다.

■ http://quest.arc.nasa.gov/mars/ask/about-mars-path/pathfinder_computer.txt
패스파인더에 탑재한 컴퓨터 사양을 설명하는 기사이다.

■ http://quest.arc.nasa.gov/mars/ask/about-mars-path/Assembly_language_programming_used_in_Pathfinder.txt
패스파인더 개발을 위해 사용한 어셈블리어에 대해 설명하는 기사이다.

■ http://quest.arc.nasa.gov/mars/ask/about-mars-path/Selection_of_programming_languages.txt
패스파인더 개발을 위해 사용한 프로그래밍 언어 선택과 관련한 기사이다.

■ http://www.windriver.com/customer/html/jpl.html
VxWorks를 만든 윈드리버에서 만든 제트추진연구소에 대한 기사이다.

■ http://www.iews.na.baesystems.com/space/pdf/0887.pdf
패스파인더에 탑재한 마이크로프로세서를 소개하는 기사이다.

목차

2장. 리눅스

□ 『리눅스 그냥 재미로: 우연한 혁명에 대한 이야기』, 리누스 토발즈, 데이비드 다이아몬드 저, 안진환 역, 한겨례신문사, 2001

리 누스 토발즈가 집필한 리눅스에 대한 일종의 자서전으로 리눅스 개발의 이면에 숨겨진 배경 이야기를 허심탄회하게 풀어내고 있다. 예상과는 달리 내용이 따분하지 않고 재미있기 때문에(제목을 한번 보라!) 언제 어디서나 부담 없이 읽을 수 있는 책이다.

□ 『Operating System Concepts 6th edition』, A. Silberschatz, J. Peterson, P. Galvin, John Wiley & Sons, 2001
일명 ‘공룡책’이라고 불리며 운영체제에 대한 일반 내용을 다루는 기본서이다. 운영체제라는 세계에 첫 걸음을 내딛도록 도와준다. 대학교에서 운영체제 과목 교과서로 많이 사용하고 있으며, 대학 3학년 이상 학생이 읽기에 적합하다.

□ 『리눅스 커널의 이해』, 다니엘 보베이, 마르코 체사티 저, 이 호, 심마로 역, 한빛미디어, 2001
오라일리 『Understanding the Linux Kerne』의 번역판이다. 리눅스 커널 내부를 탐험하고 싶은 사람에게 등불이 될 책으로 리눅스나 유닉스 운영체제에 대해 중급 이상의 지식을 확보한 개발자에게 적합하다.

□ 『러닝 리눅스 3판』, 매트 웰시, 라 카우프만, 칼레 딜하이머 저, 이만용 역, 한빛미디어, 2001

오 라일리 『Running Linux 3rd Edition』의 번역판이다. 리눅스를 처음 접하는 독자가 고민하면서 읽을 가치가 있는 ‘정보를 위한 정보를 담은 메타북(meta-book)’으로 리눅스라는 운영체제에 철학적으로 접근하는 구성 방식이 돋보인다. 운영체제를 전혀 모르는 완전 초보자에게는 다소 어려울 수도 있다.

□ 『오픈 소스』에릭 레이몬드 외 저, 송창훈 외 역, 한빛미디어, 2000
오 라일리 『Open Source: Voice from the Open Source Revolutions』의 번역판이다. 공개 소스와 관련한 여러 선구자들이 수필식으로 적은 글을 묶어놓은 책으로 리눅스를 비롯한 공개 소스 소프트웨어가 어떤 식으로 발전해왔으며 앞으로 어떻게 발전할지 전반적인 구도를 제시한다.

□ 『Operating Systems: Design and Implementation』 Andrew S. Tanenbaum, Prentice-Hall, 1987
타 넨바움 교수가 지은 MINIX 운영체제를 소개하는 책이다. 리누스도 이 책을 접합 후부터 스스로 운영체제를 만들 생각을 했다니까, 실제 운영체제가 어떻게 돌아가는지 구체적인 동작 원리에 관심있는 독자는 한 번씩 읽어보면 도움이 될 것이다.

■ http://www.linuxhq.com/
리눅스 커널에 대한 각종 정보를 체계적으로 정리한 본부 사이트이다. 각 커널 버전에 따라 무엇이 어떻게 변했으며, 패치가 어떻게 이뤄지는지 잘 정리하고 있다.

■ http://www.kernel.org
리눅스 커널을 배포하는 공식 사이트이다. 과거부터 현재까지 모든 리눅스 커널을 유지하고 있으므로, 이 사이트에 들러 필요한 버전을 가져오기 바란다.

■ http://www.livinginternet.com/?i/iw_unix_linux.htm
리눅스 역사를 간략하게 기술하는 사이트이다. 간결하면서도 있어야 하는 내용은 모두 자리잡고 있다.

■ http://www.li.org/linuxhistory.php
리누스 토발즈가 유즈넷(USENET)에 올린 글을 토대로 초창기 리눅스 역사를 재조명하는 사이트이다.

■ http://www.memalpha.cx/Linux/Kernel/
리눅스 커널 버전과 관련한 역사를 한눈에 살펴볼 수 있다. 각 버전별로 리눅스 커널이 정확하게 몇 월 몇 일 몇 시에 나왔는지 궁금하면 이 사이트를 방문해보기 바란다.

■ http://lwn.net/2001/features/Timeline/
2001년 한해동안 리눅스와 관련한 각종 사건을 월 단위로 정리하고 있다. 아쉽게도 1998년부터 추적할 수 있다. 연도별 시간띠를 보면서 과거에 어떤 일이 있었는지 기억을 한번 더듬어보기 바란다.

■ http://www.nwfusion.com/newsletters/linux/2001/01086735.html
아마존이 리눅스를 웹서버로 채택했다는 소식을 담은 기사이다.

■ http://www.computer.org/computer/homepage/0202/ec/
리눅스가 헐리우드에서 맹활약하는 사례를 제시하고 있다. 블록버스터 영화에서 리눅스를 어떻게 사용하는지 실례를 들어 설명하고 있다.

■ http://www.fsf.org
자유 소프트웨어 재단 홈페이지이다. GNU 프로젝트에 대한 여러 가지 내용을 담고 있다.

■ http://www.fsf.org/software/software.html
GNU에서 개발한 GPL과 LGPL을 따르는 각종 소프트웨어 목록과 기타 공개 소스 소프트웨어 목록을 제공하고 있다. 그냥 심심풀이로 훑어보기만 해도 리눅스에 얼마만큼 많은 응용 프로그램이 존재하는지 확인할 수 있다.

■ http://www.pcmag.com/article/0,2997,ss%253D1490%2526s%253D25068%2526a%253D17930,00.asp
리누스 오른팔인 알란 콕스가 커널 2.4 유지 보수를 더 이상 맡지 않는다는 기사를 담은 페이지이다.

■ http://www.marcelothewonderpenguin.com/
알란 콕스 뒤를 이은 새로운 커널 2.4 유지보수 펭귄(maintainer)인 마르첼로(Marcelo Wormsbecker Tosatti)의 신상정보를 담은 페이지이다.

■ http://www.linuxdoc.org/
리눅스 문서 프로젝트(LDP, Linux Document Project)와 관련한 결과 문서를 제공하는 홈페이지이다. 리눅스와 관련한 HOW-TO, FAQ를 위시하여 도움이 될만한 각종 문서를 체계적으로 제공한다.

■ http://www.kldp.org
리눅스 한글 문서 프로젝트 홈페이지이다. 리눅스 관련 각종 번역 문서와 창작 문서를 분류별/주제별로 제공한다. 또한 팁 게시판과 사용기도 정리해놓았다.

■ http://kldp.org/root/cathedral-bazaar/cathedral-bazaar.html#toc10
에릭 레이먼드씨가 작성한 시장과 성당을 번역한 글이다. 이 글이 인터넷에 오른 이후부터 공개 소스 소프트웨어 운동이 한층 활기를 띄게 된다.

■ http://www-903.ibm.com/developerworks/kr/index.html
IBM에서 운영하는 리눅스 개발 사이트(developerWorks 한글판)로서 리눅스와 관련한 여러 유용한 정보를 제공한다.

■ http://safari.informit.com/mainhom.asp?home
InformIT 에서 운영하는 사파리 서비스 홈페이지이다. 사파리 서비스는 구매에 앞서 책 내용을 온라인으로 검색할 수 있도록 지원하는 서비스이다. 아쉽게도 유료이다. 사파리 멤버 중 하나인 오라일리 출판사 홈페이지에서도 바로 사파리 서비스에 접근할 수 있다.

■ http://www.google.com/grphp?hl=en
유 즈넷 기사를 검색할 수 있는 구글(Google) 검색엔진 홈페이지이다. 구글에 앞서 이러한 서비스를 제공하던 데자뉴스(deja.com)시절부터 현재까지 엄청난 분량의 기사를 담고 있다. ISP에서 제공하는 뉴스그룹 서비스에 불만을 품고 있다면 반드시 한번 사용해보기 바란다.

목차

3장. 실시간 운영체제

□ 『리눅스 커널의 이해』, 다니엘 보베이, 마르코 체사티 저, 이 호, 심마로 역, 한빛미디어, 2001
오라일리 『Understanding the Linux Kernel』의 번역판이다. 리눅스 커널 내부를 탐험하고 싶은 사람에게 등불이 되어줄 책으로 리눅스나 유닉스 운영체제에 대해 중급 이상 지식을 확보한 개발자에게 적합하다.

□ 『러닝 리눅스 3판』, 매트 웰시, 라 카우프만, 칼레 딜하이머 저, 이만용 역, 한빛미디어, 2001

오 라일리 『Running Linux 3rd Edition』의 번역판이다. 리눅스를 처음 접하는 독자가 고민하면서 읽을 가치가 있는 ‘정보를 위한 정보를 담은 메타북(meta-book)’으로 리눅스라는 운영체제에 철학적으로 접근하는 구성 방식이 돋보인다. 운영체제를 전혀 모르는 완전 초보자에게는 다소 어려울 수도 있다.

□ 『오픈 소스』, 에릭 레이몬드 외 저, 송창훈 외 역, 한빛미디어, 2000
오 라일리 『Open Source: Voice from the Open Source Revolutions』의 번역판이다. 공개 소스와 관련한 여러 선구자가 에세이 형식으로 적은 글을 묶은 책으로 리눅스를 비롯한 공개 소스 소프트웨어가 어떤 식으로 발전해왔으며 앞으로 어떻게 발전할지 전반적인 구도를 제시한다.

□ 『Embedded Linux』, John Lombardo, New Riders, 2002

x86 플랫폼에서 리눅스를 최소한으로 패키징하는 방법을 기술한다. 아주 뛰어나거나 새로운 내용은 담고 있지 않지만, x86에서 임베디드 리눅스를 재미로 탑재해보려는 초보자에게는 도움을 줄 수 있다.

■ http://www.linuxdevices.com/articles/AT9888936014.html
임베디드 리눅스와 관련한 요약 가이드를 제공하는 기사이다. 여러 가지 읽을 거리에 대한 링크를 제공한다.

■ http://www.linuxdevices.com/articles/AT3620938516.html
임베디드 리눅스를 위한 요구 사항을 분석한 기사이다. PDA와 같은 특정 분야에 치우치지 않고 전반적인 흐름을 잘 짚고 있다.

■ http://www.linuxdevices.com/articles/AT9202043619.html
임베디드 리눅스에서 동작하는 여러 윈도우 시스템을 소개하는 기사이다. 윈도우 시스템을 공개 소스와 상용 제품으로 나누어 정리하였다.

■ http://www.linuxdevices.com/articles/AT2760742655.html
다양한 임베디드 리눅스 배포판을 소개한 기사이다. 공개 소스와 상업적 지원 배포판의 특징과 URL을 간략하게 정리하고 있다.

■ http://www.linuxdevices.com/files/article011/index.html
임베디드 리눅스에 대한 현재 상태(시장 상황, 향후 전망)를 제시한 기사이다. 다양한 도표와 그래프를 통해 통계 자료를 제공하므로 전략적인 결정에 참고하기 바란다.

■ http://www-903.ibm.com/developerworks/kr/linux/library/l-emb.html?dwzone=linux
리눅스가 임베디드 시장을 석권할 수 있는 이유를 제시한 기사이다.

■ http://www-903.ibm.com/developerworks/kr/linux/library/l-embl.html?dwzone=linux
임베디드 리눅스 애플리케이션에 대한 개요를 소개하는 기사이다. 임베디드 리눅스와 관련한 기본 사항을 잘 요약하고 있다.

■ http://www.uclinux.org/
임베디드 리눅스 마이크로 컨트롤러 프로젝트이다. MMU 없는 CPU에서 동작하는 리눅스에 대한 이식 작업 성과를 볼 수 있다.

■ http://www.linux-mtd.infradead.org/
리눅스를 위한 MTD(Memory Technology Device) 서브 시스템과 관련있는 각종 사항을 정리한 홈페이지이다.

■ http://www.microsoft.com/Windows/embedded/xp/evaluation/compare/notlinux.asp
임베디드 환경에서 동작하는 윈도우계열 운영체제와 리눅스계열 운영체제를 비교한 자료이다. 마이크로소프트사에서 작성했으므로 윈도우계열에 높은 점수를 주고 있다.

■ http://www.lineo.com/news_events/announcements/2001/12.20.html
마이크로소프트사에서 발표한 임베디드 윈도우 계열 운영체제와 임베디드 리눅스 계열 운영체제 비교 문건을 반박하는 내용을 담고 있다.

■ http://www.lynuxworks.com/products/whitepapers/xp-vs-linux.php3
임베디드 환경에서 동작하는 윈도우계열과 리눅스계열 운영체제를 비교한 자료이다. 리눅스웍스에서 작성했으므로 리눅스계열에 높은 점수를 주고 있다.

목차

4장. 실시간 운영체제

□ 『Operating System Concepts 6th edition』, A. Silberschatz, J. Peterson, P. Galvin, John Wiley & Sons 2001
일명 ‘공룡책’이라 불리며 운영체제에 대한 일반 내용을 다루는 기본서이다. 운영체제라는 세계에 첫 걸음을 내딛도록 도와준다. 대학에서 운영체제 과목 교재로 많이 사용하며, 대학교 3학년 이상이 읽기에 적합하다.

□ 『리눅스 커널의 이해』, 다니엘 보베이, 마르코 체사티 저, 이 호, 심마로 역, 한빛미디어 2001년
오라일리 『Understanding the Linux Kernel』의 번역판이다. 리눅스 커널 내부를 탐험하고 싶은 사람에게 등불이 되는 책으로 리눅스나 유닉스 운영체제에 대해 중급 이상의 지식을 확보한 개발자가 읽기에 적합하다.

□ 『The Design of the UNIX Operating System』, Maurice J. Bach, PTR/PH 1990
유닉스 운영체제 설계 사상을 담고 있는 가장 기본적인 바이블이다. 유닉스 내부 구조를 꿰뚫어야 할 필요성이 있다면 이 책부터 시작하기 바란다. 대학교 4학년 이상이 읽기에 적합하다.

□ 『UNIX Internals: The New Frontiers』, Uresh Vahalia, Prentice Hall 1996
앞 서 『The Design of the UNIX Operating System』이 유닉스 내부 구조에 대한 바이블이라면 이 책은 다양한 유닉스 변종에 대한 주해서로 볼 수 있다. 명쾌한 설명과 풍부한 예제는 이 책을 손에서 떼기 어렵게 만든다. 대학교 4학년 이상이 읽기에 적합하다.

■ http://dictionary.cambridge.org/
캠브리지 온라인 사전이다.

■ http://wombat.doc.ic.ac.uk/foldoc/index.html
FOLDOC 컴퓨터 용어 전문 사전이다.

■ http://research.microsoft.com/~mbj/Mars_Pathfinder/Authoritative_Account.html
화성 탐사선인 패스파인더가 문제를 일으켰던 원인과 해결책을 설명한 글이다.

■ http://qdn.qnx.com/articles/dec1200/realtime.html
실시간과 실시간 운영체제에 대한 기본 소개가 나온 글이다.

■ http://www.faqs.org/faqs/realtime-computing/faq/
실시간에 대해 자주 나오는 각종 질문을 정리한 FAQ를 제공한다.

■ http://www.linuxdevices.com/files/elecjun00/yodaiken/yodaiken.pdf
FSMLabs에서 개발한 RTLinux에 대한 발표 자료이다. 하드 실시간을 리눅스에서 어떻게 구현했는지 설계 사상이 잘 나타나 있다.

■ http://fsmlabs.com/community/
FSMLabs에서 지원하는 RTLinux 커뮤니티 사이트이다. 설치 방법, FAQ, 백서와 같은 자료가 있다.

■ http://www.aero.polimi.it/projects/rtai/
리니오에서 지원하는 RTAI 커뮤니티 사이트이다. 설치 방법, FAQ, 백서와 같은 자료가 있다.

■ http://www.mvista.com/realtime/
몬타비스타에서 개발한 실시간 리눅스 커널 패치에 대한 홈페이지이다. 실시간 리눅스 커널 패치와 관련한 여러 자료가 있다.

■ http://www.mech.kuleuven.ac.be/~bruyninc/rthowto/rtHOWTO/rtHOWTO.html
실시간과 임베디드에 대한 How-to 문서로써, 기본 내용을 간결하면서도 체계적으로 정리하고 있다.

■ http://www.wired.com/news/print/0,1294,13987,00.html
윈도우 NT를 탑재한 미해군 USS 요크타운호가 두 시간 동안 바다에서 표류할 수 밖에 없었던 원인을 분석한 기사이다.

■ http://www.pasc.org/
포직스 표준을 제정하는 PASC(Portable Application Standards Committee) 홈페이지로, 포직스에 대한 정보도 얻을 수 있다.

■ http://www.delphion.com/details?pn=US05995745__
FSMLabs에서 출원한 RTLinux 관련 특허를 설명하는 페이지이다. 세부 내용을 모두 보려면 subscription이 필요하다.

목차

5장. 윈도우 시스템

□ 『러닝 리눅스 3판』, 매트 웰시, 라 카우프만, 칼레 딜하이머 저, 이만용 역, 한빛미디어, 2001

오 라일리 『Running Linux 3rd Edition』의 번역판이다. 리눅스를 처음 접하는 독자가 고민하면서 읽을 가치가 있는 ‘정보를 위한 정보를 담은 메타북(meta-book)’으로 리눅스라는 운영체제에 철학적으로 접근하는 구성 방식이 돋보인다. 운영체제를 전혀 모르는 완전 초보자에게는 다소 어려울 수도 있다.

□ 『Introduction to the X Window System』, Oliver Jones, Prentice-Hall, 1989
X 윈도우에 대한 고전적인 입문서이다. 1989년에 나왔기 때문에 편집 스타일은 상당히 볼품없지만 내용 자체만 놓고 보면 아주 훌륭하다. 페졸드가 지은 마이크로소프트 윈도우 프로그래밍 입문서와 비견할 만하다.

□ 『X Window System 2nd Edition』, Robert W. Scheifler & James Gettys, Digital Press, 1990
X를 만든 아버지인 세이플러와 게티스가 지은 X 윈도우 시스템에 대한 바이블이다. 최신 버전에 대한 내용은 X 윈도우 패키지 내부에서 온라인 문서 형식으로 찾을 수 있다.

□ 『The X Toolkit Cookbook』, Paul E. Kimball, PTR/PH, 1995
현재 나와있는 X 윈도우 툴킷 책 중에 가장 정리가 잘되어있으며, 숨겨진 몇몇 비밀을 명쾌하게 해설하고 있다. 모티프나 아데나 위젯을 사용하는 개발자라면 누구나 한번 정도 이 책을 읽을 필요가 있다.

□ 『Volume 1: Xlib Programming Manual』, Adrian Nye, O’Reilly, 1992
오늘날의 오라일리가 존재하도록 만든 초기 역작이다. X 환경에서 프로그램을 작성하는 방법에 대해 간결 명료하게 설명하고 있다.

■ http://wombat.doc.ic.ac.uk/foldoc/index.html
FOLDOC 컴퓨터 용어 전문 사전이다.

■ http://www.linuxdevices.com/articles/AT9202043619.html
임베디드 리눅스에서 사용하는 여러 공개/상용 윈도우 시스템을 소개하는 기사이다. 윈도우 시스템을 상당히 체계적으로 정리하고 있으므로 특히 첫 단추를 꿰는 개발자에게 적당하다.

■ http://www.linuxdevices.com/articles/AT9035650492.html
임베디드 리눅스에서 X 윈도를 적용함에 있어 고려할 여러 사항을 소개하는 발표 자료이다. 다른 기사와는 달리 상당히 정량적인 방법으로 접근하고 있으므로, 비교 자료로 사용하기에 부족함이 없다.

■ http://www.linuxdevices.com/links/LK4761626139.html
마이크로 윈도우 프로젝트에 대해 간략하게 소개하는 기사이다.

■ http://www.linuxdevices.com/links/LK7730481424.html
피코구이 프로젝트에 대해 간략하게 소개하는 기사이다.

■ http://www.xfree86.org
x86, MacOS, 기타 임베디드 시스템에서 동작하는 공개소스 X 윈도우 환경을 개발하기 위해 설립한 XFree86 프로젝트 홈페이지이다. XFree86 소프트웨어를 자유롭게 다운로드할 수 있다.

■ http://www.x.org
X 컨소시움 후속인 오픈 그룹 홈페이지이다. X 윈도우 시스템 원본 소스와 각종 응용 프로그램을 자유롭게 다운로드할 수 있다.

■ http://www.rahul.net/kenton/xsites.framed.html
필자가 본 인터넷에서 가장 뛰어난 X 윈도우와 모티프 정리 사이트이다. 그야말로 주옥 같은 자료들이 실려있으므로, X 윈도나 모티프 개발자라면 필요할 때마다 이 사이트에 들러서 필요한 정보를 얻기 바란다.

■ http://www.openmotif.org/
공개용 모티프 툴킷을 다운로드할 수 있는 홈페이지이다. 이 페이지는 현재 BX라는 사용자 인터페이스 생성도구로 유명한 ICS 사에서 관리하고 있다.

■ http://www.opengroup.org/openmotif/
오픈 그룹에서 관리하는 오픈 모티프 공식 홈페이지이다. 공개용 모티프 툴킷 최신 버전을 다운로드할 수 있으며, 모티프 개발자를 위한 공간도 마련하고 있다. 임베디드 모티프에 대한 정보도 찾을 수 있다.

■ http://www.motifdeveloper.com/news/news12.html
오라일리의 모티프 프로그래밍 매뉴얼과 레퍼런스 매뉴얼을 온라인 문서로 받아볼 수 있도록 지원하는 홈페이지이다.

■ http://www.lesstif.org/
모 티프를 자유롭게 쓸 목적으로 시작한 레스티프 프로젝트 홈페이지이다. 레스티프는 라이센스에 제한이 있는 공개용 모티프와는 달리 LGPL 라이센스를 따르므로 완벽한 공개 소스 소프트웨어이다. 레스티프는 모티프와 원시 코드 단계에서 거의 99% 호환성을 유지하므로, 각종 공개 소스 소프트웨어 개발자가 즐겨 사용하는 라이브러리이기도 하다.

■ http://www.gtk.org/
Gtk+ 공식 홈페이지이다. 다양한 프로젝트에 걸친 여러 자료를 얻을 수 있으며 최신 버전 라이브러리를 다운로드할 수도 있다.

■ http://www.efalk.org/Widgets/
X에서 사용할 수 있는 각종 위젯 집합을 비교한 기사이다. 다양한 위젯 집합을 기능과 외양면에서 분석하고 있으므로, 개발에 필요한 툴킷을 선택할 때 참조하기 바란다.

■ http://www.microwindows.org/
마이크로 윈도우 공식 홈페이지이다. 원시 코드를 다운로드할 수 있으며, 각종 매뉴얼과 학습서도 얻을 수 있다.

■ http://www.fltk.org
X11, 마이크로소프트 윈도우, 마이크로 윈도우에서 쓸 수 있는 FLTK 프로젝트 공식 홈페이지이다.

■ http://tinywidgets.sourceforge.net/
마이크로 윈도우에서 쓸 수 있는 타이니 위젯 프로젝트 공식 홈페이지이다.

■ http://www.trolltech.com/
Qt와 Qt/임베디드를 만든 트롤테크 홈페이지이다.

■ http://pgui.sourceforge.net/
피코구이 공식 홈페이지이다. 각종 기사와 문서를 얻을 수 있으며, 피코구이 패키지도 다운로드할 수 있다.

목차

2부. 임베디드 리눅스 개발 방법론

6장. 제품 기획 단계에서 고려할 사항

□ 『C∙C++로 작성하는 임베디드 시스템 프로그래밍』, 마이클 바 저, 이석주 역, 한빛미디어, 2000
C 와 C++ 프로그래밍 언어를 사용해 임베디드 시스템을 제작하는 방법을 기술한다. 아쉽게도 이 책에 나오는 보드를 국내에서 구하기 어려워 본격적인 실습이 불가능하다. 하지만 임베디드 시스템에 대한 개념을 단기간에 잡기에는 적당하다.

□ 『Embedded Linux』, John Lombardo, New Riders, 2002

x86 플랫폼에서 리눅스를 최소한으로 패키징하는 방법을 기술한다. 아주 뛰어나거나 새로운 내용은 담고 있지 않지만, x86에서 임베디드 리눅스를 재미로 탑재해보려는 초보자에게는 도움을 줄 수 있다.

7장. 타겟 보드 선정 방법

□ 『C, C++로 작성하는 임베디드 시스템 프로그래밍』, 마이클 바 저, 이석주 역, 한빛미디어, 2000

C 와 C++ 프로그래밍 언어를 사용하여 임베디드 시스템을 제작하는 방법을 기술하고 있다. 아쉽게도 이 책에 나오는 보드를 국내에서 구하기가 어렵기 때문에 본격적인 실습이 불가능하다는 단점이 있다. 하지만 임베디드 시스템에 대한 개념을 단기간에 잡기에는 적당하다.

□ SWAN-II 사용자 설명서

아이트로닉스(제품에 포함)

■ http://www.linuxdevices.com/articles/AT4548672342.html
포스트-PC 시대를 도래해 임베디드 리눅스를 동작시킬 수 있는 SOC에 대해 소개하는 홈페이지이다.

■ http://www.linuxdevices.com/articles/AT4313418436.html
리눅스를 적용할 수 있는 각종 SOC(System On Chip)에 대한 정보를 모아놓은 홈페이지이다. ARM, MIPS, MPC, x86을 기반으로 각종 제품을 소개한다.

■ http://www.uclinux.org/
MMU가 없는 CPU를 위한 리눅스인 uClinux 공식 홈페이지이다.

■ http://www.advantech.com/products/PCM-5824.asp
어드밴텍에서 만든 Geode 기반 SBC(Single Board Computer)인 PCM-5824에 대한 각종 자료를 제공한다.

■ http://www.national.com/appinfo/solutions/0,2062,239,00.html
네셔날 세미컨덕터에서 만든 SOC인 Geode에 대한 각종 자료를 제공한다.

■ http://www.linuxdevices.com/products/PD7399900675.html
인텔에서 만든 SA-1110 마이크로프로세스 개발 참조 보드에 대한 간략한 정보를 제공한다.

■ http://developer.intel.com/design/pca/applicationsprocessors/manuals/index.htm
인텔에서 만든 각종 마이크로프로세스에 대한 문서를 모아놓은 홈페이지이다.

■ http://developer.intel.com/design/strong/datashts/278241.htm
인텔에서 만든 SA-1110 마이크로 프로세스에 대한 간략한 데이터시트를 제공하는 홈페이지이다.

■ http://developer.intel.com/design/strong/guides/278278.htm
인텔에서 만든 SA-1110 마이크로 프로세스 개발 참조 보드인 아사벳에 대한 각종 자료를 제공하는 홈페이지이다.

■ http://www.linfos.co.kr/htm/pro_li01.htm
린포스에서 만든 SA-1110 마이크로 프로세스 개발 참조 보드인 TBEL1110에 대한 각종 자료를 제공하는 홈페이지이다.

■ http://developer.intel.com/design/intelxscale/
인텔에서 개발한 StrongARM 후속 버전인 XScale에 대한 공식 홈페이지이다.

■ http://www.ipaqlinux.com/
StrongARM을 탑재한 PDA인 iPAQ에 리눅스를 탑재하는 데 필요한 정보와 링크를 모아놓은 홈페이지이다.

■ http://www.handhelds.org/
StrongARM을 탑재한 PDA인 iPAQ을 위한 리눅스 배포판과 설치 노하우를 모아놓은 홈페이지이다.

■ http://www.arm.com/
가장 널리 사용하는 32비트 RISC 방식 임베디드 CPU를 설계한 ARM 본사 홈페이지이다.

■ http://www.itronixit.co.kr/products_cpu_swan2.html
아이트로닉스에서 만든 MPC860 기반 SBC(Single Board Computer)인 SWAN-II에 대한 각종 자료를 제공하는 홈페이지이다.

■ http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MPC860&nodeId=01M0ypBDKCb
모토로라에서 만든 파워PC 계열 SOC인 MPC860에 대한 각종 자료를 제공한다.

■ http://e-www.motorola.com/brdata/PDFDB/docs/MPC860EC.pdf
MPC860에 대한 상세 정보를 제공하는 PDF 파일이다.

■ http://e-www.motorola.com/webapp/sps/site/taxonomy.jsp?nodeId=01M0ypBDKCb
모토로라에서 파워PC 코어 기반으로 만든 MPC8xx 계열 CPU에 대한 비교 정보를 제공한다.

■ http://penguinppc.org/embedded/
파워PC를 채택한 임베디드 시스템을 위한 각종 자료를 제공한다.

■ http://www.macraigor.com/zenofbdm.pdf
BDM에 대한 멋진 소개서이다. BDM에 대한 역사와 간략한 디버깅 방법을 기술하고 있다.

■ [통계] http://www.linuxdevices.com/files/article011/sld023.html
임베디드 개발자가 향후 채택하리라 예상되는 CPU 비율을 보여주는 자료이다.

■ [통계] http://www.linuxdevices.com/files/article011/sld024.html
임베디드 개발자가 향후 채택하리라 예상되는 하드웨어 플랫폼 비율을 보여주는 자료이다.

■ [통계] http://www.linuxdevices.com/files/article011/sld025.html
임베디드 개발자가 향후 채택하리라 예상되는 주변 장치를 보여주는 자료이다.

■ [통계] http://www.linuxdevices.com/files/article011/sld026.html
임베디드 개발자가 향후 채택하리라 예상되는 운영체제를 올리기 위해 사용하는 장치를 보여주는 자료이다.

목차

8장. 장치 선정과 드라이버 구현

□ 『리눅스 장치 드라이버』, 알렉산드로 루비니 저, 김인성/류태중 역, 한빛미디어, 2000

리눅스에서 장치 드라이버를 제작하는지 방법을 구체적으로 소개한다. 리눅스 커널에 대해 어느 정도 지식이 있어야 하므로 초보자가 읽기에는 적합하지 않다. 단점은 커널 2.2에 대해서 다룬다는 점이다.

□ 『Linux Device Driver 2nd Ed』, Alessandro Rubini, O’Reilly, 2001
『리눅스 장치 드라이버』 원서 2판으로 커널 2.4를 다룬다. 인쇄 버전은 물론이고 일부 발췌가 아닌 완벽한 온라인 버전까지 나와 있으므로 큰 부담 없이 읽을 수 있다.

□ 『네트워크 프린팅』, 토드 레이더마커, 매튜 개스트 저, 박재호, 이영미 역, 한빛미디어, 2001

리눅스와 유닉스를 서버로, 윈도우, 맥, 넷웨어를 클라이언트로 구성한 네트워크 환경에서 인쇄하는 방법을 기술한다. BOOTP, DHCP와 같은 네트워크 프로토콜을 사용해 프린터를 부팅하는 방법도 소개한다.

□ 리눅스 커널 내부 /Documentation/devices.txt
리눅스에서 제공하는 각종 장치에 대한 간략한 소개와 장치 번호를 정의한 문서이다. 리눅스에서 장치 드라이버를 사용하거나 만들기 위해 반드시 참조해야 하는 표준 문서이다.

■ http://lhd.datapower.com/
리눅스에서 사용할 수 있는 각종 하드웨어 데이터베이스를 제공하는 홈페이지이다. 제품 이름이나 제품 카테고리로 검색할 수 있다.

■ http://www.tldp.org/HOWTO/Hardware-HOWTO/
리눅스 하드웨어 호환성과 관련한 HOW-TO 문서이다. 다양한 주변 장치에 대한 호환성 여부를 알려준다. 제품 이름이나 카테고리를 통한 검색은 불가능하며, 목차에서 찾아 들어가기 바란다.

■ http://www.tldp.org/HOWTO/HOWTO-INDEX/hardware.html
리눅스에서 사용할 수 있는 하드웨어에 대한 HOW-TO를 집대성한 색인을 제공하는 홈페이지이다.

■ http://www.torque.net/linux-pp.html
리눅스에서 사용할 수 있는 외장 주변 장치(PC와 병렬 포트로 통신)에 대한 링크와 제품 목록을 제공하는 홈페이지이다.

■ http://www.redhat.com/support/hardware/
가장 대표적인 배포판 회사인 레드햇을 위한 리눅스 호환 하드웨어 목록을 제공하는 홈페이지이다. 다양한 방법(제조사/카테고리/하드웨어 클래스/배포판 종류/인증 상태)으로 하드웨어를 검색할 수 있다.

■ http://www.linuxhardware.net/
리눅스 관련 각종 하드웨어와 장치 드라이버를 검색할 수 있도록 데이터베이스를 제공하는 홈페이지이다. 일반 사용자 참여로 데이터베이스를 갱신하고 있다는 사실이 흥미롭다.

■ http://www.linux-usb.org/
리눅스에 탑재한 USB 스택에 대한 정보를 제공하는 홈페이지이다. FAQ와 유용한 링크를 담고 있다.

■ ftp://ftp.compaq.com/pub/supportinformation/papers/ecg0480997_a4.pdf
OHCI와 UHCI 차이점을 설명한 문서이다. 상당히 깔끔하게 정리되어 있으므로, USB에 대한 개념을 잡는 데 도움을 받을 수 있다.

■ http://usb.cs.tum.edu/usbdoc/
리눅스에서 USB 장치 드라이버를 작성하는 방법을 설명하는 홈페이지이다.

■ http://whatis.techtarget.com/definition/0,,sid9_gci537791,00.html
I2C에 대한 사전적인 정의를 소개하는 홈페이지이다.

■ http://www.connectworld.net/cable-length.html

직렬/병렬/스카시 포트에 연결할 수 있는 케이블 길이 제한에 대해 소개하는 홈페이지이다.

■ http://www.pcisig.com/news_room/faqs
다양한 PCI 규약에 대한 질문과 응답을 싣고 있는 홈페이지이다.

■ http://pcmcia-cs.sourceforge.net/
리눅스에서 PCMCIA를 사용하는 데 필요한 각종 정보를 제공하는 홈페이지이다. 리눅스에서 PCMCIA 장치를 사용하고 싶다면 여기를 먼저 방문하기 바란다.

■ http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-PROG.html
리눅스에서 PCMCIA용 장치 드라이버를 개발하는 데 도움을 주는 프로그래머 가이드이다.

■ http://linux1394.sourceforge.net/hcl.php
리눅스에서 사용할 수 있는 IEEE 1394(파이어와이어) 주변 장치 목록을 제공하는 홈페이지이다.

■ http://www.skipstone.com/wizard.html
IEEE 1394와 관련한 FAQ 모음집이다.

■ http://irda.sourceforge.net/
리눅스에서 IrDA용 장치 드라이버를 설치하고 사용하는 데 도움이 되는 정보를 제공하는 홈페이지이다.

■ http://mobilix.org/ir_misc.html
리눅스에서 사용할 수 있는 IrDA 주변 장치를 소개하는 홈페이지이다. 데이터베이스 검색은 불가능하며 전체 목록이 한꺼번에 나온다.

■ http://www.lirc.org
리눅스에서 IrDA로 여러 주변 장치를 제어할 수 있는 패키지를 소개하는 홈페이지이다.

■ http://delbert.matlock.com/linux-bluetooth.htm#howto
리눅스에서 블루투스를 사용하는데 필요한 각종 정보를 제공하는 홈페이지이다. 다양한 드라이버와 문서를 싣고 있으므로 블루투스에 관심이 많은 개발자라면 반드시 여기를 방문하기 바란다.

■ http://www.microsoft.com/hwdev/bus/1394/1394tech.asp
마이크로소프트사에서 만든 IEEE1394 관련 특장점을 설명하는 홈페이지이다. 윈도우 관련 내용이 많이 있지만, 일반적인 특성을 파악하는 데 큰 무리가 없을 것이다.

■ http://www.linux-mtd.infradead.org/
리눅스를 위한 MTD(Memory Technology Device) 서브 시스템과 관련있는 각종 사항을 정리한 홈페이지이다.

목차

9장. 임베디드 리눅스 이식 절차

□ 『Embedded Linux: Hardware, Software, and Interfacing』, Dr. Craig Hollabaugh, Addison-Wesley, 2002

임베디드 리눅스에 대해 체계적으로 잘 구성된 책이다. 절반 이상이 인터페이스하는 방법에 대한 소개이므로, 일정 수준 이상의 개발자가 보기에 적당하다.

□ 『삼바 활용하기』, 로버트 에크슈타인, 데이비드 칼리어-브라운, 피터 켈리 저, 박재호/이영미 역, 한빛미디어, 2001
리 눅스나 유닉스 환경에서 네트워크로 윈도우 클라이언트에 공유 파일과 프린팅 서비스를 해주는 소프트웨어인 삼바를 소개한다. 삼바를 사용하면 네트워크로 물린 이기종 컴퓨터 사이에 자원을 쉽게 공유할 수 있으므로, 윈도우쪽으로 기울어진 개발 환경을 리눅스쪽으로 돌리는 데 도움을 줄 수 있다.

□ 『네트워크 프린팅』, 토드 레이더마커, 매튜 개스트 저, 박재호, 이영미 역, 한빛미디어, 2001

리눅스와 유닉스를 서버로, 윈도우, 맥, 넷웨어를 클라이언트로 구성한 네트워크 환경에서 인쇄하는 방법을 기술한다. BOOTP, DHCP와 같은 네트워크 프로토콜을 사용해 프린터를 부팅하는 방법도 소개한다.

□ 『러닝 리눅스 3판』, 매트 웰시, 라 카우프만, 칼레 딜하이머 저, 이만용 역, 한빛미디어, 2001

오 라일리 『Running Linux 3rd Edition』의 번역판이다. 리눅스를 처음 접하는 독자가 고민하면서 읽을 가치가 있는 ‘정보를 위한 정보를 담은 메타북(meta-book)’으로 리눅스라는 운영체제에 철학적으로 접근하는 구성 방식이 돋보인다. 운영체제를 전혀 모르는 완전 초보자에게는 다소 어려울 수도 있다.

□ 『Embedded Linux』, John Lombardo, New Riders, 2002

x86 플랫폼에서 리눅스를 최소한으로 패키징하는 방법을 기술한다. 아주 뛰어나거나 새로운 내용은 담고 있지 않지만, x86에서 임베디드 리눅스를 재미로 탑재해보려는 초보자에게는 도움을 줄 수 있다.

□ 『GNU 소프트웨어로 프로그래밍 하기』, 마이크 루키디스, 앤디 오람 저, 이기동 역, 한빛미디어, 2000

오 라일리 『Programming with GNU Software』의 번역판이다. 문서 편집기인 이맥스, C/C++ 컴파일러인 gcc, 디버거인 gdb, 컴파일 자동화 도구인 make, 소스 관리 시스템인 RCS에 대해 입문하는 병아리 개발자에게 안내자 구실을 한다. 아쉽게도 중급 개발자에게는 부적합하다.

■ http://www.aleph1.co.uk/armlinux/devboards/Assabet-HOWTO/t1.html
아사벳에 임베디드 리눅스를 이식하는 절차를 일목요연하게 정리한 HOW-TO 문서이다. 아사벳에 임베디드 리눅스를 이식해야 한다면 꼭 살펴보기 바란다.

■ http://www-2.cs.cmu.edu/~wearable/software/assabet.html
역 시 아사벳에 임베디드 리눅스를 이식하기 위해 필요한 자료를 모아놓은 홈페이지이다. 각종 링크가 이식 순서에 맞춰 잘 나와있으므로 이식 과정에서 필요한 소프트웨어를 구할 경우에 많은 도움을 받을 수 있다. 다른 홈페이지에 비해 최신 버전으로 갱신하는 속도이 빠르다는 장점이 있다.

■ http://www-2.cs.cmu.edu/~wearable/software/docs/assabet-linux-report/intel-report.html
인 텔 아사벳 참조 보드에 ARM 리눅스를 올리는 방법을 체계적으로 기술한 기술 보고서이다. 미국립 과학재단에서 발주하고 미국 카네기 멜론 대학교의 웨어러블(Wearable) 그룹에서 수행한 프로젝트 결과 보고를 위해 만든 문서이다.

■ http://www.aleph1.co.uk/armlinux/thebook.html
다 양한 ARM 임베디드 시스템에 임베디드 리눅스를 이식하는 방법을 소개하는 온라인 책이다. 원래 StrongARM을 사용한 참조 보드인 LART를 위해 만든 책이지만, 아사벳에 대해서도 충분히 참조할만한 가치가 있는 내용을 담고 있다.

■ http://penguinppc.org/embedded/howto/PowerPC-Embedded-HOWTO.html
MPC 플랫폼을 위한 교차 개발 환경 구축 방법, PPCBOOT 설치와 사용법, 부팅에 필요한 각종 설정, 패키징 관련 내용을 체계적으로 소개하는 문서이다.

■ http://developer.intel.com/design/strong/applnots/sa1100lx/sa1100lx.htm
인텔에서 만든 자료로, 아사벳을 위한 교차 참조 개발 환경을 구축하는 방법을 소개한다.

■ http://sources.redhat.com/binutils/
GNU binutils에 대한 홈페이지이다. 들어있는 프로그램과 각 프로그램 구실을 간략하게 설명한다.

■ http://www.astonlinux.com/
윈도우 환경에서 임베디드 리눅스를 개발할 수 있게 지원하는 툴인 코드메이커 개발사 홈페이지이다.

■ http://www.linux.org/docs/ldp/howto/Glibc2-HOWTO.html
glibc 버전 2를 리눅스 시스템에 설치하고 활용하는 방법/하는 HOW-TO 문서이다.

■ http://www.linuxdoc.org/HOWTO/mini/Partition/
리눅스에서 스왑 영역을 잡는 방법을 친절하게 설명하는 HOW-TO 문서이다.

■ http://kldp.org/HOWTO/html/Kernel/Kernel-HOWTO.html
리눅스에서 커널 환경을 설정하고 컴파일하는 방법을 설명하는 HOW-TO 문서이다. 2.2.x 계열 설명이므로 시대에 조금 뒤떨어졌다고 생각할 수도 있으나 기본 사항을 충분히 잘 설명하고 있다.

■ http://kldp.org/KoreanDoc/html/2.4Kernel_Compile-KLDP/2.4Kernel_Compile-KLDP.html

리눅스 커널 2.4를 환경 설정하고 컴파일하는 방법을 소개하는 HOW-TO 문서이다.

■ http://kldp.org/KoreanDoc/html/Kernel_Compile_Guide-KLDP/Kernel_Compile_Guide-KLDP.html
리눅스 커널을 컴파일하는 기본 절차를 소개하는 문서이다. 역시 커널 2.2 계열이라서 조금 낡았다는 느낌이 들지만 전반적인 감을 잡기에는 부족함이 없다.

■ http://option.kernel.pe.kr/
리눅스 커널 환경 설정 도움말을 한글로 이식하는 프로젝트를 위한 홈페이지이다. 최신 커널 버전을 꾸준히 쫓아오고 있으므로, 리눅스 커널을 설정하다 지쳐버린 사람들에게 많은 도움을 줄 수 있으리라 확신한다.

■ http://kldp.org/HOWTO/mini/html/LILO/LILO.html
실례를 들어 리눅스 표준 부트 스트랩 로더인 LILO를 어떻게 설정하는지 설명하고 있는 문서이다.

■ http://penguinppc.org/embedded/cross-compiling/
MPC용 교차 개발 환경 컴파일 방법이다. 잘못된 내용이 들어있기 때문에, 단순히 참고용으로만 활용하기 바란다

■ http://www.armlinux.org/docs/toolchain/toolchHOWTO/x183.html
ARM용 교차 개발 환경 컴파일 방법이다. 조금 잘못된 내용이 들어있기 때문에, 단순히 참고용으로만 활용하기 바란다.

■ http://www.delorie.com/gnu/docs/glibc/libc_toc.html
GNU에서 개발한 기본 라이브러리인 glibc에 대한 온라인 북이다.

■ http://sources.redhat.com/newlib/
레드햇에서 만든 glibc를 대체할 경량 기본 라이브러리인 newlib에 대한 홈페이지이다.

■ http://www.uclibc.org/
임베디드 리눅스 시스템을 위한 경량 기본 라이브러리인 uclibc에 대한 홈페이지이다.

■ http://www.fefe.de/dietlibc/
크기에 신경을 써서 만든 기본 라이브러리인 diet libc에 대한 홈페이지이다.

■ http://www.embedded.com/story/OEG20011220S0058
경량 라이브러리인 newlib에 대해 소개하는 홈페이지이다.

■ http://www.netsonic.fi/~walker/minicom.html
유닉스에서 사용할 수 있는 직렬 통신을 지원하는 터미널 흉내내기 프로그램인 minicom 홈페이지이다.

■ http://www.tldp.org/HOWTO/mini/LILO.html
가장 널리 알려진 x86용 부트 스트랩 로더인 LILO를 설명하는 미니 HOW-TO이다. LILO 환경 설정과 주의 사항을 소개한다.

■ http://www.linuxgazette.com/issue64/kohli.html
강력한 x86용 부트 스트랩 로더인 GNU GRUB를 소개하는 홈페이지이다. GRUB이 무엇인지, 설치를 어떻게 하는지, 환경 설정을 어떻게 하는지 설명한다.

■ http://www.aleph1.co.uk/armlinux/docs/ARMbooting/t1.html
ARM에서 동작하는 각종 부트 스트랩 로더를 소개하는 온라인 기사이다.

■ http://armboot.sourceforge.net/
강력한 ARM와 StrongARM용 부트 스트랩 로더인 ARMBOOT에 대해 소개하는 홈페이지이다. 여기서 원시 코드를 다운로드할 수도 있고 간단한 설명도 읽을 수 있다.

■ http://sourceforge.net/projects/blob/
SA11x0(StrongARM)용 부트 스트랩 로더인 BLOB를 소개하는 홈페이지이다. 여기서 원시 코드를 다운로드할 수도 있고 간단한 설명도 읽을 수 있다.

■ http://www.handhelds.org/z/wiki/bootldr
컴팩에서 만든 StrongARM을 사용한 PDA인 iPAQ에서 동작하는 부트 스트랩 로더인 bootldr를소개하는 홈페이지이다.

■ http://www.wearablegroup.org/software/bootldr/
iPAQ용 부트 스트랩 로더인 bootldr을 간략하게 설명하는 홈페이지이다.

■ http://ppcboot.sourceforge.net/
임베디드 파워PC를 위한 부트 스트랩 로더인 PPCBOOT를 소개하는 홈페이지이다. 프로젝트 진행에 따른 변경 사항과 간략한 설명을 한눈에 확인할 수 있다.

■ http://www.redhat.com/embedded/technologies/redboot/
다중 플랫폼을 지원하는 강력한 부트 스트랩 로더인 REDBOOT를 소개하는 홈페이지이다. 레드햇답게 문서 정리를 깔끔하게 잘 해놓았다.

■ http://tinylogin.busybox.net/
경량급이면서도 필요한 기능을 모두 갖추고 있는 임베디드 리눅스에서 동작하는 로그인 프로그램인 tinylogin 홈페이지이다.

■ http://www.busybox.net/
GNU fileutils, shellutils에 들어있는 각종 프로그램을 하나로 묶어놓은 임베디드 리눅스를 위한 맥가이버 칼(스위스 군용 칼이 정확한 표현이지만 여기서는 편의상 맥가이버 칼로 지칭한다)인 busybox 홈페이지이다.

■ http://www.wearablegroup.org/software/ramdisk/
ARM(특히 아사벳)을 위한 램디스크를 제공하는 홈페이지이다.

■ ftp://ftp.denx.de/pub/LinuxPPC/usr/src/
MPC를 위한 램디스크를 제공하는 홈페이지이다.

■ http://kpreempt.sourceforge.net/
x86, 리눅스 커널 선점 확장 프로젝트 공식 홈페이지이다.

■ http://www.ittc.ku.edu/kurt/
또 다른 x86 리눅스 커널 선점 확장 프로젝트인 KURT 공식 홈페이지이다.

■ http://www.aero.polimi.it/~rtai/
RTAI 실시간 리눅스 확장 프로젝트 공식 홈페이지이다.

■ http://www.fsmlabs.com/community/
RTLinux 커뮤니티 공식 홈페이지이다.

■ http://www.linux-fbdev.org/
리눅스 프레임 버퍼, 프레임 버퍼 장치, 관련 사이트를 체계적으로 정리한 홈페이지이다.

■ http://gtf.org/garzik/video/
리눅스 비디오 드라이버와 프레임 버퍼에 대한 링크를 체계적으로 정리한 홈페이지이다.

■ http://www.tldp.org/HOWTO/Framebuffer-HOWTO.html
리눅스 프레임 버퍼 HOW-TO 문서로, 프레임 버퍼에 대한 일반론과 플랫폼별 특성을 소개한다.

■ http://www.microwindows.org/
마이크로 윈도우 공식 홈페이지이다. 원시 코드를 다운로드할 수 있으며, 각종 매뉴얼과 학습서도 구할 수 있다.

■ http://www.xfree86.org
x86, MacOS, 기타 임베디드 시스템에서 동작하는 공개 소스 X 윈도우 환경을 개발하기 위해 설립한 XFree86 프로젝트 홈페이지이다. XFree86 소프트웨어를 자유롭게 다운로드할 수 있다.

■ http://pgui.sourceforge.net/
피코구이 공식 홈페이지이다. 각종 기사와 문서를 얻을 수 있으며, 피코구이 패키지도 다운로드할 수 있다.

목차

10장. 임베디드 환경에서 응용 프로그램 개발 절차

□ 『Rapid Development: Taming Wild Software Schedules』, Steve McConnell, Microsoft Press 1996
소프트웨어를 짧은 시간 내 성공리에 개발하는 데 필요한 각종 지식을 총 집결시켜놓은 멋진 책이다. 이론뿐만 아니라 실전에 바로 써먹을 수 있는 내용으로 가득 하다. 관리자는 물론, 일반 개발자도 필독할 가치가 있는 책이다.

□ 『Software Project Survival Guide』, Steve McConnell, Microsoft Press, 1998
소프트웨어 개발 생명 주기 동안 벌어지는 각종 활동 내역을 위험 관리라는 측면에서 이끌어내는 방법을 명쾌하게 설명한다. “Rapid Development”와 더불어 관리자와 개발자가 꼭 읽어야 하는 필독서이다.

□ 『러닝 리눅스 3판』, 매트 웰시, 라 카우프만, 칼레 딜하이머 저, 이만용 역, 한빛미디어, 2001

오 라일리 『Running Linux 3rd Edition』의 번역판이다. 리눅스를 처음 접하는 독자가 고민하면서 읽을 가치가 있는 ‘정보를 위한 정보를 담은 메타북(meta-book)’으로 리눅스라는 운영체제에 철학적으로 접근하는 구성 방식이 돋보인다. 운영체제를 전혀 모르는 완전 초보자에게는 다소 어려울 수도 있다.

□ 『GNU 소프트웨어로 프로그래밍 하기』, 마이크 루키디스, 앤디 오람 저, 이기동 역, 한빛미디어, 2000

오 라일리 『Programming with GNU Software』의 번역판이다. 문서 편집기인 이맥스, C/C++ 컴파일러인 gcc, 디버거인 gdb, 컴파일 자동화 도구인 make, 소스 관리 시스템인 RCS에 대해 입문하는 병아리 개발자에게 안내자 구실을 한다. 아쉽게도 중급 개발자에게는 부적합하다.

□ 『The UNIX Programming Environment』, Brian Kernighan, Rob Pike, Prentice-Hall, 1984
고전 중의 고전인 이 책은 유닉스에서 프로그램을 개발하는 표준적인 방법론을 간략하면서도 짜임새 있게 다룬다.

□ 『Software Tools in Pascal』, Brian Kernighan, P Plauger, Addison-Wesley, 1981
『The UNIX Programming Environment』와 더불어 유닉스 프로그래밍 철학을 이해하는 데 중요한 책이다. C의 인기에 밀린 파스칼로 모든 코드를 소개하지만 중요한 것은 형식이 아니라 철학이라는 사실을 잊지 말자.

□ 『The Unix Network Programming』, W. Richard Stevens, Prentice-Hall, 1994
유닉스에서 네트워크 프로그램을 작성하려고 마음먹은 개발자 누구나 이 책을 읽을 필요가 있다. 더 이상의 설명이 필요없는 명작이다.

□ 『Advanced Programming in the UNIX Environment』, W. Richard Stevens, Addison-Wesley, 1992
유닉스 환경에서 시스템 프로그래밍을 하는 방법을 체계적이고 자세하게 다룬 책으로 “The Unix Network Programming”과 함께 읽으면 더욱 큰 효과를 얻을 수 있다.

□ 『유닉스 시스템 프로그래밍 SVR4』, 데이비드 커리 저, 이수진/이성희 역, 한빛미디어 , 2001
시 스템 V쪽에 치우쳐 설명하고 있지만, 유닉스 시스템 호출과 각종 라이브러리 저변에 깔린 기본 원리를 충실히 다루고 있으므로 시스템 V는 물론이고 리눅스와 BSD 계열을 사용하는 시스템 소프트웨어 개발자도 이 책을 반드시 읽어야 한다.

□ 『Programming for the real world: POSIX.4』, Bill O. Galleister, O’Reilly & Associates, 1995
실시간 프로그램을 위한 C 인터페이스인 POSIX.4에 대해 상세하게 다루는 책이다. 초보자가 보기에는 내용이 조금 어렵지만 본격적인 실시간 프로그램을 위해서는 반드시 읽고 넘어가야 한다.

□ 『Pthreads Programming』, Bradford Nichols, Dick Buttlar, Jacqueline Proulx Farrell, O’Reilly, 1996
포직스 스레드(Pthreads)에 대한 이론과 실전을 다루는 책으로 Pthreads로 프로그램을 작성하는 개발자는 반드시 읽어봐야 하는 필독서이다.

□ 『Practical UNIX Programming: A Guide to Concurrency, Communication, and Multithreading』, Kay A. Robbins, Steven Robbins, Prentice-Hall, 1996
실질적인 네트워크와 시스템 프로그래밍 작성 예제를 많이 제공하는 책이다. 포직스 스레드 프로그래밍과 동기화에 대한 내용도 들어있다.

□ 『배시 셸 시작하기』, 캐머런 뉴햄, 빌 로젠블랫 저, 배창렬 역, 한빛미디어, 2001
리눅스 표준 셸인 배시 셸에 대해 기초부터 차근차근 설명하는 책이다. 배시 셸은 이런저런 소프트웨어를 합치는 결합 언어(glue language)로 사용하기 적합하므로, 임베디드 시스템 개발자라도 알아두면 편리할 때가 많다.

■ http://pauillac.inria.fr/~xleroy/linuxthreads/
리눅스를 위한 포직스 1003.1c 스레드 패키지인 LinuxThreads에 대한 소개와 각종 링크를 제공하는 홈페이지이다.

■ http://www.cvshome.org/cyclic/cyclic-pages/rcs.html
RCS에 대해 소개하는 홈페이지이다. RCS와 관련한 각종 링크를 제공하므로 여기서 시작하면 된다.

■ http://www.cvshome.org/cyclic/cyclic-pages/sccs.html
SCCS에 대해 소개하는 홈페이지이다.

■ http://www.cvshome.org/
CVS(Concurrent Versions System) 관련 공식 홈페이지이다. CVS에 대한 매뉴얼과 소프트웨어를 다운로드할 수 있다.

■ http://www.wi.leidenuniv.nl/~wichert/strace/
리눅스에서 사용할 수 있는 시스템 호출 추적 툴인 strace 공식 홈페이지이다.

■ http://freshmeat.net/projects/ltrace/?topic_id=846%2C47
리눅스에서 사용할 수 있는 동적 라이브러리 호출 감시 툴인 ltrace 공식 홈페이지이다.

■ http://www.redhat.com/software/tools/gnupro/gnupro_gdb.html#gdb
gdb 기능에 대해 간략하게 소개하고 있는 레드햇사 홈페이지이다.

■ http://gcc.gnu.org/
gcc 공식 홈페이지이다. 필요한 각종 문서와 소프트웨어를 다운로드할 수 있다.

■ http://www.linuxgazette.com/issue71/joshi.html
gcc에서 최적화 작업을 수행하는 몇 가지 방법의 주요 원리를 설명하는 홈페이지이다.

■ http://www.cs.may.ie/~jpower/Courses/se209/optim/gcc_2.html
최적화를 위한 각종 gcc 옵션을 설명하는 홈페이지이다.

■ http://www.gnu.org/manual/gprof-2.9.1/html_node/gprof_toc.html
GNU 프로파일러인 gprof 에 대한 사용 설명서이다. 한글 번역판은 http://purple.icu.ac.kr/~kimkk/guide/gprof/gprof_toc.html를 참조하기 바란다.

■ http://www710.univ-lyon1.fr/~yperret/fnccheck/doc.html
gcc에서 사용할 수 있는 신형 프로파일러인 fncdump에 대한 소개 문서이다. 한글 번역판은 http://purple.icu.ac.kr/~kimkk/guide/functioncheck/#SEC_1를 참조하기 바란다.

■ http://www.redhat.com/software/gnupro/technical/gnupro_gcc.html

gcc 프로젝트를 이끌고 있는 레드햇사에서 개발한 상용 프로그램인 GNUPro 패키지에서 제공하는 최적화 기법을 소개하는 기사이다.

목차

11장. 개발 후 상용 제품을 위한 패키징

□ 『Embedded Linux: Hardware, Software, and Interfacing』, Dr. Craig Hollabaugh, Addison-Wesley, 2002

임베디드 리눅스에 대해 체계적으로 잘 구성된 책이다. 절반 이상이 인터페이스하는 방법에 대한 소개이므로, 일정 수준 이상의 개발자가 보기에 적당하다.

□ 『Embedded Linux Devleopment: Building Embedded Linux Systems(MPC8xx)』, 교육자료, Adelinux 2001

□ 『Embedded Linux Devleopment: Building Embedded Linux Systems(StrongARM)』, 교육자료, Adelinux 2001

■ http://www-903.ibm.com/developerworks/kr/linux/library/l-fs.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs2.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs3.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs4.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs5.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs6.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs7.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs8.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs9.html,

http://www-903.ibm.com/developerworks/kr/linux/library/l-fs10.html
IBM developerWorks에서 연재한 저널링 파일시스템 특집 기사이다. 저널링 파일시스템에 대해 일목요연하게 정리하고 있으므로 읽을만한 가치가 있다.

■ http://e2fsprogs.sourceforge.net/ext2.html
EXT2 파일시스템 홈페이지이다. EXT2 파일시스템에 대한 설명과 링크를 제공한다.

■ http://www.zipworld.com.au/~akpm/linux/ext3/
EXT3 파일시스템 홈페이지이다. EXT3 파일시스템에 대한 설명과 소프트웨어, 링크를 제공한다.

■ http://www.namesys.com/
ReiserFS 파일시스템을 만든 namesys.com 홈페이지이다. ReiserFS에 대한 각종 기술 데이터를 제공한다.

■ http://www.linuxfocus.org/English/July2001/article210.shtml
신형 리눅스 램디스크 파일시스템인 ramfs를 소개하는 기사이다. 최신 커널 2.4에 대해 다룬다.

■ http://www.linuxfocus.org/English/November1999/article124.html
구형 리눅스 램디스크 사용 방법을 소개하는 기사이다. 이 문서를 역사적인 관점에서 참조하기 바란다.

■ http://developer.axis.com/software/jffs/doc/jffs.shtml
JFFS(Journaling Flash File System)을 소개하는 문서이다.

■ http://developer.axis.com/software/jffs/
JFFS 공식 홈페이지이다.

■ http://www.embeddedlinuxworks.com/articles/jffs_guide.html
JFFS 관련해 구체적인 사용법을 정리한 홈페이지이다.

■ http://sources.redhat.com/jffs2/
JFFS2 공식 홈페이지이다.

■ http://penguinppc.org/embedded/howto/root-filesystem.html
MPC에서 루트 파일시스템을 만드는 방법을 정리한 홈페이지이다.

■ http://www.linux-mtd.infradead.org/
리눅스를 위한 MTD(Memory Technology Device) 서브 시스템과 관련있는 각종 사항을 정리한 홈페이지이다.

■ http://www.aleph1.co.uk/armlinux/projects/yaffs/jffs2_and_nand.html
NAND 플래시에서 JFFS2를 사용할 때 발생하는 문제점을 소개하는 문서이다. 그런데 문서 내용에서 잘못된 부분(예: JFFS2가 배드 섹터를 처리하지 못한다. NAND 플래시를 사용할 수 없다)이 보인다.

■ http://ftp.linux.org.uk/pub/people/dwmw2/mtd/cvs/mtd/mtd-jffs-HOWTO.txt
간단한 리눅스 MTD, JFFS HOW-TO 문서이다.

■ http://ykjung99.netian.com/mtd/mtd.html
MPC860 보드에 MTD/JFFS2를 이식하는 방법을 소개하는 홈페이지이다.

■ http://myhome.naver.com/kingseft/gallery.html
임베디드 리눅스 관련 데이터를 제공하는 홈페이지이다. 데이터/게시판 메뉴에서 ‘Embedded Linux’를 선택하기 바란다.

■ http://www.linuxdevices.com/articles/AT7478621147.html
임베디드 리눅스 시스템을 위한 플래시 파일시스템에 대한 기사이다.

■ http://www.linuxhq.com/kernel/v2.4/doc/initrd.txt.html
부팅을 위한 리눅스 램디스크인 initrd 사용법을 정리한 기사이다.

■ http://kldp.org/Translations/html/Initrd-KLDP/Initrd-KLDP.html
초기 램디스크인 initrd에 대한 사용 방법을 정리한 기사이다.

■ http://www.linux.org/docs/ldp/howto/Bootdisk-HOWTO/index.html
리눅스에서 사용할 수 있는 부트 디스크를 만드는 방법을 설명하는 HOW-TO 문서이다.

■ http://www.tldp.org/HOWTO/mini/Loopback-Root-FS.html
루프백 루트 파일시스템을 만드는 방법을 설명하는 HOW-TO 문서이다.

■ http://atrak.usc.edu/~kar/mtd-jffs.html
아사벳에서 bootldr을 사용해 MTD-JFFS 파일 이미지로 부팅하는 방법을 소개하는 홈페이지이다.

■ http://www.busybox.net/
GNU fileutils, shellutils에 들어있는 각종 프로그램을 하나로 묶어놓은 임베디드 리눅스를 위한 맥가이버 칼(스위스 군용 칼이 정확한 표현이지만 여기서는 편의상 맥가이버 칼로 지칭한다)인 busybox 홈페이지이다.

■ http://tinylogin.busybox.net/
경량급이면서도 필요한 기능을 모두 갖추고 있는 임베디드 리눅스에서 동작하는 로그인 프로그램인 tinylogin 홈페이지이다.

■ http://udhcp.busybox.net/
임베디드 리눅스에서 동작하는 경량급 dhcp 서버와 클라이언트 패키지인 udhcp 홈페이지이다.

■ http://packages.debian.org/stable/base/ae.html
경량 문서 편집기인 안토니 편집기(ae) 패키지를 구할 수 있는 홈페이지이다.

■ http://packages.debian.org/unstable/base/elvis-tiny.html
경량 vi 클론인 elvis-tiny 패키지를 구할 수 있는 홈페이지이다.

목차

3부. 리눅스 개발 환경 구축과 이식

12장. 교차 개발 환경 구축

□ 『Embedded Linux: Hardware, Software, and Interfacing』, Dr. Craig Hollabaugh, Addison-Wesley, 2002

임베디드 리눅스에 대해 체계적으로 잘 구성된 책이다. 절반 이상이 인터페이스하는 방법에 대한 소개이므로, 일정 수준 이상의 개발자가 보기에 적당하다.

□ 『러닝 리눅스 3판』, 매트 웰시, 라 카우프만, 칼레 딜하이머 저, 이만용 역, 한빛미디어, 2001

오 라일리 『Running Linux 3rd Edition』의 번역판이다. 리눅스를 처음 접

나의 경쟁력…

수강신청 문의를 위해 찾아간 교수님께 참으로 좋은 말씀을 들었다…

“남과 같아서는 안된다.

자신의 가치를 높이기 위해서는 무언가 남들과 다른 어떠한 것을 ‘이루어야’ 한다.”

교수님은 저런 말씀을 하지 않으셨지만…내용의 요지는 그러하였다.

난 줄곧 다른사람들과의 경쟁에서 내세울 수 있는 것은 ‘노력’이라고 생각했었다.

하지만 그것은 어디까지나 ‘노력’일뿐, 무엇을 이룬다거나 하는 것이 아니었다.

노력이라 함은 과정에 불과한것이다.

물론 노력이 중요하지 않다는 것은 아니다. 하지만 결과물이 없는 노력은 결과물이 있는 노력에 뒤쳐진다는 것이다.

내나이 24세(실은 23.)…..인생에서 가장 피어난다는 20대…나는 무엇을 ‘이루었는가?’

자잘한 것들이야 많겠지만…..크게 획을 긋는 무엇은 없다.

단순히 즐기는 인생이 아니라…무엇인가를 이루고 싶다.

참신한 동기부여다.

몸에 활력이 돈다. 정신이 든다. 힘이 난다.

나의 경쟁력은 더이상 ‘노력’이 아니다. 이제부터는 ‘결과물’이다.

고로 지금 나의 경쟁력은 ‘0’이다.

이제 경쟁력을 높이는 일만 남았다.

힘내자. 아자!