개발하다 보면 이상하게 코드를 어렵게 짜야 잘하는 것 같은 기분이 들 때가 있어요.
디자인 패턴도 잔뜩 넣고 추상화 레이어도 쌓고 “나중에 확장할 수도 있으니까” 하면서 인터페이스를 미리 파두고요.
그런데 몇 년 지나서 그 코드를 다시 열어보면, 정작 고생하는 건 미래의 자신이더라고요.
오늘은 그 반대편에 서 있는 원칙, KISS 이야기를 해볼게요.
결론부터 말씀드리면, KISS는 “Keep It Simple, Stupid”의 약자입니다. 직역하면 “단순하게 해, 바보야” 정도 되는데요.
시스템은 복잡하게 만들 때가 아니라 단순하게 유지할 때 가장 잘 동작한다는 설계 철학이에요.
KISS 원칙, 어디서 나온 말일까?
이 말은 원래 소프트웨어 용어가 아니었어요.
1960년대 미국 록히드사의 항공 엔지니어 켈리 존슨(Kelly Johnson)이 만든 말로 알려져 있습니다. 그 유명한 U-2, SR-71 블랙버드 정찰기를 설계한 사람이에요.
켈리 존슨이 팀에 요구한 건 이거였다고 해요.
전투 상황에서 평범한 정비사가 기본 공구만 가지고 고칠 수 있는 비행기를 만들어라.
아무리 뛰어난 설계라도 현장에서 고칠 수 없으면 소용없다는 거죠.
이 정신이 소프트웨어로 넘어온 겁니다. 아무리 기발한 코드라도 동료가 읽고 고칠 수 없으면 좋은 코드가 아니라는 얘기예요.
참고로 “Stupid”는 개발자를 바보라고 부르는 게 아니라, “바보도 이해할 만큼 단순하게”라는 뉘앙스에 가깝습니다.
코드에서 KISS가 깨지는 순간들
말로는 쉬운데, 실제 코드에서는 어떤 모습일까요? 제가 자주 봤던 패턴 몇 가지를 보여드릴게요.
1. 있어 보이는 한 줄
// 이렇게 쓰면 똑똑해 보이지만
let result = arr.reduce([Int: Item]()) { $0.merging([$1.id: $1]) { _, new in new } }
// 이게 훨씬 읽기 쉽습니다
var result = [Int: Item]()
for item in arr {
result[item.id] = item
}위 코드는 짧지만 처음 보는 사람은 한참 들여다봐야 해요. 아래 코드는 누가 봐도 3초면 이해합니다.
2. 쓰지도 않을 확장성
버튼 하나 만드는데 팩토리 패턴에 전략 패턴까지 동원하는 경우요. “나중에 버튼 종류가 늘어나면?” 하는 걱정 때문인데, 그 ’나중’은 대부분 오지 않습니다.
3. 조건문 미로
if 안에 if, 그 안에 또 if. 세 단계만 중첩돼도 머릿속 스택이 터지죠. 이럴 땐 early return으로 펼치기만 해도 코드가 확 단순해져요.
KISS를 지키는 실전 기준 3가지
그래서 저는 코드 쓸 때 이 세 가지를 기준으로 삼고 있어요.
| 기준 | 질문 |
|---|---|
| 설명 테스트 | 이 코드를 옆자리 동료에게 1분 안에 설명할 수 있나? |
| 미래 테스트 | 6개월 뒤의 내가 봐도 바로 이해할까? |
| 필요 테스트 | 지금 당장 필요해서 넣은 코드인가, 언젠가 쓸 것 같아서 넣은 코드인가? |
셋 중 하나라도 “아니요”가 나오면 더 단순한 방법이 없는지 다시 생각해봅니다.
특히 세 번째가 중요한데요, 이건 YAGNI(You Aren’t Gonna Need It) 원칙과도 통하는 부분이에요. KISS와 YAGNI는 사실상 한 세트로 움직입니다.
단순한 것과 대충 만든 것은 다릅니다
여기서 오해하면 안 되는 게 하나 있어요.
KISS는 “생각 없이 짜라”는 뜻이 아닙니다. 오히려 반대예요.
복잡하게 만드는 건 쉽습니다. 떠오르는 대로 다 붙이면 되니까요. 단순하게 만드는 게 어렵습니다. 뭘 뺄지 치열하게 고민해야 하거든요.
파스칼이 편지에 남긴 유명한 말이 있죠.
더 짧게 쓸 시간이 없어서 길게 씁니다.
코드도 똑같아요. 단순한 코드는 대충 만든 결과물이 아니라, 복잡함을 걷어내는 노력의 결과물입니다.
정리하며
KISS 원칙, 요약하면 이렇습니다.
- 코드는 쓰는 시간보다 읽히는 시간이 훨씬 깁니다. 읽는 사람을 위해 단순하게 쓰세요.
- 지금 필요 없는 확장성은 넣지 마세요. 그 걱정이 현실이 되는 일은 생각보다 드뭅니다.
- 단순함은 실력 부족이 아니라 실력의 증거입니다.
저는 요즘 코드 리뷰에서 “이거 더 단순하게 안 될까요?“라는 코멘트를 제일 많이 남기는 것 같아요. 신기하게도 이 질문 하나로 버그도 줄고 리뷰 시간도 줄더라고요.
여러분의 코드는 옆자리 동료가 1분 안에 이해할 수 있나요? 오늘 한 번 스스로에게 물어보시면 좋겠습니다.