AI랑 같이하는 코딩

1. 주제 소개

화면 하나를 통째로 만들기 시작하면 처음에는 빠르게 보이지만, 수정이 반복될수록 코드가 급격히 무거워집니다. 버튼 하나를 고치려 해도 파일 전체를 훑어야 하고, 작은 변경이 다른 영역을 망가뜨리는 일이 자주 생깁니다. 그래서 실무에서는 큰 화면을 먼저 완성하려고 하지 않고, 초기에 컴포넌트 단위로 나누는 기준부터 잡습니다. 이 과정이 흔히 말하는 “기능 쪼개기”입니다.

핵심은 디자인을 그대로 조각내는 것이 아니라, 역할과 변경 주기를 기준으로 분해하는 것입니다. 자주 바뀌는 영역과 거의 고정된 영역을 분리하면 이후 요구사항 변경이 들어와도 영향 범위를 예측하기 쉬워집니다. 예를 들어 대시보드 화면이라면 필터 영역, 통계 카드 영역, 리스트 영역, 페이지네이션 영역처럼 데이터 흐름이 다른 부분을 각각 독립시켜야 유지보수성이 크게 올라갑니다.

2. 핵심 내용

좋은 분해 기준은 세 가지로 요약할 수 있습니다. 첫째, 책임이 하나인지 확인합니다. 컴포넌트가 데이터를 가져오고, 가공하고, 렌더링까지 모두 한다면 과한 책임을 가진 상태입니다. 둘째, 재사용 가능성을 봅니다. 다른 화면에서도 같은 구조가 필요하다면 별도 컴포넌트로 분리하는 편이 장기적으로 유리합니다. 셋째, 상태 소유권을 명확히 합니다. 어떤 상태를 어디가 관리할지 결정되지 않으면 컴포넌트 분리가 오히려 혼란을 키웁니다.

또한 “작게 쪼개면 무조건 좋다”는 오해도 경계해야 합니다. 지나치게 잘게 나누면 파일 수만 늘고 맥락 파악이 어려워질 수 있습니다. 실무에서 유용한 기준은 화면을 읽는 사람이 “각 블록이 왜 존재하는지”를 즉시 이해할 수 있는지입니다. 즉, 컴포넌트 경계는 코드 스타일이 아니라 팀 커뮤니케이션 도구입니다.

3. 적용 방법

아래 표처럼 화면을 역할 기준으로 분해하면 구현 순서도 자연스럽게 나옵니다. 먼저 페이지 컨테이너에서 전체 상태를 정의하고, 하위 컴포넌트는 필요한 데이터와 이벤트만 props로 받도록 설계해 보세요. 이렇게 하면 테스트도 단위별로 작성하기 쉬워지고, 버그 위치를 빠르게 좁힐 수 있습니다.

실전에서는 먼저 와이어프레임 위에 “상태가 필요한 블록”과 “표시만 하는 블록”을 표시해 보세요. 상태가 필요한 블록은 컨테이너 성격으로 두고, 표시만 하는 블록은 프리젠테이셔널 컴포넌트로 분리하면 구조가 단순해집니다. 이후 API 응답 구조가 바뀌어도 상위 컨테이너만 수정하면 되기 때문에 하위 UI 컴포넌트를 안전하게 유지할 수 있습니다.

4. 정리

기능 쪼개기의 목표는 파일을 많이 만드는 것이 아니라 변경을 쉽게 만드는 것입니다. 화면을 역할, 상태, 재사용 기준으로 나누면 개발 속도뿐 아니라 협업 속도도 올라갑니다. 리뷰할 때도 “이 컴포넌트 책임이 과한가?”라는 질문으로 품질을 빠르게 점검할 수 있습니다. 결국 좋은 컴포넌트 구조는 멋진 아키텍처가 아니라, 다음 수정 요청이 들어왔을 때 덜 흔들리는 구조입니다.

5. 자주 묻는 질문