The EconoMic Person

조금은 가벼운 마음에 이 책을 들었다.

내가 선택한 책은 아니었고 독서 모임에서 선택이 돼서 선정된 책인데 사실 독서모임에서 선정된 책들이 대부분 읽기에 그리 어려움이 없었던 책이라서 조금은 손쉽게 생각했었다. 사실 애자일도 그냥 읽어보고 '아 그냥 그런 조직이구나' 정도로 생각만 하고 있지 실제로 내가 다니는 회사에서는 적용이 되지도 않고 있고 적용할 의지도(?) 없어 보이기 때문에 남의 나라 이야기였다. 거기다가 PM이니 PO니 하는 이야기는 정말 들어본 적도 거의 없기 때문에(다른 사람 채용하는 것은 많이 본 거 같은데...) 책을 읽으면서 다소 어려운 점이 눈에 띄기 시작했다. 애초에 프로젝트 그룹이라는 것에 참여해 본 적이 없으니 내용 자체가 머릿속에 그려지지 않았던 것이다! 그럼에도 같은 독서 모임 사람들은 정말 좋은 책이라고 하니 그래도 한 번 진득하게 파 보기로 했다(그 덕에 책을 읽는 속도가 현저히 느려지는 단점이 있긴 했다)

<1장 프로덕트 오너는 미니 CEO이다>

1장에서는 프로덕트 오너란 어떤 사람인가에 대해서 나와 있는 부분이다. 사실 읽다가 보니 PO는 스스로가 플랫폼이자 플랫폼을 구축하는 역할을 하는 사람으로서 하나의 프로덕트에 있어서 최상의 귄위(?)를 가지고 있는 사람을 지칭한다. 특히 잘해야 하는 부분이라고 생각이 되는 것이 커뮤니케이션 부분인데 개발자와 고객의 최접점에 서 있는 사람이기 때문에 고객의 불만을 온 몸으로 받아내야 하고 개발자와의 불화를 최전선에서 부딪혀야 하는 입장이다. 결국 회사는 개발자보다는 고객 편이어야 하기 때문에 PO에게 많은 권한을 주고 개발자를 쪼으면 어떨까도 생각을 해 보았는데 그렇게 되면 개발자로 하여금 무언가 만들어서 성공시켜야 되는 의지보다는 'PO의 입맛에 맞게' 만든다는 생각을 갖게 되기 때문에 그리 좋은 방법은 아니라고 한다. 하지만 고객에 대해서는 집착을 끊임없이 해야 하는 자리는 맡는 것 같다.

<2장 고객의 목소리를 어디까지 반영할 것인가>

고객의 소리는 무엇보다 중요하다고 하지만 모든 고객은 한 목소리를 내지는 않는다. 따라서 반영은 하되 내부적으로 조율을 하거나 편의성을 증대시키는 것 자체에 대해서는 PO의 능력이 필요한 부분이 많다. 개인적으로 이러한 UI시스템에서 가장 의견 반영이 잘된다고 생각이 드는 회사는 카카오라고 생각이 되는데 매 번 업그레이드를 할 때마다 카카오톡을 쓰면서 추가 되었으면 하는 기능이나 새로운 기능들이 하나씩 늘어나고 안정화되면서 점차 '절대 없으면 안 되는 프로그램'으로 거듭나고 있다. 고객 입장에서는 다른 더 훌륭한 메신저가 나오더라도 워낙 카카오톡과 연동되어 있는 것과 편의성으로 인해서 절대 바꾸기 힘든 프로그램이 되어가고 있다는 의미이다. 다만 마지막 부분에 나오는 '고객과 회사의 입장 중 상충되면 어떤 것을 따라야 하는가?'에 대한 부분에 있어서는 회사의 장기 목표에 따라가는 것이 옳다는 의견이 재미있던 것 같다. 고객을 중요시 하지만 회사의 장기 플랜은 더 중요하다는 의미라기보다는 지향점에 있어서 흔들리지 않는다라는 표현이 더 옳은 표현인 듯하다.

<3장 데이터 속에서 진실을 찾는 팁>

'데이터를 신뢰하라'

PO의 입장이 되어서 생각을 해 보면 본인이 일정기간 이상 일을 하게 되면 갖게 되는 '직관'이라는 것이 있다. 데이터에서 보이지 않는 무언가가 있다는 말로 표현이 되는 것이 있는데 어쩌면 그렇게 한 경우 성공이 되는 경우도 있으나 PO의 경우 전략을 연구하는 사람은 아니기 때문에 데이터를 신뢰하라는 내용이 나온다. 다만 그 데이터를 신뢰하기 위해서는 데이터의 신뢰성에 많은 공을 들여야 하는데 이런 조건을 잘 설정할 수 있어야 PO로서의 역할을 다 할 수 있다고 본다. 검증법도 확실해야 하고 가설과 조직의 방향성(OKR)까지 관리를 해야 하는 것을 잊으면 안 된다.

<4장 효율적인 일정 관리의 비밀>

일정 관리의 경우 사실 커뮤니케이션이 많은 비중을 차지하게 된다. 특히 목적/배경 정보/어떤 일을 하는지/원칙/목표/주요 지표/개발계획/FAQ 등이 명확하게 담겨 있다면 개발자로 하여금 다시 대화를 하거나 하는 시간 낭비를 줄일 수 있을 거라 생각해 본다. 개인적으로는 위의 내용 중에 '원칙'이라는 부분이 가장 마음에 와 닿는데 PO가 개발자로 하여금 무분별하게 지시를 하거나 개발자들이 자의적으로 판단을 하여 실제 필요한 내용을 넣지 못하고 진행하는 경우도 있는데 이런 부분에 있어서 원칙을 세우는 것은 매우 중요한 포인트라고 생각이 된다.

<5장 디자이너를 최고의 파트너로 삼는 법>

우리가 오프라인이든 온라인이든 모든 제품에 대한 정보는 인터넷으로 확인이 가능하다. 애플리케이션을 활용해서 하든 아니면 실제 웹페이지로 하든 시각적으로 보여주는 것이 굉장히 중요하다는 것인데 이런 부분에 있어서 UI/UX 부분은 굉장히 중요한 역할을 한다고 본다. 그래서 최근 역할이 굉장히 중요해지긴 했는데 여기서는 PO의 경우 디자이너가 아닌 고객의 입장에서 의견을 제시해야 한다고 한다. 이 부분이 불편함이 있는 경우 고객의 입장에서 가장 크게 불편함을 느끼게 되고 이탈을 하게 되는 원인이 되는데 이것을 바로잡기 위해서 자체적인 캐주얼 UT(User Test)을 통해서 자부서 혹은 자회사 사람들이(어쩌면 가장 많이 알고 있을) 가질 수 있는 불편함에 대해서 확인하고 사전에 그런 부분을 제거하며 디자이너로 하여금 나중에 일이 몰아치게 하는 것을 방지할 수 있다.

<6장 개발팀과의 협업을 성과로 이끄는 애자일 전략>
스프린트 플래닝에 대해서 아는가? 애자일에서 실행하는 실천법 중 하나로 애자일을 애자일답게 만드는 중요한 메커니즘이라고 하는데 보통 2주 단위 집중적으로 개발을 하고 성과 파악을 한 후 다시 2주 단위로 진행을 하는 것을 의미한다(스프린트는 전력 질주라고 생각을 하면 된다) 애자일 방식이 좋다고 하는 부분이 여기서 나오는데 반대로 개발자 입장에서는 이런 업무의 시작이 죽을 맛이지 않을까라는 생각도 해보게 된다. 다만 PO의 입장에서 이렇게 2주 단위로 하는 것을 하게 되면 문제가 생기거나 변동사항이 생겼을 때 즉각적인 대응이 가능하여 일정 조율도 어느 정도 가능하게 된다고 한다. 다만 항상 이슈가 되는 '완료일'의 경우 PO가 선정하는 데드라인 방식이 아니라 개발은 개발 매니저에게 디자인은 디자인 매니저에게 맡기되 조율하는 조율자가 되어야 하는 것이 중요하다고 한다. PO는 일방적으로 강요하지도 강요받지도 않아야 되는 입장이기 때문에 전반적으로 모든 일정 부분에 대해서는 빠삭하게 알고 있어야 하는 게 중요하다.

<7장 고객 테스트 결과만큼 강력한 데이터는 없다>

실질적으로 모든 제반이 만들어지면 UT를 진행하게 된다. 대상이 많으면 많을수록 P값에 의거하여 데이터의 신뢰성을 늘릴 수 있지만 그것이 마음처럼 쉽지 않은 경우가 있을 것이다. 다만 그런 부분에 있어서 PO는 최대한 고객 테스트의 결과에 대해서 신뢰성을 높일 수 있도록 조건을 지정하며 대상자 섭외에 힘을 들여야 한다. 또한 이에 대한 정리를 잘해두면 나중에 동일한 이슈로 문제가 되는 것을 미연에 방지할 수 있다.

<8장 프로덕트를 출시하는 최적의 시기>

이건 뭐 딱히 내가 정리할 필요가 없이 책에 깔끔하게 나와 있다.

- 개발 조직이 정한 배포 일정이나 절차가 있는지 먼저 확인한다.

- 다른 팀과의 협업이 필요한 상황이라면, 최대한 미리 배포 일자를 협의한다.

- 가급적이면 저녁 늦게 또는 금요일에 배포하지 않는다.

- A/B테스트를 통해 트래픽을 분산시킨다.

뭐, 이 정도면 되지 않을까? 실제 해 본 경험이 없어서 딱 이 정도가 나의 한계인 듯하다.

<9장 테스트 중 가설을 효과적으로 검증하려면?>

대학원 때 배웠던 것을 활용하는 부분이 되었다. 경영통계 시간에 배웠던 유의미한 P값에 대한 내용인데(문제는 내가 지금도 그걸 이해를 못했다는 건데...) 신뢰성 높은 데이터를 위해 노력을 하고 그것에 대해서 실패한 결과가 나오는 경우 인정하고 새로 다시 해야 더 나은 경험을 제공할 수 있게 된다. 특히 인간이 가질 수 있는 '자기중심적 편향'의 영향에서 최대한 멀게 이성적으로 판단하는 것이 중요하다. 이런 부분은 경험이 말해줄 수도 있지만 노력을 해도 유의미하지 않다면 다른 가설을 설정해야 한다. 그것이 PO의 큰 역할 중 하나이다.

<10장 론칭한 서비스의 문제를 바로잡기>

새로운 서비스가 론칭하면서 큰 변화가 있을 수 있다. 국내의 많은 기업들이 참 못하는 것 중 하나가 대규모 업데이트 이후 문제가 생겼을 때 정작 소비자와 최접점에 있는 고객센터에서는 무슨 내용인지 전혀 파악이 되지 않는 경우가 있다는 점이다. 하청을 주거나 높게 평가하지 않아서 그런 문제가 생기는 경우가 왕왕 있는데 누구보다 빠르게 알아야 하는 것이 고객센터가 아닌가 생각이 된다. 그리고 모든 프로덕트는 '당연히 완벽하지 않다.' 그래서 그런 문제를 바로 잡는 것도 중요한 부분이다(심하면 롤백을 해야 하니 말이다) 국내 게임 업체들 중 이러한 부분을 제대로 대응하지 못해서 역사 속으로 사라진 곳도 꽤나 있다. PO는 특히 사무실에 앉아서 가만히 플랫폼의 역할만 하는 것이 아니라 그곳을 탈피해서 직접 고객의 소리를 들어보는 것도 중요하다고 한다. 뭔가 내용이 걸러져서 오는 것보다 실제 고객들의 불만을 직접 들어보는 것도 방법이라는 생각이 든다.

<11장 어떤 인재를 PO로 선발해야 하는가>

나요.

장난이고 위와 같은 업무를 하면서 항상 긴장감이 있고 조율이 필요하며 24시간 대기를 해야 하는 경우가 발생한다. 어쩌면 책임은 크고 업무량은 과다하며 권한은 그리 없는 존재이기 때문에 최근 MZ세대에게는 매력 없는 직무일 수도 있으나 반대로 보자면 이런 업무를 완벽하게 할 수 있는 사람이 없기 때문에 각광받는 직종이 될 수도 있다(그래서 저자도 이직 좀 했나 보다) 오너십이 필요하고 일감과 환경에 따라 PO직무 자체를 채용해야 하는가 마는가에 대해서 정할 필요도 있다. 최근에는 전반적으로 경력을 뽑는 케이스가 늘어나고 있는 듯한데 회사 입장에서 장기적으로는 신입사원 때부터 여러 직무를 할 수 있는 사람을 미래 PO로 점찍어서 발전시키는 것도 필요하다고 생각이 된다. PO 본연의 업무도 알아야 하지만 회사 내 조직 구성과 현황을 가장 잘 아는 사람이 유리하다는 의미도 된다.

애자일의 정의가 뭐지?

1. 업무를 작은 단위로 쪼개고

2. 소규모의 기능혼합팀을 만들고

3. 업무량을 제한하며

4. 자율적인 팀을 만들고

5. 업무를 완수하며

6. 중단하지 않고 일하고(외부 압력 등)

7. 매일 서서 회의도 하고

8. 급진적인 투명성을 지니며(무슨 일이 생겼는지 팀원 전체가 안다)

9. 주기적으로 피드백을 받으며

10. 소급적 검토를 진행한다.

정의라고 하기는 좀 애매하고 애자일은 바로 조직의 민첩성 향상을 위해서 소규모로 쪼개놓고 과업을 완성하게 하는 조직이라고 할 수 있다. 최근 크게 유행처럼 번져가고 있는 것은 물론 성공사례가 많이 나와서 이겠지만 무엇보다도 4차 산업혁명 시대에 가장 어울리는 조직이라고 생각되어 유행하는 것이다. 애자일 방법을 주로 활용하는 기업들은 바로 S/W 기업들이나 스타트업 기업들인데 무거우면 절대 성공할 수 없는 바로 그런 기업들이 사용되어지고 있다. 이렇게 하지 않으면 안되는 케이스가 바로 GE의 경우가 있다.

GE의 경우 2013년부터 S/W 산업의 발전을 알아채고 전환을 시작한다. 그동안 GE는 정말 시대에 조금씩 앞서선 시대의 선구자였으나 금융위기 이후 금융의 실패로 인해서 회사가 전체적으로 흔들리던 시기였다. 하지만 그들은 미래를 보는 눈을 잃어버린 것은 아니어서 정확히 판단을 하였고 플랫폼 소프트웨어를 통해서 본인들이 가장 자신있어 하는 중후장대 산업들과 소프트웨어 산업을 묶어서 패키지화 하려는 것이 목적이었다. 하지만 결론적으로는 실패로 끝나고 말았는데(규모 축소 및 분사 진행) 기존에 산업들이 중공업 위주여서 그와 동일한 조직과 같이 1000명 이상의 엄청난 개발자를 뽑아놓고서는 무조건 만들라고 하는 방식 때문에 결국 빠르게 움직이지 못해서 침몰하고 말았다. 우리는 이렇게 애자일 조직을 도입하지 않고서는 빠르게 움직이는 산업에서는 성공할 수 없는 것을 보여준다(심지어 100년 이상의 거대 기업인 GE 조차도 실패하지 않았는가!)

세상은 점점 변한다. 특히 회사 중심에서 사용자 중심으로 변하고 있는 것을 볼 수 있는데, 그동안은 컴퓨터를 만드는 회사는 컴퓨터만 팔면 되고 자동차를 만드는 회사는 자동차만 팔면 되는 것이었다면 이제는 그것을 콜라보 해 보기도 하고 아예 다른 방향에서 의견을 제시해 보기도 하며 User의 의견에 따라 수정사항을 바로 조치할 수 있도록 소프트웨어로 자동차를 변환하는(테슬라와 같이) 세상이 되었다. 특히 이렇게 급진적으로 움직이는 경우 조직의 규모가 작아야 바로 대응이 가능한데 이로 인해서 애자일이라는 것이 세상에 알려지게 되었다.

2003년 미국의 대 이라크전은 누가봐도 완벽한 전술과 장비가 있었음에도 큰 피해를 낳고야 말았다. 거대한 조직으로 움직이다보니 집중사격과 같은 역할은 충분하였으나 유기적으로는 움직일 수 없었다. 장군의 명령이 아니면 아예 움직일 수 없는 조직이다보니 시시각각 다른 전술을 선보이는 이라크 군에게 미국은 계속 속수무책으로 당할 수 밖에 없었다. 특히 부대 내에 자율성이 현저히 떨어지는 대규모 조직의 경우 변칙적인 상황에서 크게 무너질 수 밖에 없는데 70년대 베트남과의 전쟁에서도 굉장한 살상무기를 살포하고도 진 황당한 경우가 미국에는 존재했다. 장군 단위가 아닌 개별 중대 단위로 결정하고 움직였다면 좀 더 유기적으로 움직일 수 있지 않았을까?

이렇게 애자일 경영을 강조하는 것은 깊숙히 투입되면서 시장을 창조하는 새로운 Item 들이 등장할 수 있다는 것이다. 그동안은 복잡하고 불편한 그리고 비싼 제품을 훨씬 저렴하고 편리하고 접근하기 쉬운 제품으로 변환하여 생산할 수 있고(개인용 PC), 사람들이 미쳐 깨닫지 못했던 숨겨진 욕구를 충족할 수 있는 새로운 시장도 나타날 수 있다(아이폰, 스타벅스 커피 등) 사실 이러한 결정은 최상부에서 인지하고 먼저 변화를 해야 할 수 있으나(탑다운 방식이 우선 선행되어야 한다. 이 때 가장 최상부의 권력을 적절히 이양하여야 한다) 시간이 걸리더라도 큰 계획의 중요성을 강조하여 결과로 낼 수 있도록 동기부여를 하는 것이 중요하다고 한다. 이렇게 보니 국내 기업들은 이것을 도입할 의지가 있는지도 의문이다. 조직이 큰 것은 둘째치고 권한 이양을 극도로 싫어하니 이런 내용이 와 닿을리가 없겠지. 한편으로는 국내 경영진들에게 필수적으로 읽혀야 하는 도서가 아닌가 조심스레 생각해 본다. 그만큼 이제 변화해야 한다. 시간이 없다.