재사용 가능한 UI 컴포넌트: 명명, 변형, 레이아웃 규칙

시각적 빌더에서 화면 일관성이 깨지는 이유

시각적 빌더는 화면을 빠르게 배포할 수 있게 해줍니다. 그러나 그 속도 때문에 UI의 모습과 동작이 서서히 흐트러지는 것을 놓치기 쉽습니다. 여러 사람이 동시에 작업하면 작은 선택들이 누적됩니다: 한 사람은 12px 패딩을 추가하고, 다른 사람은 16px를 쓰고, 또 다른 사람은 이전 화면에서 버튼을 복사해 옵니다.

증상은 보통 일찍 드러납니다: 거의 중복된 컴포넌트들, 화면 간 이동하는 간격, 같은 동작에 대해 조금씩 다른 단어(저장, 제출, 확인) 사용. 상태도 달라집니다. 한 폼은 분명한 로딩 상태를 보여주지만 다른 폼은 그렇지 않습니다. 오류 메시지가 제각각이고, 한 페이지에서만 보이는 ‘빠른 수정’이 공유 패턴으로 돌아오지 않습니다.

이것이 UI 부채가 시작되는 방식입니다. 각 불일치는 사소하게 느껴지지만 시간이 지나면 제품이 덜 신뢰받는 느낌을 줍니다. 또한 팀은 ‘올바른’ 버전을 찾고, 화면을 비교하고, 리뷰 마지막에 작은 차이들을 고치느라 더 느려집니다.

시각적 빌더의 컴포넌트 라이브러리는 모두가 재생성하는 대신 끌어다 쓰는 빌딩 블록(버튼, 입력, 카드, 헤더, 빈 상태 등)입니다. AppMaster 같은 플랫폼에서는 보통 시각적 UI 빌더 안에 재사용 가능한 UI 조각을 만들고, 이름 규칙, 설정 방법, 배치 방식을 합의해 서로 다른 사람이 만들어도 화면이 일관되게 보이도록 합니다.

목표는 창의성을 빼앗는 것이 아닙니다. 일상적인 부분을 예측 가능하게 만들어 선택을 의도적으로 하게 만드는 것입니다. 드리프트를 막는 네 가지 지렛대는: 명확한 명명, 합리적인 변형, 기본 레이아웃 규칙(간격, 정렬, 그리드), 그리고 라이브러리를 건강하게 유지하는 팀 습관입니다.

무엇을 재사용 컴포넌트로 삼아야 하고 무엇을 제외할 것인가

모든 예쁜 요소가 컴포넌트가 될 필요는 없습니다. 모든 것을 컴포넌트로 만들면 사람들이 라이브러리를 뒤지느라 시간을 낭비하고, 존재할 필요가 없는 옵션을 건드리게 됩니다.

좋은 재사용 컴포넌트는 여러 화면에서 볼 것으로 예상되거나 매번 동일하게 보여야 하는 것입니다. 사용자가 즉시 인식하는 패턴을 떠올리세요: 주요 버튼, 도움말 텍스트가 있는 텍스트 입력, 레코드를 미리보기 하는 카드 등.

작은 스타터 셋은 대부분의 화면을 커버합니다: 버튼, 입력, 카드, 페이지 헤더, 그리고 확인용/폼용 모달 한두 종류.

실용적인 추출 규칙은 결정을 단순하게 합니다: 같은 UI를 2~3번 사용하거나 브랜드상 동일해야 한다면 추출하세요. 한 번만 등장하면 로컬로 두세요.

일회성으로 남겨둘 것들: 특정 화면에 묶인 고유 레이아웃, 매일 변경되는 실험 섹션, 대부분 콘텐츠로 이루어진 요소. 예를 들어 맞춤 텍스트와 일러스트가 있는 일회성 온보딩 배너는 거의 컴포넌트로 만들 가치가 없습니다.

각 컴포넌트는 한 가지 일에 집중하게 하세요. 하나의 컴포넌트가 여러 책임을 가지면 재사용이 어려워집니다. 예: 권한, 청구 상태, 관리자 액션까지 처리하는 ‘사용자 카드’는 재사용하기 어렵습니다. 대신 표시용 User Card와 별도의 액션 버튼, 상태 칩으로 분리하세요.

압박 속에서도 읽기 쉬운 명명 규칙

팀이 빠르게 배포할 때 이름이 먼저 망가집니다. 누군가는 “Button2”를 복사하고, 다른 이는 “CTA Button”, 또 다른 이는 “BlueButton”을 만듭니다. 일주일 후에는 어느 것을 재사용해야 할지 아무도 모르게 되고 새로 만듭니다. 그렇게 라이브러리는 거의 중복된 덩어리가 됩니다.

간단한 패턴은 피곤할 때도 일관성을 유지하게 합니다: 컴포넌트 - 부분 - 상태. 대부분의 컴포넌트는 세 가지를 모두 필요로 하지 않지만 순서는 동일하게 유지하세요.

팀이 실제로 쓰는 단어를 사용하세요. 팀에서 ‘고객 카드’라고 부르면 CRM Tile이라고 이름 붙이지 마세요. 제품에서 ‘Plan’이라고 부르면 SubscriptionBox라고 부르지 마세요. 일반 언어가 검색성과 사용성을 높입니다.

한 가지 규칙이 많은 혼란을 막습니다: 같은 레이어에서 ‘무엇처럼 보이는가’와 ‘무엇을 위한 것인가’를 섞지 마세요. 하나의 접근법을 고르세요. 목적 기반 명명이 보통 더 잘 확장됩니다.

스캔하기 쉬운 예시:

• Button - Primary
• Button - Secondary - Disabled
• Input - WithLabel
• Card - Compact
• Modal - ConfirmDelete

한 번 포맷을 정하고 문서화하세요: 제목형(Title Case) 또는 문장형(sentence case), 하이픈 주위 공백, 약어는 보편적인 경우만 허용(예: URL). 많은 사람이 기여하는 시각적 빌더에서는 이런 작은 선택들이 라이브러리가 커질 때 읽기 쉬움을 유지합니다.

변형(Variants): 혼란 없이 선택권을 주는 방법

변형은 한 컴포넌트를 여러 곳에서 재사용하면서 새 복사본을 만들지 않게 해줍니다. 요점은 어떤 차이가 중요한지 미리 정하고 나머지는 잠그는 것입니다.

실제 필요를 커버하는 몇 가지 변형 차원으로 시작하세요. 많은 컴포넌트에는 세 가지면 충분합니다: 크기(S/M/L), 의도(primary/secondary/danger), 상태(default/hover/active). 새로운 옵션이 이 차원들에 맞지 않으면 ‘한 가지 더’ 변형이 아닌 새 컴포넌트로 처리하세요.

기본값은 생각보다 중요합니다. 누군가 컴포넌트를 끌어다 놓고 아무것도 바꾸지 않아도 화면이 제대로 보여야 합니다. 안전한 기본값(예: size=M, intent=primary, state=default)을 설정해 속도가 임의의 스타일링으로 바뀌지 않도록 하세요.

변형이 있는 각 컴포넌트에 대해 문서화하고 강제하세요:

• 지원하는 차원과 허용 값(간단하게 유지)
• 기본값
• 변형 간 절대 바뀌지 않는 것(패딩, 폰트, 모서리 반경, 아이콘 간격)
• 필수 상태(비활성, 로딩) 및 실패 가능 시 오류 상태
• 변형 대신 새 컴포넌트를 만들어야 하는 경우

예: 고객 포털 전반에 Submit 버튼이 있다면, 한 사람이 ‘와이드 Submit 버튼’을 만들고 다른 사람이 ‘둥근 Submit 버튼’을 만들면 드리프트가 금방 시작됩니다. 규칙을 정하면 하나의 Button 컴포넌트를 유지할 수 있습니다. 크기와 의도만 허용하고 커스텀 패딩과 모서리 반경은 금지하세요. Loading은 하나로 정의(스피너 표시, 클릭 잠금)해 어디서나 동일하게 동작하게 합니다.

누군가 ‘한 가지만 더 스타일을 추가해 달라’고 하면 그 변화가 어떤 사용자 문제를 푸는지 물어보세요. 불분명하면 아마 혼돈의 전조입니다.

레이아웃 규칙: 모두가 따르는 간격, 정렬, 그리드

레이아웃 규칙이 모호하면 모든 화면이 서서히 일회성으로 변합니다. 컴포넌트를 일관되게 유지하는 가장 빠른 방법은 간격과 정렬을 지루하게 만드는 것입니다: 허용되는 몇 가지 선택만 쓰게 하세요.

간격 스케일로 시작하고 다른 값은 금지하세요. 작은 집합을 고르세요(예: 4, 8, 12, 16, 24) — 키보드의 몇 개 키처럼 생각해 보세요. 누군가가 “18px이 필요하다”고 하면 보통 컴포넌트나 그리드가 잘못되었다는 신호입니다.

간격이 의미하는 바를 명시하세요:

• 패딩은 컴포넌트 내부이고 화면 전체에서 일관됩니다.
• 갭(gap)은 컨테이너 내부 항목 간 간격입니다(폼 행, 툴바 항목).
• 마진은 컴포넌트 외부에 사용되며 자주 쓰지 않는 것이 좋습니다.
• 중첩 마진 대신 gap을 선호해 컴포넌트 중첩 시 간격이 두 배가 되는 것을 방지하세요.

정렬 규칙은 끝없는 ‘여기 조금만 이동’ 수정을 줄입니다. 간단한 기본이 잘 작동합니다: 텍스트는 왼쪽 정렬, 라벨과 입력은 같은 수직선 위에 정렬, 주요 액션은 일관되게 배치(예: 모달에서는 오른쪽 하단, 폼 푸터에서는 오른쪽 정렬). 텍스트가 많은 행은 기준선 정렬(baseline)을 사용하세요. 아이콘 전용 행은 중앙 정렬을 예약하세요.

그리드는 복잡할 필요는 없지만 존재해야 합니다. 열과 거터를 정하고 작은 화면에서 어떻게 동작할지 정의하세요(기본적으로 데스크톱은 12열, 모바일은 단일 열 같은 규칙도 도움이 됩니다). 컨테이너 폭과 브레이크포인트를 한 번 정하고 그 안에서 화면을 만드세요.

자주 발생하는 함정: 패딩을 더하는 중첩된 컨테이너, 일관성 없는 페이지 마진, 고정 너비와 반응형 열 혼용, 특정 화면만 고치는 ‘마법 숫자’ 사용.

스타일 토큰: 폰트, 색상, 접근성 기본

스타일 토큰은 모두가 쓰는 공유 선택사항입니다. 토큰이 명확하면 서로 다른 사람이 화면을 만들어도 재사용 컴포넌트가 일관되게 유지됩니다.

타이포그래피부터 단일 출처로 삼으세요. 폰트 크기, 굵기, 줄높이에 대해 작은 스케일을 정하고 멈추세요. 대부분의 팀은 몇 단계만 필요합니다(예: body, small, caption, title, page heading). 이러한 선택을 한 곳에 두면 새 텍스트가 항상 동일한 기본값에서 시작합니다.

색상은 페인트 코드가 아니라 의미로 이름 붙이세요. Primary는 주요 액션, Success는 성공, Warning은 주의 같은 식입니다. 팀이 이미 팔레트로 생각하지 않는 한 blue-500 같은 이름은 피하세요.

나중의 문제를 막는 접근성 기본:

• 텍스트는 배경과 충분한 대비를 가져야 합니다.
• 탭 대상은 마우스 포인터가 아닌 엄지로 누를 수 있을 만큼 커야 합니다.
• 오류 메시지는 무슨 일이 일어났고 다음에 무엇을 해야 하는지 알려줘야 합니다.
• 상태를 색상만으로 전달하지 마세요.

토큰은 컴포넌트 변형과 직접 연결되어야 합니다. Primary 버튼 같은 변형은 승인된 토큰(색상, 테두리, 텍스트 스타일)을 바꾸고 일회성 스타일을 도입하면 안 됩니다.

토큰 목록은 사람들이 실제로 사용할 수 있을 만큼 짧게 유지하세요. 간단한 테스트: 누군가가 5초 안에 올바른 토큰을 고를 수 있는가? 그렇지 않다면 병합하거나 삭제하세요.

간단한 스타터 셋 예: 타이포그래피(text.body, text.small, text.title), 색상(color.primary, color.success, color.warning, color.danger), 간격(space.8, space.16, space.24), 반경(radius.sm, radius.md), 포커스(focus.ring).

단계별: 시각적 빌더에서 컴포넌트 라이브러리 설정하기

컴포넌트 라이브러리는 ‘디자인 완벽’이 아니라 일상적인 마이크로 결정을 제거하는 데 목적이 있습니다. 모두가 같은 빌딩 블록을 고르면 서로 다른 사람이 만들어도 화면이 일관됩니다.

실용적인 5단계 롤아웃

1. 이미 있는 것을 감사(audit)하세요. 실제 스크린 5~10개를 골라 반복되는 중복(버튼, 텍스트 입력, 섹션 헤더, 카드, 빈 상태)을 기록하세요.

2. 먼저 표준화할 작은 1차 목록을 고르세요. 거의 모든 곳에 나타나고 불일치를 가장 많이 일으키는 상위 10개 조각을 목표로 하세요. 많은 팀에서 이는 버튼, 입력, 드롭다운, 모달 대화상자, 테이블 헤더, 카드입니다.

3. 만들기 전에 규칙을 문서화하세요. 짧게: 컴포넌트 이름, 사용 시기, 허용 변형, 주변 레이아웃 규칙(간격, 정렬, 폭).

4. 한 번 재구성한 뒤 점진적으로 교체하세요. 새로운 컴포넌트를 시각적 빌더에 만들고 합의한 변형을 잠그세요. 구버전은 화면별로 서서히 바꾸세요. 한 스프린트에 모든 것을 리팩터링하려 하지 마세요.

5. 가벼운 검토 게이트를 추가하세요. 한 사람(주간 순환)이 새 컴포넌트와 변형을 확인합니다. 목적은 통제가 아니라 우발적 분기를 막는 것입니다.

‘충분히 좋은’ 모습

디자이너나 PM이 “표준 카드의 콤팩트 헤더를 사용하세요”라고 말했을 때 두 명의 빌더가 같은 결과를 내면 잘 되고 있는 것입니다. 보이지 않는 보상: 일회성 선택 감소, 미묘한 불일치 감소, 화면 빌딩 속도 향상.

라이브러리는 의도적으로 작게 유지하세요. 누군가 새 변형을 요청하면 먼저 묻습니다: 이것이 실제 새로운 필요인가, 아니면 기존 변형으로 콘텐츠만 바꿔 해결할 수 있는가?

느리고 일관성 없는 UI를 만드는 일반적 실수

대부분의 불일치는 나쁜 취향 때문이 아닙니다. 복사가 쉽고, 조정이 빠르며, 아무도 뒤돌아보지 않기 때문에 생깁니다. 결과는 거의 비슷한 화면들이 모여 업데이트하기 어려운 상태가 됩니다.

흔한 함정 중 하나는 변형을 추가하는 대신 거의 중복된 것을 만드는 것입니다. 누군가는 ‘약간 더 큰 주요 버튼’이 필요해 컴포넌트를 복제합니다. 일주일 뒤 다른 사람이 또 복제하면 세 개의 버튼이 생기고 외형은 비슷하지만 동작이 달라집니다. 모든 변경이 수색 작업이 됩니다.

또 다른 속도 저하 요인은 지나치게 구성 가능한 컴포넌트입니다: 수십 개 토글을 가진 메가 컴포넌트는 유연하게 느껴지지만 예측 불가능해집니다. 사람들은 그것을 신뢰하지 않고 ‘이 경우만’용 버전을 만들기 시작합니다. 그러면 목적이 무너집니다.

레이아웃 실수도 큰 손상 원인입니다. 가장 큰 문제는 책임 혼합입니다: 컴포넌트가 외부 마진을 제어하고 화면이 추가 간격을 주면 랜덤한 간격이 생깁니다. 간단한 규칙이 도움이 됩니다: 컴포넌트는 내부 패딩을 정의하고 화면이 컴포넌트 사이 간격을 제어하세요.

보통 먼저 드러나는 문제들: 명명 규칙이 급할 때 깨짐, 상태가 늦게 추가됨(로딩, 빈, 오류), 일회성 조정이 영구화됨, 여러 사람이 같은 레이아웃을 서로 다르게 해결함.

새 화면마다 빠르게 확인할 체크리스트

무엇을 추가하기 전에 60초 멈추고 기본을 확인하세요. 화면은 괜찮아 보여도 시스템을 조용히 망가뜨릴 수 있고, 이러한 작은 균열이 여러 사람이 병행 작업할 때 빠르게 쌓입니다.

• 명명: 모든 컴포넌트가 합의된 패턴을 따르는가(예: Form/Input, Form/Input.HelperText, Table/RowActions). 이름이 검색과 배치에 도움이 되지 않으면 지금 이름을 바꾸세요.
• 소유자 + 목적: 공유 컴포넌트마다 소유자(개인 또는 팀)와 사용 시기를 한 문장으로 적어두세요.
• 간격 스케일만 사용: 모든 패딩, 갭, 마진은 승인된 간격 단계를 사용합니다. 새 숫자를 직접 입력하지 말고 가장 가까운 단계를 고르세요.
• 상태 포함: 주요 인터랙티브 요소는 즐거운 경로뿐 아니라 로딩과 오류 상태를 포함해야 합니다(예: 비활성 버튼, 입력 오류, 빈 목록, 재시도).
• 새 스타일 금지: 기존 토큰과 컴포넌트를 사용해 화면을 빌드하세요. 새 색상, 폰트 크기, 반경, 그림자가 필요하면 화면 수준 수정이 아니라 시스템 요청으로 처리하세요.

예시: 규칙 없이와 규칙을 갖고 같은 기능을 만든 경우

Maya와 Leon은 고객 지원 팀입니다. 그들은 두 개의 화면이 필요합니다: 티켓 리스트(빠르게 스캔)와 티켓 상세(하나의 티켓에 대해 조치). 작업을 나눠 시각적 빌더에서 만듭니다.

규칙이 없으면 각자 ‘카드’를 다르게 만듭니다. Maya는 얇은 테두리와 그림자가 있는 흰색 카드를 쓰고, Leon은 테두리 없이 회색 카드에 추가 패딩을 씁니다. 한 화면은 둥근 주요 버튼을 쓰고 다른 화면은 각진 버튼과 텍스트 링크를 씁니다. 상태는 한 화면에선 점(dot)으로 표시되고 다른 화면에선 필(pill)로 표시됩니다. 상세 페이지에서는 라벨 너비가 달라 필드 정렬이 맞지 않아 폼 전체가 흔들립니다.

리뷰 회의는 스타일 논쟁으로 변하고, 간단한 업데이트(예: ‘우선순위’ 추가)는 여러 일회성 레이아웃을 건드려야 합니다.

규칙이 있으면 공유 재사용 UI 컴포넌트에서 시작합니다: 구조와 간격을 위한 TicketCard, 상태 스타일과 대비를 위한 StatusBadge, 일관된 주요 액션을 위한 ActionBar.

그럼 리스트 화면은 주요 필드와 미리보기 라인이 있는 콤팩트 TicketCard 변형을 사용하고, 상세 화면은 전체 설명, 타임라인, 추가 필드를 위한 상세 변형을 씁니다. 구조는 동일하고 변형이 표시 항목을 제어합니다.

보이지 않는 최고의 이점: 리뷰 코멘트 감소, “왜 다르지?” 질문 감소, 이후 업데이트가 빨라집니다. 팀이 Closed를 Resolved로 이름 바꾸고 색을 조정하면 StatusBadge 하나만 바꾸면 두 화면이 함께 업데이트됩니다.

시간이 지나도 일관성을 유지하는 방법(다음 단계)

일관성은 한 번 설정으로 끝나지 않습니다. 더 많은 사람이 화면을 만들면 ‘이 화면만’을 위한 작은 선택들이 늘어나 라이브러리가 점차 흐트러집니다.

간단한 변경 절차가 팀을 움직이게 합니다. 모든 버튼 조정이 논쟁으로 번지지 않게 하려면:

• 제안: 무엇을 왜 바꾸는가(새 컴포넌트, 새 변형, 이름 변경, 사용중단)
• 검토: 디자이너나 UI 소유자가 네이밍, 간격 규칙, 접근성 기본을 확인
• 승인: 명확한 찬반과 필요한 경우 제한적 노트
• 릴리스: 공유 라이브러리 업데이트 후 변경 사항을 한 곳에 공지

결정의 집이 필요합니다. 짧은 ‘UI 규칙’ 문서만으로도 충분합니다. 명명 규칙, 공식 변형 목록(무엇이 있고 무엇이 없는지), 하지 말아야 할 목록(예: “다른 패딩을 가진 두 번째 ‘Primary Button’ 생성 금지”)을 포함하세요.

월간 정리 시간을 예약하세요. 중복 병합, 사용하지 않는 조각 제거, 오래된 컴포넌트 사용 중단 표기를 하세요. 이렇게 하면 사람들이 잘못된 것을 잡아가는 일이 줄어듭니다.

같은 패턴이 두 번 보이면 리팩터링을 고려하세요(예: 두 팀이 약간 다른 빈 상태를 만든 경우). 진짜 고유하고 시간 민감하며 반복될 가능성이 낮다면 일회성으로 두는 것도 괜찮습니다.

AppMaster에서 빌드한다면 현실적인 다음 단계는 하나의 워크플로(예: Create ticket)를 먼저 표준화한 뒤 확장하는 것입니다. UI 빌더는 동일한 컴포넌트를 여러 화면에서 공유하기 쉽게 하고, appmaster.io는 노코드 접근으로 전체 애플리케이션을 지원하는 참조 지점이 될 수 있습니다.