소프트웨어 개발 방법론이란?

소프트웨어 개발 방법론은 소프트웨어를 개발하는 과정에서 필요한 절차, 도구, 활동, 산출물 등을 체계적으로 정의하고 표준화한 것이다.
이를 통해 효율적이고 품질 높은 소프트웨어를 개발할 수 있다.

• 왜 소프트웨어 개발 방법론이 필요한가?
  • 소프트웨어 개발은 복잡하고 다양한 요소들이 병행적으로 진행되어야 하기 때문에 표준화된 방법이 필요하다.
  • 또한, 소프트웨어 개발 과정에서 발생하는 문제점을 미리 파악하고 예방하기 위해 개발 방법론을 사용한다.

📘 소프트웨어 개발 방식의 변화

💬 소프트웨어 개발 방식의 등장

• 초기에 소프트웨어가 개발되는 과정에서는 별도의 방법론이 없어, 개발자들이 자신만의 방법으로 개발을 진행했다.
• 그러나 소프트웨어 개발의 증가와 대규모의 복잡한 시스템을 개발하는 과정에서 많은 문제가 발생하였다.
• 이에 따라, 소프트웨어 개발 방식의 체계화와 표준화를 원하는 목소리가 커졌고 이에 따라 대두된 최초의 소프트웨어 개발 방식이 폭포수 모델이다.

💬 시대에 따라 변하는 개발 방식

• 앞서 언급했던 폭포수 모델 이외에도 객체지향 프로그래밍이 대두되면서 객체지향 분석 및 방법론이 등장했다.
• 이후 선형적인 구조의 폭포수 모델을 보완하면서도 유연하고 적응성 있는 개발 방법인 애자일 방법론이 등장하여 현재까지 발전해오고 있다.

📗 폭포수 모델

💬 폭포수 모델이란?

다음 그림은 폭포수 모델의 초기 모습이다.

요구사항 기술 → 설계 → 구현 → 시험과 디버깅 → 설치 → 유지보수

• 폭포수 모델은 개발 과정을 단계별로 구분하여 개발하는 방식으로 개발 흐름이 마치 폭포수처럼 이뤄진다는 점에서 이러한 이름이 붙었다.

💬 폭포수 모델의 장단점

• 장점
  • 프로젝트 초기 단계에서 요구사항을 분석하고, 설계할 때 사용하기 적합하다.
  • 각 단계가 일련의 과정으로 이루어지므로 전체적인 개발 과정을 파악하고 계획하기 용이하다.
  • 각 단계가 완료되면 다음 단계로 진행하기 전 반드시 검증을 거치므로 오류를 최소화할 수 있다.
• 단점
  • 각 단계가 선형적으로 이루어지므로 client의 요구사항이나 피드백을 수용하기 어렵고 개발 중간에 문제가 발생하면 이를 수정하기가 어렵다.
  • 결과에 대한 test는 단계의 가장 마지막에 이뤄지므로 test는 오류나 결함을 수정하기 어렵고 고객의 요구사항과 개발 결과물에 괴리가 있을 수 있다.

📙 애자일 방법론

💬 애자일 방법론이란?

Agile : 날렵한, 민첩한, 기민한

소프트웨어를 더 빠르게, 유연하게, 효율적으로 개발하기 위한 방법론

• 애자일 방법론은 폭포수 모델에서의 문제점, 즉 요구사항 변경이나 추가에 대응하기 어렵다는 점을 극복하고자 한 것이다.
• 애자일 방법론은 소프트웨어 개발 과정에서 변경에 유연하게 대처할 수 있도록 하는 것을 목적으로 한다.
• 애자일 방법론은 포괄적인 문서보다 실행 가능한 소프트웨어를 우선한다.

💬 애자일 방법론의 장단점

• 장점
  • 짧은 개발 주기와 반복(iteration) 개발으로 빠른 개발과 출시 가능하다.
  • client 요구사항이나 계획 변경에 대한 대응력이 높아 변경이 용이하고 client 만족도를 높일 수 있다.
  • 테스트를 통해 위험을 미리 파악하고 관리 가능하다.
• 단점
  • 확정되지 않은 계획 및 요구사항으로 반복적인 유지보수 작업이 많고 개발 진행 시 이해하지 못하고 진행하는 부분이 생긴다.
  • 이 때문에 높은 의사소통 능력과 적극적인 참여를 하는 팀원이 필요하다.
  • 계획이 확정되지 않아 예산 및 일정 관리에 어려움을 겪는다.

📌 SCRUM은 뭐지?

• 프로젝트를 애자일 방식으로 진행할 때 프로젝트를 스프린트 단위로 나누어 팀 내에서 회의를 통해 문제를 해결하는 방식이다.

• SCRUM과 밑에 설명할 3가지 개발 방법론 모두 애자일 방법론의 하위 개념으로서 개발 프로세스의 일부를 담당하고 있지만 병렬적인 구조는 아니다.

• 스크럼은 프로젝트 관리 방법론 중 하나이며 TDD, BDD, DDD 등은 소프트웨어 개발 방법론이다.

💬 TDD

Test Driven Development, 테스트 주도 개발

테스트가 개발의 중심이 되는 개발 방법론으로 테스트를 먼저 작성하고 그에 해당하는 코드를 작성하는 개발 방법이다.

작성된 코드는 테스트를 통해 검증되고, 검증을 통과한 코드만이 실제로 사용된다.

• TDD 개발주기
  • { Red } 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
  • { Green } 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
  • { Blue } 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.
• TDD의 장점
  • TDD를 통해 작성된 코드는 테스트를 통해 검증되므로 오류가 줄고 유지보수가 쉬워진다.
  • 오류가 발생할 경우 디버깅 시간을 단축할 수 있다.
  • 테스트 케이스를 작성하며 요구사항을 좀 더 명확하게 이해하고 구현 방식을 결정하므로 코드의 구조와 설계에 대한 고민이 더욱 깊어질 수 있습니다.
• TDD의 단점
  • 코드 작성 전에 테스트 코드를 작성해야 하므로 개발자의 추가적인 노력이 필요합니다.
  • TDD를 처음 사용하는 개발자들은 테스트 작성 시 어려움을 느낄 수 있습니다.

💬 BDD

Behavior-Driven Development, 행위 주도 개발

요구사항을 분석하고 검증하는 것에 중점을 둔 개발 방법론이다

• BDD란?
  TDD에서 비롯된 개발 방법론으로, TDD와 상호 보완적인 관계로 비슷한 개발 주기를 따르면서도 BDD는 비지니스의 요구사항에 초점을 맞추어 테스트를 작성한다.
• BDD의 장점
  • 개발 결과물이 실제 비지니스 요구사항을 만족하는지 쉽게 확인 가능하다.
  • 테스트 자동화 구현이 쉽고, 개발자와 비즈니스 팀과의 소통이 원활해진다.
• BDD의 단점
  • 요구사항 분석이 길어지며 명세화 비용과 시나리오 작성 비용이 증가한다.
  • 또한, 개발시간이 증가한다.

💬 DDD

Domain Driven Design, 도메인 주도 개발

• DDD란?
  비즈니스 도메인을 모델링하여 이를 기반으로 소프트웨어를 설계한다.
  이를 위해 도메인 전문가와 소프트웨어 개발자가 함께 일하며, 비즈니스 도메인 지식을 소프트웨어 설계에 반영한다.
• DDD의 장점
  • 비즈니스 도메인에 초점을 맞춰 설계하므로 유지보수성이 높다.
  • 비즈니스 도메인의 복잡성을 다룰 수 있다
• DDD의 단점
  • 도메인 모델링에 시간과 비용이 많이 들어간다.
  • 도메인 전문가의 참여가 필요하므로 도메인 전문가의 시간과 노력이 많이 필요하다.

📕 종합 비교 및 결론

• 어떤 방법이 낫다기보단 프로젝트의 상황을 고려하여 더 적합한 것을 사용해야 한다.
• 최근에는 xp방법론이나 애자일 방법론을 보완하는 형태로 린(Lean) 방법론이나 DevOps 방법론이 등장하고 있습니다.
• 이러한 방법론들은 더욱 빠르고 유연한 개발을 위해 지속적인 개선과 협업을 강조합니다.