Backend developer
운영툴은 필수지만, 대부분의 백엔드 개발자는 운영툴 개발을 좋아하지 않습니다. API는 이미 잘 설계해두었는데, 운영팀·CS팀·파트너팀이 쓸 화면을 만들기 위해 새로운 프론트엔드 프로젝트를 열고, 테이블과 필터, 상세 보기, 수정 폼을 다시 구현해야 합니다.
릴리즈가 쌓일수록 “운영 화면”은 점점 늘어나고, 작은 변경에도 코드 수정과 배포가 필요해집니다. 결국 운영툴은 점점 손대기 어려운 영역이 되고, 백엔드 개발자는 제품 기능 개발보다 운영툴 요청을 처리하는 데 더 많은 시간을 쓰게 됩니다.
셀렉트 어드민은 이 지점을 완전히 없애진 않지만, 구조를 단순화합니다. 이미 가지고 있는 REST API를 기준으로, 리스트·상세·수정·액션을 정해진 UI 규칙 안에서 선언적으로 구성할 수 있게 해줍니다.
운영툴 관련 요청은 보통 이런 식으로 들어옵니다.
각 요청이 나올 때마다 해야 하는 일은 생각보다 많습니다.
한 번만 하는 작업이 아니라, 기능이 늘어날수록 계속 반복됩니다. 그 사이에 제품 기능 개발 일정은 뒤로 밀리고, “운영툴도 중요한데, 지금 여기에 시간을 쓰고 싶진 않다”는 딜레마가 생깁니다.
셀렉트 어드민은 이 반복 패턴을 줄이는 데 초점을 맞춥니다.
셀렉트 어드민은 “운영툴 UI를 자유롭게 만드는 프레임워크”가 아닙니다. 대신, 운영툴에서 반복되는 UI 패턴만 정해진 형태로 제공하고, 여기에 백엔드가 가진 API를 연결해 화면을 구성하는 도구입니다.
핵심은 세 가지입니다.
예를 들어, 특정 도메인에 대해 다음이 이미 있다고 해봅시다.
GET /orders : 주문 리스트 조회GET /orders/:id : 주문 상세 조회PATCH /orders/:id : 주문 상태 변경POST /orders/:id/cancel : 주문 취소셀렉트 어드민에서는 이 엔드포인트들을:
에 각각 연결하고, 어떤 필드를 어떤 컬럼/입력 값으로 쓸지 YAML에 선언합니다. UI는 이 스펙을 기준으로 도구가 제공하는 공통 레이아웃 안에서 렌더링됩니다.
새로운 컴포넌트를 매번 만들지 않고, 정해진 틀 안에서 필요한 부분만 스펙으로 채워 넣는 방식입니다.
셀렉트 어드민에서 운영 페이지는 전부 YAML 스펙으로 정의됩니다.
여기에는 다음 정보들이 들어갑니다.
예를 들면 이런 식입니다:
page:
id: orders
title: 주문 목록
blocks:
- table:
fetch:
url: /api/orders
method: GET
columns:
- key: id
label: 주문 ID
- key: customer_name
label: 고객명
- key: status
label: 상태
filters:
- key: status
label: 상태
type: select
options:
- pending
- completed
- canceled
이런 구조 덕분에, “운영툴 변경”이란 결국 YAML 수정과 적용에 가깝습니다. 코드 수준의 변경은 API 로직이 변할 때에만 필요합니다.
셀렉트 어드민은 기존 REST API를 최대한 그대로 활용하는 모델을 택합니다.
GET /entities 형태 API를 테이블과 연결GET /entities/:id를 상세 패널 또는 모달과 연결PATCH /entities/:id 또는 PUT API를 폼과 연결POST /entities/:id/approve, POST /entities/:id/cancel 같은 액션 API를 버튼으로 연결백엔드 입장에서는 “엔드포인트 설계”에 집중하고, UI 구성은 이미 정해진 패턴 안에서 조합하는 일로 줄어듭니다.
셀렉트 어드민의 강점 중 하나는 운영툴 구성이 코드와 비슷한 수명 주기를 가진다는 점입니다.
이 덕분에:
운영툴이 그때그때 빠르게 덕지덕지 붙는 게 아니라, 구조화된 레이어로 관리되는 방향으로 옮겨갑니다.
운영툴은 편리해야 하지만, 동시에 위험하기도 합니다. 셀렉트 어드민은 ENV와 권한 개념을 기본에 두고 있습니다.
이 수준의 구조만 갖춰도 “누구나 아무 화면에서나 모든 걸 할 수 있는” 운영툴의 위험을 많이 줄일 수 있습니다.
정리해 보면, 셀렉트 어드민은 다음을 가능하게 합니다.
운영툴을 위한 별도 프론트 프로젝트를 만들지 않아도 됩니다. UI는 도구가 제공하는 패턴을 사용하고, 백엔드는 API와 스펙 정의에 집중합니다.
운영툴 변경의 대부분을 “스펙 수정” 수준으로 처리할 수 있습니다. 필터/컬럼 추가, 액션 추가, 버튼 동작 변경 등의 요청에 대응하기 쉬워집니다.
같은 API로 여러 운영 페이지를 만들 수 있습니다. 운영팀·파트너 담당자·CS팀용 뷰를 각각 별도의 YAML 스펙으로 정의할 수 있습니다.
운영레이어가 코드와 비슷한 방식으로 관리됩니다. 변경 이력, 리뷰, 롤백 등 개발팀이 익숙한 방식으로 운영툴도 다룰 수 있습니다.
물론, 셀렉트 어드민이 모든 운영툴 케이스를 커버하는 것은 아닙니다. 복잡한 커스텀 UI/인터랙션이 필요한 경우, 직접 만드는 편이 더 적합할 수 있습니다. 하지만 리스트·필터·상세·상태 변경·액션 패턴이 반복되는 대부분의 내부 운영 화면에서는 “그때그때 SPA를 새로 만드는 방식”보다 훨씬 부담이 적습니다.
셀렉트 어드민은 “운영툴을 마법처럼 대신 만들어주는 도구”는 아닙니다. 대신, 백엔드 개발자가 이미 잘하고 있는 API 설계를 기준으로, 운영툴을 정해진 패턴 안에서 빠르게 구성하고 유지할 수 있게 해주는 레이어입니다.
운영 요청이 들어올 때마다 프론트 프로젝트를 열고 UI를 다시 만드는 대신, REST API와 YAML 스펙만으로 운영 페이지를 만들어 보고 싶다면, 셀렉트 어드민은 그 방식이 실제로 어떻게 작동하는지 확인해볼 수 있는 도구입니다.