Frontend Fundamentals에서도 말하듯, 가독성 · 예측 가능성 · 응집도 · 결합도는 네 가지 모두를 완벽하게 충족시키기 어렵습니다. 예를 들어서 응집도를 높이기 위해 추상화를 하면 가독성이 떨어질 수 있고, 결합도를 낮추기 위해 중복을 허용하면 응집도가 떨어질 수 있습니다. 따라서 프론트엔드 개발자는 현재 코드가 어떤 상황에 놓여 있는지 판단하고, 장기적으로 “가장 변경하기 쉬운 구조는 무엇인가?” 를 기준으로 가치들을 조정해야 합니다.
정리해보면, 컴포넌트 분리를 고민할 때 흔히 SRP를 떠올리지만, 절대적인 규칙이 아니라 변경하기 쉬운 코드를 만들기 위한 한 가지 도구일 뿐입니다. 프론트엔드 개발에서 더 중요한 것은 원칙 자체가 아니라 원칙을 언제 어떻게 적용할지 결정하는 판단이라는 것을 이번 학습을 통해 배울 수 있었습니다. 고민했던 부분이 해소되어 앞으로 스스로 더 나은 개발을 할 수 있는 기준이 생긴 것 같습니다.
컴포넌트를 분리할 때 단일 책임 원칙(SRP)을 기준으로 삼는다고 이야기합니다.
하지만 단일 책임 원칙을 엄격하게 적용하려면 '컴포넌트는 반드시 하나의 역할만 해야 한다'는 원칙을 지키기 위해 과도하게 쪼개야하는데, 이로 인해 컨텍스트가 분산된다면 오히려 파악하는데 시간을 많이 사용하는 비효율이 생기지 않을까? 그럼 실무에서는 어떤 단위로 분리하지? 하는 의문이 들어 찾아보게 되었습니다. 컴포넌트는 어떤 기준으로 분리하는게 좋을까요?
SRP는 절대적인 원칙이 아니라 가이드라인이다.
찾아본 결과 SRP를 지키는 것은 좋지만, '클린코드'의 저자인 로버트 마틴도 현실에 맞게 적용해야 한다고 이야기합니다.
SRP의 핵심은 '변경 이유가 두 개 이상이면 분리해라'이고, 분리의 목적은 깨끗한 구조 자체가 아니라 유지보수 편의성에 있기 때문입니다 따라서 단순히 '컴포넌트가 하나의 역할만 해야 한다'에 집착하기보다, '나중에 읽기 좋은 코드가 될까?'라는 관점이 더 중요합니다.
컴포넌트 분리 기준 정하기
실무에서는 주로 기능 단위 분리를 더 많이 사용한다고 합니다. 변경 가능성을 기준으로 언제 분리했을 때 유지보수가 편해지는지를 판단하는 것이 중요한 관점입니다.
| 상황 | 분리 |
| 단순한 UI | 분리 안 함 |
| 재사용 가능성이 있음 | 분리 |
| UI는 단순하지만 로직이 복잡함 | 훅으로 분리 |
| UI와 비즈니스 로직이 섞여 있음 | 분리 |
| 변경 시 여러 파일을 동시에 수정해야 한다면 | 분리 X |
| 파일이 지나치게 커져 흐름 파악이 어려움 (200~300줄 이상) | 분리 고려 |
Frontend Fundamentals
https://frontend-fundamentals.com/code-quality/code/
좋은 코드를 위한 4가지 기준
Guidelines for easily modifiable frontend code
frontend-fundamentals.com
토스에서 제시하는 Frontend Fundamentals에서도 좋은 프론트엔드 코드를 '변경하기 쉬운 코드'라고 정의합니다. 기존 기능을 수정하거나 새로운 요구사항을 구현해야 할 때, 적은 비용으로 빠르게 변경할 수 있는 코드가 좋은 코드라는 의미입니다. Frontend Fundamentals에서는 좋은 코드를 만들기 위한 네 가지 기준을 제시합니다.
1. 가독성(Readability)
그리고 변경하기 쉬운 코드를 만들기 위한 첫 번째 기준이 바로 가독성(Readability) 입니다. 읽기 쉬운 코드는 누가 보더라도 한 번에 이해가 되고, 위에서 아래로 자연스럽게 읽히는 구조를 가집니다. 읽는 사람이 한 번에 고려해야 하는 맥락(Context) 이 적을수록 좋습니다.
가독성을 높이기 위해 토스는 여러 전략을 제시하는데, 그중 하나가 바로 구현 상세를 추상화하기입니다.
- 맥락 줄이기
- 같이 실행되지 않는 코드 분리하기
- 구현 상세 추상화하기
- 로직 종류에 따라 합쳐진 함수 쪼개기
- 이름 붙이기
- 매직 넘버 제거하기
여기서 말하는 구현 상세 추상화하기는 제가 고민했던 컴포넌트 분리 기준과 자연스럽게 연결됩니다.
컴포넌트 내부에서 너무 많은 것을 드러내기보다, 맥락을 줄이고 역할 단위로 코드를 재배열하는 것이 바로 추상화이기 때문입니다.
2. 예측 가능성(Predictability)
예측 가능한 코드는 함수나 컴포넌트를 봤을 때 이름과 인자만 보고도 무엇을 하는지 짐작할 수 있는 코드를 의미합니다.
예측 가능성을 높이기 위해서는 아래와 같은 전략을 사용합니다.
- 이름 겹치지 않게 관리하기
- 같은 종류의 함수는 반환 타입 통일하기
- 숨은 로직 드러내기
예측 가능성이 높아지면 코드를 읽을 때 '이건 또 무슨 동작을 하는 부분이지?'라고 멈추는 순간이 줄어들어 변경에 드는 비용이 크게 줄어듭니다.
3. 응집도(Cohesion)
응집도란 함께 수정되는 코드가 물리적으로도 가까이에 있는지를 의미합니다. 응집도가 높으면 한 부분을 수정했을 때 의도치 않은 다른 오류가 발생할 가능성이 낮아집니다.
- 함께 수정되는 파일을 같은 디렉토리에 두기
- 매직 넘버 제거하기
- 폼의 응집도 고려하기
가독성과 응집도는 때로는 상충되기도 하는데, 응집도를 높이기 위해 공통로직을 추상화하면 가독성이 떨어질 수 있습니다. 반대로 가독성을 높이기 위해 중복을 허용하면 응집도가 낮아질 수 있습니다. 따라서 언제 어떤 가치를 우선할 것인지는 상황에 맞게 판단해야 합니다.
4. 결합도(Coupling)
결합도란 코드를 수정했을 때 영향 범위가 얼마나 넓어지는지를 말합니다. 결합도가 낮을수록 특정 기능을 수정하더라도 다른 부분이 깨질 위험이 작습니다.
- 책임을 하나씩 관리하기
- 중복 코드 허용하기
- Props Drilling 줄이기
여기서 책임을 하나씩 관리하기는 SRP와 닿아 있지만, Frontend Fundamentals는 무조건 분리하라는 것이 아니라, 결합도를 낮춰 변경의 영향 범위를 줄이는 수준에서의 책임 관리를 강조합니다.
네 가지 기준을 적절하게 적용하기
Frontend Fundamentals에서도 말하듯, 가독성 · 예측 가능성 · 응집도 · 결합도는 네 가지 모두를 완벽하게 충족시키기 어렵습니다.
예를 들어서 응집도를 높이기 위해 추상화를 하면 가독성이 떨어질 수 있고, 결합도를 낮추기 위해 중복을 허용하면 응집도가 떨어질 수 있습니다. 따라서 프론트엔드 개발자는 현재 코드가 어떤 상황에 놓여 있는지 판단하고, 장기적으로 “가장 변경하기 쉬운 구조는 무엇인가?” 를 기준으로 가치들을 조정해야 합니다.
정리해보면, 컴포넌트 분리를 고민할 때 흔히 SRP를 떠올리지만, 절대적인 규칙이 아니라 변경하기 쉬운 코드를 만들기 위한 한 가지 도구일 뿐입니다. 프론트엔드 개발에서 더 중요한 것은 원칙 자체가 아니라 원칙을 언제 어떻게 적용할지 결정하는 판단이라는 것을 이번 학습을 통해 배울 수 있었습니다. 고민했던 부분이 해소되어 앞으로 스스로 더 나은 개발을 할 수 있는 기준이 생긴 것 같습니다.
+) 인상깊게 보았던 SLASH 21 링크 남겨두겠습니다!
https://www.youtube.com/watch?v=edWbHp_k_9Y
'📚 CS > Basic' 카테고리의 다른 글
| 이벤트 버스 패턴(Event Bus Pattern) 알아보기 (0) | 2025.10.31 |
|---|---|
| [CS] 디자인 패턴 알아보기 (0) | 2025.10.18 |
| [CS] CORS(Cross-Origin Resource Sharing)는 왜 필요할까요? (프록시 서버로 우회하기) (0) | 2025.10.11 |
| [CS] API와 아키텍처 (1) | 2025.08.26 |
| [CS] 컴퓨터 네트워크 기초 (2) | 2025.08.25 |