[박창현 담당의 리테일 테크] 마트에서 애자일 해보기 – 애자일이 뭔데?

애자일(Agile)이란?

애자일. 영어로는 Agile. 근 몇 년 동안 소프트웨어나 인터넷, 모바일 서비스 개발 성공을 위해 꼭 필요한 그 무언가로 계속 회자되는 용어. 이게 정확히 뭘까? 일단 잘 모르겠으니 사전부터 찾아보자.

아하. 날렵하고 민첩하고 재빠르고 기민하게 무언가 하는 것을 애자일이라고 하는 것이군. 물론 우리가 밥 벌어먹기 위해 하는 모든 일이 날렵하고 민첩하고 재빠르고 기민해야겠지만, 사실 소프트웨어 개발에 ‘애자일’은 조금 더 심오한 의미를 내포한다. 그 의미를 알아보기 위해 초기 애자일 창시자들이 작성한 ‘애자일 선언문’을 살펴보도록 하자.

뭔가 매우 철학적으로 느껴질 것이다. 이를 소프트웨어 개발이라는 과정에 빗대어 조금 풀어서 쓰면 다음과 같다.

✓ 조직적인 롤 플레이나 정해진 룰보다는, 개인 간의 커뮤니케이션을 최대한 활성화해서 퍼포먼스를 높이자
✓ 문서 작업에 집중하기보다는, 실제로 동작하는 무언가를 먼저 만들어보자
✓ 기능, 일정으로 고객과 협의하기보다는, 실제 가치를 창출하는 결과물을 만들기 위해 고객과 협력해라
✓ 시장은 빛의 속도로 변한다. 이에 대응하기 위해 정해진 일정에 집착하기보다는, 변화에 빠르게 대응하자

위 내용의 왼쪽은 기업에서 소프트웨어 개발 시 매우 일반적으로 적용되는 형태를 대변한다. 소프트웨어 개발 프로젝트가 뜨면, 우선 조직부터 구성하고 사업/기획/개발/QA 역할을 설정한다. ‘요구사항 문서’ 같은 것들을 만들어서 기획-개발 부서 간 기능/정의/일정을 조율한다. 그 과정 속에서 서로 협의하며 뺄 기능 빼고, 넣을 기능 넣는다. 일정 조절도 한다. 일단 개발에 들어가면 사업-개발 부서는 만날 때마다 추가 요구 사항으로 다툼을 벌인다. 사업/기획은 자신들이 기획 단계에서 놓쳤던 기능들을 중간에 끼워 넣기 위해 무언가 다른 것들을 포기한다. 개발부서는 어쨌든 주어진 비용과 기간에 맞추기 위해 양을 조절한다. 결국 대부분, 이 과정에서 QA는 부실해질 수 밖에 없다. 시스템 오픈 시점에 다량의 버그가 발생하고, 서로 상대방에게 책임을 돌린다. 그 과정을 몇 개월 거쳐야 그나마 쓸 수 있는 시스템이 갖춰지는, 뭐 뻔히 아는 그 스토리다. 아마 십수 년 동안 계속 경험한 과정이니 다들 익숙할 것이다.

이에 반해, 우측 내용은 뭔가 다르다. 무언가를 하기로 정하면, 조직간의 룰보다 프로젝트에 속한 사람끼리 커뮤니케이션하며 문제 해결을 위해 노력한다. 서로 문서로 요구사항을 구체화하는 과정을 거치지 않고 일단 대략적인 틀 안에서 우선 돌아가는 결과물을 만든다. 서로 눈으로 보면서 이야기하고, 사업-기획-개발-QA 부서 간 네고가 아닌, 실제 가치 있는 산출물을 위해 머리를 맞대고 진행 방향을 논의한다. 그 와중에 발생하는 변경 기능 개발에 대해 서로 오픈 마인드로 기민하게 대응한다. 

‘과연 이게 가능할까’ 경험해보지 않은 사람들은 신화 속에 존재하는 이상향으로 치부할 수도 있겠다. 놀랍게도 해외, 국내의 수많은 글로벌 IT 기업 및 벤처 기업에서 이런 방식으로 업무를 진행하고, 또 많은 성공을 거두고 있다.

이러한 애자일 개발 사상(철학, Philosophy)을 녹여 넣은 개발 방법론(Development Methodology) 중 가장 많이 사용되는 것이 스크럼 개발 방법론이다. 그 내용을 대략 설명하자면 아래와 같다. 

✓ 사업, 기획, UI/UX, 개발, QA, 인프라 구성원까지 모두 하나의 팀, ‘스크럼’으로 구성
✓ 팀 내 구성원은 모두 평등. 프로덕트 오너(Product Owner)는 개발된 산출물을 이용한 서비스의 사업적 결과물을 책임지는 결정권자이며, 스크럼마스터는 해당 스크럼 구성원 간 협업 및 스크럼 운영을 조율하는 역할을 수행
✓ 전 구성원이 초기 미팅에 참여하여 프로덕트에 자체 및 프로덕트의 MVP(Minimum Viable Product)를 정의함. 프로덕트 개발을 위해 필요한 프로덕트 작업 목록(프로덕트 백로그)을 도출하고, 우선순위 및 개발 난이도를 산정
✓ 개발은 일정 주기의 스프린트로 나뉘어 진행하며, 각 스프린트는 실제 동작하는 결과물을 기준으로 구분함. 매 스프린트마다 동작하는 결과물 기반으로 리뷰를 진행
✓ 매 스프린트 시작 시 프로덕트 작업 목록(프로덕트 백로그)에 쌓여있는 업무(Task)들을 기반으로 스프린트 작업 목록(스프린트 백로그)을 도출. 필요하다면 이 시점에 기능 조정 및 백로그 수정, 우선순위 조정 수행
✓ 매일 전체 구성원이 참석하는 일간 스크럼 미팅을 통해 현재 장애가 되는 업무를 도출하여 활발한 커뮤니케이션을 통해 장애를 헤쳐나감
✓ 프로덕트 상용화는 Big Bang 방식으로 이루어지지 않고, MVP 기반으로 우선 릴리즈한 이후, 스크럼 팀의 연속적인 스프린트로 지속적으로 기능을 업데이트하는 형태로 진행

이러한 방식을 통해 얻을 수 있는 기존 방식 대비 장점은 명확하다.

✓ 높은 프로덕트 가시성 – 몇 주 단위의 매 스프린트 마다 동작하는 결과물을 볼 수 있어, 현재 프로덕트 상태가 어떠한지 몇 주마다 명확히 파악 가능
✓ 각기 다른 역할 주체 간 명확한 커뮤니케이션 가능 – 스프린트마다 동작하는 산출물을 볼 수 있어, 상상 속의 그 무엇이 아닌 매우 명시적인(Tangible) 실체를 기반으로 팀 내 주체 간 공감대 형성 용이함
✓ 기민한 대응 가능 – 스프린트마다 산출물을 기반으로 초기 놓쳤던 기능이나 실제 필요 없는 기능을 파악하고 프로덕트를 튜닝할 수 있음. 예전 방식에서는 이 작업이 프로젝트 종료 후에만 가능했었음. 정말 기적 같은 일 아닌가!
✓ Not Project, But Product – ‘소프트웨어 개발’에 집중하기보다는, 진정한 사업적 가치를 가지는 ‘프로덕트’를 만들고 가다듬는 일에 온 스크럼 팀이 집중할 수 있음. 스프린트마다 결과물을 보고, MVP 기준으로 빠른 상용화를 수행하고, 최적의 비즈니스 가치에 맞춰 지속적으로 소프트웨어를 변경함

자, 여기까지 잘 따라왔다면, 다음과 같은 의문을 가지게 될 것이다.

But, 마트에 애자일이 웬 말인가

“이건 소프트웨어가 ‘주(Main)’가 되는 서비스에는 잘 맞을 것 같지만, 우리 이마트의 주 업은 ‘유통’이라서, 이거 잘 안 맞을 것 같은데?”

오케이. 그런 생각 할 만하다. 이마트 같은 오프라인 대형마트에 웬 애자일. SSG닷컴이라면 혹시 모르겠지만…

의외로 잘 맞을 수 있어!

하지만, 조금 시각을 돌려서 생각해보자. 우선, 앞에서 언급한 애자일 기반 스크럼 개발 방법론의 장점에서 ‘소프트웨어 개발’을 쏙 빼버리자. 이마트에서 이루어지는 업무 혁신 활동, 본사/점포 Operation 혁신, 일부 기간계 시스템 변경 개발이 수반된 업무 변경의 장점으로 읽어본다면 어떻게 될까? 즉, 소프트웨어 개발은 업무 개선 활동이고, 산출물은 그 결과 도출된 데이터로 치환해본다면 어떨까? 여기서 데이터는 매출/이익/이익률 또는 뭔가 절감된 비용, 노동 시간 등등 주로 숫자일 것이다. 앞서 열거한 항목들을 바꿔 다시 읽어보자.

✓ 높은 업무개선 가시성 – 몇 주 단위의 매 스프린트 마다 데이터를 볼 수 있어, 현재 업무개선 상태가 어떠한지 몇 주마다 명확히 파악 가능
✓ 각기 다른 역할 주체 간 명확한 커뮤니케이션 가능 – 스프린트마다 데이터를 볼 수 있어, 상상 속의 그 무엇이 아닌 매우 명시적인(Tangible) 실체를 기반으로 팀 내 주체 간 공감대 형성 용이함
✓ 기민한 대응 가능 – 스프린트 마다 데이터를 기반으로 초기 놓쳤던 기능이나 실제 필요 없는 기능을 파악하고 업무를 개선할 수 있음. 예전 방식에서는 이 작업이 프로젝트 종료 후에만 가능했었음. 정말 기적 같은 일 아닌가!
✓ Not Project, But Product – ‘소프트웨어 개발’에 집중하기보다는, 진정한 사업적 가치를 가지는 ‘프로덕트’를 만들고 가다듬는 일에 온 스크럼 팀이 집중할 수 있음. 스프린트마다 데이터를 보고, MVP 기준으로 빠른 상용화를 수행하고, 최적의 비즈니스 가치에 맞춰 지속적으로 업무를 개선함

어떤가? 다 말이 되지 않는가? 그래, 여러분 생각대로다. 의외로 잘 맞을 수 있다! 물론 위에서는 소프트웨어 개발을 다 빼버렸지만, 그건 극단적으로 소프트웨어 개발이 없어도 적용 가능하다는 걸 알려주기 위해 그렇게 한 것이다. 실제로 업무 개선에 IT 시스템 변경이 뒤따르지 않는 경우는 거의 없으니, 소프트웨어 개발을 업무 개선의 일부로 생각해서 상상해도 큰 무리는 없을 것이다.(사실, 소프트웨어 이야기 빼고 이 칼럼이 쓰여진다면 내가 이 글을 쓰고 있을 이유가 없어지기도 하고)

To Be Continued…

이제 애자일 사상, 스크럼 방법론이 실제 대형마트 업무 개선에 적용 가능할 수 있다는 느낌을 대부분의 독자가 가질 수 있게 되었다는 믿음 속에, 다음 회차에서는 실제 적용 사례를 중심으로 그 효과를 살펴보도록 하자.

박창현 이마트 S-LAB 담당
온라인과 오프라인의 경계가 없어지는 그 날을 기다리며,
May the Force be with you…