PO(프로덕트 오너) K-애자일, K-PO에 대한 단상

K-애자일,K-PO에 대한 단상

회사에서 앱을 만들거나 IT 조직이 있다고 하는 대부분의 회사는 요즘 거의 애자일이라는 방법론을 도입하여 운영 중에 있다. 
본 글에서는 IT기업과 비 IT기업에 재직하며 막 애자일이 도입되던 과도기를 거쳐 현재에 이르기까지, 내 직무를 지칭하는 다양한 포지션에 몸담으며 느꼈던 점을 작성하였으며, 애자일이나 PO에 대한 이론이나 멋들어진 정의들은 다른 포스트에도 많으니 별도로 언급하진 않겠다.

 
K-POP, K-뷰티, K-방역 

요즘 들어 어떤 카테고리, 어떤 프로세스 건 한국 사회와 한국인의 특성과 결합하여 새로운 형태의 결과물이 만들어졌을 때 곧잘 K를 붙이곤 한다. 
 
스타트업을 중심으로 애자일이란 방법론이 각광받으며 한국에만 존재한다는 웹 기획, 서비스 기획자가 마침내 프로덕트의 생애에 있어 PO, PM이라는 포지션과 매칭 되면서 직군에 회의적이었던 시각들이 점차 개선되어갔다. 그리고 그런 스타트업들 중 이른바 대박을 친 유니콘 기업들이 점차 늘어가며 너도 나도 애자일이 만능인 것처럼 도입하게 되었고, 결국 한국식 애자일 방식과 한국만의 PO 역할을 만들어내며 책에서 보던 것과 사뭇 다른 혼돈의 시기를 거쳐가고 있다. 

 

반응형

비즈니스 도메인, 인지도, 매출... 그게 뭐든 간에
 

회사의 규모가 좀 있으면서 이미 엄청난 레거시 시스템이 존재하고, 높으신 분들이 IT의 중요성을 깨달아 과감하게 투자하면서, 이제 막 IT부서 한정으로 애자일과 PO 체제를 도입한 지 1년도 채 안된 곳이 이직 회사 리스트에 있다면 과감히 삭제하라.
애자일과 워터폴의 대환장 콜라보! 뭐 같은 상황을 겪을 가능성이 높기 때문이다.
(차라리 관심 있는 비즈니스 분야나 성장 가능성 높은 스타트업 지원을 추천한다. 커리어의 성장세가 다르다. 단순하게 스타트업은 개발 외 모든 걸 다해서 업무 강도가 높다는 이유로 어설픈 중견 회사의 IT 부서를 선택한다면 보수적인 회사의 답답함과 스타트업의 고단함을 동시에 겪을 수 있다) 
 
먼저, 이런 곳은 거의 높은 가능성으로 IT와 거리는 멀지만 매출을 발생시키는 부서가 존재한다. 기존 IT부서는 거의 지원부서로 존재해왔을 것이며 그들의 요구사항은 적극적인 업무방식과 비례하여 소통 채널의 구분 없이 날아온다. 

PO는 비즈니스의 방향과 목표를 이해하고 부서간의 커뮤니케이션이 가장 중요한 덕목이라고 했던가?

K-애자일, K-PO에 대한 단상

 
여기저기서 전달받은 모든 요구사항을 취합하여 IT업계에서 많이 사용하는 JIRA나 Confluence에 정리하는 것이 주요 업무 중 하나가 될 것이다.
 
이런 부서는 보통 외근이 많고 당연히 바쁘며, 그들만의 프로세스가 어느 정도 잡혀 있기 때문에 천지개벽 같은 결단력으로 높으신 분이 전사 도입을 강제로 추진하기 전엔 프로젝트 관리나 생산성 툴은 사용하지 않을 것이니 기대하지 않는 것이 속 편하다.
 
이메일, 문자, 카톡, 구두로 오는 요건을 언제 확인해서 언제 JIRA나 Confluence에 업데이트할지 고민하는 것이 그나마 일에 매몰되지 않는 방법일 것이다.  

 
 
PO (Product Owner) 그 이름도 찬란한 제품 소유자, 미니 CEO 라지...('권한'은 없는)
 

흔히 이름만 보면 직책이 높거나 관리자라고 생각할 수 있지만, 위와 같은 특성의 조직에서는 그냥 '탱커(몸빵)'다.
 
회사마다 프로세스는 다르지만 좀 한다는 서비스들이 홈 화면 PO, 장바구니 PO, 리뷰단 PO와 같이 세분화되어 있는 것과 다르게 한 명의 PO에게 1개 이상 (많게는 3개)의 서비스가 맡겨진다.
 
이렇게 되면 자연스럽게 헬 게이트가 열리는데, 프로덕트에 가장 잘 알아야 하는 '오너'이기 때문에 서비스마다 미팅 요청이 쇄도하고 대부분 필수 참석으로 초대된다. 또 모든 커뮤니케이션 툴 단톡방에 붙박이로 들어가 있어 시도 때도 없이 울리는 알람 소리에 노이로제 걸리기 쉬운 환경에 놓이게 된다.
 
애자일 방식이 안정화된 조직의 PO는 엄청난 범위와 무게의 고민과 의사결정을 해야 하기 때문에 문서 작성보다는 가설과 실험을 빠른 주기로 진행하며 개선한다. 이때 Product Spect이란 문서를 작성하는데 이것을 왜 하는지에 대한 목적과 고객이 어떻게 사용하는지 상세하게 적은 유저 스토리, 그에 필요한 솔루션이나 예상되는 임팩트 등을 작성한 문서로 디자이너나 개발자는 해당 문서를 기준으로 프로토타입이나 개발 스펙을 정의한다.
 
그러나 과도기 조직의 PO는 원활한 프로젝트 진행을 위해 기존의 화면설계서도 작성한다.
Product Spec을 작성해서 Confluence에 올려놓으면 '그래서 기획서는 언제나 오나요?'라는 말만 들을 뿐이다.
물론 Product Spec을 통해 프로젝트를 진행하는 것으로 협의했겠지만, 개발기간은 언제나 촉박하기 때문에 새로운 프로세스는 다음 프로젝트를 기약하며 역시나 해오던 대로 진행될 것이다. 그만큼 기존 프로세스를 변경하는 것은 쉽지 않다.

 

그마저도 스프린트니 스크럼이니 하는 시간으로 기획서 쓸 시간은 예전 워터폴 방식 때보다 줄어든다.

 

'그래, 새로운 프로세스는 자리잡기까지 시간이 걸리겠지, 내가 조금 많이? 고생하면 되지' 라며 마음을 다잡고 이니셔티브(initiative)한 업무 수행을 위해 우리도 데이터 드리븐(Data Driven) 문화를 도입해보자며 개발자에게 필요한 데이터를 요청하면... 뭐 대부분 좋은 소리 못 듣는다. 
(치사하다고 데이터 추출 목적으로 괜히 주말 시간 쪼개서 무작정 SQL 강의 같은 거 들으러 가진 말자! DB서버 열어주는 곳 흔치 않다.
직접 쿼리문 날리고 추출할 수 있는 환경이 되는지 먼저 확인하고 움직이자) 

 

좋은 소리 못 듣는 김에 몰아서 듣는 게 나으니, 페이지와 버튼에 로그를 심어 겨우 GA세팅까지 완료하면 유독 나한테만 시크한 건지 이유 없는 수집 오류에 속 한번 뒤집히고 나서야 작고 소중한 데이터를 얻을 수 있다. 이걸 분석해서 호기롭게 사업부가 참석하는 우선순위 미팅에 가져가면 의외로 반응이 나쁘지 않다.
 
역시 데이터의 힘인가? 다양한 추가 아이디어까지 쏟아지니 그동안의 고생한 보람이 좀 있어지려고 할 것이다. 

 

그러나, 다음 날 (보통은 한 주 뒤) 
 
따로 경영진 보고에서 결정된 사안이라며 지금 시즌엔 매출 확대를 위한 영업 관련 기능이 더 중요하다고 노래방 우선 예약도 아닌 것이 다 긴급이란 태그를 달고 꽂히는데 사용성 개선은 구중궁궐 대왕대비마냥 뒷방 늙은이 같이 백로그 페이지 푸터 영역과 맞닿을 정도의 위치에 짱 박힌다.  

 

뭐 매출 발생시키는 부서에서 신규 고객 유치를 위한 억대의 예산이 배정됐다고 하니 사용성 따위 무슨 걱정인가. 이쯤 되면 마음의 소리가 육성으로 튀어나오게 된다. (내 사업이냐 ㅅㅂ)
 
이제 갖은 우여곡절 끝에 우선순위와 스펙이 정해졌으니 C레벨 보고를 해야 할 것이다. 
참, K애자일에서 경영진은 예외다. 보고서는 워드나 PPT로 만드는데 보통 돈 달라고 하는 신규 건의 경우 PPT로 정성스럽게 만들어 대회의실에서 PT를 한다. (남의 돈으로 사업하는 게 쉬운 게 아니다) 
 
오랜만에 PPT라 디자인 욕구가 샘솟겠지만, 바쁘다 바빠 현대 사회인만큼 잘 만들어진 템플릿을 찾아보자.
그동안의 자료들을 모아서 열심히 작성하고 자연스러운 PT를 위해 대본까지 만들어 어느 정도 익숙해질 때까지 연습하면, 언제나 그렇든 제목만 보고 '그래서 결론이 뭐야?'라는 질문에 이래저래 구두보고로 마무리될 것이다. (그래서 이런 보고 때는 항상 인쇄해야 할지 고민이 된다. 예의를 차려야 할지 종이를 아껴야 할지)

 

보고까지 마무리되면 본격적으로 진행을 위한 미팅이 진행된다. 이제야 진정한 IT부서의 회의가 시작되는 것이다. 
서로 대등한 의견 제시를 위해 직급은 당연히 없앴고, 닉네임까지 도입했는데 매번 미팅이 이모양으로 끝나는 거보면 직급 문제는 아닌 것 같다.

 

그렇게 말할 시간도 생각할 시간도 없이 여기저기 불려 다니며 JIRA / Confluence에 정리하다 보면 어느새 하루가 끝나버리는 생활이 계속 이어지게 되고 어느덧 분기가 지나게 되면 슬슬 이런 소리가 들려온다. 
 
IT에 돈을 이렇게 투자했는데 결과가 안 나온다며, DX전문가로 외국 컨설팅 회사 출신의 C레벨 임원이 곧 부임한다고...

 

그래, 보고 라인이 하나 더 늘어난 것이다.
CTO 표정을 보니... 곧 사내정치 중심에 서있을지 모른다. (사회생활 난이도가 +2 상승했습니다.) 
 
이렇게 훌륭한 인재도 모셔왔으니, 대표님께서 혁신하자며 어디 10대 IT 뉴스에나 나올법한 기술이 소개된 URL 하나를 리드급 단톡방에 올리시고 비즈니스를 고민해보라고 한다. 

 
 

---

 
 

극단적인 예시 같겠지만, 놀랍게도 한 회사에서 겪은 일상의 일부이며 지인들을 통해 들은 회사 중에서도 유사한 곳들은 많았다.
앞서 말한 것처럼 모든 도입 단계의 회사가 이렇다고 일반화하는 것은 아니다. 
도입 단계부터 제대로 하는 회사도 있고, 많은 시행착오를 겪어 지금은 자신들만의 특성에 맞게 효율적으로 잘 운영되는 곳들도 많다.
 
다만, 굳은 결심을 하고 서비스 기획에서 PO로 전향하거나 애자일로 일하는데 익숙하지 않은 기획자들의 경우 그 시행착오 단계를 지나 프로세스가 어느 정도 잡힌 회사를 선택하기를 바라는 마음에서 글을 썼다.
 
소규모 스타트업은 프로세스가 잡히지 않았어도 한두 명의 의지로 개선이 가능할 수 있지만 이미 업력과 규모가 있으며 기술 부채가 쌓인 레거시 시스템이 존재하는 위와 같은 회사라면 의식 있는 임원급이 대대적으로 손대지 않는 이상, PO 혼자서 바꾸는 것은 쉽지 않고 오히려 그러한 환경에 갇혀 일에 끌려다니다 지칠 수 있기 때문에 이미 겪어본 자로서 피할 수 있다면 피하라는 얘기를 해주고 싶었다. 
 
그 에너지를 다른 조직에서 발산한다면 더 빠르게 적응하며 성장해나갈 수 있을 테니...