1일1개 (35) - 애자일

1일 1개념정리 24.08.09.금 ~

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

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

#35. 애자일

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

애자일의 핵심 원칙

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

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

애자일의 장점

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

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

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

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

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

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

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

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

1. 폭포수 모델 (Waterfall Model)

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

2. V-모델

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

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

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

4. 나선형 모델 (Spiral Model)

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

저작자표시

시 쓰는 개발자