4. 소프트웨어 공학과 개발 프로세스(4) - 에자일 모델

2000년대 이전까지 소프트웨어 개발은 전문가들의 영역이었지만, 점차 일반인들도 소프트웨어를 개발할 수 있는 환경이 조성되었다. 이에 따라 많은 소프트웨어 기업이 등장했으나, 변화하는 기술을 따라가지 못하거나 비효율적인 개발 방식(예: 폭포수 모델)으로 인해 경쟁에서 밀려났다. 반면, 일부 기업은 새로운 방식을 도입하며 생존했다.

 

구글, 애플, 아마존과 같은 빅테크 기업들은 기존의 통합 프로세스를 따르지 않고, 빠른 개발과 유연한 조직 문화를 구축했다. 특히 구글은 긴 회의를 지양하고, ‘스크럼(Scrum)’을 활용해 신속한 개발을 진행했다. 이러한 방법론은 이후 ‘애자일(Agile)’로 정착되었으며, 빠르게 개발하고 테스트하는 반복적인 접근 방식을 통해 기존보다 훨씬 효율적인 개발이 가능해졌다.

 

대표적인 사례로, 구글의 Gmail 프로토타입은 단 하루 만에 개발되었다. 이는 애자일 방식이 신속한 개발과 지속적인 개선을 가능하게 한다는 것을 보여준다. 오늘은 이러한 애자일 개발 방식에 대해 이야기해보도록 하겠다.

 

1. 애자일 프로세스 모델의 이해

애자일(Agile)이란 빠르고 유연한 소프트웨어 개발 방식을 의미한다. 핵심 원칙은 짧은 주기(1~4주) 내에 실행 가능한 프로토타입을 개발하고, 이를 지속적으로 개선하는 것이다. 이를 위해 기능을 작은 단위로 나누어 개발하며, 빠른 피드백 반영이 가능하도록 설계된다.

 

이는 폭포수(Waterfall) 모델과 유사하지만, 중요한 차이점이 있다. 폭포수 모델이 계획을 기반으로 한 순차적 개발 방식이라면, 애자일은 기능을 잘게 나누어 신속하게 구현하고 지속적으로 수정하는 방식이다. 이를 통해 요구사항 변화에 유연하게 대응할 수 있다.

 

애자일은 도구나 프로세스보다 팀원 간의 협업을 중시하며, 계획보다는 변화에 대한 적응을 우선한다. 또한, 계약 기반 일정 관리가 아닌 고객과의 지속적인 협력을 통해 개발이 이루어진다. 이러한 접근 방식은 민첩한 대응을 가능하게 했고, 결국 더 많은 사용자를 확보하는 데 기여했다. 이러한 이유로 애플, 구글, 아마존과 같은 기업들이 살아남을 수 있었다.

 

일들을 잘개 쪼개서 빨리 개발하고 이를 반복하는 것. 그리고 고객과의 상호작용. 그것이 바로 애자일 모델의 핵심이다.

 

이러한 애자일 모델은 다음과 같은 여러 방식이 존재한다.

스크럼(Scrum), 칸반(Kanban), XP(eXtreme Programming, 익스트림 프로그래밍), 린 소프트웨어 개발(Lean Software Development), FDD(Feature-Driven Development, 기능 중심 개발)

 

여기에서는 가장 대표적인 스크럼에 대해서 자세하게 서술해보도록 하겠다.

 

2. 에자일 프로세스 모델: 스크럼

 

스크럼(Scrum)이란 럭비에서 유래한 용어로, 경기 중 여러 선수들이 밀착하여 공을 앞으로 밀어내는 장면을 의미한다.  이는 즉, 신속하게 하대 여러 사람들이랑 여럿이서 하는 것이다. 이 방법을 개발 프로세스에도 결합한 것이다. 

 

스크럼은 명확한 역할과 효율적인 절차를 기반으로 진행된다. 가장 먼저, 제품 책임자(Product Owner, PO)가 존재하며, 이는 프로젝트의 요구사항을 정의하고 우선순위를 결정하는 역할을 한다. 다만, 직접 개발을 수행하지 않으며, 개발팀이 원활하게 작업할 수 있도록 방향을 제시하는 것이 핵심이다.

 

개발을 수행하는 팀은 스크럼 팀(Scrum Team)으로 구성되며, 이를 지원하는 스크럼 마스터(Scrum Master)가 존재한다. 스크럼 팀은 제품 백로그(Product Backlog)를 기반으로 개발 목표를 수립하고, 이를 세부적으로 나누어 구체적인 개발 단위를 정의한다. 스크럼 마스터는 팀을 감독하는 관리자가 아니라, 팀이 원활하게 협업할 수 있도록 돕고 장애물을 해결하는 조력자 역할을 한다.

 

개발 과정에서는 매일 15~20분간 짧은 회의(데일리 스크럼, Daily Scrum)를 진행하며, 보통 서서 회의하는 것이 일반적이다. 이를 통해 불필요한 시간을 줄이고 핵심적인 진행 상황만 공유한다. 또한, 정기적으로 스프린트 리뷰(Sprint Review)와 스프린트 회고(Sprint Retrospective)를 통해 개발 과정을 점검하고, 개선할 점을 논의한다. 이 과정은 단순한 평가가 아니라, 팀의 성장과 프로젝트의 발전을 위한 협력적인 접근 방식이 강조된다.

 

이러한 절차를 반복하여 최종 결과물을 만들어내는 것이 스크럼 방식의 핵심이다. 스크럼은 개발팀이 자율적으로 운영되도록 설계되어 있어, 불필요한 보고 체계나 형식적인 절차를 최소화한다. 이러한 방법론은 구글을 비롯한 여러 글로벌 IT 기업에서 활용되며, 빠른 개발 주기와 효율적인 협업을 가능하게 하는 요소 중 하나로 평가된다. 이 내용을 정리하면 다음과 같다.

 

 

3. 스크럼 방식의 이해

스크럼 방식을 더 자세하게 다음의 순서대로 말할 수 있다.

 

3.1. 제품 기능 목록

 

처음에는 이러한 방법으로 추상적으로 스토리 형식으로 만들어본다. 이 방법에서 포인트로 나누어 가장 먼저 우선순위를 정하는 것이 첫번째다. 점수는 추상적으로 만드는 것이다.

 

이 스토리의 경우에는 간략하게 서술하는 것이 중요하다. 또한 각 스토리는 서로 의존적이지 않아야한다. 주로 회사에서는 포스트잇을 사용해서 이를 간단하게 정리한다. 

 

위처럼 스토리 보드를 만든다. 이것은 그림으로만 이렇게 하는게 아니라 실제로 회사에서도 이렇게 한다. 

 

3.2. 스트린트 계획 수립

 

다음 단계에서는 계획을 수립하고 각자의 역할을 분담하기 위해 스프린트를 설정한다. 여기서 '스프린트'는 스크럼과 마찬가지로 미식축구에서 유래된 용어로, 빠르게 끝낸다는 의미가 내포되어 있다. 이는 개발 과정에서 효율적이고 집중적으로 목표를 달성하기 위한 짧은 기간의 작업 단위를 의미한다고 볼 수 있다.

 

 

실제로 작성하면 이런 식으로 작성을 할 수 있다. 이를 통해 각자의 맡은 것을 수행한다.

 

3.3. 스프린트 수행

 

이제는 스프린트를 수행을 하게 되는데 개발을 직접적으로 한다. 이것은 소멸그래프를 통해 진행상황을 이해하고 일일 스크럼 회의를 한다. 이것은 서서 하며 핵심적인 내용만 이야기하고 빨리 끝내는 것이 핵심이다. 스크럼 마스터는 끼어들거나 어떠한 일은 하지 않고 이를 지원해주는 역활만 한다. 

 

3.4. 스프런트 개발 완료 및 완료 후

스프린트 개발이 완료되면, 그 다음으로 중요한 일은 작업을 검토하고 회고하는 시간을 갖는 것이다. 이 과정에서는 단순히 잘한 점과 부족한 점을 지적하는 것이 아니라, 팀이 진행한 작업에 대해 전반적으로 돌아보는 시간을 가진다. 회고에서는 무엇이 잘되었는지, 무엇을 개선할 수 있는지에 대해 논의하며, 이를 통해 더 나은 방법을 모색한다. 중요한 점은 즉시 수정하기보다는, 개선점을 찾고 팀이 함께 성장할 수 있도록 건설적인 의견을 나누는 것이다.

 

 

위의 스크럼 방법에서 각 역활은 이렇게 주어진다. 이를 통해 빠르고 신속하고 사용자 중심의 소프트웨어를 만들수가 있다. 

 

4. 스크럼 방식의 장점과 단점

스크럼 방식은 빠르고 신속하게 개발을 진행하며, 실천 지향적이고 목표 달성에 집중할 수 있는 장점이 있다. 또한, 사용자 요구에 맞는 친화적인 소프트웨어를 개발하는 데 유리하다. 이러한 점들은 스크럼을 효율적인 개발 방법론으로 만든다.

 

하지만 단점도 존재한다. 수정 작업이 빈번해지면 그만큼 테스트와 검토 작업이 늘어나고, 이에 따라 시간과 비용이 증가할 수 있다. 또한, 회의가 길어질 경우, 회의 시간이 본래의 작업 시간을 압박할 수 있어 비효율적이 될 수 있다. 더불어, 팀원들이 각자 얼마나 효율적으로 작업을 수행했는지 파악하기 어렵고, 품질 관련 활동이 상대적으로 부족해 품질 관리에 대한 명확한 판단을 내리기 어려운 점도 단점으로 꼽힌다.

 

즉, 모든 방법이 다 확답이 아니라는 것이다. 이는 사람이기에 더욱 완벽히 못한다는 점을 반영한다.

 

출처: 쉽게 배우는 소프트웨어 공학

쉽게 배우는 소프트웨어 공학 - 예스24