⛔️ 본 포스팅은 개발력이 많이 떨어지는 초보 개발자의 시점에서 작성한 글이기에 부정확한 정보가 다수 포함되어 있을 수 있으며, 그런 요소를 발견한 분께서는 댓글이나 이메일로 알려주시면 감사하겠습니다. 항상 유익한 컨텐츠를 위해 노력하겠습니다^-^.

Intro

우연히 모빈켈님의 글(Dick Side of the Dev II)을 보았다. 개발 업계의 좆같은 면에 대해 이야기하는 시리즈의 두번째 포스팅인데, 실제 개발 사회에서 애자일 방법론이 어떤 식으로 이용당하고 있는지 간략하게 나와있다.

😂 자세한 내용이 궁금하다면 해당 포스팅 참고 바람.

나도 회사에서 새로운 프로젝트가 시작되면 데일리 스크럼을 진행하기도 하고, "애자일하게 갑시다~" 등의 말도 심심치 않게 들어왔다. 모빈켈님의 글을 보면서 '나는 정말 애자일하게 개발하고 있는가?' 라는 생각이 들어 이번 기회에 애자일 방법론에 대해 정확히 짚고 넘어가야 할 것 같았다.

When I Heared it First

나는 애자일 방법론이라는 용어를 대학 졸업프로젝트를 진행하면서 처음 들었다. 우아한 형제들에 재직중이신 선배님과의 산학협력멘토링 중에 얻은 조언이었다.

🧑🏻‍💻 : 우리 프로젝트를 애자일하게 진행해 볼까요?
🧑🏻‍💻 : 애자일 문화란 ...어쩌구 저쩌구...

사실 선배님께서 애자일 문화에 대해 간략하게 설명해주셨는데 뭐라고 하셨었는지 정확하게 기억이 안 난다. 죄송하빈다. 선배님께서는 현업에서 실제로 사용하고있는 방법이라며 애자일하게 개발할 수 있는 여러 요소들을 알려주었다.

우선 1주 단위로 스프린트를 나누어 매주 금요일 저녁 8시에 온라인에서 모여 일주일 간의 경험과 성과 그리고 이슈사항 등을 공유했다. 이를 스프린트 회고라고 했는데 이번 스프린트의 목표는 달성했는지, 어떤 것을 잘 했고 어떤 것을 못 했는지, 어떤 이슈사항이 있었고 어떻게 수정할 것인지, 어떤 것을 새롭게 배웠고 다음엔 어떻게 할 것인지 일주일 간 해왔던 것들을 점검하며 반성할 수 있는 시간이었다.

회고가 끝난 후에는 스프린트 계획이 시작되었다. 회고에서의 점검과 반성을 기반으로 다음 스프린트에서는 '뭘' '어떻게' 잘 할 것인지 새로운 계획을 세웠다. 매주 반복되는 반성과 학습을 통해 팀 전체가 빠르게 배우고 성장할 수 있었다.

아 그래서 애자일이 뭐냐고 ㅋㅋ

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Indivituals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contact negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

© 2001 - 2022 Agile Manifesto Authors
This declaration may be freely copied in any form, but only in its entirety through this notice.

애자일 소프트웨어 개발 선언문 한국어판

애자일 방법론은 어느 특정 개발 방법론을 가리키는 말이 아니라 말 그대로 '애자일한' 방법론이다. 소프트웨어를 애자일하게 개발할 수 있도록 하는 다양한 방법론 전체를 말하는 것이다. 위의 애자일 소프트웨어 개발 선언문을 보면 애자일한 것이 무엇인지 파악할 수 있다. 서로 간의 의사소통, 문서작성보다 기능구현, 고객과의 협력, 변화에 빠르고 유연하게 대응 <- 이런 것들을 중시하는 방법론이면 모두 애자일 방법론이 될 수 있다는 뜻이다.

문제는 바로 여기에서 출발한다. 많은 개발자들이 여기까지만 안다는 것이다. 그렇기 때문에 아래와 같은 불상사가 발생하는 것이다.

---

'애자일'은 이 업계에서 쉽게 접할 수 있는 단어이고 방법론이다. 사실 "애자일하게 해 주세요"의 뜻은 그냥 아무때나 기능과 기획을 마음대로 바꿀 것인데 그 때마다 순응 해달라는 말이다. 또는 '알잘딱깔쎈' 방법을 사용할 것인데 토달지 말고 니가 열심히 하라는 뜻이다.

---

출처 : Dick Side of the Dev II - 모빈켈

Twelve Principles of Agile Software

애자일 선언문 이면에는 12가지 원칙이 있다. 단순히 의사소통하고, 문서작성 안 하고, 고객의 니즈를 파악하고, 변화에 빠르고 유연하게 대응한다고 해서 애자일한 소프트웨어 개발이 아니라는 말이다. 12가지 원칙을 살펴보면 작동하는 소프트웨어를 자주 전달하라, 작동하는 소프트웨어가 진척의 주된 척도이다. 라는 말이 있다. 이것이 애자일 방법론의 핵심이라고 생각한다. 일단 뭐가 됐든 프로젝트 진행의 판단 척도가 실제로 동작하는 결과물이라는 것이다.

위 그림은 전통적인 방식과 애자일한 방식의 차이를 명확하게 보여준다. 전통적인 방식은 최종 완성이 되기까지 그 중간 단계에서 제품이 제 기능을 할 수 없다. 하지만 애자일한 방식으로 개발한다는 것은 중간 단계에서 바퀴가 굴러가는 최소 기능을 하는, 즉 '작동하는 소프트웨어'가 만들어져야 한다는 것이다. 이를 최소기능제품, 혹은 MVP(Minimum Viable Product)라고 하며, 이 MVP를 기준으로 프로젝트를 판단하고 고객과 협력하며 변화에 대응해 새로운 기능을 추가하면서 제품을 지속적으로 향상시킨다. 작동하는 소프트웨어가 프로젝트 진행의 판단 척도여야 한다. 단순히 변화에 대응하고 유연하게 대처한다고 다 애자일한 것은 아니다. '알잘딱깔쎈'이 아니다.

그렇다면 내가 졸업프로젝트를 진행했던 방식은 애자일한 방식이었을까?

스크럼

내가 졸업프로젝트를 진행했던 방식은 애자일 방법론 중 스크럼 방법론을 흉내낸 방법이라고 불 수 있다. 실제 스크럼은 스프린트마다 실제로 동작하는 제품을 개발해, 매 스프린트마다 제품을 테스트하고 스프린트 회고와 계획을 통해 새로운 기능을 추가하고 이런 반복되는 일련의 과정들을 통해 제품을 지속적으로 향상시키는 방법이다. 아주 애자일하지 않나?

결론

졸업프로젝트에서 우리 팀은 스프린트 회고와 계획을 통해 아주 '애자일한' 스크럼을 진행한 것처럼 착각할 수 있다. 실제로 나는 착각했고, 나는 아주 애자일하게 어플리케이션을 개발했다고 생각했다. 그러나 아주 중요한 것이 빠졌다. 바로 프로젝트 진행의 판단 척도의 역할을 하는 '작동하는 소프트웨어'이다.

우리 팀의 스프린트 회고와 계획에서 중요했던 것은 그저 내가 맡은 일을 얼마나 해냈고, 어떤 이슈사항이 있었고, 앞으로 어떻게 하겠다고 다짐했던 것이 다였다. 우리가 개발하는 제품에는 전혀 관심이 없었다. 우리는 전혀 애자일하게 '소프트웨어'를 개발하지 못했다. 우린 애자일하게 '자기개발'했다..;