emart DT

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

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

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

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

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

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

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

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

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

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

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