단일 책임 원칙: 확장 가능한 웹 아키텍처의 초석

Source: Dev.to

왜 SRP가 중요한가

웹 애플리케이션을 구축해 온 경험을 통해 나는 단일 책임 원칙(Single Responsibility Principle, SRP)이 가장 중요한 아키텍처 결정이라고 확신하게 되었다. 애플리케이션의 모든 컴포넌트, 서비스, 모듈은 정확히 하나의 변경 이유만을 가져야 한다. 이것은 이론적인 클린 코드 이야기가 아니라, 트래픽과 팀 규모가 커져도 애플리케이션을 확장할 수 있게 해 주는 실질적인 기반이다.

SRP 위반의 결과

SRP를 위반하면 나는 이를 “변경 자석”이라고 부른다—여러 팀이 동시에 수정해야 하는 컴포넌트가 생겨 병합 충돌, 배포 조정 악몽, 연쇄적인 장애가 발생한다. 간단한 기능 추가만으로도 네 개의 서로 다른 서비스에 걸쳐 12개의 파일을 수정해야 했던 사례를 본 적이 있다. 이는 단순히 나쁜 아키텍처가 아니라 개발 속도를 급격히 저하시키는 시한폭탄이다.

SRP 수용의 장점

SRP의 아름다움은 자연스럽게 다른 좋은 실천들을 이끌어낸다는 점이다. 각 컴포넌트가 하나의 책임만을 가질 때, 그 컴포넌트를 이해하고, 격리된 상태로 테스트하며, 시스템의 나머지 부분에 영향을 주지 않고 교체하기가 쉬워진다. 마이크로서비스는 한 가지 일을 잘 수행하도록 설계하고, 데이터베이스 스키마는 관심사를 명확히 분리하며, 프론트엔드 컴포넌트는 UI 상태의 한 조각만을 담당해야 한다. 이것은 과도하게 꼼꼼해지는 것이 아니라, 지속적인 고통스러운 리팩터링 없이도 진화할 수 있는 시스템을 구축하는 것이다.