한 줄 요약
여러 도구에 흩어진 신규 부원 가입 절차를 HGM_WorkSpace로 모으기 위해 운영팀 요구사항을 조사하고, 우선순위와 역할·권한 구조를 설계한 과정을 정리했어요.
1. 들어가며
안녕하세요.
회기동 막걸리 인프라팀에서 HGM_WorkSpace의 서비스 기획을 맡고 있는 성은영이에요.
지난 HGM_WorkSpace #00에서는 HGM_WorkSpace를 만든 이유와 당시 개발 현황을 소개했어요.
이번 글에서는 신규 부원 온보딩을 준비하며 회원 관리와 권한 관리 기능을 기획한 과정을 다뤄보려고 해요.
운영팀의 의견을 반영하며 요구사항이 어떻게 달라졌는지, 그리고 역할과 권한의 관계를 설계하면서 어떤 문제를 만났는지 자세히 설명드릴게요.
2. 신규 부원 한 명을 등록하려면 여러 도구를 거쳐야 했어요
기존에는 신규 부원에게 카카오워크 가입을 안내하고 계정 정보를 하나씩 모았어요.
그다음 디스코드, 구글 드라이브, 아사나에 각각 회원을 등록하고 필요한 권한을 설정해야 했고요.
도구마다 회원을 따로 관리하다 보니 가입 진행 상태를 한눈에 확인하기 어려웠어요.
어느 도구까지 등록했는지, 빠진 권한은 없는지 담당자가 직접 확인해야 했거든요.
신규 부원이 늘거나 담당자가 바뀌면 챙겨야 할 일도 늘어났어요.
그래서 여러 도구에 흩어진 신규 가입 진행 상황을 HGM_WorkSpace 한곳에서 확인하고 관리하자는 방향을 잡았어요.
3. 기존 RFP만으로는 실제 운영 절차를 반영하기 어려웠어요
회원 관리 기획은 프로젝트 초기에 작성한 RFP의 요구사항에서 시작했어요.
RFP(Request for Proposal, 제안요청서)는 원래 제안에 필요한 요구사항을 전달하는 문서이고, HGM_WorkSpace에서는 초기 기능 요구사항을 확인하는 출발점으로 활용했어요.
다시 살펴보니 초기 요구사항만으로는 신규 가입 업무를 모두 처리하기 어려웠어요.
신규 부원보다 기존 부원의 정보 관리에 초점이 맞춰져 있었거든요.
운영팀이 어떤 정보를 받고 언제 확인하는지, 가입 안내 이후에는 무엇을 관리하는지 더 구체적으로 알아야 했어요.
그래서 운영팀을 대상으로 설문조사를 진행했어요.
설문에서는 신규 부원 모집에 꼭 필요한 기능과 기존 업무에서 불편했던 점을 확인했어요.
운영팀은 신규 부원이 가입 절차를 모두 밟았는지 간편하게 확인하고 싶다고 답했어요.
기존 요구사항으로는 처리하기 어려운 일이어서, 각 가입 절차의 완료 여부를 바탕으로 신규 부원의 가입 진행 상태를 자동으로 확인할 수 있는 기능을 RFP에 추가했어요.
기능 목록만 보고 기획할 때는 보이지 않았던 일이 실제 업무 과정을 확인하면서 드러났어요.
회원 정보를 저장하는 것뿐 아니라 가입 절차가 어디까지 진행됐는지도 확인할 수 있어야 했어요.
4. 온보딩이 시작되기 전에 구현해야 했어요
요구사항을 보완한 뒤에는 우선순위를 다시 정해야 했어요.
신규 부원 온보딩이 시작되기 전까지 실제로 사용할 수 있는 기능을 구현해야 했거든요.
모든 요구사항을 한 번에 구현할 수는 없었어요.
그래서 기능을 P0, P1, P2로 구분했어요.
P0는 이번 온보딩 일정에서 빠지면 실제 운영이 어려운 최우선 요구사항으로 정의했어요. P1과 P2는 필요하지만 이번 일정 이후에도 보완할 수 있는 후순위 요구사항으로 분리했고요.
회원 관리와 권한 관리 모두 P0 범위를 먼저 구현하기로 결정했어요. 판단 기준은 단순했어요.
- 이번 신규 가입 과정에서 실제로 사용하는가
- 이 기능이 없으면 운영팀의 업무가 중단되는가
- 당장은 기존 방식이나 수작업으로 대응할 수 있는가
- 운영 정책이 충분히 합의되어 있는가
설문 응답을 바탕으로 기존 RFP에 없던 요구사항을 추가하고 P0·P1·P2 우선순위를 다시 정했어요.
이 기준에 맞춰 요구사항을 정리하고, 온보딩에 필요한 범위부터 개발하도록 기획을 조정했어요.
5. 가장 오래 막힌 건 권한 구조였어요
회원 관리의 기본 흐름을 정리한 뒤 권한 관리로 넘어갔어요.
처음에는 회원에게 필요한 권한을 부여하기만 하면 된다고 생각했지만, 실제 구조를 정의하는 일은 예상보다 복잡했어요.
처음에는 직무와 직책에 권한을 직접 연결하려고 했어요.
그런데 권한 차이에 따라 직무를 나누다 보니 역할이 너무 많아지고 예외 관리도 복잡해졌어요.
그래서 회원의 소속·직무·직책 조합으로 시스템상의 역할(Role)을 결정하고, 역할 → 권한 세트 → 기능 권한으로 연결하는 구조로 정리했어요.
- 역할(Role)은 소속·직무·직책을 바탕으로 시스템에서 권한을 부여하기 위해 사용하는 단위예요.
- 권한 세트는 특정 역할에 필요한 권한을 하나로 묶은 단위예요.
- 기능 권한은 특정 화면을 보거나 기능을 실행할 수 있는 개별 권한이에요.
회원마다 기능 권한을 직접 부여하는 방식은 초기에는 단순하지만, 인원과 기능이 늘수록 권한을 받은 이유와 변경 기준을 추적하기 어려워져요.역할이 바뀔 때마다 권한을 일일이 수정해야 하고요.
역할과 권한 세트를 지나치게 나눠도 관리가 어려워질 수 있었어요.
특히 한 회원이 여러 역할을 맡을 때 각 역할의 권한을 합칠지, 충돌하는 권한은 어떻게 처리할지, 역할이 사라졌을 때 어떤 권한을 회수할지 결정하는 일이 까다로웠어요.
기본 구조와 예외 처리 방식을 함께 고민하면서 권한 관리 기획에 예상보다 많은 시간이 들었어요.
6. 처음부터 너무 넓은 범위를 잡았어요
기획 범위도 시간이 오래 걸린 이유 중 하나였어요.
초기 기획 범위에는 P0뿐 아니라 이미 P1과 P2로 분류했던 기능까지 포함했어요.
언젠가 필요할 기능이니 처음부터 함께 고려해야 전체 구조를 제대로 만들 수 있다고 생각했거든요.
하지만 모든 상황을 한 번에 해결하려다 보니 결정해야 할 항목이 계속 늘어났어요.
당장 온보딩에 필요한 문제와 나중에 검토해도 되는 문제를 같은 무게로 다루면서 일정도 늦어졌고요.
다시 “이번 온보딩에 꼭 필요한가”를 기준으로 범위를 좁혔어요.
P0에 해당하는 범위의 흐름을 먼저 확정하고, P1과 P2는 향후 확장할 수 있도록 기본 구조만 고려하고, 세부 동작 정의와 구현은 이후 과제로 미뤘어요.
처음부터 모든 예외를 해결하기보다, 이번 온보딩에서 실제로 운영할 수 있는 기본 구조를 먼저 만드는 편을 선택했어요.
범위를 줄인 뒤에는 회원 관리와 권한 관리의 P0 기능부터 구현했어요.
운영팀 설문에서 나온 요구사항을 반영하고, 역할·권한 세트·기능 권한으로 이어지는 구조도 마련했어요.
HGM_WorkSpace 안에서 이번 온보딩에 필요한 회원 관리와 기본 권한 부여 절차를 처리할 기반이 생겼어요.
이번 구현이 회원·권한 관리의 모든 상황을 처리한다는 뜻은 아니에요.
P1과 P2로 미룬 기능이 있고, 실제 운영 과정에서 새로운 예외가 발견될 수도 있어요.
이번에 만든 구조는 운영을 통해 검증해야 하는 첫 번째 구조에 가까워요.
7. 권한 설계는 조직을 다시 이해하는 과정이었어요
이번 기획을 하면서 권한 구조를 정하려면 먼저 조직의 운영 방식을 이해해야 한다는 걸 배웠어요.
유지보수하기 쉬운 권한 체계를 만들려면 먼저 조직에 어떤 역할이 있고, 각 역할이 어떤 책임을 맡으며, 어디까지 접근할 수 있어야 하는지 알아야 했어요. 권한 구조를 설계하는 과정은 동아리의 운영 방식을 시스템의 언어로 다시 정리하는 과정이었어요.
역할과 권한 세트를 나눌 때도 처음 권한을 부여하는 방법만 생각해서는 부족했어요.
담당자가 바뀌거나 필요한 기능이 늘어나면 어디를 수정해야 하는지도 고려해야 했거든요.
변경이 생겨도 관리하기 쉬운 구조인지도 함께 고민하게 됐어요.
또 하나 배운 점은 우선순위가 곧 실제 기획 범위가 되어야 한다는 것이었어요.
앞으로는 P0의 완료 조건부터 먼저 정하고, 후순위 요구사항은 실제 운영에서 얻은 근거를 바탕으로 확장하려고 해요.
8. 다음은 화면을 다듬을 차례예요
이번 개발에서 회원·권한 관리의 기본 화면까지 구현을 마쳤어요.
다음에는 현재 회원의 역할·권한 세트·기능 권한을 사용자가 한눈에 이해할 수 있도록 화면 구조를 개선하려고 해요.
역할과 권한 세트의 관계, 현재 부여된 권한을 어떻게 보여줄지 살펴볼 예정이에요. 복잡한 구조를 화면에 어디까지 드러낼지도 고민해야 하고요. 이후에는 일정 관리 기능의 기획도 이어갈 계획이에요.
다음 글에서는 회원·권한 관리 화면을 개선하며 어떤 선택을 했는지 기록해 보려고 해요.
권한 관리 화면에서 역할이나 접근 권한을 확인할 때 헷갈렸던 점이 있다면 댓글로 알려주세요.
'Project > HGM_WorkSpace' 카테고리의 다른 글
| [HGM_WorkSpace #00] 동아리 협업툴을 직접 만들었어요 - 노션·아사나·카카오워크를 하나로 (0) | 2026.07.13 |
|---|
