소프트웨어 개발 주기와 애자일

소프트웨어는 단순히 이거 만들자~ 해서 만들수도 있겠지만

 

소프트웨어 개발 프로젝트를 진행함에 있어서 일정 프로세스가 없다면 왁자지껄 소프트웨어가 완성될 것이다.

아니 완성되지 않을 가능성도 있다.

 

그런 이유로 소프트웨어 개발 주기란 것이 나왔을 것이라 본다.

일명 SDLC( Software Development Life Cycle )은 소프트웨어 개발의 계획, 개발, 테스트, 배포를 총칭한다.

간단하게 현재 현업에서 경험하고 있는 것을 보자면 분석, 설계, 구현, 테스트, 유지보수( 기능추가, 버그패치 )의 절차로 진행된다. 

 

과거에도 여러 시행착오를 거치면서 많은 소프트웨어 개발 주기 모델들이 있었을 텐데 

그 중에서도 유명한 폭포수 모델이란 것이 있다. 제조업을 벤치마킹하여 차용된 방식으로 현재는 잘 쓰이지 않는다.

그 이유는 여러가지 있겠지만 개인적인 판단으로는 아래와 같은 이유가 가장 큰 이유일 것이라 본다.

폭포수 모델은 분석->설계->구현->테스트->배포->유지보수 순으로 진행되는데 분석 및 설계에 상당한 시간이 할당되게 되는데 설계가 완료된 이후 개발에 착수하게 되면 설계에 어떠한 변경사항도 반영할 수 없다는 단점이 있다.

 

물론 여러 장단점이 있겠지만 이 글에선 생략하도록 한다.( 궁금하다면 태그된 도서를 읽어보시길 바란다. )

 

기술이 발전할수록 소프트웨어로 여러가지를 해낼 수 있기에 소프트웨어는 점점 복잡해져간다.( 물론 기술도 너무 많아서 복잡하다. )

거기에 더하여 세상도 하루가 다르게 변해가고 있고 사용자의 요구사항도 시시각각 변하기 마련이다.

그러므로 폭포수 모델에서 설계 완료후 어떠한 변경사항도 반영할 수 없다는 것이 최대의 단점이라 생각한 것이다.

 

서론이 길었는데 위와 같은 이유도 포함하여 애자일 방법론이 등장했다고 본다.

애자일이란 용어는 빠르고 쉬움을 뜻하고 SOT( self-organized team : 모든 구성원이 참여해 문제를 정의하고 해결하는 팀 )의 협업을 통해 소프트웨어가 개발되는 방법론이다.

애자일의 핵심은 빠르고 유연하며 조금씩 발전되는 소프트웨어 개발을 통해 목표를 계속 수정해나가는 것이라고 한다. 그러므로 폭포수에서 치명적으로 작용했던 문제가 해소될 수 있으므로 현재는 많은 곳에서 애자일 방법론이 쓰이고 있다. 물론 폭포수 모델처럼 A-B-C 이렇게 딱딱 정해진 절차가 있는 것은 아닌거 같고 아래의 12가지 원칙만 지켜진다면 애자일 방법론을 적용하고 있다고 봐도 무방할 것이다.

 

 

애자일 원칙

위의 페이지가 한국어로 번역된 페이지며 책에 요약된 12가지 원칙은 아래와 같다.

1. 고객을 만족시키기 위해 소프트웨어를 빠르고 지속적으로 배포한다.

2. 새로운 요구 사항은 개발 후기에도 기꺼이 받아들인다.

3. 동작 가능한 소프트웨어를 몇 달 주기가 아닌 몇 주 주기로 배포한다.

4. 업무 담당자와 개발자 간의 긴밀한 소통을 지향한다.

5. 믿을 수 있는 동기부여된 개인들로 구성된 팀이 소프트웨어를 개발한다.

6. 직접 만나 얼굴을 보며 이야기하는 것이 최선의 의사소통이다.

7. 동작하는 소프트웨어가 가장 중요한 진척의 척도다.

8. 일정한 속도를 유지함으로써 지속 가능한 개발을 추구한다.

9. 좋은 기술과 설계를 향해 지속적으로 관심을 기울인다.

10. 단순함을 중요시한다.

11. SOT( self-organized team )를 추구한다.

12. 새로운 환경에 지속적으로 적응한다.

 

처음에는 복무신조 같기도 하고 뭐 이리 많아 라고 생각했지만 대부분 공감되는 내용이다.( 그러나 생가보다 현업에서 지키기가 힘들다. )

자신의 팀원들과 함께 작은 프로젝트라도 진행한다면 한번 위의 원칙들을 되새기며 좀 더 효율적으로 진행해보길 바란다.

 

---

본 글은 아래의 도서를 참고하여 작성되었습니다.

초보를 위한 젠킨스2 활용 가이드 2/e( 원제 : Learning Continuous Integration With Jenkins )