TDD (Test Driven Development) 과 애자일 (Agile) 그리고 폭포수 모델

TDD (Test Driven Development) 과 애자일 (Agile)에 대해서 (폭포수모델도)

SM성의 SI쪽으로만 주로 일하다보니,

내가 처음부터 솔루션이나 Framework를 만든건 없다.

 

그래도 알고리즘 매매 프로그램을 개발하려다보니 한번 개발방법론관련해서 찾아봤다.

처음에 TDD (Test Driven Development)를 찾아보다, 애자일 (Agile)까지 간략히 찾아봤다.

 

목차

• TDD (Test Driven Development)  에 대해서 알려줘
• 애자일 개발 방법론
• 폭포수모델

 

TDD (Test Driven Development)  에 대해서 알려줘

소프트웨어 개발 방법론 중 하나로, 코드를 작성하기 전에 먼저 테스트 코드를 작성하고 그 테스트를 통과하기 위한 최소한의 코드를 작성하는 방식입니다.

TDD는 소프트웨어 품질을 높이고 개발 프로세스를 효율적으로 관리할 수 있도록 돕습니다.

TDD의 핵심 과정은 크게 3단계로 이루어져 있습니다.

TDD의 3단계:

1. Red: 테스트 작성
   먼저 실패하는 테스트를 작성합니다. 이 테스트는 아직 구현되지 않은 기능에 대한 것입니다. 테스트는 항상 실패해야 하며, 이는 아직 해당 기능이 없기 때문입니다.
2. Green: 코드 작성
   테스트를 통과할 수 있는 최소한의 코드를 작성합니다. 이 단계에서 코드는 간단하게 작성되어야 하며, 목표는 테스트를 성공시키는 것입니다.
3. Refactor: 코드 개선
   테스트가 통과한 후, 코드를 리팩토링하여 성능을 개선하거나 코드 품질을 높이는 작업을 합니다. 리팩토링 과정에서 테스트가 계속 통과하는지를 확인해야 합니다.

TDD의 장점

• 높은 코드 품질: TDD는 기능을 작동시키기 전에 테스트를 작성하므로, 잠재적인 결함을 미리 발견하고 수정할 수 있습니다.
• 자신감 향상: 작성된 테스트가 자동으로 코드의 안정성을 보장해주므로, 개발자는 코드 변경에 대한 두려움이 줄어듭니다.
• 문서화 역할: 테스트 코드는 시스템이 어떻게 동작하는지 명확하게 설명하는 역할을 합니다.
• 효율적인 리팩토링: 리팩토링을 할 때 테스트가 있으면 기능이 의도대로 작동하는지 확인할 수 있어 리팩토링이 용이해집니다.

TDD의 단점

• 시간 소모: 처음에는 테스트 코드를 작성하는 것이 시간 소모적일 수 있습니다. 프로젝트 초기에는 TDD 적용이 느리게 느껴질 수 있지만, 장기적으로 보면 버그 수정과 유지보수에서 이점을 얻습니다.
• 복잡성 증가: 모든 코드에 대해 테스트를 작성하다 보면 테스트 코드 자체가 복잡해질 수 있습니다.
• 완벽한 적용 어려움: 특히 UI나 비즈니스 로직이 복잡한 시스템에서는 모든 부분에 TDD를 적용하기 어렵습니다.

TDD는 특히 애자일 개발 방법론과 잘 맞으며, 코드의 품질을 높이고 유지보수를 용이하게 만드는 강력한 도구입니다.

-> 스타트업같은데서 일해본적은 없고, 거의 공장쪽만 일하다보니

이런걸 적용해서 개발해본적은 한 번도 없다.

내 개인프로젝트에 별도 프로젝트를 만들고 TDD를 적용해본적은 있긴하지만..

솔직히 시간이 좀 문제긴 하더라.

 

애자일(Agile) 개발 방법론

빠르고 유연한 소프트웨어 개발을 지향하는 방법론입니다. 1990년대 후반부터 기존의 폭포수(Waterfall) 방식 개발의 한계를 극복하기 위해 등장했으며, 변화하는 요구사항에 신속하게 대응하고 지속적인 개선을 통해 소프트웨어를 개발하는 데 중점을 둡니다. *2001년 발표된 애자일 선언(Agile Manifesto)*가 애자일 철학의 핵심 원칙을 정의합니다.

애자일 선언의 4가지 가치:

1. 프로세스와 도구보다 개인과 상호작용을 중시
   개발 프로세스와 도구도 중요하지만, 팀원 간의 소통과 협력이 더 중요한 요소로 간주됩니다.
2. 포괄적인 문서화보다 실행 가능한 소프트웨어를 중시
   문서 작성에 너무 많은 시간을 들이는 대신, 실제로 작동하는 소프트웨어를 만드는 데 집중합니다.
3. 계약 협상보다 고객과의 협력을 중시
   고객의 요구를 명확히 정의하고 이에 맞춰 대응하는 것을 목표로 합니다. 계약서에 명시된 요구사항에만 집중하기보다 고객과의 협력을 통해 요구사항을 유연하게 조정할 수 있습니다.
4. 계획을 따르기보다 변화에 대응하는 것을 중시
   계획은 중요하지만, 요구사항이나 시장 상황의 변화에 빠르게 대응할 수 있는 능력이 더 중요합니다.

-> 개인적인 생각으로 스타트업에서 필요로 하지 않을까 생각한다.

애자일의 12가지 원칙:

1. 고객 만족을 최우선으로, 지속적으로 가치 있는 소프트웨어를 제공한다.
2. 변화하는 요구사항을 환영한다. 설계의 유연성이 중요하다.
3. 작동하는 소프트웨어를 자주 제공한다. 주기를 짧게 하여 자주 배포한다.
4. 개발자와 비즈니스 이해관계자가 함께 협력한다.
5. 동기 부여된 개인들을 중심으로 프로젝트를 구성한다.
6. 대면 커뮤니케이션이 가장 효과적인 방법이다.
7. 작동하는 소프트웨어는 진척 상황의 주된 척도이다.
8. 일정한 속도로 개발을 유지한다.
9. 기술적 탁월함과 좋은 설계를 통해 지속 가능성을 높인다.
10. 단순성, 즉 해야 할 일을 최소화하는 것이 필수적이다.
11. 자율적인 팀이 가장 좋은 설계를 만든다.
12. 팀은 정기적으로 성과를 개선할 수 있는 방법을 반성하고 조정한다.

애자일 방법론의 주요 프레임워크

1. 스크럼(Scrum)
   스크럼은 가장 널리 사용되는 애자일 프레임워크로, 고정된 기간(보통 2~4주) 동안의 작업을 '스프린트'라고 부르며, 이 기간 내에 일정한 목표를 달성합니다. 매일 데일리 스크럼 미팅을 통해 진행 상황을 점검하고 장애물을 해결합니다. 스크럼에는 스크럼 마스터(프로세스 촉진자), 제품 책임자(Product Owner), 그리고 개발 팀이 참여합니다.
2. 칸반(Kanban)
   칸반은 작업 흐름을 시각화하고, 작업 단계별로 진행 상황을 추적하는 데 중점을 둡니다. 칸반 보드에 '할 일', '진행 중', '완료' 등의 칸을 두어 각 작업의 상태를 시각적으로 관리합니다.
3. XP(eXtreme Programming)
   XP는 품질을 높이고 변화를 수용하기 위해 개발 속도를 극대화하는 방법론입니다. TDD(Test Driven Development), 페어 프로그래밍(Pair Programming), 리팩토링(Refactoring) 등의 기법을 강조합니다.
4. LEAN
   린 소프트웨어 개발은 낭비를 줄이고, 빠른 피드백을 통해 고객 가치를 극대화하는 것을 목표로 합니다. 주로 제조업에서 유래한 원칙을 소프트웨어 개발에 적용합니다.

애자일의 장점

• 빠른 대응: 변화하는 요구사항에 유연하게 대처할 수 있습니다.
• 고객과의 소통 강화: 개발 과정에서 고객의 피드백을 자주 반영할 수 있어 고객 만족도가 높습니다.
• 지속적인 개선: 반복적인 작업과 회고를 통해 프로세스와 제품의 품질을 지속적으로 향상시킵니다.
• 리스크 감소: 작은 단위로 자주 배포하므로 큰 프로젝트에서 발생할 수 있는 리스크를 줄입니다.

애자일의 단점

• 명확한 요구사항 부재: 요구사항이 자주 변할 경우, 장기적인 계획 수립이 어렵고 혼란이 생길 수 있습니다.
• 지속적인 협업 필요: 팀원과 고객 간의 지속적인 소통이 필수적이며, 이로 인해 커뮤니케이션 비용이 증가할 수 있습니다.
• 프로세스 남용 가능성: 애자일 방식이 "계획이 필요 없다"는 오해로 남용될 수 있습니다.

애자일은 빠르게 변화하는 비즈니스 환경에 적응하기 위해 설계된 방법론으로, 유연성, 고객 중심의 개발, 팀의 자율성을 중시하는 특징이 있습니다.

 

-> 참고로, 맨위에 나왔던 폭포수 모델만 언급하자면

 

폭포수(Waterfall) 모델

전통적인 소프트웨어 개발 방법론 중 하나로, 각 단계가 순차적으로 진행되는 구조를 가지고 있습니다.

이전 단계가 완료되어야만 다음 단계로 넘어갈 수 있으며, 단계 간 후퇴가 어렵다는 특징이 있습니다.

각 단계는 명확하게 정의된 절차를 따르고, 단계별로 문서화가 중시됩니다.

폭포수 모델의 주요 단계:

1. 요구사항 분석(Requirements)
   고객의 요구사항을 분석하고 명확하게 문서화하는 단계입니다.
2. 설계(Design)
   시스템과 소프트웨어의 전반적인 설계를 수행하며, 시스템 아키텍처와 상세 설계를 구체화합니다.
3. 구현(Implementation)
   설계에 따라 실제 코드를 작성하는 단계입니다.
4. 테스트(Testing)
   구현된 소프트웨어가 요구사항에 맞게 작동하는지 검증하고, 결함을 찾고 수정합니다.
5. 배포(Deployment)
   최종 소프트웨어를 고객에게 인도하고 배포하는 단계입니다.
6. 유지보수(Maintenance)
   소프트웨어가 실제 운영되는 동안 발생하는 문제를 수정하고, 개선 작업을 수행하는 단계입니다.

폭포수 모델의 장점:

• 명확한 구조: 각 단계가 명확하게 정의되어 있어 관리가 용이합니다.
• 문서화 강조: 모든 단계가 문서로 기록되어 있어 향후 유지보수나 인수인계에 유리합니다.
• 프로젝트 진행 통제: 계획이 체계적이므로 전체 프로젝트를 통제하기 쉽습니다.

폭포수 모델의 단점:

• 변경에 대한 유연성 부족: 각 단계가 끝난 후에는 수정하기 어렵기 때문에 요구사항 변경에 유연하게 대처하기 어렵습니다.
• 테스트가 늦게 진행: 테스트가 개발 후반부에 이루어지므로, 결함이 늦게 발견되어 수정 비용이 증가할 수 있습니다.
• 긴 개발 주기: 모든 단계가 순차적으로 진행되기 때문에, 최종 결과물이 나오는 데 시간이 오래 걸립니다.

폭포수 모델은 요구사항이 명확하고 변화 가능성이 적은 프로젝트에서 효과적이지만, 요구사항이 자주 변하거나 개발 중간에 피드백이 필요한 프로젝트에서는 비효율적일 수 있습니다.