Technical Lead and Founder

셀렉트 어드민 — 기술 창업자를 위한 운영 레이어

초기 팀에서 기술 창업자는 제품 개발, 인프라, 배포, 운영, 파트너 대응까지 대부분의 기술 의사결정을 혼자 책임지는 경우가 많습니다. MVP를 출시하고 고객·파트너·운영이 붙기 시작하면, 제품 화면 외에 운영을 위한 별도 화면들이 필요해집니다.

파트너 승인 / 상태 관리
예약·주문·결제 검수
내부 설정·메타데이터 변경
CS팀이 참조·수정해야 하는 고객 정보 화면

이런 운영툴은 분명 필요하지만, 이것들을 위해 새로운 프론트엔드 프로젝트를 계속 만드는 것은 현실적으로 부담이 큽니다. 셀렉트 어드민은 이 지점을 정면에서 다룹니다. “운영툴을 잘 만드는 것”이 아니라, 운영툴을 “관리 가능한 구조”로 만드는 것에 집중한 제품입니다.

1. 초기 스타트업에서 운영툴이 항상 뒤로 밀리는 이유

초기에는 “일단 제품부터”가 자연스러운 우선순위입니다. 하지만 제품이 시장에서 조금이라도 반응을 얻기 시작하면, 운영 관련 요구사항이 빠르게 늘어납니다.

파트너사가 본인 상태를 확인하거나 요청할 수 있는 화면
내부 운영팀이 주문·예약·티켓을 필터링·정렬해서 처리해야 하는 화면
특정 플래그/파라미터를 조정하는 내부 설정 화면

보통 이 시점에서 선택지는 두 가지입니다.

임시 도구로 버티기
- Notion, 시트, 쿼리 도구, 임시 API를 섞어서 사용
- 사람마다 쓰는 화면과 기준이 달라지고, 데이터 신뢰도와 속도가 떨어짐
운영툴을 제대로 한 번 만들어 보기
- 별도 어드민 프론트엔드(React/Next 등)를 만들고
- 라우팅, 인증, 테이블, 필터, 상세, 액션, 권한, 배포까지 모두 구현

둘 다 단점이 분명합니다. 1번은 운영 품질·속도 문제, 2번은 시간·에너지 문제를 안고 갑니다. 그러다 보면 “운영툴을 개선해야 하는건 알지만, 지금은 당장 손 못 대는 상태”가 길어집니다.

2. 셀렉트 어드민이 보는 ‘운영 레이어’라는 개념

셀렉트 어드민은 “운영툴을 예쁘게 그려준다”는 관점이 아니라, 회사 내부에 하나의 운영 레이어(Operations Layer)를 만드는 도구라는 관점으로 설계되어 있습니다.

이 레이어는 다음과 같은 특징을 갖습니다.

UI 패턴이 정해져 있습니다. 테이블, 필터, 정렬, 상세 보기, 폼, 액션 버튼 등의 형태는 도구가 제공하는 규칙을 따릅니다. 운영툴마다 제각각 다른 UI 패턴을 정의하지 않습니다.
각 화면은 YAML 스펙으로 정의합니다. “어떤 데이터를 어떤 컬럼으로 보여줄지”, “어떤 필터/정렬을 제공할지”, “어떤 버튼이 어떤 API를 호출할지”를 YAML로 선언합니다.
데이터는 REST API를 통해 가져옵니다. 기존 서비스 백엔드에 이미 존재하는 API를 사용하거나, 운영용 API를 만들어서 연결합니다.

이 구조를 통해 셀렉트 어드민은 운영툴을 “한 번 쓰고 버리는 화면”이 아니라, 코드/구성으로 관리되는 운영 레이어로 만듭니다.

3. 한 명의 엔지니어로도 운영 레이어 전체를 구성할 수 있게

초기 팀에서 “엔지니어가 한 명뿐인 상황”은 흔합니다. 이 한 명이 제품 개발과 운영을 동시에 책임져야 하는 상황에서, 셀렉트 어드민이 가져다주는 장점은 다음과 같습니다.

3-1. 화면을 새로 짓지 않고, 스펙을 채웁니다

프론트엔드 프레임워크로 어드민 레이아웃, 사이드바, 페이지 라우팅, 테이블, 검색, 모달 등을 매번 다시 만들 필요가 없습니다.

페이지를 하나 정의하고
연결할 API(리스트, 상세, 수정, 액션)를 지정하고
UI에 필요한 필드 구성을 YAML에 선언하면

화면은 도구가 제공하는 규칙에 따라 그려집니다. 화면을 “직접 구현하는 것”이 아니라, 정해진 틀 안에 필요한 요소를 채워 넣는 것에 가깝습니다.

3-2. 스펙이 코드로 남습니다

어떤 팀이 어떤 화면을 쓰는지, 어떤 필터와 액션을 사용하는지, 운영 플로우가 어디에서 시작해 어디로 이어지는지,

이 모든 것이 YAML 파일과 리포지토리 구조로 남습니다. 이렇게 되면 나중에 팀원이 늘어났을 때 “이 화면이 어떻게 만들어졌는지”를 코드 기준으로 전달할 수 있고, 과거 변경 이력도 추적할 수 있습니다.

4. 제품 개발과 운영 속도를 동시에 유지하기 위한 현실적인 타협

셀렉트 어드민은 “모든 UI를 자유롭게 만들 수 있는 도구”가 아닙니다. 대신, 반복되는 운영 패턴만 정해진 규칙 안에서 빠르게 구성할 수 있도록 집중한 도구입니다.

이 말은 곧, 다음과 같은 경우에는 잘 맞지 않을 수 있다는 뜻입니다.

마케팅 랜딩페이지처럼 디자인 자유도가 중요한 화면
매우 특수한 인터랙션이 필요한 데이터 시각화
사용자 경험 디자인이 핵심 경쟁력이 되는 외부 노출 화면

반대로 다음과 같은 특징을 가진 화면에는 잘 맞습니다.

리스트 + 필터 + 정렬 + 상세 + 상태 변경 같은 패턴
운영팀이 매일 들어와서 “조회하고 조작하는” 내부 화면
역할/권한에 따라 접근 범위가 달라지는 내부 페이지

기술 창업자 입장에서 보면, “직접 UI를 세밀하게 다루는 대신, 운영툴 영역은 정해진 패턴 안에서 빠르게 구성하고, 비즈니스 핵심이 되는 제품 쪽에 더 많은 에너지를 쓰겠다”라는 선택에 가깝습니다.

5. 셀렉트 어드민이 실제로 제공하는 것

기술적인 관점에서, 셀렉트 어드민이 현재 제공하는 기능들을 보다 구체적으로 정리하면 다음과 같습니다.

5-1. 페이지 단위 구성

메인 메뉴, 하위 메뉴, 페이지를 YAML로 정의
각 페이지에 테이블·필터·상세·폼·액션 등을 선언적으로 배치
페이지별로 사용할 API endpoint 지정(fetchFn/http 방식)

5-2. REST API 기반 데이터 연동

GET/POST/PATCH/DELETE 엔드포인트를 각 동작에 연결
API 응답(JSON)에서 어느 필드를 컬럼·폼 필드·태그 등에 쓸지 지정
응답 구조를 바꾸지 않고도 YAML 수정으로 표현 방식 변경 가능

5-3. 기본 UI 패턴 제공

테이블(컬럼 정의, 정렬, 기본 검색/필터)
행 클릭 시 상세 보기(모달 또는 별도 영역)
폼 기반 생성/수정
단일/다중 선택 후 액션(예: 일괄 승인)

UI는 “자동으로 알아서 만들어주는 것”이 아니라, 명시된 구성에 따라 정해진 패턴으로 렌더링됩니다.

5-4. ENV 및 권한 관리

Dev / Prod 등 환경별로 다른 API endpoint·설정을 지정
역할/사용자 그룹에 따라 메뉴·페이지 접근을 제한
민감한 액션은 특정 역할에게만 허용하는 식의 구성이 가능

5-5. 구성 변경과 동작의 추적(제공 범위 내)

페이지 스펙(YAML)의 변경 이력은 코드 레포 수준에서 관리
어떤 페이지에서 어떤 액션이 호출되는지, 문제 상황에서 “어디에서 무슨 요청이 나갔는지”를 좁혀갈 수 있는 최소한의 단서 제공 (이 부분은 실제 구현된 범위에 맞게 구체화/조정 가능)

6. 셀렉트를 도입하면 좋은 팀과 그렇지 않은 팀

셀렉트 어드민 도입이 잘 맞는 팀

엔지니어 인원이 제한적인 초기/성장 단계 스타트업
운영툴이 필요하다는 건 알지만, 별도 어드민 프론트를 계속 만들기는 부담스러운 팀
운영팀·파트너팀·CS팀이 내부 화면을 매일 쓰고, 리스트/필터/상세/액션 패턴이 반복되는 비즈니스를 가진 팀
운영 화면을 *“코드와 설정으로 관리되는 자산”*으로 보고 싶은 기술 창업자

셀렉트 어드민보다 직접 만드는 편이 나을 수 있는 팀

자체적인 디자인 시스템과 프론트엔드 조직을 갖추고 있으며, 운영툴 UI까지 세밀하게 통제하고 싶은 팀
운영툴 인터랙션 자체가 제품 경험의 핵심인 경우
매우 자유로운 레이아웃·컴포넌트 구성이 필수인 경우

마무리: 기술 창업자가 가져갈 수 있는 것

셀렉트 어드민은 “운영툴을 마법처럼 만들어주는 도구”가 아닙니다. 대신, 운영툴을 만드는 방식을 예측 가능한 구조로 제한하고, 그 안에서 빠르게 반복할 수 있게 해주는 도구입니다.

기술 창업자의 관점에서 보면, 이 도구는 다음과 같은 선택을 가능하게 합니다.

운영 레이어는 셀렉트의 고정된 패턴 위에서 구성하고
제품의 고객-facing 부분, 경쟁력을 좌우하는 UX/기능에 더 많은 개발 리소스를 투입하는 선택

운영툴을 “당장 급해서 대충 만든 화면”에서 “코드로 정의된 운영 레이어”로 전환하고 싶다면, 셀렉트 어드민은 그 출발점이 될 수 있습니다.