800줄짜리 뷰 파일 하나에 모든 게 들어 있는 코드, 한 번쯤 보셨을 거예요.
화면 그리는 뷰 코드 안에 API 호출이 있고, 그 옆에 할인율 계산 로직이 있고, 그 아래에 날짜 포맷 함수가 있고, 중간중간 분석 이벤트 전송까지. 뭐 하나 고치려면 800줄을 전부 읽어야 합니다.
이런 파일이 어기고 있는 원칙이 바로 관심사 분리, 영어로 Separation of Concerns예요. 개발 원칙 시리즈, 마지막 편은 이 원칙입니다.
관심사 분리(SoC)는 프로그램을 서로 다른 관심사 단위로 나눠서, 각 부분이 한 가지 관심사만 다루게 하라는 원칙입니다.
’관심사’는 프로그램이 신경 써야 할 일의 종류예요. 화면을 어떻게 보여줄지, 데이터를 어디서 가져올지, 비즈니스 규칙을 어떻게 적용할지는 서로 다른 관심사입니다.
이 용어를 만든 사람은 컴퓨터 과학자 데이크스트라(Dijkstra)인데, 1974년 글에서 이렇게 표현했어요.
한 번에 한 측면에만 집중해서 사고하는 것. 그것이 내가 아는 유일한 효과적 사고 기법이다.
사람 머리는 한 번에 여러 관심사를 못 다룹니다. 그러니 코드도 한 조각에 한 관심사만 담자는 거예요.
익숙한 사례부터: HTML, CSS, JS
웹 개발을 해보셨다면 이미 관심사 분리를 매일 써온 셈입니다.
| 기술 | 관심사 |
|---|---|
| HTML | 구조 — 무엇이 있는가 |
| CSS | 표현 — 어떻게 보이는가 |
| JavaScript | 동작 — 어떻게 반응하는가 |
옛날처럼 HTML 태그에 style 속성과 onclick을 덕지덕지 바르면, 버튼 색 하나 바꾸는 데도 HTML을 뒤져야 합니다. 세 파일로 나누면 디자이너는 CSS만, 마크업 담당은 HTML만 보면 되고요.
백엔드의 컨트롤러-서비스-리포지토리 구조, iOS에서 뷰와 뷰모델·데이터 계층을 나누는 것도 전부 같은 원리입니다. MVC니 레이어드 아키텍처니 하는 것들은 결국 관심사 분리를 정형화한 패턴이에요.
아까 그 800줄 뷰를 수술해보면
앞에서 본 800줄 뷰를 관심사별로 갈라볼게요.
// Before: 모든 관심사가 한 파일에
struct ProductPage: View {
// 관심사 1: 데이터 가져오기 (네트워크 호출, 로딩, 에러 처리 150줄)
// 관심사 2: 비즈니스 규칙 (할인율·재고 계산 200줄)
// 관심사 3: 분석 이벤트 (탭 추적 100줄)
// 관심사 4: 화면 그리기 (body 350줄)
}// After: 관심사마다 제 집을 찾아줌
ProductStore(id:) // 데이터 가져오기
calcDiscount(product, user) // 비즈니스 규칙 (순수 함수)
Tracker.track("product") // 분석 이벤트
struct ProductPage: View { // 화면 그리기만
@State private var store: ProductStore
var body: some View {
let price = calcDiscount(store.product, user)
...
}
}나눠놓고 나면 좋은 점이 명확합니다. 할인 정책이 바뀌면 calcDiscount만 보면 되고, 이 함수는 화면과 무관한 순수 함수라 테스트도 쉽습니다. API 스펙이 바뀌면 ProductStore만 고치면 되고요. 800줄을 다 읽던 때와 비교하면 수정 범위가 10분의 1로 줄어듭니다.
어디까지 나눠야 할까?
관심사 분리에서 제일 어려운 건 “그래서 경계를 어디에 긋느냐”입니다. 과하게 나누면 파일 수십 개를 넘나들며 읽어야 하는 미로가 되거든요.
제가 쓰는 기준은 변경의 이유예요. SOLID 편에서 다룬 SRP와 똑같은 질문입니다.
이 두 코드는 같은 이유로, 같은 시점에 바뀌는가?
할인 정책과 화면 레이아웃은 다른 이유로 바뀌니 분리합니다. 반대로 버튼과 그 버튼의 탭 핸들러는 거의 항상 같이 바뀌니 붙여둡니다. SwiftUI가 뷰 단위로 구조·스타일·동작을 오히려 한 파일에 모으는 것도 이 관점으로 보면 모순이 아니에요. 기술 종류가 아니라 함께 바뀌는 단위로 관심사를 다시 그은 겁니다.
시리즈를 마치며
관심사 분리에서 남길 핵심은 이겁니다.
- 한 조각의 코드는 한 가지 관심사만 다루게 하세요. 사람 머리는 멀티태스킹이 안 됩니다.
- 경계는 기술 종류가 아니라 “같이 바뀌는 단위”로 긋는 게 실전적입니다.
- 과한 분리는 미로를 만듭니다. 나누는 것 자체가 목적이 되면 안 돼요.
이걸로 개발 원칙 시리즈가 마무리됐네요. KISS(단순하게), DRY(지식은 한 곳에), YAGNI(지금 필요한 것만), SOLID(변경의 파급을 좁게), 최소 놀람(예상대로 동작하게), 그리고 관심사 분리(한 번에 하나만)까지.
돌아보면 여섯 원칙이 전부 같은 곳을 가리키고 있습니다. 코드는 컴퓨터가 아니라 사람이 읽는 것이고, 좋은 코드란 바꾸기 쉬운 코드라는 것. 원칙 이름은 잊어버려도 이 문장 하나만 남기시면 됩니다.