관리자 페이지를 새로 개발했는데도 운영팀이 여전히 엑셀을 사용하는 경우가 있습니다.
주문 목록도 볼 수 있고, 회원 정보도 확인할 수 있으며, 데이터를 등록하거나 수정하는 기능도 갖춰져 있습니다.
겉으로 보기에는 운영에 필요한 기능이 모두 있는 것처럼 보입니다.
그런데 실제 업무를 살펴보면 담당자는 관리자 페이지에서 데이터를 확인한 뒤 다시 엑셀 파일을 열어 내용을 정리하고 있습니다.
주문 상태를 변경하기 위해 여러 건의 데이터를 하나씩 수정하거나, 담당자별 업무 현황을 확인하기 위해 관리자 페이지의 데이터를 다운로드해 별도의 엑셀 파일을 만들기도 합니다.
이런 상황은 관리자 페이지에 기능이 부족해서만 발생하는 것은 아닙니다.
실제 운영팀이 어떤 순서로 업무를 처리하는지 반영하지 않고 조회·등록·수정 화면만 만들어졌기 때문일 수 있습니다.
관리자 시스템은 단순히 데이터를 관리하는 화면이 아니라 운영팀이 매일 사용하는 업무 도구입니다.
따라서 관리자 페이지를 개발할 때는 화면 목록보다 먼저 실제 업무 흐름을 확인하고, 반복되는 작업을 시스템 안에서 끝낼 수 있도록 설계하는 것이 중요합니다.
1. 관리자 페이지가 있어도 엑셀을 쓰는 이유
관리자 시스템 개발을 시작할 때 가장 먼저 정리하는 것은 보통 메뉴와 화면입니다.
회원 관리, 주문 관리, 상품 관리, 문의 관리, 통계와 같은 메뉴를 만들고 각 화면에서 조회·등록·수정·삭제 기능을 제공하는 방식입니다.
이런 구조는 기본적인 관리자 시스템을 만드는 데 필요합니다.
하지만 실제 운영 업무는 데이터 하나를 조회하고 수정하는 것으로 끝나지 않는 경우가 많습니다.
예를 들어 주문을 처리하는 운영자가 있다고 생각해보겠습니다.
이 담당자는 주문 목록을 조회한 뒤 결제가 완료된 주문만 골라야 하고, 배송이 필요한 주문을 확인한 뒤 담당자를 지정하고, 처리 상태를 변경한 다음 하루 업무 결과를 다시 정리해야 할 수 있습니다.
관리자 페이지가 주문 목록 조회만 제공한다면 담당자는 필요한 데이터를 엑셀로 내려받아 다시 필터링하게 됩니다.
즉 문제는 관리자 화면의 존재 여부가 아니라 운영자가 한 업무를 끝내기 위해 시스템 밖으로 나가야 하는가에 있습니다.
2. 실제 업무 순서를 먼저 확인해야 합니다
관리자 페이지를 기획할 때는 화면보다 실제 업무 순서를 먼저 정리해보는 것이 좋습니다.
예를 들어 신청형 서비스를 운영한다고 생각해보겠습니다.
실제 운영 흐름은 다음과 같을 수 있습니다.
신규 신청 확인 → 담당자 배정 → 신청 내용 검토 → 고객 연락 → 상태 변경 → 결과 입력 → 완료 처리
이 흐름을 모르고 단순히 ‘신청 목록’과 ‘신청 상세’ 화면만 만든다면 운영자는 여러 작업을 다른 프로그램에서 처리하게 될 가능성이 높습니다.
반대로 실제 업무 흐름을 기준으로 관리자 시스템을 설계하면 필요한 기능이 달라집니다.
- 신규 신청만 모아서 보기
- 담당자 지정
- 처리 상태 변경
- 내부 메모 작성
- 고객 연락 여부 기록
- 완료 처리
이렇게 업무 순서와 기능을 연결하면 운영자가 엑셀이나 메신저로 다시 정리해야 하는 작업을 줄일 수 있습니다.
3. 조회 기능보다 검색과 필터가 더 중요할 수 있습니다
관리자 시스템에는 대부분 목록 조회 기능이 있습니다.
하지만 데이터가 수천 건 이상 쌓이기 시작하면 단순한 목록만으로는 실제 업무를 처리하기 어렵습니다.
운영자가 원하는 것은 전체 데이터를 보는 것이 아니라 지금 처리해야 하는 데이터를 빠르게 찾는 것입니다.
예를 들어 주문 관리 화면에서는 다음과 같은 조건이 필요할 수 있습니다.
- 주문일
- 결제 상태
- 배송 상태
- 담당자
- 상품명
- 고객명
- 주문번호
이런 검색 조건이 없다면 운영자는 전체 주문을 엑셀로 다운로드한 뒤 엑셀에서 다시 필터를 적용하게 됩니다.
결국 관리자 페이지에서 엑셀 사용을 줄이려면 운영자가 실제로 데이터를 찾는 기준을 검색 조건에 반영해야 합니다.
4. 자주 사용하는 검색 조건은 저장할 수도 있습니다
운영자가 매일 같은 조건으로 데이터를 조회한다면 검색 조건 자체가 하나의 업무 흐름이라고 볼 수 있습니다.
예를 들어 고객센터 담당자가 매일 다음 조건을 조회한다고 생각해보겠습니다.
오늘 접수 + 미처리 + 담당자 미배정
매번 세 가지 필터를 직접 선택해도 되지만 이런 작업이 반복된다면 기본 필터나 저장된 검색 조건을 제공할 수도 있습니다.
‘처리 대기’, ‘오늘 신규’, ‘내 담당 건’처럼 운영 목적에 맞는 빠른 조회 기능을 제공하면 업무 속도를 높일 수 있습니다.
관리자 페이지는 데이터를 보여주는 것만큼 담당자가 지금 해야 할 일을 빠르게 찾게 해주는 것도 중요합니다.
5. 여러 건을 하나씩 수정하게 만들면 다시 엑셀을 찾게 됩니다
운영 업무에서는 한 번에 여러 데이터를 처리해야 하는 경우가 많습니다.
예를 들어 주문 50건의 상태를 ‘배송 준비’로 변경해야 할 수 있습니다.
그런데 관리자 페이지에서 주문 하나를 열고 상태를 변경한 뒤 저장하고 다시 목록으로 돌아와 다음 주문을 수정해야 한다면 상당한 시간이 필요합니다.
이런 작업이 반복되면 담당자는 엑셀로 데이터를 내려받아 한 번에 수정한 뒤 개발팀이나 다른 담당자에게 반영을 요청하는 방식을 선택할 수 있습니다.
따라서 반복적인 업무가 있는 시스템에서는 일괄 처리 기능을 검토할 수 있습니다.
- 여러 건 상태 일괄 변경
- 담당자 일괄 배정
- 카테고리 일괄 변경
- 태그 일괄 추가
- 선택 항목 일괄 다운로드
어떤 기능을 일괄 처리해야 하는지는 실제 운영팀이 반복적으로 하는 업무를 기준으로 정하는 것이 좋습니다.
6. 엑셀 업로드가 필요한 업무도 있습니다
엑셀을 완전히 없애는 것이 항상 좋은 목표는 아닙니다.
대량 데이터를 다루는 업무에서는 엑셀이 오히려 효율적인 도구일 수 있습니다.
예를 들어 상품 가격 수백 건을 변경하거나 외부 거래처에서 전달받은 데이터를 시스템에 등록해야 하는 경우입니다.
이런 업무에서는 엑셀 사용을 막기보다 관리자 시스템에서 엑셀 업로드를 정식 업무 흐름으로 지원하는 것이 더 효율적일 수 있습니다.
다만 단순히 파일을 업로드해 바로 반영하는 방식보다는 다음과 같은 검증 과정을 고려하는 것이 좋습니다.
엑셀 업로드 → 형식 확인 → 오류 데이터 표시 → 변경 예정 내용 확인 → 최종 적용
이렇게 하면 잘못된 엑셀 파일 하나 때문에 대량 데이터가 잘못 변경되는 위험을 줄일 수 있습니다.
7. 담당자별 권한을 나누면 업무 흐름이 더 명확해집니다
여러 명이 하나의 관리자 페이지를 사용한다면 모든 담당자가 같은 기능을 볼 필요는 없습니다.
예를 들어 고객센터 담당자는 고객과 주문 정보를 볼 수 있지만 상품 가격을 수정할 필요는 없을 수 있습니다.
정산 담당자는 결제와 정산 정보를 확인해야 하지만 회원 관리 기능은 필요하지 않을 수 있습니다.
서비스에 따라 다음과 같이 역할을 나눌 수 있습니다.
- 최고 관리자
- 운영 담당자
- 고객센터 담당자
- 정산 담당자
- 파트너 담당자
각 담당자가 자신에게 필요한 메뉴와 기능에 집중할 수 있도록 권한을 나누면 관리자 페이지가 복잡해지는 것도 줄일 수 있습니다.
또한 중요한 삭제, 환불, 권한 변경 등의 기능은 특정 역할만 실행하도록 제한할 수 있습니다.
8. ‘내 담당 업무’를 바로 확인할 수 있어야 합니다
담당자 배정이 있는 서비스라면 관리자 페이지에 전체 목록만 제공하는 것으로는 부족할 수 있습니다.
각 운영자는 자신에게 배정된 업무를 빠르게 확인하고 싶어합니다.
예를 들어 다음과 같은 정보를 한 화면에서 확인할 수 있습니다.
- 내 담당 신청
- 오늘 처리해야 하는 업무
- 처리가 지연된 업무
- 고객 답변을 기다리는 업무
- 승인이 필요한 업무
이런 화면이 없다면 담당자별 업무 목록을 다시 엑셀로 만들어 관리하거나 메신저에서 서로 업무를 배분할 수 있습니다.
따라서 관리자 시스템이 실제 업무 도구가 되려면 단순 데이터 관리뿐 아니라 담당자의 업무 큐를 보여주는 기능도 고려할 수 있습니다.
9. 상태값은 실제 업무 단계에 맞게 설계해야 합니다
관리자 시스템에서 매우 중요한 것이 상태값입니다.
상태값이 실제 업무를 충분히 표현하지 못하면 운영자는 별도의 엑셀 칼럼이나 메모를 만들어 추가 상태를 관리하게 됩니다.
예를 들어 시스템에는 ‘처리 중’과 ‘완료’ 두 가지 상태만 있다고 생각해보겠습니다.
하지만 실제 운영에서는 다음과 같은 단계가 있을 수 있습니다.
- 신규 접수
- 담당자 배정
- 고객 확인 중
- 추가 자료 요청
- 승인 대기
- 처리 완료
- 보류
이런 업무 단계를 시스템이 표현하지 못하면 운영팀은 결국 엑셀을 만들어 ‘실제 상태’를 별도로 관리하게 됩니다.
따라서 상태값은 개발자가 임의로 단순화하기보다 실제 업무 담당자와 함께 정하는 것이 좋습니다.
10. 상태 변경 이력을 확인할 수 있어야 합니다
현재 상태만 보여주면 왜 해당 상태가 되었는지 알기 어려운 경우가 있습니다.
예를 들어 어떤 신청이 ‘보류’ 상태로 되어 있다고 생각해보겠습니다.
누가 언제 보류로 변경했는지, 이전에는 어떤 상태였는지 알 수 없다면 담당자가 다시 상황을 파악해야 합니다.
상태 변경 이력을 남기면 다음과 같이 볼 수 있습니다.
8월 25일 10:15 / 신규 접수 → 담당자 배정
8월 26일 14:20 / 담당자 배정 → 추가 자료 요청
8월 28일 09:30 / 추가 자료 요청 → 승인 대기
이런 기록이 있으면 다른 담당자가 업무를 이어받더라도 이전 처리 과정을 파악하기 쉬워집니다.
11. 담당자가 바뀌어도 업무 내용을 이어받을 수 있어야 합니다
실제 조직에서는 담당자가 휴가를 가거나 퇴사하거나 다른 업무로 이동할 수 있습니다.
업무 내용이 담당자 개인의 엑셀이나 메신저에만 남아 있다면 다른 사람이 이어받기 어렵습니다.
따라서 관리자 시스템에는 필요한 경우 내부 메모나 처리 기록을 남길 수 있는 기능을 두는 것이 좋습니다.
예를 들어 고객 문의라면 다음과 같은 내용이 남을 수 있습니다.
“8월 28일 고객 통화 완료. 추가 서류를 이메일로 받기로 함.”
다음 담당자는 별도의 인수인계 문서를 찾지 않고도 현재 업무 상황을 파악할 수 있습니다.
이런 운영 기록이 시스템에 쌓이면 담당자가 바뀌더라도 업무의 연속성을 유지하기 쉬워집니다.
12. 같은 데이터를 여러 곳에 입력하고 있지는 않은지 확인해보세요
운영팀이 엑셀을 사용하는 또 다른 이유는 같은 데이터를 여러 시스템에 반복 입력해야 하기 때문일 수 있습니다.
예를 들어 관리자 페이지에서 주문 상태를 변경한 뒤 배송사 시스템에도 같은 정보를 입력하고, 다시 회계용 엑셀에도 내용을 작성해야 할 수 있습니다.
이런 반복 입력은 시간이 많이 들 뿐 아니라 서로 다른 시스템에 다른 값이 들어갈 가능성도 높입니다.
외부 서비스에서 API를 제공한다면 관리자 시스템과 연결해 일부 작업을 자동화할 수 있습니다.
예를 들어 주문 상태가 변경되면 배송사에 필요한 정보를 전달하거나, 처리 결과를 다시 관리자 페이지에 반영하는 방식입니다.
반드시 모든 업무를 자동화해야 하는 것은 아니지만 동일한 데이터를 반복해서 입력하는 업무가 있다면 연동 우선순위를 검토해볼 수 있습니다.
13. 관리자 페이지에서 다운로드한 엑셀이 다시 ‘원본 데이터’가 되면 문제가 생길 수 있습니다
운영 과정에서 자주 발생하는 상황 중 하나는 시스템에서 데이터를 다운로드한 뒤 엑셀 파일을 별도로 관리하는 것입니다.
시간이 지나면 관리자 시스템과 엑셀 중 어느 것이 최신 데이터인지 알기 어려워질 수 있습니다.
예를 들어 관리자 시스템에서는 주문 상태가 ‘완료’인데 운영팀 엑셀에는 여전히 ‘처리 중’이라고 적혀 있을 수 있습니다.
반대로 엑셀에서만 수정한 정보가 관리자 시스템에는 반영되지 않을 수도 있습니다.
이런 상황이 반복되면 데이터 기준점이 여러 개 생깁니다.
따라서 관리자 시스템을 만들 때는 가능한 한 최종 상태를 확인하는 기준 시스템을 하나로 정하는 것이 좋습니다.
엑셀은 분석이나 전달을 위한 보조 수단으로 활용하더라도 실제 업무 상태는 관리자 시스템에서 관리하도록 만드는 것입니다.
14. 중요한 작업은 일괄 처리 전에 미리 확인할 수 있어야 합니다
일괄 수정 기능은 운영 효율을 높일 수 있지만 그만큼 한 번의 실수가 많은 데이터에 영향을 줄 수 있습니다.
예를 들어 주문 300건의 상태를 한 번에 바꾸는데 잘못된 조건으로 선택했다면 대량의 데이터가 잘못 변경될 수 있습니다.
그래서 중요한 일괄 작업에서는 실행 전에 대상과 변경 내용을 확인하는 절차를 둘 수 있습니다.
예를 들면 다음과 같습니다.
300건 선택 → 변경 예정 상태 확인 → 처리 대상 확인 → 최종 적용
필요하다면 작업자와 작업 시각도 기록할 수 있습니다.
운영 효율을 높이면서 실수 가능성도 함께 관리하는 것입니다.
15. 관리자 화면에 필요한 통계는 실제 의사결정과 연결되어야 합니다
관리자 페이지를 만들 때 멋진 그래프와 대시보드를 먼저 구성하는 경우도 있습니다.
하지만 실제 운영팀이 업무를 처리하는 데 도움이 되지 않는 통계라면 결국 엑셀에서 다시 데이터를 가공하게 됩니다.
예를 들어 운영 담당자에게 단순한 월별 가입자 그래프보다 ‘3일 이상 처리되지 않은 신청 건수’가 더 중요할 수 있습니다.
고객센터라면 오늘 접수된 문의 수와 미답변 문의 수가 중요할 수 있습니다.
정산 담당자라면 월 매출 그래프보다 정산 예정 금액과 미정산 건을 확인하는 것이 더 중요할 수 있습니다.
따라서 관리자 대시보드는 보기 좋은 통계를 만드는 것보다 운영자가 다음 행동을 결정하는 데 필요한 정보를 보여주는 것이 중요합니다.
16. 운영팀이 직접 관리자 페이지 설계에 참여하는 것이 좋습니다
관리자 시스템은 실제 사용하는 사람의 업무를 반영해야 합니다.
대표자나 기획자만 요구사항을 정리하면 실제 운영 과정에서 필요한 세부 기능이 누락될 수 있습니다.
따라서 개발 전 운영 담당자의 실제 업무를 확인하는 것이 좋습니다.
예를 들어 다음과 같은 질문을 할 수 있습니다.
- 하루 업무를 어떤 순서로 처리하는가?
- 가장 자주 보는 데이터는 무엇인가?
- 매일 사용하는 엑셀 파일은 무엇인가?
- 엑셀에서는 어떤 필터와 수식을 사용하는가?
- 반복해서 복사·붙여넣기 하는 데이터가 있는가?
- 다른 담당자에게 업무를 어떻게 전달하는가?
- 문제가 생겼을 때 어떤 기록을 찾아보는가?
특히 현재 사용 중인 엑셀 파일은 관리자 시스템 요구사항을 찾는 데 좋은 자료가 될 수 있습니다.
운영팀이 엑셀에 직접 만들어 사용하고 있는 칼럼과 상태값이 실제로 필요한 업무 기능일 가능성이 높기 때문입니다.
17. 엑셀을 없애는 것이 아니라 반복 업무를 줄이는 것이 목표입니다
관리자 시스템을 만들었다고 해서 모든 엑셀 사용을 없애야 하는 것은 아닙니다.
대량 데이터를 분석하거나 외부 업체에 전달하는 업무에서는 여전히 엑셀이 편리할 수 있습니다.
중요한 것은 엑셀을 사용하는 이유입니다.
데이터를 분석하거나 공유하기 위해 필요해서 사용하는 것인지, 아니면 관리자 시스템이 실제 업무를 지원하지 못해서 임시로 사용하는 것인지 구분해야 합니다.
관리자 페이지의 목표는 엑셀 자체를 없애는 것이 아니라 중복 입력, 수작업 정리, 담당자 개인 파일 의존 같은 반복적인 운영 업무를 줄이는 것에 가깝습니다.
18. 초기에는 단순하게 시작하고 실제 운영 후 확장할 수도 있습니다
처음부터 모든 운영 기능을 완벽하게 만들 필요는 없습니다.
서비스 초기에는 운영 인원도 적고 데이터도 많지 않을 수 있기 때문입니다.
이때는 기본적인 목록 조회, 검색, 상세 확인, 상태 변경 기능으로 먼저 시작할 수 있습니다.
실제 운영 과정에서 반복되는 업무가 발견되면 그 업무부터 자동화하거나 일괄 처리 기능을 추가할 수 있습니다.
예를 들어 처음에는 담당자가 주문 상태를 개별 수정했지만 주문량이 증가하면서 일괄 수정 기능을 추가할 수 있습니다.
이후 담당자가 늘어나면 역할별 권한과 변경 이력을 추가할 수 있습니다.
이런 방식으로 실제 업무량과 운영 문제를 기준으로 관리자 시스템을 단계적으로 확장하면 불필요한 기능 개발을 줄일 수 있습니다.
19. 관리자 시스템 개발 전에 확인하면 좋은 항목
관리자 페이지를 새로 만들거나 기존 시스템을 개선하려고 한다면 화면 수만 정리하기보다 실제 업무를 기준으로 다음 항목을 확인해보는 것이 좋습니다.
- 업무 순서: 운영자가 하루 업무를 어떤 순서로 처리하는가?
- 검색: 어떤 조건으로 데이터를 자주 찾는가?
- 담당자: 업무를 담당자별로 나누는가?
- 권한: 담당자마다 사용할 수 있는 기능이 다른가?
- 상태: 실제 업무 단계가 시스템 상태값에 반영되어 있는가?
- 일괄 처리: 같은 작업을 여러 건 반복해서 하고 있는가?
- 엑셀: 어떤 데이터를 다운로드하거나 다시 업로드하는가?
- 이력: 누가 언제 상태를 변경했는지 확인해야 하는가?
- 메모: 담당자 간 업무 인수인계가 필요한가?
- 연동: 같은 데이터를 다른 시스템에 반복 입력하고 있는가?
- 통계: 운영자가 실제 의사결정을 위해 필요한 지표는 무엇인가?
이런 내용을 정리하면 단순한 관리자 화면이 아니라 실제 운영 업무를 처리할 수 있는 시스템의 범위를 구체적으로 정하기 쉬워집니다.
20. 관리자 페이지 견적은 화면 개수만으로 비교하기 어렵습니다
관리자 시스템 견적을 받을 때 화면 개수를 기준으로 비교하는 경우가 많습니다.
회원 관리 2페이지, 주문 관리 3페이지, 상품 관리 4페이지처럼 화면 수를 계산하는 방식입니다.
하지만 같은 주문 목록 화면이라도 실제 개발 범위는 크게 다를 수 있습니다.
단순 목록 조회만 제공할 수도 있고, 복수 조건 검색, 담당자 배정, 상태 일괄 변경, 엑셀 다운로드, 변경 이력, 권한 관리까지 포함될 수도 있습니다.
따라서 관리자 페이지 견적을 검토할 때는 단순히 화면이 몇 개인지보다 그 화면 안에서 운영자가 어떤 업무까지 완료해야 하는지를 확인하는 것이 중요합니다.
21. 관리자 페이지가 실제 업무 도구가 되려면
관리자 페이지는 사용자가 직접 보는 서비스 화면과 성격이 다릅니다.
일반 사용자 화면은 쉽고 직관적인 경험이 중요하지만 관리자 화면은 운영자가 반복적으로 업무를 빠르게 처리할 수 있어야 합니다.
클릭 한 번을 줄이는 것, 여러 건을 한 번에 처리하는 것, 필요한 데이터만 빠르게 찾는 것이 하루에 수십 번 반복되면 운영 효율에 큰 차이가 생길 수 있습니다.
따라서 관리자 페이지를 만들 때는 기능 목록만 확인하기보다 실제 담당자가 현재 어떤 방식으로 업무를 처리하고 있는지 살펴보는 것이 좋습니다.
특히 관리 시스템을 만들었는데도 운영팀에서 별도의 엑셀 파일이 계속 늘어나고 있다면 그 파일 안에 아직 시스템에 반영되지 않은 업무 규칙이 있을 가능성이 있습니다.
엑셀에 새롭게 추가되는 칼럼, 담당자가 직접 만든 상태값, 반복적으로 사용하는 필터를 살펴보면 다음 관리자 기능의 우선순위를 발견할 수 있습니다.
관리자 페이지를 개발하고 있다면
관리자 페이지는 데이터를 조회하고 수정할 수 있다는 것만으로 실제 운영 업무를 충분히 지원한다고 보기 어려울 수 있습니다.
운영자가 데이터를 확인한 뒤 다시 엑셀에 정리하고, 메신저에서 담당자를 배정하고, 여러 건을 하나씩 반복해서 수정하고 있다면 업무 흐름 중 일부가 아직 시스템 밖에 남아 있는 것입니다.
따라서 관리자 시스템을 설계할 때는 다음과 같은 전체 운영 흐름을 함께 확인해보는 것이 좋습니다.
데이터 접수 → 조건별 조회 → 담당자 배정 → 업무 처리 → 상태 변경 → 일괄 작업 → 처리 이력 기록 → 결과 확인
필요한 경우 엑셀 업로드·다운로드나 외부 시스템 연동까지 포함해 담당자가 실제 업무를 어디에서 시작하고 어디에서 끝내는지도 확인해야 합니다.
결국 관리자 시스템에서 중요한 것은 기능이 몇 개 있는지가 아니라 운영팀의 실제 업무가 시스템 안에서 자연스럽게 이어질 수 있는가입니다.
반복되는 운영 업무가 있다면 OneSoft와 관리자 기능 범위를 함께 정리해보세요.
개발 문의와 자세한 내용은 OneSoft 홈페이지 에서 확인해보세요.
#관리자페이지 #백오피스개발 #업무자동화 #운영시스템 #관리자시스템 #사내시스템 #업무시스템개발 #웹개발 #외주개발 #OneSoft
