우리의 Fragile 했던 Agile
Fool 한 Agile 은 제품을 Fragile 하게 한다구요...!!
'이제 (애자)일합시다.'로 끝난 회의
작년 하반기, 팀에 OKR이 도입되면서 모든 구성원이 모여 논의하는 회의가 있었다. 회의가 끝날 즈음 팀장님께서는 "이제 애자일이라는 키워드에 집중해주세요."라는 말을 전했다. 그 말씀 이후로 팀에 '애자일'이라는 키워드가 사용되는 일이 많아졌습니다.
애자일(Agile)의 사전적 의미는 '기민한'입니다. 해당 회의 이후 팀에서는 애자일의 사전적 의미대로 더 '빠른' 실행에 집중했고 6개월 간 새로운 아이디어를 적용했습니다. 하지만 6개월이 지난 후, 반기를 회고해보니 공허함이 느껴졌습니다. 프로덕트가 새로워졌지만 이전보다 '성장했다'는 느낌은 들지 않았죠.
출처 : unsplash6개월을 돌아보니
지금 와서 생각해보면 문제는 한두 가지가 아니었습니다. 가장 큰 문제로 생각되는 건 '변화로부터 고객이 혼란을 겪었다'는 점입니다. 내부에서는 '빠른' 변화였지만 고객은 이를 '급작스런' 변화로 받아들인 것이죠. 내부에서 새로운 시도를 논의하면서 속도에만 집착했을 뿐 프로덕트의 정체성, 고객 경험, 데이터 등은 고려하지 못했던 겁니다. 게다가 서비스 일관성에 대한 이야기가 나올 때마다 "일관성을 위해 더 나은 서비스를 미룰 수는 없다."는 이야기가 나오곤 했죠.
당시에는 생각할 시간이 부족했다보니 '그런가?'라는 물음을 끝으로 자리로 돌아갔습니다. 그리고 다시 빠르게 여러 가지를 시도했는데요. 하지만 지금 와서 생각해보니 일관성은 생각보다 더 많이 중요했습니다.
(브런치) 카카오계정 비밀번호 변경 유도 화면가장 가까이는 저 역시 일관성을 위해 '나음'을 포기하는 경우가 많았습니다. 위 사진에서 볼 수 있는 비밀번호 변경이 그러한 예시 중 하나인데요. 여러 사이트에서는 보안을 위해 주기(주로 3개월)마다 비밀번호 변경을 유도하고 있습니다. 글을 읽고 계신 독자분께서는 비밀번호를 얼마나 자주 변경하시나요?
저는 저런 화면이 뜨면 99% 이상 '다음에 할게요.' 버튼을 누릅니다. '다음에 할게요.' 버튼이 빠진 화면은 상상만해도 끔찍합니다. 매 번 새로운 비밀번호를 기억하고, 사이트마다 전부 다른 비밀번호를 기억해야 하다니요. 새로운 비밀번호로 변경하는게 보안상으로는 훨씬 더 '나음'에도 말입니다.
(최근에는 이런 문제를 해결하기 위해 브라우저에 저장되는 자동 비밀번호 기능을 제공해주고 있습니다만...)
회의 이후 반기 동안 했던 '빠른' 실행은 고객에게 강제로 비밀번호를 바꿔야 하는 상황을 연출했습니다. '애자일 소프트웨어 개발 선언'에서도 강조하고 있는 '고객과의 협력'은 그저 빠른 실행이라는 함정에 의해 외면당했고요.
조금씩만 돌아보며 했더라면
무조건 빠르게하기 보다는 '더 잘하기 위해서 점검할 수 있는 장치를 만들어 두고 체크해야 했다'는 생각을 해봅니다. 예를 들면, 고객의 반응을 관찰하고 데이터를 추적하기 같은 것들 말이지요. 이를 바탕으로 새로운 시도가 고객에게 더 많은 가치를 제공했는 지를 점검하고, 성공적일 때에는 발전시키고 그렇지 못할 때에는 다른 방법으로 시도하고나 과감히 버려야 했습니다.
하지만 우리의 제품에는 이를 점검할 수 있는 데이터도, 고객 반응을 추적하기 위한 프로세스도 없었습니다. 그렇다 보니 고객이 실제로 좋아하는지 알 수 없는 결과물만 덕지덕지 붙어가게 되었죠. 빠르게 실패하긴 했지만 제대로 실패하지는 못했습니다.
월가의 현자로도 불리는 나심 탈레브는 ⌜블랙스완(Black swan)⌟ 등에서 불확실한 세상에서 더 잘 살아남는 방법을 말하고 있습니다. (완전히 같지는 않지만) 그의 주장은 애자일과 궤를 같이하는 부분이 있는데요. 그는 자신의 책 ⌜안티프래질(Anti-Fragile)⌟ 에서 실패를 활용하는 방법에 대해 다음과 같이 말하고 있습니다.
"나는 실패를 한 후 새로운 정보를 얻거나 그 이유를 찾기보다, 자기 반성을 하지 않고 실패를 활용하려고도 하지 않으며 당혹스럽고 방어적인 자세만 취하는 사람을 패배자로 규정한다."
- 안티프래질, 119p
어쩌면 빠른 실행보다는 점검과 회고가 중요했던 거 아닐까? 출처 : unsplash물론 빠른 실행과 그로 인한 수많은 실패는 애자일의 중요한 요소 중 하나입니다. 하지만 이를 개선하기 위한 점검, 회고와 피드백 역시 동시에 이뤄져야 합니다. 그 중심에는 고객이 있어야 할테고요. 이를 잊어버린 채 진행했던 '우리의 어설펐던 애자일'은 프로덕트를Anti-Fragile 하지 못한, 즉 Fragile 한 상태로 만들지 않았나 합니다.
