스케일링 프레임워크

애자일에서 갈라져 나온 실행 규칙은 대체로 한 팀을 전제로 씌었습니다. 애자일은 계획을 한 번에 확정하지 않고 짧게 만들어 내보인 뒤 방향을 고치자는 태도인데, 그 태도를 규칙으로 옮긴 스크럼도 칸반도 대여섯에서 열 명 안쪽이 한 제품을 붙들고 있는 모습을 기준으로 삼습니다. 회의에 관계자가 모두 들어갈 수 있고, 누가 무엇을 하는지 굳이 적지 않아도 옆자리를 보면 알고, 무엇을 먼저 할지도 한 사람이 정하면 끝나는 크기입니다.

문제는 사람이 늘 때 생깁니다. 팀을 하나 더 만드는 것까지는 쉬운데, 두 팀이 같은 제품을 건드리는 순간 한 팀만 있을 때는 없던 일이 생깁니다. 결제 화면을 맡은 팀이 로그인 팀의 인증 기능을 기다리게 되고, 두 팀이 같은 코드를 각자 고쳐 두었다가 합치는 날 충돌하고, 같은 주에 두 팀이 각각 내보내겠다고 하면 순서를 정할 사람이 없습니다. 이런 일은 팀 수가 늘수록 빨리 불어납니다. 팀이 둘이면 신경 쓸 사이가 하나지만, 넷이면 여섯이고 여덟이면 스물여덟입니다.

그 불편은 회의에서 이런 모양으로 나타났습니다. 팀 A의 아침 회의에서 "인증 쪽 답을 기다리는 중입니다" 가 3주 연속 나오는데, 정작 그 말을 들어야 할 팀 B는 그 자리에 없습니다. 팀 B의 아침 회의에서는 그 요청이 이번 주기 계획에 들어 있지 않아 아무도 꺼내지 않습니다. 두 팀 다 자기 보드 위에서는 막힌 데가 없고, 멈춰 있는 것은 두 보드 사이입니다.

예전에는 이 자리를 한 사람이 채웠습니다. 전체 일정을 표에 모아 두고 팀마다 마감을 배분하는 관리자입니다. 그런데 이 방식은 각 팀이 스스로 정하던 것을 도로 위로 걷어 올리는 일이라, 팀 안의 짧은 주기는 형식만 남고 실제 결정은 표를 쥔 사람에게 돌아갔습니다. 스케일링 프레임워크는 그 대신 팀 안의 자율은 두고 팀과 팀 사이에만 규칙을 얹으려는 시도입니다. 무엇을 위로 올리고 무엇을 팀에 남길지를 어디서 자르느냐가 체계마다 다르고, 그 차이가 아래 갈래를 만듭니다.

스케일링 프레임워크 아래 묶인 용어는 모두 체계 한 갈래입니다. 여섯 가지가 있고, 한 팀짜리 규칙을 어디까지 손대는지로 줄을 세울 수 있습니다. 스크럼을 거의 그대로 두고 팀 사이 연결만 얹는 쪽이 한끝에 있고, 팀 위에 새로운 층과 주기를 세우는 쪽이 반대 끝에 있고, 회의가 아니라 조직도를 다시 그리는 쪽이 옆에 있습니다.

연결만 얹는 쪽은 셋입니다.

1. 스크럼 오브 스크럼 — 각 팀에서 한 명씩 나와 정기적으로 모이는 상위 회의입니다. 팀 안에서 매일 묻던 세 가지를 팀 단위로 옮겨 묻습니다. 우리 팀이 무엇을 끝냈는지, 다음에 무엇을 할지, 다른 팀 때문에 막힌 것이 있는지입니다. 새로 만드는 것이 회의 하나뿐이라 여섯 가운데 가장 가볍고, 팀이 서넛일 때 제일 먼저 시도합니다. 결제 팀 대표가 "인증 쪽 답을 2주째 기다립니다" 라고 말하면 그 자리에 로그인 팀 대표가 앉아 있다는 것이 이 회의가 하는 일의 전부입니다.
2. 넥서스 — 여러 팀이 만든 것이 하나의 결과물로 합쳐지는 과정을 관리하는 체계입니다. 팀마다 따로 만든 것을 주기 끝에 한꺼번에 합치면 그때서야 충돌이 드러나므로, 합치는 일을 맡는 사람들을 팀 대표로 따로 묶고 주기 중에도 계속 합쳐 둡니다. 팀 서넛에서 아홉쯤까지를 상정합니다.
3. LeSS — 스크럼을 최소한으로만 늘린 체계입니다. 늘리는 대신 빼는 쪽을 택해서, 제품 책임자도 하나, 우선순위 목록도 하나, 주기도 하나로 두고 팀만 여럿 둡니다. 새 역할과 새 회의를 거의 만들지 않겠다는 것이 규칙이라, 앞의 둘보다 팀 수는 많이 감당하면서 규정집은 얇습니다. 목록이 하나라는 말은 팀마다 자기 할 일을 따로 쌓아 두지 않는다는 뜻입니다. 다섯 팀이 같은 목록의 위에서부터 가져가니 무엇이 회사 전체에서 가장 급한지가 목록 한 장에 드러납니다. 대신 그 목록 하나를 유지하는 일이 만만치 않아, 한 사람이 다섯 팀의 일을 다 이해하지 못하면 이 방식은 곧 무너집니다.

팀 위에 층을 세우는 쪽은 둘입니다.

1. SAFe — 팀의 2주 주기 위에 8~12주짜리 큰 주기를 하나 더 얹고, 그 위에 회사 전체의 투자 결정을 다루는 층을 또 둡니다. 층마다 계획 회의와 책임자와 산출물이 이름까지 규정돼 있어 여섯 가운데 가장 무겁습니다. 큰 주기를 시작할 때는 여덟 팀이 이틀 동안 한자리에 모여 서로가 서로에게 무엇을 언제 넘겨야 하는지를 벽에 붙여 맞춥니다. 사람 백 명의 이틀이 계획에 들어가는 셈이라, 그만큼을 들일 이유가 있는 조직에서만 값을 합니다. 규제를 받는 산업이나 구성원 수백 명 규모처럼 위로 설명할 일이 많은 조직에서 주로 채택합니다.
2. 릴리스 트레인 — 여러 팀이 같은 날짜에 맞춰 함께 내보내는 운영 방식입니다. 이름 그대로 기차라서 정해진 시각에 출발하고, 준비가 안 된 기능은 다음 편을 탑니다. 날짜를 기능에 맞추는 대신 기능을 날짜에 맞추는 것이라, 팀마다 제각각이던 출시일이 하나로 모입니다. SAFe 안에서 큰 주기를 굴리는 장치이기도 하고 따로 떼어 쓰기도 합니다.

조직 구조로 답한 쪽이 하나 있습니다. 스포티파이 모델은 회의나 주기가 아니라 사람을 묶는 단위를 바꿉니다. 한 목표를 맡아 기획과 디자인과 개발이 함께 들어간 소규모 팀을 스쿼드라 부르고, 같은 직군끼리 가로로 묶은 줄을 챕터라 부릅니다. 일은 스쿼드에서 하고 기술 기준과 사람의 성장은 챕터에서 돌봅니다. 앞의 다섯과 다른 점은 이것이 규정집이 아니라 한 회사가 2012년에 공개한 자기 사례라는 것입니다. 공개한 쪽에서 나중에 이것을 모델로 부르지 말라고 했는데, 그때 한 시점을 찍은 사진일 뿐 자기들도 이후로 계속 바꿔 왔기 때문입니다.

여섯 가지는 메뉴판에서 마음에 드는 것을 고르는 항목이 아니라 대체로 순서가 있습니다. 무거운 쪽부터 들이면 회의만 늘고 팀 안에서 하던 결정이 위로 올라가니, 가장 가벼운 상위 회의로 시작해 그것으로 안 되는 지점이 드러날 때 다음을 봅니다. 상위 회의에서 매주 같은 기다림이 반복되면 합치는 방식을 손볼 때가 된 것이고, 팀마다 출시일이 어긋나 서로를 기다리면 날짜를 묶을 때가 된 것입니다. 어느 쪽을 고르든 먼저 할 일은 같습니다. 팀 사이에 기다리는 지점 자체를 줄이는 일입니다. 결제 팀이 인증 팀을 매번 기다려야 하는 구조라면 회의를 아무리 잘 짜도 기다림은 그대로 남고, 새로 생긴 회의는 그 기다림을 더 일찍 알려 줄 뿐입니다.

"팀이 셋으로 늘었는데 아직 팀별로 따로 계획을 세웁니다. 이번 분기엔 스크럼 오브 스크럼부터 돌려 보죠."

가장 가벼운 상위 회의부터 시작하자는 제안입니다.

"그건 이번 트레인에 안 실려 있어요. 다음 편에 넣을지는 다음 계획 회의에서 정합시다."

공동 출시 주기의 범위 밖이니 다음 주기를 기다리라는 뜻입니다.

"45명인데 SAFe를 통째로 깔자는 건 과합니다. 회의가 늘어난 만큼 만드는 시간이 줄어요."

조직 크기에 견줘 체계가 무겁다는 반대 의견이고, 필요한 부분만 떼어 쓰자는 제안이 뒤에 따라붙습니다.

페이지덱에서는 시리즈 A 직후 제품 팀이 하나에서 셋으로 나뉘면서 이 이야기가 나왔습니다. 문서 편집기 팀, 공유와 권한을 맡은 협업 팀, 요금제와 결제를 맡은 팀입니다. 나누고 두 달쯤 지나자 각 팀의 주기는 잘 도는데 전체로 보면 나가는 것이 오히려 줄었습니다.

규원이 대규모 조직용 체계를 통째로 도입하자는 자료를 들고 왔고, 태오가 반대했습니다. 45명에게 층을 세 개 만드는 일이라는 것이었습니다. 지현이 지난 3주 동안 각 팀에서 막혔다고 적힌 항목을 세어 보니 열한 건 가운데 여덟 건이 결제 팀이 협업 팀의 권한 기능을 기다린 것이었습니다. 원인이 한 군데에 몰려 있었던 셈입니다.

그래서 세 팀은 두 가지만 정했습니다. 팀마다 한 명씩 나와 주 2회 30분씩 모이고, 세 팀의 주기 시작일을 같은 화요일로 맞추기로 한 것입니다. 시작일을 맞춘 이유는 한 팀이 주기 중간에 요청을 받으면 그 팀 계획에 끼워 넣을 자리가 없기 때문입니다. 같은 날 시작하면 서로 필요한 것을 각자의 계획 회의에서 함께 올릴 수 있습니다.

한 달 뒤에도 기다리는 건수는 여덟에서 다섯으로 줄었을 뿐입니다. 다만 무엇을 기다리는지가 요청한 날 드러나기 시작했고, 그래서 다음 결정이 보였습니다. 권한 기능을 협업 팀에서 떼어 결제 팀으로 옮기자는 이야기가 그 자리에서 나왔습니다. 회의가 답을 준 것이 아니라 어디를 잘라야 할지를 보여 준 것입니다.

가장 흔한 오해는 이런 체계를 들이면 팀이 늘어도 속도가 그대로 유지된다는 생각입니다. 규칙의 이름에 확장이라는 말이 붙어 있으니 팀 수만큼 결과도 따라 늘 것처럼 읽히기 때문입니다. 실제로 이 체계들이 하는 일은 늘어난 조율 비용을 관리하는 것이지 없애는 것이 아닙니다. 앞에서 본 대로 팀 사이의 연결은 팀 수보다 훨씬 가파르게 늘고, 새로 생긴 회의와 합치는 작업은 그 자체로 시간을 씁니다. 그래서 사람을 두 배로 늘려도 나가는 결과물은 두 배가 되지 않고, 잘 운영해야 1.5배쯤에서 멈춥니다. 이 사실을 모른 채 인원을 두 배로 늘려 두면 경영진은 반년 뒤에 왜 속도가 그대로냐고 묻고, 팀은 체계가 잘못 깔렸다고 답하게 됩니다. 실제로 어긋난 것은 체계가 아니라 처음의 기대치입니다. 채용 계획을 세울 때 팀 수가 늘면 조율에 쓰는 시간도 함께 늘어난다는 몫을 미리 빼 두는 편이 낫습니다.

두 번째는 팀이 여럿이 됐으니 체계를 고르는 것이 첫 단계라는 생각입니다. 선택지가 여섯 개나 되고 저마다 이름과 자격증과 자료가 갖춰져 있어서 고르는 일부터 시작하게 됩니다. 하지만 어느 체계를 골라도 공통으로 하는 일은 팀 사이의 기다림을 드러내고 조율하는 것뿐이고, 기다림 자체를 줄이는 것은 팀을 어떻게 나눴는지에 달려 있습니다. 한 기능을 끝내려면 세 팀을 거쳐야 하는 구조라면 어떤 회의도 그 세 번의 대기를 없애지 못합니다. 이 순서를 뒤집으면 팀은 회의만 늘어난 상태로 반년을 보내고, 기능 하나가 나가는 데 걸리는 시간은 그대로인 채 체계 탓을 하다가 다른 체계로 갈아탑니다. 먼저 볼 것은 어느 팀과 어느 팀이 매주 서로를 기다리는지이고, 그 쌍을 하나로 합치거나 경계를 다시 긋는 쪽이 회의를 늘리는 것보다 대개 먼저입니다.