#2 Pragmatic Approach
2장 실용주의 접근법
💻 실용주의 프로그래머: Topic 8 좋은 설계의 핵심
1. 좋은 설계의 기준
“좋은 설계는 나쁜 설계보다 바꾸기 쉽다.”
이 문장은 실용주의 프로그래머의 설계 철학을 단 한 줄로 요약한다. 완벽한 설계란 존재하지 않는다. 시간이 지나면 환경이 바뀌고, 요구사항이 변하며, 기술도 낡아간다. 결국 진짜 좋은 설계란 변화에 쉽게 적응할 수 있는 구조, 즉 ETC (Easier to Change) 원칙을 따르는 것이다.
ETC의 핵심은 단순하다. 코드가 수정되거나 기능이 추가될 때, 전체 시스템이 쉽게 바뀌어야 한다는 것이다. 이를 위해 불필요한 결합을 줄이고, 역할을 분리하며, 이름을 명확히 붙여야 한다. 단일 책임 원칙(Single Responsibility Principle) 역시 이 흐름 안에 있다. 좋은 설계는 처음부터 완벽하게 짜인 구조가 아니라, 나중에 바꾸기 쉬운 코드로 완성된다.
2. ETC는 규칙이 아니라 ‘가치’
ETC는 “이렇게 해야 한다”는 강제 규칙이 아니다. 그것은 개발자가 스스로의 결정을 내릴 때마다 떠올려야 할 가치다. “이 설계가 나중에 바꾸기 쉬울까?” 이 질문이 바로 실용주의적 사고의 출발점이다.
ETC는 코드의 가독성, 이름의 명확함, 모듈의 독립성, 테스트 용이성 등 다양한 차원에서 작동한다. 이는 ‘지금 잘 동작하는 코드’를 만드는 것이 아니라, **“미래에 더 잘 바꿀 수 있는 코드”**를 만드는 것이다.
3. 교체 가능한 설계를 고민하라
설계의 진정한 목적은 코드의 교체 가능성이다. 특정 기능을 바꾸거나 확장할 때, 시스템 전체를 뜯어고치지 않고 일부만 수정할 수 있다면 그게 바로 좋은 설계다. 코드가 모듈화되어 있으면 새로운 요구사항이 와도 기존 구조를 유지한 채 확장할 수 있다.
즉, 교체 가능성은 단순히 기술적 완성도가 아니라 유지보수의 생산성을 결정한다. “교체가 쉽다”는 말은 결합도를 낮추고 응집도를 높이는 설계적 균형의 결과물이다.
4. ETC를 위한 실천법
항상 스스로에게 물어라: “내가 지금 수정하는 부분이 전체를 바꾸기 어렵게 만들지는 않았는가?”
테스트를 작성할 때도 생각하라: “이 테스트는 기능이 바뀌어도 쉽게 수정 가능한가?”
이름을 짓는 데 신중하라: 명확한 이름은 나중의 혼란을 줄이고, 코드의 의도를 설명한다.
교체가 가능한 구조를 설계하라: 한 기능의 변경이 다른 모듈에 최소한의 영향을 주도록 하라.
이 모든 질문은 ETC라는 가치로 수렴된다. 실용주의 프로그래머는 규칙을 따르기보다 원칙을 체화한다. 즉, “지금의 결정이 미래의 변화를 어렵게 만들지 않을까?”를 스스로 묻는 개발자다.
5. 실용적 결론
좋은 설계는 완벽한 설계가 아니다. 오히려 변화를 수용할 준비가 된 설계다. 바꾸기 쉬운 구조를 만든다는 것은 결국 인간적인 여유를 남기는 일이다. 불확실한 미래에 대비해, 코드를 유연하게 만들어 두는 것. 그것이 바로 실용주의 프로그래머가 말하는 ‘좋은 설계의 핵심’이다.
💻 실용주의 프로그래머: Topic 9 DRY — 중복의 해악
1. 중복은 단순한 반복이 아니다
‘DRY(Don’t Repeat Yourself)’ 원칙은 단순히 “복붙하지 말라”는 뜻이 아니다. 이 원칙의 본질은 ‘지식(knowledge)’의 중복을 피하라는 데 있다. 프로그램 내에서 동일한 개념이나 규칙이 여러 곳에서 표현되면, 나중에 수정할 때 그 모든 곳을 함께 바꿔야 한다. 이런 중복은 유지보수를 어렵게 만들고, 코드의 신뢰성을 떨어뜨린다. 결국 DRY는 “모든 지식을 시스템 내 단 한 번만, 명확하게 표현하라”는 선언이다.
2. 코드 안팎의 중복
DRY는 코드뿐 아니라 **의도(intent)**의 중복까지 포함한다. 같은 계산 로직이 반복되거나, 동일한 데이터 구조가 코드 여러 곳에 흩어져 있으면 이미 DRY 위반이다. 심지어 테스트 데이터, 문서 주석, DB 스키마 등에서도 같은 정보가 반복된다면 모두 같은 위험을 낳는다. 따라서 실용주의 프로그래머는 “어떤 정보를 바꿀 때, 내가 수정해야 할 곳이 하나뿐인가?”를 늘 자문해야 한다.
3. 다양한 형태의 중복
중복은 여러 형태로 나타난다.
표현상의 중복: 외부 시스템(API, 스키마, 저장소 등)과 연결되며 동일한 지식을 여러 번 표현하는 경우.
데이터 저장소의 중복: 데이터베이스, 캐시, 로그 등에서 같은 정보를 여러 소스에 나누어 저장하는 경우.
개발자 간 중복: 협업 중 서로 동일한 기능을 구현하거나 같은 문제를 해결하는 코드가 여러 버전으로 생기는 경우.
이런 중복은 피하기 어렵지만, 최소화할 수 있다. 내부 API를 명확히 문서화하고, 공용 명세를 정의하며, 공유된 툴로 테스트를 자동화하면 중복을 크게 줄일 수 있다. 핵심은 “모두가 같은 언어로 말하도록 만드는 것” 이다.
4. 재사용성과 DRY의 관계
DRY의 반대는 ‘재사용 불가능한 코드’다. 사람들은 대체로 재사용이 어렵다면 쉽게 포기한다. 따라서 실용주의 프로그래머는 “재사용하기 쉽게 만들라(Tip 16)”는 환경 자체를 설계한다. 명확한 API, 일관된 데이터 구조, 반복 없는 설계가 곧 재사용성을 높인다. 이는 단순히 코드를 절약하는 게 아니라, 시스템 전체의 **지식 일관성(knowledge integrity)**을 지키는 행위다.
요약하자면 DRY 원칙은 “코드를 줄이는 기술”이 아니라 ‘한 번의 변경으로 모든 곳이 바뀌는 시스템’을 만드는 사고방식이다. 실용주의 프로그래머는 중복을 없애며 코드를 정제하고, 유지보수 가능한 시스템이라는 장기적 이익을 추구한다.
Last updated