
관심사 분리는 소프트웨어 디자인 원칙으로, 하나의 모듈이나 컴포넌트가 여러 관심사를 동시에 처리하는 대신, 각 부분은 하나의 특정 관심사만 담당하도록 코드를 분리하는 것을 의미한다.
관심사 분리는 프런트엔드와는 거리가 있다고 하는 분이 있다면, 이는 명백한 오판이었다. (내가 그랬다..!!)
프런트엔드에서도 관심사 분리를 염두에 두고 코드를 작성하면, 유지보수성과 확장성이 눈에 띄게 좋아진다. 각 로직의 책임이 명확해지면서 협업이나 디버깅 과정에서도 훨씬 효율적으로 일할 수 있다. 어떻게 하는지 간락하게 살펴보자.
/Main.tsx
export default function Main() => {
const handleInput = () => {}
return (
<input onClick={handleInput} />
)
}
위 처럼 input을 그려야하는 페이지를 하나 예를 들어보자. Main 이라는 컴포넌트에 input을 컨트롤하는 함수와(로직) 사용자에게 보여지는 return (뷰) 부분이 하나의 페이지에 구성되어있다. 이 코드에서는 관심사 분리의 필요성이 크게 느껴지지 않는다. 한눈에 뷰의 구성과 해당되는 함수가 한눈에 들어오기 때문이다. 하지만 필요한 함수가 늘어나고 보여줘야하는 컴포넌트가 무수히 많아진다면 위 코드는 어떻게 될까? 코드 자체의 길이도 늘어나는것은 물론이고 한눈에 파악하기도 매우 어려워 진다.
예전의 나였다면 return(뷰) 쪽의 컴포넌트들을 나누는 선택지만을 선택했다. 그러면 하나의 코드에 보여지는 함수도 줄어들고 뷰도 훨신 쉽게 파악할 수 있기 때문이다. 물론 좋은 방법이지만 여기에 관심사 분리를 적용한다면 더욱 깔끔하게 코드를 관리할 수 있다.
이전의 글에서 featured-based 구조를 다룬적이 있다. 이를 기반으로 위 코드에 관심사 분리를 적용해보자.
src/
├── features/
│ ├── Main/
│ │ ├── components/ // 공틍으로 사용되는 컴포넌트
│ │ ├── hooks/ // REACT와 의존적, 상태관리, 생명주기, UI와 밀접
│ │ ├── services/ // 단순 함수
│ │ └── Main.tsx
현재 코드에서는 컴포넌트와 단순 함수는 없으니 hooks 만 추가해보려고 한다. hooks 와 services 차이점은 단순한가, 다른 상태관리, 생명주기 등과 엮겨있나 이다. 단순하게 string의 형식 변경 같은 함수는 services 폴더에, 값에 따라서 팝업을 보여주는 함수는 hooks 에 추가하면된다. (위 handleInput 은 이런 함수라고 가정해본다.)
/hooks/useMainLogic.ts
const useMainLogic = () => {
const handleInput = () => {}
return {
handleInput
}
}
/Main.tsx
export default function Main() => {
const { handleInput } = useMainLogic();
return(
<input onClick={handleInput} / >
)
}
위 처럼 관심사 분리를 통한 코드 관리는 코드의 양이 커져갈 수록 더 큰 힘을 발휘한다.
오늘 한번 함수와 뷰가 많이 섞여있는 페이지를 하나 나눠본다면 그 힘을 바로 체감할 수 있을것이다!
'Front-end' 카테고리의 다른 글
| [Firebase] Firebase Hosting Setup Complete 해결하기!(feat. Nextjs) (1) | 2025.08.08 |
|---|---|
| [FE] Figma와 cursor MCP 연결하기! (0) | 2025.08.01 |
| [FE] 프로젝트 폴더 아키텍처 알아보기 (0) | 2025.07.28 |
| [FE] MVC패턴? 아키텍쳐? 프런트엔드 개발자가 알빠노 (feat: 응 아니야) (2) | 2025.07.24 |
| [FE] Hot Reloading 문제, 왜 강제 새로고침이 되는걸까? (3) | 2025.07.10 |