일하는 방식

소프트웨어를 만드는 순서는 원래 건물을 짓는 순서에서 빌려 왔습니다. 요구사항을 빠짐없이 받아 적고, 설계를 확정하고, 그대로 만들고, 마지막에 검수합니다. 앞 단계가 끝나야 다음으로 넘어가고 위에서 아래로만 흐른다고 해서 폭포수라고 불렀습니다. 다리를 놓는 일이라면 합리적인 순서입니다. 기둥을 절반쯤 올린 뒤에 위치를 옮기자고 할 수는 없으니까요.

문제는 소프트웨어에서는 되돌아갈 일이 자주 생긴다는 데 있었습니다. 열여덟 달 동안 문서대로 만들어 납품했더니 그사이 고객의 사업이 바뀌어 쓸 데가 없어진 일, 착수할 때 적어 둔 요구사항 300개 가운데 실제로 쓰이는 기능이 마흔 개였던 일이 반복됐습니다. 틀렸다는 사실을 가장 늦게, 돈을 다 쓴 다음에 알게 되는 구조였습니다.

그래서 2001년에 이 순서를 뒤집자는 선언이 나왔고, 짧게 만들어 보여 주고 고치는 방식을 실제로 굴리기 위한 규칙들이 뒤따라 쏟아졌습니다. 회의 이름, 역할 이름, 작업을 세는 단위, 보드 쓰는 법이 각각 이름을 달고 늘어났습니다. 십 년쯤 지나자 회사마다 조합이 달라졌습니다. 어떤 팀은 2주씩 끊어 일하고, 어떤 팀은 끊지 않고 흐름만 관리하고, 어떤 팀은 둘을 섞었습니다.

이 축은 그렇게 쌓인 규칙 더미에 붙인 이름입니다. 첫 출근한 사람이 듣는 말을 떠올리면 왜 한 덩어리로 묶어야 하는지가 보입니다. "그건 다음 스프린트에 넣죠", "일단 백로그로 내려 두세요", "진행 중인 게 꽉 차서 지금은 못 당겨요" 같은 문장이 하루에도 몇 번씩 지나갑니다. 스프린트는 2주처럼 정해진 길이로 끊어 둔 작업 주기고, 백로그는 아직 손대지 않은 할 일을 쌓아 두는 목록입니다. 두 단어는 같은 틀에서 나왔고 그 틀에는 이름과 사용법이 있는데, 연결을 모르면 낱개의 은어로 외우게 됩니다.

일하는 방식 아래 묶인 용어는 일곱 갈래로 나뉩니다. 무엇을 옳다고 보고 일하는지(방법론), 그 생각을 어떤 규칙으로 옮기는지(프레임워크), 규칙을 누가 돌보는지(역할), 얼마나 걸릴지를 어떻게 가늠하는지(추정·계획), 어떻게 이야기하고 누가 정하는지(협업), 일을 어떤 단위로 쪼개 추적하는지(작업 관리), 그리고 이 모든 것이 어디서 무너지는지(리스크)입니다.

방법론은 태도를 정하는 갈래입니다. 두 가지가 있습니다. 애자일은 계획을 한 번에 확정하지 않고 짧게 만들어 내보인 뒤 방향을 고치는 쪽을 택합니다. 린은 가치로 이어지지 않는 일을 낭비로 보고 걷어 내 흐름을 빠르게 만드는 쪽에 무게를 둡니다. 둘은 경쟁하지 않고 겹칩니다. 반쯤 만들다 만 기능 열두 개를 동시에 붙들고 있는 상태를 애자일은 피드백이 늦어지는 문제로 읽고 린은 재고가 쌓인 낭비로 읽는데, 시키는 일은 같습니다. 벌여 놓은 것을 줄이고 하나씩 끝내라는 것입니다. 다만 태도만으로는 내일 아침에 무엇을 할지가 정해지지 않습니다. 회의를 몇 번 열고 누가 무엇을 정할지는 한 층 아래에서 결정됩니다.

프레임워크는 그 태도를 손에 잡히는 규칙으로 옮긴 갈래입니다. 네 가지가 있고, 시간을 끊느냐 흐름을 관리하느냐가 첫 갈림길입니다.

1. 스크럼 — 2주 같은 고정 길이로 시간을 끊고, 주기 앞에 무엇을 할지 고르는 회의와 주기 끝에 돌아보는 회의를 정해 둡니다. 역할과 회의가 이름까지 규정돼 있어 처음 도입하는 팀이 따라 하기 쉽습니다.
2. 칸반 — 주기를 끊지 않고 일이 흘러가는 모습을 보드에 늘어놓습니다. 핵심 규칙은 한 칸에 동시에 올려 둘 수 있는 일의 개수를 막아 두는 것입니다. 개발 중 칸을 세 건으로 제한하면 네 번째를 시작하려던 사람이 먼저 막힌 건을 치우게 됩니다. 장애나 문의처럼 예고 없이 들어오는 일이 많은 팀에 맞습니다.
3. 익스트림 프로그래밍 — 회의보다 개발 습관을 규정합니다. 둘이 한 화면을 보며 짜기, 테스트를 먼저 쓰고 그다음에 기능을 만들기, 하루에도 여러 번 각자 작업을 합치기 같은 규칙이 여기 속합니다.
4. 스케일링 프레임워크 — 한 팀에 맞춰 만든 규칙을 여러 팀에 얹을 때 쓰는 확장 체계입니다. 팀이 여덟 개가 되면 각 팀이 따로 잘 도는 것만으로는 부족하고, 서로 기다리는 지점을 맞출 규칙이 따로 필요해집니다.

역할은 그 규칙을 누가 돌보는지를 가르는 갈래입니다. 네 자리가 있고, 한 팀을 보느냐 여러 팀을 보느냐와 절차만 돌보느냐 사람까지 책임지느냐로 나뉩니다.

1. 스크럼 마스터 — 한 팀에 붙어 회의가 제 기능을 하게 만들고 팀이 막힌 곳을 치웁니다. 일을 시키고 평가하는 자리가 아니라서 팀장과 다릅니다.
2. 애자일 코치 — 여러 팀을 돌며 방식을 고치도록 가르칩니다. 대신 해결해 주기보다 팀이 스스로 고치게 만드는 쪽입니다.
3. 딜리버리 매니저 — 약속한 것이 약속한 때 나가는지를 봅니다. 여러 팀과 외부 일정이 얽힌 큰 출시에서 주로 필요해집니다.
4. 엔지니어링 매니저 — 개발자의 평가와 성장까지 함께 맡습니다. 사람에 대한 권한을 가졌다는 점에서 앞의 셋과 갈립니다.

구성원이 열 명 남짓인 회사는 네 자리를 따로 두지 않고 한 사람이 겸합니다. 사람이 늘면서 먼저 떨어져 나오는 쪽은 대개 절차를 돌보는 자리입니다.

추정·계획은 얼마나 걸릴지를 다루는 갈래입니다. 애자일 추정은 시간 대신 상대 크기로 가늠합니다. 로그인 화면 만들기를 3이라고 정해 두고 다른 작업을 그것과 견줘 1·2·5·8로 매기는 식입니다. 같은 일도 사람마다 걸리는 시간이 달라 시간으로 매기면 합산이 의미를 잃기 때문입니다. 캐파시티 플래닝은 다음 주기에 이 팀이 실제로 소화할 수 있는 양을 셉니다. 개발자 다섯 명에 2주면 50인일처럼 보이지만, 휴가 3일과 면접 2일과 다른 팀 지원 4일을 빼면 41인일이 남습니다. 추정이 작업의 크기를 재는 일이라면 이쪽은 담을 그릇의 크기를 재는 일입니다.

협업은 사람 사이의 규칙을 다루는 갈래입니다. 협업 방식은 언제 모이고 언제 각자 하는지를 정합니다. 같은 시간에 모여 말로 푸는 방식과 문서에 적어 두고 각자 읽는 방식은 속도와 기록이 정반대라, 근무 시간이 겹치지 않는 팀은 후자로 기울 수밖에 없습니다. 의사결정 방식은 누가 무엇을 정하는지를 미리 적어 둡니다. 전원이 동의할 때까지 기다릴지, 의견을 다 듣되 한 사람이 정할지, 아예 한 사람에게 맡길지를 사안별로 정해 두지 않으면 같은 결정이 회의마다 다시 열립니다. 가격을 올릴지 말지를 다섯 명이 합의로 정하려 들면 세 주가 지나도 결론이 나지 않습니다.

작업 관리는 일을 어떤 단위로 쪼개 추적하는지를 다루는 갈래입니다. 작업 항목은 이슈 관리 도구에 등록되는 일 한 건입니다. 큰 덩어리부터 에픽, 스토리, 태스크, 버그처럼 층이 나뉘고 층마다 적어 두는 정보가 다릅니다. 어디까지 쪼갤지는 팀이 정하는데 대체로 한 사람이 며칠 안에 끝낼 크기까지 내려갑니다. 쪼개는 크기가 들쭉날쭉하면 남은 항목 수를 세도 진척이 보이지 않습니다.

리스크는 앞의 여섯 갈래가 어디서 무너지는지를 모아 둔 갈래입니다. 실행 리스크에는 범위가 슬금슬금 늘어나는 일, 다른 팀 작업을 기다리다 멈추는 일, 급하게 질러 둔 코드가 다음 주기의 속도를 깎는 일이 들어갑니다. 셋 다 어느 날 갑자기 생기지 않고 앞선 결정의 결과로 나타납니다.

일곱 갈래는 메뉴판에서 하나씩 고르는 항목이 아니라 서로를 붙듭니다. 프레임워크를 고르면 회의와 역할이 따라오고, 역할이 정해지면 결정 방식이 정해지고, 추정 단위가 있어야 계획이 서고, 계획과 실제가 벌어지는 자리에서 리스크가 드러납니다. 한 조각만 떼어다 쓰면 대개 겉도는 이유가 여기 있습니다. 매일 아침 15분 회의만 들여온 팀에서 아무도 막힌 것을 말하지 않는다면 빠진 것은 회의가 아니라 말해도 불이익이 없다는 합의입니다.

"입사하면 첫 주에 팀 일하는 방식부터 맞춥니다. 회의가 뭐가 있고 결정은 누가 하는지요."

개인 실력보다 팀의 규칙을 먼저 익혀야 일이 굴러간다는 뜻입니다.

"이건 도구 문제가 아니라 일하는 방식 문제예요."

티켓 양식이나 보드 설정을 고쳐서 될 일이 아니라 결정 절차와 회의 구조를 손봐야 한다는 지적입니다.

"팀이 커지면서 예전 방식이 안 맞아요. 다음 분기에 한 번 다시 짜죠."

여덟 명일 때 통하던 규칙이 스물다섯 명에서 깨졌으니 새로 합의하자는 제안입니다.

페이지덱은 구성원이 45명으로 늘면서 팀마다 방식이 갈렸습니다. 지현이 있는 제품 팀은 2주 주기로 끊어 일하고, 태오가 있는 플랫폼 팀은 주기를 두지 않고 보드로 흐름만 관리합니다. 규원이 왜 한 회사에서 둘이 다르냐고 물었을 때 태오가 든 근거는 들어오는 일의 성격이었습니다. 제품 팀은 2주 뒤에 무엇이 나올지 미리 정할 수 있지만, 플랫폼 팀은 장애 신고와 다른 팀 요청이 예고 없이 들어와 주기를 지키려 할수록 계획이 매주 깨진다는 것이었습니다.

대신 두 팀이 맞춰 둔 것도 있습니다. 작업 항목의 층을 같은 이름으로 쓰고, 분기마다 같은 날 방식을 되돌아보고, 팀을 넘어가는 요청은 같은 창구로 받습니다. 방식을 통일하는 대신 팀 사이에 걸치는 부분만 맞춘 셈입니다.

일하는 방식을 회의와 도구의 목록으로 여기는 경우가 가장 흔합니다. 밖에서 보이는 것이 매일 아침 회의와 보드와 티켓뿐이니 그렇게 읽힐 만합니다. 하지만 실제로 팀의 속도를 가르는 것은 결정 권한이 어디 있고 나쁜 소식이 얼마나 빨리 위로 올라오느냐입니다. 목록만 베껴 오면 모양은 갖췄는데 아무것도 달라지지 않는 상태가 됩니다. 매일 모여 한 명씩 어제 한 일을 읊고 흩어지는데 정작 막힌 사람은 일주일째 말하지 않는 회의가 그 상태입니다.

정답이 하나 있다고 믿는 것도 자주 보입니다. 책과 자격증이 완성된 규칙 한 벌을 가르치니 그중 하나가 옳은 답처럼 보입니다. 그러나 맞는 방식은 팀 규모와 제품 성격과 고객과의 약속에 따라 달라집니다. 대기 시간을 계약으로 못 박은 팀과 아직 만들 것을 찾는 팀에 같은 규칙을 씌울 수는 없습니다. 정답이 있다고 믿으면 남의 회사 규칙을 그대로 옮겨 놓고, 잘 안 돌아갈 때 규칙을 의심하는 대신 팀이 제대로 못 지킨다고 결론짓게 됩니다. 그러면 고칠 곳을 영영 못 찾습니다.