맨위로가기

유닉스 철학

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

유닉스 철학은 1970년대 벨 연구소에서 유닉스 운영체제를 개발하면서 시작되었으며, 더글러스 매클로이, 켄 톰슨, 데니스 리치 등 주요 개발자들이 핵심 원칙을 정립했다. 주요 개념으로는 각 프로그램이 하나의 기능을 잘 수행하도록 설계하는 DOTADIW (Do One Thing and Do It Well) 원칙, KISS (Keep It Simple, Stupid) 원칙, 그리고 Worse is better 철학 등이 있다. 유닉스 철학은 단순성, 명료성, 모듈성을 강조하며, 프로그램 간의 상호 작용을 통해 유연하고 확장 가능한 시스템을 구축하는 것을 목표로 한다. 그러나 사용자 인터페이스의 부족, 마이크로서비스와 유사한 비효율성 문제, 그리고 GNU 프로젝트의 도구들이 유닉스 철학에서 벗어났다는 비판도 존재한다.

더 읽어볼만한 페이지

  • 소프트웨어 개발 철학 - 애자일 소프트웨어 개발
    애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.
  • 소프트웨어 개발 철학 - 폭포수 모델
    폭포수 모델은 소프트웨어 개발 방법론 중 하나로, 요구사항 분석부터 운영 및 유지보수까지 순차적으로 단계를 진행하며, 각 단계가 완료되어야 다음 단계로 넘어가는 방식을 따른다.
  • 유닉스 - 유닉스 시간
    유닉스 시간은 1970년 1월 1일 00:00:00 UTC부터 경과된 초를 나타내는 시스템으로, 컴퓨터 시스템에서 시간 저장 및 처리에 널리 사용되며 32비트 정수 표현 시 2038년 문제를 야기할 수 있고 64비트 정수로 해결 가능하며, 다양한 시스템에서 타임스탬프로 활용되지만 윤초 처리 차이로 UTC 시간과 완벽히 일치하지는 않는다.
  • 유닉스 - 유닉스 계열
    유닉스 계열은 유닉스 운영체제의 특징과 설계를 공유하는 운영체제들을 지칭하며, 유전적, 상표, 기능적 유닉스로 분류되고 macOS는 상표 유닉스이자 유전적 유닉스에 해당하며 리눅스는 기능적 유닉스의 대표적인 예이다.
유닉스 철학
기본 정보
유닉스의 역사
유닉스의 역사
유형운영체제 철학
기원1970년대
창시자켄 톰슨
데니스 리치
더글러스 매클로이
조 오산나
개발 장소벨 연구소
영향 받은 것MULTICS
영향을 준 것리눅스
BSD
Plan 9 from Bell Labs
Inferno
Minix
GNU
핵심 원칙
작은 것이 아름답다각 프로그램은 하나의 작업만 잘 수행해야 한다.
각 프로그램을 협력하게 만들어라모든 프로그램의 출력은 아직 알려지지 않은 다른 프로그램의 입력이 될 수 있어야 한다.
가능한 한 빨리 프로토타입을 만들어라복잡한 문제를 해결하기 위해 프로토타입을 빠르게 만들고 테스트해야 한다.
이식성을 우선시하라프로그램은 다양한 환경에서 실행될 수 있도록 설계해야 한다.
데이터를 단순 텍스트 파일에 저장하라데이터는 쉽게 처리하고 공유할 수 있도록 텍스트 형식으로 저장해야 한다.
소프트웨어를 지렛대로 활용하라기존 도구와 라이브러리를 활용하여 개발 효율성을 높여야 한다.
셸 스크립트를 활용하여 지렛대를 높여라셸 스크립트를 사용하여 복잡한 작업을 자동화하고 관리해야 한다.
사일런스 원칙"아무 말도 안 하는 것이 좋은 소식이다." (오류가 없으면 조용히 실행되어야 한다.)
모든 것을 파일로 만들어라모든 시스템 자원을 파일 형태로 추상화하여 일관된 인터페이스를 제공해야 한다.
추가 정보
관련 인물피터 웨인버거
브라이언 커니핸
롭 파이크
리처드 스톨먼

2. 기원

유닉스 철학은 1970년대 벨 연구소에서 유닉스 운영체제를 개발하면서 시작되었다. 더글러스 매클로이, 켄 톰슨, 데니스 리치 등 주요 개발자들은 유닉스 철학의 핵심 원칙을 정립했다.

1974년 켄 톰슨과 데니스 리치는 유닉스 설계에서 고려한 사항으로 다음을 제시했다.[3][18]


  • 프로그램을 작성, 테스트, 실행하기 쉽게 설계한다.
  • 초기 버전은 1명의 사용자만 지원했지만, 대화형으로 시스템을 사용한다.
  • 잘 설계된 대화형 시스템은 배치 처리 시스템보다 생산적이고 만족스럽다.
  • 크기 제약은 경제성뿐 아니라 설계를 우아하게 만든다.
  • 모든 유닉스 소프트웨어는 유닉스 하에서 유지보수된다.


1978년 벨 시스템 기술 저널에 유닉스 철학이 문서화되었다.[1][2][16][17][25][26]

2. 1. 핵심 원칙 (초기)

더글러스 매클로이[25][26]는 1978년 벨 시스템 기술 저널에 다음과 같은 유닉스 철학을 문서화했다.[1][2]

# 각 프로그램이 하나의 일을 잘 할 수 있게 만들 것. 새로운 일을 하려면, 새로운 기능들을 추가하기 위해 오래된 프로그램을 복잡하게 만들지 말고 새로 만들 것.

# 모든 프로그램 출력이 아직 잘 알려지지 않은 프로그램이라고 할지라도 다른 프로그램에 대한 입력이 될 수 있게 할 것. 무관한 정보로 출력을 채우지 말 것. 까다롭게 세로로 구분되거나 바이너리로 된 입력 형식은 피할 것. 대화식 입력을 고집하지 말 것.

# 소프트웨어를 설계하고 구축할 때 빠르게 써볼 수 있게 할 것. 심지어 운영체제라도 이상적으로는 수 주 내로. 어설픈 부분을 버리고 다시 만드는 것을 주저하지 말 것.

# 프로그래밍 작업을 가볍게 하기 위해, 심지어 우회하는 방법으로 도구를 만들고 바로 버릴지라도 어설픈 도움 보다는 도구 사용을 선호할 것.

피터 H. 살러스는 《A Quarter-Century of Unix》(1994)에서 유닉스 철학을 다음과 같이 요약했다.[1]

  • 한 가지 일을 잘 수행하는 프로그램을 작성한다.
  • 함께 작동하는 프로그램을 작성한다.
  • 텍스트 스트림을 처리하는 프로그램을 작성한다. 왜냐하면 그것이 보편적인 인터페이스이기 때문이다.


유닉스 파이프를 발명한[7] 더글러스 매킬로이는 유닉스 철학을 다음과 같이 요약했다.[1]

1974년 유닉스 논문에서 데니스 리치와 켄 톰슨은 다음과 같은 설계 고려 사항을 언급했다.[3]

  • 프로그램을 쉽게 작성, 테스트 및 실행할 수 있도록 한다.
  • 일괄 처리 대신 대화형 사용.
  • 크기 제약으로 인한 절약과 우아함.
  • 자급 자족 시스템: 모든 유닉스 소프트웨어는 유닉스 하에서 유지 관리된다.


매킬로이는 유닉스 프로그래밍에서 단순함과 미니멀리즘을 강조했다.[1]

반대로, 매킬로이는 현대 리눅스가 소프트웨어 비대화를 겪고 있다고 비판하며, "숭배자들이 리눅스에 실망스러운 비만 상태가 될 때까지 이것저것 줬다."라고 언급했다.[8] 그는 연구용 유닉스를 개발할 때 벨 연구소에서 취했던 초기 접근 방식과 대조했다.[9]

3. 발전과 전개

유닉스 철학은 시간이 지나면서 여러 저자와 개발자들에 의해 재해석되고 확장되었다.

벨 연구소의 브라이언 커니핸과 롭 파이크는 1984년에 출판된 책 ''The UNIX Programming Environment''의 서문에서 유닉스 설계와 철학을 간략하게 설명했다.[4] 같은 해 10월, 그들은 "유닉스 환경에서의 프로그램 설계(Program Design in the UNIX Environment)"라는 논문을 발표하여, 각각 하나의 기능을 수행하는 소프트웨어 도구에 대한 유닉스 철학을 설명했다.[5]

롭 파이크


브라이언 커니핸


더글러스 매클로이는 유닉스 파이프를 발명했으며, 유닉스 철학을 "한 가지 일을 잘 하는 프로그램을 작성하라"는 격언으로 요약했다.[1] 그는 유닉스 프로그래밍에서 단순성과 미니멀리즘을 강조했다.[1]

에릭 S. 레이먼드는 2003년에 출판된 그의 저서 ''유닉스 프로그래밍의 예술''에서[11] 유닉스 철학을 KISS 원칙 ("단순하게 유지하라")으로 요약하고,[12] 다음과 같은 설계 규칙들을 제시했다:[1]

규칙설명목표
모듈(Module)화 규칙깨끗한 인터페이스로 연결되는 단순한 부품을 작성하라.문제 국소화, 교체 가능성, 디버깅 시간 절약.
명료성 규칙명료함은 독창성보다 낫다.코드를 읽고 이해하기 쉽게 하는 것.
합성 규칙다른 프로그램과 연결될 수 있도록 디자인하라.작고 단순한 프로그램으로 분해.
분할 규칙기구와 정책의 분리(Separation of Mechanism and Policy)를 수행하라. 인터페이스를 엔진으로부터 분리하라.정책 변경으로 인한 버그 감소.
단순성 규칙단순함을 추구하여 디자인하라.버그 방지.
검약 규칙큰 프로그램을 작성하는 것을 피하라.개발 시간 투자 방지.
투명성 규칙투명성을 추구하여 디자인하라. 조사와 디버깅이 쉬워진다.디버깅 시간 단축, 프로그램 수명 연장.
견고함 규칙견고함은 투명성과 단순성에서 비롯된다.견고하고 신뢰할 수 있는 제품 구축.
대표 규칙지식을 데이터에 포함시켜라. 그러면 프로그램의 로직을 지루하고 견고하게 만들 수 있다.프로그램 유지보수성 향상.
최소 놀라움의 원칙(Principle of least astonishment) 규칙인터페이스 디자인에서는 항상 놀라움이 최소화되도록 하라.직관적인 제품 개발.
침묵 규칙불필요한 출력을 하지 마라.필요한 정보 선택 가능.
수복 규칙실패해야 할 때는 시끄럽게, 그리고 가능한 한 빨리 실패하라.부정한 출력으로 인한 손상 방지.
경제 규칙프로그래머의 시간은 소중하다. 프로그래머의 시간을 컴퓨터의 시간보다 우선하여 절약하라.프로젝트 개발 비용 절감.
생성 규칙수작업(hand-hacking)을 피하라.[23]휴먼 에러 감소 및 시간 절약.
최적화 (정보 공학)(Optimization (computer science)) 규칙세련되게 하기 전에 원형 (프로토타입)을 만들어라.과도한 시간 소비 방지.
다양성 규칙모든 "단 하나의 진짜 방법"이라는 주장은 믿지 마라.의도 외 사용 가능.
확장성 규칙미래를 위해 디자인하라. 미래는 생각보다 빨리 온다.코드 수명 및 실용성 향상.



마이크 갠카르츠(Mike Gancarz)는 1994년에 ''유닉스 철학''을 출판하여, 하드웨어 및 그래픽 장치에 대한 비표준 인터페이스를 사용하는 효율성보다 이식성이 더 중요해야 한다는 그의 철학을 설명했다. 그가 중요하다고 주장하는 9가지 기본 "원칙"은 다음과 같다.

# 작은 것이 아름답다.

# 각 프로그램은 한 가지 일을 잘해야 한다.

# 가능한 한 빨리 프로토타입을 구축한다.

# 효율성보다 이식성을 선택한다.

# 데이터를 평평한 텍스트 파일에 저장한다.

# 소프트웨어 레버리지를 유리하게 사용한다.

# 셸 스크립트를 사용하여 레버리지와 이식성을 높인다.

# 종속적인 사용자 인터페이스를 피한다.

# 모든 프로그램을 필터로 만든다.

3. 1. 피터 H. 살러스의 요약 (1994)


  • 한 가지 일을 잘 수행하는 프로그램을 작성한다.
  • 함께 작동하는 프로그램을 작성한다.
  • 보편적인 인터페이스인 텍스트 스트림을 처리하는 프로그램을 작성한다.[1]

3. 2. 브라이언 커니핸과 롭 파이크 (1984)

벨 연구소의 브라이언 커니핸과 롭 파이크는 1984년에 출판된 책 ''The UNIX Programming Environment''의 서문에서 유닉스 설계와 철학을 간략하게 설명했다.[4]

커니핸과 파이크는 이 책의 목표가 "유닉스 프로그래밍 철학을 전달하는 것"이라고 덧붙였다.

1984년 10월, 브라이언 커니핸과 롭 파이크는 "유닉스 환경에서의 프로그램 설계(Program Design in the UNIX Environment)"라는 논문을 발표했다. 이 논문에서 그들은 4.2BSD와 System V와 같은 일부 새로운 유닉스 시스템에서 발견되는 프로그램 옵션과 기능의 축적을 비판하고, 각각 하나의 일반적인 기능을 수행하는 소프트웨어 도구에 대한 유닉스 철학을 설명했다.[5]

커니핸과 파이크는 과 같은 유닉스 도구를 다른 시스템에서 사용되는 더 큰 프로그램 제품군과 대조했다.[5]

3. 3. 더글라스 매클로이

더글러스 매클로이는 벨 연구소의 컴퓨팅 과학 연구 센터 책임자였으며, 유닉스 파이프를 발명했다.[7] 그는 유닉스 철학을 "한 가지 일을 잘 하는 프로그램을 작성하라"는 격언으로 요약했다.[1]

매클로이는 유닉스 프로그래밍에서 단순성과 미니멀리즘을 강조했다.[1]

반면, 매클로이는 현대 리눅스가 소프트웨어 비대화를 겪고 있다고 비판하며, "숭배자들이 리눅스에 실망스러운 비만 상태가 될 때까지 이것저것 줬다."라고 언급했다.[8] 그는 연구용 유닉스를 개발할 때의 벨 연구소의 접근 방식과 대조하며 다음과 같이 말했다.[9]

3. 4. 에릭 S. 레이먼드 (2003)

에릭 S. 레이먼드는 2003년에 출판된 그의 저서 ''유닉스 프로그래밍의 예술''에서[11] 유닉스 철학을 KISS 원칙 ("단순하게 유지하라")으로 요약하고,[12] 다음의 설계 규칙들을 제시했다:[1]

  • 모듈화된 프로그램을 작성하라.
  • 읽기 쉬운 프로그램을 작성하라.
  • 구성을 사용하라.
  • 메커니즘과 정책을 분리하라.
  • 단순한 프로그램을 작성하라.
  • 작은 프로그램을 작성하라.
  • 투명한 프로그램을 작성하라.
  • 견고한 프로그램을 작성하라.
  • 프로그램이 아닌, 필요할 때 데이터를 복잡하게 만들라.
  • 잠재적인 사용자의 예상된 지식을 기반으로 구축하라.
  • 불필요한 출력을 피하라.
  • 진단하기 쉬운 방식으로 실패하는 프로그램을 작성하라.
  • 기계 시간보다 개발자 시간을 중시하라.
  • 코드를 직접 작성하는 대신 코드를 생성하는 추상적인 프로그램을 작성하라.
  • 다듬기 전에 소프트웨어를 프로토타입하라.
  • 유연하고 열린 프로그램을 작성하라.
  • 프로그램과 프로토콜을 확장 가능하게 만들라.


레이먼드는 그의 저서에서[22] 유닉스 철학이 "Keep it Simple, Stupid" (KISS 원칙)라는 공학 철학으로 요약될 수 있다고 설명하며, 이것이 유닉스 문화에 어떻게 적용되는지에 대한 그의 신념을 설명한다. 그러나 이러한 규칙을 위반하는 예시도 쉽게 찾아볼 수 있다.

규칙설명목표
모듈(Module)화 규칙깨끗한 인터페이스로 연결되는 단순한 부품을 작성하라. 프로그램은 단순한 부품들을 명확하게 정의된 인터페이스로 연결하여 작성해야 한다.문제의 국소화, 미래 버전에서 새로운 기능을 지원하기 위한 프로그램 일부 교체 가능. 복잡하고 긴 코드를 디버깅하는 시간 절약.
명료성 규칙명료함은 독창성보다 낫다. 개발자는 컴퓨터가 아닌, 프로그램을 읽고 유지보수할 자신을 포함한 개발자를 대상으로 프로그램을 작성해야 한다.미래에 코드를 다룰 사람에게 코드가 읽기 쉽고 이해하기 쉽도록 하는 것.
합성 규칙다른 프로그램과 연결될 수 있도록 프로그램을 디자인하라. 개발자는 다른 프로그램과 쉽게 통신할 수 있는 프로그램을 작성해야 한다.프로젝트를 지나치게 복잡한 일체형 프로그램이 아닌 작고 단순한 프로그램으로 분해.
분할 규칙기구와 정책의 분리(Separation of Mechanism and Policy)를 수행하라. 인터페이스를 엔진으로부터 분리하라. 프로그램의 메커니즘과 정책을 분리해야 한다. (프런트 엔드 인터페이스와 백엔드 엔진으로 프로그램을 나누는 등)메커니즘을 훼손하지 않고 정책을 변경하여 버그 감소.
단순성 규칙단순함을 추구하여 디자인하라. 복잡하게 해야만 하는 경우에만 복잡성을 더하라. 단순한 디자인을 유념하고, 작고 이해하기 쉬운 협조적인 부품으로 프로그램을 분할하라."정교하고 아름답지만" 버그가 많은 프로그램 작성 방지.
검약 규칙큰 프로그램을 작성하는 것을 피하라.개발 시간의 과도한 투자 방지. 작은 프로그램은 최적화와 유지보수가 용이하며 폐기하기도 쉬움.
투명성 규칙투명성을 추구하여 디자인하라. 조사와 디버깅이 쉬워진다. 미래 개발자가 사고 과정을 명료하게 이해하고, 유효한 입력과 올바른 출력을 쉽게 식별하도록 가시성과 발견성을 설계해야 한다.디버깅 시간 단축 및 프로그램 수명 연장.
견고함 규칙견고함은 투명성과 단순성에서 비롯된다. 투명성과 발견력을 높이는 설계를 통해 견고한 프로그램을 만들어야 한다.이해하기 쉬운 코드는 복잡한 프로그램에서 예측 불가능한 상황에 대한 스트레스 테스트를 쉽게 수행 가능. 견고하고 신뢰할 수 있는 제품 구축.
대표 규칙지식을 데이터에 포함시켜라. 그러면 프로그램의 로직을 지루하고 견고하게 만들 수 있다. 프로그램의 절차적 로직보다 데이터를 더 복잡하게 선택하라.복잡한 데이터는 복잡한 로직에 비해 인간이 이해하기 쉽다. 프로그램 유지보수성 향상.
최소 놀라움의 원칙(Principle of least astonishment) 규칙인터페이스 디자인에서는 항상 놀라움이 최소화되도록 하라. 사용자가 기대하는 잠재적인 지식 위에 구축되는 프로그램을 설계해야 한다. (예: 계산기에서 +는 항상 덧셈)직관적으로 사용하기 쉬운 제품 개발.
침묵 규칙불필요한 출력을 하지 마라. 다른 개발자에게 방해가 될 뿐이다.불필요한 출력을 분석하지 않고 프로그램 출력에서 필요한 정보를 선택 가능.
수복 규칙실패해야 할 때는 시끄럽게, 그리고 가능한 한 빨리 실패하라. 고장 원인을 특정하기 쉽고 진단하기 쉬운, "소리 내며 고장 나는" 프로그램을 설계해야 한다.부정한 출력이 입력되어 다른 코드의 출력이 감지되지 않고 손상되는 것을 방지.
경제 규칙프로그래머의 시간은 소중하다. 프로그래머의 시간을 컴퓨터의 시간보다 우선하여 절약하라. 머신 사이클은 상대적으로 저렴하므로, 개발자 타임을 중시해야 한다.프로젝트 개발 비용 절감.
생성 규칙hand-hacking을 피하라.[23] 손으로 코드를 작성하는 대신 추상적인 고수준 프로그램을 작성하여 코드를 생성해야 한다.휴먼 에러 감소 및 시간 절약.
최적화 (정보 공학)(Optimization (computer science)) 규칙세련되게 하기 전에 원형 (프로토타입)을 만들어라. 최적화하기 전에 원형이 작동하도록 하라.작은 이익을 위해 과도한 시간 소비 방지.
다양성 규칙모든 "단 하나의 진짜 방법"이라는 주장은 믿지 마라. 프로그램이 유연하고 열려 있도록 설계해야 한다.개발자가 의도한 것 이외의 사용을 가능하게 함.
확장성 규칙미래를 위해 디자인하라. 미래는 생각보다 빨리 온다. 프로토콜을 확장 가능하게 하고, 다른 개발자가 쉽게 플러그인할 수 있도록 하며, 프로그램 버전을 표기하는 등 미래 지향적 설계를 해야 한다.코드 수명 연장 및 실용성 향상.



이러한 규범의 대부분은 유닉스 커뮤니티 밖에서도 받아들여지고 있다. 처음 유닉스가 채택했을 때는 그렇지 않았더라도, 나중에 그렇게 되었다. 또한, 많은 부분은 유닉스 커뮤니티 특유의 것이 아니며, 유닉스 커뮤니티에서 생겨난 것도 아니다. 그럼에도 불구하고, 숙련된 유닉스 프로그래머는 이러한 생각들을 조합한 것을 유닉스 스타일의 기초로 받아들이는 경향이 있다.

3. 5. 마이크 갠카르츠 (1994)

마이크 갠카르츠(Mike Gancarz)는 디지털 이큅먼트 코퍼레이션(Digital Equipment Corporation)(DEC)의 유닉스 엔지니어링 그룹(UEG)의 일원이었다. 그는 1980년대 DEC에서 진행한 자신의 유닉스(울트릭스(Ultrix)) 포트 개발 경험과 동료들과의 토론을 바탕으로 1994년에 ''유닉스 철학''을 출판했다. 그는 X 윈도 시스템 개발팀의 일원이며, 울트릭스 윈도 매니저(uwm)의 저자이기도 하다.

이 책은 1980년대의 유닉스 전쟁 동안 유닉스를 다양한 컴퓨터로 포팅하는 데 초점을 맞추고 있으며, 하드웨어 및 그래픽 장치에 대한 비표준 인터페이스를 사용하는 효율성보다 이식성이 더 중요해야 한다는 그의 철학을 설명한다.

그가 중요하다고 주장하는 9가지 기본 "원칙"은 다음과 같다.

# 작은 것이 아름답다.

# 각 프로그램은 한 가지 일을 잘해야 한다.

# 가능한 한 빨리 프로토타입을 구축한다.

# 효율성보다 이식성을 선택한다.

# 데이터를 평평한 텍스트 파일에 저장한다.

# 소프트웨어 레버리지를 유리하게 사용한다.

# 셸 스크립트를 사용하여 레버리지와 이식성을 높인다.

# 종속적인 사용자 인터페이스를 피한다.

# 모든 프로그램을 필터로 만든다.

다음 교리는 중요성이 상대적으로 낮다고 여겨지며, 유닉스 철학으로서 보편적으로 합의된 것은 아니며, 경우에 따라서는 현재도 격렬하게 논의되고 있다(예: 모놀리식 커널과 마이크로 커널).

# 취향에 따라 스스로 환경을 조정할 수 있도록 하라.

# 운영체제 커널은 작고 가볍게 하라.

# 소문자 짧은 이름을 사용하라.

# 숲을 지켜라.

# 침묵은 금이다.

# 병렬성을 고려하라.

# 부분의 총합은 전체보다 크다.

# 90% 해결을 모색하라.

# 열등한 것이 우월하다 (더 나쁜 것이 더 좋은 것이다).

# 계층적으로 생각하라.

4. 주요 개념

더글러스 매클로이가 1978년 벨 시스템 기술 저널에서 문서화한 유닉스 철학의 핵심 원칙 중 하나는 "하나의 일만 하고 그것을 잘 하라(Do One Thing and Do It Well, DOTADIW)"이다.[25][26]

매클로이는 이 철학을 다음과 같이 요약했다.

> 이것이 UNIX의 철학이다.

> 한 가지 일을 하고, 또 그것을 잘 해내는 프로그램을 써라.

> 협력하여 움직이는 프로그램을 써라.

> 표준 입출력(텍스트 스트림)을 다루는 프로그램을 써라. 표준 입출력은 보편적인 인터페이스이다.

>

>

더글러스 매클로이, UNIX의 4분의 1세기


에릭 S. 레이먼드는 저서 ''유닉스 프로그래밍의 예술''에서[11][22] 유닉스 철학을 KISS 원칙 ("단순하게 유지하라(Keep it Simple, Stupid)")으로 요약했다.[12]

리처드 P. 가브리엘은 유닉스의 핵심적인 장점이 "더 나쁜 것이 더 낫다(Worse is better)"라는 설계 철학을 구현한 데 있다고 주장한다.

4. 1. DOTADIW (Do One Thing and Do It Well)

더글러스 매클로이[25]가 1978년 벨 시스템 기술 저널에서 문서화한 유닉스 철학의 핵심 원칙 중 하나로, "하나의 일만 하고 그것을 잘 하라(Do One Thing and Do It Well, DOTADIW)"는 의미를 담고 있다.[26]

DOTADIW 원칙에 따르면, 유닉스 프로그램은 한 가지 특정 작업을 효율적으로 수행하는 데 집중해야 한다. 새로운 기능을 추가해야 할 때는 기존 프로그램을 복잡하게 만들기보다 새로운 프로그램을 만들어야 한다.

파이프 발명자이자 UNIX 창시자 중 한 명인 매클로이는 이 철학을 다음과 같이 요약했다.

> 이것이 UNIX의 철학이다.

> 한 가지 일을 하고, 또 그것을 잘 해내는 프로그램을 써라.

> 협력하여 움직이는 프로그램을 써라.

> 표준 입출력(텍스트 스트림)을 다루는 프로그램을 써라. 표준 입출력은 보편적인 인터페이스이다.

>

>
더글러스 매클로이, UNIX의 4분의 1세기


이 철학은 보통 "한 가지 일을 잘 해내라"는 말로 요약된다.

슬랙웨어 리눅스(Slackware Linux) 프로젝트 리더인 패트릭 볼커링(Patrick Volkerding)은 systemd 아키텍처를 비판하면서 이 설계 원칙을 언급했다. 그는 "하나의 데몬 내에서 서비스, 소켓, 장치, 마운트 등을 제어하려는 시도는 하나의 일만 하고 그것을 잘 하라는 유닉스 개념에 정면으로 배치된다"고 말했다.[10]

4. 2. KISS 원칙 (Keep It Simple, Stupid)

에릭 S. 레이먼드는 저서 ''유닉스 프로그래밍의 예술''에서[11][22] 유닉스 철학을 "단순하게 유지하라(Keep it Simple, Stupid)"라는 KISS 원칙으로 요약했다.[12] 이는 복잡성을 피하고 명료하고 이해하기 쉬운 코드를 작성해야 한다는 원칙이다.

레이먼드는 이 원칙을 따르는 설계 규칙으로 단순성 규칙을 제시했다.

;단순성 규칙

: 단순함을 추구하여 디자인하라. 복잡하게 해야만 하는 경우에만 복잡성을 더하라.

: 개발자는 단순한 디자인을 유념해야 한다. 프로그램을 작고 이해하기 쉬운 협조적인 부품으로 분할하는 방법을 모색해야 한다. 개발자가 "정교하고 아름답고 복잡하지만" 실제로는 버그가 많은 프로그램을 작성하는 것을 방지하기 위한 것이다.

4. 3. Worse is better (더 나쁜 것이 더 낫다)

리처드 P. 가브리엘은 유닉스의 핵심적인 장점이 "더 나쁜 것이 더 낫다(Worse is better)"라는 설계 철학을 구현한 데 있다고 주장한다. 이 철학에서는 인터페이스와 구현의 단순성이 시스템의 다른 어떤 속성(정확성, 일관성, 완전성)보다 더 중요하다고 본다. 가브리엘은 이 설계 스타일이 핵심적인 진화적 이점을 가지고 있다고 주장하지만, 일부 결과의 품질에 대해서는 의문을 제기한다.[21]

예를 들어, 초기 유닉스는 모놀리식 커널을 사용했는데, 이는 사용자 프로세스가 커널 시스템 호출을 모두 사용자 스택에서 수행했음을 의미한다. 프로세스가 커널에서 장기적인 I/O로 차단된 상태에서 시그널이 전달되면 어떻게 처리해야 할지 불분명했다. 프로세스가 커널 모드에 있고 민감한 커널 데이터가 스택에 있는 경우 시그널 처리기를 실행할 수 없었기 때문이다.

이러한 경우에 켄 톰슨과 데니스 리치는 완전성보다 단순함을 선호했다. 초기 유닉스는 시스템 호출을 종료하고, "Interrupted System Call"(시스템 콜 실행 중에 사용자가 인터럽트를 발행) 오류(오류 번호 4, EINTR)를 빠르게 통지했다. 이후 시스템 콜은 재개되지 않았다.[21]

5. 비판

돈 노먼은 1981년 Datamation에 게재된 "유닉스에 대한 진실: ''사용자 인터페이스는 끔찍하다''"[13]라는 기사에서 유닉스의 설계 철학이 사용자 인터페이스에 대한 고려가 부족하다고 비판했다. 그는 인지 공학[14] 관점에서 최종 사용자가 시스템을 이해하고 개인적인 인지 모델을 형성하는 방식에 초점을 맞췄다. 그는 유닉스의 경우 이해에 실패하여 치명적인 실수(예: 한 시간 분량의 작업 손실)가 너무나 쉽게 발생한다고 지적했다.

조나단 블로우는 팟캐스트 On the Metal에서 유닉스 철학이 시대에 뒤떨어졌다고 비판했다.[15] 그는 모듈식 도구를 연결하는 것이 매우 비효율적인 프로그램을 초래한다고 주장했다. 그는 유닉스 철학이 마이크로서비스와 유사한 문제점을 겪고 있다고 말한다. 즉, 전체적인 감독 없이 큰 아키텍처는 결국 비효율적이고 효과적이지 않게 된다는 것이다.

GNU 프로젝트에 의한 표준적인 UNIX 프로그램의 대체(diff나 find 등)가 UNIX 철학에 따르는 것인지, 아니면 그것을 오해하고 있는지는 논란이 있는 부분이다. UNIX에 오래 전부터 관여해 온 사람들 중 일부는 GNU 프로젝트의 툴들이 UNIX의 것보다 크고 기능도 풍부하기 때문에 UNIX 철학을 위배한다고 주장한다.

1983년, 롭 파이크는 UNIX의 기본적인 툴에 대해 BSD에 의해 확장된 기능의 일부(대표적인 예로 cat에 제어 코드를 문자로 변환하여 가시화하는 -v)의 사양이 UNIX적이지 않다고 비판했다.[24] UNIX 철학에 따르면, cat -v의 기능은 독립된 필터로 수행되어야 한다. 원래 '연결' 명령어인 cat이, 단순히 스트림을 읽고 쓰는 목적으로 사용되는 경우가 많지만, 그 외에 이것저것 기능을 가져서는 안 된다는 생각도 있다.

마찬가지로 비판받은 ls 명령어의 옵션인 출력을 표시되는 폭에 맞춰서 서식을 지정하는 기능은 충분히 편리하지만, UNIX 철학에 따르면 column 명령어를 파이프로 연결해야 하며, 이는 번거롭다고 생각할 수도 있다.

6. 한국적 관점 및 의의

유닉스 철학은 한국의 IT 문화와 개발 방식에 큰 영향을 미쳤다고 평가하기는 어렵다. 유닉스 철학의 핵심 가치인 모듈화, 이식성, 단순성은 한국의 소프트웨어 개발 관행에 일부 반영되었지만, 한국 특유의 개발 문화와는 다소 차이가 있다.

예를 들어, 유닉스 철학은 "작은 것이 아름답다"는 철학을 바탕으로 각 프로그램이 한 가지 기능을 잘 수행하도록 설계하는 것을 강조한다. 하지만 한국의 개발 환경에서는 여러 기능을 통합한 복합적인 소프트웨어가 선호되는 경향이 있다. 또한, 유닉스는 텍스트 기반 인터페이스를 중시하지만, 한국에서는 그래픽 사용자 인터페이스(GUI)가 더 보편적이다.

그럼에도 불구하고, 유닉스 철학의 일부 요소는 한국의 개발자들에게 영감을 주었다. 특히, 오픈 소스 운동과 리눅스 커널 개발은 유닉스 철학의 영향을 받아 이루어졌으며, 이는 한국의 IT 생태계에도 긍정적인 영향을 미쳤다.

참조

[1] 서적 The Art of Unix Programming http://www.catb.org/[...] Addison-Wesley Professional 2016-11-01
[2] 논문 Unix Time-Sharing System: Foreword https://archive.org/[...] Bell Laboratories 1978-07-08
[3] 논문 The UNIX time-sharing system https://people.eecs.[...]
[4] 서적 The UNIX Programming Environment
[5] 논문 Program Design in the UNIX Environment https://harmful.cat-[...] 2022-12-15
[6] 문서 CP/M Operating System Manual http://www.tramm.li/[...] 1983-01-01
[7] 논문 The Evolution of the UNIX Time-Sharing System http://tech-insider.[...]
[8] 웹사이트 Remarks for Japan Prize award ceremony for Dennis Ritchie, May 19, 2011, Murray Hill, NJ http://www.cs.dartmo[...] 2014-06-19
[9] 웹사이트 Ancestry of Linux — How the Fun Began (2005) https://archive.org/[...] 2014-06-19
[10] 웹사이트 Interview with Patrick Volkerding of Slackware http://www.linuxques[...] 2015-10-24
[11] 서적 The Art of Unix Programming http://www.catb.org/[...] Addison-Wesley 2009-02-09
[12] 서적 The Art of Unix Programming http://www.catb.org/[...] Addison-Wesley 2009-02-09
[13] 뉴스 The truth about Unix: The user interface is horrid http://www.ceri.memp[...] 1981-01-01
[14] 웹사이트 An Oral History of Unix https://www.princeto[...] Princeton University History of Science
[15] 팟캐스트 On the Metal Podcast: Jonathan Blow https://oxide.comput[...]
[16] 논문 Unix Time-Sharing System: Foreword https://archive.org/[...] Bell Laboratories 1978-07-08
[17] 서적 The Art of Unix Programming http://www.catb.org/[...] Addison-Wesley Professional 2016-11-01
[18] 논문 The UNIX time-sharing system https://people.eecs.[...]
[19] 웹사이트 Notes on Programming in C http://www.lysator.l[...] 2008-11-21
[20] 문서 凝ったアルゴリズムは、それ自身がすでに大きなコストであるということ。
[21] 문서 現在のUnixではカーネルコードがユーザスタックで実行されない。また、I/O中のシグナルがこのようなふるまいであったのは初期のUNIXやSystemV（あるいは初期のLinux）のことである。4.3以降のBSDや現在のLinuxでは、全くI/Oが進行していない状態でシグナルが入った場合、シグナル処理が終わった後、中断されたI/Oが再開される。
[22] 서적 The Art of Unix Programming Addison-Wesley, 아스키
[23] 웹사이트 hand-hacking http://www.catb.org/[...] 2023-01-09
[24] 웹사이트 http://harmful.cat-v[...]
[25] 웹인용 Basics of the Unix Philosophy: Chapter 1. Philosophy http://www.faqs.org/[...] 2016-05-28
[26] 웹인용 Unix Time-Sharing System Forward https://archive.org/[...] Bell Laboratories 1978-07-08


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com