[CS] 소프트웨어 개발방법론(폭포수 모델, 애자일, 데브옵스)

소프트웨어 개발 방법론 ?

 소프트웨어를 개발하는 방법에 대한 이론, 소프트웨어 개발과정, 절차, 방법, 산출물, 기법 도구 등을 체계적으로 정리하고 표준화 시킨 것을 말한다.

 

폭포수 모델

Why ?

1960년대 까지의 "선 코딩 후 수정"의 문제를 해결하기 위해 로이스가 제시한 모델이다.

 

How ?

요구분석 -> 설계 -> 구현 -> 테스트 -> 유지보수 순으로 이루어지고, 하향식 / 순차적인 개발 방식이다. 앞 단계가 완료되어야 다음 단계로 넘어갈 수 있다.

 

Major Rules

• 앞 단계가 끝나야 다음 단계로 이동
• 다음 단계로만 이동이 가능
• 명세(문서)에 기반한 구현

 

Good Points

• 단계가 명확하고 이해하기 쉽다.
• 대규모 프로젝트도 관리하기 쉽다.(모든 일정이 산출되어, 관리 측면에서도 일정 조정 등 유리한 부분이 많다.)
• 단계별 산출물이 존재한다. (관리자나 개발자나 큰 메리트, 협업 개발에 관리 용이)
• 요구사항 대로 완성된다.

 

한계점

• 요구사항은 애초에 명확하지 않다.
• 나중 단계에서 앞 단계의 문제가 드러난다.
• 요구사항은 언제든지 바뀔 수 있다.
• 피드백 시점이 너무 늦다.

 

 

애자일(Agile)

Why ?

폭포수 모델의 피드백 부재와 변화가 어려운 문제를 해결하기 위해 나타남.

처음에 모든 요구사항을 확정짓는 것은 애초에 불가능하다.

관리만을 위한 방법론은 아무것도 바꿀 수 없다.

 

애자일 선언문

공정과 도구 보단 개인과의 상호작용을,

포괄적인 문서보다 작동하는 소프트웨어를,

계약 협상보다 고객과의 협력을,

계획을 따르기보다 변화에 대응하기를,

더 가치있게 여긴다. (전자가 중요하지 않다는 이야기는 아니다.)

 

본질

비즈니스 요구변화를 민첩하게 수용

실패를 두려워하지 말자(실행하고, 빨리 실패하고, 배우고, 다시 시도하라)

 

주요 방법론으론 Scrum, XP가 있다.

 

Scrum

짧은 단위를 반복(스프린트)

1. 모든 할 일은 백로그로 관리(스프린트 진행 시 구체화)

2. 한 스프린트(2~4주)의 할일만 정해서 개발 단계를 빠르고 짧게 반복

3. 한 스프린트가 끝나면, 제품 출시(빠른 릴리즈)

4. 고객한테 받은 피드백은 백로그에 추가하여 다음 스프린트에 반영.

=> 1~4번을 무한 반복하며, 지속적으로 개선한다.

 

장점

• 변화에 빠르게 대응이 가능하다.(계획, 기능 변경이 쉽고, 문제점을 조기 발견, 고객이 원하는 기능을 빠르게 출시할 수 있다.)
• 현실적인 목표 수립이 가능하다.
• 불필요한 관리 비용이 감소한다.(전체 일정을 무의미하게 관리할 필요가 없다.)
• 높은 고객 만족도를 지닌다.

 

Before Agile

• 경영진의 지원 부족 -> 통제력 상실 우려, 전체 일정이 없으니 경영진 입장에서는..
• 애자일과 기업문화의 충돌
• 적용 시 초기 적응이 어려움

 

After Agile

• 잦은 요구 사항 변경 -> 코드품질이 하락하고, 리팩토링이 자주 생략됨, 잦은 재설계가 일어남.
• 빠르기만한 릴리즈 -> 충분히 테스트되지 않은 완성도 낮은 기능이 출시됨.
• 이름만 애자일인 막 코딩 -> 개발 단계를 생략한 채 그냥 개발하고 고치는 관행으로 복귀.

 

애자일을 성공하려면 ?

팀원의 역량강화가 필수!

각자가 장인 정신을 가지고 자기 역량을 발전시켜야 점차 달성이 가능하다.

애자일 달성을 위한 연습

- Clean Code

- OOP

- TDD(테스트 주도 개발)

- Refactoring

- Pair Programming

- Code Review

 

한계점

규모가 큰 회사일 수록 개발팀, 테스트팀, 운영팀이 분리되어 있으며,

애자일팀이 빨리 개발해도 테스트팀의 검증이 늦어지거나 운영팀에서 배포를 하지 못하면 빠른 릴리즈가 안되는 문제 발생.

결국 이미 완료된 스프린트 여러 개가 쌓이며 폭포수 모델처럼 됨.

 

 

데브옵스(DevOps)

Why?

개발을 하고도 빠른 배포가 불가능한 문제를 해결

개발(Development)과 운영(Operations)을 하나처럼

- 애자일로 빠른 시간에 개발하고, 데브옵스로 빠른 시간에 배포하자.

 

How?

• 통합, 빌드, 테스트, 배포, 모니터링 등 개발 사이클의 모든 부분을 신뢰가능한 수준으로 자동화하면, 개발에서 배포까지 빠르게 반복.
• 현실적인 제약을 해결하여, 애자일의 이상적인 목표(빠른 릴리즈) 달성.

 

Good Points

• 개선 -> 배포 -> 피드백 -> 개선 고리형성을 발목잡는 느린 배포 문제를 해결해서 애자일을 정상 작동하게 해줌.
• CI/CD 및 전달, 구현~릴리즈 까지 모든 부분이 자동화되어 높은 효율을 보임.

 

오해..?

• 모든 과정을 신뢰 가능한 수준으로 자동화가 현실적으로 어렵다.
• 개발자가 테스트, 운영, 다하는 것? 자동화가 되기 전이라면 어려운 문제.
• 전문성 및 책임 문제가 있을 수 있다.

 

데브섹옵스(DevSecOps)

더 이상 보안을 별개로 두고 개발을 하면 안된다.

- 애자일로 빠른 시간에 개발하고,

- 데브옵스로 빠른 시간내에 배포하기 전에 보안을 챙기자.

 

How ?

기존 데브옵스 과정 전반에 자동화된 보안 취약점 진단을 추가한다.

특정 파이프 라인이 아닌 자동화 파이프 라인 모든 과정에 보안이 고려되어야 한다.

 

딜레마

팀 전체가 보안에 중점이 되어 보안은 모든 사람의 책임이 되고, 경계가 모호해진다.

모든 개발자가 보안전문가는 아니며, 자기 분야가 아닌일에 책임을 지기 어렵다.

 

결론

무엇이 최선일까 ?

개발 방법론이 아니라 이해가 중요하다.

당신은 스스로 합리적인 판단을 내릴 수 있다.

과거와 현재를 이해하라, 그리고 현재 필요한 것들을 적용.

그러면 미래에 판단할 수 있는 데이터를 얻을 것이다.

 

 

SW 공학 Technical 세미나 (소프트웨어 개발 방법론 및 프로세스)

https://www.youtube.com/watch?v=Tfgh9oNhtmA