'기초부터 다시 시작하는' 애자일 방법론의 이해

애자일(Agile) 방법론이 등장한 지 2021년을 기준으로 꼭 20년이 됐다. 일부 스타트업이 공동 장소에서 스티커와 화이트보드를 가지고 협업하던 비주류 방법론이 이제는 정교하고 확장성 있고 널리 쓰이는 애자일 소프트웨어 개발 프로세스와 툴로 발전했다.

 

ⓒ Drew Graham (CC0)

애자일 개발은 오랜 기간 사용되고 많은 기업이 스크럼, 칸반 등의 애자일 기법을 이용해 애플리케이션을 현대화하고 고객 경험을 개선하고 디지털 트랜스포메이션을 이행하는 데는 그만한 이유가 있다. 디자인 씽킹, 제품 관리, 데브옵스와의 접점에 대한 방대한 지식이 쌓이는 것도 같은 맥락이다. 이제 사람들은 ‘애자일이 무엇인가?’라고 묻지 않는다. 오히려 자기 팀에 최고의 애자일 방법론을 적용할 방법을 활발하게 논의한다.

 

여기서는 다시 기본으로 돌아가 사람과 팀, 프로세스, 툴과 함께 애자일 방법론의 기초를 알아본다. 또한, 애자일이 데브옵스와 어떻게 연결되는지 살펴보고, 애자일 문화를 양성하고 고품질의 소프트웨어를 완성하는 모범 관행을 소개한다.

 

 

애자일 방법론에서의 주요 역할들

애자일 소프트웨어 개발 프로세스는 언제나 특정 제품의 사용자를 정의하고, 다뤄야 할 문제와 기회, 가치의 범위에 관한 비전을 문서화하며 시작한다. 제품 소유자(Productowner)는 이 비전을 포착하고 이를 달성하기 위해 다양한 팀과 협업하며 애자일 개발 프로세스에는 여러 역할이 관여한다.

 

사용자 : 애자일 프로세스는 언제나 사용자(User) 또는 고객을 염두에 두면서 시작한다. 오늘날에는 일반적으로  고객 요구 및 행동의 다른 워크플로우 역할/유형을 정형화한 사용자 페르소나(User Personas)를 정의한다.

 

제품 소유자 : 제품 소유자는 내부 이해관계자 등 고객의 목소리를 담당한다. 통찰, 발상, 피드백을 종합해 제품 비전을 만든다. 보통 제품 비전은 단순하고 직접적이지만, 고객 또는 사용자가 누구이고, 어떤 가치를 다루는지, 이들을 다루는 전략에 대한 전체 그림을 반영한다. 예를 들면 구글이 가졌던 원래의 비전 아마도 다음과 같았을 것이다.

 

단순한 키보드 중심 인터페이스와 검색 결과에서 유명한 출처를 앞에 배치하는 알고리즘을 가지고 인터넷에 접근할 수 있는 사람이 적절한 웹사이트와 웹 페이지를 쉽게 찾을 수 있도록 하자.

 

비전이 무엇이든지 제품 소유자는 이를 정의하고 개발팀과 협력해 이를 구체화한다. 개발팀과 협력하기 위해 제품 소유자는 제품 비전을 일련의 사용자 스토리(User Stories)로 나눈다. 각 사용자 스토리는 표적 사용자, 이들이 가진 어려움, 해법이 필요한 이유, 그리고 해법을 한정하는 단서와 허용 기준을 규명하기 위한 것이다. 제품 소유자는 사용자 스토리의 우선순위를 정하고 이를 팀과 함께 평가해 팀에 필요한 것이 무엇인지에 대해 공통의 이해를 가질 수 있도록 해야 한다. 애자일 개발에 대한 빠른 입문서를 찾고 있다면 이 5분짜리 영상을 참고하면 된다.

 

소프트웨어 개발팀 : 팀은 다학제적이어야 하고, 일을 완수할 수 있는 기술과 이력을 가진 다양한 집단을 포함해야 한다. 애자일 개발팀은 개발자는 물론 품질 보증 자동화 엔지니어, 데이터 엔지니어, 사용자 경험(UX) 디자이너, 그리고 소프트웨어 제품의 유형에 따라 그 외의 다양한 역할로 구성해야 한다.

 

애자일은 팀이 유효한 소프트웨어를 전달하는 데 집중시킨다. 따라서 이들은 완전히 기능하는 애플리케이션, 통합, 사용자에게 영향을 주는 결과물을 완성해야 한다. 단순히 기술 컴포넌트만으로는 충분하지 않다. 모든 팀원이 무엇을 만드는지, 누가 무엇을 하는지, 소프트웨어가 어떻게 개발될 것인지 충분히 이해하고 참여해야 한다. 이 밖에 애자일 팀에는 일반적으로 다음과 같은 역할이 배정된다.

 

• 기술 또는 팀 리더(Tech or Team leads)는
  아키텍처, 기능 미달 허용 기준, 시퀀싱, 디펜던시, 여타 기술 및 보안 고려사항에 관해 제품 소유자와 협력한다. 기술 리더는 팀과 함께 스토리를 평가하고 구현 디테일을 계획하는 등 광범위한 책임을 맡는다.
• 스크럼 마스터(Scrum master)는
  흔히 새로운 팀에게 애자일 프로세스, 책임, 툴에 관해 지도한다. 스크럼 마스터는 진전을 가로막는 장애를 해소하고, 애자일 팀의 개발 속도를 향상할 방법을 검토하고, 백로그를 정리하는 등의 책임을 진다.
• 비즈니스 애널리스트(Business analysts)는
  제품 소유자와 협력한다. 일반적으로 비즈니스 애널리스트는 와이어 프레임의 생성, 사용자 스토리의 문서화, 테스트 결과의 검토 등을 책임진다. 이들은 마이크로서비스 등의 기술 제품을 개발할 때, 그리고 소프트웨어 개발에 있어 제품 소유자보다 더 여러 가지 지식을 가지고 있을 때 특히 도움이 된다.

 

애자일 팀의 구성과 규모를 정하는 일은 전적으로 조직 리더에게 달려 있다. 팀원 간의 협업을 극대화하기 위해 제프 베조스의 '피자 두 판 애자일 팀(Two pizza-size agile teams)' 관행을 따르는 경우가 많다.

 

 

스크럼과 칸반

일단 제품 비전 및 팀이 애자일 선언서(Agile manifesto)에 나온 원리 등 애자일에 공감했다면, 이제 프로세스 방법론을 선택해야 한다. 대표적인 애자일 프로세스는 스크럼(Scrum)과 칸반(Kanban)이다.

 

칸반은 이해하고 구현하기가 비교적 쉽다. 일종의 팬-인 및 팬-아웃 프로세스(Fan-in and Fan-outprocess)로 작동하며, 팀은 인테이크 보드(Intake board)로부터 사용자 스토리를 획득해 워크플로우 전체에 걸쳐 전파하고 구현한다.

 

그러나 대부분 기업은 스크럼을 활용한다. 대개 1~2주간 지속되는 스프린트(sprints)라는 리드미컬한 흐름에 따라 개발 작업을 진행한다. 제품 소유자는 요구사항을 사용자 스토리로 작성하고, 비즈니스 가치에 따라 백로그에서 우선순위를 정한다. 팀은 백로그를 검토한 후 스프린트 중 완수할 수 있는 최상위 사용자 스토리에 집중한다.

 

스크럼은 몇 가지 표준적인 회의를 포함한다(스크럼 의례(scrum ceremonies) 혹은 스크럼 의식(scrum rituals)이라고도 불림). 이는 팀이 스프린트 우선 사항에 집중하고, 스프린트 기간 중 작업을 완수하고, 각 스프린트를 성공적으로 마감하는 데 도움이 된다. 다음과 같은 공통 요소를 갖는 것이 보통이지만, 애자일 하이브리드 작업 모델에 맞게 수정할 수 있다.

 

• 스프린트 계획(Sprint planning)은
  제품 소유자가 우선순위를 공유하는 것으로, 팀은 스프린트 중에 얼마나 많은 작업을 완수할 수 있는지를 결정한다.
• 일일 스탠드업 회의(Daily standup meetings)에서는
  팀이 사용자 스토리의 현황을 논의한다. 팀원은 각자 일일 목표를 공유하고, 팀의 진전을 가로막는 장애물이 있다면 상부로 위임할 수 있다.
• 스프린트 평가(Sprint reviews)는
  스프린트의 마감 시 행하는 실증 회의이다. 여기서는 최종 결과물에 대한 제품 소유자의 승인을 얻기 위해 제반 기능을 시연한다.
• 회고 회의(Retrospective meetings)에서
  팀은 애자일 및 소프트웨어 개발 프로세스에서 잘된 부분과 개선이 필요한 부분을 논의한다.

 

스크럼은 제품, 프로그램, 프로젝트 매니저가 예정 시한 및 범위를 명시하는 것이 아니라 팀이 자율적으로 달성할 수 있는 분량의 작업에 집중해 성과를 개선한다. 사용자 스토리를 이용하면 비즈니스 요구와 허용 기준을 (또는 애자일 팀이 때때로 ‘완수의 정의(Definition of done)’라고 부르는 것) 나누는 작은 업무를 형성하고, 팀이 이행 방식을 자율적으로 체계화할 수 있다. 스프린트 평가는 피드백 순환 고리의 하나이고, 제품 소유자는 각 스프린트 전에 우선순위를 다시 평가해 요건을 재정의하는 것이 좋다. 스프린트 회고는 팀이 협업을 개선하고 프로세스를 개선하는 데 도움이 된다.

 

 

애자일 팀을 위한 모범 관행

스크럼은 팀이 협력하고 계획하고 완성하기 위한 기본 프로세스다. 그러나 이는 최고의 기술 관행이 아니고 조직적 표준이 아니다. 애자일 문화를 정의하고 견인하지도 않는다.

 

대신 오늘날 가장 널리 쓰이는 기술 관행은 대개 소프트웨어 개발 수명주기(SDLC)의 정의와 데브옵스 프로세스의 이행을 포함한다. SDLC는 코드 작성, 소프트웨어 자산의 관리, 기술 표준의 개발에 관한 지침을 제공한다. CI/CD, 코드형 인프라(IaC), 지속적 테스팅 등의 데브옵스 자동화는 한층 안정적인 개발  프로세스를 만드는 데 도움이 된다. 시프트-레프트 보안 관행(Shift-left security practices), 옵서버블 마이크로서비스(Observable microservices), 피처 플래깅(Feature flagging), 카나리아 배포(Canary releases), AI 옵스 같은 다른 관행은 유연하고 안정적인 소프트웨어 공급 모델이다.

 

자율적인 팀, 애자일 방법론, 데브옵스 자동화, 클라우드 아키텍처로의 현대화 등은 모두 IT 조직이 문화를 진화시키는 데 기여한다. 장기적인 개발 주기는 기능과 개선을 신속히 배포할 수 있도록 CD 모델로 대체된다. 자동화는 성과, 신뢰성, 보안에 대해 운영 책임을 지면서 자율성과 속도를 추구하는 개발자 사이의 여러 차이를 메우는 데 도움이 된다.

 

애자일 팀은 이들 관행을 여러 가지 조합해 현명한 아키텍처를 결정해 테스트할 수 있다. 데이터 지향적인 문화를 만들고 빠르게 실수를 바로잡는 것도 가능하다. 이밖에 디자인 씽킹과 스크럼의 융합, 가치 스트림(Value streams)의 이행, 제품 관리 관행의 개발, 지속 계획의 이행 등의 관행은 애자일 팀이 고객, 최종 사용자, 현업관계자와 협력하는 데 도움이 된다.

 

일반적으로 애자일 팀은 지라 소프트웨어(Zira Software), 애저 데브옵스(Azure DevOps), 디지털닷에이아이(Digital.ai) 등의 툴을 활용해 애자일 백로그 및 칸반 보드 상에서 협력한다. 이들 툴은 작업의 우선순위를 정하고, 요구사항을 포착하고, 사용자 스토리를 완성하고, 번다운 보고서(Burndown reports)를 검토하고, 버전 제어, CI/CD, 여타 툴을 이용해 워크플로우를 자동화하는 데 도움이 된다.

 

SAFe, 엔터프라이즈 스크럼(Enterprise Scrum), LeSS(Large-Scale Scrum), 스포티파이 모델(Spotify Model), 스타CIO 애자일(StarCIO Agile) 등 개념적 프레임워크와 가이드는 여러 협업 팀이 애자일 원리와 표준, 관행을 추진하는 데 기여한다.

 

애자일 전문가 대부분은 명확히 정의된 목적, 소수의 정예 팀, 제한된 수의 엄선된 툴과 함께 애자일 관행을 시작하도록 권고한다. 물론 다양한 팀, 자율 조직 원리, 표준, 툴, 그리고 통합 사이에서 적절한 균형을 발견하는 것은 쉽지 않다. 그러나 이런 노력을 통해 기술 역량을 구축, 확장하고 유지할 수 있다.

 

 

 

 

'기초부터 다시 시작하는' 애자일 방법론의 이해