“나중에 필요할 것 같은데, 미리 만들어둘까요?”
개발하다 보면 이 유혹이 정말 자주 찾아옵니다. 설정 옵션도 미리 빼두고, 다국어 지원 구조도 미리 잡아두고, 어드민에서 바꿀 수 있게 테이블도 미리 파두고요.
오늘 다룰 YAGNI가 바로 이 유혹에 정면으로 “아니요”라고 답하는 원칙입니다. KISS, DRY와 함께 개발 원칙 3대장으로 불리죠.
YAGNI는 “You Aren’t Gonna Need It”의 약자입니다. “그거, 어차피 필요 없을 거야”라는 뜻이에요.
익스트림 프로그래밍(XP)이라는 개발 방법론에서 나온 말인데, 켄트 벡과 론 제프리스 같은 XP 진영 사람들이 입버릇처럼 쓰던 표현이 원칙으로 굳어진 겁니다.
핵심 주장은 하나예요.
기능은 실제로 필요해질 때 구현하라. 필요할 것 같다고 예상될 때가 아니라.
미리 만들면 뭐가 문제인데요?
“미리 만들어두면 나중에 편하잖아요?“라는 반론이 바로 나올 텐데요. 문제는 그 예측이 대부분 틀린다는 겁니다.
마틴 파울러가 이 주제로 정리한 글에서 미리 만든 기능의 비용을 네 가지로 나눠요.
| 비용 | 내용 |
|---|---|
| 구현 비용 | 지금 당장 안 쓸 기능을 만드는 데 들어간 시간 |
| 지연 비용 | 그 시간에 만들었어야 할 진짜 기능이 늦어짐 |
| 유지 비용 | 안 쓰는 코드도 테스트·리팩토링·버그 수정은 계속 따라옴 |
| 수리 비용 | 막상 필요해진 시점엔 요구사항이 달라서 뜯어고쳐야 함 |
제일 아픈 게 마지막이에요. “나중”이 진짜로 왔을 때, 그 나중의 요구사항은 내가 예상했던 모양과 거의 항상 다릅니다. 결국 미리 만든 코드를 뜯어고치는 비용까지 이중으로 내는 거죠.
실무에서 YAGNI가 깨지는 장면들
말로 하면 다들 고개를 끄덕이는데, 실전에서는 이런 모습으로 슬쩍 들어옵니다.
1. 파라미터 미리 빼두기
// 지금은 이메일 알림뿐인데
func sendNotification(user: User, message: String, channel: String = "email",
retryCount: Int = 3, priority: String = "normal",
template: String? = nil) {
// channel이 "email"일 때만 동작하는 코드
}호출하는 곳은 전부 sendNotification(user: user, message: msg)뿐입니다. 나머지 파라미터는 “나중에 슬랙 알림 붙일 때 쓰려고” 만든 건데, 슬랙 알림 요구는 끝내 들어오지 않았습니다.
2. 프로토콜 미리 깔기
구현체가 하나뿐인데 프로토콜부터 만드는 경우요. UserService 하나 만들면서 UserServiceProtocol을 같이 만드는 패턴인데, 두 번째 구현체가 등장하기 전까지 그 프로토콜은 파일 수만 늘리는 장식품입니다.
3. “설정으로 빼두면 좋잖아요”
하드코딩이 무서워서 모든 값을 설정 파일과 어드민 화면으로 빼는 경우. 정작 그 설정을 바꾸는 일은 1년에 한 번도 없고, 설정이 늘어날수록 “이 값 바꾸면 어디에 영향 가요?“라는 질문만 늘어납니다.
YAGNI가 아닌 것들
오해를 막기 위해 선을 그어둘게요. YAGNI는 이런 뜻이 아닙니다.
먼저, 설계를 하지 말라는 게 아니에요. 코드를 고치기 쉽게 짜는 노력(좋은 이름, 작은 함수, 테스트)은 지금 당장 가치가 있는 일이라 YAGNI 대상이 아닙니다. 오히려 코드가 고치기 쉬워야 “필요해진 그때” 빠르게 만들 수 있어요.
그리고 되돌리기 어려운 결정까지 미루라는 것도 아닙니다. 데이터베이스 선택이나 API 공개 스펙처럼 한 번 정하면 바꾸기 힘든 것들은 미리 고민하는 게 맞아요. YAGNI가 겨냥하는 건 “나중에 쉽게 추가할 수 있는데도 미리 만드는 기능”입니다.
제가 쓰는 판단 기준
저는 “미리 만들어둘까?” 싶을 때 두 가지를 물어봅니다.
이 기능이 필요하다는 근거가 로드맵에 있나, 아니면 내 상상 속에 있나?
나중에 추가하면 지금보다 훨씬 비싸지나?
근거가 상상이고, 나중에 추가해도 비용이 비슷하다면 안 만듭니다. 대부분의 경우가 여기에 해당하더라고요.
마무리
YAGNI 원칙에서 챙겨갈 건 세 가지입니다.
- 기능은 필요해질 때 만드세요. 필요할 것 같을 때가 아니라요.
- 미리 만든 기능은 구현·지연·유지·수리 비용을 사중으로 청구합니다.
- 단, 좋은 설계 습관과 되돌리기 어려운 결정은 YAGNI 대상이 아닙니다.
KISS, DRY에 이어 YAGNI까지 놓고 보면 세 원칙은 결국 하나의 문장으로 모여요. 오늘 필요한 것을, 단순하게, 한 곳에만 만들어라.
“언젠가 쓰겠지” 하고 만들어둔 채 잠자는 기능이 하나라도 있다면, 2년 뒤에 본인 손으로 지우게 될지도 모릅니다.