관리자 페이지를 도입하면 운영 업무가 훨씬 편해질 것이라고 기대합니다.
회원 목록을 조회하고, 주문 정보를 확인하고, 필요한 데이터를 수정할 수 있다면 기존에 엑셀로 관리하던 업무도 자연스럽게 줄어들 것처럼 보입니다.
하지만 실제 운영을 시작하면 관리자 페이지가 있는데도 엑셀과 메신저를 계속 사용하는 경우가 있습니다.
담당자는 관리자 페이지에서 데이터를 조회한 뒤 다시 엑셀로 내려받아 정리하고, 여러 건의 상태를 하나씩 바꾸거나, 별도의 파일에서 담당자를 관리하기도 합니다.
이 경우 관리자 페이지가 없는 것은 아닙니다.
문제는 조회 기능은 있지만 실제 운영팀이 반복해서 수행하는 업무를 시스템 안에서 끝낼 수 없는 구조일 수 있다는 점입니다.
관리자 시스템은 단순한 데이터 조회 화면이 아니라 실제 운영팀이 매일 사용하는 업무 도구입니다.
따라서 개발 범위를 정할 때 화면 개수보다 먼저 운영자가 어떤 순서로 데이터를 확인하고, 무엇을 바꾸고, 어떤 결과를 남기는지를 살펴보는 것이 중요합니다.
1. 조회 기능만 있다고 운영 업무가 자동화되는 것은 아닙니다
관리자 시스템의 가장 기본적인 기능은 데이터 조회입니다.
회원 목록, 주문 목록, 문의 목록, 신청 목록 등을 관리자 화면에서 볼 수 있도록 만드는 것입니다.
하지만 실제 업무는 데이터를 보는 것에서 끝나지 않습니다.
운영자는 데이터를 확인한 뒤 담당자를 배정하고, 상태를 변경하고, 메모를 남기고, 여러 건을 한 번에 처리해야 할 수 있습니다.
예를 들어 신청 서비스에서 운영자가 매일 다음 업무를 처리한다고 생각해보겠습니다.
신규 신청 확인 → 담당자 배정 → 내용 검토 → 고객 연락 → 상태 변경 → 완료 처리
그런데 관리자 페이지에서 할 수 있는 것이 신청 목록 조회와 상세 확인뿐이라면 나머지 업무는 시스템 밖에서 처리하게 됩니다.
담당자 배정은 엑셀에 적고, 연락 여부는 메신저에서 공유하고, 완료 목록은 또 다른 파일로 정리할 수 있습니다.
결국 관리자 페이지가 존재하더라도 업무가 시스템 안에서 이어지지 않으면 수작업은 크게 줄지 않을 수 있습니다.
2. 관리자 시스템은 화면보다 업무 순서를 먼저 봐야 합니다
관리자 페이지를 기획할 때 흔히 메뉴와 화면부터 정합니다.
회원 관리, 주문 관리, 상품 관리, 통계와 같은 메뉴를 만들고 각 메뉴에 목록과 상세 화면을 배치합니다.
물론 이런 구조는 필요합니다.
하지만 실제 운영 효율을 높이려면 화면보다 먼저 업무 흐름을 정리하는 것이 좋습니다.
예를 들어 주문 처리 업무라면 다음과 같은 흐름이 있을 수 있습니다.
신규 주문 확인 → 결제 상태 확인 → 상품 준비 → 배송 정보 등록 → 배송 상태 변경 → 고객 안내
이 흐름을 기준으로 관리자 기능을 정하면 단순한 주문 목록 이상의 기능이 필요하다는 것을 알 수 있습니다.
반대로 화면을 먼저 만들면 실제 업무 중간에 필요한 기능이 빠지면서 운영팀이 엑셀과 메신저를 다시 사용하게 될 수 있습니다.
3. 검색 조건이 부족하면 결국 엑셀 필터를 사용하게 됩니다
운영자는 전체 데이터를 보고 싶은 경우보다 특정 조건에 해당하는 데이터만 보고 싶은 경우가 많습니다.
예를 들어 주문 담당자라면 오늘 들어온 주문 중 결제가 완료됐지만 아직 배송 준비가 시작되지 않은 주문을 찾아야 할 수 있습니다.
문의 담당자는 2일 이상 답변하지 않은 문의만 보고 싶을 수 있습니다.
관리자 페이지에서 이런 조건을 검색할 수 없다면 전체 데이터를 엑셀로 다운로드한 뒤 필터를 적용하게 됩니다.
따라서 실제 운영에서 사용하는 검색 기준을 파악하는 것이 중요합니다.
- 기간
- 처리 상태
- 담당자
- 고객명
- 주문번호
- 결제 여부
- 상품 또는 서비스 유형
어떤 조건이 필요한지는 서비스마다 다릅니다.
중요한 것은 운영자가 실제로 데이터를 찾는 기준이 관리자 검색 기능에 반영되어 있는지입니다.
4. 반복해서 여러 건을 수정한다면 일괄 처리 기능을 검토해야 합니다
관리자 시스템에서 수작업이 많이 발생하는 대표적인 이유 중 하나가 개별 수정입니다.
예를 들어 주문 100건을 같은 상태로 변경해야 하는데 주문 하나씩 상세 화면에 들어가 상태를 수정해야 한다면 상당한 시간이 걸립니다.
담당자 역시 여러 건을 같은 직원에게 배정해야 할 수 있습니다.
이런 업무가 반복되면 운영자는 관리자 페이지보다 엑셀을 더 편하게 느낄 수 있습니다.
서비스 특성에 따라 다음과 같은 일괄 기능을 고려할 수 있습니다.
- 상태 일괄 변경
- 담당자 일괄 배정
- 선택 데이터 일괄 다운로드
- 태그 또는 분류 일괄 변경
- 여러 건 일괄 승인
이런 기능 하나가 운영팀의 반복 클릭 수십 번을 줄일 수도 있습니다.
5. 상태값이 실제 업무 단계와 맞지 않으면 별도 엑셀이 생깁니다
관리자 시스템에서 상태값은 중요한 역할을 합니다.
하지만 개발 과정에서 상태를 지나치게 단순하게 정의하면 실제 업무를 표현하기 어려울 수 있습니다.
예를 들어 시스템에는 ‘처리 중’과 ‘완료’만 있다고 생각해보겠습니다.
실제 운영팀에서는 다음과 같이 더 세부적인 단계가 필요할 수 있습니다.
- 신규 접수
- 담당자 배정
- 고객 확인 중
- 추가 자료 요청
- 승인 대기
- 처리 완료
- 보류
시스템에서 이런 상태를 표현할 수 없다면 운영팀은 엑셀에 ‘실제 상태’라는 새로운 칼럼을 만들어 관리할 가능성이 높습니다.
따라서 상태값은 개발자가 임의로 정하기보다 실제 업무 담당자와 함께 정의하는 것이 좋습니다.
6. 담당자 배정 기능이 없으면 메신저가 업무 관리 도구가 될 수 있습니다
여러 명의 운영자가 함께 일한다면 어떤 업무를 누가 처리하는지 구분해야 합니다.
담당자 배정 기능이 없다면 팀에서는 메신저나 엑셀을 이용해 업무를 나누게 될 수 있습니다.
예를 들어 “이 주문은 김OO님이 처리해주세요”라고 메신저에 남기고, 별도 엑셀에 담당자 이름을 적을 수 있습니다.
이런 방식은 업무량이 적을 때는 가능하지만 데이터가 많아지면 누락이나 중복 처리 가능성이 높아집니다.
관리자 시스템에서 담당자를 지정하고 ‘내 담당 업무’를 바로 조회할 수 있다면 별도 파일 관리가 줄어들 수 있습니다.
7. 담당자마다 필요한 권한이 다를 수 있습니다
관리자 페이지를 여러 명이 사용한다면 모든 사람이 같은 기능을 사용할 필요는 없습니다.
예를 들어 고객센터 담당자는 주문을 조회하고 메모를 남길 수 있지만 환불 권한은 없어야 할 수 있습니다.
정산 담당자는 결제 정보를 확인할 수 있지만 회원정보를 수정할 필요는 없을 수 있습니다.
최고 관리자만 다른 직원의 권한을 수정하도록 만들 수도 있습니다.
따라서 업무 역할에 따라 조회, 등록, 수정, 삭제, 승인 권한을 구분할 수 있습니다.
권한을 제대로 나누면 불필요한 기능을 감추고 중요한 작업의 실수 가능성도 줄일 수 있습니다.
8. 데이터 다운로드는 없어도 문제지만 너무 자유로워도 문제가 될 수 있습니다
운영팀에서는 데이터를 엑셀로 내려받아야 하는 업무도 있습니다.
외부 업체에 자료를 전달하거나 내부 보고서를 만들거나 추가적인 분석을 해야 할 수 있기 때문입니다.
따라서 엑셀 다운로드 자체가 나쁜 것은 아닙니다.
오히려 필요한 기능일 수 있습니다.
다만 매번 전체 데이터를 내려받은 뒤 필요한 칼럼을 삭제하고 필터링하는 작업을 반복한다면 다운로드 기능을 개선할 수 있습니다.
검색 결과만 내려받거나 필요한 항목을 선택해서 다운로드할 수 있도록 만들 수도 있습니다.
개인정보가 포함된 데이터라면 어떤 관리자에게 다운로드 권한을 줄 것인지도 함께 검토해야 합니다.
9. 엑셀 업로드가 오히려 필요한 업무도 있습니다
관리자 시스템의 목표가 반드시 엑셀을 완전히 없애는 것은 아닙니다.
대량 데이터를 수정해야 하는 업무에서는 엑셀이 효율적일 수 있습니다.
예를 들어 상품 가격 1,000건을 변경해야 한다면 웹 화면에서 하나씩 수정하는 것보다 엑셀을 이용하는 것이 편할 수 있습니다.
이런 경우 엑셀 사용을 없애려고 하기보다 시스템의 정식 기능으로 가져오는 방법을 고려할 수 있습니다.
예를 들어 다음과 같은 흐름입니다.
엑셀 파일 업로드 → 형식 검증 → 오류 데이터 표시 → 변경 예정 내용 확인 → 최종 적용
이렇게 하면 엑셀의 장점은 활용하면서 데이터 반영 과정은 시스템에서 관리할 수 있습니다.
10. 상태 변경 이력이 없으면 담당자가 다시 상황을 조사해야 합니다
운영 시스템에서는 현재 상태뿐 아니라 그 상태가 어떻게 만들어졌는지도 중요합니다.
예를 들어 어떤 주문이 갑자기 ‘취소’ 상태로 변경되어 있다고 생각해보겠습니다.
누가 언제 바꿨는지 알 수 없다면 운영팀은 담당자들에게 일일이 확인해야 할 수 있습니다.
상태 변경 이력을 남기면 다음과 같이 확인할 수 있습니다.
8월 30일 10:21 / 김OO / 신규 주문 → 결제 확인
8월 30일 14:15 / 이OO / 결제 확인 → 배송 준비
이런 기록은 담당자가 바뀌거나 고객 문의가 들어왔을 때도 도움이 됩니다.
운영팀이 별도의 엑셀에 처리 일자를 기록하는 이유가 시스템에 이런 이력이 없기 때문일 수도 있습니다.
11. 내부 메모가 없으면 업무 내용이 메신저에 흩어질 수 있습니다
운영 업무에서는 상태값만으로 표현하기 어려운 정보가 있습니다.
예를 들어 고객과 통화한 내용이나 추가 서류를 요청했다는 사실을 남겨야 할 수 있습니다.
이런 정보를 관리자 시스템에 기록할 수 없다면 담당자는 메신저나 개인 메모를 이용하게 됩니다.
담당자가 휴가를 가거나 퇴사하면 다른 직원이 이전 상황을 파악하기 어려워질 수 있습니다.
따라서 업무 특성에 따라 내부 메모, 처리 기록, 담당자 간 인수인계 내용을 시스템에 남길 수 있도록 하는 것이 좋습니다.
12. 반복적으로 같은 데이터를 다른 시스템에 입력하고 있지는 않은지 확인해보세요
운영팀의 수작업이 많은 이유가 관리자 페이지 내부 기능 때문만은 아닐 수 있습니다.
관리자 시스템에서 확인한 데이터를 다시 ERP, 배송사, CRM 등의 다른 시스템에 입력해야 할 수도 있습니다.
예를 들어 주문이 들어오면 관리자 페이지에서 확인하고 같은 고객 정보를 다시 배송사 시스템에 입력한다고 생각해보겠습니다.
이런 업무가 하루 수십 번 반복된다면 상당한 시간이 필요합니다.
외부 시스템에서 API를 제공한다면 필요한 범위에서 연동을 검토할 수 있습니다.
주문 상태 변경 시 외부 시스템으로 정보를 보내거나 외부 처리 결과를 다시 관리자 화면에 반영하는 방식입니다.
모든 업무를 자동화할 필요는 없지만 같은 정보를 반복해서 복사하고 붙여넣는 업무는 우선적으로 확인해볼 만합니다.
13. 실제 운영팀이 쓰는 엑셀을 보면 필요한 기능이 보일 수 있습니다
관리자 시스템 개선을 준비한다면 운영팀에게 현재 사용하는 엑셀 파일을 받아보는 것도 좋은 방법입니다.
파일 안에는 실제 업무에서 필요한 정보가 이미 정리되어 있을 가능성이 높습니다.
예를 들어 시스템에는 없는 다음과 같은 칼럼이 엑셀에 존재할 수 있습니다.
- 담당자
- 고객 연락 여부
- 처리 예정일
- 보류 사유
- 추가 확인 사항
- 최종 처리일
운영팀이 매번 이런 칼럼을 직접 관리하고 있다면 관리자 시스템에 아직 반영되지 않은 업무 요구사항일 수 있습니다.
엑셀에서 자주 사용하는 필터와 정렬 조건도 관리자 검색 기능을 설계하는 좋은 참고 자료가 됩니다.
14. 화면 하나에서 업무를 얼마나 끝낼 수 있는지도 중요합니다
관리자 시스템에서는 화면이 많다고 항상 좋은 것은 아닙니다.
하나의 주문을 처리하기 위해 목록 화면, 상세 화면, 회원 화면, 결제 화면을 계속 이동해야 한다면 업무 속도가 느려질 수 있습니다.
운영자가 자주 확인하는 정보를 주문 상세 화면에 함께 보여주거나 필요한 작업 버튼을 같은 화면에서 제공하는 방법도 고려할 수 있습니다.
예를 들어 주문 상세에서 고객 정보, 결제 상태, 배송 정보, 내부 메모를 한 번에 확인할 수 있도록 구성할 수 있습니다.
결국 관리자 UI는 사용자용 서비스보다 반복 작업의 클릭 수와 화면 이동을 줄이는 것이 더 중요한 경우가 많습니다.
15. 관리자 대시보드도 운영 행동과 연결되어야 합니다
관리자 페이지를 만들 때 보기 좋은 그래프와 통계를 먼저 구성하기도 합니다.
하지만 실제 운영 담당자에게 필요한 정보는 단순한 월간 가입자 그래프가 아닐 수 있습니다.
예를 들어 오늘 처리되지 않은 주문이 몇 개인지, 3일 이상 답변하지 않은 문의가 몇 개인지, 환불 확인이 필요한 건이 몇 개인지가 더 중요할 수 있습니다.
이런 정보는 단순 통계가 아니라 다음 업무를 결정하게 해줍니다.
따라서 관리자 대시보드는 예쁜 그래프를 만드는 것보다 운영자가 지금 무엇을 처리해야 하는지 알려주는 정보를 중심으로 설계하는 것이 좋습니다.
16. 같은 업무를 하루에 몇 번 반복하는지 확인해보세요
관리자 기능의 우선순위를 정하기 어려울 때는 업무의 반복 횟수를 기준으로 보는 것도 방법입니다.
한 달에 한 번 수행하는 작업보다 하루에 100번 반복하는 작업을 먼저 개선했을 때 운영 효율이 크게 높아질 수 있습니다.
예를 들어 주문 상태를 변경하는 작업을 하루에 200번 하고 있다면 클릭 수를 줄이는 것만으로도 의미가 있습니다.
반대로 거의 사용하지 않는 상세 통계 기능을 먼저 개발하면 실제 운영 효율에는 큰 변화가 없을 수 있습니다.
따라서 관리자 기능을 정할 때는 ‘있으면 좋은 기능’보다 현재 가장 자주 반복되는 업무를 먼저 찾아보는 것이 좋습니다.
17. 중요한 일괄 작업에는 확인 절차가 필요할 수 있습니다
일괄 수정 기능은 매우 편리하지만 한 번의 실수가 여러 데이터에 영향을 줄 수 있습니다.
예를 들어 주문 500건을 잘못 선택한 상태에서 일괄 취소를 실행하면 큰 문제가 발생할 수 있습니다.
따라서 중요도가 높은 일괄 작업에는 실행 전에 대상과 변경 내용을 확인하는 절차를 둘 수 있습니다.
예를 들면 다음과 같습니다.
500건 선택 → 변경 내용 확인 → 최종 확인 → 적용 → 작업 이력 기록
이렇게 하면 업무 속도를 높이면서도 실수 가능성을 줄일 수 있습니다.
18. 관리자 시스템에서 기준이 되는 데이터는 하나여야 합니다
관리자 시스템과 여러 개의 엑셀 파일이 동시에 운영되면 어떤 데이터가 최신인지 알기 어려워질 수 있습니다.
관리자 시스템에서는 주문이 완료인데 팀에서 관리하는 엑셀에는 처리 중이라고 적혀 있을 수 있습니다.
반대로 엑셀에서만 수정한 내용이 시스템에는 반영되지 않을 수도 있습니다.
이런 상황이 반복되면 문제가 생길 때 어느 데이터가 맞는지 다시 확인해야 합니다.
따라서 가능하다면 실제 업무 상태의 기준이 되는 시스템을 하나로 정하는 것이 좋습니다.
엑셀은 보고서 작성이나 외부 전달을 위한 보조 도구로 사용할 수 있지만 최종 업무 상태는 관리자 시스템에 반영되도록 만드는 것입니다.
19. 모든 엑셀 업무를 없애는 것이 목표는 아닙니다
관리자 페이지가 있다고 해서 엑셀 사용이 0이 되어야 하는 것은 아닙니다.
엑셀은 대량 데이터를 분석하거나 외부 업체에 전달하는 데 여전히 편리한 도구입니다.
중요한 것은 운영팀이 왜 엑셀을 사용하고 있는지입니다.
단순한 분석과 보고를 위해 쓰는 것인지, 아니면 관리자 시스템에 필요한 기능이 없어서 업무 자체를 엑셀에서 처리하고 있는지 구분해야 합니다.
관리자 시스템의 목적은 엑셀을 없애는 것이 아니라 중복 입력, 반복 수정, 수작업 상태 관리와 같이 불필요하게 반복되는 업무를 줄이는 것입니다.
20. 관리자 페이지 개발 전에 운영팀에게 물어보면 좋은 질문
신규 관리자 시스템을 개발하거나 기존 백오피스를 개선한다면 실제 담당자에게 업무 과정을 확인하는 것이 좋습니다.
- 업무 순서: 하루 업무를 어떤 순서로 처리하나요?
- 검색: 데이터를 찾을 때 가장 많이 사용하는 조건은 무엇인가요?
- 반복 작업: 같은 수정 작업을 하루에 몇 번 하나요?
- 엑셀: 현재 어떤 엑셀 파일을 사용하고 있나요?
- 상태: 실제 업무에서 사용하는 처리 단계는 무엇인가요?
- 담당자: 업무 배정은 어떻게 하고 있나요?
- 권한: 담당자마다 할 수 있는 작업이 다른가요?
- 이력: 누가 언제 처리했는지 확인해야 하나요?
- 일괄 처리: 여러 건을 동시에 처리해야 하는 업무가 있나요?
- 외부 시스템: 같은 데이터를 다른 곳에 다시 입력하고 있나요?
이런 질문에 답하다 보면 실제로 필요한 관리자 기능이 단순한 화면 목록보다 훨씬 구체적으로 보이기 시작합니다.
21. 관리자 페이지 견적도 화면 수만 보면 안 됩니다
관리자 페이지 개발 견적을 비교할 때 화면 개수만 확인하는 경우가 많습니다.
회원 관리 2화면, 주문 관리 3화면, 통계 2화면처럼 계산하는 방식입니다.
하지만 같은 주문 목록 화면이라도 개발 범위는 크게 달라질 수 있습니다.
단순 조회만 가능한 화면과 복합 검색, 다중 선택, 일괄 상태 변경, 담당자 배정, 엑셀 다운로드, 권한 관리가 있는 화면은 구현 범위가 다릅니다.
따라서 견적을 받을 때는 화면 수보다 각 화면에서 실제 운영자가 어떤 작업을 완료해야 하는지를 기준으로 범위를 확인하는 것이 좋습니다.
22. 관리자 시스템은 운영하면서 계속 개선할 수 있습니다
처음부터 모든 운영 기능을 완벽하게 구현할 필요는 없습니다.
서비스 초기에는 데이터도 적고 운영 담당자도 한두 명일 수 있습니다.
이 단계에서는 목록 조회, 기본 검색, 상세 확인, 상태 변경 정도로 시작할 수도 있습니다.
실제 운영 후 반복되는 업무가 발견되면 그 부분을 우선적으로 개선하는 것이 좋습니다.
주문량이 늘어나면 일괄 처리를 추가하고, 직원이 늘어나면 권한과 담당자 기능을 추가하는 식입니다.
이렇게 하면 실제 필요를 기준으로 관리자 시스템을 단계적으로 확장할 수 있습니다.
23. 관리자 페이지는 데이터 화면이 아니라 업무 도구입니다
관리자 시스템을 단순히 데이터베이스 내용을 보기 좋게 보여주는 화면으로 만들면 실제 운영 효율은 크게 달라지지 않을 수 있습니다.
운영팀이 매일 하는 업무는 데이터를 보고 끝나는 것이 아니라 그 데이터를 기준으로 판단하고 수정하고 다음 단계로 넘기는 과정이기 때문입니다.
따라서 관리자 페이지가 실제 업무 도구가 되려면 다음과 같은 흐름을 지원해야 합니다.
필요한 데이터 찾기 → 담당자 확인 → 처리 → 상태 변경 → 여러 건 일괄 작업 → 이력 기록 → 결과 확인
이 과정 중 중요한 기능이 시스템 밖에 남아 있다면 운영자는 자연스럽게 엑셀이나 메신저를 사용하게 됩니다.
결국 좋은 관리자 시스템의 기준은 화면이 많은지가 아니라 운영팀의 반복 업무를 얼마나 시스템 안에서 자연스럽게 끝낼 수 있는가입니다.
관리자 페이지가 있는데도 수작업이 계속된다면
새로운 관리자 화면을 하나 더 만드는 것보다 운영팀이 현재 어떤 작업을 엑셀과 메신저에서 하고 있는지 먼저 확인해보는 것이 좋습니다.
특히 일괄 수정, 담당자 배정, 복합 검색, 상태 관리, 데이터 다운로드와 같은 기능이 빠져 있다면 데이터를 조회한 뒤 다시 수작업으로 정리해야 하는 상황이 반복될 수 있습니다.
다음과 같은 전체 흐름을 기준으로 관리자 기능을 살펴볼 수 있습니다.
업무 데이터 접수 → 조건별 검색 → 담당자 배정 → 처리 → 상태 변경 → 일괄 작업 → 변경 이력 기록 → 필요한 데이터 다운로드
서비스에 따라 여기에 엑셀 업로드, 승인 과정, 외부 시스템 연동 등을 추가할 수 있습니다.
중요한 것은 모든 기능을 많이 넣는 것이 아니라 현재 운영팀이 반복하고 있는 작업을 기준으로 우선순위를 정하는 것입니다.
운영 흐름에 맞는 관리자 기능이 필요하다면 OneSoft와 함께 범위를 검토해보세요.
개발 문의와 자세한 내용은 OneSoft 홈페이지 에서 확인해보세요.
#관리자페이지 #백오피스개발 #업무자동화 #시스템개발 #관리자시스템 #운영시스템 #사내시스템 #웹개발 #업무시스템개발 #외주개발 #OneSoft
