노트KISS 원칙
Keep It Simple, Stupid
설계#architecture · 연결된 개념 12개
쉽게 말하면
KISS 원칙은 고장 나도 누구나 고칠 수 있게 물건을 단순하게 만들자는 거예요. 부품이 적은 자전거가 고장도 덜 나고 고치기도 쉽듯, 코드도 영리하게 꼬기보다 단순하게 써야 디버깅이 쉬워요.
비유가 깨지는 곳 단순함은 '쉬움'과 달라요. 익숙한 도구를 쓴다고 단순해지는 게 아니라 요소와 관계가 적은 쪽이 단순하고, 디버깅이 처음 쓰기보다 두 배 어려우니 영리한 코드일수록 고치기 힘들어요.
설계와 시스템은 가능한 한 단순해야 한다는 원칙. "Keep It Simple, Stupid"의 줄임말로, 1960년대 미 해군 설계 원칙에서 유래했다고 알려져 있다.
- 복잡성은 이해·유지보수·디버깅 비용을 모두 키운다. 단순한 해법이 대부분 더 잘 동작하고 결함도 적다
- 커니핸의 법칙(Kernighan's Law)이 근거가 된다. 디버깅은 코드를 처음 쓰는 것보다 두 배 어렵기 때문에, 코드를 최대한 영리하게 쓰면 정의상 그 코드를 디버깅할 만큼 영리하지 못하다
- 롭 파이크의 "멋진 알고리즘은 n이 작을 때 느리고 버그가 많다"도 같은 이야기다(롭 파이크의 프로그래밍 5규칙)
- 단순함은 "쉬움"과 다르다. 익숙한 도구를 쓰는 게 쉽다고 단순해지지는 않는다. 요소와 관계가 적은 쪽이 단순하다(구성요소 줄이기)
YAGNI, DRY 원칙, 심플 디자인과 함께 자주 묶인다. 단순하게 시작해 키워 가라는 골의 법칙가 시스템 수준의 KISS다. 파이썬의 "단순한 것이 복잡한 것보다 낫다"(파이썬의 선 (PEP 20))도 같은 정신이다.
출처: Laws of Software Engineering: KISS (Keep It Simple, Stupid) · Laws of Software Engineering: Kernighan's Law
연결된 개념
이 노트를 가리키는 문서
뜻이 가까운 노트
- SOLID 원칙
객체지향 설계를 위한 다섯 가지 원칙의 머리글자. 로버트 C. 마틴(Robert C. Martin)이 정리했고 마이클 페더스(Michael Feathers)가 SOLID라는 약어를 붙였다.
- 기술 부채
지금 지름길을 택한 대가로 나중에 갚아야 할 비용을 빚에 빗댄 말. 워드 커닝햄(Ward Cunningham)이 1992년에 처음 썼다. 원금은 언젠가 제대로 고치는 비용이고, 이자는 지저분한 코드 때문에 매번 더 드는 개발 시간이다.
- 섣부른 최적화
"섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.
- 의존성 역전 원칙
고수준 모듈(업무 규칙)이 저수준 모듈(데이터베이스(DB), HTTP(Hypertext Transfer Protocol) 클라이언트 같은 세부 구현)에 직접 의존하지 않고, 둘 다 추상화에 의존해야 한다는 원칙. 의존 방향이 "업무 → 세부"에서 "세부 → 추상화 ← 업무"로 뒤집힌다.
- 최소 놀람의 원칙
함수·API(Application Programming Interface)·UI(User Interface)는 사용자와 다른 개발자를 가장 덜 놀라게 하는 방식으로 동작해야 한다는 원칙. 이름과 관례에서 예측한 대로 움직여야 한다.