Technical Lead and Founder

운영툴을 새로 짓지 않고, API와 YAML로

초기 팀의 운영 레이어를 빠르게 구성하세요.

기술 리드, 창업자를 위한 운영 레이어

초기 팀에서 기술 리드와 창업자는 거의 모든 기술 결정을 직접 책임지는 경우가 많습니다. 제품 기획과 개발, 인프라와 배포, 장애 대응, 파트너 기술 지원, 심지어 데이터 파이프라인까지 한 사람의 머리 안에서 굴러갑니다.

MVP를 출시하고 고객과 파트너가 붙기 시작하면, 제품 화면 이외에 “운영을 위한 별도 화면”이 필요해지는 시점이 찾아옵니다.

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

이 화면들이 없으면 운영의 품질과 속도가 떨어지고, 있자니 새로운 프론트엔드 프로젝트를 계속 만들어야 하는 부담이 뒤따릅니다.

셀렉트 어드민은 이 순간을 전제로 설계되었습니다. “운영툴을 얼마나 잘 만들까?”가 아니라, 운영툴을 “관리 가능한 구조” 안으로 넣고, 창업자가 다시 제품에 집중할 수 있게 만드는 것이 목표입니다.


운영툴이 항상 “조금 뒤로” 밀리는 이유

스타트업의 우선순위는 직관적입니다. 처음에는 일단 제품부터입니다.

그러나 시장에서 반응이 조금이라도 나오기 시작하면, 운영과 파트너, CS, 재무까지 제품 바깥의 일들이 빠르게 늘어납니다.

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

이때 기술 창업자의 선택지는 보통 두 가지입니다.

  1. 임시 도구로 버티기

    • Notion, 스프레드시트, 쿼리 툴, 임시 API를 섞어서 사용
    • 사람마다 보는 화면이 달라지고, 누가 기준인지 모호해지며, 데이터 신뢰도와 처리 속도가 함께 떨어집니다.
  2. 운영툴을 “제대로” 한 번 만들기

    • 별도 어드민 프론트엔드(React/Next 등)를 만들고
    • 라우팅, 인증, 테이블, 필터, 상세, 액션, 권한, 배포까지 한 번에 구현

1번은 운영 품질·속도 문제, 2번은 시간·런웨이 문제를 끌어안습니다. 그래서 “운영툴이 필요하다는 것은 알지만, 지금 손댈 수 없다”는 상태가 길어지는 경우가 많습니다.


셀렉트 어드민이 제안하는 ‘운영 레이어’ 관점

셀렉트 어드민은 내부툴을 예쁘게 그려주는 프레임워크가 아니라, 회사 안에 하나의 “운영 레이어(Operations Layer)”를 세우는 도구라는 관점을 택합니다.

이 운영 레이어는 다음과 같은 특징을 가집니다.

  • 운영툴 UI는 정해진 패턴을 따릅니다. 테이블, 필터, 정렬, 상세, 폼, 액션 버튼 등은 셀렉트 어드민이 제공하는 규칙 안에서 구성됩니다. 팀·페이지마다 UI 철학을 다시 발명하지 않습니다.

  • 각 화면은 YAML 스펙으로 정의됩니다. “어떤 데이터를 어떤 컬럼으로 보여줄지”, “어떤 필터·정렬을 제공할지”, “어떤 버튼이 어떤 API를 호출할지”를 사람이 읽을 수 있는 스펙으로 선언합니다.

  • 데이터는 이미 존재하는 API로부터 가져옵니다. 현재 백엔드에서 사용 중인 엔드포인트를 그대로 연결하거나, 최소한의 운영용 API를 추가해도 충분합니다.

결과적으로 셀렉트 어드민은 운영 화면을 “그때그때 급하게 만든 페이지”에서 “코드와 스펙으로 관리되는 운영 레이어”로 전환하는 기반을 제공합니다.


한 명의 기술 창업자로도 운영 레이어를 구성할 수 있도록

초기 팀에서 기술 창업자는 사실상 유일한 플랫폼입니다. 이 상황에서 셀렉트 어드민이 주는 가치는 “개발 리소스를 절약한다”보다 조금 더 구체적입니다.

UI를 새로 짓지 않고, 스펙을 채웁니다

프론트엔드 프레임워크를 열어:

  • 어드민 레이아웃을 만들고
  • 사이드바와 라우팅을 구성하고
  • 테이블과 필터·검색·모달을 다시 구현하는 일은 시간과 에너지를 크게 소모합니다.

셀렉트 어드민에서는,

  • 페이지를 하나 정의하고
  • 연결할 API(리스트, 상세, 수정, 액션)를 지정하고
  • UI에서 사용할 필드를 YAML로 선언하면

화면은 도구가 제공하는 정해진 패턴 안에서 자동으로 렌더링됩니다. 화면을 “새로 만든다”기보다는, 필요한 운영 흐름을 “스펙으로 설명한다”에 가깝습니다.

스펙은 그대로 팀의 자산으로 남습니다

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

이 모든 것은 YAML 파일 구조로 남습니다. 기술 창업자가 혼자 만들었던 운영 레이어는, 이후 합류하는 엔지니어와 운영 담당자에게 그대로 전달 가능한 “시스템”이 됩니다.


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

셀렉트 어드민은 모든 UI를 마음대로 만들 수 있는 도구는 아닙니다. 대신, 내부 운영에서 반복되는 패턴을 정해진 규칙 안에서 빠르게 구성하는 도구입니다.

그래서 다음과 같은 화면에는 적합하지 않을 수 있습니다.

  • 마케팅 관점의 디자인 자유도가 중요한 화면
  • 매우 특수한 인터랙션이 필요한 시각화 화면
  • 사용자 경험 디자인이 핵심 경쟁력인 외부 노출 화면

반대로, 이런 화면에는 잘 맞습니다.

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

기술 창업자 입장에서 보면, “운영 레이어는 셀렉트 어드민 패턴 위에서 정리하고, 고객-facing 제품 경험에 더 많은 리소스를 쓴다”는 선택지입니다.


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

기술적인 관점에서, 셀렉트 어드민이 제공하는 기능을 요약하면 다음과 같습니다.

  • 페이지 단위 구성

    • 메뉴/페이지를 YAML로 정의하고, 각 페이지에 테이블·상세·폼·액션을 배치
    • 각 페이지마다 사용할 API endpoint 지정
  • API 연동

    • GET/POST/PATCH/DELETE 엔드포인트를 리스트·상세·수정·액션에 연결
    • 응답 필드를 컬럼·폼·태그 등에 매핑
  • 기본 UI 패턴 제공

    • 테이블, 상세 모달, 폼, 단일/다중 선택 액션 등 운영툴에서 반복되는 패턴 제공

이 기능들은 “운영툴을 완전히 자동으로 만들어준다”기보다는, 운영툴을 만드는 비용과 리스크를 일정한 범위 안으로 묶어주는 장치에 가깝습니다.


셀렉트를 도입하면 좋은 기술 창업자의 상황

다음과 같은 상황이라면 셀렉트 어드민 도입을 고려할 만합니다.

  • 엔지니어가 매우 제한적인 초기/성장 단계 스타트업
  • 운영툴이 필요하다는 것은 분명하지만, 어드민 프론트를 계속 새로 만들 여유는 없는 팀
  • 운영팀·파트너팀·CS팀이 내부 화면을 매일 사용하고, 리스트/필터/상세/액션 같은 패턴이 반복되는 비즈니스
  • “운영툴을 관리 가능한 구조로 정리하고 싶다”는 생각이 들기 시작한 기술 창업자

반대로, 이런 팀은 직접 만드는 편이 더 나을 수 있습니다.

  • 프론트엔드 팀과 디자인 시스템이 잘 갖춰져 있고, 운영툴 UI까지 세밀하게 설계하고 싶은 팀
  • 내부툴의 인터랙션 자체가 제품 경쟁력과 직결되는 경우

운영 레이어는 정리하고, 제품에 다시 집중할 수 있도록

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

기술 창업자의 관점에서는 이것이 하나의 전략적 선택이 됩니다.

  • 운영 레이어는 셀렉트 어드민 위에서 구조화하고
  • 고객과 시장을 향한 제품 경험에 더 많은 시간을 투자할 것인지

운영툴을 “당장 급해서 만든 임시 화면”에서 “코드와 스펙으로 관리되는 운영 레이어”로 바꾸고 싶다면, 셀렉트 어드민이 그 전환의 출발점이 될 수 있습니다.


더 알아보기

API로 운영 레이어 바로 시작하기

운영툴을 짓지 않고, 제품 개발에 다시 집중할 수 있습니다.