배경
- 2023년 9월 openpath.kr 오픈 당시 어드민은 일부 기능만 동작
- VOD 등록, 회원 조회, 결제 확인은 건마다 개발사에 요청해 처리
- 초기 기능 정의서로 개발 중이었지만 실무에 쓰기에는 부족한 기능이 많음
서비스 기획 · 어드민
운영 어드민 구축 ✅
목표
- 운영 담당자가 VOD 등록, 회원 관리, 결제 확인을 개발사 요청 없이 직접 처리
- 12월 운영 시작 전까지 관리 메뉴 12개의 기능을 모두 테스트하고 오류 수정
- 새 담당자도 바로 쓸 수 있는 어드민 사용 가이드 마련
업무
- 초기 정의서를 바탕으로 기능 보완 요청서 작성과 개발사 커뮤니케이션
- 디자이너 2명과 메뉴를 나눠 QA 리딩, 12개 메뉴 중 절반 이상 직접 담당
- 테스트 시나리오로 검수하고 실서버 패치 일정 조율
- 알림톡 템플릿 정리·등록, 관리자 가이드 작성
성과
- VOD 등록, 회원 관리, 결제 확인을 개발사 요청 없이 직접 처리
- QA 이슈 639건을 운영 시작 전 전부 정리, 월 신규 이슈 10월 315건 → 12월 8건
- 관리자 가이드로 신규 담당자 인수인계
- 2023년 12월부터 실제 운영, 3년째 사용 중
Background
배경
1. 서비스 맥락 및 프로젝트 배경
오픈패스는 디자이너 대상 교육 플랫폼으로, 2023년 9월 openpath.kr을 오픈했습니다. 오픈 시점 어드민은 1:1 문의 응대 등 일부 기능만 동작했고, 나머지는 디자이너가 작성한 초기 기능 정의서를 바탕으로 개발사가 만들고 있었습니다. 저는 9월부터 디자이너 2명과 함께 어드민 구축을 맡아서 리딩을 진행하였습니다.
2. 구축 전 운영 방식 (As-Is)
- VOD 등록: 영상 파일과 강의 정보를 엑셀로 정리해 개발사에 전달하면 개발사가 등록
- 회원 정보 확인: 회원 상태와 수강 정보를 볼 화면이 없어 건마다 개발사에 요청
- 결제 확인: 결제 데이터를 개발사에 요청해 받음
- 기능 정의: 초기 정의서는 메뉴와 기능 목록 위주라 조회 조건, 수정 가능 범위 같은 세부 항목이 비어 있음
Tasks
진행 업무
- 1. 기능 보완 요청서 작성초기 기능 정의서로 개발된 어드민을 메뉴별로 검토해 수정·추가 요청을 정리하고 개발사에 설명
- 2. QA 리딩과 실서버 반영3인의 메뉴별 담당과 일정을 정하고, 테스트 시나리오 기반 QA부터 실서버 패치 확인까지 관리
- 3. 알림톡 템플릿 정리와 등록발송 케이스별 템플릿을 정리해 알림톡 업체에 등록하고, 개발사가 같은 템플릿을 어드민에 올리도록 전달
- 4. 관리자 가이드 작성메뉴별 사용법과 상품 등록 절차를 화면 캡처와 함께 노션 가이드로 정리
How
항목별 세부 업무
1. 기능 보완 요청서 작성
2023.09 ~ 10
배경
- 초기 구축 담당 디자이너가 작성한 기능 정의서로 어드민이 개발됐으나, 실무에 쓰기에는 조회 조건 등 기능적으로 부족한 부분이 있었음
진행 업무
- 쇼핑몰과 교육 플랫폼 어드민을 참고하고, 인프런 지식공유자 계정을 만들어 판매자 어드민 구조를 확인
- 개발된 어드민을 메뉴별로 직접 써 보며 수정·추가가 필요한 기능을 한 건씩 정리
- 디자이너 2명과 메뉴를 나눠 요청서를 작성하고, 전체를 검토해 개발사에 설명
결과
- 개발사 미팅에서 수정·추가 요청 약 380건 전달
- 회원 조회 결과에 구매 상품, 총 결제 금액, 작성 글 수가 추가되고, 회원 정보 엑셀 다운로드 항목이 정해짐
2. QA 리딩과 실서버 반영
2023.10 ~ 12
배경
- 관리 메뉴 12개와 하위 메뉴를 3인이 12월 운영 시작 전까지 검수해야 함
진행 업무
- 메뉴마다 담당자를 정해 3명이 나눠 검수하고, 회원, 메시지, 통계, SEO 등 절반 이상은 직접 담당
- 이슈는 한 장에 한 건씩 발견, 수정, 최종 확인 날짜와 담당자를 기록하고, 주마다 모아 개발사 미팅에서 수정 요청
- 테스트 서버에서 확인한 수정 사항을 모아 실서버 패치 일정을 개발사와 조율하고, 패치 뒤 실서버에서 다시 확인
결과
- QA 이슈 639건을 개발사에 전달하고, 운영 시작 전 모두 수정 확인 또는 보류로 정리
- 월 신규 이슈 10월 315건 → 11월 229건 → 12월 8건
3. 알림톡 템플릿 정리와 등록
2023.10 ~ 11
배경
- 결제와 환불 안내는 회원이 놓치면 바로 문의나 분쟁으로 이어지는 정보라, 처리 즉시 확인율이 높은 카카오 알림톡으로 자동 발송하는 구조가 필요
- 알림톡은 업체 검수를 통과한 템플릿으로만 보낼 수 있어, 운영 시작 전에 발송 케이스와 문구를 모두 확정해야 함
진행 업무
- 발송 케이스별 템플릿 코드, 내용, 버튼, 발송 조건을 시트로 정리
- 정리한 템플릿을 알림톡 업체(비즈톡)에 등록해 검수 승인을 받고, 개발사가 같은 내용을 어드민에 올리도록 전달
결과
- 운영 시작부터 가입, 결제, 환불, 심사 결과 등의 알림톡을 자동 발송
4. 관리자 가이드 작성
2023.11 ~ 12
배경
- 사용법 문서가 없어 어드민을 다룰 줄 아는 사람은 구축에 참여한 3명뿐이었고, 운영 시작 뒤에는 여러 담당자가 같은 방식으로 상품을 등록하고 관리해야 했음
진행 업무
- 메뉴별 하위 페이지 13개로 가이드를 구성하고, 단계 번호, 실제 화면, 주의 표시 같은 작성 규칙을 먼저 정해 같은 형식으로 작성
- 상품 등록은 VOD, 멤버십 전용 VOD, 세미나 유형별로 단계 절차와 화면을 붙여 자세히 작성
결과
- 운영 시작에 맞춰 팀에 공유하고, 이후 합류한 기획자에게 인수인계 자료로 전달
Result
결과
구축 시점
운영 시작
2023년 12월
착수 후 약 4개월, 관리 메뉴 12개
월 신규 이슈
315 → 8건
10월 → 12월 (11월 229건)
QA 이슈 처리
639건
운영 시작 전 수정 확인 또는 보류로 전부 정리
구축 전후 (현재 3년째 사용 중)
| 업무 | 구축 전 | 현재 |
|---|---|---|
| VOD 등록 | 영상과 강의 정보를 개발사에 보내 등록 요청 | 운영 담당자가 어드민에서 직접 등록 |
| 회원 조회·관리 | 건마다 개발사에 요청 | 조회, 상태 변경, 쿠폰 지급을 직접 처리 |
| 결제 확인 | 개발사에 데이터를 요청해 받음, 정산 불가 | 결제 이력과 통계로 상품별 결제 확인 |
| 환불 처리 | 결제사에서 건별 처리 | 사유 확인, 부분·전체 환불, 신청 취소까지 어드민에서 처리 |
| 신규 담당자 교육 | 사용법 문서 없음 | 관리자 가이드로 인수인계 |
Decisions
주요 결정
1. 테스트 시나리오 기반 QA로 전환
10월 초에는 메뉴 구성이 자주 바뀌어, 시나리오 문서 없이 페이지를 하나씩 눌러 보며 테스트했습니다. 이 방식으로는 확인하지 못한 기능이 남았고, 수정 완료로 처리한 이슈가 패치 뒤 다시 나타났습니다. 문서를 쓰는 데 시간이 들더라도 메뉴별 조작 순서와 예상 결과를 정리한 시나리오를 만들고, 이를 기준으로 QA를 다시 진행했습니다.
2. 대시보드 대신 결제 통계 우선 반영
개발 일정상 어드민에 대시보드와 결제 통계를 모두 넣을 수는 없었습니다. 당시 결제 데이터는 건마다 개발사에 요청해 받아야 해서, 상품별 성과 확인과 정산이 모두 막혀 있었습니다. 운영에 바로 필요한 결제 통계를 먼저 넣고, 방문과 유입 지표는 GA로 확인하기로 했습니다.
3. 상품 등록 중심의 관리자 가이드 작성
모든 메뉴를 같은 깊이로 쓰면 운영 시작 전에 가이드를 내놓기 어려웠습니다. 상품 등록은 콘텐츠 등록부터 전시까지 순서가 정해져 있고, 콘텐츠는 한 번 등록하면 삭제할 수 없어 실수했을 때 되돌리기 가장 어려운 작업이었습니다. 이 작업부터 VOD, 세미나 등 유형별로 Step 단위 절차와 화면을 붙여 자세히 쓰고, 나머지 메뉴는 기본 사용법만 먼저 정리했습니다.
Retrospective
배운 점과 아쉬운 점
변경이 잦을수록 먼저 필요한 테스트 시나리오
메뉴가 계속 바뀌어 시나리오를 미뤘지만, 실제로는 메뉴가 바뀔수록 패치가 잦아져 이미 확인한 기능이 되돌아오는 일을 잡아낼 기준이 더 필요했습니다. 시나리오를 만든 뒤에는 패치가 있을 때마다 같은 순서로 다시 돌려, 되돌아온 오류를 바로 찾을 수 있었습니다. 변경이 잦은 프로젝트일수록 조작 순서와 예상 결과만 담은 가벼운 시나리오를 먼저 두고, 바뀔 때마다 고쳐 쓰는 편이 낫다는 것을 배웠습니다.
QA 전에 합의해야 할 패치 내역 공유
QA 기간에 개발사는 수정 사항을 수시로 반영했지만, 언제 어느 서버에 무엇을 반영했는지는 따로 공유되지 않았습니다. 확인을 마친 이슈가 다시 나타나도 처음 확인이 잘못됐는지 패치로 서버 상태가 달라졌는지 가릴 수 없었고, 안 되던 기능이 예고 없이 고쳐져 있기도 했습니다. 개발사와 일할 때는 QA를 시작하기 전에 패치 내역을 서버별로 공유받는 방식부터 합의해야 한다는 것을 배웠습니다.
정의서 단계에서 챙겨야 할 예외 화면
쿠폰 등록 오류 안내처럼 화면 디자인에는 있었지만 개발 요청 문서에는 빠진 기능을 QA 중에 발견했습니다. 이 시점에 요청하면 기능 추가로 분류돼 반영을 장담할 수 없었습니다. 기능 정의서에는 정상 흐름뿐 아니라 오류와 예외 화면까지 담아야 한다는 것을 배웠습니다.
운영 규모에 맞춘 테스트 데이터 준비
목록이 11페이지로 넘어가지 않는 페이지네이션 오류를 QA에서 놓쳤습니다. 테스트 서버에는 데이터가 몇 건뿐이라, 100개를 넘어야 드러나는 오류는 볼 수 없었습니다. 기능을 확인하는 것만큼 실제 운영 규모의 테스트 데이터를 준비하는 일도 QA 계획에 넣어야 한다는 것을 배웠습니다.
아쉬운 점: 사용자 행동 데이터 부재
결제 통계로 상품별 결제는 볼 수 있지만, 회원이 어떤 경로로 들어와 어느 단계에서 이탈하는지 보는 퍼널이나 행동 추적 기능은 없습니다. 유입은 GA로 따로 보고 있어, 결제 데이터와 행동 데이터를 한 흐름으로 이어 보기 어렵습니다.
다른 프로젝트
서비스 기획 · 플랫폼 런칭
교육 플랫폼(openpath.kr) 런칭
서비스 기획 · 페이지·어드민
기업 교육 페이지와 어드민 구축
서비스 기획 · 페이지·어드민
이벤트 페이지와 어드민 구축
안재찬 · asa0677@naver.com