애자일한 프로덕트팀을 만나 당황하는 PO/PM를 위해
폭포수한 기능조직에 익숙한 내가 애자일한 프로덕트팀에 fit을 맞추려면
누군가가 물었다. 'PO는 서비스 기획자와 뭐가 달라요?'
누군가가 대답한다. 'PO/PM은 좀 더 전략적이고 매니지먼트에 중심적으로 일하는 상위기획을 많이 해요'
또 누군가는 대답한다. 'PO/PM은 데이터를 통한 수치를 많이 보고, 주도적으로 사용자의 문제 해결 중심으로 일해요'
나는 둘 다 겪어보고 이야기한다. "그렇게 단순하게 구분 지을 수는 없을 것 같은데요?"
2020년, 10년 가까운 폭포수한 대기업의 조직에서 서비스 기획자로 경험을 뒤로 하고, 나름의 성장을 위해서 프로덕트팀과 애자일을 지향하는 조직의 PO가 되었다. 그리고 체감한 것은 서비스기획 직무가 PO/PM로 이 가능한 연장선상의 업무는 확실히 맞다는 점이었다. 물론 개인의 체감이기에 이것이 모든 곳의 경험과 일치할 것이라 생각하지 않지만 동의하는 사람도 분명히 있을 것이다.
내 경험상 PO/PM과 서비스 기획자를 가르는 위와 같은 대답들과 구분은 문제가 있다. 서비스기획자의 환경도 많이 변했다. 고객의 데이터의 수치를 보면서 일해야하고, 서비스 기획자도 주도적으로 프로젝트를 리딩해야하고, 서비스 기획자도 사용자의 문제를 해결하는 것에 중점을 두고 있다. 이 구분은 트렌드를 말하고 있을 뿐 그 본질적인 차이를 설명하기 어렵다. 그럼 전략이나 상위전략에 대한 말은 어떨까? 전략이나 관리에 대한 부분이 위에서 많이 내려오느냐, 바텀업으로 많이 올라오느냐는 직무의 구성방식과 상관이 없다. 이건 조직의 형태나 사이즈와도 관계있는 문제다.
그래서 PO를 뽑는다고 위와 같은 JD를 쓰면 서비스 기획자들이 자신의 경험을 동일하게 기술한 이력서를 넣는다. 그리고 이유는 모르겠는데 면접을 보고 Fit이 맞지 않는다며 떨어지는 일들이 일어난다. 서로 황당하기 짝이 없다.
그 Fit을 가르는 미묘한 차이는 조직에 있다. 그 조직에서 길들여진 업무 습관의 차이에 있다. 그리고 그 조직의 차이는 아이러니하게도 협업자들의 태도에서도 나타난다.
차이 1. 직무의 목적은 무엇인가.
내가 10년간 서비스기획자로 일하면서 느낀 업무의 이미지는 '파도를 탄다'고 생각했다. 무슨 뜻이냐면 일이 많은 때가 있으면 썰물처럼 빠져나간다는 뜻이다. 사이즈가 너무 커서 몇 날 몇일을 개고생을 해서 힘들게 오픈한 서비스라도 일단 오픈하고 나서 커다란 오류만 없다면 마음이 놓이고 편안한 기분이 들었다. 그렇게 홀가분하게 할 수 있었던 이유는 지금 생각해보면 '목표가 오픈'이었기 때문에 가능했다. 그랬기 때문에 조금은 부정적인 생각을 가지고 협의해가면서 만들어진 서비스에 대해서 어떤 때는 '만들어 달란 놈들이 문제지'하고 팔짱을 끼고 바라볼 수 있었다. 물론 서비스기획자로서도 문제를 제기할 수는 있으나, 협의된 것에 대해서 아예 거부하는 것은 사실상 어렵기 때문이다. 그만큼 여러가지 이유에 의해서 프로젝트는 진행된다.
그렇지만 PO로 프로덕트팀을 운영한다는 생각을 하게 되면서 점차 신경쓰게 된 것은 오픈을 시키고 오픈을 시키고 난 후까지다. 개발을 진행하는 과정에서 이 프로젝트의 목표를 명확히 해야하고, 오픈을 시키고 나면 오류만 바라보는 것이 아니라 그 목표가 가설대로 움직이는가를 생각해봐야한다. 그래서 제일 괴로운 것은 해야할 일이 명확하고 가설은 있으나 그 가설을 검증할 지표를 마련하기 어려울 때였다. 오픈 후에 오류가 없어도 어떤 가치를 증명하지 못하면 박수치며 즐거워할 수가 없어졌다. 직무의 목적은 무엇인가로 보면 PO의 목표는 '프로덕트의 비즈니스적 가치 발전'에 있다. 그래서 나는 파도처럼 일렁이며 자유로울 수가 없었다.
이 개념의 차이를 '결과에 대한 책임'이라고 하는 것은 상당히 피상적인 표현이다. 왜냐면 결과가 잘못 나왔다고해서 모든 것을 책임지고 징벌을 받는 그런 것이 아니기 때문이다. 그래서 기능조직에서 상위기획을 하는 것과 개념적 차이가 있다. PO의 오픈 후 관심사는 도리어 결과에 대한 '예의주시'에 가깝다. 제일 중요한 것은 오픈하는 변화를 만들었다는 것 자체고, 그 다음에 중요한 것은 그게 예상한 대로 정말 의미있게 사용되는가에 있다. 'Go-to-market'전략 또는 '롤아웃 전략'이라는 단어에 '그건 현업팀이 할 일이지'가 안되는 관점을 가지는 것이 프로덕트팀이 크로스펑셔널팀이기에 필요한 사상이다.
차이 2. 확장성에 대한 고려방식이 다르다.
폭포수방식으로 오래 일한 분들에게 요즘 가장 많이 하는 이야기가 있다.
자신이 속한 조직이 애자일을 지향하는 프로덕트팀이 되려면 무엇이 가장 필요하냐고 묻는다면, 나는 그 무엇보다도 딱 한가지가 필요하다고 말한다.
바로 '애자일로 비즈니스적 임팩트를 키우는게 완벽하게 체득하고 있는 개발자'다. 아이러니하지만 기획자는 아무리 프로덕트팀을 운영하고 싶어도 개발자가 애자일을 체득하지 못하면 프로젝트는 조금도 애자일해질 수가 없다. 그리고 이 부분은 '시스템 확장성의 고려방식'에서 확연하게 드러난다.
폭포수 방식에서 일할 때 특정 서비스를 만들때, 전사에 요구사항을 수집하러 다닌다. 내가 첫 인턴으로 출근하던 12년전에 읽은 <정유진의 웹기획론>에서 기획자의 덕목은 '확장성의 고려'라고 이야기했다. 그래서 모두의 요구사항을 수집해서 거대한 요구사항 더미를 바탕으로 우리가 하려고 하는 일들을 추가로 고민하고, 생겨날 수 있는 모든 케이스를 고민해서 전체 프로젝트 일정을 산정하고, 지나치게 길게 걸린다 싶으면 우선순위로 나눠서 1차, 2차로 나누는 것들을 고민했었다. 이때 개발자들은 스펙과 요구사항이 서로 실타래처럼 연결되어 있으면 '같은 거 2번 개발하게 하지 말고 프로젝트 하나로 띄우자'는 이야기를 자주 했다. 그리고 회사 차원에서도 그게 더 효율적인 성과 생성의 길이었고, 회사는 이런 거대한 프로젝트를 하는 사람들에게 평가를 잘 주었다.
그런데 프로덕트팀을 지향하는 관점에서 '1차, 2차'가 아닌 '로드맵'이라는 개념이 등장한다. 로드맵이란 개념은 1차, 2차와 다르다. 서비스기획에서 1차, 2차는 우선순위로 나누어진 기능리스트일 뿐이고, 그 우선순위의 기준은 자의적일수밖에 없다. 다 만들어야 하는 것을 못만든 것 뿐이기에 개발의 공수를 기준으로 나누는 경우도 허다하다. 그리고 무자르듯이 프로젝트를 2개로 나누지 못하면 프로젝트가 길어지는 경우가 있을 수밖에 없다. 길어진 프로젝트에는 필연적으로 '요구사항 변경'이 나타난다. 마음은 바뀌는 거니까...
로드맵은 그 애매하게 연결되는 부분을 무자르듯이 잘라낸다. 폭포수 방식의 프로젝트가 5층짜리 건물을 1층부터 5층까지 동시에 왼쪽에서 오른쪽으로 짓는방식이라면, 프로덕트팀의 스프린트 방식의 운영은 1층짜리 건물부터 짓고, 그 다음에 2층을 올리는 방식에 가깝다. 여기서 제일 중요한 부분은 2층을 올릴 때 1층을 부셔서 2층으로 가는 계단을 만드는 일은 모두가 인정한다는 점이다.
다시 정리해서 이야기해본다면, 확장성에 대한 고려방식이 다르다. 폭포수 방식에서는 확장성의 고려가 프로젝트의 사이즈와 정책의 수를 키우는 방식으로 프로젝트가 점점 커진다. 하지만 애자일을 지향하는 프로덕트팀이라면 수많은 요구사항과 정책에서 정말로 '비즈니스 임팩트가 가능한' 사이즈로 최소화 MVP로 오픈을 하고, 그 다음 로드맵에서 앞에서 개발한 일부를 부수고 다음 로드맵의 최대한의 비즈니스 임팩트를 만들어 내기 위한 프로젝트를 진행할 수 있어야 한다. 그래서 로드맵은 1차, 2차처럼 기능 리스트가 아니라 정말 프로덕트가 지향하는 가치가 드러날 수 있는 Userstory라는 형태로 쓰여 있어야 한다. 그리고 이 모든 것이 허용되려면, 기획자가 아니라 개발자 역시 비즈니스 임팩트의 극대화를 기준으로 만들고 부수고 다시 만드는 것에 대해서 완전히 허용할 수 있어야 한다. 이게 안된다면, 프로덕트팀은 애자일해질 수가 없다.
차이 3. 주도성의 개념이 다르다.
PO는 주도적이어야 한다고 말한다. 그런데 모든 폭포수 방식으로 일해온 서비스기획자도 주도적이지 않은 적은 한번도 없었다. 프로젝트 진행되는 과정과정에서 챙겨야 할 곳이 한두군데가 아니다. 그래서 폭포수 방방식의 조직에서 일한 사람에게도 '주도적으로 일에 참여하는가?'라는 질문을 한다면 대답은 언제나 'Yes'다.
문제는 그 주도성의 범주와 개념이 다르다는 점이다. 폭포수 방식의 기능조직은 요구사항을 내는 사람과 그 일을 수행하는 것이 하나의 물줄기처럼 내려온다. 그래서 모든 흐름은 어디서 시작되었든 기획자와 개발팀에 모여든다. 바텀업으로 해야할 프로젝트를 제안했다고 해도 그 프로젝트는 기획팀, 개발팀 내에 머무르고 오픈하게 된다. 그래서 반대로 현업이 더 열심히 나서서 많은 변화를 가져와야 하는 변화는 현업이 먼저 나서지 않는 한 진행되기가 어렵다고 생각한다. 바로 이 부분에서 주도성의 차이가 드러난다.
프로덕트팀은 크로스 펑셔널 팀을 지향하기 때문에 프로덕트팀 방식으로 일할 때에 바텀업으로 하자고 제안하는 범위는 프로덕트 그 이상의 범위가 될 수 있다. 즉, 뭔가 새로운 서비스를 만드는 것에 현업의 적극적인 참여와 많은 업무가 필요한 것이 있다면 그걸 그 팀에 하게 하도록 만들 수 있다. 보통 폭포수 방식으로 일하는 사람들은 '가이드를 줄테니 서비스를 사용하세요' 정도의 매뉴얼 작업만 할 뿐, '우리가 무슨 프로덕트 개선을 할테니 거긱에 알맞는 적절한 업무 프로세스를 만드세요'라는 말은 해본 적도 없고, 월권처럼 느껴진다. 그 반대의 흐름으로만 일한 경우가 너무 많기 때문이다. PO는 그런 범위의 주도성에 대해서 인식할 수 있어야 한다.
하지만 이러한 주도성의 범주와 차이는 '바텀업'이나 '데이터'라는 개인의 설득 역량으로 치환해서는 안된다고 생각한다. 이건 어디까지나 조직의 차이가 명확해야한다. 예를 들어서 프로덕트팀의 PO가 다른 현업에 저렇게 변화를 요청했을 때 현업의 조직 팀장이 '월권이다!'라고 길길이 화내고 거부하며 '우린 이런 다른 일은 바빠서 하기 싫으니 우리가 요청한 거나 먼저 해주세요!' 라고 말하는 조직이라면 직무는 있으나 권위는 없는 프로덕트팀의 PO가 할 수 있는 주도적인 일은 없다.
반대로 폭포수 방식의 기획자는 프로덕트팀의 PO보다 프로덕트형태에 대한 권한은 더 강력하다. 하고싶은 대로 그린 UI와 내가 생각한 그대로의 로직을 메이커들에게 그대로 전달하고 컨펌하고 테스트를 진행한다. 그 안에서 목표를 통한 자율성을 주지 않기 때문에 디자이너와 개발자는 기획자의 생각이 다소 이해되지 않고 불합리 하더라도 그대로 진행하고, 기획자가 성격마저 나쁘면 아예 대화를 말아버리게 된다. 기획자가 진두지휘한다고 생각하는 거대한 착각은 많은 프로젝트팀내의 분쟁을 일으킨다.
하지만 프로덕트팀의 PO는 정책과 방향성에 대해서는 더 강력하게 주장할 수 있으나, 이 강력한 주장에 근거가 없다면 그 로직이나 UI에 대해서 메이커들이 특정 기준 이상의 퀄리티를 내보이거나 동의하며 같이 만들어나가려 하지 않게 된다. 이게 바로 권한은 없고 의무가 많은 수평적인 PO/PM의 역할이다. UI를 한땀한땀 와이어프레임을 짜고 케이스별 로직을 다 생각하느라 머리 아프던 상황을 그래서 메이커들에게 이 서비스의 개발 이유와 자율성을 높이는 것에 써야한다. 폭포수의 'SB 다 했으니 던지기'가 불가능한 상황이기에 더더욱 사전에 함께 조율하는 시간이 많이 필요하다. UI를 손대기전에 다같이 유저스토리를 이해하고 설득하는 과정이 step으로 나눠져야 일이 잘 돌아간다. 이건 push하며 내 기준에서 빠진 것을 찾아내는 거솨는 다른 차원의 주도성이다.
때론, 우린 PO/PM에 대한 환상을 '데이터'나 '의사결정' 같은 말로 치환한다.
폭포수 방법론의 조직적인 갑갑함은 서비스기획자의 개인의 역량 문제가 아니다. 커리어패스처럼 서비스기획자에서 더 나은 PO/PM로 상향 승진하는 개념으로 생각한다면 그것은 큰 오산이다. 그저 조직의 관점과 범주와 일하는 방식, 그리고 협업 구성원들의 태도와 방식 등이 제일 중요한 차이일 뿐이다.
폭포수 방식으로 일하는 것이 편하고 효율적인 사람이 있고, 또 반대로 프로덕트팀 방식으로 일하는 가치가 마음에 드는 사람이 있다. 하지만 한쪽이라도 일해보기 전까지는 내가 어떤 것을 더 추구하는 확실히 이해하기 어렵다. 폭포수 방식에서 일하던 내가 프로덕트팀의 방식에 적응해보려고 갖은 자료와 협업자들과 대화하며 애를 쓸 때, 나 역시 '내가 이런 업무 방향성을 정말 원했던 것인가'와 '기존의 내 경험이 어디까지 도움이 될 것인가'에 대해서 무지무지 고민에 빠졌었다. 결론은 나는 이렇게 수평적인 프로덕트팀의 방식에서 더 잘하고 싶어서 노력하고 싶다는 결론을 내렸고, 기존의 경험은 언제나 도움이 된다는 점이다. 오히려 기존의 서비스기획자로서 쌓아온 프로젝트 경험은 여러가지 면에서 좋은 참고 자료가 된다.
그래서 꼭 말하고 싶은 것은, 이런 점이다.
주니어에겐 조직형태보다는 플젝경험이 필요하다.
얼마전 연세대의 특강에서 이 두가지 형태의 조직의 차이와 그 안에서 생겨나는 업무적 차이를 설명하고 물었다. 신입으로 입사할 떄 폭포수 조직과 프로덕트팀 조직 중 어디에 가고 싶냐고 물었다. 프로덕트팀이 훨씬 가고 싶다고 했다. 자율적이고 협업하고 더 멋있다고 말이다. 그래서 나는 충고했다.
"온라인 서비스를 만드는 프로젝트를 한번도 해보지 않았다면 프로젝트 소통에 필요한 기본적인 지식이 없어서 바로 PO나 PM을 하기에는 어려운 것 같아요. 프로젝트 경험을 먼저 쌓을 수 있는 주니어로서의 기간을 가져야 프로덕트팀 내에 메이커들의 일 자체를 이해하고 조율할 수 있거든요. 플젝경험은 어느 조직에서든 쌓을 수 있어요! 다만 그 조직과 다른 형태로 일하는 조직이 있다는 점을 잊지 말고 다양한 조직에서 일하는 다양성을 인지하고 있는 것이 제일 중요한 것 같아요. 사실 우리는 일하다보면 자신이 처한 환경이 세상의 전부인양 착각하게 되요. 그게 가장 최악의 문제에요."
그러니까, 지금 조직의 형태에 대해서 무조건적인 불만이나 조직 환경 때문에 성장을 못한다거나 그런 생각이 있다면 그 전에 먼저 생각해야할 것은 내가 어떤 일의 방식에 이미 젖어있는가를 눈치채는 것이다. 회사 조직은 조금씩 차이가 있고, 진짜 커리어적으로 성장하길 바란다면 조직의 변화나 일하는 방식의 변화에도 변화할 수 있을만큼 평소에 다른 사람들의 일하는 방식에도 관심을 갖고 있어야 한다고 말이다.
이 글은 나와 같이 폭포수조직에서 익숙하다가 프로덕트팀 조직에 가서 당황하며 '나는 PO 역량이 없나봐'라고 걱정하고 있는 모든 분들에게 먼저 적응한 사람으로서 드리는 후일담이다. 누구든 자신이 하던 것을 고집하지 않고 하던 일도 새롭게 바라보고 기존의 노하우와 지금의 변화를 합쳐 나간다면, 아무리 연차가 높은 시니어라도 한 번 더 성장할 수 있다. 그리고 나는 지난 1년 넘는 시간동안 꽤나 많이 성장한 것 같다.
