애자일 설계가 탄생하는 배경에는 잘못된 설계가 있다
설계 -> 요구사항 변경 -> 설계의 퇴화
요구사항 변경으로 처음에 설계하여 진행한 소프트웨어가 점점 부패되기 시작했을 때 요구사항 변경을 탓하는 경우가 있다(개발자 책임이 아니지 않느냐)
아니다.
우리는 변하는 요구사항의 세계에 살고 있고, 우리가 만든 소프트웨어가 이런 변화 속에서 살아남을 수 있게 만드는 것이 우리가 해야하는 일이다. -> 애자일 방식을 해야하는 주 원인이다.
특히, 기업은 이익을 목표로 하는 집단이기에 다양한 프로젝트를 시도하고 다양한 요구사항이 추가 및 변경은 불가피하다.(어떠한 서비스가 이익이 되지 않을 때 요구사항 변경을 통해 이익을 불러올 수 있는 가능성이 있다면 마다할 기업이 어디있는가)
요구사항 변화에 대응하여 변경에 대해 탄력적으로 설계를 수정할 수 있다.
위와 같은 방식으로 좋은 상태의 설계를 유지할 수 있다. 애자일 개발자는 몇 주에 한 번씩 설계를 진단하고 청소하지 않는다. 매일, 매시간, 심지어 몇분마다 간단하고 명료하게 유지한다.
절대로 부패가 시작되도록 놔두지 않는다.
애자일 설계는 과정이지 결과가 아니다. 원칙과 패턴을 적용하여 설계를 좋은 상태로 두기 위한 연속적인 방식이다.
단, 앞으로 설명하는 원칙과 패턴을 큰 설계에서 적용하지 않고 매 순간마다 리팩토링하여 설계를 명료하게 유지하려는 시도의 일환임을 알아두자
추후에 기업에서 진행하는 애자일 사례를 들어 글을 추가할 예정이다