정책 정해주세요.
PM, 기획자로 일을 하면서 디자이너나 개발자로부터 자주 듣는 말 중에 하나는 정책을 정해 달라는 말이에요. 근데 늘 저는 이미 정책은 이미 잡았다고 생각했어요. 정책에 기반한 요구사항도 정해놓았어요. 가령 아래와 같이 말이에요.
000 법과 가이드에 따라 사용자의 재산권 보호와 앱의 보안을 위해 앱 잠금 기능을 구현합니다. 한편, 이러한 목적에 따라 디바이스의 잠금과 앱의 잠금 기능이 모두 적용되지 않았을 때 앱을 강제로 잠그는 동작이 진행되어야 합니다.
이렇게 요구사항을 내려주고, 팀원들과 미팅을 하면 대체로 다 이해를 해요. 그래서 저 또한 “아 요구사항이 잘 전달되었구나. 이제 필요한 부분은 구현과정에서 나오는 추가 고려사항으로 디테일을 챙기면 되겠다.”라고 생각하고 다른 작업을 진행해요. 근데 한창 잘 구현을 하고 있을 거라고 생각했을 때, 정책을 잡아달라는 이야기가 나와요. “대체 어떤 정책? 정책과 요구사항은 다 내려준 것으로 이해했는데?”
이번 글은 유저 시나리오를 통해서 기획안을 작성하는 방법을 소개해보았어요. 글의 순서는 아래와 같아요.
1. 정책은 무엇일까?
2. 유저 시나리오를 작성해 봐요.
3. 유저 시나리오 작성의 이점과 연습하기
정책은 무엇일까?
먼저 팀원들이 말하는 “정책”이 무엇인지 고민해 봤어요.
첫 번째로 정책은 비즈니스나 산업, 법과 관련한 내용을 말해요. 가령 이런 경우가 있어요. “비즈니스의 최근 환경이 A로 바뀌었습니다. 그에 따라 B라는 기능의 필요성이 증대했습니다.”, “정보통신망법의 개정으로 00 조항이 신설되었습니다. 이에 따라 A라는 기능을 구현해야 할 필요가 생겼습니다.”. 이렇게 조직의 대 ・ 내외적인 환경의 변화를 비롯하여 큰 틀에서 우리가 어떤 특정한 과업을 수행해야 할 이유를 설명해 줄 수 있는 내용을 말해요.
두 번째로 정책은 사용자가 겪고 있을 문제를 말해요. 흔히 “문제 정의”라고 말하는 부분이에요. 예를 들어 “사용자가 본인의 자산이 앱 실행 직후 바로 노출되는 것에 불안해하고 있어요.”, “나쁜 사람들이 바로 앱을 실행해서 나쁜 짓을 실행할 수 있어요. 이는 곧 사용자에게 큰 피해로 이어지게 됩니다.”와 같은 것들이 바로 문제 정의입니다. 문제 정의 역시 첫 번째와 마찬가지로 큰 틀에서 우리가 과업을 수행해야 할 이유를 설명해 주는 내용이에요.
세 번째로 정책은 요구사항을 말해요. 요구사항이란, 앞서 제시한 문제에 대해서 해소할 수 있는 구체적인 방안을 말해요. 또한 우리는 요구사항을 토대로 달성가능한 목표와 일정을 같이 수립하게 돼요. 이 글의 제일 처음에 예시로 들었던 “디바이스와 앱의 잠금 기능이 모두 적용되지 않았을 때, 앱 강제 잠금 기능이 동작해야 합니다.”가 요구사항이 될 수 있어요. 여기에 더해 “앱 잠금 기능을 통해 000 법과 가이드를 준수하고, 사용자의 재산권을 보호합니다.”와 같은 달성해야 할 목표가 제시되어야 하고, “m월 d일에 배포되어야 합니다.”와 같이 구체적인 기한까지 명시된다면 더 좋아요.
마지막으로 정책은 예외 케이스를 말해요. 개인적으로 제가 팀원과 가장 이해도가 달랐던 부분이면서 동시에 가장 많이 놓치는 부분이 바로 이 부분이었어요. 예외 케이스는 요구사항을 구현하는 과정에서 상위 레벨에서는 고려하지 못했던 세부적인 내용들을 말해요. 디자이너가 제품 디자인을 진행하다가 막혔을 때, 개발자가 구현을 진행하다 기능 간 충돌이 발생하거나 빈 틈이 보였을 때는 모두 예외 케이스가 존재하기 때문이에요. 이때 팀원들은 저희에게 이런 이야기를 할 거예요.
“PM님, 정책 잡아주세요.”
“정책이 충분히 고려되지 않은 것 같아요.”
“어떻게 하라는 건지 모르겠어요. 구체적으로 잡아주세요.”
저는 그동안 많은 실수가 있었어요. 이런 얘기를 들었을 때, 법이나 가이드에서 명시하는 세부적인 내용을 좀 더 찾아 근거를 보완하거나, 요구사항을 좀 더 디테일하게 작성하곤 했어요. 정작 팀원들의 막힘에 대해서 해소하지는 못한 채 말이에요.
우리의 팀원들은 이 모든 걸 아울러서 “정책”이라는 표현을 쓰곤 해요. 그래서 우리의 기획안은 이 모든 것을 아우르는 정책이 포함되어 있어야 해요.
유저 시나리오를 작성해 봐요.
우리는 이제 우리의 기획안에 하나만 더 작성해 보면 돼요. 바로 유저 시나리오예요. 앞서 얘기한 정책들, 이 모든 걸 아우를 수 있는 PM의 무기는 바로 유저 시나리오입니다. 유저 시나리오란, 사용자가 제품이나 서비스를 사용하는 상황에 대한 설명 또는 스토리를 말해요. 사용자가 어떤 목표를 달성하고 싶은지, 사용자가 목표를 달성하고자 하는 맥락 · 배경은 무엇인지, 사용자는 목표를 달성하기 위해서 무엇을 하는지를 그려내는 것을 말합니다.
간단한 유저 시나리오 예시를 만들어볼게요. 적절한 시나리오 작성에 대한 예시를 위해 위에서 제시한 기능인 앱 잠금 기능을 구현하는 과정을 생각해 볼게요. 먼저 사용자와 목표를 정해볼게요. 우리의 사용자는 “금융 앱을 사용하면서 핸드폰의 분실이나 도난으로 인하여 피해를 입을 것을 우려하는 사용자”입니다. 이들의 목표는 “본인이 아닌 경우에는 앱 실행이 가능하지 않도록 동작하는 것”이 될 수 있어요.
이제 두 가지를 모두 설정했으니 사용자가 무엇을 하는지를 그려볼게요. 아래와 같이 사용자의 동작을 작성해 볼 수 있어요. 하기 시나리오는 예시로 실제 기능 구현 과정에서는 보다 다양한 케이스와 세부 스펙의 작성이 필요할 수 있어요.
1. 사용자의 디바이스 잠금과 앱 잠금 기능은 설정되지 않은 상태입니다.
2. 사용자가 자산 확인, 송금 등을 위하여 앱을 실행합니다.
3. 앱을 실행하는 단계에서 사용자의 디바이스 잠금 여부를 가져오고, 서버에서 사용자의 정보에 저장된 앱 잠금 여부를 가져옵니다.
4. 디바이스의 잠금 여부가 off이며, 앱 잠금 여부가 off이면 앱 강제 잠금 기능을 실행합니다.
5. 두 가지 조건 중 하나라도 on이라면 앱 강제 잠금을 실행하지 않고 앱으로 진입합니다.
다만 이렇게 구현하게 되는 경우, 예외 케이스나 비효율적인 부분이 반드시 존재할 거예요. 가령 여기 예시에서는 이런 경우가 있을 수 있어요. “매번 디바이스 잠금 여부와 서버에서 앱 잠금 설정 여부를 가져와서 비교하는 로직이 스플래시에서 구현된다면, 앱의 성능이 저하될 것 같은데?” 또는 “앱을 잠시 백그라운드로 내린 상태에서 디바이스 암호를 설정하면 어떻게 동작해야 하지? 백그라운드에서 포그라운드로 올라올 때도 앱 강제 잠금 여부를 확인해야 하나?”. 그래서 이제 다음과 같은 시나리오를 추가로 작성해 줘요.
6. 앱 강제 잠금 로직 적용 여부를 서버에 매번 확인하지 않기 위해 앱이 백그라운드로 내려가거나 앱을 종료하는 경우, 사용자의 앱 잠금 여부를 클라이언트 캐시에 저장해 둡니다. 이를 통해 서버 호출을 줄여 트래픽을 감소하게 만들고, 앱 실행 단계에서 성능의 저하를 방지합니다.
7. 사용자의 디바이스 잠금 여부는 앱이 동작하지 않는 경우에는 파악하기 어렵기 때문에 앱 실행 또는 앱이 포그라운드로 진입할 때마다 디바이스에서 정보를 가져옵니다. 이를 캐시에 저장된 앱 잠금 여부와 비교하여 앱 강제 잠금 실행 여부를 판단합니다.
이제 우리는 예외 케이스를 포함해서 시나리오를 작성함으로써 팀원들이 막혔던 부분을 해소했어요. 여기서 작성한 시나리오 하나하나가 모두 요구사항이자 제품 스펙이 될 수 있어요. 이제 팀원들은 이렇게 작성한 시나리오를 기반으로 설계를 진행하고, 클라이언트와 서버 개발자 간 의사소통을 진행할 수 있으며, 디자이너는 플로우 설계를 진행할 수 있어요.
유저 시나리오 작성의 이점과 연습하기
이렇게 시나리오를 통해 작성하게 되는 경우 이점은 크게 3가지가 있어요.
1. 팀원 간 커뮤니케이션 비용을 줄일 수 있어요.
2. 여러 케이스를 고려할 수 있어 요구사항에 대한 오류를 줄이고, 불필요 기능을 최소화할 수 있어요.
3. 전반적으로 개발 비용을 감소하게 만들 수 있고, 개발 속도를 향상할 수 있어요.
유저 시나리오를 잘 작성하려면 크게 2가지를 연습하면 좋아요.
첫 번째, 사용자 관점에서 끊임없이 우리가 구현하고자 하는 케이스를 상상해 봐요. 동작도 사용자 관점에서 이런저런 동작을 모두 떠올려봐요. 물론 그럼에도 불구하고 사용자는 항상 예상외의 케이스를 마주할 수 있어요. 하지만 기획 과정에서 가급적 많은 사용자 관점을 녹여내면 이후 설계 과정에서 또 다른 여러 케이스를 보완해 가면서 보다 완성도 높은 제품의 구현이 가능해질 수 있어요.
두 번째, 당연하게도 많이 작성해 보고 팀원들에게 적극적인 피드백을 구해봐요. 우리가 기획안을 작성하는 것은 팀원들이 제품을 만들 수 있도록 하기 위함이며, 무엇보다도 우리는 일이 되게 만들어야 하는 직무예요. 그렇기 때문에 팀원들이 수용할 수 있는 형태의 기획안을 만들어 실제로 구현까지 이어지는 경험들을 많이 가져볼수록 더 잘할 수 있게 돼요. 그런 경험들이 반복해서 쌓이다 보면 크고 깊이 고민하지 않아도 자연스레 여러 예외 케이스를 자연스럽게 떠올릴 수 있게 돼요. 또한 이러한 경험이 점점 쌓일수록 팀원들로부터 신뢰받는 기획안의 형태가 만들어질 수 있어요.
결론
우리는 늘 고민해요. 어떻게 하면 팀원들을 잘 이해시키는 기획안을 만들 수 있을지. 만약 팀원들이 우리가 만든 기획안을 잘 이해하지 못하고, 계속 정책을 잡아달라고 이야기하거나 요구사항이 명확하지 않다고 한다면 유저 시나리오를 통해 기획안을 작성해 보는 것을 해보는 것을 추천합니다.
June님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
