애자일 - 코드 품질을 떨어뜨리고 마이크로 매니징을 유발할 수 있다

Devclass 기사를 요약/의역한 글입니다

---

전 구글 개발자인 Murat Guler의 주장에 따르면, 애자일 방법론이 마이크로 매니징과 코드 품질의 저하를 유발 할 수 있다고 합니다. Murat Guler는 구글에서 13년 이상 소프트웨어 엔지니어 및 아키텍트로 일했으며 2022년에 퇴직 후 현재는 스타트업의 창업자가 되었습니다.

애자일 방법론은 23년 전 처음 세상에 공개되었으며 기존 워터폴 방식의 개발 방법에 대응한 개발 방법론이었습니다. 기존 워터폴 방식과는 달리 애자일은 점진적인 방식을 추구하고 MVP를 공개한 후 작은 단위로 기능을 지속적으로 출시하며 사용자의 반응에 따라 대응하는 형태입니다.

Guler는 애자일 방법론 중 몇 가지 사항들이 과하게 적용되어 마이크로 매니징을 유발하고 코드 품질을 떨어뜨린다고 주장했습니다. 특히 “비즈니스 이해 관계자와 개발자들이 매일 (주기적으로) 프로젝트에 대해 논의하고 일해야 한다” 라는 항목이 마이크로 매니징을 유발 한다고 주장했습니다. 이는 “프로덕트 오너들이 개발자들의 의견을 중요하게 생각하지 않고 논의를 강압적으로 끌고 가게끔 한다” 라고 언급했습니다. 또한 “일정 예측은 데드라인이라는 것으로 변모하고 개발자들이 신뢰 할 수 없고, 의심의 대상이 되고, 무언가 잘못되면 쉽게 질책의 대상이 된다” 라고 덧붙였습니다.

애자일은 이런 상황을 더 악화 시키는 경우도 있습니다. 가끔 매니저들은 이런 상황을 타개하고자 “좀 더 명확한 스펙을 정리한 문서”와 같이 새로운 프로세스 도입을 시도하는데 이는 생산성을 저하 시킬 수 있는 행위입니다. 피쳐 플래그와 같은 기능도 안정성을 위해 도입되는 것은 이해하지만, 너무 많은 플래그는 복잡한 조합으로 이어지며 관리하기 어려워집니다. 이런 상태에서 제대로 된 테스트를 하는 것은 어렵다고 합니다.

Guler에 따르면 애자일이 모두에게 맞지는 않는다고 합니다. 애자일 하면 대표적으로 언급되는 스프린트라는 개념은 모든 제품에 맞는 형태는 아니라고 합니다. 또한, “변화에 대응하라” 라는 항목도 “변화”가 개발 과정 막바지에 계속된다면 문제가 될 것이라고 합니다. Guler는 애초에 요구 사항을 잘 정리한 문서로 시작하지 않는 것도 이해되지 않는다며 “요구사항이 잘 정의 된 문서는 소프트웨어 개발 프로세스에서 중요합니다” 라고 주장했습니다.

마지막으로 Guler는 페어 프로그래밍은 상당히 비효율적인 개발 방법이라고 언급하고 모든 구성원이 코드 관리를 하는 것은 아무도 코드 관리를 하지 않는 것과 같다고 합니다.

그의 글을 지지하는 몇 몇의 개발자들은 “비즈니스나 개발에 대해 아무것도 모르는 애자일 코치들이 도입한 애자일 방법론 때문에 일이 너무 고통스럽다” 라고 공감했으며 “이들보다 실제로 일을 할 수 있는 인원을 고용하는 게 더 도움이 될 것”이라고 주장했습니다.

애자일에 대한 또 다른 부정적인 의견은 애자일이 일종의 종교처럼 변모한 것입니다. 애자일 방법론이 효율성과 코드 품질을 높여준다는 맹목적인 믿음 아래 과도하게 사용되기 때문입니다.

Guler는 자신의 블로그를 통해 이미 무너진 상호 신뢰, 커뮤니케이션, 팀 합은 어떤 프로세스를 도입해도 개선할 수 없다고 피력했습니다.

---

원글: https://devclass.com/2024/02/01/agile-process-can-spur-micromanagement-and-poorly-maintained-code-says-ex-google-software-engineer/