1일1개 (35) - 애자일은 신이야

1일 1개념정리 24.08.09.금 ~ 

 

큰 결정에 큰 동기가 따르지 않을 때도 있다. 하지만 큰 결심이 따라야 이뤄낼 수 있다.

무조건 무조건 1일 1개의 개념 정리하기 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

---

#35. 애자일

SW공학개론에서 굉장히 혁신적으로 비춰지는 게 바로 애자일이다. 서류가 없어지고 코딩중심이라는 게 핵심이다. 그리고 고객의 요구사항이 바뀔 수도 있다는 게 전제라서 불확실성이 높고 변동성 큰 상황에서 유용하며, 팀이 반복적인 개발 주기를 통해 프로젝트를 개선하는 것을 지향한다. 오늘은 애자일에 대해 알아봅시다.

애자일의 핵심 원칙

사실 따지고 보면 간단하다. 고객중심, 변화수용, 코딩중심 요정도로 요약할 수 있겠다.

1. 고객 협업 : 고객과 지속적으로 소통하고 요구사항을 파악해 반영함
2. 변동성 : 계획보다 고객의 요구 변화에 더 가치가 있다고 생각하고 이를 반영함
3. 반복 주기 : 짧은 주기(2-3주 정도)로 기능을 개발하고 점진적으로 제품을 완성한다.
4. 코딩 중심 : 완벽한 문서보다 작동하는 SW를 더 중요하게 여긴다.
5. 점진적 개발 : 각 반복 주기마다 회고를 통해 작업 방식을 지속적으로 개선한다.

 

애자일의 장점

애자일은 확실히 자질구레한 것들이 빠져서 좋아보인다. 장점부터 이야기하면 리스크가 줄고, 유연하다는 것이 핵심!!!

1. 빠른 피드백 수용 : 고객과의 지속적인 소통을 통해 요구사항 변경을 빠르게 반영할 수 있어, 고객 만족도가 높아짐
2. 리스크 감소 : "작은 단위"로 진행하기에 개발 리스크를 줄이고, 이슈를 조기에 발견하고 수정할 수 있다.
3. 유연성 : 계획이 변경되더라도 빠르게 적응할 수 있어 불확실한 프로젝트에 효과적이다.

이 외에도 팀 생상성 증가, 품질 향상 등도 이야기할 수 있는데 부차적인 것들이니 굳이 쓰진 않았다.

 

애자일은 무적인가 ? - 단점

공부를 하다보면 마치 애자일이 무적처럼 보인다. 모든 상황에서 애자일이 혁신적이고 반드시 도입해야하고 선진문물이고 .... 그렇게 비춰지는데, 그정돈 아니다. 주요 개발론은 맞지만 한계와 단점도 존재한다.

1. 대규모 프로젝트에서 오히려 복잡할 수도 : 대규모 프로젝트에서는 애자일의 유연성이 오히려 복잡하게 만들 수 있다. 변동성이 크면 안되는데 계속 요구사항을 받아들이다보니, 진행이 안될 수 있다. 이럴 땐 전체적인 시스템 구조와 요구사항을 미리 정의하는 폭포수(Waterfall) 모델이 적합할 수 있다.
2. 고객 요구사항이 고정된 경우는 애자일 불필요 : 고객의 요구사항이 명확하고 변동성이 작은 경우, 애자일의 반복적인 작업이 불필요할 수 있다. 이때는 폭포수 모델을 통해 명확하게 계획을 수립하고 진행하는 것이 효율적이다.
3. 안정성을 매우 높여야 하는 경우 : 은행, 의료, 항공 등 안정성이 매우 매우 중요할 땐 검증이 늘어나야한다. 그래서 규칙적인 단계와 엄격한 문서화가 필수인 V-모델이 적합할 수 있다.
4. 고객 참여가 어려운 경우 : 애당초 고객과 소통이 장점이었는데, 소통이 불가능하다면 혹은 어렵다면 굳이 애자일로 하지 말고, 프로토타이핑 모델을 도입하여 프로토타입을 보여주는 게 낫다.

 

상황에 따른 다른 개발 방식 적용 예시

앞서 이야기한 폭포수, V모델 등에 대해 좀 더 자세히 알아보자.

 

1. 폭포수 모델 (Waterfall Model)

• 상황 : 대규모 & 고정된 요구사항
• ex) 정부기관의 데이터베이스 구축 프로젝트는 법, 표준 등 준수해야하니까 요구사항 명확하고 변동성 낮음.

2. V-모델

• 상황 : 안전과 품질이 중요해서 테스팅 많이 해봐야 할 때
• ex) 의료 기기 SW는 철저하게 품질 확보해서 오류 방지해야하므로 검증이 많이 들어가야함

3. 프로토타이핑 모델 (Prototyping Model)

• 상황 : 요구사항이 불명확하고, 사용자 경험이 중요한 프로젝트. 그리고 앞선 예시처럼 사용자와 이야기 많이 못할 때도 프로토타입 모델 써서 목업 보여주고 피드백 받는 것도 좋음.
• ex) 새로운 소비자 애플리케이션 개발. 초기에는 고객의 요구사항이 명확하지 않으니까 빠르게 프로토타입을 개발해 보여주고 피드백으로 개선하는 게 효과적임.

4. 나선형 모델 (Spiral Model)

• 상황 : 리스크가 큰데 요구사항도 계속 변화할 가능성 높은 경우 (리스크 관리 모델)
• ex) 대규모 IT 시스템 통합 프로젝트. 이 프로젝트는 초기 단계에서 요구사항을 완전히 파악하기 어렵고, 다양한 이해관계자의 요구를 수용함. 그래서 나선형 모델로 반복적으로 개발하고, 위험 요소 관리해서 점진적으로 요구사항을 반영함.