어드민은 거의 언제나 마지막입니다. 고객이 보는 화면이 아니니까요. 그런데 저희가 SaaS 제품을 인수받아 보면 가장 심각하게 망가져 있는 곳이 대부분 어드민입니다.
증상은 늘 비슷합니다. 운영팀이 DB를 직접 열어서 값을 고칩니다. 개발자에게 슬랙으로 부탁합니다. 엑셀로 받아서 수기로 대조합니다. 이 비용은 매달 나가는데 아무도 계산하지 않습니다.
30초 요약
- •어드민 부실의 비용은 매달 나가는 운영 인건비로 나타납니다. 눈에 안 보일 뿐입니다.
- •"개발자에게 부탁하는 일"의 목록이 그대로 어드민 요구사항입니다.
- •조회보다 '수정과 그 흔적'이 중요합니다. 누가 언제 무엇을 바꿨는지 남아야 합니다.
- •실수 복구 경로가 없으면 운영자는 아무것도 못 누릅니다. 결국 다시 개발자를 부릅니다.
- •고객 화면만큼 예쁠 필요는 없지만 일관성은 똑같이 필요합니다.
1. 미룬 대가는 이렇게 나타납니다
개발자가 운영 업무를 합니다
"이 고객 플랜 좀 바꿔주세요", "결제 상태 수동으로 완료 처리해 주세요". 하루에 몇 건씩 쌓이면 개발자 한 명의 시간이 통째로 사라집니다. 그리고 이 일은 기록이 안 남아서 나중에 추적도 안 됩니다.
사고가 조용히 일어납니다
DB를 직접 고치면 실수가 나도 아무도 모릅니다. 잘못된 값이 몇 주 뒤 정산 단계에서 발견되는 일이 실제로 자주 벌어집니다. 그때는 이미 원인을 찾기 어렵습니다.
사람이 늘어도 속도가 안 붙습니다
신규 운영 담당자가 들어와도 할 수 있는 일이 없습니다. 도구가 없으니 선임에게 물어야 하고, 결국 인원을 늘려도 처리량이 그만큼 안 늘어납니다.
2. 요구사항은 이미 있습니다
어드민 기획을 백지에서 시작하실 필요가 없습니다. 지난 한 달 동안 개발자에게 요청된 운영 업무를 모으면 그게 곧 요구사항입니다.
슬랙에서 "~좀 해주세요"를 검색해 보세요. 대부분 거기에 다 있습니다.
모은 목록을 빈도와 위험도로 나누면 우선순위가 바로 나옵니다.
- •자주 + 위험 낮음 — 가장 먼저. 회수 효과가 즉시 나타납니다
- •자주 + 위험 높음 — 다음. 승인 절차나 이력 기록을 함께 설계합니다
- •드물 + 위험 높음 — 굳이 화면으로 만들지 않아도 됩니다. 절차를 문서로 두는 편이 낫습니다
3. 어드민 설계의 네 가지 원칙
① 수정에는 반드시 흔적을 남긴다
누가, 언제, 무엇을, 어떤 값에서 어떤 값으로 바꿨는지. 이력이 없는 어드민은 DB 직접 수정과 위험도가 같습니다. 오히려 더 나쁠 수도 있습니다 — 아무나 누를 수 있으니까요.
② 되돌릴 수 있게 만든다
운영자가 버튼을 못 누르는 가장 큰 이유는 "잘못 누르면 어떡하지"입니다. 삭제 대신 비활성화, 즉시 반영 대신 예약, 그리고 취소 경로. 이 셋만 있어도 운영자가 훨씬 과감해집니다.
③ 검색과 필터가 본체다
어드민에서 가장 많이 하는 일은 대상을 찾는 것입니다. 고객 하나 찾는 데 30초가 걸리면 하루에 수십 분이 사라집니다. 목록 화면의 검색·필터·정렬은 부가 기능이 아니라 핵심입니다.
④ 권한을 세분화한다
전부 볼 수 있는 슈퍼 계정 하나만 두면 결국 모두가 그걸 공유해서 씁니다. 그러면 이력이 있어도 의미가 없습니다. 역할별 계정과 권한은 IA 단계에서 함께 설계해야 합니다 — IA 재설계 실무에서 다뤘습니다.
4. 어디까지 만들어야 하나
완벽한 어드민을 처음부터 만들 필요는 없습니다. 오히려 쓰지 않을 화면을 잔뜩 만드는 게 더 흔한 실패입니다. 저희가 권하는 범위는 이렇습니다.
- •1단계 — 조회와 검색. 개발자에게 "이거 지금 어떻게 돼 있어요?" 묻는 일이 사라집니다
- •2단계 — 자주 하는 수정 3~5개 + 이력. 여기서 대부분의 시간이 회수됩니다
- •3단계 — 일괄 처리와 예약. 규모가 커진 뒤에 필요해집니다
1단계만 해도 체감이 큽니다. 조회만 열어줘도 개발자 문의의 절반 이상이 줄어드는 경우를 여러 번 봤습니다.
5. 디자인은 어느 정도로
고객 화면만큼 다듬을 필요는 없습니다. 다만 일관성은 똑같이 필요합니다. 같은 동작이 화면마다 다른 자리에 있으면 매일 쓰는 사람에게는 그 비용이 더 큽니다.
그리고 어드민은 정보 밀도를 높이는 쪽이 맞습니다. 여백을 넉넉히 두면 한 화면에 담기는 행이 줄어 스크롤이 늘어납니다. 하루 종일 보는 사람에게는 그게 피로입니다.
자주 묻는 질문
기존 어드민 템플릿을 사서 쓰면 안 되나요?
초기에는 유효합니다. 다만 템플릿은 일반적인 CRUD를 전제하고 있어서, 우리 제품 고유의 운영 흐름(승인, 정산, 예외 처리)이 들어가는 순간 맞지 않게 됩니다. 그 시점이 오면 갈아타실 생각을 미리 해두시는 게 좋습니다.
운영 인원이 두세 명뿐인데도 필요한가요?
오히려 더 필요합니다. 인원이 적을수록 한 사람이 멈추면 전체가 멈춥니다. 어드민은 그 사람 머릿속에 있는 절차를 도구로 옮기는 일이기도 합니다.
어드민 개발은 얼마나 걸리나요?
1단계(조회·검색)는 짧게 끝납니다. 2단계부터는 이력과 권한이 붙어서 기간이 늘어납니다. 다만 회수되는 운영 시간을 계산해 보면 대부분 몇 달 안에 상쇄됩니다. 개발자 문의 건수를 한 달만 세어보시면 근거가 나옵니다.
정리하면
어드민은 고객이 안 보는 화면이지만, 매달 돈이 새는 곳입니다.
슬랙에서 "~좀 해주세요"를 검색해 목록을 만들고, 자주 하면서 위험이 낮은 것부터 여세요. 이력과 되돌리기를 함께 넣고, 검색을 제대로 만드세요. 조회 하나만 열어도 체감이 옵니다.
함께 읽으면 좋은 글
제품 구조부터 점검이 필요하시면 상담 신청을 남겨주세요. 범위와 예상 기간을 먼저 정리해 드립니다. 진행 방식과 포함 범위는 요금제 페이지에서 확인하실 수 있습니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, 제품 단계와 조직 구성에 따라 다를 수 있어 결과를 보장하지 않습니다. 우리 제품에 맞는 개선 방향이 궁금하시다면 편하게 상담 신청해주세요.
