안녕하세요. 벌써 금요일이네요. 윗층에서 변기에 발포세정제를 넣은건지 저희 집 변기가 역류했네요...화장실 청소하느라 힘 다 빼고 하루를 시작하게 되었습니다. 저번 시간에는 SOLID에 대해서 간략하게 학습해보았습니다. 이번 시간에는 DRY와 리팩토링을 마무리로 개발 설계 원칙을 마무리할 것 같습니다. 그럼 시작해보겠습니다.
DRY
DRY(Don't Repeat Yourself)는 같은 내용을 반복하지 말라는 의미를 가진 개발 원칙으로 "모든 지식은 시스템 내에서 단일하고 명확하며 신뢰할 수 있는 표현을 가져야 한다"는 소프트웨어 개발 핵심 원칙입니다. 단순히 코드 줄 수를 줄이라는 의미가 아닌 같은 지식이나 같은 변경 이유가 여러 곳에 흩어지지 않도록 하라는 원칙에 가깝습니다.
즉, DRY의 핵심은 "같은 변경 이유를 가진 코드가 여러 곳에 반복되지 않도록 하는 것"입니다.
중복 코드가 위험한 이유
| 문제 | 설명 |
| 수정 범위 증가 | 같은 로직이 여러 곳에 있으면 변경 시 모두 수정해야함 |
| 실수 가능성 증가 | 일부 코드만 수정하고 다른 곳을 놓칠 수 있음 |
| 유지보수 어려움 | 어떤 코드가 실제 기준인지 파악하기 어려움 |
| 버그 발생 가능성 | 같은 기능인데 위치마다 동작이 달라질 수 있음 |
예를 들어 이메일 형식을 검증하는 로직이 회원가입, 회원정보 수정, 관리자 회원 등록 기능에 각각 따로 작성되어 있다고 가정해보겠습니다. 나중에 이메일 검증 규칙이 변경되면 세 곳을 모두 수정해야 합니다. 이때 한 곳이라도 수정하지 않으면 같은 이메일 검증 기능인데도 화면이나 API에 따라 다른 결과가 발생할 수 있습니다.
무조건 중복을 제거하면 좋을까?
DRY를 적용한다고 해서 모든 중복을 무조건 제거해야 하는 것은 아닙니다. 겉으로 보기에는 비슷해 보이는 코드라도 변경 이유가 다르면 억지로 하나로 합치지 않는 편이 더 나을 수 있습니다.
예를 들어 회원가입 요청 DTO와 관리자 회원 생성 요청 DTO가 비슷한 필드를 가지고 있다고 해서 무조건 하나의 DTO로 합치면 나중에 두 기능의 요구사항이 달라졌을 때 오히려 수정이 어려워질 수 있습니다.
회원가입은 사용자가 직접 입력하는 정보가 기준이고, 관리자 회원 생성은 관리자가 부여하는 권한이나 상태값이 추가될 수 있습니다. 이처럼 변경 이유가 다르다면 비슷해 보여도 분리하는 것이 더 적절할 수 있습니다.
즉, DRY는 단순히 같은 모양의 코드를 없애는 것이 아니라 같은 이유로 변경되는 중복을 줄이는 원칙입니다.
리팩토링
리팩토링은 외부 동작은 유지하면서 내부 코드 구조를 개선하는 작업입니다. 즉, 기능을 새로 추가하거나 동작 결과를 바꾸는 것이 아니라 같은 기능을 더 읽기 쉽고 수정하기 쉬운 구조로 정리하는 과정입니다.
예를 들어 하나의 Service 메서드 안에 검증, 계산, 저장, 응답 생성 로직이 모두 들어 있다면 처음에는 동작하더라도 시간이 지날수록 읽기 어려워질 수 있습니다. 이때 검증 로직은 별도 메서드로 분리하고, 계산 로직은 도메인 메서드로 옮기고, 응답 생성은 DTO 변환 메서드로 정리할 수 있습니다. 이러한 작업이 리팩토링에 해당합니다.
DRY와 리팩토링의 관계
DRY는 중복을 줄이기 위한 원칙이거, 리팩토링은 중복이나 복잡한 구조를 실제로 개선하는 과정입니다. 즉, DRY는 "어떤 방향으로 개선해야 하는지"에 대한 기준이 되고, 리팩토링은 그 기준에 따라 코드를 정리하는 작업이라고 볼 수 있습니다.
| 구분 | 의미 |
| DRY | 중복을 줄이기 위한 원칙 |
| 리팩토링 | 기능은 유지한 채 코드 구조를 개선하는 작업 |
| 관계 | DRY를 적용하는 과정에서 리팩토링이 사용될 수 있음 |
리팩토링할 때 주의할 점
리팩토링은 코드를 개선하는 작업이지만 잘못 진행하면 오히려 기존 기능을 깨뜨릴 수 있습니다. 따라서 리팩토링 할 때는 몇 가지를 주의해야 합니다.
- 기능 변경과 리팩토링을 한 번에 진행하지 않기
- 테스트 코드나 Postman 테스트로 기존 동작을 확인하기
- 한 번에 너무 많은 구조를 바꾸지 않기
- 중복 제거가 오히려 복잡성을 높이지 않는지 확인하기
- 변경 이유가 다른 코드를 억지로 합치지 않기
좋은 리팩토링은 코드를 무조건 짧게 만드는 것이 아니라 다음 변경을 더 안전하고 쉽게 만들 수 있도록 구조를 정리하는 것입니다.
DRY와 리팩토링을 통해 개발 설계 원칙에 대한 학습을 끝마치도록 하겠습니다. 다음 시간에는 아키텍처 패턴으로 돌아오도록 하겠습니다. 수고하셨습니다.
'백엔드 공부' 카테고리의 다른 글
| 아키텍처 패턴(2) - CQRS, 이벤트 소싱, 서버리스란 무엇인가? (0) | 2026.05.25 |
|---|---|
| 아키텍처 패턴(1) - 모놀리식, MSA, SOA란 무엇인가? (0) | 2026.05.24 |
| 개발 설계 원칙(2) - SOLID (0) | 2026.05.21 |
| CI/CD(2) - CI/CD 도구와 GitHub Actions (0) | 2026.05.19 |
| CI/CD(1) - CI/CD란 무엇인가? (0) | 2026.05.18 |