지난해 삼성전자가 전사적으로 애자일을 도입한다는 게 이슈가 됐다. 애자일 선언문이 발표된 건 지난 2001년. 20년이 다 되어가는 애자일 방법론이 아직 화제가 되고 회자된다는 건 흥미로운 현상인 건 분명하다. 애자일은 여전히 IT 업계에선 ‘힙스러운’ 단어로 인식되고 있다. 왜 그럴까.
⓵ 실리콘밸리 스타트업이 대부분 쓴다는 개발 방법론이고 ⓶ 화려하고 다양한 애자일 협업 도구가 유행처럼 쓰이며 ⓷ 왠지 수평적 분위기인 일일 스탠드업 스크럼 미팅도 하고 ⓸ 스크럼 포커 등 다양한 게임화(Gamification) 방식이 있다는 정도라고 할 수 있겠다.
하지만 이런 힙한 느낌과 무관하게 소프트웨어 문화에서 애자일 방법론은 안 쓸래야 안 쓸 수 없는 방법론이다. 왜? 소프트웨어니까. 소프트하기 때문에 수정 요구가 들어오면 기민하게 수정할 수 있다. 미술 작품을 만드는 게 아니라 화분에 물을 주고 가지치기하는 작업에 가깝다. 일단 애자일 방법론 이전에 있던 게 폭포수 방법론이지만 이는 건설 산업에 가장 알맞은 것이다.
건설업이나 제조업 종사가에게 소프트웨어는 얼마나 매력적으로 보일까. 최소한으로 MVP를 먼저 만들고 그때그때 수정하고 보완할 수 있는 소프트웨어 유연성 말이다. 애자일은 이런 특성을 잘 활용해 개발 주기를 짧게 반복하고 작동하는 소프트웨어를 그때그때 만든다. 이런 산출물을 갖고 짧은 주기로 고객 대상 실험을 하거나 실험 결과를 바탕으로 기획 방향을 빠르게 전환할 수도 있다.
이런 이유로 필자가 근무 중인 조직에서도 애자일을 도입하기 위해 온갖 자료를 찾고 IT 업계 지인과 이 주제로 얘기를 나눴다. 하지만 묘하게도 국내 IT 현업에서 애자일 방법론을 직접 겪는 사람은 애자일에 그리 호의적인 것 같지 않다. 예컨대 매일 1시간씩 일일 스크럼을 하면 “나랑 관계없는 얘기 90%를 계속 들어야 하냐? 일일 스크럼은 10분 안에 끝내면 되는 거 아니었냐”는 식이다.
필자는 애자일에 좋은 기억을 갖고 있다. 애자일을 모르던 조직에서 적용한 곳으로 옮기면서 불확실하던 수많은 요소가 시각화되고 합리적으로 산출한 숫자를 바탕으로 커뮤니케이션하는 모습. 그런데 필자가 만나본 이들은 모두 애자일에 대해 다른 얘기를 하고 있었다. 받아들이는 사람의 이해가 부족해 방법론을 왜곡한걸까. 혹은 방법론 자체가 근본적인 문제를 갖고 있는 것일까. 의문을 품고 전문서적을 찾던 중 책 한 권을 찾았다.
드림팀의 악몽(원제: The Dream Team Nightmare)은 기대 이상의 책이다. 분류상 분명 IT 서적이지만 내용을 풀어나가는 건 1인칭 소설의 형식이다. 또 고전 어드벤처 게임 같은 다양한 선택지를 통해 여러 결말로 이어진다. 경영서에 가까운 다른 애자일 서적과는 완전히 다른 느낌을 준다. 줄거리 역시 드라마틱하다. 애자일 코치인 주인공이 회사에 계약직으로 고용되어 생전 처음 보는 개발팀을 코칭한다. 주어진 일정은 5일. 5일 만에 효율 제로 팀을 자기주도적이고 팀웍 탄탄한 팀으로 변모시킨다? 이런 사람이 현실에 있다면 그야말로 애자일의 신 아닐까.
책에는 기술적 내용은 거의 없다. 다양한 애자일 용어가 간혹 나오지만 오히려 사람 사이의 관계, 논리적 마음, 도덕적 자세가 주제가 아닌가 싶을 정도다. 알고 보면 이런 게 애자일 아닐까. 한 가지 생각이 퍼뜩 머리를 스쳤다. 이 책, 게임화된 애자일 소설을 그냥 게임으로 만든다면 어떨까.
필자가 근무하는 회사에선 콘텐츠 신사업을 진행하고자 하는 의지가 있었고 구체적인 레퍼런스로 채팅 포맷을 가진 텍스트 어드벤처 게임이 거론되고 있었다. ‘드림팀의 악몽-애자일로 부수기’는 스토리텔링 측면에서 게임으로서의 조건을 완벽하게 갖추고 있었다. 필자는 진짜로 회사에서 프로젝트 승인을 받았다. ‘드림팀의 악몽’ 판권 보유 출판사와 라이선스 계약도 마쳤다. 하지만 세상에 공짜는 없는 법. 프로젝트 진행 조건은 ‘2개월 내 개발 완료 및 출시’였다.
어쨌든 프로젝트가 시작된 이상 뒤돌아보지 않고 달려 나가야 했다. 하지만 애자일을 처음 접하는 조직 구성원이 수많은 애자일 도구를 모두 쓰게 만들 수는 없는 노릇이다. 개발 기간이 엄청나게 짧아서 새로운 문화를 정착시킬 만한 여유도 없어 보였다. 결국 필자는 애자일 방법론의 여러 도구 중 당장 필요하고 적용할 수 있는 부분만을 차용하기로 했다.
◇ 먼저 커뮤니케이션 빈도를 높였다. 일일 스크럼을 통해 프로젝트 관련자 모두 매일 오전 모여서 진행 상황을 공유했다. 프로젝트 기간이 짧은 만큼 매일 업무 분량도 상당했고 공유 사항도 많은 편이었다. 매일 하는 미팅인 만큼 필요한 얘기만 나누고 자세한 내용은 업무 유관자끼리 따로 하는 게 맞겠지만 쉽지 않았다.
하지만 오버커뮤니케이션(overcommunication)은 언제나 언더커뮤니케이션(undercommunication)보다 낫다는 말도 있지 않나. 일일 스크럼은 프로젝트 정보를 확산시킬 뿐 아니라 팀워크를 만드는 데에도 도움이 된 것 같다. 스크럼 전후 커피를 사러 오가는 사이 주고받는 짤막한 잡담에서도 중요한 인사이트를 얻기도 한다. 원작 소설을 모두 읽고 콘텐츠에 대한 이해를 공유할 수 있었던 것도 스크럼 덕이 아니었나 싶다.
◇ 다음으로 작업을 시각화했다. 지라(JIRA)로 작업을 시각화하면 좋겠지만 이미 비용을 들여서 컨플루언스(CONFLUENCE)를 셋업해 예산을 들인 상황이라 추가 예산 신청은 어려웠다. 결국 이미 쓰던 컨플루언스로 칸반보드 비슷한 시스템을 만들었다. 어설프지만 아쉬운 대로 일단은 쓸만했다. 사실 공수만 좀 들이면 가난한 스타트업이 구글 스프레드시트로 만들어도 못할 건 없겠다 싶었다.
요구사항을 수집하고 ‘할일/진행중/완료’ 주기를 관리하는 채널을 단일화하는 건 의외로 쉽지 않다. 보통 본능적으로 구두로 요구사항을 전달하고 끝내곤 한다. 메신저는 더 안 좋다. 정보가 휘발성인 탓이다. 카테고리화나 검색이 쉬운 슬랙은 좀 낫지만 트렐로(TRELLO)나 지라(JIRA)처럼 절대 좌표에 업무가 정리된 게 가장 이상적이다. 책에 나온 것처럼 포스트잇, 칸반보드를 실물로 직접 만들어서 쓰는 것도 좋다. 어쨌든 필자는 컨플루언스를 썼다. 어떤 식으로든 채널 하나로 작업을 시각화하고 나니 커뮤니케이션 효율이 높아지고 불필요한 작업을 덜어내기도 쉬워졌다.
◇ 마지막으로 일정을 지속적으로 추정했다. 사실 가장 힘든 부분이다. 게임 엔진을 쓰는 것도 아니고 네이티브 앱 2개를 새로 개발하는 과정인데다 이런 텍스트 게임을 만들어본 코드 베이스도 없었다. 복잡한 기능이 많은 건 아니지만 한 번도 구현해본 적이 없는 기능도 기획에 꽤 많이 들어 있었다.
더구나 일정을 줄이려고 기획과 콘텐츠 변환, UX 디자인, 기능 프로토타입 개발을 동시에 진행했다. 불확실성이 높은 초반 일정을 몇 번 과소 추정한 탓에 2개월짜리 프로젝트는 결국 3개월이 됐고 여럿을 설득하는 과정도 필요해졌다. 물론 2개월 이후에는 비교적 추정이 정확해져 결국에는 어떻게든 출시일을 맞출 수 있었다. 이 과정에서 책에도 등장하는 대사가 머릿속에 맴돈다. “초능력을 하나 고를 수 있다면 ‘추정’으로 할 거야.”
물론 앱의 성공 여부는 시장에서 결정되지만 출시까지 라이프사이클을 되돌아보니 아쉬움이 꽤나 많았다. 먼저 일을 가져가는 방식(pull 방식)으로 일하지 못했다. 촉박한 일정을 핑계로 PM이 일을 일방적으로 전달하면서 조율하는 방식으로 프로젝트가 계속 진행됐다. 다시 말해 실무자가 일을 고르는 선택권을 거의 가져가지 못한 셈이다.
지속 가능한 속도로 일하지도 못했다. 프로젝트 도중 유지보수 등 다른 업무가 들어오는 경우가 허다했는데 익숙지 않은 ‘자발적 추정’을 하다 보니 이런 부분을 놓치기 일쑤였다. 사실 프로젝트가 끝난 지금 상황에서 돌이켜보면 불필요한 요구사항을 덜어내고 우선순위가 낮은 업무를 조정해서 야근 없이 일할 수도 있었다. 이런 부분을 해결하지 못한 결과는 결국 개발자와 디자이너의 야근으로 이어졌다.
이런 아쉬움을 돌아보며 자문했다. 애자일 방법론을 완전히 이해하지 못한 상태로 애자일을 적용하려 한 건 아닐까. 이런 생각을 하게 된 계기는 콘텐츠를 정리하던 도중 원작에서 읽게 된 아래 문구 때문이다.
“개발3팀은 ‘애자일을 배운다’는 철학으로 접근했다. 개발1팀은 애자일에 대해 이미 다 알고 있다 생각하고 애자일을 덜어낸다는 접근법을 택했다. 이것이 개발1팀의 실패 원인일지도 모른다.”
필자는 과연 개발3팀과 같이 일했을까. 아니면 개발1팀과 같이 일했을까. 소싯적 애자일을 활용하는 조직에서 일해본 경험으로 어설프게 여러 도구를 시도한 것은 아닐까.
하지만 현업에 종사하는 애자일 코치도 얘기한다. 애자일은 0과 1이 아니라고. 정형화된 개발 단계와 산출물이 존재하는 절차가 아니라 철학이기 때문에 조직의 특성에 따라 실현되는 모습이 천차만별이라고. 그리고 이 게임을 플레이한 한 사용자 코멘트에서 필자는 해답을 찾았다.
“도덕책을 보는 느낌이네요. 배드 엔딩 쪽으로 플레이하고 나면 왜 잘못된 선택을 했는지 확연하게 이해가 됩니다.”
말 그대로였다. ‘드림팀의 악몽’ 서적이 다루는 주제는 결국 기술적인 것이 아니었다. 애자일은 결국 삶의 자세에 대한 것이었다. 사람과 사람의 관계, 논리적인 마음가짐, 도덕적인 자세. 거기에 실험을 통한 예측, 정보의 효율적 공유, 시작과 끝에 대한 명확한 정의.
애자일이 삶의 자세에 관한 방법이기 때문에 애자일 방법론을 일상 생활에 적용하고 웨딩 플래닝에 적용하고 학생의 방학 숙제에 적용할 수 있는 것이 아닐까 생각된다. 그런고로 애자일의 신은 있을 수 없다. 직장의 신이 있을 수 없는 것과 마찬가지로.
하지만 우린 애자일의 신을 꿈꿀 수는 있다. 그리고 도달할 수 없는 꿈을 이루기 위해 무한히 달려갈 뿐이다.
※ 직장백서 : 애자일의 신은 현재 구글 플레이와 앱스토어에 출시되어 있다.
You must be logged in to post a comment.