어드민 개발 스택을 결정하기 전에
어드민은 “나중에 한 번 정리하자”로 시작해서, 어느 순간 팀의 발목을 잡습니다.
"React로 새로 만들까, Rails/Django Admin으로 버틸까, Retool 같은 도구를 쓸까, 내부 프레임워크를 만들까.."
스택 보다 먼저 정리해야 할 질문이 있습니다. 이 질문에 답을 먼저 구하고 방향을 정해보세요.
공통 체크리스트
어떤 스택을 쓰더라도, 이 네 가지는 피해 갈 수 없습니다.
1) 누가 이 어드민을 만들고, 누가 유지할 것인가
- 프론트엔드 개발자가 꾸준히 지원 가능한가
- 어드민 담당이 따로 생길 가능성이 있는가
- 백엔드 개발자가 UI까지 가져가야 하는 상황인가
여기서 사실상 이런 선택지로 갈리며
- 프론트 리소스 O → React, Vue / 내부 프레임워크 쪽으로 기울어짐
- 프론트 리소스 거의 없음 → Rails/Django Admin / 저코드 / 스펙 기반 쪽이 현실적
이 때 채용 계획이나 팀원 리소스에 대한 불확실성도 함께 고려해야합니다.
2) 무엇을 얼마나 자주 바꿀 것인가
- 상태값, 옵션, 데이터 정책이 자주 바뀌는가
- 업무 프로세스(승인 단계, 제한 조건)가 달라질 수 있는가
- UI나 비즈니스 상황이 바뀌는 경우가 많은가
정리하면:
- 규칙이 자주 바뀜 → 설정·스펙·구성(Declarative) 쪽이 유리
- 규칙이 거의 고정 → 무엇을 써도 잘 버틴다
3) 어떤 리스크를 다루는 도구인가
- 내부 운영자 몇 명만 사용하는 도구인가
- 파트너, 고객사 계정이 들어오는가
- 금전, 정산, 보안 이슈가 걸린 화면인가
여기서:
- 리스크 낮음 → Retool, Rails Admin, 간단한 React, Vue 페이지도 충분
- 리스크 높음 → 권한/로그/감사 도입이 쉽거나, 직접 구현할 수 있는 스택이 필요
4) 해당 어드민의 예상 수명
- 6개월-1년짜리 임시 도구인가
- 2-3년 이상 가져갈 코어 시스템인가
이렇게 나뉩니다:
- 수명 짧음 → 초기 속도가 중요, 저코드·Rails/Django 유리
- 수명 김 → 확장성과 구조 통제 가능한 스택 필요 (React, Vue, 내부 프레임워크, 잘 설계된 스펙 기반 등)
다만 도구의 수명이라는것이 예측 가능성이 낮은편이고, 의지나 선호의 문제에 따라 다를 수 있습니다.
위 네 가지를 문서로 한 번 적어두고, 그다음에 스택을 고민해봐야 합니다.
1. React, Vue 기반 Admin
장점은 명확합니다. 세밀한 UX, 복잡한 플로우, 실시간 상태 업데이트 같은 것들을 제한 없이 구현할 수 있습니다.
단점도 명확합니다. 프론트 리소스가 필요하고, 페이지가 늘어날수록 유지보수 범위가 끝없이 커집니다.
프레임워크 기반 어드민은 결국 “공통 패턴을 얼마나 빨리 추상화하느냐” 싸움이 됩니다.
처음 몇 페이지는 빠르게 만들 수 있습니다. 10페이지를 넘어가면, 패턴을 정리하지 않은 부분이 하나씩 드러납니다.
간단히 정리하면:
- 좋은 점
- 복잡한 UX 구현 가능
- 디자인 시스템 재사용
- 주의할 점
- 프론트 리소스가 계속 필요
- 패턴 정리 없이는 금방 난개발로 감
- “어드민 전용 UI 레이어”를 만들지 고민이 생김
React나 Vue로 간다면, 최소한 이것 하나는 잡고 가는 게 좋습니다:
“어드민용 테이블/필터/폼/레이아웃 컴포넌트를 초기에 한 번 정의한다.”
이걸 하지 않으면, 테이블이 페이지마다 다르게 구현되어 있을 수 있습니다.
관련 도구:
2. Rails / Django Admin
ORM 기반 Admin은 “모델 → 곧바로 화면”이라는 극단적인 빠른 길입니다.
서버 개발자 입장에서는 가장 부담이 없습니다.
모델을 제대로 설계해두면, 리스트/상세/생성/수정 화면이 자동으로 나옵니다.
초기에 데이터를 보고 수정만 할 수 있으면 되는 상황에서 좋은 도구입니다.
다만 모델이 늘어나고 비즈니스 규칙이 복잡해지면, UI가 모델 구조에 지나치게 붙어버립니다.
상태, 승인 플로우, 복잡한 필터를 붙이는 순간부터 “Admin이 편한가?”보다 “프레임워크를 우회하는 코드가 얼마나 늘어났는가?”가 더 중요한 문제가 됩니다.
정리하면:
- 좋은 점
- CRUD 생성 속도 최강
- 서버 개발자 1명으로도 시작 가능
- MVP 단계에서 부담 없이 쓰기 좋음
- 주의할 점
- 복잡한 프로세스를 표현하는 데 한계
- “Admin을 커스터마이즈하기 위한 코드”가 쌓이면 기술부채가 됨
- 2~3년짜리 코어 어드민으로 쓰기에는 보통 모자람
그래서 이 스택은 이렇게 정의하면 편합니다:
“단순 CRUD + 내부 운영자용 + 1년 안에 구조를 다시 볼 수도 있는 도구에 쓴다.”
이 범위를 넘는 순간에는, 다른 스택으로 옮길 타이밍을 봐야 합니다.
결정적으로 관련 개발언어를 사용하기 어려운 경우 알맞지 않습니다.
관련 도구:
3. Retool / Appsmith 같은 저코드(Low-code) 도구
로우코드 도구는 “화면을 많이 만들어야 하는 팀”에게는 유효한 선택입니다.
SQL이나 API만 있으면, 꽤 쓸 만한 내부 도구를 빠르게 여러 개 만들 수 있습니다.
초기 도입의 느낌은 이렇습니다.
- 운영팀 요청이 빠르게 처리된다
- 데이터팀이 스스로 필요한 화면을 만든다
- “이건 개발 안 붙여도 되겠다”는 안도감이 생긴다
문제는 도구 개수가 늘어날수록 상태 관리가 어려워진다는 점입니다.
어떤 쿼리가 어디에 연결되어 있는지, 누가 어떤 화면을 유지보수하는지, 권한은 어떻게 관리할지 같은 메타 문제가 하나씩 나옵니다.
핵심 업무에 너무 깊게 엮이기 시작하면, 나중에 코드로 옮기는 비용도 커질 수 있습니다.
요약하면:
- 좋은 점
- 화면 생산 속도 매우 빠름
- 비개발자도 일정 부분 참여 가능
- 수명이 짧은 도구가 많을 때 효율적
- 주의할 점
- 프로젝트가 쌓이면 거버넌스 이슈 발생
- 도구의 권한/보안 모델에 종속
- 핵심 비즈니스 플로우까지 맡기면, 나중에 옮기기 부담
그래서 이 스택은 이런 기준이 좋습니다:
“버려도 괜찮은 도구, 실험적 도구, 운영/데이터 팀의 자체 툴에는 적극 사용.
핵심 운영 플로우는 어느 시점부터 코드로 내려보낸다.”
“어디까지 로우코드로 할 것인가”를 미리 선을 그어두는 것이 중요합니다.
비개발자의 참여가 정말 중요한지, 의미있는 정도로 참여가 가능한지, 도구가 무겁지는 않은지 등도 함께 고려해야합니다.
관련 도구:
- https://retool.com/
- https://www.appsmith.com/
- https://www.superblocks.com/
- https://refine.dev/
- https://www.windmill.dev/
4. 자체 Internal Admin Framework
팀 규모가 어느 정도 커지면 “어드민이 너무 제각각이다”라는 말이 나옵니다.
이 시점에서 내부 프레임워크를 고려하게 됩니다.
내부 프레임워크는 레이아웃, 권한, 공통 컴포넌트, 로그 같은 것을 한 번 정의하고,
각 도메인은 그 위에서만 어드민을 만드는 구조를 말합니다.
장점은 새로운 도메인 팀이 어드민을 만들 때, “이미 정해진 방법”이 있으니, 팀마다 다른 패턴이 나오지 않습니다.
역할/권한/로그 같은 “귀찮지만 중요한” 기능을 매번 새로 만들지 않아도 됩니다.
대신 초기 투자 비용이 크고 유지보수 부담이 있습니다.
프레임워크를 설계하고 유지할 팀이 필요하고, 설계가 틀리면 전체 조직이 그 틀을 계속 떠안고 가야 합니다.
정리하면:
- 좋은 점
- 장기 유지보수 비용 감소
- 여러 도메인이 있어도 일관된 구조 유지
- 권한/로그 같은 인프라 레이어 재사용
- 주의할 점
- 초기 비용과 설계 난이도 높음
- 팀 규모가 작으면 오버킬
- “무엇까지 프레임워크에 넣고, 무엇은 각 팀이 하도록 둘지” 범위를 명확히 해야 함
이 선택은 보통 이런 상황에서 고려할 만 합니다:
개발팀 규모가 두 자릿수 이상이고,
어드민이 3개 이상이며,
앞으로도 계속 늘어날 때.
단 어드민 개발은 개발자에게 커리어 측면에서 양면적인 요소가 있기 때문에 성공 가능성, 유지 가능성, 철회 가능성에 대해 냉정하게 판단해야 합니다.
5. 스펙 기반 운영 툴 - 셀렉트 어드민
스펙 기반 어드민은 UI를 코드가 아니라 선언(Declarative)으로 정의하는 접근입니다.
페이지, 테이블, 필터, 액션 같은 것을 YAML로 적고, 실제 데이터 처리는 기존 API나 DB가 담당하는 구조입니다.
프론트 리소스가 부족한 팀에서는 꽤 현실적인 선택입니다.
백엔드 개발자가 스펙 파일을 수정하는 것만으로도 어느 정도 수준의 화면을 만들 수 있기 때문입니다.
강점은 “변경에 대한 흡수력”입니다.
상태값이 추가되거나, 필터 조건이 바뀌거나, 새로운 액션이 붙을 때마다
컴포넌트 코드를 직접 고치는 대신 스펙을 바꾸는 형태가 됩니다.
반대로, 이 추상화가 허용하는 범위를 벗어나는 순간에는 제약이 있습니다.
특정한 인터랙션, 아주 커스텀한 화면, product-level UX 같은 것들은 구현 범위 밖일 수 있습니다.
요약:
- 좋은 점
- 프론트 리소스 없이도 일관된 UI 구성 가능
- 비즈니스 규칙 변경을 스펙 수정으로 처리
- 주의할 점
- 스펙 작성 방식 학습 필요
- 특수한 UX는 구현 어려움
이 방식은 이런 상황에서 고려할 만 합니다:
백엔드 개발자가 어드민까지 책임지고,
주문/결제/구독 관리 처럼 트랜잭션 패턴이 많은 도메인이고,
규칙이 자주 바뀌는 팀.
관련 도구:
마무리
어드민 스택 선택은 “어떤 게 제일 좋아 보이는가”의 문제가 아닙니다.
팀이 감당할 수 있는 제약을 고르는 일에 가깝습니다.
- React, Vue는 제어권과 함께 코드베이스를 가져옵니다.
- Rails/Django Admin은 초기 속도와 함께 확장성의 한계를 가져옵니다.
- 로우코드 도구는 생산성과 함께 거버넌스와 종속성을 가져옵니다.
- 내부 프레임워크는 일관성과 함께 초기 비용을 가져옵니다.
- 스펙 기반 도구는 변경 대응력과 함께 추상화의 경계를 가져옵니다.
어떤 선택이든 틀렸다고 할 수는 없습니다.
다만, 선택 전에 최소한 이런 질문만은 해볼 수 있겠습니다.
- 우리는 누가 이걸 만들고, 누가 유지할 수 있는 팀인가
- 무엇이 얼마나 자주 바뀔 것인가
- 이 화면이 다루는 리스크는 어느 정도인가
- 이 도구를 몇 년 동안 쓸 생각인가
여기에 대한 생각을 적어두면, 적어도 “왜 이렇게 만들었는지”는 팀 안에서 명확하게 남고 계속해서 발전의 기반이 될 수 있습니다.
우리 팀의 스타일을 고민하고 테스트하고 발전시켜보세요.
내부 도구, 작게 시작해보세요. 셀렉트 어드민으로 필요한 화면부터 바로 만들어볼 수 있습니다.
