이 글의 순서
핵심 내용
앱을 운영하면 `로그인이 안 된다`, `버튼 위치를 바꿔 달라`, `필터를 추가해 달라`, `통계를 내려받고 싶다` 같은 요청이 한 목록에 쌓입니다. 모두 중요해 보여도 한 번에 처리할 수는 없습니다.
우선순위의 목적은 가장 많은 요청을 빨리 끝내는 것이 아니라 사용자와 운영에 큰 손실을 만드는 문제를 먼저 줄이고, 다음 배포에서 확인할 결과를 분명히 하는 것입니다.
먼저 장애·오류·사용성·기능 요청을 구분하세요
요청 이름이 아니라 기대 결과와 실제 상태를 기준으로 나눕니다.
이 구분은 비용을 결정하기 위한 계약 분류와도 연결되지만, 여기서는 `무엇을 언제 처리할지`를 정하는 데 사용합니다. 무상 오류와 유상 개선의 범위는 앱 유지보수 계약 가이드에서 별도로 확인할 수 있습니다.
확인해보세요
- 장애: 다수 사용자가 핵심 기능을 사용할 수 없거나 데이터·결제·보안 위험이 진행 중임
- 오류: 합의한 환경과 기능에서 기대 결과와 다르게 동작함
- 사용성 문제: 기능은 동작하지만 사용자가 찾거나 이해하기 어려워 반복해서 실패함
- 기능 요청: 기존에 없던 조건, 화면, 데이터, 권한 또는 자동화를 추가함
- 운영 요청: 문구·콘텐츠·설정·계정처럼 개발 없이 처리할 수 있거나 운영 절차가 필요한 일
한 요청에 판단할 수 있는 정보를 모으세요
제목만 있는 요청은 크기를 비교할 수 없습니다. 다음 항목을 한 카드에 모읍니다.
기능 요청이라면 `필터 추가` 대신 누가 어떤 목록에서 무엇을 찾지 못해 어떤 업무가 지연되는지 적으세요. 해결 방법보다 먼저 문제와 기대 결과를 기록해야 더 작은 대안을 비교할 수 있습니다.
확인해보세요
- 요청한 사람과 영향을 받는 사용자 역할
- 발생한 화면·기능·앱 버전·시간
- 다시 만드는 순서와 기대 결과·실제 결과
- 영향을 받은 사용자 수 또는 운영 건수
- 결제·개인정보·주문·예약·업무 중단 여부
- 우회 방법과 현재 고객 안내
- 화면 캡처·영상·오류 기록·문의 번호
- 완료됐다고 판단할 검수 조건
사용자 영향과 발생 범위로 먼저 정렬하세요
요청 수가 적어도 결제 중복이나 개인정보 노출처럼 피해가 큰 문제는 먼저 처리해야 합니다. 반대로 많은 사람이 불편을 말해도 우회 방법이 있고 핵심 행동을 막지 않는다면 다음 배포로 계획할 수 있습니다.
다섯 항목을 같은 기준으로 비교해보세요.
점수를 더해 자동 결정하지 말고 비교를 위한 공통 언어로 사용합니다. 보안·개인정보·결제처럼 별도 대응 원칙이 필요한 문제는 총점과 관계없이 즉시 책임자에게 올립니다.
확인해보세요
- 영향: 사용자가 결과를 얻지 못하거나 금전·데이터 손실이 생기는가?
- 범위: 전체, 특정 역할, 특정 기기, 일부 조건 중 어디까지 영향을 받는가?
- 긴급성: 지금도 피해가 커지고 있는가, 정해진 일정 전에 필요한가?
- 근거: 재현 기록, 행동 데이터, 반복 문의가 있는가?
- 작업 크기와 위험: 수정 범위, 외부 심사, 데이터 변경과 회귀 위험은 어느 정도인가?
긴급 등급은 응답과 복구 목표를 함께 적으세요
팀이 작을수록 세세한 등급보다 누구나 같은 행동을 할 수 있는 기준이 중요합니다.
시간 약속은 계약과 운영 조건에 맞게 정해야 합니다. 중요한 것은 등급을 붙이는 것보다 최초 확인, 임시 조치, 수정, 고객 검수, 배포와 완료 안내의 담당자가 정해져 있는지입니다.
확인해보세요
- P0: 서비스 전체 중단, 결제·데이터·보안 피해가 진행 중 — 즉시 확인, 확산 방지와 복구 우선
- P1: 핵심 기능을 다수가 사용하지 못하고 우회가 어려움 — 같은 업무 주기 안에 영향과 계획 공유
- P2: 일부 조건의 오류 또는 반복되는 사용 실패 — 다음 배포 후보로 검수 범위와 일정 결정
- P3: 작은 표시 문제, 편의 개선, 근거가 부족한 아이디어 — 목록에 보관하고 묶어서 재검토
오류는 재현과 영향 범위, 기능은 결과와 근거로 비교하세요
오류와 새 기능을 같은 방식으로 평가하면 긴급 복구와 장기 개선이 섞입니다.
오류에서는 다음을 우선 봅니다.
기능 요청에서는 다음을 봅니다.
확인해보세요
- 핵심 행동을 막는가?
- 데이터가 잘못 저장되거나 복구가 필요한가?
- 같은 조건에서 다시 발생하는가?
- 다른 기능까지 깨질 가능성이 있는가?
- 어떤 사용자 문제를 해결하는가?
- 현재 수작업·우회 방식의 비용은 얼마인가?
- 행동 데이터와 반복 문의로 근거가 확인되는가?
- 더 작은 화면·정책·운영 변경으로 먼저 해결할 수 있는가?
- 개발 뒤 어떤 행동이 달라지면 성공인가?
목소리가 큰 한 사람과 실제 반복 문제를 구분하세요
중요 고객의 요청을 무시하라는 뜻은 아닙니다. 다만 한 요청을 전체 사용자의 요구로 확대하기 전에 역할과 상황을 확인해야 합니다.
고객 중요도, 전체 제품 개선과 계약상 약속은 각각 표시하세요. 하나의 숫자로 합치면 왜 먼저 하는지 설명하기 어렵습니다.
확인해보세요
- 같은 단계에서 여러 사용자가 멈추는가?
- 문의가 없어도 행동 데이터에서 반복 이탈이 보이는가?
- 특정 고객만 사용하는 계약 기능인가?
- 운영팀이 매번 수작업으로 같은 문제를 해결하는가?
- 요청을 반영하면 다른 사용자 흐름이 복잡해지는가?
주간 결정 회의에서는 세 가지만 확정하세요
작은 팀은 긴 회의보다 다음 세 가지 결과를 남기는 편이 좋습니다.
각 결정에는 근거 링크와 결정 날짜를 남기고, 새 정보가 들어오면 등급을 바꿀 수 있게 합니다. 보류는 거절이 아니라 지금 더 중요한 문제에 집중하기 위한 명시적인 선택입니다.
확인해보세요
- 지금 복구할 문제: 확산 방지, 담당자, 고객 안내와 완료 기준
- 다음 배포에 넣을 개선: 해결할 사용자 문제, 범위, 검수일과 확인 지표
- 보류할 요청: 지금 하지 않는 이유와 다시 볼 조건
완료는 개발자 수정이 아니라 운영 결과로 확인하세요
코드가 수정됐어도 고객이 사용하는 버전에 배포되지 않았거나 관련 기능이 다시 깨졌다면 완료가 아닙니다.
기능 요청도 화면이 생긴 것보다 사용자가 목표 행동을 더 잘 끝내는지 확인해야 합니다.
확인해보세요
- 테스트 환경에서 재현 조건이 해결됨
- 관련 권한·상태·기기에서 회귀 검수 완료
- 고객 또는 운영 담당자가 결과 확인
- 서버·관리자·앱스토어에 필요한 배포 완료
- 오류·문의·핵심 행동 지표에서 재발 여부 확인
- 변경 내용과 복구 방법 기록
우선순위 목록이 커지면 삭제 기준도 필요합니다
오래된 요청이 계속 쌓이면 중요한 일이 묻힙니다. 다음 조건이면 닫거나 다시 확인합니다.
삭제한 이유와 다시 열 조건을 남기면 같은 논의를 반복하지 않을 수 있습니다.
새 기능 후보가 많다면 MVP 기능 우선순위 진단으로 지금 만들 것과 다음으로 미룰 것을 나눠보세요. 운영 요청의 화면·데이터 확인은 앱 관리자 화면 검수 가이드도 함께 활용할 수 있습니다.
현재 오류와 기능 요청을 같은 기준으로 정리하고 싶다면 30분 무료 상담을 신청해 주세요. 사용자 영향이 큰 문제, 작은 개선으로 확인할 가정과 별도 개발 범위를 함께 나누겠습니다.
확인해보세요
- 요청한 문제를 현재 버전에서 재현할 수 없음
- 사용 흐름이나 사업 정책이 바뀌어 더 이상 필요하지 않음
- 더 작은 운영 변경으로 문제가 해결됨
- 근거를 확인하기로 한 기간 동안 사용·문의 신호가 없음
- 다른 개선으로 같은 결과를 달성함
