백오피스 시스템 기획 시 TIPS
과거 스타트업에 재직 중이었을 때, 이직 전 마지막으로 받은 마지막 미션은 서비스의 백오피스 시스템을 만드는 것이었습니다. 벤치마킹에 집착하는 기획자의 특성상 서비스의 프론트 기획의 경우, 세상에 널려있는 서비스가 많았지만, 백오피스 시스템은 고도몰이나 Cafe24의 입점 고객용 화면 이외에는 참고할 화면이 별로 없더라고요.(참고 목록) 앞서 말한 두 서비스는 백오피스 시스템을 참고하기에는 매우~ 잘 만든 서비스이긴 하지만, 반대로 너무 잘 만들어서 몸담고 있는 회사에서 프론트에 맞는 백오피스 시스템을 만들기에 참고하기 어려울 수 있습니다. 제가 쓴 글이 주니어 기획자가 백오피스 시스템을 만드는 데 있어, 조그마한 지침이 되길 바랍니다.
백오피스 시스템이란?
사실 IT 전반에서 이러한 기능을 통칭하는 말이 별로 없어 보이긴 합니다.
백오피스 시스템이라고 하기엔 백앤드 개발자가 관리하는 DB와 시스템 전체를 말하는 거 같고,
관리자 페이지라고 하기엔 프론트 전반과 서버를 연결하는 시스템의 역할로서 기능 축소가 된 거 같고,
미디어 회사에 있는 입장에서 CMS(Contents Managing System)라는 말을 많이 쓰긴 하지만,
콘텐츠 외 정산 및 전체적인 관리의 영역도 포함되어 있어, CMS도 범위가 좁아 보입니다.
ERP(Enterprise Resourcing Planning) 시스템이라고 하기에는 좁은 기능을 담당하고 있습니다.
뭐라고 부르든 애매한 듯하여. 백오피스 시스템이라고 지칭하겠습니다.
잘 만든 백오피스 시스템의 경우, 다음의 항목들을 갖추어야 한다고 생각합니다.
안정성
- 이슈 없이 서비스를 구동할 수 있는 안정성
완전성
- 모든 필요 서비스(프론트 운영, 정산, 홍보 등)를 모두 지원할 수 있는 완전성
확장 가능성
- 당장은 지원하지 않더라도 예상되는 기능을 쉽게 추가할 수 있는 확장 가능성
운영 편의성
- 운영에서 휴먼 에러가 발생하지 않을 수 있도록 직관적인 페이지를 기획하는 운영 편의성
개발 편의성
- 상대적으로 적은 개발 리소스 투입으로 추가 개발이 가능할 수 있는 개발 편의성
위 요소의 순서는 개인적으로 생각하는 중요도입니다.
그중에서도 서비스 안정성은 하위 항목들의 추구를 통해, 도달해야 할 최종 목표입니다.
팁들을 나열하며, 팁들이 어떠한 요소들을 보완하는지 적어보겠습니다.
(요소가 생각날 때마다 꾸준히 업데이트될 수 있습니다.)
1. 정석적으로 기획하고, 개발에 반영하자.
별도의 메뉴를 통해 기획/개발돼야 함에도 불구하고,
비슷한 기능이 있다는 이유로, 인적 리소스가 부족하다는 이유로, 시간에 쫓긴다는 이유로
연관성이 없는 기능이 상관없는 메뉴에 편입되는 경우가 있습니다.
백오피스 기능에 대한 전반적인 개선은 IT 회사 내에서 가장 후순위로 생각되는 프로젝트입니다.
백오피스 기능이 전반적인 개선이 기업의 이윤 창출에 도움이 되는 것도 아니고,
이슈가 줄어든다는 장점이 있을 수 있으나 과거 시스템에 적응한 운영자와 개발 결과물의 온보딩 실패 등으로 인해 당장은 이슈가 늘어날 수 있습니다.
정석적으로 행하지 않은 기획은 몇 년 뒤에 더 큰 재앙으로 다가올 수 있습니다.
꼭 정석적으로만 기획해야만 하는 건 아니지만, 되도록 피해야 합니다.
2. 프론트에 대한 완벽한 이해를 전제로 백오피스를 기획하자.
어쨌든 서비스의 주인공은 프론트입니다.
프론트에서 조작 반영하고자 하는 사항을 완벽하게 파악하여, 개발 없이 운영만으로도 서비스를 다룰 수 있게 백오피스를 기획해야 합니다.
3. 서버 구조에 대한 이해도 역시 필요하다.
어떤 서버에 대한 백오피스 기획을 하는 것인지.
한 페이지 내에 모두 조회할 수 있는 데이터인지.
조회만 가능한지, 수정까지 모두 가능한 데이터인지.
위의 사항들을 파악하려면 서비스의 서버 구조에 대한 이해가 필요합니다.
개발자 레벨까지는 아니더라도, 이 서버 내에 어떤 데이터가 담겨있으며, 어떤 기능을 수행한다 까지는 숙지해야 합니다.
4. 제한 사항과 운영 숙련도를 생각하여 기능을 부여하자.
서비스 내에 공지사항 게시판을 출력해야 하는 상황을 가정해 봅시다.
게시판 내 글을 쓰기 위해서 백오피스 내에 텍스트 입력 필드가 필요합니다.
텍스트 입력 필드는
- 단순히 글씨만 쓸 수 있으면 되는지
- 텍스트 에디터가 존재하여, 글자색, 배경색, 볼드, 이텔릭, 밑줄 등을 설정할 수 있어야 하는지
- HTML 태그를 지원할지
생각해봐야 합니다.
대부분의 서비스는 전체적인 색깔톤과 룩앤필을 중시 여깁니다.
고로 공지사항 게시판의 경우, 대부분 글씨만 써도 가능하게 백오피스를 구현해야 합니다.
괜히 운영자가 실수로 다른 색깔이나 폰트 등을 사용하여, 서비스의 컨셉을 흔들면 안 되니까요.
게다가 스마트폰의 라이트 모드, 다크 모드까지 생각하면, 텍스트 필드를 더 만들어야 하니 이것도 엄청 귀찮은 일이고요.
하지만 특수한 이유로 편집이 필요하다면, HTML 태그 기능으로 손쉽게 구현이 가능하지 않을까요?
운영 담당자가 HTML 태그 활용이 용이한지 선 체크하시는 걸 추천드립니다.
인력의 익숙함에 따라 상황이 달라질 수 있으니, 에디터 없이 HTML만 지원하는 것은 되도록 지양해야 합니다.
5. 자동화와 운영 사이의 조율은 안정성을 기반으로 하자.
기획/운영이 발달한 회사에서 개발팀은
개발 리소스도 부족한데, 굳이 이걸 편하게 하자고 개발해야 해? 그냥 운영 외주에 맡기라고 해!
라고 할 수 있고,
반대 상황에서는
아 운영 인력도 부족한데, 제발 이것 좀 자동화시켜줘.
라고 말할 수 있습니다.
회사 사정에 따라 다르게 기획 적용해야 하는 부분이지만, 중요한 것은 안정성입니다.
서비스가 운영의 손을 많이 탈수록 휴먼 에러의 가능성 또한 높아집니다.
데이터의 유무가 분명한 부분은 자동화로 풀어나가고(DB구조와 이미 상용 배포된 데이터의 예시를 살펴보고 결정해야 합니다.), 회색지대로 구분이 어려운 영역은 운영에 맡겨, 서비스의 이슈를 최소화해야 합니다.
6. 가이드 없는 직관적인 백오피스 시스템을 목표로 하자.
설명서가 필요 없는 서비스가 최고의 서비스죠.
운영자의 눈높이에 맞춰 서비스를 기획합시다.
그리고 직관적인 백오피스 시스템을 만들기 어렵다면, 이해하기 쉬운 가이드를 만들어봅시다.
사용하기 쉬운 백오피스 시스템 기획을 위해 혼동이 없는 정확한 용어를 사용합시다. 그리고
7. 직관적인 버튼 및 아이콘 등을 사용하자.
적재적소에 적절한 컴포넌트를 사용해야 합니다.
최근에 백오피스 제작 용도로 많이 쓰이는 프레임워크인 부트스트랩의 컴포넌트 페이지가 있습니다.
해당 페이지에서 컴포넌트들을 살펴보며, 어떤 상황에서 어떤 컴포넌트를 사용할지 고민해봅시다.
단일 선택이 필요한 항목에서 좌측의 체크 박스를 사용하고 있진 않은지
단순 텍스트 출력 자리에 버튼이 출력되어 클릭하게 만들고 싶게 하는지
1-10까지의 숫자만 선택하면 되는데, 드롭다운 메뉴로 선택하는 대신 텍스트 박스를 넣어 불편함을 주는지
최적화된 선택 방법이 무엇인지 고민해봅시다.
8. 입력 및 표시 시 헷갈림이 없이 분명하게 기획하자.
예시 1)
2022년 1월 1일부터 2022년 1월 31일까지 노출시켜야 하는 배너가 있다고 가정합시다.
개발자와의 협의 끝에 기획안은 연월일 시분까지 드롭다운으로 숫자를 선택하게 하고, 분은 5분 단위로 컨트롤하는 것으로 협의하였습니다.
그렇다면 종료 시각은 2022년 1월 31일 23시 55분으로 해야 할까요? 2022년 2월 1일 0시 00분으로 해야 할까요?
방법은 세 가지입니다.
뒤 시간을 이하가 아닌 미만으로 설정하여 개발 적용.
별도의 순서 적용이 없는 배너나 요소라면, 2월 1일 0시 0분에 새로운 배너나 요소를 노출한다.
시간을 시분초까지 디테일하게 표기하여, 1월 31일 23시 59분 59초에 종료하게 기획한다.
어떤 것이 좋을까요?
예시 2)
메인에 노출하는 배너를 생성한다고 가정합시다.
암묵적으로 종료 날짜를 설정할 때 공란으로 설정하면, 배너 종료일이 없이 별도 컨트롤이 없으면 무기한으로 배너를 노출하는 것으로 가정합니다. 보통 그렇긴 합니다만, 능숙한 운영자만 백오피스를 운영한다는 보장은 없습니다. 헷갈리는 요소를 최소화하기 위해, "종료 없음" 버튼을 기간 옆에 두고, "종료 없음"이 활성화되면 종료 날짜의 날짜 필드가 비활성화되는 것이 분명한 기획입니다.
9. 직관적으로 GNB 및 SNB 메뉴를 설정하자.
변동이 있을 수 있는 R&R 대신 프런트의 메뉴를 기준으로 직관적으로 백오피스의 GNB 및 SNB의 메뉴를 설정합시다. 프런트에 어떠한 부분을 변경하고자 할 때, 메뉴명만으로도 직관적으로 변경할 수 있게 메뉴명을 설정합시다.
메뉴별 메뉴를 설정했다면, 기타 메뉴는 기능에 맞춰 직관적인 메뉴명으로 메뉴를 설정합시다.
콘텐츠관리/고객관리/정산관리/백오피스관리 등의 이름으로 기능에 맞춰 누구나 알아보기 쉬운 이름으로 메유를 설정합시다.
1번 사항의 연장선으로, 신규 기능 업데이트 시 기존 메뉴 안에서 구현 가능하다 생각하여 욱여넣는다면 이슈 처리비용과 QA, 실제 운영 비용이 더 증대될 수 있습니다.
10. 저장과 배포 기능을 구분하자.
저장은 변경 사항을 백오피스 내에 저장하는 것이고, 배포는 서비스 출력을 위해 저장된 사항을 프런트에 출력하는 행위를 의미합니다.
배포 기능을 별도로 가지고 있을 경우의 장점은
- 예약 배포 기능 구현 가능
- 배포 후의 상용 리스트를 출력함으로써, 현재 프런트에 출력되는 요소(배너 등)에 대해 확인이 가능
위와 같습니다.
11. 예약 배포 기능을 구현하자.
예약 배포 기능 구현 시, 운영 직원이 밤새 서비스를 컨트롤할 필요가 없고, 그만큼 운영 비용이 감소됩니다.
또한 개별로 저장 버튼을 누른다면, 정확히 같은 시간에 프론트 서비스를 컨트롤할 수 없지만,
예약 배포 기능이 있다면, 원하는 시간에 일괄적으로 서비스를 컨트롤할 수 있습니다.
12. 운영자가 알아보기 쉽도록 에러 메시지를 분명하게 출력하자.
하나의 백오피스 페이지에서 저장이나 배포 시 오류 사항 시나리오를 모두 생각하여, 팝업 스트링을 기획합시다.
13. 오류 코드가 출력되는 팝업의 텍스트 복사를 가능하게 하자.
하지만 운영자의 휴먼에러가 아닌 상황에서도 오류는 발생할 수 있습니다. 구분되는 오류 상황에서 오류코드를 설정하고 해당 오류코드의 텍스트 복사를 가능하게 하여, 빠른 이슈 해결에 도움을 줍시다.
14. 에러 메시지가 출력되기 전에 인지하는 게 더 좋다.
저장 버튼을 누르기 전에 에러 메시지를 출력하면, 운영 편의성을 더 줄 수 있습니다.
15. 기획 전에 이해관계자와 충분히 대화를 나누자.
결제 취소 운영을 했을 때의 경험입니다.
결제 취소 운영 시 보는 테이블은 유저 ID, 금액, 날짜 세 가지 입니다만, 날짜 열이 가로 스크롤로 우측으로 이동해야만 확인이 가능했었죠.
작은 불편함이지만, 운영 속도 저하 및 휴먼 에러 발생이라는 부작용을 초래하는 불편함이었습니다.
실제 사용하는 운영자의 의견을 들어 백오피스 시스템을 기획해야 합니다.
16. 삭제 기능은 되도록 넣지 말고, 노출 불가로 처리하자.
로그는 개발만 쌓는 것이 아닙니다.
운영에서도 관리 이력들을 쌓아놓는다면,
향후에 비슷한 요소를 프론트에 반영할 때, 운영 이슈 사항이 발생했을 때 히스토리 파악 시에 더 유리할 수 있습니다. 그렇기에 삭제 버튼은 없거나, 고권한의 관리자에게만 부여돼야 합니다.
17. 과부하의 원인을 제거하고, 이슈를 컨트롤하자.
과부하가 발생될 수 있는 기능의 경우, 개발자와 협의하여 일괄 처리의 양과 범위를 UI로 제한해야 합니다.
예를 들어, 마케팅 이벤트를 통해 다수의 사용자에게 일괄적으로 캐시를 부여한 적이 있습니다.
해당되는 사용자의 ID를 CSV 파일로 적용하는 작업이었는데, 다수의 인원이 동시간대에 적용을 하다 보니,
서버의 과부하 상태를 체크해가며 작업을 진행한 경험이 있었습니다.
그때 CSV 파일 내의 고객 ID의 개수를 제한하는 방식으로 운영을 수행하고,
이미 개수가 제한된 CSV 파일이지만, 서비스 페이지에 적용 시에 적용된 고객 ID의 개수를 체크하고,
적용 시에 페이지가 다운되었는지 확인할 수 있게 움직이는 프로그레스바로 상태를 확인하게 한다든지
의 방법으로 개발과의 적극적 협의를 통해, 과부하 이슈를 컨트롤해야 합니다.
18. 자주 쓰는 기능을 공통으로 사항으로 기획하여 사용하자.
미디어 서비스의 백오피스 시스템의 경우,
영화나 음악 같은 미디어를 호출하는 화면, 고객 조회 화면 등은 공통으로 사용할 수 있게 팝업으로 설정하면,
손쉬운 기획 및 개발이 가능합니다. 특히나,
19. 랜딩타입과 모듈타입을 공통 사항으로 설정하자.
랜딩타입과 모듈타입의 경우 미리 공통으로 기획하면 더욱 좋습니다.
반응 없이 구현, 서비스 내 일정한 메뉴로 이동, 일정한 URL로 이동(웹뷰), 일정한 URL로 이동(외부 브라우저), 단말기의 공유하기 기능으로 이동, 단말기의 설정 메뉴로 이동 등 다양한 곳으로 이동할 수 있습니다. 그리고 이동시에 필요한 값도 모두 다르죠. 일정한 콘텐츠에 진입할 땐 콘텐츠로 연결하거나 콘텐츠 ID를 입력할 수 있어야 하고, URL이동시에는 주소가 필요합니다.
이러한 기능을 랜딩타입으로 구현하여, 다른 백오피스 화면에서 공통으로 사용할 수 있게 관리한다면 효율적으로 기능 구현 및 개발이 가능합니다.
모듈타입의 경우 리스트가 보이는 형태입니다.
예를 들어 홈 화면 내에 5개의 영화를 보여줄 경우, 보이는 방식을 다르게 하여 출력할 수 있습니다.
포스터 5개를 출력하거나, 썸네일 5개를 출력하거나, 주인공의 사진 5개를 출력할 수도 있고요.
5개가 가로스와이프로 출력되는지, 세로스와이프로 출력되는지도 다르게 설정할 수도 있습니다.
서비스 내에서 일정한 모듈타입을 계획하고 팝업으로 관리한다면, 노출 관리의 효율성을 도모할 수 있습니다.
20. 랜딩타입의 최선은 리스트 UI 구현, 차선은 ID 부여, API주소 부여는 최후의 수단으로 고려하자.
메인에 어떠한 최신영화를 배너로 설정하는 상황을 가정해봅시다.
백오피스 내에서 배너를 설정하고 영화에 대한 링크를 구현할 때, 배너에 최신영화를 어떻게 선택하는 것이 좋을까요?
최선은 영화를 조회하는 팝업을 출력하고, 그 창내에서 조건대로 검색을 하여 영화를 선택하는 것입니다.
운영자가 별도의 화면에서 영화를 찾는 수고를 덜고, 여러 검색 조건에서 정확하게 원하는 콘텐츠를 선택할 수 있으니까요.
이러한 최선의 상황을 구현하기 어려울 때, 콘텐츠에 매겨진 별도의 ID를 입력합니다.
별도의 ID를 입력하는 기획을 해야 하는 상황은
- 다수의 콘텐츠를 빠르게 입력하고 싶을 때 (적당한 수의 콘텐츠를 정확하게 찾는 시나리오에서는 리스트 팝업만으로도 구현이 용이합니다.)
- 이미 팝업이 하나 열려있는 상황이어서, 또 팝업을 열기가 어려울 경우 (이 상황은 뒤에 더 후술 하겠습니다.)
- 리스트 팝업에 개발이 되어있지 않은 경우
등이 있습니다.
반면 API주소를 입력하는 상황은 되도록 지양해야 합니다.
개발 리소스의 부족 등이 이유라면, 이러한 UI를 유지하는 기간은 되도록 짧아야 합니다.
운영 숙련도 측면에서도 그렇고, 운영을 위한 지속적 개발 리소스가 소모되는 상황도 방지해야 하기 때문입니다.
21. 백오피스 로그인 후 백오피스를 위한 공지사항 란을 마련하자.
여러 협업툴과 기업 홈페이지 내 소통 창구가 있지만,
이 백오피스를 사용하는 사람들에게 정확하게 닿을 수 있는 소통 창구는 백오피스 접속 후 게시판입니다.
긴급한 서버 점검 등의 상황을 백오피스 메인 내 게시판에 게재한다면, 커뮤니케이션 부족으로 인한 이슈 또한 감소될 것입니다.
22. 개인정보 관련 기능은 되도록 몰아넣자.
스타트업에서는 당장 신경 쓰지 않을 수 있지만, 기업의 규모가 커진다면, 보안은 선택이 아닌 필수가 될 것입니다. 개인정보를 다루는 메뉴를 별도로 생각해서 몰아넣는다면, 외부 감사나 ISMS 심사 시 개발 편의성을 도모할 수 있습니다.
23. 순서 변경 기능은 보수적인 UI를 가져가자.
기획하며 생각보다 아규가 많았던 기능이 백오피스 내 순서 변경 기능이었습니다.
모바일 UI의 보편화로 햄버거 버튼의 드래그 드롭으로 순서 변경을 요구했었는데,
이 기능이 생각보다 이슈 사항이 많았습니다.
다루는 백오피스 메뉴의 성질에 따라 노출 유무, 노출 기간 설정 등과 꼬여서 제대로 작동하지 않는 경우가 있었습니다. 별도의 순서 팝업을 띄운 후, 각각 항목을 드롭다운 내 숫자로 선택해서 순서를 변경하거나, 항목을 체크박스로 선택한 후, 고정된 아래/위 버튼을 눌러 순서를 변경해서 이슈를 해결한 경험이 있습니다.
24. 팝업은 한 개만 출력하자.
서비스 기획에서 불문율처럼 내려오는 가이드 중 하나입니다.
백오피스에서도 적용하는 것이 좋습니다.
팝업이 두 개가 열린 경우, 앞서 열린 팝업이 먼저 닫히고 뒤에 열린 팝업이 서비스 적용이 되는 경우라든지, UI 및 개발 상으로 이슈가 발생할 소지가 많은 기획이기에 회피하는 것이 좋습니다.
25. 복사 기능을 넣자.
11번의 예약 배포 기능이 활발하게 적용되는 서비스의 경우, 원래 있던 메뉴의 순서가 시간대에 다이내믹하게 변경될 수 있습니다. 기존의 노출 시간 적용 및 노출 순서 변경으로 손쉽게 적용이 되면 좋겠지만, 두 가지 기능을 원하는 대로 시간대에 맞춰 설정하는 백오피스 기능을 기획하는 것은 매우 어려운 일입니다.
기존에 배포된 요소를 그대로 복사하여, 운영의 편의성을 더해준다면 운영기획의 편의성을 증대할 수 있습니다. (다만 계속해서 쌓이는 가비지 데이터를 주기적으로 정책을 잡아 제거하는 작업이 필요할 수 있습니다.)
이렇게 포인트들을 살펴보았습니다.
하지만 글로만 살펴보기에 배포 기능 및 예약 배포 기능 같은 경우에는 어떻게 구현해야 할지 막막해 보일 수도 있을 것입니다. 근시일 내에 위 기능의 백오피스 화면을 새롭게 기획하여 보충하는 포스팅을 올려보도록 하겠습니다.
그리고 이렇게 팁들을 읽어도, 잘 만들어 놓은 백오피스 시스템을 경험하여 레퍼런스를 흡수하는 것만큼 학습이 빠르지 않습니다. 이 글을 읽는 기획자 분들 모두 좋은 백오피스 시스템을 갖춘 회사로 점프업 하시길 바라겠습니다.
