우선 제품 출시전까지 시간을 얼마 남겨놓지 않은 상태에서 개선을 위해 문제점을 파악하라는 업무를 받으셔서 정말 힘드시겠다는 생각이 듭니다. 또한 시간적 문제뿐만 아니라 사업팀이나 개발팀과의 협력 부분에도 어려움이 있으신 것 같고요. 자세한 상황을 모르는 제삼자 입장에서 답변이 얼마나 도움이 될지는 모르겠으나 제 경험에서 몇 가지 답변을 드려보도록 하겠습니다.

우선 대문자로 시작하는 애자일(Agile)과 소문자로 시작하는 애자일(agile)로 구분하여 답을 드려보겠습니다. 대문자로 시작하는 애자일은 고유명사로 "애자일은 이런 것이다"라고 특정해 말하는 사람들의 입장을 대변합니다. 소문자 애자일은 애자일을 보통명사로 보고 "여러가지 애자일이 있을 수 있다"고 말하는 사람들의 의견을 말합니다.

대문자 애자일에서는 선생님께서 설명하신 프로세스는 폭포수 방식(Waterfall Method)이라고 말할 것입니다. 개발이 거의 완료된 시점에서 검증/UX팀에게 업무가 전달되는 것, 즉 개발의 단계가 나뉘어지고 핸드오버가 그 단계의 경계에서 이루어지는 것이 폭포수 방식입니다. 이렇게 할 때의 문제는 매몰 비용이라는 인간의 심리적 편향이 작용하게 된다는 점입니다. 즉, 이미 투자를 많이 해서 해놓은 것에 대해 "방향이 잘못되었다" 는 말을 하기 힘들고 오히려 정당화하는 쪽으로(혹은 피상적인 차원에서만) 요식적인 검증이 이루어지기 쉽습니다. 실제로 많은 기업에서는 이 방향이 옳다는 주장을 강화하기 위한 방법으로 검증/UX팀에게 마지막에 일을 주는 경우도 흔한 것 같습니다.

이에 반해 애자일 방식은 처음 프로젝트 계획을 세울 때부터 검증/UX팀이 협업을 함께 해서 방향을 정해 나갑니다. 만약 신제품 개발의 전체적인 프로세스를 바꿀 수 있다면(만약 애자일의 최대 효과를 내고 싶다면 이렇게 해야 합니다) 오토데스크(Autodesk)사의 사례로, 데저레이 시(Desirée Sy)가 사용한 방법이 힌트가 되지 않을까 합니다. 기본적인 방식은 개발팀과 UX팀이 프로젝트 시작부터 병렬로 동시 진행을 하며, 서로 1 반복주기(iteration)만큼 시간 차이를 두고 진행합니다. 1 반복주기가 만약 2주라면, 개발팀이 2주 동안 P1을 개발을 하면 그 다음 2주에는 P2를 개발하는데, 이 때 UX팀은 P1의 사용자 경험을 검증하고 개선 제안을 만들어 개발팀에 전달하고, 동시에 개발팀의 다음 반복주기 개발대상인 P3를 설계하고 사전 연구, 사전 테스트(이 부분은 최근의 린스타트업의 기법들을 활용하십시오)합니다. 그래서 다음 반복주기가 되면 개발팀은 UX팀에서 건네준 P1의 개선점과 P3의 계획안 두 가지를 같이 받아서 개발합니다. 이 동안 UX팀도 한 칸 나아가서 P2의 테스트와 P4의 계획을 같이 만들게 됩니다. 이 방식을 섞어짜기(interwoven parallel iteration) 방식이라고 저는 부릅니다. 이 방법에도 단점이 있긴 하지만 여기에서 힌트를 얻어 우리 조직에 맞는 방식을 조금씩 만들어 나가는 방식을 권하고 싶습니다.

아마 제가 설명한 방식이 어쩌면 선생님의 조직에서는 조직구조와 문화를 볼 때 불가능하다고 느껴질 수 도 있겠습니다. 또 경영진의 전폭적인 지원과 추진이 필요하다고 느낄 수도 있을 것입니다. 정말 어려운 일이지요. 내가 할 수 있는 건 없다는 생각이 들 수도 있죠. 하지만 저는 이 구조를 그대로 복사하기보다 이런 "느낌"을 자체적으로 조금씩 만들어가는 것을 권하고 싶습니다. 그것은 오늘 당장 나로부터 시작할 수 있습니다. 이 말은 다음의 이야기와 연결됩니다.

소문자 애자일에서는 좀 더 점진적인 방법을 이야기할 수 있겠습니다.

우선, 제가 많은 기업의 UX팀들을 컨설팅해 본 경험에서 UX팀의 UX가 다른 팀에 비해 가장 안좋다 느껴지는 경우가 많았습니다. 그 말은 UX팀이 그 안에서 직원들이 느끼는 팀 만족도가 낮고, 서로 협력을 잘 못하고, 또 다른 부서와도 소통이 잘 되지 않더라는 말입니다. 사실 UX팀이 그런 일을 잘해야하는 사람들임에도 불구하고 매우 아이러니한 일이지요.

그래서 우선은 UX팀 내부에서 애자일하게 일하는 것을 시도해 보시면 어떨까 싶습니다. 아마 출발은 이런 모습이지 않을까 싶습니다. UX팀 회의를 소집합니다. 그리고 팀장이 말을 합니다. "여러분. 이번에 추천 알고리즘의 개선안 조사를 2주 안에 해내야 하는 상황이 되었습니다. 저는 참 고민이네요. 솔직히 말도 안된다고 생각합니다. 우리 방식대로라면 3-4주는 필요한데 말이죠. 근데 출시일이 정해져 있다고 합니다. 어떻게들 생각하시나요?" 저는 이게 애자일의 출발이라고 생각합니다.

그런데, 반-애자일(anti-agile)의 출발은 이렇습니다. "여러분. 우리 팀은 이번에 애자일로 일할 겁니다. 우선 제가 애자일 프로세스 소개 발표를 할 겁니다. 그리고 업무 배정을 해드릴게요. 내일부터는 아침마다 각자 한일, 할일, 어려움 돌아가면서 발표하셔야 합니다. 좀 더 협력적으로 일하시고요." 만약 일단 UX팀 안에서 애자일이 잘 일어나기 시작하면 선생님과 선생님의 팀은 조직 내에서 변화를 만들기에 훨씬 유리한 입장에 있게 될 것입니다.

소문자 애자일을 통해 조직적인 변화를 만들고 싶으실 경우 도움이 될 말씀을 하나 드리고 싶습니다. 제가 몇 대기업과 그룹사를 컨설팅하며 연구를 한 적이 있습니다. 조직적 변화가 어떻게 일어나나 혹은 안 일어나나를 연구했습니다. 반복된 연구를 통해 거듭 나오는 주제는 이렇습니다. 효과적인 의사소통. 제 연구에서 회사의 정책이 바뀌거나 조직 구조가 바뀌어서 실제 지속되는 변화가 일어나는 경우는 거의 없었습니다. 변화의 핵심 요소는 효과적인 의사소통을 하고 본인이 열심히 돌아다니며 주변을 설득하는 사람이 존재하는가 하는 점이었습니다. CEO가 지원해주냐 아니냐가 중요한 것이 아니었습니다.

특히 인상적인 부분은 마이크로한 레벨에서도 이 효과적 의사소통이 의미가 있었다는 점입니다. 직원의 일상을 연구했을 때, 그 직원이 당일날 효과적인 의사소통을 해 낸 경우, 당일 그리고 그 다음날 그 직원은 의도적으로 새로운 시도를 더 많이 해보는 확률이 매우 높았습니다. 자기효능감이 커져서입니다. 그래서 조직의 변화를 꿈꾸는 사람은 우선 자신에게 이런 질문을 해야 합니다. "내가 주변 사람들과 효과적으로 의사소통하고 있는가? 그 사람들의 신뢰를 얻어나가고 있는가?"

마지막으로 한가지 일화로 긴 답변을 마칠까 합니다. 군대문화로 유명한 모 대기업의 사례입니다. 대리급 직원 하나가 해당 개발 부서(100명 이상)의 일하는 방식을 약 1년에 걸쳐 완전히 바꿔놨습니다. 보고하는 방식도 바뀌었고 프로그램 코드를 저장하고 공유하는 방식(기술적으로 말하자면 cvs에서 git으로)도 바뀌었습니다. 이 사례를 발표하게 되었습니다. 그 때 청중 중 하나가 손을 들고 말하더군요. "저도 똑같이 다 해봤어요. 새로운 기술 설명회도 하고 참고자료도 다 보내주고 하라하라 했는데 아무도 안하더군요. 우리 팀 사람들은 너무 수동적이고 보수적이에요." 그 때 저는 발표자와 질문자에게 똑같은 질문을 했습니다. "동료들이 선생님을 좋아하나요?"