운영자와 고객 관리자의 층을 가른 AIDRA 백오피스

문제 정의

팔 준비를 하려고 보니, 운영자의 도구가 고객의 화면 안에 섞여 있었다

9월 말 AIDRA는 팀 워크스페이스와 크레딧 결제를 붙여 외부 팀에 팔 수 있는 제품으로 바뀌는 중이었다. 팔기 시작하면 테넌트와 결제를 다루고 제품 전체를 내려다볼 운영 수단이 있어야 한다. 그런데 운영 기능은 제품 안의 관리자 탭 하나에 모여 있었고, 그 탭은 내부 팀 하나만 있던 시절에 만들어진 것이었다. 착수하자마자 관리자 탭 11개와 지표 데이터, 업계 운영 콘솔 사례를 세 갈래로 나눠 조사했다.

문제는 양쪽에서 나왔다. 운영 스위치, 사용 한도, 계정 영구 삭제, 전역 지식처럼 플랫폼 전체를 바꾸는 기능이 운영자가 아니라 '첫 워크스페이스의 관리자' 권한 뒤에 있었다. 관리자 탭 11개 중 7개가 노출 규칙 없이 다른 팀의 관리자에게도 보이는 상태로는 외부 팀을 한 곳도 받을 수 없었다. 반대로 비용, 감사, 로그는 전부 지금 워크스페이스 범위라 운영자인 나는 제품 전체를 볼 방법이 없었다. 지표를 만들 재료도 부족했다. 로그는 90일이면 사라졌고 원가는 달러 추정치뿐이었다. 결제는 운영 환경에서도 전부 모의 청구였고, 사용자가 어디서 왔는지는 기록조차 없었다.

제약은 일정이었다. 외부 개방이 코앞이라 빠르게, 그러면서도 운영자가 매일 들여다볼 수 있을 만큼의 품질로 만들어야 했다. 결제와 멀티테넌트 작업이 다른 세션에서 동시에 돌고 있어 같은 파일을 함부로 건드릴 수도 없었다. 실제로 운영을 도는 사람도 두 명뿐이라, 무거운 절차를 얹으면 그 절차가 운영을 멈추게 할 수 있었다.

가설 수립

운영 콘솔은 새로 발명할 물건이 아니라고 보고, 검증된 템플릿을 통째로 들였다

화면 문법은 Stripe 같은 결제·운영 콘솔의 관례에서 가져왔다. 표가 중심이고 색은 상태에만 쓴다. 계정 하나를 열면 그 계정의 모든 것이 한 화면에 모이고, 위험한 조작에는 사유를 받는다. 처음에는 shadcn/ui의 겉모습만 제품과 같은 바닐라 JS로 옮기기로 했다. 하지만 그 결정으로 나온 결과물을 직접 보고 같은 날 오후에 방향을 뒤집었다.

검증된 컴포넌트의 모양을 손으로 재현하는 것은 이미 있는 물건을 한 벌 더 만드는 일이었고, 일정 안에서 품질을 끌어올리기도 어려웠다. 백오피스는 제품 번들과 분리된 별도 진입점이라 제품의 무번들 제약을 따를 이유도 없었다. 그래서 MIT 라이선스의 shadcn-admin 템플릿을 React, Vite, TanStack Router 그대로 받아 그 위에 새로 지었다. 기대한 것은 테넌트, 결제, 지표, 공지, 지원을 한 곳에서 운영할 수 있게 되어 팔 준비가 끝나는 것이었다.

솔루션 도출

누가 무엇을 만지는지부터 정해, 운영자 층과 워크스페이스 관리자 층을 갈랐다

핵심은 화면이 아니라 층이었다. 운영자는 백오피스에서 플랫폼 전체를 다루고, 제품 안의 관리자 탭은 외부 팀의 관리자가 자기 팀만 다루는 곳으로 정의를 바꿨다. 기능 하나를 어느 층에 둘지는 두 질문으로 갈랐다. 이 조작의 영향이 자기 팀 밖으로 나가는가, 그리고 이 정보를 고객이 봐도 되는가. 기능 켜기와 끄기, 다른 워크스페이스 관리는 첫 질문에 걸려 운영자에게 갔고, 벤더 원가와 행동 로그는 두 번째 질문에 걸려 운영자에게 갔다. 고객 관리자는 원가 대신 자기 팀의 크레딧 사용량을 본다.

정의를 바꾼 뒤의 제품 안 관리자 탭. 남은 것은 멤버와 결제 두 칸뿐이고, 고객 관리자는 자기 팀의 가입 신청과 멤버만 다룬다

관리자 탭은 11개에서 멤버와 결제 2개로 줄었고, 플랫폼 전역 라우트는 전부 운영자 가드 뒤로 옮겼다. 처음 정리 때는 감사 로그를 관리자 탭에 남겼는데, 다시 보니 그것까지 고객 화면에 둘 이유가 없어 백오피스로 올렸다. 덕분에 운영자의 조작을 고객 화면에서 가려 주려던 장치도 필요 없어졌다. 명단에는 여러 명이 올라 있어도 실제로 운영을 도는 사람은 두 명이라, 4인 승인과 대리 로그인은 만들지 않았다. 한 명이 자리를 비우면 운영이 멈추기 때문이다. 대신 위험한 변경에는 사유를 필수로 받고, 계정 영구 삭제나 환불처럼 되돌릴 수 없는 작업은 10분 안에 다시 로그인해야 실행되게 했다.

백오피스에서 워크스페이스 하나를 연 화면. 사용량·원가·결제·켜진 기능이 한 화면에 모이고, 정지와 영구 삭제는 맨 아래 위험 구역으로 떼어 냈다

시스템 화면의 런타임 스위치. 전 워크스페이스에 즉시 적용되는 기능 켜기·끄기라 첫 질문에 걸려 운영자 층으로 올라왔고, 바꾸려면 사유를 남겨야 한다

없는 데이터는 없는 대로 보여 주기로 했다. 로그가 사라지기 전에 매일 롤업해 추세를 남기고, 모의 결제는 빼면 매출 화면이 전부 0이 되므로 포함하되 배지를 달아 실매출과 섞여 보이지 않게 했다. 나는 결정을 내리고 구현은 여러 레인의 에이전트에 병렬로 나눠 맡겼다. 레인끼리 서로 모르고 같은 지표 API를 두 번 만든 것은 통합 단계에서 하나로 합쳤다.

결과 & 배운 점

나흘 만에 운영 콘솔이 섰고, 처음으로 제품 전체의 숫자를 봤다

9월 26일 착수해 9월 30일 지표 롤업까지, 테넌트·사용자·매출·원가·지표 네 렌즈·공지·시스템 상태를 다루는 백오피스를 운영에 올렸다. 운영자 명단은 첫날 네 명에서 여섯 명으로 늘었다. 무엇보다 백오피스를 열고 처음으로 제품 전체의 숫자를 봤다. 고착도는 약 20%로, 일간 활성 2명에 월간 활성 약 12명이었다. 그 숫자를 운영 실데이터로 열어 보며 결함도 잡았다. 화면이 서버의 비율 값을 퍼센트로 읽어 20%를 0.2%로 찍고 있었고, 목 데이터가 같은 오류를 가려 테스트까지 그 버그를 굳히고 있었다. 내부 사용이 전부 결제 면제라 '7일 원가'가 $0.00으로 보이던 것도, 30일 실원가 $228.71과 맞지 않아 내부 사용을 포함한 전체 원가로 바꿨다.

백오피스 개요(10월 7일 기준). 사업·제품·마케팅·운영 네 렌즈를 한 줄에 올리고, 모의 결제가 섞여 있다는 배지를 제목 옆에 단다. 이 시점 고착도는 50%이고, $0.00으로 보이던 7일 원가 타일은 내부 사용을 포함한 전체 원가로 바뀌어 있다

원가 화면(10월 7일 기준 30일). 원가를 벤더·모델·단계별로 쪼개고 내부 사용 원가를 따로 세운다. 9월 30일 대조 때의 $228.71보다 한 주 치가 더 쌓인 값이다.

실결제 연동은 아직이고, 매출 화면은 지금도 모의 배지를 달고 있다. 그래도 팔기 위해 필요한 층과 운영 도구는 다 섰다고 판단한다. 이 프로젝트에서 나는 원래 갖고 있던 습관 하나가 왜 중요한지 다시 확인했다. 빠르게 품질을 내야 할 때는 이미 검증된 오픈소스와 라이브러리를 적극적으로 들여오는 것이다. 오전의 결정을 오후에 버린 덕에, 남은 시간은 누가 무엇을 만지는지 정하는 데 고스란히 썼다.