Backend Developers

프론트엔드 없이 HTTP API와 YAML로

리스트·상세·수정·액션 페이지를 선언적으로 구성하세요.

셀렉트 어드민 - 운영툴 부담을 줄이는 백엔드 개발자 중심 운영 레이어

운영툴을 어떻게 만들고 유지해야 할지에 대한 고민은 대부분의 팀에서 반복됩니다. API는 이미 잘 정리되어 있고, 데이터 모델도 안정적입니다. 하지만 운영팀·CS팀·파트너팀이 사용할 화면을 만들어야 할때는 다른 일이 됩니다. 새로운 프론트엔드 프로젝트를 열고, 테이블과 필터를 다시 구성하고, 수정 폼을 만들고, 배포까지 진행해야 합니다.

초기에는 단순한 운영 페이지 몇 개만 있으면 충분합니다. 하지만 서비스가 성장하면 운영 화면은 도메인별로 분리되고, 요구사항이 세분화되면서 점점 복잡해집니다. 어느 순간부터 운영툴은 “손대기 어려운 영역”이 되고, 작은 변경이라도 전체 개발 일정에 영향을 주기 시작합니다.

셀렉트 어드민은 이 지점에서 출발했습니다. HTTP API를 중심에 두고, 리스트·상세·수정·액션 페이지를 “정해진 UI 패턴” 안에서 선언적으로 구성할 수 있게 합니다. 프론트엔드 프로젝트를 새로 만들 필요가 없고, 화면 컴포넌트를 직접 구현할 필요도 없습니다. YAML 스펙을 정의하면 UI는 자연스럽게 렌더링됩니다.

처음에는 단순해 보이지만, 실제로는 운영툴 개발의 반복적 작업을 효과적으로 제거합니다. 운영 페이지가 늘어나더라도 API만 유지하면 되며, 운영 레이어가 점차 정리되어 갑니다.

운영툴이 시간이 지날수록 부담이 커지는 이유

운영팀이 요청하는 기능들은 대부분 비슷한 패턴을 가집니다.

“파트너 상태 승인/거절 페이지가 필요합니다.”
“CS팀이 사용자 상세 정보를 볼 수 있어야 합니다.”
“오류 건을 필터링하고 처리할 수 있어야 합니다.”

문제는 이 기능들을 구현하기 위해 필요한 작업이 단순하지 않다는 점입니다.

운영용 프론트 프로젝트 구성
라우팅 및 테이블 컴포넌트 설정
필터·검색 조건 추가
상세 보기 모달 구성
액션 버튼과 상태 변경 API 연결
권한 검토 및 배포

운영 요구가 늘어날수록 반복해야 하는 작업량도 함께 증가합니다. 이 구조는 팀 규모와 상관없이 항상 비슷한 패턴으로 나타납니다.

셀렉트 어드민은 이 반복을 줄이고, 화면을 새로 만드는 대신 “정의”하는 방식으로 전환하는 데 중점을 둡니다.

UI를 직접 만들지 않고, 스펙을 조립하는 방식

셀렉트 어드민은 “운영툴 UI를 자유롭게 디자인하는 툴”이 아닙니다. 대신 운영툴에서 반복적으로 등장하는 UI 패턴을 정제해 제공합니다. 백엔드 개발자는 이미 가지고 있는 API를 이 패턴에 연결하기만 하면 됩니다.

기본 패턴은 다음과 같습니다.

리스트 → 테이블 패턴
상세 → 정보 표시 패턴
수정 → 입력 폼 패턴
액션 → API 호출 패턴

이 패턴들은 운영툴에 필요한 대부분의 UX 흐름을 충족하며, 일관된 구조 덕분에 화면은 한결 단순하게 구성할 수 있습니다.

셀렉트 어드민의 관점은 명확합니다. 대부분의 운영 페이지는 결국 구조가 비슷하므로, 그 반복을 효율적으로 해결하는 데 집중하자는 것입니다.

YAML로 운영 레이어를 코드처럼 관리하기

셀렉트 어드민에서 모든 운영 화면은 YAML 스펙으로 정의됩니다. 스펙 안에는 화면 구성에 필요한 정보가 담깁니다.

어떤 컬럼을 보여줄지
어떤 파라미터를 필터로 사용할지
상세 보기에 표시할 필드
버튼 클릭 시 호출할 API

이 스펙은 코드처럼 버전 관리가 가능하고, 사람이 읽기에도 명확합니다. 변경 사항을 쉽게 비교할 수 있고, 리뷰도 쉬워집니다.

결과적으로 운영툴은 직접 만든 UI가 아니라, 선언된 스펙을 기반으로 렌더링되는 구조가 됩니다. 이는 작은 변경에도 많은 프론트 코드를 수정해야 했던 기존 방식과 다릅니다.

API를 기준으로 리스트·상세·수정·액션을 연결하는 구조

셀렉트 어드민은 HTTP API 기반으로 화면을 구성합니다. API가 있다면 리스트와 상세, 수정과 액션은 자연스럽게 연결됩니다.

리스트 → GET /entities
상세 → GET /entities/:id
수정 → PATCH /entities/:id
액션 → POST /entities/:id/*

프론트 코드를 작성해 데이터를 매핑하거나 별도의 컴포넌트를 구성할 필요가 없습니다. 어떤 필드를 컬럼으로 사용할지, 어떤 값을 표시할지, 어떤 API를 호출할지를 스펙으로 정의하면 됩니다.

여러 도메인이나 팀별로 다른 화면을 구성해야 할 때에도, API만 유지하면 서로 다른 스펙을 쉽게 만들 수 있습니다. 백엔드 개발자는 API 설계에 집중할 수 있고, 운영 레이어는 자연스럽게 정돈됩니다.

백엔드 개발자에게 실제로 생기는 변화

정리하면, 셀렉트 어드민은 다음과 같은 변화를 만듭니다.

운영툴을 위한 별도 프론트 프로젝트를 만들 필요가 없습니다.
운영툴 변경 대부분을 YAML 수정으로 처리할 수 있습니다.
팀별 화면을 분리하기 쉬워집니다.
API 중심의 명확한 운영 구조를 유지할 수 있습니다.
운영 레이어를 “페이지”가 아니라 “스펙 단위”로 관리할 수 있습니다.

그리고 무엇보다, 운영툴이 백엔드 개발자 일정에 부담으로 남지 않게 됩니다. 운영 요청이 들어와도 제품 기능 개발과 충돌하지 않고, API 설계 흐름 안에서 자연스럽게 해결할 수 있습니다.

작게 시작하고, 자연스럽게 확장할 수 있습니다

셀렉트 어드민은 한 번에 모든 운영툴을 교체해야 하는 도구가 아닙니다. 오히려 작은 페이지 하나부터 시작하는 방식이 더 자연스럽습니다.

단순 리스트 화면
내부 검토용 상세 보기
간단한 상태 변경 페이지

이 작은 페이지들이 하나둘 쌓이면, 어느 순간 운영 레이어 전체가 정리되어 있음을 체감하게 됩니다. 기존 운영툴을 즉시 걷어낼 필요도 없습니다. 필요한 부분부터 점진적으로 옮기면 됩니다.

API는 이미 준비되어 있습니다. 이제 그 위에 운영 레이어를 쌓는 일만 남아 있습니다.

그리고 시간이 지나면, 운영툴은 “개발해야 하는 UI”에서 “정의하면 자동으로 구성되는 레이어”로 자연스럽게 변화하게 됩니다.