SRP 리팩터링 체크리스트: 코드 냄새 없애는 7단계

“클래스가 바뀌어야 할 이유는 단 하나여야 한다.” 이 단순한 문장이 지켜지지 않을 때 나타나는 것이 바로 거대 클래스, if‒else 난무, UnsupportedOperationException 남발 같은 대표적인 코드 냄새입니다. 국내 개발자들이 많이 찾은 SRP(단일 책임 원칙) 리팩터링 후기들을 종합해, 실무에서 바로 써먹을 7단계 체크리스트를 정리했습니다. 

---

1. 코드 냄새 스캐닝

• new 나 if(type)가 몰려 있는 거대 메서드
• 한 클래스에 DB + 네트워크 + 뷰 로직이 섞여 있는 경우
• 인터페이스 구현체가 사용하지 않는 메서드에 예외를 던질 때

2. 책임 라벨링

클래스·메서드마다 “이 로직은 누구를 위해 존재하나?” 메모를 붙여보세요.
라벨이 두 개 이상이면 SRP 위반 후보입니다.

3. 행위·데이터 분리

• 행위: 계산, 외부 호출, 상태 변화
• 데이터: 단순 보관 객체(VO·DTO)
  둘을 같은 클래스에 섞어두면 변경 이유가 복수로 늘어납니다.

4. 인터페이스 추출

변화가 잦은 로직은 interface로 뽑고, 구현체를 여러 개로 나눕니다.
스프링이라면 빈 주입, Kotlin이라면 Koin 모듈로 DI 설정을 옮겨주세요.

5. 의존성 방향 확인

고수준(서비스) 모듈이 저수준(구현) 모듈을 직접 생성(new)하고 있지 않은지 점검합니다. 발견되면 DIP까지 함께 만족하도록 추상화에 의존하도록 뒤집습니다. 

6. 자동 테스트 확보

SRP를 적용한 후에는 단위 테스트가 훨씬 쓰기 쉬워집니다.
Mock으로 상위 타입만 주입해 시나리오별 행동을 검증해 보세요. 실패한다면 치환 가능한지 재점검!

7. 정적 분석 & 코드 리뷰 룰 추가

• SonarQube “Lines per Class”, Detekt LargeClass 규칙 켜기
• PR 템플릿에 “변경 이유가 하나인가?” 체크박스 넣기
  지속적으로 감시해야 SRP는 조직 문화로 정착합니다.

---

마무리

SRP 리팩터링은 거창한 재설계가 아닙니다. “변경 이유를 단순화”하는 작은 분할이 쌓여 팀 전체의 생산성과 안정성을 끌어올립니다. 오늘 코드 리딩 시간 10분만 투자해 7단계 체크리스트로 클래스 하나를 다이어트해 보세요. 변화가 체감될 겁니다!