나는 지금으로 부터 약 3년전
프로젝트 BEP라는 태그로 내부 교육을 위한
초안으로 글을 작성한 적이 있다.
그리고 개발 방법론에 대해 이야기 할때
워터폴과 애자일에 대한 이야기 해야만 했는데
비교적 애자일에 대한 경험이 부족했기 때문에
논의를 이어나가기 힘들었고
애자일에 대한 부분은 넘어간 적이 있다.
물론 그럴싸하게 작성할 수는 있으나
이 프로젝트는 내 경험을 녹여내는 것이 목표였기 때문에
중단한다는 선택을 내릴 수 밖에 없었다.
하지만
어느 정도 시간이 지났고
나 또한 애자일에 대한 경험을 쌓았기 때문에
이 제 2장 개발 방법론 애자일에 대한
논의를 이어감과 동시에 초안에 대한 마침표를 찍으려 한다.
그럼 이제 애자일에 대략적인 프로세스를 살펴보자.
애자일의 프로세스를 살펴보자면
정의(define)를 내리고
만들고(build, programming, develop)
배포(Release)를 반복하는 것을 말한다.
앞서 살펴봤던 워터폴 모델을 살펴보자.
그냥 보기만 해도 애자일 방법론이 워터폴 방법론보다
프로세스가 많다는 것을 알 수 있다.
애자일 방법론의 목표를 살펴보자면
크게 4가지로 볼 수 있다.
- terative, incremental, and evolutionary(반복, 점진, 진화)
- Efficient and face-to-face communication(효율적이고 face to face 커뮤니케이션)
- Very short feedback loop and adaptation cycle(짧은 주기의 피드백 및 짧은 사이클)
- Quality focus(품질의 집중)
어렵게 말은 써있지만
많은 반복을 통해
점진적으로 프로젝트를 완성시킴으로써
반복 만큼의 커뮤니케이션과 피드백을 통해
의견을 일치시켜
좋은 품질의 소프트웨어를 만드는 것이다.
워터폴의 가장 큰 문제점은
초입 부분에 요건 및 정의(Requirements and Design)가
사실상 완벽하다고 가정하고 진행하기 때문에
상황 변화에 따라 유연하지 못함 물론이고
모두가 이상적인 커뮤니케이션 능력을
가지고 있지는 않기 때문에
완벽하게 프로그램에 대한 파악이 이루어지기란 힘들다.
어느 정도 워터폴 방법론을 경험해본 사람은
잘 알고 있겠지만
여러가지 이유와 원인에 의해
완벽하게 파악이 불가능 하기 때문에
그 다음 단계인 개발 단계에서
자주 변경이 이루어지고 개발이 지연되며
최악의 경우 프로젝트가 실패하게 된다.
그렇기 때문에 애자일에서는 이를 방지하기 위해
반복과 점진 그리고 face to face가 포인트라 할 수 있다.
따라서 뒤에 자세한 설명을 할 것이지만
무엇보다 PO(Product Owner)의 존재와 역할이 너무 나도 중요하다.
또한 문서화 작업을
워터폴에서 중요시 하는 만큼
문서화를 중요시하지 않는다.
이는 워터폴의 프로세스 중에서 설계(Design)부분을
소홀히 할 수 있다는 말인데
그렇게 된다면
프로젝트가 처음 성공적으로 완수 할 수 있다면
큰 문제가 없을 것이지만
만약 시스템 확장을 할 시기에 나타날 수 있는 변수,
예를 들어 부득이하게 개발자가 팀을 떠난다거나 들어오는 상황
클라이언트의 요구가 바뀐다던가 등의 상황에서
유연하게 대처하기 힘들 것이다.
또한 시스템의 확장이 필요한 경우
상당한 시간이 소요될 것 이다.
따라서 어떻게, 어디까지 문서를 작성할지에 대해
사전에 토론과 준비가 필요하다.
이는 해당 팀에서 여러가지 리스크를 고려해
어디까지 문서화 할 것인지에 대해
명확히 정해야 한다.
먼저 나는 문서에서 보일 법한
수 많은 단어를 나열하지는 않을 것이다.
이는 가독성을 떨어트리며
내가 가진 경험을 전달하려고 하는 글의 목적에 벗어난다.
따라서 이에 대한 내용을 최소화 하고
필요한 것들만 가져와 이야기를 하려 한다.
전개 방식은 팀 부터 시작해
프로세스를 설명하는 방식으로 이어 가겠다.
애자일 방법론에 익숙하지 않다면
먼저 그 유명한 애자일 소프트웨어 개발 선언문
[1] 을 확인하고
좀 더 세부적인 내용이 알고 싶다면
아래의 스크럼 가이드
[2] 를 참고하길 바란다.
먼저 팀 부터 살펴보자.
팀은 크게
실제 프로젝트의 의뢰인이자
프로젝트의 결과물인 프로그램의 소유자인
프로덕트 오너(PO)
프로젝트의 중재자 역할을 하는
스크럼 마스터
그리고 개발자가 있다.
이렇게 세 가지 역할에 따라 인원이 배치되며
사실상 한 팀으로 움직이게 된다.
실제 개발 프로세스는
사용하는 방법론에 따라 달라질 수 있으나
일반적으로 스크럼이라는 방법론을 사용하며
이 방법론은 스프린트(Sprint)라는 사이클로 이루어진다.
이론적으로는 1~4주를 설정 한다.
경험상 1~2주가 많으며,
1주는 조금 짧은 느낌을 많이 받았으나
애자일에 익숙하고 잘 다룰줄 아는 사람이라면
최대한의 퍼포먼스를 끌어내기에는 아주 적절하다고 생각 한다.
스스로의 문제점 뿐만아니라
팀의 문제점이 어느 부분에 있는지 파악하기 수월하며,
조금 타이트한 것이 긴장감을 주기 좋다.
물론 2주도 나쁘지 않다.
다만, 내가 스크럼 마스터라면
나는 망설임 없이 1주일 스프린트를 선택할 것이다.
전체적인 흐름은
먼저 Sprint Planning을 통해
팀 전체의 이번 스프린트 목표 및 계획 그리고 스케쥴을 확인한 후
각 팀 별로 동일하게 세부적인 작업들을 설정한다.
스프린트 종료 당일,
Sprint Review를 통해 PO와 함께
결과물들을 확인하여
결과물이 PO가 생각했던 대로 진행되고 있는지
팀 전체적으로 확인 한다.
그 다음 마지막으로
Sprint Retrospective를 통해
스프린트 사이클 내에 나타났던 문제점들을 공유하고
이에 대한 대응책을 공유함과 동시에 대응책을 세운다.
다만, 여기서 주의해야 할 점은
문제점을 파악하고 대응책을 설정하는데 의미가 있지
반성을 고백하는 자리나
누군가에게 책임이 있는지를 결정하거나
책임을 지게 하기 위한 자리가 아니라는 점이다.
물론 스스로를 환기하기 위해 또는
반성하기 위해 언급할 수는 있지만
매번 그런 방식으로 Retrospective를 진행하게 된다면
애자일을 실행하는 의미가 사라지기 때문에
충분히 주의를 할 필요가 있다.
또한 팀 전체에 문제점이 없다는 것은
사실상 있을 수 없기 때문에
Retrospective에서 문제점이 제기되지 않는 다는 것은
분명 어디에 문제가 있다고 보는 편이 좋다.
이상하게 들릴지는 모르겠지만
문제가 없다는 것 또한 문제다.
이는 팀원 중 누군가가 문제가 있음에도
문제를 제기하지 않을 가능성이 크다.
때문에 Retrospective에서
누군가에게 책임을 결정하거나
지게 하는 것이 매우 좋지 않다는 것 이다.
누구 하나의 문제가 아니라 팀 전체의 문제이다.
이는 팀원들을 소극적이게 하고,
수동적이게 하여 결과적으로 팀 전체를 둔화시킨다.
이런 상황이라면
차라리 애자일 방법론을 버리고
워터폴로 회귀하는 것이 좋을지도 모른다.
이 부분에 있어서 스크럼 마스터의 조율이 가장 중요하지 않나 싶다.
올챙이가 성장하여 개구리가 되듯이
팀도 프로그램도 단계적으로 성장하는 것이
애자일에서 가장 이상적인 상황이라고 나는 생각하고 있다.
아무리 모두가 애자일에 익숙하다고 하더라도 말이다.
점진적 개발, 빠른 커뮤니케이션의 장점을 가지는
애자일은 이론상으로 보면 완벽한 것으로 보인다.
워터폴에서 나타날 수 있는
지연 현상을 막을 수 있음과 동시에
끈임없는 PO와의 대화를 통해
제품에 대한 목표를 명확히 할 수 있고
동시에 수정을 할 수 있기 때문이다
하지만 인간의 삶이 계획대로 되지 않듯이
현실적인 몇 가지 이유 때문에
계획대로 이루어지지 않는데
이에 대한 이야기를 나누어보자.
애자일의 허와 실 : 팀 내부의 애자일에 대한 숙련도
문서 한번 읽는다고 해서
애자일을 잘 수행할 수 있는 것은 물론 아니다.
정도에 따라 다르겠지만
각자의 역할에 따른 이해와 숙련도가 부족할 경우
중요한 제품이라면 워터폴로 진행하는 것이 나을 수 있다.
최악의 경우
입으로는 프로젝트에서
애자일 방법론을 사용한다고 말하지만
실상 내부는 워터폴과 같이 움직이게 된다.
이는 애자일 방법론을 도입하는 과정에서
당연히 나타나는 문제이다.
하지만, 숙련도가 매우 낮은 경우
어떤 것이 문제이며
개선 방안 또한 도출해내기 힘들기 때문에
이 경우 어느 정도 애자일에 대한 경험을 해본 팀에게
자문을 구하는 것이 매우 좋다.
또한 이외에도 애자일 팀 내부에
경험과 기술이 부족한 주니어급의 개발자가
참여하는 경우가 꽤나 자주 발생하는데
애자일은 이론상
모두가 프로페셔널 해야하지만
주니어 개발자는 경험과 기술이 부족하기 때문에
소극적인 태도를 취하기 쉽다.
소극적인 태도는 커뮤니케이션이 중요한
애자일 방법론에서 이는 매우 치명적이다.
애자일에 방법론을 이용하는 이상
모두가 프로페셔널 해야 한다.
따라서 이 경우
조금 애자일에서 벗어날 수는 있지만
해당 팀원에게 맞는 작업물을
경험이 풍부한 시니어급의 팀원이 분배함과 동시에
가능하다면 잘못된 의견을 발언한다고 하더라도 것도
지적하지 않는 것도 좋은 방안이다.
물론 이 방법은 애자일이 목표하고자 하는 방향은 아니다.
애자일의 허와 실 : PO의 부재
가장 곤란한 경우다.
제품의 목표와 방향은
사실상 PO가 설정해야하기 때문에
PO의 부재는 애자일 방법론에서 매우 치명적이다.
PO의 부재라고 설명했지만,
여기에는 PO가 있음에도 불구하고
제대로 PO의 역할을 하지 않는 것도 포함된다.
이 경우 매우 최악의 상황이 발생하기 쉬운데
왜냐하면 제품의 방향과 책임 소재가 확실하지 않기 때문에
품질이 매우 떨어지기 때문이다.
확실한 PO가 없거나 경우
있음에도 불구하고 소극적인 경우
차라리 워터폴로 전환하는 것이 좋을지도 모른다.
애자일의 허와 실 : 개발팀 내부의 퍼포먼스에 대한 상이함
위에서 언급했듯이
애자일은 이론상으로 모두가 프로페셔널 해야 한다.
여기에서 프로페셔널에 대한 의미는 태도도 있겠지만
퍼포먼스 또한 마찬가지이다.
그렇기 때문에 최상의 결과를 가져오려면
이상적으로 사실상 모두가 시니어급 레벨의 개발자가 되어야 한다.
하지만, 현실은 그렇지 않기 때문에
이러한 갭이 크면 클 수록
상대적으로 뛰어난 개발자가 과부화가 이루어지기 쉽다.
따라서 특정 팀원이
과부화가 발생하지 않게 주의가 필요하다.
이 경우 팀 전체에 이를 공유하고
과부화가 일어나지 않도록 목표 설정을 바꿀 필요가 있을 것이다.
애자일의 가장 큰 장점은 빠른 제품과 대응인데
팀이 비대해진다면
이러한 장점을 잃어버리기 십상이다.
팀이 비대해지면,
그 만큼 스프린트 이벤트에 시간을 쏟아야 하며
누가 어떤 작업을 어떻게 하고 있는지,
문제는 없는지 파악하기가 매우 힘들다.
개인차야 있겠지만
인원 수가 많으면 많을 수록
시간적으로 그리고 심리적으로 말하기 매우 힘들어진다.
따라서
실제로 소수의 인원으로 스프린트를 진행했을 때
퍼포먼스가 좋은 느낌을 받았다.
팀이 비대해진다면 적절하게 분할하는 것이 좋아보이나
이에 대한 좋은 방안은 아직 파악하지 못했다.
애자일의 장점은 무엇보다 빠른 개발 속도에 있다.
다만, 이런 빠른 개발을 보장하기 위해서는
무엇보다 반복적인 작업을 줄일 필요가 있는데
그 중 하나가 문서 작성이고 또 다른 하나가 테스트이다.
품질을 높이고 시스템의 안정성을 높이기 위해서는
가능한 많은 테스트를 진행하는 것은 당연하다.
워터폴의 경우 단계적으로
유닛 테스트(Unit Test), 통합 테스트(Integration Test),
시스템 테스트(System Test)를 기본으로
내부 로직의 변경이 있을 시
회귀 테스트(Regression Test)를 통해 품질을 높인다.
하지만, 문제는 시간이 너무 많이 소요된다는 것이고
더 큰 문제는 이러한 지루한 작업을
하고 싶어 하는 사람이 사실상 없다는 것이다.
애자일의 경우
짦은 시간 동안 많은 반복을 통해 프로토타입을
점진적으로 개발해 나가기 때문에
워터폴에서 자주 사용하는 테스트를
한 스프린트 내에 진행하기에는 사실상 무리가 있다.
따라서 비교적 최근에 워터폴 또한
일반적으로 테스트 자동화를 하는 편이지만
애자일의 경우는 사실상 테스트 자동화는 필수에 가깝다.
이 경우 두 가지 선택을 해볼법 한데
첫 번째로 테스트 자동화 툴을 사용하는 것
두 번째로 테스트 자동화 프레임 워크를 사용하는 것이다.
먼저 잘 만들어진 첫 번째의 테스트 자동화 툴을 도입하는 것이 가장 베스트다.
이 경우 어느 정도 비용이 소모되지만
빠르게 그리고 좋은 품질의 앱을 만들고 싶다면 툴을 이용하는 것이 좋다.
비용 조금 아낀다고 프로젝트가 지연되는 것보다 낫지 않은가?
리스크는 최대한 줄이는 것이 좋다.
두 번째는 언어마다 존재하는 테스트 자동화 프레임워크를 이용해
테스트 코드를 작성하는 것 이다.
이 경우 개발자가 직접 테스트 코드를 작성해야 한다.
다만, 앱이 비대하면 비대할 수 록
이 테스트 코드 또한 비대해지며
이를 위한 시간 또한 그 만큼 증가하게 된다.
애자일이란 무엇인가?
짧게 줄여보자면
빠른 제품 개발을 위한 개발 방법론이다.
이는 워터폴에서 나타나는 문제를 해결하기 위함이다.
물론 점진적으로 개발이 이루어지기 때문에
개발 과정 중에는 완성도가 떨어져 보이겠지만 말이다.
하지만,
워터폴에 익숙한 개발자라면 인식하고 있듯이
처음부터 요건 정의를 완벽하게 하기란
사실상 불가능에 가까우며
이것이 실현되었다고 하더라도
현실 상황에 따른 인프라 구축의 불가,
인원 충원의 불가, 기술적인 문제 등
프로젝트를 진행하면서 수 많은 문제에 직면하게 될 것이다.
이는 개개인의 노력,
팀 전체의 노력으로 해결 할 수 있는 문제가 아니다.
이외에도 여러가지 문제가 있겠지만
가장 큰 문제는 서로에 대한 신뢰이다.
신뢰가 없기 때문에 팀원 뿐만 아니라
의뢰를 하는 사람들 또한 소극적으로 변하게 된다.
이런 태도는 점점 다른 팀원들에게도 영향을 주며
결국 팀 전체적으로 잠식 된다.
결과적으로 애자일 프로세스를 이용하고 있음에도 불구하고
워터폴보다 느린 상황에 놓여지는 것은 어찌보면 당연하다.
나는 실제로 이런 프로젝트를 여럿 본 적이 있다.
물론 이는 워터폴에서
새로운 애자일이라는 프로세스 도입에 따른
시행착오의 가능성이 크겠지만 말이다.
그런 의미에서 애자일은
스프린트가 진행되가면서
많은 커뮤니케이션을 통해 서로에게 신뢰감을 줄 수 있다.
나는 이 부분이 애자일에서 가장 큰 장점이라고 생각 한다.
따라서 애자일 방법론이
최고의 방법론이라고 할 수는 없겠지만
최선의 방법론이라고 나는 평가한다.
