대기업에도 Agile Scrum 문화를 만들 수 있는가 - Spotify 사례

대기업에도 Agile Scrum 문화를 만들 수 있는가?

먼저 애자일(Agile)이 무엇인지 살펴보자. 애자일은 조직 운영의 구체적인 방법론이라고 하기보다는 운영 철학이나 조직 문화에 가깝다고 볼 수 있다.

"세상에 확실한 것은 아무것도 없다"

"고객도 자신이 원하는 바를 정확히 모른다"

이것이 애자일의 전제이다.

그리고 애자일과 함께 다니는 용어가 있는데 바로 '스크럼(Scrum)' 이다. 스크럼이란 애자일을 실제 조직 운영에 적용할 수 있는 구체적인 방법론 중 하나로서 자체 결정권을 가진 소규모 조직이 '스프린트(Sprint)'로 불리는 업무 사이클을 유지하는 것을 가장 중요하게 여긴다.

스프린트는 2주에서 6주 간격으로 돌아가는데 한 스프린트 내에서 스크럼 조직은 기획/개발/출시/피드백으로 이어지는 일련의 과정을 반복하게 된다. 여기서 중요한 건 한 스프린트 내에서 개발 등 중간 과정이 지연된다고 일정 전체를 늘려선 안 된다는 거다.

이전 스프린트에서 나온 지적사항이 너무 많아 개발이 늦어지고 있다면, 반영할 내용을 과감하게 줄이더라도 예정된 기한 내에 실제 사용 가능한 제품을 시장에 내놔야 한다. 여기서 새로운 소비자 피드백을 얻는 것만으로 이번 스프린트는 제 역할을 다했다고 보는 것이다.

스크럼(Scrum) 문화를 도입시켜 가장 성공한 사례로 꼽히는게 '스포티파이(Spotify)' 음악 스트리밍 업체이다. 내가 다니고 있는 회사는 대기업에 속하는데 해당 문화를 도입하고자 아래 영상을 꼭 보고 오라는 숙제를 받았다.

Spotify의 Agile Scrum 도입 일러스트 설명

위 동영상을 보면 Spotify 에서는 특이한 명칭으로 불리는 소규모 조직들이 있다.

무슨 일을 할 것인가(what)에 대해서는 Squad와 Tribe를 통해 결정하고, 어떻게 하면 잘할 것인가(how)에 대해서는 Chapter와 Guild를 통해 해결하고 있다.

이제 본론으로 "대기업에도 Agile 문화를 만들 수 있는가?"에 대한 생각을 적어보려 한다.

1) 느낀 점 2) 우리 팀 업무에 적용해 본다면 3) 우리 회사에 적용해 본다면 순으로 작성하였다.

<느낀 점>

동영상을 보고 가장 먼저 느낀 점은 '스타트업에 적용 가능한 기법이 아닐까? 과연 우리도 가능할까?'였다. 그리고 Alignment와 Autonomous 간의 상관관계가 흥미로웠다. 자유성과 리더십이 적절히 결합된 조직이 가장 이상적이라는 것. 자유성은 좋으나 리더십이 낮으면 각개전투가 될 가능성이 높다는 것이다.

스포티파이 내 업무 조직은 최소 단위인 '스쿼드(Squad)'부터 시작되는데 스쿼드엔 엔지니어, 디자이너, 프로그래머 등 여러 업무 담당자가 모여 있다. 스쿼드는 하나의 스타트업처럼 프로젝트 종류와 진행 방식을 자유롭게 정한다는 점이 흥미로웠다.

비슷한 업무를 맡은 스쿼드가 여러 개 모이면 '트라이브(Tribe)'를 이루고 보통 트라이브는 100명 이내로 구성된다고 하는데 한 트라이브 안에서 같은 직군의 직원끼리는 일종의 기술 교류 모임인 '챕터(Chapter)'를 형성한다.

대기업의 팀 형식은 비슷한 역할, 즉 개발자면 개발자, BA면 BA, 디자이너면 디자이너 이런 식으로 모아 놓다 보니 오히려 챕터 형식을 띄고 있었던 점이 스크럼 조직과는 상충된다는 점이었다.

그리고 예산을 받아서 하는 식의 SI업체식의 전통적인 프로젝트 베이스로 일하는 것은 애자일과 맞지 않다고 생각했다. 프로젝트는 시작할 때 총예산, 납기, 투입 인원 등이 정해진다. 지금까지는 일단 예산을 많이 받기 위해서 최대한 많은 기능을 넣어서 기획안을 만들었지만 프로젝트를 착수하는 시점에서는 이 기능들 중 어떤 것이 진정으로 가치 있는 것인지 사실 정의되기 어렵다. 사용자의 검증을 거쳐야 알 수 있는 부분이기 때문이다. 하지만 일단 예산을 받아내야 하기 때문에 이런 고민은 무시되었던 게 현실이었다.

<우리 팀 업무에 적용해본다면?>

일단 각자 맡은 기본 BA업무에 대해서는 팀원들 간에 Squad를 이루는 것은 맞지 않아 보인다. 차라리 내가 진행하고 있는 프로젝트 내에서 우리 팀원 + 협력 개발사 PM + 개발자 + 디자이너 간에 팀을 이루는 것이 가장 이상적인데, 동영상에서 말하는 물리적인 한 공간을 이뤄 일하기는 현재로선 어려워 보인다.

앞으로 새로운 서비스를 개발하는 프로젝트를 해 나갈 때 이런 조직을 작게 구성해보면 좋을 것 같다.

우리 팀에서도 각 분야에 대한 전문가를 양성해야 한다고 생각한다. 예를 들어 UI/UX와 시스템 설계, 환경 구성 전문가, 문서작성 등이다. 즉 역할을 명확하게 지정하고 시너지를 이뤄내는 것이 필요하다. 우리 회사는 Generalist를 지향하는 것 같고, BA는 이것저것 다 할 줄 알아야 한다는 인식이 크다.

내년에는 팀원 7명이 다 같이 Involve 해서 도전해 볼 수 있는 프로젝트가 하나 있으면 재밌을 것 같다. 화이트보드에 TO-DO list 등을 작성해가며 진행경과를 체크해가면서 프로덕트 개발을 수행하는 것이다. 예를 들어 AI 콜 같은 것들?

그런데 운영조직이 타 부문에 있다 보니 잦은 변경과 수정은 너무 눈치가 보인다.

<우리 회사(대기업)에 적용이 가능할까?>

우리 회사는 상사에게 보고하고 공유하는 게 당연시되고 리소스도 많이 투입되는 게 현실이다. 보고는 당연히 중요하고 필요하지만 발표자료처럼 느껴지게 준비를 해야 한다는 건 상당한 부담이다. 어떻게 하면 고객에게 좋은 서비스를 제공할 수 있을까에 집중해야 하는데 그전에 어떻게 하면 상사가 안 좋게 보지 않을까를 생각하며 자료를 만드는 건 스스로나 고객에게 모두 불행한 일이다.

애자일 소조직은 사내 다른 조직의 도움 없이 맡은 프로젝트를 원활하게 진행할 수 있어야 한다. 이를 위해선 기획은 기획 부서에서, 개발을 개발팀에서, 마케팅은 마케팅본부에서 맡던 기존 조직체계를 완전히 허물어야 하고 기획자, 개발자, 마케터, 세일즈맨 등 여러 직무자들이 한 팀에 속해 긴밀하게 협업해야 한다.

현재의 우리 회사 구조에서는 완전한 애자일 스크럼을 이뤄내긴 어렵다고 본다. IT 부서만 해본다고 과연 의미가 있는 걸까?라는 생각이 들었다.

아니면 IT조직 내에서 비용 예산부터 기획-개발-배포-운영 까지 다 해낼 수 있는 조직을 시험 삼아 만들어보는 것도 좋을 것 같다. 그런데 IT부서에서 지원되는 예산 규모를 보면 글쎄... 란 생각이 든다.

스타트업은 구체화된 명확한 1개 또는 몇 개의 서비스에 대해 미션이 명확하고 집중할 수 있는 환경이 된다. 하지만 대기업은 수백/수천 가지의 작은 서비스들이 있고 신규 서비스를 해도 론칭 후에는 그 서비스에 참여하고 있는 인력 Pool을 가만히 두지 않는다. 스타트업은 이슈를 선점하고 기술을 부각해서 투자를 받거나 M&A를 받음으로써 조직을 유지할 수 있지만, 대기업은 그렇지 않기 때문에 다르다고 본다.

그리고 Product 개념에서는 SI/SM 식으로 프로젝트를 나눴을 때 외부와 절대 경쟁이 되지 못한다. 이것이 Agile Scrum을 하는 조직과 경쟁이 되지 않는 결과를 보여줄 것이다. 처음에 서비스를 론칭하는 시점에서는 대기업과 Agile 식으로 하는 회사간에 크게 차이가 나지 않는다. 오히려 처음 서비스를 런칭하는 시점에서는 대기업이 훨씬 퀄리티가 좋을 것이다. 하지만 시간이 지나 계속 iteration을 하는 Agile 회사는 훨씬 앞서 가게 될 것이 분명하다.

스타트업에서 하는 그대로 Agile 문화를 대기업에 도입한다고 하면 실패할 가능성이 매우 매우 크다.

---

번외) 스타트업이 DevOps를 하는 이유는?

이제는 운영 업무가 쉬워졌기 때문이다. 쉬워졌다는 표현은 구글, 아마존과 같은 업체에서 대부분의 인프라를 제공해주기 때문에 이제는 자기가 개발한 영역에 대한 운영만 집중할 수 있기 때문에 그게 가능해졌다고 본다.