INTERACTIVE DEMO
어드민 작업 관리 테이블
검색 · 멀티셀렉트 필터 · 필터 칩 · 페이지네이션을 갖춘 관리자 작업 관리 테이블
Next.js 15 / MUI / TypeScript
작업 관리
| 작업명 | 서비스 | 상태 | 최근 실행 |
|---|---|---|---|
| 배치 작업 01 | 색인 관리 | 성공 | 2026-07-01 00:00 |
| 배치 작업 02 | 문서 수집 | 실행 중 | 2026-07-02 01:13 |
| 배치 작업 03 | AI 분류 | 실패 | 2026-07-03 02:26 |
| 배치 작업 04 | 리포트 | 대기 | 2026-07-04 03:39 |
| 배치 작업 05 | 색인 관리 | 성공 | 2026-07-05 04:52 |
| 배치 작업 06 | 문서 수집 | 실행 중 | 2026-07-06 05:05 |
CASE STUDY
관리자 대시보드에는 사용자 관리, 스케줄러, 색인 관리 등 성격이 다른 관리 화면이 수십 개 필요했고, 전부 “검색·필터·정렬·선택·페이지네이션이 달린 테이블”이라는 같은 뼈대를 공유했습니다. 화면마다 테이블을 따로 구현하면 코드 중복은 물론 동작(필터 시 페이지 리셋, 선택 상태, 빈 데이터 처리)이 화면마다 미묘하게 어긋나는 문제가 보였습니다. 여기에 역할별 권한에 따라 보이는 화면까지 달라야 했습니다.
“화면마다 다른 것과 같은 것을 분리해, 같은 것은 한 번만 구현한다”는 가설로 TypeScript 제네릭 기반 공통 컴포넌트 GenericTableCard<T, F>를 직접 설계했습니다. 도메인마다 달라지는 부분은 밖에서 주입받고(renderRow 렌더 프롭, applyFilter 필터 로직, 툴바·필터결과 슬롯), 공통 동작(정렬·선택·페이지네이션·상태 탭·빈 상태)은 컴포넌트가 흡수했습니다. 데이터 규모에 따라 클라이언트/서버 페이지네이션을 전환하는 serverMode도 같은 인터페이스로 제공했고, 서버 상태는 TanStack Query, 화면 상태는 Zustand로 소유자를 나눴습니다.
이 공통 컴포넌트 하나가 17개 관리 화면에서 재사용됐고, 새 관리 화면을 추가할 때는 행 렌더러와 필터 로직만 작성하면 되는 구조가 됐습니다. 날짜 범위 피커, 대시보드 카드, 데이터 그리드 등 다른 커스텀 컴포넌트도 같은 원칙으로 만들어 화면 전반의 동작 일관성을 확보했습니다. 이 데모는 그 공통 테이블의 상태 설계를 샘플 데이터로 재현한 것입니다.
재사용 컴포넌트의 핵심은 “무엇을 흡수하고 무엇을 열어둘 것인가”라는 추상화 경계 설계라는 것을 배웠습니다. 경계를 잘못 잡으면 옵션만 늘어난 괴물이 되는데, 렌더 프롭과 슬롯으로 변화를 밖으로 밀어내는 방식이 제네릭 컴포넌트를 오래 살게 한다는 감각을 이 프로젝트에서 얻었습니다.
기술 노트
- ·실무에서는 TypeScript 제네릭 공통 컴포넌트(GenericTableCard<T, F>)로 구현 — renderRow 렌더 프롭, 필터 로직 주입, 툴바·필터결과 슬롯
- ·클라이언트/서버 페이지네이션을 같은 인터페이스로 전환하는 serverMode 설계
- ·멀티셀렉트 필터의 선택 표시 로직('All' / 'N selected'), 필터 칩 · 결과 건수 · 초기화 UX
- ·필터 변경 시 페이지 리셋 등 파생 상태 간 일관성 유지
관련 프로젝트
관리자 대시보드
다른 데모