동아리와 프로젝트를 진행하면서, 다양한 문서들을 작성 및 관리하는 과정에서 경험했던 내용들을 기반으로 지정 템플릿의 만들어 활용하는 것이 앞으로 효율적이라고 판단했다. 기존에 활용했었던 템플릿들에서 만족했던 부분과 주변인들의 템플릿 등을 받아서 종합해보았다.
아래는 템플릿에서 파트별 설명을 이미지와 함께 작성해봤다.
(다크모드에 익숙하여, 모든 캡처가 다크모드인 것은 양해바란다.)
메인 페이지
먼저 메인 페이지다. 메인 페이지에서는 상단의 공통 외부/팀별/공통 내부/바로가기로 분류된 문서파트와 하단의 프로젝트 전체 일정에서 주요 이벤트와 관련내용을 정리하는 일정 관리 파트로 작성되어 있다
바로가기
바로가기는 서비스 개발 프로젝트를 기준으로 하여, 운영 과정에서 활용하는 다양한 서비스들의 링크를 모아서 관리하는 것을 목표로 한다.
바로가기로 등록할 수 있는 링크, 즉 팀 전원이 활용할 수 있는 링크들의 예시로는 아래와 같다.
- 피그마: 기획자들이 기획서/페르소나/유저 플로우 등 피그마를 활용할 경우가 많고, 디자이너들이 주로 작업이 진행되는 공간이기에 팀 전체의 접근 빈도가 높다.
- 카카오톡 채널: 카카오톡 채널의 관리자 센터로, CS 접수 창구를 카카오톡 채널을 이용할 경우 활용 빈도가 높다.
- 채널톡: 채널톡은 AI를 활용한 메신저로 고객 상담 및 자동 응대 등 다양한 강점을 가지고 있어 CS 접수 창구로의 활용 빈도가 높다.
- Slack: 슬랙은 팀 채널로 많이 활용되며, 파트별 채널 분리 및 권한 제어, 슬랙 봇을 활용한 알림 등 다양하게 활용할 수 있는 좋은 수단이다. 다만 무료요금제는 데이터가 90일만 유지된다는 게 아쉬운 점이다.
공통 외부
프로젝트 소개
프로젝트 소개 페이지는 동아리/사이드 프로젝트 등의 특정 목적을 기반으로 구성되었을 경우, 해당 프로젝트의 방향성 또는 프로젝트의 목표를 정리하는 페이지다. 해당 페이지는, 사실 서비스 개발 및 운영이 목적인 경우에는 필요성이 낮아, 필요하지 않다면 사용하지 않고 삭제해도 무방하다.
서비스 소개
서비스에 대한 원 페이지 소개서를 작성하는 페이지다. "우린 어떤 서비스다." 를 간결하게 알려주는 것을 목표로 한다. 이는 랜딩 페이지와 동일하게 간주될 수 있다. 웹 서비스의 경우, 랜딩 페이지를 분리하여 운영하는 것은 쉬운 편이나 앱 서비스의 경우에는 웹을 별도로 개발하는 것에 코스트가 존재하므로 노션 + 우피의 조합을 통해서 상대적으로 손쉽게 랜딩 페이지로 해당 페이지를 활용해도 된다.
노션 + 우피 조합의 랜딩 페이지 예시를 첨부한다.
팀 소개
팀 소개 페이지의 목적은 크게 두 가지로 생각하고 만들었다.
1. 최초 팀 구성 시, 서로에 대한 기본 정보를 파악하기 위한 목적
최초 팀 구성 시, 구면인 경우도 있지만 초면인 경우도 분명히 존재할 것이다. 이 때, 가볍게 서로를 알 수 있는 정보들을 작성하여 기본적인 정보를 파악하는데 활용할 수 있다.
2. 외부와 MOU 등의 협업 진행 시, 구성원 소개를 위한 페이지
실제로, 서비스를 개발 및 운영하는 과정에서 외부와 협업 또는 미팅 등이 진행될 수 있다. (굉장히 잘 풀어나가고 있다는 의미다.) 이럴 때에는, 팀 구성원에 대한 정보를 전달해야 할 경우 활용할 수 있다.
위의 두 가지 목적 중, 팀의 목적과 부합하는 방향으로 기입 정보를 추가 및 삭제하면서 활용하면 좋을 것이다.
개인정보 처리방침
개인정보 처리방침의 필요성
| 개인정보보호법 제2조 제5호 | 개인정보보호법 제30조 제1항 |
|---|---|
| 5. "개인정보처리자"란 업무를 목적으로 개인정보파일을 운용하기 위하여 스스로 또는 다른 사람을 통하여 개인정보를 처리하는 공공기관, 법인, 단체 및 개인 등을 말한다. | ① 개인정보처리자는 다음 각 호의 사항이 포함된 개인정보의 처리 방침(이하 "개인정보 처리방침"이라 한다)을 정하여야 한다. 이 경우 공공기관은 제32조에 따라 등록대상이 되는 개인정보파일에 대하여 개인정보 처리방침을 정한다. |
(출처: ‘개인정보 처리방침’ 이란?)
위의 법에서 안내하듯이, 개인정보파일을 처리하게 된다면, 개인정보처리방침에 대한 고지는 필수적이다.
고지 주의사항
- 웹 서비스: 개인정보 처리방침을 홈페이지에 계속 공시하여야 함.
- 앱 서비스: 앱 내에서 지속적으로 개인정보 처리방침을 게시하여야 함.
- "개인정보 처리방침"이라는 명칭을 활용하여 게시하여야 함.
- 개인정보 처리방침 변경 시, 이전 버전도 확인이 가능하게 변경이력을 포함하여야 함.
(출처: 개인정보 처리방침 공개, 이런 것도 법으로 정해져 있다고?)
어떻게 만들 수 있는데?
이미지에도 첨부되어 있는 개인정보 처리방침 만들기를 통해 작성지침을 확인할 수 있다. 23년도 하반기까지만 해도 해당 페이지 내에서 손쉽게 제작이 가능했는데, 어느새부턴가 해당 기능은 사라진 상황이다. 그렇기에, 구글 검색 등 기존 제작된 포맷을 가져와 변경하거나, 작성 지침을 기반으로 새로 만들어야 한다.
서비스 이용약관
서비스 이용 약관은 사용자들에게 공시해야만 그 효력이 발생하기 때문에, 사용자와 서비스 제공자 간 문제 발생 시 관련 책임을 명확하게 하기 위한 용도로 공시하는 것이 좋다. 찾아본 결과, 양식을 명확히 정의하기는 어려울 것으로 보여, 기입하면 좋을 내용과 참고할 수 있는 약관 사이트를 첨부한다.
기입하면 좋을 내용
- 서비스 목적
- 약관의 효력
- 관련 용어 정의
- 회원가입 존재 시, 계정 이용과 관련된 내용
- 서비스 기능과 관련된 내용
- 공고 날짜 및 수정 날짜 등
이용 약관 참고 서비스
공통 내부
전체 회의록
팀 전체의 회의록을 작성 및 관리하는 페이지이다.
팀 전체가 참여하는 회의를 기반으로, 2개 이상의 파트가 함께 회의를 진행하게 될 경우, 해당 페이지에서 기록하여 모든 파트의 인원들이 확인할 수 있도록 해야 한다.
활용 방법
- 관련된 일정 존재 시, 메인 페이지의 일정 리스트 및 캘린더와 연동 가능
- 기획팀 자체 회의와 연동될 경우, 기획팀의 OKR 페이지와 연동 가능
서비스 운영 지표
실제로 서비스가 런칭되고 나서, KPI를 지속적으로 파악하고 있어야 한다.
KPI란?
KPI는 Key Performance Indicator의 약자로, 핵심 성과 지표라는 의미를 담고 있습니다.
하단의 이미지와 같은 별도의 페이지를 통해서 관리하는 것이, 서비스의 성장세 또는 핵심 기능이 유효하게 동작하고 있는지를 확인할 수 있을 것이다.
다만, 서비스 운영 지표를 관리하는 위 방식은 사람이 꾸준하게 확인 및 기입을 진행해야 하므로, 제품 분석(Product Analysis) 툴을 사용하는 것을 병행하는 것을 추천한다.
제품 분석 툴이라고 부르는 것이 맞지 않는 경우도 있지만, 정보 전달을 위해 통칭한다.
제품 분석 툴
필자는 믹스 패널을 제외한, GA와 Amplitude를 사용한 경험이 있다. GA는 무료 모델의 제일 기본적인 기능만 사용했었기에, 크게 효과적이게 사용하지 못했지만, Amplitude에서는 퍼널 설정을 통해 사용자의 서비스 이용 과정에서 이탈 위치를 파악하고 개선 방향성을 찾아내는 과정을 진행했었기에 Amplitude를 조금 더 좋아한다.
세 종류의 분석 툴을 비교하여 정리한 글을 첨부한다.
유저 피드백 리스트 정리
위의 카카오톡 채널, 채널톡을 바로가기에서 등록해놓았듯이, 사용자의 기능 추가 요청 또는 개선사항 등을 정리해서 활용해야 한다.
이 템플릿에서는 유저의 피드백 리스트를 다 기입해놓는 섹션과 해당 피드백을 반영했을 경우, 반영 완료 섹션으로 모아서 관리할 수 있도록 만들어 놓았다.
정리하는 내용은 아래와 같다.
- 접수 플랫폼: 피드백을 접수하는 창구가 다양할 경우, 창구별로 정리의 필요성이 있다.
- 내용: 실질적인 피드백 내용을 기입한다. 해당 내용이 자세할 경우, 페이지를 열어 관련된 부분을 세부적으로 작성한다.
- 서비스 버전: 사용자가 사용하고 있는 서비스의 버전에 따라 피드백이 달라질 수 있으므로, 서비스 버전을 기입한다.
- 날짜: 피드백이 들어온 날짜를 기입한다.
- 업데이트 반영 여부: 해당 피드백을 업데이트에 반영할 것인지에 대한 판단 여부를 기입하고, 만약 반영하기로 결정하였다면 반영 예정/반영 중/반영 완료로 나누어서 상태를 관리한다.
운영 관련 장애 및 개선사항
바로 위 목차에 적혀 있는 유저 피드백에 더해 운영 중 발생한 장애 및 개선사항을 정리하는 페이지이다.
유저 피드백을 기반으로 개선사항을 추가할 수도 있으며, 별도의 모니터링 툴 또는 사용 중 발생한 장애 연락을 명확하게 정리하여, 반영할 수 있도록 한다. 현재는 중요도 정보를 새로 추가하여, 중요도에 따라 개발 우선순위를 관리할 수 있도록 하고 있다.
중요도 (숫자가 높을수록 중요한 업무)
- 1: 개발하지 않아도 되나 최후순위 개발 업무
- 2: 개발해야 하나 후순위 개발 업무
- 3: 개발 필요
- 4: 개발해야 하며, 선순위 개발 업무
- 5: 긴급한 사항으로, 당장 개발 진행 필요
QA List
버전이 업데이트 될 때마다 기존 버전과의 충돌은 없는지 새롭게 추가되거나 수정된 기능의 문제는 없는지 테스트를 거쳐야 합니다.
QA를 작성할 때, 분류를 잘해야 하는데, 이는 관점이 페이지 단위이냐 기능 단위로 접근하냐에 따라 분류가 달라질 수 있습니다. 접근하는 방식을 구분하지 않는다면, 동일한 기능을 계속 테스트하게 될 수도 있습니다.
예를 들자면, 인증이라는 기능적 관점에서는 아래와 같이 분류될 수 있습니다.
- 인증
- 회원가입
- 카카오 로그인
- 애플 로그인
- 로그인
- 로그인
- 로그아웃
페이지에서는 아래와 같이 분류해볼 수 있습니다.
- 메인 페이지 (비 로그인 상황)
- 로그인 버튼 클릭
- 애플 로그인
- 카카오 로그인
(필자 또한 QA를 잘 아는 사람이 아님을 감안하고 읽어주세요. 더 좋은 예시 또는 개선사항이 있다면 바로 반영할 예정입니다.)
예산 사용 목록
서비스를 운영하는 과정에서는 다양하게 예산이 사용될 수 있습니다. 이러한 예산을 투명하게 관리하는 것은 꼭 필요한 일입니다.
보통 사용되는 예산으로는 서버비용, 마케팅 비용, 이벤트 진행 시 경품 지급 비용 등이 있을 수 있습니다.
예산을 관리하는 과정 중 제일 중요한 부분은 지출 여부 칼럼입니다.
지출 여부 칼럼은 아래와 같은 상태값을 가지고 있습니다.
- 승인 예정: 예산을 사용하겠다고 올려놓은 상태, 팀 내 예산 사용 여부 미결정
- 승인 완료: 예산을 사용하는 것으로 팀 내 결정된 상태
- 결제 예정: 예산 승인이 된 상태에서, 아직 결제가 이루어지지 않은 상태
- 결제 완료: 예산 승인이 된 상태 및 결제가 완료 된 상태
- 정산 예정: 예산 승인 및 결제 완료 상태에서 팀 내 정산이 이루어지지 않은 상태
- 정산 완료: 예산 승인 및 결제 완료 상태에서 팀 내 정산이 완료된 상태
- 증빙 첨부 예정: 예산 승인 및 결제 완료 상태에서, 증빙 자료가 첨부되어 있지 않은 상태
- 증빙 첨부 완료: 예산 승인 및 결제 완료 상태에서, 증빙 자료가 첨부된 상태
위 8가지 상태값에서 팀 내 상황에 맞추어 상태값을 추가 또는 삭제하여 예산 사용을 명확하게 관리할 수 있습니다.
서버비용과 같이 월 결제 비용이면서 비용이 명확하게 딱 결정되지 않는 경우는 결제 예상치를 기반으로 예산을 집행하는 방식으로 진행하면 좋을 것 같습니다.
접속 재원
접속 재원은 팀 공식 계정 등을 정리해놓는 페이지입니다. 게정의 비밀번호 변경 등의 특이사항을 해당 페이지에 관리한다면, 계정을 조회하기 위해 별도의 연락을 최소화할 수 있습니다.
업데이트 노트
업데이트 노트는, 서비스의 업데이트 버전 및 날짜 등을 정리해놓는 페이지입니다. 배포하는 플랫폼 및 담당자를 명시함을 통해, 배포 과정에서의 문제상황(Ex: 앱 심사 거절) 등을 정리하고 해결할 때 도움을 줄 수 있습니다. 또한, 여기서 기입된 서비스 버전은 유저 피드백 또는 운영 관련 장애 및 개선사항과 같은 페이지에서 기입되는 버전명을 의미합니다. 또한 버전별 업데이트 사항을 명확히 기입해놓는다면, 앱 스토어의 버전별 기록을 기입할 때 도움을 줄 수 있으며, 기획자/마케터가 업데이트 관련 사용자 모집 과정에서 활용할 수 있습니다.
팀별
기획팀
기획을 전문적으로 하지 않아, 작성할 내용이 많지는 않지만, 정리해놓으면 좋을 것 같은 내용들을 정리해보았다.
비즈니스 모델 캔버스를 추가했다.
비즈니스 모델 캔버스는 비즈니스에 포함되어야 할 9개의 주요 정보들을 모아서 관리하는 그래픽 템플릿이다. 템플릿 활용방법은 브런치 글을 통해 자세히 알아볼 수 있다.
백엔드팀
백엔드 팀은 기본적으로 필요한 정보들만 명시해놓았다.
ERD 설계 시 사용할 수 있는 사이트는 아래와 같다.
API 명세서 템플릿은 굉장히 다양하므로 별도로 제작하지는 않았다. 검색 후 원하는 템플릿을 가져와서 사용하면 좋을 것 같다. 구글 검색 시 나오는 예시 노션 템플릿을 몇 개 첨부한다.
인프라의 경우, 피그마 또는 PPT로 작업을 하는 편인데, 공식 아이콘등을 모아놓은 사이트를 첨부한다.
Issue/PR 템플릿을 추가했다.
적용 방법도 작성해놓았으므로, 프로젝트 내에서 작성할 내용을 변경 또는 추가해서 사용하면 된다.
이외에, 네이밍 컨벤션, 코드 리뷰 방식, Monitoring 또는 BI 툴 등 다양한 내용들을 추가하여 관리하면 좋을 것이다.
- 프론트엔드팀은 필자가 백엔드 개발을 주로 하다보니, 필요한 페이지들이 무엇일지 몰라 제작하지 않았다.
- 디자인 파트는 대부분 피그마에서 작업이 진행되다 보니, 주요 정보들을 어떤 형식으로 템플릿으로 관리하는 것이 좋을지 몰라 별도의 템플릿을 제작하지 않았다.
프론트엔드, 디자인 템플릿으로 추천하고자 하는 내용들을 발견하면 지속적으로 업데이트할 예정이다. 이외에도 개선 또는 추가되었으면 하는 내용들을 발견하면 이 또한 지속적으로 업데이트할 예정이다.
업데이트 내역
24. 04. 18: 프로젝트 템플릿 1차 제작
24. 05. 12: 운영 관련 장애 및 개선사항 템플릿에 중요도 칼럼 추가
24. 06. 23: 기획팀의 비즈니스 캔버스 모델 템플릿 추가, 개발팀 Github Template 추가
