대부분의 IT 회사에는 다양한 서비스 데이터들이 존재합니다.

독창적인 서비스와 비즈니스 로직을 모든 구성원들이 공유하며
제품에 녹이고 운영과 고객지원, 영업지원에도 자연스럽게 스며듭니다.

초기에는 간단한 페이지와 데이터베이스 구조를 가지고 정돈된 로그와 내역이 쌓이며, 데이터베이스에 없더라도 엑셀을 통해 자유롭게 데이터를 축적하고 이용하게 됩니다.

문제는 서비스가 성장하고 새로운 기능이 생기고 정책이 변하면서, 데이터의 구조가 복잡해지고 문의 처리를 위해서 봐야할 데이터들이 늘어납니다. 기존 코드에 대한 이해와 설명이 필요하고, 유지보수 작업과 담당자의 변경, 인수인계를 거치며 점점 전체 시스템의 난이도가 높아지게 됩니다.

점진적인 개선을 통해 유지보수 비용과 복잡도를 낮추고자 노력을 하는 시점이 찾아옵니다. 동시에 레거시 부분은 모두 고치기엔 양이 너무 많다고 깨닫고 이미 고객을 만족시키고 있고 서비스 성장에 기여하고 있으므로 현상 유지를 선택할수도 있고, 또는 부족하고 아쉬운 부분부터 하나씩 고치는 방법도 있습니다.

시스템 통합, 버전 관리, 안정성, 레거시 전략등을 이야기하기에 내용이 너무나 많기에 오늘은 '어드민의 생애주기'를 이야기 해봅니다.

어드민 백오피스가 꼭 필요할까요

스타트업부터 규모가 있는 조직까지 각자 비슷하면서 다른 고민과 해결방법을 통해 지금당장의 많은 문제를 해결하고 있습니다.

• 서비스 컨텐츠 데이터를 조회하며 자사의 웹 또는 앱과 같은 플랫폼에 노출되는 부분을 수정합니다.
• 서비스 고객 데이터를 조회하고 정책에 따라 필요한 상태를 변경합니다.
• 서비스 통계 데이터를 조회하고 정렬하며 필요한 자료를 공유하거나 엑셀로 다운받습니다.
• 서비스 정책 데이터를 조회하고 권한을 가진 담당자가 개발팀의 도움없이 시스템의 키값 또는 활성/비활성 상태를 제어합니다.
• 서비스 맵핑 데이터를 담당자가 손으로 검수하고 관리하며 제휴사의 데이터를 조회하고 수정 합니다.
• 서비스 승인/검수/이슈/티켓팅 데이터를 자동처리가 아닌 담당자가 확인 후 실서비스에 반영 처리합니다.
• 서비스의 연락처/컨택 데이터(이메일, 전화번호, 친구톡, 알림톡 프로필)로 아직 개발/배포된 프로세스가 없어서 직접 해야하는 경우 알림과 안내 메시지를 발송합니다.
• 같은 서비스라도 개인정보 접근 정책이나 권한의 범위에 따라 담당자들이 보는 페이지를 분리하여 별도의 어드민을 제공합니다.
• 같은 서비스라도 제휴사/지역/국가별 분리하여 별도의 어드민을 제공합니다.
• 다른 서비스라도 통합된 중간 어드민을 만들거나 데이터 연동으로 어드민간 연결조회, 이슈이관의 어려움을 해결합니다.

하지만 어드민의 구성과 역할에 비해서 개발 우선순위를 높이기는 쉽지 않습니다. 매일 방문하는 고객들과 닿아있는 서비스 개발이 더 중요하기 때문이죠.

어드민 담당인력 채용과 팀을 만들어도 어드민은 데이터베이스 구조와 비즈니스로직 그리고 각 직군별 팀을 넘나드는 담당자의 필요성을 파악해야하므로 신규 인력이 바로 성공적인 어드민을 만들기엔 무리가 있습니다.

어드민 개발과 유지보수는 시스템을 모두 이해하고 있는 개발자와 함께 해야합니다. 최소한 데이터베이스와 가까운 backend 개발자가 어드민을 담당해야합니다. 기존 데이터들의 히스토리를 이해하고 어드민에 표기를하며, 새로운 기능으로 변경되는 데이터 구조를 가장 잘 알고있으며, 통계성 쿼리 또한 실시간성의 필요 여부를 파악하고 데이터베이스 성능을 고려하여 서비스에 지장이 가지 않는 방식으로 구현합니다.

그렇다고 핵심 개발자에게 어드민 개발을 모두 맡길 수 없습니다. 바쁘기 때문이죠. 때로는 어드민의 완성도를 포기하고 기대치를 낮추어 작동여부, 업무에 쓸만한 정도로만 구성을 하는게 정답일 수 있습니다. 꼭 '어드민' 형태로 만들지 않아도 일관성있는 프로세스를 통해 이슈 인입, 처리중, 처리완료를 처리한다면 매일 10건 정도는 개발자가 수작업으로 처리해도 버틸 수 있다고 봅니다.

다행히도 대부분의 똑똑하고 개발자는 매일 반복되는 단순 업무를 어떻게든 자동화하거나 덜어주기 위해 스크립트를 짜거나, CI에 스위치를 만들어두거나, Postman을 만들어두거나, Slack에 버튼을 열어주는등 방법을 제공하기 시작합니다. 그리고 결국은 어드민을 만들게 됩니다.

왜 어드민 만드는건 어려울까요

개발자의 입장에서는 어드민의 공통 요소가 있습니다.

• 로그인, 인증, 담당자 추가, 권한 처리
• 회사 이메일 연동, 권한 처리
• 로그 관리
• 어드민용 서버 배포
• +디비 스키마 변경 또는 API 실패/응답지연에도 문제가 안생기는 방어적인 설계
• +여러명이 고칠수있는 소스코드 파일 구조
• +UI Framework를 잘 선택해서 Frontend UI 개발없이 기능 구현 가능한 구조

아무리 개발해도 고객과 서비스에는 티가 안나는 부분이고, 어드민을 새로 만들때마다 공통적으로 반복해야하는 작업들 입니다.

장단점을 고민한 뒤, 이미 1개의 잘 작동하는 어드민이 존재한다면 그것을 복제하여 다시 쌓아올리는 것도 좋은 방법이 됩니다. 또는 1개의 어드민에 힘을 모아 집중하여 쌓아올리는 것도 방법 입니다.

• 신규 기능마다, 기존 어드민에 기능을 추가한다면 관리/배포는 편리하지만 유지보수의 범위와 복잡도가 점점 커지고, 모델과 상태코드가 비대해져서 추후 어드민 분할(분리)의 어려움이 커집니다.
• 신규 기능마다, 새로운 어드민을 추가한다면 관리/배포는 시간이 들지만 유지보수 범위가 줄어들고 개별적인 커스텀이 쉽지만, 중복된 모델과 상태코드가 늘어나고 추후 데이터의 변경이 어드민의 많은 변경을 요구합니다.

어드민은 누구나 개발할수있나요?

기술적인 관점이 아닌 실무자의 입장에서는 이러한 어려움이 있습니다.

• 소수 인원이 서비스 이해, 서버 개발, 프론트 개발을 모두 해야한다.
• 원하는 데이터가 어느 테이블에 있는지 모르겠다.
• 어드민에서 업데이트 구현을 하려면 해당 DB+API 담당자 모두 논의가 필요하다.
• 어드민 화면에 보여주는 데이터와 실제 디비 데이터 구조가 다르다.
• 어드민에 에러가 나거나 불편해도 아무말없이 쓴다. (정확한 버그리포트가 어렵고, 유지보수를 하다가 버그로 인해 고생하거나, 잘못표기된 값으로 착오하여 담당자가 고생하는 경우, 어드민 신뢰성이 떨어지는 경우)
• 어드민 요구사항은 늘 쌓여있고 토씨 하나 고치는 작업이 계속 늦어진다.
• 때로는 기능 릴리즈 전에 어드민부터 급하게 오픈해야하는 경우가 있다.
• 기존 UI Framework에 없는 UI를 요구하시면 설득을 하거나 추가 개발해야한다.
• 인수인계를 해야하는데/받아야하는데 기술스택이 다르다.
• 아무리 잘 만들어도 연계 시스템과 데이터가 많아서 완벽할수 없다.

어드민이 부족하고 불편한데 그냥 쓰고 있어요.

다양한 이해 관계가 입장에서도 어려운 점이 있습니다.

• 고객 상태를 물어보면 단순 확인이 꽤 오래걸린다.
• 고객 문의가 들어와서 처리를 하려고 하니 개발팀까지 이슈가 갔다온다.
• 서비스 상위/누적등 통계가 필요한데 정확한 디비 데이터를 매번 요청하고있다.
• 버그나 CS 처리로 알수없는 id 값들이 채널에 떠다니고 있다.
• 신규 기능을 오픈했는데 어드민에는 값이 표시되지 않는다.
• 어드민이 없어서 안쓴다. 띄워놓을 페이지가 없다.

어떻게 해결하면 될까요

조직마다 팀 규모마다 기술스택마다 업종마다 가용리소스 마다 모두 다르기 때문에 단 하나의 공식은 없지만 대부분 행복한 어드민은 아래의 공통점들이 있습니다.

• 최대한 작은/간단한 코드베이스를 유지하기
  어드민 메뉴와 기능이 늘어나더라도 단순한 구조로 추가하는 구조가 중요합니다.
• 메뉴/페이지마다 코드 분리, 독립성을 유지하기
  새로운 화면 추가가 기존 메뉴에 영향을 주면 안되며, 유지보수하면서 다른 화면에 영향을 끼치지 않아야합니다.
• 가능한 원본 데이터를 보여주기
  과도하게 친절한 문구는 오히려 조회/액션의 모호함을 키웁니다. 개발직군이 아니더라도 어느정도 영문 스키마 컬럼명이나 데이터 구조를 습득하고 이해할수있습니다. 정확한 에러메시지는 문제 해결에도 도움이 됩니다.
• 점진적인 기능 제공, 반복된 개선을 목표로 하기
  한번에 완벽한 어드민을 기획하기는 쉽지 않습니다. 운영하다보면 주로 보는 페이지와 주로 쓰는 기능이 생기고 그것을 빠르게 대응을 하는 계획과 기간을 가지는 것이 도움이 됩니다. 별로 안쓰는 버튼과 기능은 점점 유지보수에 짐이 됩니다.
• 이쁘지 않더라도 빠르고 정확한 UI
  개발담당자는 좋은 실력으로 높은 소프트웨어 품질을 낼수있지만 욕심을 참는 것도 필요합니다. 어드민은 매일 쓰이고 매일 보는 것이기에 불편하지 않고 단순하고 담백한 모습이 좋습니다.

이미 멀리온거 같아요. 늦어버린 것 같아요.

초기 성장하는 팀이나 스타트업에게는 매우 흔하고 당연한 고민입니다. 하지만 이는 고객과 서비스가 잘 크고 있다는 모습을 보여줍니다.

• 너무 크다면 쓰는 팀 단위로 나누기
  어드민 개선 이슈인입 단위로 코드도 나누면 체감 배포가 늘어나지 않습니다.
  
• 너무 쪼갠건 하나로 합치기
  한번 고치고 여러곳에 반영중인가요? 코드레벨에서 통합하거나, 인증 통합 후 L7 로드밸런서 활용하여 논리적으로 합치거나, Cloudflare Access등으로 하나처럼 느끼게 하는 방법도 있습니다.
  
• 이미 만들어진 어드민이 개발팀의 기술스택과 다르다면
     본인의 기술스택으로 새롭게 정리하여 재작성하면 될까요? 아닙니다. 섣부른 재작성은 더 큰 문제를 냅니다. 어드민 코드베이스의 99%를 파악하고 있다고해도 재작성을 하는 순간 1% 이상의 결함이 생길수있습니다. 간단한 패치는 본인의 기술스택이 아니더라도 고객을 위해서 꼭 해야합니다.
     지금 당장 급한 고객응대를 위한 어드민 개선이 느려지는 리스크가 있습니다.  다만 원래의 프로덕트 자체가 재작성된 경우, 데이터베이스 변경으로 큰 개선을 요구한다면 그 기능부터 새로운 스택에 쌓는건 어떨까요?
  
• 내부툴이 산재하고, 어드민 메뉴가 백과사전 같다면
  때로는 소프트웨어 관점보다도 업무, 운영, 팀간의 프로세스를 먼저 살펴봐야할 필요가 있습니다. 레파지토리와 API 단위에서 합치고 쪼개는 고민을 잠시 내려두고, 업무를 하는 분들이 필요한 문제와 도구를 재정의할 필요가 있을지 모릅니다.
  
• 구어드민과 신어드민 사이에서 줄타기 중이라면
  고통스러운 일이지만 신어드민이 모든 구어드민 역할을 할때까지 병행이 필요합니다. 구어드민 유지보수 비용이 현저하게 낮다면, 담당자분들이 병행을 크게 불편해하지 않으신다면 여러개의 어드민도 당장 해결해야할 문제가 아닐수 있습니다. 병행에 앞서 최소한으로 계정관리, 인증 로그인 통합은 필요합니다.
  
• 여러모로 느리다면
     UI적으로 페이지 분할, 검색조건 분할, 추가조회 분할등 방법이 있는지 확인이 필요합니다. DB+API 트랜잭션이 느리다면 비동기적으로 처리할 방법이 있는지 내부에 queue가 있는지 확인이 필요합니다. 때로는 서비스 정책의 변경으로 예를 들면 즉시취소가 아닌 취소대기, 취소확정등 협의가 필요할수있습니다.
     개발인력부족으로 개선이 느리다면 채용전까지는 API 직접호출, Slack 채널에 요청, 월1회 일괄 작업요청등의 방법으로 버티는게 필요합니다.

어드민은 즐거운 정원 가꾸기
Gardening

정원을 꾸미고 집안을 청소하고 인테리어와 수납을 하는건 선택의 문제입니다. 본인의 만족과 함께 일하는 팀원, 다른팀분들이 좋아하신다면 그 일 자체도 기쁨이 될수있습니다.

• 마케팅/영업/온보딩/지표확인/CS등 고객을 위해 꼭 필요한 일 입니다.
• 완벽하지 않더라도 우리 팀의 개성과 스타일에 맞는 무게의 어드민 요구치/기대치를 찾는것이 필요합니다.
• 어드민 백오피스가 회사 성장의 걸림돌이 되지 않으려면 더 늦기 전에
  빠른 대응과 정확한 개선이 필요합니다.

관련 글: 코드가 아닌 스펙으로 어드민을 만든다면

이 글은 셀렉트 어드민의 철학과 관점을 담고 있습니다.

스타트업을 위한 어드민 솔루션 - 셀렉트

비즈니스, 운영 지원 시스템을 만드는데 반복적으로 일어나는 비효율을 해결하고 있습니다.

[object Object]