문제
이 고객사는 행사·캐스팅을 중개하는 에이전시였습니다. 가수, 광고모델, 강연자, MC, 공연팀까지 다루는 분야가 넓었고, 분야마다 관리해야 하는 정보가 전부 달랐습니다. 가수는 장르와 구성(솔로·그룹)이 중요하고, 강연자는 강연 분야가, 광고모델은 연령대가 핵심이었습니다. 이 모든 걸 하나의 엑셀 양식에 욱여넣다 보니 시트가 갈라지고, 같은 인물 정보가 파일마다 따로 돌아다녔습니다.
문제는 데이터 구조만이 아니었습니다. 문의가 들어오면 섭외를 확정하고, 계약서를 보내고, 행사가 끝나면 출연료와 인센티브를 정산하고, 매출을 집계하는 일련의 흐름이 전부 사람 손과 카카오톡, 별도 엑셀로 이어져 있었습니다. 정보가 한 곳에 없으니 "그 건 어떻게 됐더라"를 매번 사람에게 물어봐야 했습니다.
가장 까다로운 요구는 따로 있었습니다. 분야가 늘거나 관리 항목이 바뀔 때마다 개발자를 부르고 싶지 않다는 것이었습니다. 새 분야를 추가하거나 "이 항목도 검색되게 해달라"는 요청이 수시로 생기는데, 그때마다 테이블을 바꾸고 배포하는 구조라면 운영이 멈춥니다.
접근
핵심은 데이터 구조 자체를 고객이 바꿀 수 있게 만드는 것이었습니다. 카테고리마다 필요한 필드가 다르고 그 목록이 계속 변한다면, 필드를 코드가 아니라 데이터로 다뤄야 합니다. 그래서 PostgreSQL의 JSONB를 활용한 동적 필드 시스템을 데이터 레이어의 중심에 놓았습니다. 카테고리별 필드 정의는 관리자가 화면에서 직접 추가·수정하고, 실제 인물 데이터는 JSONB 컬럼에 담깁니다. 검색 성능을 위해 GIN 인덱스를 걸어 JSONB 안의 값으로도 필터가 빠르게 동작하도록 했습니다.
기능
코드 없이 카테고리마다 다른 필드를 정의하는 동적 스키마
관리자가 카테고리별로 필드(이름·타입·검색 여부)를 직접 정의합니다. 가수에는 장르·구성을, 강연자에는 강연 분야를, 광고모델에는 연령대를 두는 식으로, 분야마다 완전히 다른 데이터 구조를 코드 수정이나 배포 없이 화면에서 구성합니다.
카테고리별 필드 정의 관리 화면
필드를 데이터로 다루니 검색도 데이터를 따라가야 했습니다. 인물 검색 화면은 선택한 카테고리에 맞춰 검색 조건이 실시간으로 바뀝니다. 가수를 고르면 성별·구성으로 거르고, 강연자를 고르면 강연 분야가, 광고모델을 고르면 연령대 범위가 조건으로 나타납니다. 같은 검색 화면이지만 카테고리마다 완전히 다른 폼이 되는 셈입니다.
기능
카테고리에 따라 검색 조건이 바뀌는 인물 DB
카테고리를 바꾸면 검색 조건 영역이 그 카테고리의 필드 정의를 읽어 다시 그려집니다. 운영자는 분야가 추가돼도 새 검색 화면을 따로 만들 필요가 없습니다.
카테고리를 전환하면 검색 조건 필드가 동적으로 바뀌는 인물 DB 화면
이 동적 데이터 레이어 위에 에이전시의 실제 업무 흐름을 통째로 올렸습니다. 문의가 들어오면 칸반 보드의 카드로 등록되고, 섭외가 확정되면 상태가 전환되며 같은 데이터가 계약 단계로 넘어갑니다. 계약서는 전자계약(모두싸인)으로 발송하고, 서명 완료 상태는 웹훅으로 시스템에 다시 반영됩니다. 행사가 끝나면 출연료와 인센티브가 규칙에 따라 계산되고, 입금 내역과 자동으로 대조해 정산 PDF까지 만들어집니다. 매출 보고서는 이 데이터를 행사일 기준으로 집계합니다.
운영 안전장치도 함께 설계했습니다. 관리자·직원 역할과 페이지·카테고리 단위 권한을 두어 누가 무엇을 보고 고칠 수 있는지 통제하고, 기존 엑셀 자산은 업로드 → 필드 매핑 → 비동기 실행의 3단계 임포트로 시스템에 옮겼습니다. 데이터는 구글 드라이브로 백업됩니다.
기술적으로는 Rails 8 + Hotwire(Turbo·Stimulus) 조합으로, 무거운 SPA 없이도 화면 전환이 매끄러운 내부 도구를 만들었습니다.
결과
흩어져 있던 섭외·계약·회계·정산·보고가 하나의 시스템 안에서 이어지면서, "그 건 어떻게 됐더라"를 사람에게 묻는 일이 줄었습니다. 무엇보다 고객의 업무가 바뀔 때 개발자를 기다리지 않아도 됩니다. 새 분야를 추가하거나 관리 항목을 바꾸는 일은 이제 관리자 화면에서 직접 처리됩니다.
이 사례에서 우리가 가장 신경 쓴 것은 "지금 요구사항을 구현하는 것"이 아니라 "앞으로 바뀔 요구사항을 고객이 직접 감당할 수 있게 하는 것"이었습니다. 그 선택이 데이터 구조부터 권한, 마이그레이션까지 전체 설계를 관통합니다.
이 프로젝트에서 다룬 기술적 선택들은 아래 글에서 더 자세히 풀었습니다.
- 고객사마다 다른 스키마 다루기: JSONB 동적 필드 설계
- 엑셀을 버리지 않고 시스템으로 옮기는 법: 단계적 임포트
- 전자계약을 시스템에 통합하기: 모두싸인 API·웹훅
- 출연료 정산을 자동화한 방법: 인센티브 계산과 입금 매칭
자주 묻는 질문
동적 필드 시스템은 기존 데이터베이스를 자주 바꿔야 하나요?
아니요. 카테고리마다 다른 필드는 별도 테이블을 만드는 대신 JSONB 컬럼 하나에 담고, 필드 정의는 데이터로 관리합니다. 새 필드를 추가해도 마이그레이션이나 배포가 필요 없고, 관리자 화면에서 바로 반영됩니다.
JSONB로 검색하면 느리지 않나요?
JSONB 컬럼에 GIN 인덱스를 걸면 내부 값으로 거르는 검색도 빠르게 동작합니다. 자주 쓰는 검색 조건은 카테고리 필드 정의에서 "검색 가능"으로 표시해 인덱스가 받쳐주는 범위 안에서 다루도록 설계했습니다.
엑셀로 관리하던 데이터도 옮길 수 있나요?
네. 업로드한 엑셀의 열을 시스템 필드에 매핑하고 비동기로 실행하는 3단계 임포트를 제공합니다. 수천 건 단위도 백그라운드 작업으로 처리해 화면이 멈추지 않습니다.
분야가 늘어나면 새로 개발해야 하나요?
새 카테고리를 만들고 필요한 필드를 정의하면 검색·목록·입력 화면이 그 정의를 따라 자동으로 구성됩니다. 분야 추가는 운영 업무이지 개발 업무가 아니도록 설계했습니다.