본문으로 건너뛰기

KISS 원칙

개념

복잡성을 피하고 단순함을 설계의 핵심 목표로 삼아야 한다는 공학 및 소프트웨어 설계 원칙

목차22개 항목

KISS 원칙(KISS principle, Keep It Simple, Stupid)은 대부분의 시스템이 복잡하게 설계되기보다 단순하게 설계될 때 가장 잘 작동하므로, 설계 과정에서 단순함을 핵심 목표로 삼고 불필요한 복잡성을 피해야 한다는 공학 설계 원칙이다. 소프트웨어 공학을 포함한 여러 공학 분야와 제품 설계, 사용자 경험 설계 등에서 폭넓게 통용되는 경험칙으로, 특정 개인이나 기관이 엄밀하게 정식화한 이론이라기보다 실무 경험을 통해 형성되고 전파된 설계 지침에 가깝다.

이 명칭은 록히드사의 항공 엔지니어 켈리 존슨과 연관되어 전해지며, 그가 이끌던 비밀 개발 부서인 스컹크 웍스에서 야전 정비사가 기본적인 공구만으로도 수리할 수 있을 만큼 단순한 항공기 설계를 요구한 데서 비롯되었다고 알려져 있다. 이와 별개로 단순함을 유지하라는 취지의 설계 지침 자체는 1960년 미국 해군의 한 문서에서도 명시적으로 다루어진 바 있으며, 이후 1970년 무렵부터 ’원칙’이라는 이름으로 여러 업계 간행물에 등장하며 대중화되었다. ’어리석다’는 표현이 다소 거칠게 느껴진다는 지적에 따라 뒷부분만 순화한 여러 변형 표현도 함께 통용된다.

소프트웨어 공학에서 KISS 원칙은 코드와 시스템 구조를 필요 이상으로 복잡하게 만들지 말아야 한다는 지침으로 받아들여지며, 캔트 벡이 제시한 익스트림 프로그래밍의 다섯 가지 핵심 가치 가운데 하나인 단순성과 직접적으로 연결된다. 오컴의 면도날, 유닉스 철학, YAGNI, Worse Is Better 등 단순성을 강조하는 다른 개념들과 함께 언급되는 경우가 많으며, 이들 개념은 서로 다른 시대와 맥락에서 등장했지만 불필요한 요소를 배제하고 이해와 유지보수가 쉬운 결과물을 지향한다는 공통점을 지닌다.

실무에서 KISS 원칙은 코드 수준에서는 읽기 쉬운 구조와 필요한 만큼의 추상화를 지향하는 형태로, 시스템 설계 수준에서는 각 구성 요소가 하나의 역할만 수행하도록 나누는 형태로 나타난다. 벨 연구소에서 형성된 유닉스 철학이나 리처드 개비얼이 제시한 Worse Is Better 논의는 이러한 적용 양상을 보여주는 대표적인 사례로 거론된다.

다른 한편으로 KISS 원칙은 무엇이 충분히 단순한 상태인지에 대한 명확한 기준을 제시하지 않기 때문에, 필요한 기능이나 예외 처리까지 제거하는 과잉 단순화로 이어질 수 있다는 비판을 받기도 한다. 프레더릭 브룩스는 소프트웨어의 복잡성을 문제 영역 자체에서 비롯되는 본질적 복잡성과 도구·기법의 한계에서 비롯되는 부수적 복잡성으로 구분하며 단순화가 다룰 수 있는 범위에 한계가 있다고 지적했으며, 리치 히키는 단순함과 쉬움이 흔히 혼동되는 서로 다른 개념이라고 구분해 논의를 정교화했다.

어원과 정의

명칭의 유래

KISS는 ’단순하게 유지하라, 이 바보야’라는 문구의 머리글자를 딴 두문자어이다. 다만 이 표현을 처음 사용한 것으로 전해지는 켈리 존슨 본인은 쉼표 없이 표기했다고 전해지며, 이 표기 방식이 오늘날에도 여러 문헌에서 함께 쓰인다. ’어리석다’는 단어가 설계자나 사용자를 낮잡아 부르는 것으로 오인될 수 있다는 우려에 따라, 동일한 두문자를 유지하면서 뒷부분만 순화한 ’단순하고 명료하게 유지하라’나 ‘지나칠 정도로 단순하게 유지하라’ 등의 변형 표현도 함께 통용된다.

소프트웨어 공학에서의 정의

소프트웨어 공학에서 KISS 원칙은 주어진 요구 사항을 충족하는 여러 설계안 가운데 불필요한 요소가 가장 적은 설계를 선호해야 한다는 지침으로 정의된다. 여기서 단순함은 코드의 물리적인 줄 수가 적다는 의미에 국한되지 않으며, 구성 요소 간의 의존 관계가 적고 동작을 예측하기 쉬우며 읽는 사람이 적은 노력으로 의도를 파악할 수 있는 상태를 가리키는 경우가 많다. 이러한 정의는 명확한 수치나 기준으로 환원되기 어렵기 때문에, KISS 원칙은 엄밀한 공학적 법칙이라기보다 설계 판단을 이끄는 경험칙으로 다루어진다.

역사적 배경

켈리 존슨과 록히드 스컹크 웍스

KISS라는 표현이 가장 널리 연관되는 인물은 록히드사의 항공 엔지니어 클래런스 켈리 존슨이다. 존슨은 U-2 정찰기와 SR-71 블랙버드를 비롯해 40종이 넘는 항공기 설계에 관여했으며, 록히드의 비밀 개발 부서인 스컹크 웍스를 이끌었다. 록히드의 엔지니어였던 벤 리치가 1995년 미국 국립과학원을 위해 작성한 존슨의 전기적 회고록에 따르면, 존슨은 설계팀에게 전장에서 기본적인 정비 훈련만 받은 인원이 간단한 공구만으로도 수리할 수 있을 정도로 항공기를 단순하게 설계하라고 요구했다고 전해진다. 복잡한 장비나 정밀한 부품에 의존하는 설계는 전투 환경에서 쉽게 무용지물이 될 수 있다는 것이 그 이유였다.

미 해군과 용어의 확산

KISS라는 표현이 공식 문서에 명시적으로 등장한 사례로는 1960년 미국 해군의 한 설계 지침이 거론된다. 언어학자 톰 댈젤은 저서에서 폴 D. 스트루프 해군 소장이 이끈 프로젝트가 1960년 시카고의 한 일간지에 보도되었다고 서술했다. 이후 ’키스 원칙’이라는 명칭 자체는 1970년 무렵부터 여러 업계 간행물에서 대중적으로 쓰이기 시작했으며, 항공·군사 공학의 경계를 넘어 제품 설계와 경영 전반으로 확산되었다.

소프트웨어 공학으로의 편입

소프트웨어 공학에서 KISS 원칙이 명시적인 설계 가치로 자리 잡은 대표적인 사례로 캔트 벡이 1999년 제시한 익스트림 프로그래밍을 들 수 있다. 벡은 익스트림 프로그래밍을 구성하는 다섯 가지 핵심 가치로 의사소통, 단순성, 피드백, 용기, 존중을 제시했으며, 이 가운데 단순성을 다섯 가치 중 지적으로 가장 까다로운 것이라고 설명하면서 팀이 당장 통할 수 있는 가장 단순한 해법이 무엇인지 스스로 질문해야 한다고 서술했다. 존중은 2004년 출간된 개정판에서 추가된 다섯 번째 가치이다. 이후 KISS라는 이름 자체는 익스트림 프로그래밍뿐 아니라 다양한 소프트웨어 개발 방법론과 교육 자료에서 폭넓게 인용되며 일반적인 설계 원칙으로 자리 잡았다.

핵심 특징

복잡성과 오류 가능성의 관계

KISS 원칙을 뒷받침하는 근거로 흔히 제시되는 논리는 구성 요소가 늘어날수록 요소 사이의 상호작용 경우의 수가 함께 늘어나 오류가 발생할 지점도 함께 늘어난다는 것이다. 이 논리에 따르면 하나의 기능이나 코드 조각을 추가하는 일은 그 자체의 복잡성뿐 아니라 기존 요소들과 맺는 관계의 복잡성까지 함께 가져오므로, 설계자는 새로운 요소를 더하기 전에 그것이 실제로 필요한지를 검토해야 한다. 이러한 사고방식은 YAGNI나 오컴의 면도날과 같이 단순성을 추구하는 다른 원칙들과도 상당 부분 맞닿아 있다.

단순함과 쉬움의 구분

클로저 언어의 설계자인 리치 히키는 2011년 스트레인지 루프 콘퍼런스에서 발표한 강연 「단순함을 쉬움으로 만들기」에서 단순함과 쉬움을 구분해야 한다고 주장했다. 히키에 따르면 단순함은 하나의 역할, 하나의 개념만을 다루어 요소들이 서로 얽혀 있지 않은 객관적인 상태를 가리키는 반면, 쉬움은 익숙하거나 손에 닿기 쉽다는 상대적이고 주관적인 성질을 가리킨다. 그는 개발자가 당장 편리한 도구나 프레임워크를 선택하는 행위가 반드시 단순한 결과로 이어지지는 않으며, 오히려 서로 다른 개념을 뒤섞는 선택이 장기적으로 복잡성을 키울 수 있다고 설명했다. 이 구분은 KISS 원칙을 적용할 때 익숙해서 편한 방법과 실제로 단순한 방법을 혼동하지 않아야 한다는 점을 부각하는 논의로 받아들여진다.

소프트웨어 개발에서의 적용

코드 수준의 적용

코드 작성 단계에서 KISS 원칙은 읽는 사람이 적은 노력으로 의도를 파악할 수 있는 구조를 지향하는 형태로 나타난다. 명확한 이름을 가진 함수와 변수를 사용하고, 문제 해결에 실제로 필요한 만큼의 조건 분기와 추상화 계층만을 두며, 아직 검증되지 않은 미래의 요구 사항에 대비한 일반화된 구조를 미리 만들어 두지 않는 방식이 대표적으로 거론된다. 이러한 적용은 소프트웨어 공학 교육 자료에서 정교해 보이는 코드보다 명료한 코드를 우선해야 한다는 조언으로 자주 소개된다.

아키텍처 및 시스템 설계 수준의 적용

시스템 설계 수준에서 KISS 원칙이 가장 자주 인용되는 사례는 벨 연구소에서 형성된 유닉스 철학이다. 유닉스 파이프의 고안자인 더그 매킬로이는 1978년 벨 시스템 기술 저널에 실린 글에서, 하나의 프로그램이 한 가지 일만 잘 수행하도록 만들고 프로그램들이 서로 협력할 수 있도록 작성하며 프로그램 사이에 주고받는 자료로는 보편적인 인터페이스인 텍스트 스트림을 사용하라고 제안했다. 이 원칙에 따라 만들어진 유닉스의 여러 명령줄 도구들은 각각 좁은 범위의 단일한 기능만을 수행하며, 필요할 때 서로 연결해 더 복잡한 작업을 수행하는 방식으로 활용된다. 리처드 개비얼이 1989년 발표한 Worse Is Better 논의는 유닉스와 C 언어의 성공 요인을 구현의 단순성을 인터페이스의 완결성보다 우선한 설계 태도에서 찾으며, 이러한 사례를 KISS적 사고가 실제 시스템 설계에 반영된 예로 든다.

관련 개념과의 관계

KISS 원칙은 그 자체로 독립적인 이론이라기보다, 단순성을 강조하는 여러 개념들과 서로 겹치거나 갈라지는 지점을 가진 사고방식의 하나로 다루어지는 경우가 많다.

graph TD
    A[오컴의 면도날] --> B[KISS 원칙]
    B --> C[YAGNI]
    B --> D[Worse Is Better]
    B --> E[유닉스 철학]
개념 핵심 초점 최초 제시 맥락
KISS 원칙 시스템 전반의 불필요한 복잡성 배제 항공공학·미 해군, 1960년대
오컴의 면도날 불필요한 가정의 배제 14세기 스콜라 철학
YAGNI 당장 필요하지 않은 기능의 배제 익스트림 프로그래밍, 1990년대
DRY 코드 중복의 배제 실용주의 프로그래머, 1999년
Worse Is Better 구현 단순성의 우선순위화 유닉스·리스프 진영 논쟁, 1989년

오컴의 면도날

KISS 원칙보다 훨씬 앞서 등장한 사고방식으로는 14세기 스콜라 철학자 오컴의 윌리엄이 제시한 것으로 전해지는 오컴의 면도날이 있다. 오컴의 면도날은 여러 설명이나 가설이 동일한 현상을 설명할 수 있다면 불필요한 가정을 가장 적게 포함한 설명을 선택해야 한다는 원칙으로, 소프트웨어 설계에서는 동일한 요구 사항을 충족하는 여러 구현안 가운데 가장 적은 구성 요소로 이루어진 안을 선호해야 한다는 논리로 종종 원용된다. 다만 오컴의 면도날은 본래 참과 거짓을 가리는 인식론적 도구로 제시된 것이며, 공학적 설계 원칙인 KISS와는 등장한 맥락과 적용 대상이 다르다는 점에서 구분된다.

YAGNI와 DRY

YAGNI는 익스트림 프로그래밍에서 함께 제시된 원칙으로, 당장 필요하지 않은 기능은 미리 구현하지 말아야 한다는 지침을 담고 있다. YAGNI가 무엇을 만들 것인가라는 범위의 문제에 초점을 맞춘다면, KISS는 만들기로 한 것을 어떻게 구현할 것인가라는 방식의 문제에 좀 더 가깝게 적용되는 경우가 많아, 두 원칙은 서로 다른 층위에서 단순성을 뒷받침하는 것으로 설명되곤 한다. 한편 중복을 피해야 한다는 DRY 원칙은 중복된 코드를 하나의 추상화로 묶어내는 과정에서 오히려 새로운 개념과 의존 관계를 만들어낼 수 있어, 실무에서는 DRY를 적용하는 정도와 KISS가 요구하는 단순함 사이에서 균형을 찾아야 한다는 논의가 이루어진다.

Worse Is Better

리처드 개비얼은 Worse Is Better 논의에서 좋은 설계가 갖추어야 할 성질을 단순성, 정확성, 일관성, 완결성 네 가지로 나누고, 이 가운데 구현의 단순성을 가장 높은 우선순위에 두어야 한다고 제안했다. 그는 완결성은 구현의 단순성을 해치는 경우 가장 먼저 희생되어야 하는 성질이라고 서술했으며, 이러한 태도를 ’뉴저지 스타일’이라 부르고 완결성과 일관성을 우선시하는 ’MIT·스탠퍼드 스타일’과 대비시켰다. Worse Is Better는 KISS 원칙이 정확성이나 기능의 완결성과 충돌할 때 무엇을 우선할 것인가에 대해 하나의 구체적인 입장을 제시한 논의로 받아들여진다.

비판과 논쟁

과잉 단순화의 위험

KISS 원칙에 대한 비판은 주로 무엇이 충분히 단순한 상태인지 판단할 명확한 기준이 없다는 점에서 출발한다. 여러 소프트웨어 공학 해설 자료들은 KISS 원칙을 잘못 적용할 경우 오류 처리나 보안, 확장성을 위해 필요한 요소까지 제거해 오히려 취약한 설계로 이어질 수 있다고 지적한다. 이러한 논의에서는 단순함 자체가 목적이 아니라 요구 사항을 충족하면서 불필요한 부분만을 덜어내는 것이 KISS 원칙의 취지이며, 필요한 기능까지 생략하는 것은 원칙의 오용이라는 점이 강조된다.

본질적 복잡성과의 관계

소프트웨어 공학자 프레더릭 브룩스는 1986년 발표한 논문 “No Silver Bullet: Essence and Accident in Software Engineering”에서 소프트웨어가 지닌 복잡성을 문제 영역 자체에서 비롯되는 본질적 복잡성과, 도구나 표현 수단의 한계에서 비롯되는 부수적 복잡성으로 구분했다. 브룩스는 고급 프로그래밍 언어와 같은 발전이 부수적 복잡성을 상당 부분 줄여 왔지만 본질적 복잡성은 어떤 기법으로도 제거할 수 없다고 주장했다. 이 구분은 KISS 원칙이 다룰 수 있는 범위가 대체로 부수적 복잡성에 한정되며, 문제 영역 자체가 요구하는 복잡성까지 단순화로 없앨 수는 없다는 점을 짚는 근거로 인용되곤 한다.

같이 보기

  • YAGNI
  • DRY
  • 오컴의 면도날
  • 유닉스 철학
  • Worse Is Better
  • 관심사의 분리
  • 익스트림 프로그래밍
  • 본질적 복잡성과 부수적 복잡성
  • 미니멀리즘

참고 자료

  • Rich, Ben R. (1995), “Clarence Leonard (Kelly) Johnson 1910–1990: A Biographical Memoir”, Biographical Memoirs Volume 67, National Academies Press
  • Dalzell, Tom (2009), The Routledge Dictionary of Modern American Slang and Unconventional English, Routledge
  • Brooks, Frederick P. Jr. (1987), “No Silver Bullet: Essence and Accidents of Software Engineering”, IEEE Computer, Vol. 20, No. 4
  • Gabriel, Richard P. (1989), “The Rise of ‘Worse is Better’”
  • Beck, Kent; Andres, Cynthia (2004), Extreme Programming Explained: Embrace Change (2nd ed.), Addison-Wesley
  • McIlroy, M. D.; Pinson, E. N.; Tague, B. A. (1978), “Unix Time-Sharing System: Foreword”, The Bell System Technical Journal, Vol. 57, No. 6
  • Hickey, Rich (2011), “Simple Made Easy” (강연), Strange Loop Conference
  • Hunt, Andrew; Thomas, David (1999), The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley