DevLog

엔지니어링 블로그를 한 곳에서 탐색하고, 최근 발행 흐름을 빠르게 파악할 수 있는 서비스 입니다.

Quick Links

  • Latest Feed
  • Engineering Directory

Support

  • 소개
  • 개인정보처리방침

Contribute

  • 원하는 블로그 추가 (준비 중)
  • Feedback

© 2026 DevLog Inc. All rights reserved.

본 사이트는 공개 RSS 피드를 통해 콘텐츠를 수집하며, 모든 콘텐츠의 저작권은 원저작자에게 있습니다.

Back to Feed
Read Original

Contents

Continue Reading

  • More from 카카오페이
  • Related reads#React
#Frontend

공통 컴포넌트를 건강하게 기르기 위한 고민

공통 컴포넌트를 건강하게 기르기 위한 고민
01

Summary

"공통 컴포넌트는 자산이 아니라 부채일 수 있다?" 카카오페이손해보험의 컴포넌트 생존 전략

무분별한 재사용의 늪에서 벗어나 건강한 디자인 시스템을 구축하기 위한 FE 팀의 치열한 고민과 해법

이 아티클은 공통 컴포넌트가 팀의 생산성을 높이는 도구에서 관리의 짐으로 변하는 과정을 '생애주기'라는 독특한 관점으로 분석합니다. 무조건적인 공통화 대신 컴포넌트의 책임 범위를 고민하고, 때로는 과감한 폐기(Deprecated)를 통해 코드 건강성을 유지하는 실무적인 인사이트를 제공합니다. 단순한 기술 공유를 넘어 프론트엔드 개발자가 가져야 할 제품 설계 철학을 다룹니다.

  • 01비대해진 컴포넌트의 징후인 '사춘기' 패턴 분석과 리팩토링 시점 제안
  • 02섣부른 추상화(DelayRender 사례)를 경계하고 공통화 유지를 결정하는 기준 정립
  • 03템플릿 결합을 결정하는 '그린 라이트'와 '레드 라이트' 체크리스트 제공
  • 04스타일과 로직을 분리해 자유도를 높이는 헤드리스 컴포넌트 기반의 구조적 대안 제시
  • 05공통 컴포넌트의 '죽음'을 실패가 아닌 유지보수 비용 절감을 위한 의도적 선택으로 정의

+RECOMMENDATION

공통 컴포넌트 비대화로 고통받는 시니어 개발자와 디자인 시스템 도입을 고민 중인 팀에게 강력 추천합니다. 특히 '일단 공통으로 빼고 보자'는 관성에서 벗어나 유지보수 가능한 아키텍처를 설계하고 싶은 분들에게 실질적인 가이드가 될 것입니다.

The Problem

제품의 성장 과정에서 재사용을 목적으로 만들어진 공통 컴포넌트들이 시간이 흐름에 따라 과도한 책임을 떠안으며 비대해지거나, 충분한 검증 없이 성급하게 공통화되어 오히려 유지보수 비용을 증가시키는 문제가 발생했습니다. 특히 특정 도메인 로직이나 환경 대응 코드가 섞이면서 변경의 영향 범위를 예측하기 어려워지고 팀 생산성을 저하시키는 결과를 초래했습니다.

The Solution

컴포넌트의 생애주기(탄생, 사춘기, 결혼, 죽음)를 정의하여 각 단계에 맞는 관리 전략을 수립하고, 템플릿과 컴포넌트를 구분하는 명확한 기준(그린/레드 라이트)을 도입했습니다. 또한 UI 스타일과 비즈니스 로직을 분리하여 확장성을 높이는 헤드리스(Headless) 패턴 도입을 검토하고, 코드 리뷰 시 공통화의 적절성을 지속적으로 질문하는 문화를 정착시켰습니다.

The Result

본문에 구체적인 수치는 명시되지 않았으나, 무분별한 공통화를 경계하고 명확한 판단 기준에 따라 컴포넌트를 분리 또는 제거함으로써 기술 부채를 예방하는 효과를 얻었습니다. 결과적으로 팀 내에서 공통 컴포넌트를 영구 자산이 아닌 유연한 관리 대상으로 인식하게 되었으며, 유지보수 효율을 고려한 의사결정 체계가 마련되었습니다.

Trade-off

로직과 스타일을 분리하는 헤드리스 패턴이나 더 세밀한 컴포넌트 분리는 초기 설계와 구현 단계에서 더 많은 공수가 투입될 수 있습니다. 또한 공통 컴포넌트를 엄격하게 관리하는 과정에서 개별 화면 개발의 속도가 단기적으로는 둔화될 수 있으며, 팀원 간의 지속적인 커뮤니케이션 비용이 발생할 수 있습니다.

03

Key Concepts

Concept · 01

Headless Component

UI 스타일이나 외형을 정의하지 않고 오직 상태 관리, 인터랙션 로직, 접근성(ARIA) 처리 등 핵심 동작만을 담당하는 컴포넌트 패턴입니다.

  • 스타일은 사용처에 위임하고 로직만 공통으로 제공하여 UI 자유도를 확보함
  • 접근성과 같은 복잡한 로직을 안정적으로 재사용하기 위한 방안으로 활용됨
Concept · 02

Premature Abstraction

충분한 반복 사례나 검증이 이루어지기 전에 섣부르게 코드를 공통화하거나 추상화하여 오히려 유연성을 해치는 현상입니다.

  • DelayRender 사례를 통해 실질적 사용 빈도와 관리 비용 간의 저울질 필요성을 강조함
  • 불확실한 미래를 위해 미리 추상화하는 것에 대한 경고로 사용됨
Concept · 03

Component Deprecation

더 이상 새로운 요구사항을 충족하지 못하거나 관리 비용이 이점을 넘어선 컴포넌트를 의도적으로 사용 중단 대상으로 지정하는 과정입니다.

  • 컴포넌트의 '죽음'을 비용 절감을 위한 전략적 선택으로 정의함
  • 새로운 디자인 시스템(KID) 정비 과정에서 기존 컴포넌트의 역할을 재정의하는 수단으로 쓰임
Continue reading · same source

카카오페이More from 카카오페이

View all posts from 카카오페이
  • 2025 TAM CONNECT: 카카오페이 x 토스, 기술지원의 미래를 함께 그리다

    Technical Account ManagementTAMOperational Excellence
    3개월 전
  • 2026년 카페개페, AI와 함께한 현장 스케치

    카카오페이DevRel개발자페스티벌
    5개월 전
  • 수억 건의 데이터, 맛있게 쪼개 먹는 방법 (with. Partitioning)

    Spring BatchPartitioningMongoDB
    5개월 전
  • SDD (spec-kit) 에이전트 코딩 실전기

    SDDSpec-kit에이전틱 코딩
    5개월 전
  • 그때는 맞고 지금은 틀리다. Yarn Berry에서 pnpm으로 패키지 매니저 전환기

    pnpmYarn BerryZero-installs
    5개월 전

Related reads#React

Explore #React
채널 톡

AI가 읽는 디자인 시스템: 추상화를 다시 설계한 이유

#React5일 전
당근·Lynx

Laying the Rails Beyond WebView: Why Karrot Chose Lynx

#React2주 전
당근·Lynx

웹뷰 다음의 레일을 깔다: 당근이 Lynx를 선택한 이유

#React2주 전
여기어때

항공 프론트엔드 구축기 (6/10): 컨테이너를 둘로 쪼개지 않았다

#React3주 전
여기어때·WebView

항공 프론트엔드 구축기 (5/10): 뒤로가기가 가장 어려웠다

#React3주 전

Source

카카오페이
카카오페이
Engineering Blog

Published · March 24, 2026

Topics

ReactComponent LifecycleHeadless UIDesign SystemRefactoringCode QualityFrontend