카카오페이지 프론트엔드가 SOLID 원칙을 실무 컴포넌트 설계에 어떻게 적용했는지 정리한 글이다. SRP의 책임을 동작이 아니라 요구사항을 전달하는 책무로 읽어야 한다는 것이 축이며, 콘웨이 법칙을 대전제로 깐다. 기획과 디자인 조직의 산출물을 그대로 컴포넌트 경계로 삼은 사례가 이어진다.
핵심 포인트- SOLID는 기법이 아니라 원칙이므로 기법으로 접근하면 범위와 목적이 어긋난다.
- SRP의 책임을 동작으로 읽으면 컴포넌트가 과도하게 쪼개져 전체 로직 파악과 코드 탐색 비용이 올라간다.
- 로버트 마틴의 최종 정의는 하나의 모듈이 오직 하나의 액터에 대해서만 책임진다는 것이다.
- 즉 컴포넌트는 요구사항을 전달하는 책무 단위로 설계하며, 컴포넌트와 요구사항의 변경 범위를 맞추는 것이 목적이다.
- 단일 동작으로 쪼개는 것은 컴포넌트가 아니라 순수 함수에 해당하며 이는 클린 코드의 영역이다.
- OCP는 섹션 목록처럼 운영 중 추가·변경·삭제가 잦은 구조에 다형성을 적용해 조건 분기를 없애는 데 쓴다.
상세 정리- 저자의 전제: SOLID는 경력 없이 책으로만 보면 이해하기 어렵고 컴포넌트에 대한 잘못된 선입견만 생길 수 있다고 본다.
- 인용의 근거: 마틴 본인도 SOLID 중 의미가 가장 잘 전달되지 못한 원칙이 SRP이며 이름이 부적절한 탓도 있다고 밝혔다.
- 콘웨이 법칙: 소프트웨어 구조는 그 소프트웨어를 만든 조직의 커뮤니케이션 구조를 닮게 된다.
- 법칙의 함의: 뒤집으면 구조가 조직의 커뮤니케이션과 다르면 어딘가 잘못된 구조라는 뜻이 된다.
- 이상적인 구조: 요구사항이 바뀌었을 때 다른 컴포넌트에 영향을 주지 않고 원하는 부분만 고칠 수 있는, 응집도가 높고 결합도가 낮은 집합이다.
- 어긋났을 때: 쓰는 용어와 생각하는 영향 범위가 달라 미스커뮤니케이션이 생기고 의존성이 얽혀 손대기 어려워진다.
- 흔한 오해: 책임을 동작으로 두면 쪼개는 기준이 애매해지고 자잘한 컴포넌트가 양산된다.
- 올바른 해석: 액터는 사용자나 이해관계자 집단이며 팀 단위나 책무 단위가 될 수 있다. 책임을 소프트웨어 내부의 동작이나 논리가 아니라 조직 간 커뮤니케이션 영역으로 봐야 한다.
- 적용 대상: 카카오페이지의 요구사항은 사업과 마케팅, 기획, 디자인 부서에서 오고 구현 중에는 개발 조직과 본인에게서도 나온다.
- 조직별 분리 기준: 기획과 디자인 조직이 분리돼 있으면 컴포넌트도 분리하고, 디자이너가 기획을 겸하는 조직이면 UI와 비즈니스가 결합된 컴포넌트도 무방하다.
- 기획 책무: 기획은 API 데이터를 어떤 디자인과 연결할지 정하고 컴포넌트의 제약조건과 예외사항을 정의한다.
- 활용 팁 1: 정보구조도의 단위와 네이밍을 변환 없이 그대로 컴포넌트에 쓰면 이후 커뮤니케이션 미스가 없어진다. 모호하면 기획 쪽에 네이밍 변경을 요구하는 것도 방법이다.
- 활용 팁 2: 상세 기획서를 그대로 컴포넌트 설계도로 써서 섹션과 타이틀, 더보기, 목록 뷰를 그대로 구성했다.
- 테스트로의 연결: SRP를 만족하면 무엇을 테스트할지가 자연히 정해진다. 기획서의 제약조건과 예외사항을 검증하면 되며, 타이틀 15자 제한 같은 테스트가 예시다.
- 디자인 책무 이전: 디자인 시스템이 없던 시절에는 화면마다 UI 담당자가 따로 있고 바뀌기도 해 커뮤니케이션 비용이 컸다.
- 그때의 문제: 개발팀이 자체 공통 컴포넌트를 만들어도 디자인 쪽은 화면별로 따로 디자인하는 구조라 화면마다 다른 체크박스가 생겼고, 하나를 고쳐도 반영되지 않아 공통이라는 것이 사실상 없었다.
- 개편 이후: 2022년 개편 때 디자인과 개발이 함께 디자인 시스템을 구축했고, 저자 팀이 먼저 공식·비공식으로 건의한 것이 계기였다고 밝힌다.
- 아토믹 디자인: 도출된 UI 컴포넌트를 그대로 쓰기 위해 차용했으며 각 계층이 하나의 책무를 담당하도록 구조화해준다.
- 매칭 팁: 디자인 컴포넌트와 1대1로 대응시키되 네이밍과 variant는 물론 마진과 패딩까지 포함한다. 간격도 디자인 책무가 단일하게 책임질 부분이다.
- 효과: 문의가 화면 위치 설명에서 컴포넌트와 링크 기반으로 바뀌었다.
- OCP 적용 대상: 서비스 운영 중 추가·변경·삭제가 명확한 섹션 UI를 예로 든다.
- OCP 미적용 코드: 섹션 타입을 조건문으로 분기하면 섹션이 늘 때마다 분기를 덧붙여야 해 확장에 닫힌 구조가 된다.
- OCP 적용 코드: 섹션과 아이템 컴포넌트에 다형성을 주어 섹션을 추가하거나 지워도 이 코드가 바뀌지 않게 한다.
왜 읽나SOLID를 알긴 아는데 실제로 컴포넌트를 어디서 갈라야 할지 매번 막힌다면, 조직의 커뮤니케이션 구조를 기준으로 삼는 해석과 그 적용 사례를 볼 수 있다.
카카오 엔터테인먼트 FE·
AWS Architecture·
flex·