셀렉트 어드민 - 사내 시스템 개발자를 위한 운영 레이어
조직이 성장하면, 내부툴은 더 이상 “누가 잠깐 만들어둔 페이지”가 아닙니다.
CS, 운영, 파트너, 세일즈, 재무 등 여러 팀의 일상이 내부툴 위에서 돌아갑니다.
사내 시스템 개발자 입장에서 보면, 문제는 단순하지 않습니다.
새로운 화면을 만드는 것보다,
이미 존재하는 수많은 내부툴을 어떻게 유지하고, 정리하고, 일관되게 가져갈 것인지가 더 어렵습니다.
- 팀마다 따로 만든 운영 페이지
- 비슷한 일을 하는데 서로 다른 UX를 가진 도구들
- 과거에 만들고 지금은 담당자도 없는 레거시 어드민
- 스프레드시트·쿼리 툴·임시 웹툴로 흩어진 운영 흐름
이 상태가 길어지면, 사내 시스템 개발자는
“새로운 도구를 만드는 사람”이 아니라
“파편화된 내부툴을 계속해서 설명하고 수습하는 사람”이 되기 쉽습니다.
셀렉트 어드민은 이 상황에서
내부툴을 “단순한 운영 레이어"로 쓰이도록 설계되었습니다.
흩어진 운영 화면이 만드는 숨은 비용들
사내 시스템 개발자가 조직에서 듣게 되는 요청들은 익숙합니다.
- “CS팀 화면이랑 파트너팀 화면이 다르게 동작하는데, 어느 쪽이 맞나요?”
- “이 페이지는 예전 버전인가요, 지 금도 쓰는 건가요?”
- “유사한 기능이 여기에도 있고 저기에도 있는데, 어디를 기준으로 바꾸면 되나요?”
문제는 화면 개수보다 규칙의 수입니다.
- 각 어드민마다 다른 테이블 컴포넌트
- 검색/필터 규칙이 페이지마다 제각각
- 승인/취소 같은 액션도 팀마다 구현 방식이 다름
- 권한과 역할이 화면마다 다르게 적용
이 구조에서는,
- 운영팀 온보딩에 시간이 오래 걸리고
- 장애가 발생했을 때 영향 범위를 좁히기 어렵고
- “이 도구는 누가 담당자인지”조차 모호해집니다.
사내 시스템 개발자의 진짜 과제는
“새로운 도구를 또 하나 만드는 것”이 아니라,
운영 레이어 전체를 일정한 규칙 아래에서 정리하는 일에 가깝습니다.
셀렉트 어드민이 제안하는 운영 레이어의 기준
셀렉트 어드민은 사내 시스템 개발자에게
“이제부터 운영 레이어는 이 규칙을 따른다”라는 기준을 줄 수 있는 도구를 목표로 합니다.
이 기준은 크게 세 가지 축으로 구성됩니다.
-
UI 패턴의 표준화
- 리스트, 필터, 정렬, 상세, 폼, 액션 버튼은 정해진 패턴에 맞춰 구성합니다.
- 팀·서비스마다 운영 UX를 새로 발명하지 않습니다.
-
YAML 스펙 기반 정의
- 화면이 어떤 데이터를 어떻게 보여주고,
어떤 액션을 어디로 날리는지
YAML 스펙으로 명시합니다.
- 스펙은 그대로 문서이자 코드이고, 재사용 가능한 자산이 됩니다.
-
API 중심 데이터 연동
- 데이터는 각 서비스의 API에서 가져옵니다.
- 사내 시스템 개발자는 “어떤 API를 어떤 페이지에 어떻게 연결할지”를 설계합니다.
이 구조를 통해 셀렉트 어드민은
각 팀이 제각각 쓰던 화면들을 하나씩 “공통 운영 레이어”로 가져오는 수단이 됩니다.
사내 시스템 개발자 입장에서의 “작업 단위”를 바꾸기
셀렉트 어드민을 사용할 때, 사내 시스템 개발자의 작업 단위는 달라집니다.
페이지/플로우 단위로 생각하기
더 이상 “이 화면 버튼 하나만 빨리 고쳐주세요” 수준의 요청에 끌려다니지 않고,
해당 요청이 어느 페이지, 어느 플로우, 어느 API와 연결되는지
운영 플로우 단위로 바라볼 수 있습니다.
- 특정 도메인(예: 주문, 파트너, 정산)에 대해
“리스트 → 상세 → 상태 변경” 흐름을 하나의 페이지 그룹으로 설계하고
- 각 팀(운영, CS, 파트너 담당자)을 위한 뷰를 스펙 단위로 분리할 수 있습니다.
화면이 아닌 스펙을 관리하기
셀렉트 어드민에서는
“이 화면이 어떤 데이터를 보여주고, 어떤 버튼이 어떤 API를 호출하는지”가
하나의 YAML 스펙으로 모입니다.
개발자는 더 이상 흩어진 화면 코드를 찾아다니기보다,
설명서 한 장을 고치는 느낌으로 운영툴을 관리할 수 있습니다.
이 방식의 장점은 단순합니다.
-
변경이 한 곳에 모입니다.
- 새 컬럼을 추가하거나 필터를 바꾸고 싶을 때, FE 코드 곳곳을 뒤지지 않고
해당 페이지의 YAML만 수정하면 됩니다.
-
추적·리뷰가 용이합니다.
- 누가 언제 어떤 필드를 숨겼는지,
어떤 액션이 어느 API로 바뀌었는지
스펙 변화만 보면 바로 알 수 있습니다.
-
영향 범위를 빠르게 가늠할 수 있습니다.
- 장애가 났을 때 “이 화면은 어떤 API에 기대고 있는지”,
“어떤 파라미터를 넘기는지”를 스펙 한 장에서 바로 확인할 수 있습니다.
사내 시스템 개발자의 역할은 점점
“각 팀의 운영 요구를 받아서 임시 화면을 만들어주는 사람”에서
“운영 레이어 전체의 구조와 규칙을 설계하는 사람”으로 바뀝니다.
셀렉트 어드민으로 운영 레이어를 쌓는 방식
이제 셀렉트 어드민이 실제로 어떻게 하나의 레이어로 묶는지를
사내 시스템 개발자의 작업 흐름 기준으로 정리해보겠습니다.
-
페이지 구조
- 메뉴에서 “페이지 추가”를 클릭해 기본 페이지를 생성합니다.
- 생성된 페이지 안에 테이블·상세·폼·액션 같은 블록들을 YAML로 정의합니다.
-
데이터 연동
- GET/POST/PATCH/DELETE API를
리스트·상세·수정·액션 블록에 연결합니다.
- JSON 응답 필드를 테이블 컬럼, 상세 정보, 폼 필드, 태그 등에 매핑합니다.
- “어떤 페이지가 어떤 API에 의존하는지”를 스펙에서 한눈에 볼 수 있습니다.
-
기본 UI 패턴
- 테이블, 검색/필터, 상세 모달, 폼, 단일/다중 선택 액션 등
내부 운영툴에서 반복되는 패턴은
셀렉트 어드민이 제공하는 공통 컴포넌트를 사용합니다.
- 팀마다 다른 방식으로 리스트/필터를 구현하는 대신,
“운영 레이어의 기본 UX”를 통일합니다.
이 구조는 조직마다 이미 존재하는 내부툴을
“한 번에 전부 갈아엎겠다”는 접근이 아닙니다.
우선순위가 높은 도메인부터 셀렉트 어드민 위로 옮겨오면서,
점점 공통 운영 레이어의 비중을 키워가는 방식입니다.
사내 시스템 개발자에게 생기는 실제 변화
셀렉트 어드민을 도입했을 때 사내 시스템 개발자에게 생기는 변화는 다음과 같습니다.
- 운영 화면을 새로 만들 때마다
프론트엔드 아키텍처를 다시 고민할 필요가 줄어듭니다.
- 팀마다 다른 방식으로 구현된 리스트/필터/상세/액션 패턴이
하나의 규칙으로 정리됩니다.
- 어떤 팀이 어떤 화면을 쓰는지,
운영 플로우가 어떤 API에 의존하는지
스펙 단위로 파악할 수 있습니다.
- 레거시 어드민을 정리할 때도
“스펙과 플로우” 기준으로 접근할 수 있습니다.
- 신규 팀·신규 서비스가 생겨도,
동일한 운영 레이어 위에서 시작할 수 있습니다.
사내 시스템 개발자는 점점
“오늘 들어온 요청을 처리하는 역할”에서
“조직 전체 운영 레이어의 건강 상태를 관리하는 역할”로 이동합니다.
언제 셀렉트 어드민이 특히 잘 맞을까
다음과 같은 상황이라면 셀렉트 어드민 도입을 적극 고려할 수 있습니다.
- 여러 팀이 운영툴을 사용하지만, UX·구조가 제각각인 상태
- 레거시 어드민과 임시 도구가 혼재해 있고,
담당자도 교체된 지 오래된 경우
- 새로운 내부툴을 만들 때마다
“이번에는 어떻게 만들지?”를 처음부터 논의하는 상황
- 내부 운영 화면을 일관된 규칙과 구조로 재정렬하고 싶다는 요구가 있을 때
반대로,
- 내부 플랫폼 팀과 대규모 프론트엔드 조직이 있고
- 내부툴 UX까지 전부 직접 설계·구현하려는 전략이라면,
셀렉트 어드민보다는 자체 플랫폼 구축이 더 잘 맞을 수 있습니다.
도구를 늘리는 것이 아니라, 레이어를 만드는 방향으로
사내 시스템 개발자의 목표는
내부툴의 “개수”를 늘리는 것이 아니라,
내부 운영을 떠받치는 레이어를 건강하게 만드는 것에 가깝습니다.
셀렉트 어드민은 이 레이어를:
- 정해진 UI 패턴 위에서
- YAML 스펙을 통해
- HTTP API를 기준으로
차근차근 다시 쌓아 올릴 수 있도록 돕는 도구입니다.
새로운 내부툴을 한 번 더 만드는 대신,
단순한 운영 레이어를 통해 정돈하는 선택을 하고 싶다면,
셀렉트 어드민이 그 장기적인 정리 작업을 시작하기에
좋은 출발점이 될 수 있습니다.