[CS] 폭포수(waterfall) 방법론과 에자일(agile) 방법론

언제인지는 정확히 모르겠으나 갑자기 이런 단어가 생기고, 사용되기 시작한 것 같습니다.
이걸 늦게 접하던 빨리 접하던 상관은 없는 것 같습니다.
제 입장에선 이런 개념 없이도 도메인 주도 개발을 어느정도 적용하고 있었기 때문입니다.

다만 개발방법론 적인 측면에서 DDD라는 용어가 누가 왜 정의했고, 기술적인 영역으로 사용하는 부분에 대해 많은 생각을 하게 되었습니다.
이런 것 까지 알고 따라야 하나... 누군가 시도하는 것을 계속 따라해야 할까?... 이런 것을 계속 공부해야 하나... 쉽지 않은 것 같습니다.
그저 한번 쯤 해볼만 한, 그리고 다른 사람들과 대화가 통하기 위해서? 알아 두기는 해야 할 기술 같습니다.

Domain 주도 설계 라고 하는데... 
"소프트웨어 개발 접근 방법"으로 정의되고 있습니다.
방법론 적인 내용이며, 소프트웨어 프로젝트 방법을 이해해야 DDD를 좀더 쉽게 이해할 수 있습니다.

소프트웨어 프로젝트 방법론

개발이 프로젝트 단위로 진행되며, 프로젝트가 어떤 순서대로 진행되는지 표준화 시켜 정의되는 방법론 입니다.
프로젝트에 개발자만 투입되는 것이 아니라 기획자, 데이터 관리자, 인프라 엔지니어, QA 담당자, 업무 담당자 등 많은 역할이 나뉘어 투입되며, 여러 역할을 나눠 프로젝트를 수행하는데 있어 따르는 방법입니다.
반드시 지킬 필요는 없고, 정해진 규칙도 없으나, 이런 방법도 있다는 취지이며 사람들이 많이 쓰는 방법론은 크게 2가지 입니다.

- 폭포수 방법(Water Fall)
- 에자일 방법(Agile)

기본적으로 소프트웨어 개발 프로젝트는 아래의 구성요소로 구분할 수 있습니다.

폭포수 방식

폭포수 방식의 개발 방법은 제품의 수명 주기의 각 단계가 순차적으로 일어나 폭포처럼 진행이 꾸준히 아래쪽으로 흐르는 모델입니다.
폭포수 모델을 누가 만들지는 않았지만, 특정 생산 단계가 완료되면(예를 들어 건물의 기초를 다지는 것과 같이) 다음 단계 업무를 수행하는 식과 비슷합니다.
이처럼 비실용적인 다른 산업의 업무 방식을 소프트웨어 개발자들에 의해 문서화 시키며 방법론으로 자리잡게 되었습니다.

특히 폭포수 방식은 모든 요구사항 수집 및 설계 작업이 이루어진 후, 구현(개발)이 수행되는 형태입니다.
관련 자격으로는 영국 정부가 만든 PRINCE2와 PMI PMP가 있습니다.

수많은 프로젝트들이 지금까지도 폭포수 방식으로 수행되고 있으며
프로젝트 계획을 아래 그림처럼 시간 기준으로 상세하게 분류하고, 맨먼스를 측정해서 프로젝트 비용을 산정하고 수행하는 식입니다.

관례라고 해야할지 모르겠지만, 프로젝트를 수행하기 위해 가장 중요한 인력 분배와, 여기서 발생하는 비용 문제를 정의하는데 있어 계속 해오던 방식이라고 합니다.
다만 여기서 DDD가 나온 계기가 있다고 합니다.

폭포수 방식대로 하면, 요구사항 분석과 설계가 끝난 뒤에 개발(구현)이 수행됩니다. 여기서 문제점
- 1. 고객사 측 요구사항 변경 요청이 빈번함(개발 중이거나, 테스트 중에)
그러면 다시 전 단계로 돌아가 새로 요구사항 분석 및 설계를 진행하고 추가로 개발하며, 부딛치는 요소를 제거해야 하는데 이 과정에 미리 계획해둔 맨먼스보다 이상의 비용이 발생하며, 특히 번거롭고 신경쓸게 많다보니 어렵습니다.(즉 비용이 많이 발생합니다.)
- 2. 설계한 내용을 구현하기 힘든 경우
요구사항 대로 설계한 부분이 구현함으로써 다른 기능과 충돌한다거나, 소프트웨어 구조적으로 구현이 어려운 경우가 있기 때문입니다.
제 경험 중에선, 어플리케이션의 api 중에 endpoint를 재시작 없이, 외부 config파일의 변경 만으로 api의 endpoint를 변경할 수 있도록 적용 요청받은 적이 있었습니다.
변경을 적용하기 위해선 모듈의 재시작이 필요한 context기반 서비스에서, 재시작이 필요 없도록 매번 동적으로 endpoint를 할당하여 처리해야 하는데, 그로인해 발생하는 오버헤드로 성능이 낮아져 여러 이슈들이 발생합니다.

위의 현상들은 설계 후 개발 도중 다시 설계로 돌아갈 수 밖에 없는 문제들 입니다.
폭포수 방식으로 잡은 개념과는 조금 다르게 흘러갈 수 밖에 없는 부분인 것이지요.

에자일 방법론

소프트웨어 개발 프로젝트에서 추가되는 요구사항에 좀더 유연하게 대응하기 위해 고안된 방법론 입니다.
고객과의 지속적인 소통을 통해 최종 제품의 품질을 향상시키는 것을 목표로 합니다.

애자일 방법론의 핵심은 스프린트 단위의 작은 프로젝트 단위로 분리하여 진행합니다.
스프린트 단위로 개발하고, 개발된 스프린트를 테스트하며 고객에게 제공하는 것입니다. 
그 다음 스프린트를 개발하고, 개발된 스프린트를 테스트하며... 반복이지요.

에자일 방법론의 핵심가치

개인과 프로세스, 도구보다 협업: 에자일 팀은 독립적으로 일하거나 ‘서적대로’ 일하는 것보다 팀 협업과 팀워크를 중요시합니다.
포괄적인 문서보다 작동하는 소프트웨어: 에자일 팀이 개발하는 소프트웨어는 작동해야 합니다. 문서 작성과 같은 추가 작업은 좋은 소프트웨어 개발보다 중요하지 않습니다.
계약 협상보다 고객 협력: 고객은 에자일 방법론에서 매우 중요합니다. 에자일 팀은 고객이 소프트웨어가 어떻게 발전해야 하는지 안내하도록 합니다.
계획 따르기보다 변화에 대응하기: 에자일 프로젝트 관리의 주요 이점 중 하나는 팀이 유연하게 전략과 워크플로를 변경할 수 있다는 점입니다.

기본적인 폭포수 방식 과는 다르게, 요구사항에 대한 기준이 낮으며, 추가적으로 변경사항이나 요구 조건이 들어오면 이를 대응해줘야 합니다.
그렇다보니 개발 하면서 요구 조건을 추가 해 나가고, 들어오는 걸 환영하고 가치를 높이는 태도가 필요합니다.
도메인 전문가, 기획자, 운영자 들의 의견을 들어주며 개발자는 들어오는 변경 요구조건을 들어줘야 합니다.
이를 위해 매일 스크럼을 짜서 어떻게 수행하는지 의사소통 해야 하며, 이에 대한 기록은 간략하게 최소한으로 해야합니다.
그렇지 않으면 다른 일을 할 시간이 없기 때문입니다.

에자일 방식을 간략하게 그림으로 표현하면 다음과 같습니다.
아래처럼 결과물이 계속  성장하고 변화하며, 이를 위해 추가 요구사항이 계속 들어오는 식입니다.

에자일 방법 그림으로 표현해보기

정리하자면 에자일 방법론은, 프로젝트를 분석하고 스프린트 단위와 백로그 단위로 나눌 수 있어야 합니다.
그리고 결과물을 피드백 받으며 변수를 파악하고 해결해 나가며 목적에 다가가는 것입니다.
- 내부적 피드백( 내가 만든 결과물에 대해 확인하고, 개선 점이나 문제점을 찾기, 도구를 통해 분석 후 개선)
- 외부적 피드백( 고객이나 다른 팀에서 사용 후 개선점을 알려줌)
이 과정이 원활하게 이루어지기 위해서 협력이 중요합니다.
- 내부적 협력인 팀원들과의 협력( 문제 해결이나 구현 부분에서 중요하며, 직무 역할에서 도움을 주는 부분도 의미합니다.)
- 외부적 협력인 고객사와의 협력( 협의되지 않은 이슈를 협력을 통해 찾아낼 수도 있고, 개발적인 해결 대신 비즈니스적인 해결로 도움을 받을 수 있음)

애자일에서 주요 용어

애자일 방법론에서 사용되는 종류를 이해하는데 들어가는 
애자일을 사용한다고 해서 아래 용어들을 무조건 적으로 따르지는 않았으며, 회사마다 부르는 이름이 있었습니다.
또한 아래 용어들 중 일부만 쓰기도 했습니다.
그러니 아래 처럼 추상적으로 저런게 있다 정도로 이해하면 좋을 것 같습니다.

스프린트(Sprint): 프로젝트를 작은 기간(일반적으로 1~4주)으로 나눈 단위입니다. 
각 스프린트는 완전한 결과물을 생성하도록 계획되며, 스프린트가 끝난 후 팀은 개선할 점을 돌아보고 다음 스프린트를 위해 전략을 조정합니다.
백로그(Backlog): 백로그는 프로젝트에서 해야 할 작업 목록을 의미합니다.
이 작업 목록은 우선순위에 따라 정렬되며, 스프린트 계획에 사용됩니다.
백로그 항목은 사용자 스토리, 기능 요구사항, 버그 수정 등을 포함할 수 있습니다.
스크럼 팀은 백로그 항목을 스프린트로 이동시켜 작업을 진행합니다.
특히 제품 백로그(Product Backlog)와 스프린트 백로그(Sprint Backlog)로 나뉩니다. 
- 제품 백로그 (Product Backlog) :  제품에 필요한 기능, 개선사항, 버그 등을 스프린트에 관계없이 목록화 한 것입니다. 
- 스프린트 백로그 (Sprint Backlog) : 특정 스프린트 동안 작업할 항목들의 목록입니다.

스탠드업 미팅(Stand-up Meeting): 매일 짧게 진행되는 미팅으로, 팀원들이 진행 상황을 공유하고, 당면한 문제를 논의하며, 앞으로의 계획을 설정합니다.
회고(Retrospective): 스프린트가 끝난 후 팀이 모여 스프린트 동안 무엇이 잘 되었고 무엇이 개선되어야 하는지 논의하는 회의입니다.

애자일에서 사용되는 주요 방법론들

* 스크럼(Scrum): 스프린트 기반의 프로젝트 관리 방법론입니다. 

스프린트 계획, 일일 스크럼, 스프린트 리뷰, 스프린트 회고와 같은 정기적인 행사를 진행합니다.
스크럼 팀은 제품 소유자(Product Owner), 스크럼 마스터(Scrum Master), 개발팀(Development Team)으로 구성됩니다.
- 제품 소유자(Product Owner) : 제품 백로그를 관리하고, 백로그 항목의 우선순위를 정하며, 팀이 고객 가치를 최대화할 수 있도록 안내합니다.
- 스크럼 마스터(Scrum Master) : 스크럼 팀이 스크럼 프레임워크를 따르도록 돕는 역할을 합니다. 장애물을 제거하고 팀이 최적의 생산성을 유지할 수 있도록 지원합니다.
- 개발팀(Development Team) : 시키는걸 개발합니다.

* 칸반(Kanban): 작업 시각화에 중점을 둔 프로젝트 관리 방법론입니다.

칸반 팀은 작업을 시각적으로 관리하며, 작업 진행 상황을 한눈에 파악할 수 있도록 합니다.
작업을 시각적으로 추적하는 보드를 사용하여 팀 간 협업과 지속적인 개선을 강조합니다.
일반적으로 jira에서 스크럼 방법을 제공할 때, 칸반 방법도 같이 제공해 준다고 합니다.
그래서 업무의 흐름을 한눈에 볼 수 있도록 시각화 해 줍니다.(안그럼 일일이 그림으로 다 만들어 보고서 써야되니...)

칸반보드 예시

제가 경험했던 칸반 보드

정해진 양식은 없으며, 업무 방식을 따르면 됩니다.

익스트림 프로그래밍(eXtreme Programming, XP) : 고객의 요구 사항을 신속하게 반영하고 소프트웨어의 품질을 높이기 위해 다양한 실천 방법을 제시합니다.

비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법으로, Programming Explained - Embrace Change'에서 발표되었습니다.
애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나입니다.
아래 항목은 XP에서 제시하는 방법들 입니다.

반복적 개발(Iterative Development) 이라는 개발 단위를 반복적으로 수행하며, 짧은 개발주기(1~2주) 사이에 개발이 끝나야 합니다. 이를위해 고려해야 할 요소가 있습니다.
첫 번째, 이번 반복(iteration)에는 어떤 개발 과정을 끝마칠 것인가?
두 번째, 그 이후 개발 반복(iteration)에서는 무엇을 할것인가?
< 즉 XP에서 반복이란, 스크럼 보다는 아젠다 개념으로 보시면 됩니다.>

고객 참여(Customer Collaboration) 를 통해 "고객"은 "개발팀"에게 지속적인 피드백을 제공하여 소프트웨어의 방향을 결정합니다.
고객은 개발 과정에 적극적으로 참여하여 요구 사항을 상세하게 정의하고, 우선 순위를 설정합니다.

작은 릴리스(Small Releases)로 XP는 가능한 한 자주 소프트웨어를 배포합니다.
이는 고객이 "고객 참여"를 쉽게 할 수 있고, 빠르게 피드백을 제공할 수 있게 하며, 위험을 줄이고 유연성을 높입니다.

반복적 개발, 고객 참여, 작은 릴리스를 수행하기 위한 상세한 방법으로 아래의 요소들이 활용됩니다.

1. 테스트 주도 개발(Test-Driven Development, TDD): 개발자는 코드를 작성하기 전에 테스트를 먼저 작성합니다. 이는 코드의 품질을 높이고, 버그를 사전에 예방하는 데 도움이 됩니다.
2. 짝 프로그래밍(Pair Programming): 두 명의 개발자가 하나의 컴퓨터에서 함께 코딩하는 방식입니다. 한 사람이 코드를 작성하면, 다른 사람은 이를 검토하며 실시간으로 피드백을 제공합니다. 이는 코드의 품질을 높이고, 지식을 공유하는 데 효과적입니다.
3. 리팩토링(Refactoring): 코드를 더 간결하고 이해하기 쉽게 개선하는 작업입니다. 기능은 그대로 유지하면서 코드 구조를 개선하여 유지보수성을 높입니다.
4. 지속적 통합(Continuous Integration): 개발자는 변경 사항을 자주 통합하여 코드베이스를 지속적으로 빌드하고 테스트합니다. 이를 통해 통합 문제를 조기에 발견하고 해결할 수 있습니다.
5. 코드 표준(Code Standards): 팀 내에서 일관된 코딩 스타일을 유지하기 위해 코드 표준을 정의하고 준수합니다.
6. 간단한 설계(Simple Design): 보통의 프로젝트 개발 혹은 코딩의 경우 기능이 더해지면 더 해질 수록 복잡해 집니다. 그렇게 되면, 새롭게 충원되는 개발자의 경우에 현재까지의 개발 상황을 이해하는데 오랜 시간이 걸립니다.
   또한 버그가 발생할 경우에도 쉽게 처리를 하지 못하고 오랜 시간이 걸리게 됩니다.
   그렇기 때문에 XP에서 모든 코딩을 가능한 간단하게 할 것을 강조합니다.
   이러한 추세 혹은 트렌드는 KISS 원칙 원리와도 함께 한다고 할 수 있습니다.

FDD (Feature Driven Development) : 기능 중심 개발은 반복적이고 점진적인 소프트웨어 개발 프로세스입니다

빠르게 변화하는 요구사항을 해결하는 방법으로써, 기능을 중심적으로 설계하고 개발하는 방법입니다.
도메인을 분석하고 고객에게 필요한 기능을 중심적으로 분류 한 뒤에 개발하면서 핵심 로직을 테스트를 통해 구현합니다.

FDD에서는 5개의 주요 활동이 있습니다.

1. 전체 모델 개발 : 전체 모델을 개발하려면 도메인 전문 지식과 개발자와 도메인 전문가 간의 협업을 기반으로 클래스 다이어그램과 같은 시스템에 대한 높은 수준의 표현을 만드는 것이 포함됩니다.
2. 기능 목록 작성 : 초기 모델이 정의되면 각 기능은 명확한 비즈니스 가치를 지닌 특정 기능이나 작업을 나타내는 기능 목록을 파생하는 데 사용됩니다.
   기능은 특정 엔터티에 대한 CRUD(생성, 읽기, 업데이트 및 삭제) 작업과 같은 관련 그룹으로 구성되어 작업 관리를 더욱 간단하게 만듭니다.
   
3. 기능별 계획 : 작업 할당 생성, 노력 추정, 종속성 결정, 각 기능에 대한 타임라인 설정이 포함됩니다.
   기능 개발은 "적시" 설계 접근 방식을 따릅니다. 즉, 기능 구현이 예정된 경우에만 설계 노력이 수행됩니다. 
4. 기능별 디자인 : 기능별 디자인 부분에서 수행되는 세부 디자인에는 기능을 구현하는 데 사용할 클래스와 메서드를 지정하는 것뿐만 아니라 단위 테스트 및 사용 사례와 같은 기타 아티팩트도 포함됩니다.
5. 기능별로 구축 : 개발자가 디자인을 실행하고, 단위 테스트를 생성하고, 코드를 기본 코드베이스에 통합합니다. 

FDD는 이해관계자가 더 큰 그림을 향해 작업하면서 더 작은 기능 덩어리를 관리하는 데 집중할 수 있도록 하기 때문에 복잡한 요구 사항과 대규모 개발 팀이 있는 대규모 프로젝트에 이상적입니다. 예를 들어 CRM 애플리케이션을 작업하는 팀은 고객 기록 관리, 판매 주문 처리, 보고서 생성과 같은 기능을 중심으로 작업을 구성할 수 있습니다. 이러한 높은 수준의 기능 각각은 더 작은 기능 구성 요소로 나누어진 다음 FDD 프로세스를 사용하여 개발 및 통합됩니다.

정리해보면,

저는 에자일 방법론을 도입하는게 더 좋다고 생각되는건 아닙니다.
처음 배울 때 부터 정해진 에자일 방식 대로 업무를 해온 것은 아니지만, 에자일 처럼 아젠다를 정하고,
요구조건이 수없이 바뀌며 이를 다 쳐내는 환경에서 개발을 해 왔습니다.
동시에 여러 프로젝트를 같이 하기도 했으며, 중간에도 요구조건이 변경되거나 추가로 요청이 오면
시간을 만들어 분석하고 백로그로 남긴 뒤 스크럼을 짜서 수행해야 했습니다.
특히 매일 매일 이런 업무를 보고하고 내일 무엇을 할지 논의하는 과정에서 적당한 피드백을 받지 못한다면 업무가 산으로 갈 확률이 높은데, 저는 피드백을 받기 너무 힘든 환경에 있었습니다.(선임과 구성원의 역량 문제)

이렇게 일을 하다보니 결과물은 쌓이지만, 프로젝트 내역이나 경력 정리가 안되었습니다.
공식 문서를 남길 시간을 만드는게 불가능 할 정도로 업무가 많았고, 이게 1~2년 이상 하다보니 수행했던 프로젝트들이 정리가 안되고 뒤죽박죽 쌓여가며, 인수인계도 더 어려워 졌습니다.
그리고 이걸 누군가에게 설명할 수 있도록 경험을 정리한다거나, 지나친 점을 더 개선할 수 있는 기회도 점점 줄어들었습니다.
결국 야근을 계속 부르는 방법론 이었습니다.
수행하는 분들 경험담을 물어보면, 다들 힘든 방법이고 지치는 방법이다 라고 이야기를 많이 들었습니다.

그렇다보니 애자일 방법론이 아직까지 정착을 못하고, 폭포수와 계속 비교되는 것 같습니다.
어떻게 보면 완전한 대안책의 방법론도 아닌 것이지요...
그렇다고 폭포수의 단점을 보완해야 하는 부분도 아직 많이 남아있긴 하지만, 이는 기존에 맨먼스 단위로 단가를 계약해서
업무를 수행하는 식 까지 변경하던지, 아니면 이런 부분을 고려해서 맨먼스를 길게 잡던지 하는 식의 계산 방법이 필요합니다.

내가 경험했던 lg의 에자일 방식의 개발 프로세스

 

참고

https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html
https://ememomo.tistory.com/126
https://m.blog.naver.com/ijoos/221447224599
https://hanminwoo.com/33
https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Software%20Engineering/%EC%95%A0%EC%9E%90%EC%9D%BC(Agile)2.md
https://appmaster.io/ko/glossary/gineung-jungsim-gaebal-fdd

https://velog.io/@masonlee/63
https://hanminwoo.com/31