다리메이커
멀티 역할 B2B SaaS 백오피스
웹에이전시 거인소프트가 제작한 다리메이커 프로젝트입니다.
고시원 운영 관리를 위한 멀티 역할 B2B SaaS 백오피스 플랫폼으로 제작되었습니다.
다리메이커
3종 역할 기반 워케이션 관리 SaaS 플랫폼
- Next.js 14
- Refine
- NextAuth
- Recoil
- React Hook Form
- Zod
- TanStack Table
- Nivo
- Node.js
- Express
- MySQL
-
Project다리메이커
-
Period2024.10 ~ 2024.11
-
TypeB2B SaaS / Admin Platform
-
Role풀스택 개발 (1인 개발)
- 프로젝트 유형
- B2B SaaS / 워케이션 관리 플랫폼
- Frontend
- Next.js 14, Refine, Recoil, React Hook Form, Zod, TanStack Table, Nivo
- Backend
- Node.js, Express, MySQL, REST API
- 인증 시스템
- NextAuth 기반 3종 역할(관리자/기업담당자/근로자) 인증·인가
- 핵심 성과
- 55개 페이지, 25개 Data Provider, 대시보드 시각화, 수료증 PDF 생성, CRUD 표준 구조 수립 → 고수플러스에 재활용
Architecture
Overview
워케이션 프로그램을 운영하려면 관리자·기업담당자·근로자라는 세 종류의 사용자가 하나의 시스템 안에서 각각 다른 권한과 화면을 사용해야 했습니다. 신청부터 운영, 설문, 보고서, 수료증 발급까지 전 과정을 하나의 플랫폼에서 처리하되, 역할마다 접근 범위를 서버에서 검증하는 것이 핵심 과제였습니다.
이를 위해 17개 리소스에 대한 REST API와 DB 스키마를 설계하고, Refine 프레임워크 위에 역할별 커스텀 Data Provider를 구축하여 API 연동을 표준화했습니다. 이 확장형 CRUD 구조는 이후 두 번째 프로젝트인 고수플러스에 그대로 재활용되었습니다.
Key
Features
역할별 인증·인가 — 같은 리소스라도 관리자·기업담당자·근로자가 보는 데이터와 수행 가능한 액션이 달라야 했기에, 2~3종 역할별 접근 범위를 서버에서 검증하고 라우팅·API·UI를 일관 분리했습니다.
서버사이드 페이지네이션·정렬·필터 — 프로그램·회원·설문 등 대량 데이터를 다루는 관리 화면에서 클라이언트 부하를 줄이기 위해 서버 측 처리를 적용했습니다.
15개 폼 Zod 타입안전 검증 — 프로그램 등록, 설문 생성, 회원 수정 등 복잡한 입력 폼의 날짜 교차 검증까지 포함하여 런타임 오류를 사전에 차단했습니다.
수료증 PDF 생성 — 프로그램 수료 후 증빙이 필요한 기업 요구에 맞춰, html2canvas + jsPDF로 수료증을 즉시 생성·다운로드할 수 있도록 구현했습니다.
소프트삭제·감사 이력 — 운영 데이터의 추적성을 확보하기 위해 스키마에 소프트삭제와 감사 이력을 반영하여, 삭제된 데이터도 복원·추적이 가능하도록 설계했습니다.
User
Management
워케이션 플랫폼에는 관리자·기업담당자·근로자 세 종류의 회원이 존재하는데, 각 역할마다 볼 수 있는 정보와 수행할 수 있는 액션이 달라야 했습니다. 예를 들어 관리자는 전체 회원 목록과 권한 변경이 가능하지만, 기업담당자는 자사 소속 근로자만 조회할 수 있어야 했습니다.
이를 위해 역할(mbType)에 따라 노출 컬럼과 액션 버튼을 분기하고, 서버사이드 페이지네이션과 공통 코드 시스템으로 상태 뱃지·필터를 일관되게 렌더링했습니다. 이 역할 기반 테이블 패턴은 프로그램·설문·보고서 등 전체 리소스 관리 화면에 동일하게 적용되었습니다.
Challenge 1 | 3종 역할 기반 Data Provider 설계
상황: 관리자·기업담당자·근로자가 같은 화면(프로그램 목록, 회원 관리 등)을 사용하지만 각 역할마다 호출하는 API 엔드포인트와 응답 데이터가 달랐습니다. Refine의 기본 Data Provider는 단일 API 구조만 지원했기 때문에, 역할별 분기를 컴포넌트마다 개별 처리하면 17개 리소스 전체에 조건문이 산재할 위험이 있었습니다.
판단: 컴포넌트 레벨에서 분기하는 대신, Data Provider 자체를 역할별로 분리하면 비즈니스 로직과 API 호출을 깔끔하게 격리할 수 있다고 판단했습니다. 또한 이 구조가 충분히 범용적이면 다음 프로젝트에서도 재사용할 수 있을 것으로 예상했습니다.
액션: 역할별 커스텀 Data Provider(admin/manager/worker)를 분리 설계하고, RefineContext에서 세션의 role에 따라 동적으로 주입하는 구조를 만들었습니다. 각 Provider는 CRUD 표준 인터페이스를 공유하되, 엔드포인트와 인증·인가 로직만 역할에 맞게 교체했습니다.
결과: 이 확장형 CRUD 표준 구조를 두 번째 프로젝트인 고수플러스에 그대로 재활용하여, 개발 기간을 약 30~40% 단축할 수 있었습니다. 역할이 추가되더라도 새 Provider만 구현하면 되는 확장 가능한 아키텍처를 확보했습니다.
Challenge 2 | 공통 코드 시스템 설계
상황: 프로그램 상태, 성별, 설문 유형 등 코드성 데이터가 55개 이상의 페이지에서 반복적으로 사용되고 있었습니다. 필터 드롭다운, 상태 뱃지, 폼 셀렉트 옵션 등 곳곳에서 동일한 코드값이 필요했는데, 매번 API를 호출하면 불필요한 네트워크 비용이 발생하고, 프론트엔드에 하드코딩하면 백엔드 변경 시 불일치가 생기는 딜레마가 있었습니다.
판단: 코드 데이터는 변경 빈도가 낮지만 참조 빈도는 매우 높으므로, 앱 초기화 시점에 한 번만 가져와서 전역 상태로 캐싱하는 것이 최적이라고 판단했습니다. 하드코딩 대비 백엔드 정합성을 유지하면서도, 페이지별 반복 호출을 제거할 수 있는 방법이었습니다.
액션: 앱 초기화 시 /code API를 한 번 호출하여 Recoil atom에 저장하고, codesDto 유틸로 plain 배열과 codeMap 두 가지 형태로 변환하여 전역에서 참조하도록 구현했습니다. 필터 드롭다운에는 plain 배열을, 상태 뱃지 렌더링에는 codeMap을 사용하여 용도에 맞는 데이터 접근을 제공했습니다.
결과: 55개 이상의 페이지에서 코드 데이터 관련 API 호출이 초기 1회로 줄었고, 백엔드에서 코드값이 변경되어도 프론트엔드 수정 없이 자동 반영되는 구조를 확보했습니다. 이 패턴 역시 고수플러스에 재활용되었습니다.
What I Learned | 배운 점
다리메이커는 1인 개발로 17개 리소스의 REST API·DB 스키마 설계부터 프론트엔드 구현까지 전 과정을 경험한 프로젝트입니다. 가장 큰 수확은 "재사용 가능한 구조"의 실질적 가치를 체감한 것입니다.
역할별 Data Provider, 공통 코드 시스템, 서버사이드 페이지네이션 등 다리메이커에서 설계한 확장형 CRUD 표준 구조를 고수플러스에 그대로 재활용하여 두 번째 프로젝트의 개발 기간을 약 30~40% 단축했습니다. 처음부터 "다음 프로젝트에서도 쓸 수 있을까?"를 기준으로 설계하는 습관이 실제 성과로 이어진 경험이었습니다.
