애자일은 억울해 - "그놈의 '애자일' 때문에 임원진 회의가 매일 잡혔는데, 그 회의 때마다 개발 방향 완전히 갈아 엎어져. 무슨 일을 해도 어차피 안 쓰일 일이라고 생각하니 의욕도 안 생기고 방향성도 모르겠어. 그냥 솜사탕 물에 씻는 너구리 된 기분이야." IT업계에서 일하는 친구가 '애자일 방법론'에 대해 볼멘소리를 합니다. 하지만 친구의 이야기를 들으면 들을수록, 친구가 경험한 방법론이 '애자일'보다는 기존의 경영 방법에 애자일 원칙을 딱 1/3만 섞은 '웨자일 (waterfall+agile)'같다는 생각이 들었습니다. 공유하는 기본 전제 자체가 다른 두 방법론을 한데 섞어버리는 순간, 모순적이고 혼란스러운 상황들이 연출될 수 밖에 없다보니 질색하는 구성원들이 생기는 건 당연한 일이었습니다. 그래서 지금 말하는 케이스에서는 애자일의 핵심적인 원칙을 많이 간과되어 있다고 말해주기 위해, 오랜만에 애자일에 대한 설명이 국내 기업에 맞게 정리된 책, <네이키드 애자일>을 펼쳐보게 되었습니다. - 1. 고객이 아닌 보스를 위한 애자일 <네이키드 애자일>은, 애자일의 시대가 도래한 이유 중 하나가 '소비자 주도의 전환이 일어났기 때문' 이라고 설명합니다. 애자일 방법론이 이전 경영 방식보다 더 고객 중심의 프로덕트를 내기 용이한 이유는, 고객의 평가를 받기도 전에, 현장에서 멀리 떨어져 있는 경영진에 판단만으로 결과물이 '킬(kill)' 당할 일을 줄이고, '고객에게' 빨리 자주 프로덕트를 전달하기 때문이라는 것입니다. 하지만 애자일 방식을 도입한 많은 조직의 분들과 대화를 나누어보면서, 애자일이 '상사에게' 빨리 자주 프로덕트를 전달해서 '상사'를 만족시키는 것으로 변형되어 적용되는 경우가 많다는 것을 알게 되었습니다. 그리고 이 잘못된 적용은, 아마 애자일 선언 중 가장 많이 인용되는 듯한 문구, "비록 개발의 후반부일지라도 요구사항 변경을 환영하라."와 만날 때 특히 큰 파괴력을 갖는 듯 했습니다. 맥락이나 이유는 모르겠지만 그저 그렇게 하는 것이 '애자일'의 중요한 원칙이라고만 듣고, 조건없는 무한 수정을 요청 당한다면 그 어느 개발자가 불만을 갖지 않을 수 있을까요. 게다가 실제 고객이 아닌 상사, 또는 고객 역할을 맡기로 한 사내의 어느 직원의 개인적인 판단으로 인해 작업 후반부에서 요청상황을 반영, 심지어 '환영'해야한다면, 그 요청들을 납득할 수 있는 인원은 많지 않을 것입니다. - 2. 동기가 부여되지 않은 개인들로 구성된 애자일 조직 '동기가 부여된 개인들을 중심으로 프로젝트 구성하라.'는 크게 주목받지 못하는 항목 중 하나인 듯 합니다. 하지만 이는 애자일한 프로젝트를 진행하기 전에 마련되어야 하는 필수 조건입니다. "회사에는 필요하지만 아무도 하고 싶지 않은 일을 하는 조직을 만들어 놓고 그걸 애자일하게 굴리겠대요. 동의도 없이 통보식으로 발령받은 사람, 정보를 실제와 다르게 듣고 온 사람들로만 구성된 팀에서 말이에요. 심지어 PO도 퇴사를 고민 중인데 어떻게 잘 돌아가겠어요?" 애자일 방법론은 실무자들의 능동성을 믿고, '일하는 구성원들이 필요로 하는 환경과 지원을 해주면 그들은 일을 끝낼 것'이라고 믿는 방법론입니다. 이 일에 대한 동기부여가 전혀 되지 않은 사람들만이 모여 있다면 그것은 애자일 경영을 시작할 준비가 갖추어지지 않은 것입니다. 그들에게 충분한 동기를 지금이라도 제공한 뒤에 적용하지 않는다면 다른 모든 원칙들을 완벽히 지킨다고 해도 애자일 방법론은 관리자와 실무자 모두에게 짐이 될 것입니다. - 3. 문서 작성을 중시하는 애자일 작성해야할 문서의 목록들은 전부 그대로 유지하면서, 두어주에서 두어개월의 간격으로 작동하는 소프트웨어를 요청하는 것은 애자일의 방향성과 먼 이야기입니다. 애자일의 원칙은 프로덕트의 빠른 시장 검증을 위해 작업하는 기간을 몇배씩 조이는 대신, 다른 일들을 최소화할 필요가 있음을 이해하고 있습니다. 원래 하던 일의 양을 유지하되, 밤낮도 휴일도 없이 몸 갈아 일해서 짧아진 기한을 맞추라고 말하지 않습니다. 애자일 선언은 '단순성(안 하는 일의 양을 최대화 하는 기술)이 필수적이다.', '스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.'며 일시적으로 불태우는, 끝이 보이는 노동이 아닌 지속가능한 개발의 필요성에 대해 이야기합니다. 그리고 애자일의 4원칙 중 하나는 '포괄적 문서보다 작동하는 소프트웨어를 더 중시한다.'로 문서 작업의 우선순위를 실무보다 낮추고 있기에, 문서작업은 그 양을 최소한으로 줄이는 것이 빠른 개발을 위해서는 필수적입니다. - 그 외에도 팀의 효율성을 개선하려는 노력이 안 보이는 경우, 비즈니스 직무와 개발 직무의 전문가들간의 활발한 협업이 불가능한 구조인 경우 등, 애자일을 도입했다고는 하지만 그 원칙이 극히 일부만 도입되거나, 일간 회의의 이름이 스크럼으로 바뀌는 정도로만 도입되었을 때 오히려 애자일에 대한 구성원들의 오해만 커지는 것을 어렵지 않게 볼 수 있었습니다. 애자일이 절대 완벽한 경영 철학, 완벽한 개발 방법론이 아니지만, 적어도 정확하게 적용되지 않은 상태들로 인해 억울함을 당하는 일은 줄어들기를 바라며, TIAA의 Head of Product Technology, 데럴 페르난데스의 한마디로 글을 마무리 지어봅니다. "마음가짐부터 적응할 준비가 되어야 한다. 학습에 개방적이지 못하면 '웨자일'(wagile)로 끝나게 된다" - Derrel Fernandes, Head of Product Technology at TIAA - 주니어 PM의 생각 한 조각 (9) https://brunch.co.kr/@clipkey/43
로그인 후 모든 글을 볼 수 있습니다.