Eric Raymond의 17가지 유닉스 규칙들(Unix Rules)

들어가며

개발관련 서적들을 읽다보면 유닉스 철학이 자주 언급됩니다. 이 철학은 훗날 많은 개발언어와 디자인패턴 등에 영향을 주기도 했다고 합니다. 그런 점에서 오늘은 유닉스 철학에 대해서, 그 중에서도 Eric Raymond의 17가지 유닉스 규칙들(Unix Rules) 에 대해서 간단히 알아볼까 합니다.

본문

Eric Raymond의 17가지 유닉스 규칙들(Unix Rules)을 소개하기에 앞서, 먼저 유닉스 철학에 대해서 간단히 소개하겠습니다.

유닉스 철학

유닉스 철학(Unix philosophy)은 켄 톰프슨이 고안한 것으로, 최소주의적인 모듈 방식의 소프트웨어 개발에 대한 문화적 규범이자 철학적 접근입니다. (위키피디아 참조)

 

아래는 1978년 더글러스 매클로이가 문서화한 내용의 번역본입니다. (원본)

1. 각 프로그램이 하나의 일을 잘 할 수 있게 만들 것.
새로운 일을 하려면, 새로운 기능들을 추가해서 오래된 프로그램을 더 복잡하게 하지말고 새로 만들 것.
(Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".)

2. 모든 프로그램의 출력이 다른 프로그램(설령 아직 잘 모르더라도)의 입력이 된다고 생각할 것.
무관한 정보로 출력을 채우지 말 것. 까다롭게 세로로 열거되거나 바이너리의 입력 형태를 피할 것. 대화식 입력을 고집하지 말 것.
(Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.)

3. 빠르게(이상적으로는 수 주내에) 써볼 수 있도록 소프트웨어를 설계하고 빌드할 것. 심지어 운영체제라도. 어설픈 부분을 버리고 다시 만드는 것을 주저하지 말 것.
(Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.)

4. 프로그래밍 작업의 부담을 덜기 위한 어설픈 도움보다는 도구를 사용할 것. 비록 그 도구들을 빌드하기 위해 우회해야하고 다 쓰고 바로 버리게 될 것 같아도. 
(Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.)

 

Eric Raymond's 17 Unix Rules

미국인 개발자이자 오픈소스 기여자인 Eric Raymond는 2003년에 출판한 그의 저서 "The Art of Unix Programming" 에서,

유닉스 철학을 KISS Priciple ("Keep it Simple, Stupid") 로 요약했습니다. 

그는 일련의 설계 규칙을  아래와 같이 제안했습니다. (오역이 있을 수 있습니다. 지적해주시면 감사하겠습니다.)

 

• Build modular programs
  모듈식으로 프로그램을 만들 것
• Write readable programs
  읽기쉬운 프로그램을 작성할 것
• Use composition
  컴포지션을 사용할 것.
• Separate mechanisms from policy
  메커니즘을 정책으로부터 분리할 것.
• Write simple programs
  간단한 프로그램을 작성할 것.
• Write small programs
  작은 프로그램을 작성할 것.
• Write transparent programs
  투명한 프로그램을 작성할 것.
• Write robust programs
  튼튼한 프로그램을 작성할 것.
• Make data complicated when required, not the program
  필요한 경우 프로그램이 아니라 데이터를 복잡하게 만들 것.
• Build on potential users' expected knowledge
  잠재적인 사용자의 예상되는 지식에 기반하여 구축할 것.
• Avoid unnecessary output
  불필요한 출력은 피할 것.
• Write programs which fail in a way that is easy to diagnose
  진단하기 쉬운 방법으로 실패한 프로그램을 작성할 것.
• Value developer time over machine time
  기계의 시간보다 개발자의 시간에 더 가치를 둘 것.
• Write abstract programs that generate code instead of writing code by hand
  손으로 코드를 작성하는 대신 코드를 생성하는 추상적인 프로그램을 작성할 것
• Prototype software before polishing it
  좋게 다듬기 전에 프로토타입을 먼저 만들어 볼 것.
• Write flexible and open programs
  유연하고 공개된 프로그램을 작성할 것.
• Make the program and protocols extensible
  프로그램과 프로토콜을 확장가능하게 만들 것.

 

이상입니다.

맺으며

특정 개발언어를 새롭게 익힐 때, 그 언어의 철학을 먼저 이해하는 것이 좋다는 말을 종종 듣습니다.

예를 들어, 제가 좋아하는 언어인 PHP는 아래와 같이 그 언어의 지향점을 설명하고 있습니다.

The goal of the language is to allow web developers to write dynamically generated pages quickly.
( PHP의 목표는 웹개발자들이 동적으로 생성되는 페이지를 빠르게 적을 수 있게 하는 것이다. )

또한 PHP 언어를 창시한 Rasmus Lerdorf 는 인터뷰에서 아래와 같이 말했는데, 여기서 PHP라는 언어가 가지는 실용적인 느낌을 조금 느낄 수 있습니다. 

I actually hate programming, but I love solving problems.
( 사실 나는 프로그래밍은 싫어하지만, 문제를 해결하는 것은 좋아합니다. ) 

 

본문에서 살펴본 유닉스 철학과 규칙들을 보면, 각종 개발 언어의 철학이나 개발할 때에 주로 접하게 되는 개발방법론들도 유닉스 철학으로부터 많은 영향을 받은 것 같습니다. 저도 처음엔 아무런 의심없이 부모 클래스에 공통으로 사용되는 함수를 구현하고 습관적으로 상속을 사용하곤 했었는데요, 불필요하게 상속을 남발하는 것은 좋지 않다고 선배 개발자분께 혼났던 기억이 있습니다. 

 

짧은 글이었지만 유닉스 철학과 Eric Raymond의 17가지 유닉스 규칙이 궁금하셨던 분들께 조금이나마 도움이 되셨기를 바랍니다. 감사합니다.