PM의 시간 단축: '예외 처리 시나리오' 문서화
PM이라면 누구나 "이슈가 없으면 좋겠다"는 소망을 가집니다. 하지만 기능 개발 과정에서 발생하는 시간 지연의 상당수는 코딩 오류가 아니라, '예외 상황(Error Case)'에 대한 기획자의 판단이 부재할 때 발생합니다. 개발자가 기능 구현을 마쳤는데, '네트워크가 끊기면 어떻게 해야 하나요?', '데이터가 없을 때는요?'라는 질문에 PM이 즉각 답하지 못하면 그만큼 출시 일정이 늦춰지는 것이죠.
오늘은 PM의 실무 효율성을 극대화하고 개발팀의 질문을 원천 차단하는 '예외 처리 시나리오 문서화'의 중요성과 작성 방법을 자세히 이야기해 보겠습니다.
1. 예외 처리가 단순한 '버그 대응'이 아닌 이유
PM에게 예외 처리는 단순한 버그 대응을 넘어 '사용자 경험(UX) 설계의 완성'입니다. 사용자들은 기능이 정상 작동할 때보다, 실패했을 때 그 서비스의 완성도와 진정성을 평가합니다.
토스 화면예를 들어, 결제가 실패했을 때 '알 수 없는 오류(Code: 500)'라는 메시지를 보여주는 앱과, '카드 연결에 문제가 발생했습니다. 결제 수단을 확인해 주세요.'라고 친절히 안내하며 재시도 버튼을 보여주는 앱의 사용자 경험은 완전히 다릅니다. 예외 처리는 사용자가 혼란에 빠지지 않고 다음 행동을 이어갈 수 있도록 설계하는 PM의 책임 영역입니다.
2. 개발 전, 예외 시나리오를 예측하고 문서화하는 방법
예외 시나리오 문서화는 기능 개발에 들어가기 전, PM이 개발팀의 언어로 미리 답을 준비하는 과정입니다. 먼저, 기능별로 발생 가능한 오류를 세 가지 주요 영역으로 분류합니다.
첫째, 사용자 행동 오류: 사용자가 입력값을 잘못 넣었거나(빈칸, 길이 초과), 권한이 없는 행동을 시도
둘째, 네트워크/클라이언트 오류: 사용자의 통신 환경이 불안정하거나 앱 버전이 오래되었을 때
셋째, 서버/시스템 오류: API 호출 실패, 데이터베이스 연결 오류, 타사 서비스 연동 실패 등 백엔드 문제
이렇게 분류한 후, PM은 각 상황에 대해 '어떤 일이 일어날 때 (원인)', '사용자에게 무엇을 보여줄지 (UX)', '시스템은 어떻게 동작할지 (로직)'를 명확하게 정의해야 합니다. 이 문서에는 '오류 코드' 대신 사용자에게 보여줄 친절한 문구와 함께, 개발팀이 디버깅에 사용할 수 있는 내부 오류 코드를 함께 명시하는 것이 중요합니다.
3. 문서화된 예외 처리가 가져오는 PM의 이점
PM이 예외 처리를 선행 문서화했을 때, 프로젝트 전반에 걸쳐 놀라운 효율을 얻게 됩니다.
첫째, 개발 속도 극대화: 개발팀이 코딩 중 '막히는 지점' 없이 일관된 로직을 적용할 수 있어 불필요한 질의응답 시간이 사라집니다. 이는 곧 개발 공수(工數)의 예측 가능성을 높여 일정 준수에 큰 도움이 됩니다.
둘째, QA(품질 보증)의 효율성 증가: PM이 미리 정의한 예외 시나리오가 QA팀의 핵심 테스트 시나리오가 됩니다. QA팀은 '이런 상황에서는 이 메시지가 나와야 한다'는 명확한 기준을 가지고 테스트할 수 있어 품질 검증의 정확도를 높입니다.
셋째, CS 대응의 표준화: 고객 지원(CS) 팀은 사용자가 문의했을 때 어떤 오류 메시지가 노출되었는지 확인하고, PM이 미리 작성한 표준 가이드라인에 따라 일관성 있고 신속하게 응대할 수 있게 됩니다.
PM에게 예외 처리 시나리오 문서는 단순한 추가 작업이 아니라, 팀 전체의 시간을 절약하고 제품의 신뢰도를 지키는 가장 강력하고 전략적인 도구입니다. 이 문서를 통해 예측 가능한 PM의 능력을 증명하고, 성공적인 프로젝트 출시를 이끌어보시길 바랍니다.
