by
Aug 11. 2020
단순한 정책 설계가 중요한 이유
‘기획자와 정책’은 떼려야 뗄 수 없는 중요한 관계이다. 기획자의 업무 프로세스는 문제의 발견 -> 데이터를 통한 검증 -> 가설 설정 -> 해결안 및 마일스톤 설정 -> 유관 부서 리뷰 -> 서비스 구현 -> 가설 검증의 절차를 거치게 되는데 이때 해결안을 세우고 구현을 할 때 단단한 뿌리와 기둥이 되어주는 것이 바로 ‘정책’이기 때문이다. 정책에 따라 소비자의 전환율이 높아질 수도 있고, 불만이 극대화될 수도 있으며 관리 포인트가 늘거나 줄기도 한다.
특히 정책은 상위 정책과 하위 정책으로 나눌 수 있는데, 상위 정책은 주로 비즈니스 레벨에서의 의사결정을 의미하며 하위 정책은 서비스 구현 레벨에서의 기능적 정책을 의미한다. 예를 들어 상위 정책은 쿠폰 프로모션을 할 때 누구를 대상으로 어느 기간 동안 얼마나 많은 쿠폰을 지급할 것인가가 될 수 있고, 하위 정책은 기 발급된 쿠폰의 사용 처리가 가능한 시간이 언제부터 언제까지인지를 결정하는 등이 될 수 있다. 물론 상위 정책과 하위 정책은 그 구분이 모호한 경우도 있다. 이를 테면 서비스 기능적인 부분이지만 비즈니스적으로 impact가 큰 경우에는 상위/하위 정책을 나누는 게 다소 모호해질 수 있다. 금번에 서술하고자 하는 ‘정책’은 주로 하위 정책인 서비스 기능적인 부분에 집중해 기술해보고자 한다.
단순한 정책 설계를 중시하는 이유는 아래와 같다.
1. 정책은 독립적이지 않다.
특정 서비스의 ‘정책’이라는 것이 독립적으로 움직이는 경우는 많지 않다. 수많은 정책과 의사결정이 서로에게 dependency를 주어 옴짝달싹 못하게 되는 경우가 있다. 이때 복잡한 정책이 다른 정책을 세우는 데 방해가 되기도 하고, 심하면 이전의 레거시 정책 때문에 전체 시스템을 고쳐야 하는 경우가 발생할 수도 있다. 테트리스 게임을 예로 들면 깔끔하고 모양 좋은 벽돌(정책)들만 있는 경우에는 유연하고 확장 가능한 게임 플랜 설계가 가능하지만 복잡도가 높은 벽돌만 나올 경우 다른 벽돌과 매칭이 되지 못해 곧 망가지고 마는 것과 유사하다고 볼 수 있다.
2. 업무 대응이 어렵다.
복잡하게 많은 사람들의 의사가 고려된 정책을 한번 만들어내면, 일단 CS 대응부터 쉽지 않아 진다. 각각의 케이스에 따른 대응방안을 CS팀에 명확히 공유해주어야 하고, 정책 설계자 또한 시간이 지나면 그 정책을 설계하기까지의 맥락은 사라지고, 정책이라는 ‘결과’만 남아 후속 의사 결정이 어려워질 때가 종종 있다. 만약 정책 설계자가 퇴사를 하게 된다면 더 문제다. 정책은 남아있는데, ‘왜’ 그렇게 결정을 했는지를 알지 못해 후임자의 잘못된 의사결정으로 이어질 수도 있다. 또한 어렵고 복잡한 정책일수록 이를 뒷받침하는 시스템 설계 또한 복잡해져 무겁고 유연하지 않은 시스템으로 이어질 수 있음은 당연지사이다.
그렇다면 정책은 어떻게 설계하는 것이 좋을까?
일단 비즈니스 모델링으로부터 시작하는 것이 좋다. 유관부서와 소비자, 생산자와의 관계를 정의한 업무 도식도(flow)를 그리고 현재 상황을 명확히 파악한다. 어떤 문제를 해결하고자 하는지 정의한다. 문제를 해결하는 데 있어 관리 포인트를 줄일 수 있는 부분이 무엇일지 고민한다. 또한 최대한 예외 케이스를 없앨 수 있는 방안은 무엇인지 생각해본다. 예외 케이스가 생길 수밖에 없는 환경이라면 어떻게 구조적으로 잘 해결해 나갈 수 있는지 유관부서와 논의한다. A, A-1, A-2, A-3 식으로 계속 예외 루프에 빠지게 되면 나중에 처치 곤란한 일이 발생할 수 있으니 주의해야 한다.
개인적으로 중학생이 와서 문서를 읽어도 쉽게 이해할 수 있도록 깔끔하게 정리된 단순한 정책을 선호한다.
