공공기관 고도화 실전

웹 퍼블리셔를 위한 공통 UI 컴포넌트 설계 순서 (버튼·폼·테이블 기준)

DDODDO_LAB 2026. 2. 25. 14:43
반응형

공통 컴포넌트 설계 순서 (버튼/테이블/폼 우선순위)

(버튼/테이블/폼 우선순위)

고도화 프로젝트에서 공통 컴포넌트를 “예쁘게” 만들기보다 중요한 건 하나다.

먼저 만들면 손이 덜 가는 것부터 만든다.

 

특히 공공기관/관리자 화면은 테이블·폼·버튼이 반복되기 때문에
설계 순서가 곧 일정이다.

 

공통 컴포넌트 설계 순서

 

왜 “순서”가 중요한가?

 

공통을 늦게 잡으면 이런 일이 생긴다.

  • 페이지 20개 만든 뒤 버튼 스타일 전체 수정
  • 테이블 줄 간격/정렬 규칙이 페이지마다 달라짐
  • 폼 요소(인풋/셀렉트)만 QA 때 전부 걸림
  • 결국 “공통 반영”으로 재작업이 발생

고도화에서 공통은
초반에 고정해야 한다.

 

결론: 추천 설계 순서

1) 버튼 (Button)

2) 폼 (Form: input/select/checkbox/radio)

3) 테이블 (Table)

4) 상태/피드백 (badge, tooltip, toast, error)

5) 레이아웃 유틸 (grid, spacing)

 

이렇게 가면 제일 안전하다.


1. 버튼부터 만드는 이유 (가장 먼저)

버튼은 모든 화면에 존재하고,
디자인 변경 요청도 가장 자주 온다.

그리고 버튼이 정해지면
다른 컴포넌트가 연쇄적으로 정리된다.

버튼 설계 체크리스트

  1. 크기: S/M/L
  2. 타입: Primary / Secondary / Text / Danger
  3. 상태: default / hover / active / disabled / focus
  4. 아이콘 유무
  5. 접근성: 키보드 포커스(필수), aria-label (아이콘 버튼)

실무 팁

버튼은 .btn 하나로 끝내지 말고
modifier 규칙을 먼저 만든다.

예)

  • .btn
  • .btn--primary
  • .btn--secondary
  • .btn--lg
  • .btn--danger

이 규칙만 잡혀도
페이지 작업 속도가 확 올라간다.


2. 폼은 QA에서 가장 많이 걸린다 (두 번째)

공공기관/관리자 화면에서
폼 요소는 “검수 지뢰밭”이다.

  • focus 표시
  • placeholder 대비
  • disabled 스타일
  • 오류 메시지 구조
  • 필수 입력 표시

폼을 늦게 잡으면
모든 화면에서 수정해야 한다.

폼 설계 체크리스트

  1. input/text/textarea
  2. select
  3. checkbox/radio
  4. datepicker(있다면)
  5. validation 상태: error/success
  6. 도움말 텍스트 / 에러 텍스트 규칙

실무 팁

폼은 스타일만이 아니라
마크업 규칙을 함께 고정해야 한다.

예: label/desc/error 구조

  • label + input 묶는 규칙
  • 에러 메시지 위치 규칙
  • 도움말 텍스트 클래스 규칙

3. 테이블은 “마지막에” 만드는 이유 (의외로 세 번째)

많은 사람들이 테이블부터 만들고 싶어하지만,
테이블은 구성 요소가 많아서 먼저 만들면 잘 깨진다.

테이블은 사실상

  • 버튼
  • 배지/태그
  • 정렬 아이콘
  • 페이지네이션

이 모든 걸 포함한다.

그래서 버튼/폼 규칙이 먼저 잡혀야
테이블도 흔들리지 않는다.

테이블 설계 체크리스트

  1. 기본 테이블(조회용)
  2. 검색/필터 포함 테이블(관리자형)
  3. fixed header 여부
  4. 스크롤 테이블 여부
  5. 정렬(sort) UI
  6. 상태(empty/loading)
  7. 접근성: caption, scope, th 구조

실무 팁

테이블은 스타일보다 먼저
“정렬 규칙”을 문서로 고정해라.

  • 좌측 정렬/우측 정렬 기준
  • 숫자/금액 정렬 규칙
  • 버튼 그룹 위치
  • 행 높이(기본/컴팩트)

이게 페이지마다 달라지면 유지보수 끝난다.


공통 설계할 때 꼭 같이 정해야 하는 3가지

1) 네이밍 규칙 (BEM/Utility 등)

한 프로젝트에서 섞이면 지옥.

  • 공통은 BEM
  • 유틸은 u- 접두어
  • 상태는 is-/has-

같이 정해두면 좋다.

2) 로드 순서

공통 컴포넌트가 밀리면
page.css가 다 덮어쓴다.

권장:

  • base → layout → components → pages → override

3) 상태 디자인(Empty/Loading/Error)

고도화에서 “마지막에 추가” 하다가
QA 때 전부 걸리는 파트.


실무 적용 루틴 (바로 써먹는 순서)

  1. 버튼 1시간 안에 규칙/상태 정의
  2. 폼 마크업 규칙 + error 구조 고정
  3. 테이블은 “화면 1개”로 대표 타입 먼저 제작
  4. 그 다음 페이지 작업 들어가기

정리

고도화 프로젝트에서 공통 컴포넌트는
“정리 잘한 UI”가 아니라

재작업을 막는 설계

다.

 

버튼 → 폼 → 테이블 순서로 잡으면
속도와 안정성을 동시에 얻는다.

 

 

반응형