Backend developer

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

운영툴은 필수지만, 대부분의 백엔드 개발자는 운영툴 개발을 좋아하지 않습니다. API는 이미 잘 설계해두었는데, 운영팀·CS팀·파트너팀이 쓸 화면을 만들기 위해 새로운 프론트엔드 프로젝트를 열고, 테이블과 필터, 상세 보기, 수정 폼을 다시 구현해야 합니다.

릴리즈가 쌓일수록 “운영 화면”은 점점 늘어나고, 작은 변경에도 코드 수정과 배포가 필요해집니다. 결국 운영툴은 점점 손대기 어려운 영역이 되고, 백엔드 개발자는 제품 기능 개발보다 운영툴 요청을 처리하는 데 더 많은 시간을 쓰게 됩니다.

셀렉트 어드민은 이 지점을 완전히 없애진 않지만, 구조를 단순화합니다. 이미 가지고 있는 REST API를 기준으로, 리스트·상세·수정·액션을 정해진 UI 규칙 안에서 선언적으로 구성할 수 있게 해줍니다.


1. 운영툴 때문에 백엔드 일정이 계속 밀리는 이유

운영툴 관련 요청은 보통 이런 식으로 들어옵니다.

  • “CS팀에서 쓸 사용자 상세 화면이 필요해요.”
  • “파트너 상태를 보고 승인/거절할 수 있는 페이지가 있었으면 해요.”
  • “운영팀이 오류 건을 필터링해서 처리할 수 있으면 좋겠어요.”

각 요청이 나올 때마다 해야 하는 일은 생각보다 많습니다.

  • 운영용 SPA 프로젝트 만들기 (또는 기존 어드민 수정)
  • 라우팅 추가
  • 테이블 컴포넌트/필터/정렬/페이지네이션 구성
  • 상세 보기/수정 폼/버튼/상태 관리
  • 권한 체크, 에러 처리, 배포 준비

한 번만 하는 작업이 아니라, 기능이 늘어날수록 계속 반복됩니다. 그 사이에 제품 기능 개발 일정은 뒤로 밀리고, “운영툴도 중요한데, 지금 여기에 시간을 쓰고 싶진 않다”는 딜레마가 생깁니다.

셀렉트 어드민은 이 반복 패턴을 줄이는 데 초점을 맞춥니다.


2. 셀렉트 어드민이 다루는 범위: UI를 새로 짓지 않고, 스펙으로 조립하기

셀렉트 어드민은 “운영툴 UI를 자유롭게 만드는 프레임워크”가 아닙니다. 대신, 운영툴에서 반복되는 UI 패턴만 정해진 형태로 제공하고, 여기에 백엔드가 가진 API를 연결해 화면을 구성하는 도구입니다.

핵심은 세 가지입니다.

  1. UI 패턴은 정해져 있고
  2. 데이터는 REST API로 가져오며
  3. 화면 구성은 YAML 스펙으로 정의한다

예를 들어, 특정 도메인에 대해 다음이 이미 있다고 해봅시다.

  • GET /orders : 주문 리스트 조회
  • GET /orders/:id : 주문 상세 조회
  • PATCH /orders/:id : 주문 상태 변경
  • POST /orders/:id/cancel : 주문 취소

셀렉트 어드민에서는 이 엔드포인트들을:

  • 리스트 테이블
  • 상세 보기 모달
  • 수정 폼
  • 액션 버튼

에 각각 연결하고, 어떤 필드를 어떤 컬럼/입력 값으로 쓸지 YAML에 선언합니다. UI는 이 스펙을 기준으로 도구가 제공하는 공통 레이아웃 안에서 렌더링됩니다.

새로운 컴포넌트를 매번 만들지 않고, 정해진 틀 안에서 필요한 부분만 스펙으로 채워 넣는 방식입니다.


3. YAML 기반으로 운영 페이지를 정의하고 관리하기

셀렉트 어드민에서 운영 페이지는 전부 YAML 스펙으로 정의됩니다.

여기에는 다음 정보들이 들어갑니다.

  • 이 페이지가 어떤 메뉴/경로에 노출되는지
  • 테이블에 어떤 컬럼을 어떤 이름으로 보여줄지
  • 필터는 어떤 조건을 제공할지
  • 상세 보기에서 어떤 필드를 어떻게 표시할지
  • 어떤 버튼이 어떤 API를 호출할지
  • 어떤 역할이 이 페이지와 액션을 사용할 수 있는지

예를 들면 이런 식입니다:

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 로직이 변할 때에만 필요합니다.


4. REST API를 기준으로 리스트·상세·수정·액션을 분리해서 붙이기

셀렉트 어드민은 기존 REST API를 최대한 그대로 활용하는 모델을 택합니다.

리스트

  • GET /entities 형태 API를 테이블과 연결
  • 응답에 포함된 필드를 컬럼과 필터로 지정
  • 페이지네이션/정렬은 규칙에 따라 설정

상세 보기

  • GET /entities/:id를 상세 패널 또는 모달과 연결
  • 특정 필드를 읽기 전용, 특정 필드는 편집 가능 등으로 구분 가능

수정

  • PATCH /entities/:id 또는 PUT API를 폼과 연결
  • 폼 필드는 응답/요청 스키마 중 일부를 선택해 구성

액션

  • POST /entities/:id/approve, POST /entities/:id/cancel 같은 액션 API를 버튼으로 연결
  • 버튼 클릭 시 어떤 메서드/URL/바디를 보낼지 스펙에 정의
  • 응답 결과에 따라 메시지 표시나 테이블 새로고침 등을 설정

백엔드 입장에서는 “엔드포인트 설계”에 집중하고, UI 구성은 이미 정해진 패턴 안에서 조합하는 일로 줄어듭니다.


5. 코드처럼 관리 가능한 운영툴 스펙

셀렉트 어드민의 강점 중 하나는 운영툴 구성이 코드와 비슷한 수명 주기를 가진다는 점입니다.

  • YAML 스펙 파일은 Git 레포에 저장할 수 있습니다.
  • 운영툴 변경은 PR로 관리하고 리뷰할 수 있습니다.
  • 어떤 버전에서 어떤 페이지 구성이었는지 이력을 남길 수 있습니다.

이 덕분에:

  • “이 화면 왜 이렇게 동작하죠?”라는 질문이 들어왔을 때, 스펙을 기준으로 바로 파악할 수 있고
  • 운영툴 변경 자체가 “문서화된 변경”이 됩니다.

운영툴이 그때그때 빠르게 덕지덕지 붙는 게 아니라, 구조화된 레이어로 관리되는 방향으로 옮겨갑니다.


6. 환경(ENV) 분리와 권한 관리를 통해 운영 리스크 줄이기

운영툴은 편리해야 하지만, 동시에 위험하기도 합니다. 셀렉트 어드민은 ENV와 권한 개념을 기본에 두고 있습니다.

ENV 분리

  • Development / Staging / Production 등 환경 별로 다른 endpoint를 지정할 수 있습니다.
  • 같은 페이지 스펙을 사용하지만, 실제로 호출되는 API와 데이터는 환경 별로 분리됩니다.
  • 운영팀이 쓰는 URL은 같아도, “어느 환경을 보고 있는지”를 명확히 관리할 수 있습니다.

권한 제어

  • 특정 페이지는 특정 역할/그룹에만 보여줄 수 있습니다.
  • 민감한 액션(삭제, 정산, 강제 상태 변경 등)은 별도의 권한이 있어야 수행할 수 있게 구성할 수 있습니다.

이 수준의 구조만 갖춰도 “누구나 아무 화면에서나 모든 걸 할 수 있는” 운영툴의 위험을 많이 줄일 수 있습니다.


7. 셀렉트 어드민이 백엔드 개발자에게 현실적으로 주는 이점

정리해 보면, 셀렉트 어드민은 다음을 가능하게 합니다.

  • 운영툴을 위한 별도 프론트 프로젝트를 만들지 않아도 됩니다. UI는 도구가 제공하는 패턴을 사용하고, 백엔드는 API와 스펙 정의에 집중합니다.

  • 운영툴 변경의 대부분을 “스펙 수정” 수준으로 처리할 수 있습니다. 필터/컬럼 추가, 액션 추가, 버튼 동작 변경 등의 요청에 대응하기 쉬워집니다.

  • 같은 API로 여러 운영 페이지를 만들 수 있습니다. 운영팀·파트너 담당자·CS팀용 뷰를 각각 별도의 YAML 스펙으로 정의할 수 있습니다.

  • 운영레이어가 코드와 비슷한 방식으로 관리됩니다. 변경 이력, 리뷰, 롤백 등 개발팀이 익숙한 방식으로 운영툴도 다룰 수 있습니다.

물론, 셀렉트 어드민이 모든 운영툴 케이스를 커버하는 것은 아닙니다. 복잡한 커스텀 UI/인터랙션이 필요한 경우, 직접 만드는 편이 더 적합할 수 있습니다. 하지만 리스트·필터·상세·상태 변경·액션 패턴이 반복되는 대부분의 내부 운영 화면에서는 “그때그때 SPA를 새로 만드는 방식”보다 훨씬 부담이 적습니다.


마무리: 운영툴 때문에 일정이 계속 밀리는 상황에서 벗어나고 싶다면

셀렉트 어드민은 “운영툴을 마법처럼 대신 만들어주는 도구”는 아닙니다. 대신, 백엔드 개발자가 이미 잘하고 있는 API 설계를 기준으로, 운영툴을 정해진 패턴 안에서 빠르게 구성하고 유지할 수 있게 해주는 레이어입니다.

운영 요청이 들어올 때마다 프론트 프로젝트를 열고 UI를 다시 만드는 대신, REST API와 YAML 스펙만으로 운영 페이지를 만들어 보고 싶다면, 셀렉트 어드민은 그 방식이 실제로 어떻게 작동하는지 확인해볼 수 있는 도구입니다.