프로그래밍에서 Rule of Three 이란?

Rule of three(세 가지 법칙)는 디자인, 프로그래밍 등 여러 분야에서 적용되는 개념이다.
“세 개가 모이면 패턴이 된다 “는 아이디어로 기반이 되었다고 한다.

프로그래밍에서 Rule of three 개념은 “같은 코드가 두 번 반복은 괜찮으나 세 번째 반복이면 추상화를 해라 “이다.

개념은 쉽고 명료하다. 말 그대로 세 번 반복되었을 때 리팩토링 하는 것이니까
하지만 만약 이 개념을 모르고 개발을 하고 있었다면 많은 어려움이 있었을 것이다.

---

Rule of Three를 몰랐을 때 벌어질 수 있는 실수

맡은 프로젝트에서 쇼핑몰을 개발한다고 가정해 보자.

당연히 상품을 보여주는 Card 컴포넌트는 필수적이다. 
그러니 이걸 미리 공통 컴포넌트로 추상화하기로 했다.

 

개발하다 보면 이것저것 생각하며 추가하게 되었다.

• “만약 이미지를 표시하지 않는 카드가 필요하면?”
• “가격을 숨겨야 하는 경우는?”
• “이미지가 슬라이드 형태로 변해야 한다면?”
• “특정 상품은 배경색이 달라야 한다면?”

아직 실제 요구 사항도 나오지 않았는데, 미리 모든 경우의 수를 고려해서 만들기 시작한 것이다.
결과적으로 너무 많은 옵션과 분기를 가진 거대한 Card 컴포넌트가 탄생하게 된다.

그러나 정작 프로젝트가 진행되면서 사용하지 않는 기능이 생기고, 예상하지 못한 기능이 추가가 되는 것이다.
결국, 시간과 노력을 들여 만든 복잡한 컴포넌트를 유지보수해야 하는 빚을 지게 된 것이다.

이게 바로 Rule of Three를 몰랐을 때 겪게 되는 실수다.
미리 추상화를 하려고 하다 보니, 실제 필요하지 않은 기능까지 설계해 버리고, 오히려 코드가 복잡해지는 것.

---

Rule of Three를 알았다면?

Rule of Three를 알고 있었다면 결과는 달랐을 것이다.

 

1. 처음에는 요구된 기능만을 포함한 Card 컴포넌트를 만든다.
2. 비슷하지만 기능이 약간 다른 Card 컴포넌트가 필요해지면, 기존 코드에서 필요한 부분만 복사하여 사용한다.
3. 세 번째로 또 다른 Card 컴포넌트를 만들려 할 때, 이전 두 개의 Card와 동일한 기능이 반복된다면, 그 기능을 추상화하여 공통 모듈로 만든다.

이 과정을 따르면, 각 Card 컴포넌트에는 불필요한 기능이 포함되지 않으며,
반복되는 코드들은 재사용하기 쉬운 컴포넌트 또는 모듈로 자연스럽게 정리될 것이다.

몰랐을 때의 결과를 비교하면 시간도 아끼고, 유지보수도 쉬워진다.

---

 

먼저, 나중에는 개발자에게 빚이 될 수 있다.

소프트웨어 개발에서는 적절한 추상화와 코드 재사용이 중요하다.
하지만 너무 이른 추상화는 오히려 유지보수 부담을 증가시키고,
반대로 필요한 시점에 리팩터링 하지 않으면 코드 중복이 쌓여 기술 부채가 된다.

이런 문제를 해결하는 실용적인 원칙이 바로 Rule of Three(세 가지 법칙)이다.

 

Rule of Three 개념을 떠올리다 보면,
소프트웨어 개발의 중요한 원칙 두 가지가 함께 떠오른다.

• YAGNI(You Ain’t Gonna Need It) 원칙 → 현재 필요 없는 코드를 작성하지 말자.
• DRY(Don’t Repeat Yourself) 원칙 → 반복되는 코드가 있으면 분리하자.

Rule of Three를 알고 개발하면, 자연스럽게 YAGNI 원칙과 DRY 원칙을 지킬 수 있다.

YAGNI 원칙을 지켜 불필요한 기능을 미리 구현하지 않게 되고,

DRY 원칙을 따르며, 세 번째 반복이 발생했을 때만 추상화하여 코드 재사용성을 높일 수 있다.

즉, Rule of Three는 단순히 “세 번 반복되면 추상화하라 “ 는 개념을 넘어서,
YAGNI와 DRY 원칙을 실천하도록 도와주는 실용적인 가이드라인이 될 수 있다.

 

Rule of Three 개념을 리팩토링을 할 때 적용하는 것도 좋지만,
처음 개발을 시작할 때부터 이 원칙을 염두에 두면 더욱 효과적인 거 같다.