SOLID SRP - 30년 후의 재해석

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

소프트웨어 개발자, 아키텍트, 팀 리더

• 난이도: 중간
• 관련 분야: 코드 공유, 팀 구조 설계, 마이크로서비스 아키텍처

핵심 요약

• SRP의 기존 오해: "모듈은 하나의 기능만 수행해야 한다"는 해석은 Conway's Law에 기반한 팀 구조와의 연관성을 간과함
• SRP의 진정한 의미: "모듈은 단일 팀에 속해야 한다"는 원칙으로, 팀 토폴로지와 사용자 그룹의 일치 여부가 핵심 조건
• 공유 코드의 위험성: 다중 사용자 그룹이 공유 코드를 사용하는 경우, 기능 변경이나 충돌이 발생할 수 있으며, 공유 코드는 의도적으로 필요할 때만 사용해야 함

섹션별 세부 요약

1. SRP의 기존 해석과 재해석

• SRP의 오해: "모듈은 하나의 기능만 수행해야 한다"는 해석은 Conway's Law와의 연관성을 놓침
• Conway's Law: 소프트웨어의 구조는 개발 팀의 조직 구조에 따라 자연스럽게 분리됨 (예: 마이크로서비스)
• SRP의 진정한 의미: 모듈은 단일 팀에 속해야 한다는 원칙으로, 팀 토폴로지와 사용자 그룹의 일치 여부가 조건
• 예시: 사용자 알림 팀과 분석 팀이 별도 서비스를 운영하는 경우, 팀 간 협업 부담으로 인해 분리됨

2. 팀 구조와 사용자 그룹의 연관성

• SRP 적용 조건: 팀 구조가 사용자 그룹과 일치하는 경우에만 SRP가 적용됨
• 예외 사례: DB 팀, AI 팀 등 다중 제품 지원 팀의 경우, 팀 구조와 사용자 그룹의 일치 여부가 중요
• 문제점: 팀별 세분화 vs 사용자 그룹 세분화 중 우선순위 결정이 어려움

3. 공유 코드의 위험성 및 해결 방안

• 공유 코드의 문제점:

- 예시 1: 두 팀이 동일한 급여 계산 함수를 사용할 경우, 한 팀의 변경이 다른 팀에 버그 유발

- 예시 2: 공유 함수의 병합 충돌로 인해 2개 사용자 그룹 모두에 영향

• 공유 코드의 원칙:

- 공유 코드는 의도적으로 필요한 경우에만 사용해야 하며, 리스크를 감수해야 함

- 대안: 코드 복사/버전 고정으로 의존성을 제거 (예: 라이브러리 대신 서비스 사용)

4. SRP의 재정의 및 향후 방향

• SRP의 재정의:

- "공유 모듈은 a) 공유 리스크를 감수할 의향이 있거나, b) 모듈 사용자 간 동일한 동작을 보장하려는 경우에만 사용"

- SRP의 이름 부적절성: 원칙 명칭은 "ShaRe Purposefully"로 변경 제안

• 향후 방향: SOLID의 다른 원칙(예: Open-Closed Principle)을 통해 코드 분할 전략을 다룰 예정

결론

• 핵심 팁: 공유 코드는 의도적인 필요성이 없을 경우 복사/버전 고정이 더 안전한 선택이며, 팀 구조와 사용자 그룹의 일치 여부를 확인한 후 SRP를 적용해야 함.
• 실무 적용: 공유 코드 사용 전에 의도적 공유 여부와 리스크 관리를 반드시 검토하고, 팀과 사용자 그룹의 토폴로지를 기반으로 아키텍처 설계를 수행해야 함.