관리자 페이지는 출시 후에 만들면 늦습니다. 운영팀이 직접 다루지 못하는 제품은 매주 개발자가 데이터베이스를 손으로 만지는 비용으로 굴러갑니다. 그 비용은 첫 달엔 안 보이고, 6개월쯤 지나서야 누적치로 드러납니다.
“관리자 페이지는 나중에 만들죠”라는 말은 거의 모든 프로젝트에서 한 번쯤 등장합니다. 이유도 늘 같습니다. 사용자가 보는 화면이 더 급하고, 어차피 운영자는 두세 명이고, 처음엔 개발자가 옆에서 도와주면 된다는 것입니다. 단기적으로는 맞는 말입니다.
문제는 ‘옆에서 도와주는’ 단계가 끝나지 않는다는 데 있습니다. 출시 직후엔 사용자 데이터 정리 한두 건이지만, 사용자가 늘어나면 쿠폰 발급, 환불 처리, 권한 변경, 잘못 들어간 입력 수정, 통계 추출 같은 요청이 매주 몇 건씩 쌓입니다. 그리고 그 요청은 전부 개발자에게 향합니다.
| 운영팀 | 슬랙으로 “이거 처리해 주세요”를 보내고 결과를 기다린다 |
|---|---|
| 개발자 | 본인 일을 멈추고 데이터베이스에 직접 쿼리를 돌려 처리한다 |
| 고객 | 응답이 늦거나 처리가 누락된다 |
| 회사 | 매주 ‘기능 개발이 아닌 일’에 개발 시간을 일정 비율 쓴다 |
이 구조는 한두 달은 굴러갑니다. 그러나 사용자가 1.5배만 늘어도 운영 요청도 거의 그만큼 늘고, 개발자의 본업 시간이 가장 먼저 깎입니다. 결국 “기능을 못 만드는 게 아니라 운영을 못 줄인다”는 상태에 갇힙니다.
관리자 페이지를 미룰 수 있다고 느끼는 이유 중 하나는 그것을 ‘조회 화면 몇 개’로만 보기 때문입니다. 실제로는 다릅니다. 관리자 페이지는 누가 어떤 데이터를 어떤 권한으로 어떤 흐름으로 다룰지를 정의하는 작업입니다. 그래서 화면을 못 만든 게 아니라 권한·로그·검증 흐름이 없는 상태가 됩니다.
이걸 출시 후에 끼워 넣으면 거의 항상 같은 문제가 생깁니다. 데이터 모델은 이미 사용자 화면 기준으로만 설계되어 있어, 운영자가 봐야 할 ‘처리 상태’, ‘이전 값’, ‘담당자’, ‘처리 사유’가 들어갈 자리가 없습니다. 결국 컬럼 추가, 인덱스 변경, 마이그레이션이 줄줄이 필요합니다.
이 다섯 가지는 ‘관리자 페이지를 잘 만든 결과’가 아니라 ‘관리자 페이지를 같은 시점에 같이 설계한 결과’입니다. 화면이 화려할 필요는 없습니다. 단순한 표 몇 개라도, 운영팀이 직접 닫을 수 있는 흐름이 잡혀 있다는 것 자체가 가장 큰 차이를 만듭니다.
관리자 페이지가 ‘운영팀이 직접 닫을 수 있는 도구’가 되려면 몇 가지 조건이 필요합니다.
이 조건들이 맞으면 관리자 페이지가 단순 조회 도구가 아니라, 회사의 운영 절차를 그대로 담는 시스템이 됩니다. 운영팀이 바뀌어도, 인수인계가 화면 한 번 보여주는 것으로 끝납니다.
SL:IT은 ‘인수 가능성’을 별도 기준으로 봅니다. 출시 시점에 “이 제품을 운영팀이 직접 인수해서 운영할 수 있는가”라는 질문을 던집니다. 답이 “아직 개발자가 옆에 있어야 한다”라면, 그 제품은 출시는 됐어도 운영은 시작되지 않은 상태입니다.
인수 가능성을 갖추려면 관리자 화면뿐 아니라 운영 문서, 오류 알림 흐름, 자동화 작업의 실패 복구 절차가 같이 갖춰져 있어야 합니다. SL:IT 프로젝트는 이 네 가지를 첫 단계 산출물에 같이 포함합니다.
SL:IT은 ‘사용자 화면 먼저, 관리자 페이지는 나중에’라는 분리를 권하지 않습니다. 첫 사용자 흐름과 그에 대응되는 운영 흐름을 같이 설계하고, 같이 출시합니다. 화면 수가 늘어나서 일정이 길어지는 게 아니라, 데이터 모델과 권한이 처음부터 운영을 고려해서 잡히기 때문에 오히려 6개월 뒤의 비용이 작습니다.
관리자 페이지는 부가 기능이 아닙니다. 제품을 ‘운영하는 팀’이 직접 굴릴 수 있게 만드는 도구이고, 그 도구가 없으면 모든 운영 비용은 결국 개발자에게 청구됩니다.
