개발자

'애자일은 뭐고 폭포수는 뭐야?' 애자일 방법론 역사 이해하기

Isaac Sacolick  | InfoWorld 2022.04.12
요즘은 모든 기술 조직이 어떤 형태로든 애자일 방법론을 실천하거나 그렇게 하고 있다고 믿는 것 같다. 소프트웨어 개발에 처음 발을 들여놓는 사람이든 수십 년 경력자든, 지금 하는 모든 작업이 많건 적건 애자일 방법의 영향을 받는다 해도 과언이 아니다.
 
애자일은 도대체 무엇이고, 개발자와 조직이 애자일 방법론을 도입하려면 어떻게 해야 하는 것일까? 애자일 개발의 역사, 전통적인 폭포수 방법론의 차이점을 간략히 알아보자. 애자일과 폭포수 방법론의 차이점을 실무 관점에서 살펴보고, 특히 오늘날의 개발 환경에서 개발자와 팀이 작업할 때 왜 애자일이 훨씬 더 나은 방법인지를 설명한다.
 
ⓒ Getty Images Bank
 

애자일 이전 : 폭포수 방법론

폭포수 방법론이 소프트웨어 개발의 금본위였던 시절을 기억하는 사람이 아직 있을 것이다. 폭포수 방법론을 사용하려면 코딩을 시작하기 전에 상당한 문서 작업이 필요했다. 보통 비즈니스 애널리스트가 애플리케이션에 필요한 기능을 정리한 비즈니스 요구사항 문서를 작성하면서 프로세스가 시작됐다. 이 문서는 길고 세부적이며, 전체 전략부터 포괄적 기능 사양, 사용자 인터페이스 시각 디자인에 이르기까지 모든 요소를 포함했다.
 
기술자는 이 비즈니스 요구사항 문서를 사용해서 애플리케이션의 아키텍처와 데이터 구조, 객체 지향 기능 설계, 사용자 인터페이스, 기타 비기능적 요구사항을 세부적으로 정의한 기술 요구사항 문서를 작성했다.
 
비즈니스와 기술 요구사항 문서가 완성되면 비로소 개발자가 코딩을 시작한다. 이후 통합을 거쳐 마지막으로 테스트가 이어졌다. 애플리케이션이 프로덕션 단계에 이르려면 이 모든 과정과 작업이 먼저 마무리되어야 했다. 전체 프로세스가 완료되기까지는 몇 년이 걸리는 것도 흔한 일이다.
 

실무에서의 폭포수 방법론

폭포수 방법론에 사용된 문서를 ‘사양’이라고 했는데, 개발자는 문서를 작성한 당사자들 못지않게 이 사양을 철저히 파악해야 했다. 예를 들어 200페이지짜리 문서의 77페이지에 기술된 중요한 세부 사항을 적절히 구현하지 못했다고 질책을 받을 수 있었다.
 
소프트웨어 개발 툴 역시 전문화된 교육이 필요했으며 선택할 수 있는 툴의 종류도 많지 않았다. 데이터베이스 연결 열기, 멀티쓰레딩으로 데이터 처리하기 등 모든 저수준 동작을 직접 개발했다.
 
기초적인 애플리케이션을 개발하는 경우에도 팀 규모는 큰 반면 커뮤니케이션 툴은 제한적이었다. 팀은 기술 사양을 마치 성경처럼 받들고 활용했다. 요구사항이 변경되면 비즈니스 리더가 긴 검토를 거쳐 승인하는 프로세스를 거쳐야 했으며 팀 전체에 변경 사항을 전파하고 코드를 수정하는 데 많은 리소스가 소비됐다.
 
소프트웨어는 기술 아키텍처를 기반으로 개발되었으므로 저수준 아티팩트가 먼저 개발되고 종속 아티팩트가 나중에 개발됐다. 작업은 각자의 스킬을 기준으로 할당됐는데 보통 데이터베이스 엔지니어가 먼저 테이블과 기타 데이터베이스 아티팩트를 구축했다. 이후 애플리케이션 개발자가 기능과 비즈니스 로직을 코딩하고 마지막으로 사용자 인터페이스를 입혔다. 애플리케이션이 실제 동작할 때까지는 수 개월이 걸렸다. 그 시점이 되면 이해당사자들은 이미 안달이 나 있는 경우가 보통이었는데, 개발자보다 자신이 원하는 기능을 더 잘 안다고 생각하는 경우가 많았다. 그 시점에서 무언가를 변경하려면 당연히 많은 비용이 들었다.
 
이후 사용자에게 기능을 공개했지만 예상한 대로 작동하지 않는 것도 있었고, 아예 사용자가 사용하지 않는 기능도 생겨났다. 기능은 매우 성공적으로 구현됐지만 확장성과 성능을 지원하기 위해 리엔지니어링이 필요하기도 했다. 폭포수 세계에서는 긴 개발 사이클이 지나고 소프트웨어가 배포된 이후에만 이 모든 것을 파악할 수 있었다.

 

관련 영상 : 애자일 방법론의 원리

모두가 애자일 소프트웨어 개발을 논하지만 실제 환경에서 애자일 방법론이 어떻게 작동하는지 제대로 이해하지 못하는 기업이 더 많다. 5분 길이의 짧은 영상으로 쉽게 이해해보자. 

 

폭포수 방법론의 장단점

1970년에 고안된 폭포수 방법론은 소프트웨어 개발에 규율을 적용하고 명확한 사양을 만들어 따르도록 했다는 면에서 혁신적이었다. 폭포수 방법론의 기반은 헨리 포드의 1913년 조립 라인 혁신에서 파생된, 생산 공정의 각 단계에 대한 확실성을 부여한 폭포수 제조 방법이다. 폭포수 방법의 목적은 최종 제품이 사양과 일치하도록 하는 것이었다.
 
소프트웨어 팀이 폭포수 방법론을 채택하기 시작할 당시 컴퓨팅 시스템과 애플리케이션은 일반적으로 복잡하고 일체식(monolithic)이었으며 규율과 제공해야 할 명확한 결과물이 필요했다. 요구사항의 변경 속도도 지금에 비하면 느렸으므로 대규모 작업이 별다른 문제가 되지 않았다. 마치 변경될 일이 없는 영구적인 전함을 건조하듯 시스템을 만들었다. 몇 년에 이르는 타임프레임은 소프트웨어 개발뿐만 아니라 제조 및 다른 기업 활동에서도 일반적이었다. 그러나 인터넷 시대로 접어들면서 폭포수의 엄격함은 단점이 됐고 속도와 유연성이 더 중요한 요소로 부상했다.
 

애자일 성명서

애자일은 2001년 17명의 기술자가 애자일 성명서 초안을 마련하면서 공식적으로 출범했다. 이들은 더 나은 소프트웨어를 개발는 팀을 이끌고자 애자일 프로젝트 관리를 위한 다음의 4가지 주요 원칙을 기술했다.
 
  • 프로세스와 툴보다 개인과 상호작용이 우선
  • 포괄적인 문서화보다 작동하는 소프트웨어가 우선
  • 계약 협상보다 고객 협업이 우선
  • 계획 추종보다 변화 대응이 우선
 

애자일 방법으로의 전환

개발자가 인터넷 애플리케이션을 다루게 되면서 소프트웨어 개발이 바뀌기 시작했다. 초창기 작업의 많은 부분이 신생업체에서 이뤄졌다. 신생업체의 소규모 팀은 한 곳에 모여 일했고 전통적인 컴퓨터 과학 배경이 없는 경우가 많았다. 이들에겐 웹사이트와 애플리케이션, 새로운 기능을 시장에 더 빨리 내놔야 하는 금전적, 경쟁적 압박이 있었다. 개발 툴과 플랫폼도 빠르게 바뀌었다.
 
이렇게 되자 신생업체에서 일했던 많은 이가 폭포수 방법론에 의문을 품고 더 효율적인 방법을 찾기 시작했다. 사전에 모든 세부적인 문서 작업을 할 여유가 없었고, 프로세스는 더 반복적이고 협업적이어야 했다. 요구사항 변경을 두고 여전히 논쟁을 했지만 실험, 사용자 피드백에 따른 소프트웨어 조정에 대해서는 더 개방적이었다. 체계는 부족했지만 애플리케이션은 엔터프라이즈 레거시 시스템에 비해 덜 복잡했으므로 애플리케이션 구매보다 구축에 더 열려 있었다. 중요한 점은 신생업체 조직은 몸뚱이를 키우기 위해 노력했으므로 사용자가 어떤 부분이 제대로 작동하지 않는다고 알려주면 대체로 그 의견을 경청했다는 것이다.
 
혁신에 필요한 스킬과 역량을 갖추는 것이 전략적으로 중요해졌다. 아무리 돈을 많이 준다 해도 빠르게 변화하는 인터넷 기술과 호흡을 맞출 수 있는 유능한 소프트웨어 개발자를 영입해 이들에게 “사양’을 따르도록 강제할 수는 없었다. 개발자들은 무엇을 개발해야 하고 애플리케이션이 언제 전달되어야 하며 심지어 코드를 어떻게 구축해 하는지까지 세세하게 기술한 빈틈없는 스케줄로 팀을 이끄는 프로젝트 관리자를 외면했다. 프로젝트 관리자가 만들어 끊임없이 업데이트하는 3개월, 6개월 스케줄에 맞출 재간이 개발자에게는 없었다.
 
대신 개발자가 운영자에게 인터넷 애플리케이션을 엔지니어링해야 하는 방법을 알려주고 직접 마련한 반복적인 스케줄에 따른 결과를 제공하기 시작했다. 막상 겪어보니 개발에 전념할 수만 있다면 1~4주 간격으로 약속한 업데이트를 배포할 만했다.
 
2001년이 되자 경험 많은 일련의 소프트웨어 개발자는 자신이 전통적인 폭포수 방법론과는 다른 소프트웨어 개발 방법을 실천하고 있다는 사실을 인식했다. 이들 모두가 신생업체에 속한 개발자는 아니었다. 켄트 벡, 마틴 파울러, 론 제프리스, 켄 슈와버, 제퍼 서덜랜드 같은 권위 있는 기술자를 포함한 이 집단은 바람직한 현대 소프트웨어 개발 프로세스에 관한 공통적 신념을 문서화한 애자일 성명서를 작성했다. 이들은 문서화보다는 협업을, 엄격한 관리보다는 자기 조직화를, 경직된 폭포수 개발 프로세스에 갇히기보다는 지속적인 변화를 관리하는 역량을 강조했다.
 
이 원칙에서 소프트웨어 개발을 위한 애자일 방법론이 탄생한 것이다.
 

애자일 개발이 더 나은 소프트웨어로 이어지는 이유

애자일 원칙을 받아들여 애자일 프레임워크에 구현하고 협업 툴을 활용하고 애자일 개발 방법을 채택하면 일반적으로 더 품질이 우수하고 개발 속도도 빠른 애플리케이션이라는 결과로 이어진다. 또한 더 나은 기술적인 방법, 이른바 위생(hygiene)도 얻게 된다.
 
그 주된 이유는 애자일이 유연성과 적응성을 염두에 두고 설계된다는 데 있다. 폭포수 방법에서 하듯이 모든 대답을 사전에 정의할 필요가 없다. 대신 문제를 소화 가능한 구성요소로 쪼갠 다음 사용자와 함께 개발하고 테스트한다. 예상대로 작동하지 않거나 미처 생각하지 못한 부분이 드러나면 적절히 조정하여 신속하게 본 궤도로 돌아오거나, 필요한 경우 아예 궤도를 바꿀 수도 있다. 애자일은 각 팀원이 솔루션에 기여할 수 있게 해주며 각 팀원이 작업에 대해 책임감을 가질 것을 요구한다.
 
애자일 원칙, 프레임워크, 실천 방법은 현재의 운영 상황에 맞게 설계된다. 애자일은 일반적으로 반복적인 개발, 피드백을 활용한 애플리케이션 및 개발 프로세스 개선을 중시한다. 반복과 피드백 모두 지금의 더 스마트하고 더 빠른 운영 환경과 잘 맞는 요소다.
 
또한 애자일 개발은 지속적인 개선을 촉진한다. 마이크로소프트가 버전 3.1을 끝으로 윈도우 개발을 중단했거나 구글이 2002년에 검색 알고리즘 개선을 중단했다고 상상해 보자. 소프트웨어에는 끊임없는 업데이트, 지원, 향상이 필요하다. 애자일 방법론은 이 지속적인 개선을 위한 사고방식과 프로세스를 확립한다.
 
마지막으로, 애자일 팀에 속한 사람이 일반적으로 더 생산적이고 더 행복하다는 점도 애자일 개발이 더 나은 소프트웨어로 이어지는 이유 중 하나다. 엔지니어는 얼마나 많은 일을 하고 어떤 결과물을 만들었는지를 자랑스럽게 보여준다. 제품 소유자는 비전이 빠르게 소프트웨어에 표현되는 모습과 최신 정보를 기반으로 우선 순위를 바꿀 수 있다는 점을 좋아한다. 사용자는 필요한 작업을 제대로 하는 소프트웨어를 얻으므로 만족한다.
 
오늘날 기업은 치열한 경쟁 세계에서 더 우수한 디지털 경험을 제공하기 위해 높은 수준의 소프트웨어 역량이 필요하다. 또한 좋은 소프트웨어를 만들기 위한 뛰어난 인재를 영입하고 유지해야 한다. 애자일 개발은 이 두 가지 모두에 도움이 된다.
editor@itworld.co.kr 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.