실행 리스크

일정이 밀리고 품질이 떨어지는 일은 소프트웨어를 만들기 시작한 이래 늘 있었습니다. 걸림돌은 그 일을 부를 이름이 없었다는 데 있었습니다. 출시가 3주 밀린 뒤 회고에서 나오는 말은 대체로 하나였습니다. "이번엔 좀 급했죠." 다음 문장도 정해져 있었습니다. "다음엔 여유 있게 잡읍시다."

이 대화에는 고칠 대상이 없습니다. 급했다는 것은 결과로 나타난 상태이지 원인이 아니고, 여유 있게 잡자는 것은 다짐이지 규칙이 아닙니다. 그래서 다음 주기에도 같은 일이 같은 순서로 벌어집니다. 팀은 세 번째 분기쯤부터 일정을 세우는 일 자체를 형식으로 여기게 됩니다.

바뀐 지점은 이 문제들이 매번 새로운 사고가 아니라 몇 가지 정해진 모양으로만 나타난다는 것을 알아차린 데 있습니다. 날짜가 먼저 박히고 할 일의 양은 그대로인 상황, 마감 직전에 시간을 늘려 메우는 기간, 급한 불을 끄느라 계획한 일을 한 줄도 못 건드리는 주기. 각각에 이름이 붙자 회고의 문장이 달라졌습니다. "이번엔 급했다" 대신 "이번엔 팀 시간의 40퍼센트가 장애 처리로 갔다"고 말하면, 다음에 무엇을 바꿀지가 따라 나옵니다.

실행 리스크는 그렇게 이름이 붙은 문제들을 한 자리에 모아 둔 이름입니다. 방법론을 고르고 그 위에 프레임워크를 얹고 역할을 나누고 작업 크기를 추정해 계획을 세워도, 계획과 실제가 벌어지는 자리는 그대로 남습니다. 앞의 여섯 갈래가 무너지는 지점이 여기라는 뜻입니다.

여기 들어가는 문제는 어느 날 갑자기 생기지 않고 앞선 결정의 결과로 나타납니다. 합의 없이 범위가 슬금슬금 늘어나는 스코프 크리프는 두 달 전에 "그 정도는 그냥 같이 해 드리죠" 라고 답한 자리에서 시작됩니다. 빨리 가려고 정리를 미뤄 둔 대가가 쌓이는 기술 부채도 지난 분기에 하루를 아끼려고 내린 선택이 이번 분기에 사흘로 돌아온 것입니다. 그래서 이 갈래의 용어는 사고 보고서가 아니라 앞으로 내릴 결정을 점검하는 목록에 가깝습니다.

이름이 생기면서 달라진 것이 하나 더 있습니다. 말을 꺼낼 수 있게 된 것입니다. 마감 2주 전에 개발자가 "이대로 가면 테스트할 시간이 없습니다" 라고 말하면 그것은 개인의 엄살로 들립니다. 같은 말을 "지금 일정 압박이 걸려 있고, 이대로면 다음 주기가 소방 업무로 채워집니다" 라고 하면 팀이 함께 아는 현상을 가리키는 말이 됩니다. 용어 하나가 사람 문제를 구조 문제로 옮겨 놓는 셈입니다. 이 말이 실제로 쓰이는 자리는 둘입니다. 계획을 세울 때는 무엇을 미리 비워 둘지를 묻는 질문이 되고, 회고에서는 이번 한 번뿐인 사고와 세 주기째 같은 모양으로 돌아오는 문제를 갈라 줍니다.

실행 리스크 아래 묶인 용어는 두 갈래입니다. 계획이 무너질 때 팀이 실제로 겪는 상황(유형)과, 그 상황이 왜 되풀이되는지를 설명하는 오래된 관찰(법칙)입니다. 앞쪽이 증상이라면 뒤쪽은 그 증상에 흔히 내려지는 처방이 왜 듣지 않는지를 말해 줍니다.

유형은 팀이 몸으로 겪는 쪽입니다. 세 가지가 있고, 따로 떨어져 있지 않고 대개 순서대로 이어집니다.

1. 일정 압박 — 날짜가 먼저 정해져 있고 할 일의 양은 줄지 않을 때 생깁니다. 4주로 추정한 기능에 3주 뒤 발표 일정이 잡히면 팀은 1주치를 어디선가 빼야 합니다. 먼저 빠지는 쪽은 대개 테스트나 코드 리뷰처럼 지금 당장은 티가 나지 않는 작업입니다. 날짜를 바꿀 수 없다는 전제가 서는 순간 조정할 수 있는 항목이 품질밖에 남지 않기 때문입니다.
2. 크런치 — 압박이 풀리지 않으면 남은 방법은 시간을 늘리는 것뿐입니다. 2주 동안 매일 밤 11시까지 남아 메우는 기간이 여기 해당합니다. 한두 주는 실제로 통합니다. 다만 그렇게 나간 코드에는 급히 질러 둔 부분이 남고, 사람의 집중력도 셋째 주부터는 주말을 쉬어도 돌아오지 않습니다. 번아웃까지 가면 그 사람이 회복하는 동안 남은 사람의 몫이 다시 늘어납니다.
3. 소방 업무 — 급히 나간 것이 장애나 문의를 만들면 다음 주기는 그것을 처리하는 데 쓰입니다. 계획한 일은 다시 밀리고, 밀린 만큼 그다음 날짜가 또 압박으로 돌아옵니다. 한 바퀴가 돌고 나면 팀에는 이번 주기에 무엇을 하기로 했는지 기억하는 사람이 남지 않습니다. 주간 계획의 절반이 매번 지워지는 팀에서는 아무도 계획을 진지하게 세우지 않게 되고, 그러면 다음 주기의 예측은 더 빗나갑니다.

셋을 한 줄로 이으면 이렇습니다. 날짜가 밀어붙이고, 사람이 시간으로 메우고, 그렇게 생긴 빚을 다음 주기가 갚습니다. 그래서 하나만 떼어 고치려 들면 대개 실패합니다. 크런치를 금지한다고 공지해도 앞의 압박이 그대로면 사람들은 퇴근 후에 집에서 같은 일을 합니다.

법칙은 그 되풀이를 설명하는 쪽입니다. 세 가지가 있습니다. 실험으로 증명된 공식이 아니라 오래 관찰된 경향이라 예외도 있지만, 알아 두면 잘못된 처방을 고르지 않게 됩니다.

1. 파킨슨의 법칙 — 주어진 시간을 다 쓰도록 일이 늘어난다는 관찰입니다. 2주면 끝날 작업에 4주를 주면 대체로 4주가 걸립니다. 시작이 늦어지고, 다듬을 곳이 계속 눈에 띄기 때문입니다. 일정을 넉넉히 잡는 것만으로 앞의 유형이 사라지지 않는 이유가 여기 있습니다.
2. 브룩스의 법칙 — 이미 늦어진 프로젝트에 사람을 더하면 더 늦어진다는 관찰입니다. 새로 온 사람은 맥락을 익혀야 하고, 그 설명은 지금 가장 바쁜 사람이 해야 합니다. 세 명이 하던 일에 두 명을 더하면 첫 몇 주 동안 팀의 산출은 오히려 줄어듭니다.
3. 콘웨이의 법칙 — 만들어진 시스템의 구조가 그것을 만든 조직의 소통 구조를 닮는다는 관찰입니다. 결제와 알림을 서로 다른 팀이 맡고 있으면 두 기능 사이에 팀 경계를 닮은 이음매가 생깁니다. 일정이 늘 같은 지점에서 밀린다면 원인이 담당자의 실력이 아니라 조직을 가른 선에 있을 수 있습니다. 이 경우 처방은 그 사람을 교체하는 것이 아니라 두 기능을 한 팀으로 합치거나 둘 사이에 합의된 규격을 두는 쪽입니다.

두 갈래를 함께 봐야 처방이 맞아 들어갑니다. 유형만 보면 나오는 답은 대개 둘 중 하나입니다. 더 열심히 하자, 아니면 사람을 더 붙이자. 브룩스의 법칙은 두 번째 답이 왜 듣지 않는지를, 파킨슨의 법칙은 첫 번째 답의 반대편인 "여유를 주자"가 왜 듣지 않는지를 설명합니다. 남는 선택지는 범위를 줄이거나 일하는 구조를 바꾸는 쪽입니다. 세 법칙이 팀에게 방법이 없다고 말하는 것은 아닙니다. 어느 손잡이가 가짜인지를 알려 줄 뿐입니다. 추정에 여유를 덧붙이는 일, 사람을 더 넣는 일, 더 열심히 하자고 말하는 일이 그 셋입니다.

기록이 있어야 어느 쪽인지 가릴 수 있습니다. 스프린트처럼 고정된 주기로 일하는 팀이라면 주기마다 계획한 양과 실제로 끝낸 양, 그리고 계획에 없던 일에 쓴 시간을 함께 적어 둡니다. 세 주기만 모여도 이번 분기의 문제가 압박 쪽인지 소방 업무 쪽인지가 숫자로 보입니다. 계획한 20건 중 12건을 끝냈고 계획에 없던 일에 8일을 썼다는 기록은 "이번엔 좀 급했다" 와 달리 다음 계획을 바로 고치게 만듭니다.

"지난 분기 회고 보면 계획에 없던 일이 팀 시간의 40퍼센트예요. 이번엔 그만큼 비워 두고 계획합시다."

소방 업무가 매 주기 일정하게 발생하니 그 양을 예외가 아니라 상수로 놓고 계획하자는 제안입니다.

"지금 사람 더 붙이는 건 다음 달을 더 늦추는 선택이에요. 범위를 깎는 쪽으로 갑시다."

브룩스의 법칙을 근거로, 인력 투입 대신 범위 조정을 택하자는 말입니다.

"날짜는 못 미룬다고 하니 밤새서 맞추자는 얘기가 나올 텐데, 그러면 다음 주기를 통째로 잃습니다."

크런치로 이번 마감을 넘겨도 그 대가가 다음 주기에 청구된다는 경고입니다.

페이지덱에서는 분기 계획을 세우는 자리에서 이 말이 나옵니다. 지현이 지난 세 주기의 기록을 펼쳐 놓고, 계획한 양과 실제로 끝낸 양의 차이가 어디서 났는지를 짚습니다. 차이의 대부분이 계획에 없던 장애 처리와 고객 문의였다면 그건 팀이 게을러서 생긴 간극이 아닙니다. 다음 분기에는 그만큼을 처음부터 비워 두고 계획을 세우는 편이 정확합니다.

태오가 여기에 하나를 덧붙입니다. 장애가 몰리는 지점이 매번 같은 기능이라면 그 기능은 일정 문제가 아니라 구조 문제라는 것입니다. 그러면 다음 분기 계획에는 새 기능 대신 그 부분을 정리하는 작업이 한 자리를 차지합니다. 규원은 이 자리에서 날짜를 지키라고 말하는 대신 무엇을 뺄지를 묻습니다. 셋 중 하나를 고르게 하지 않으면 팀은 늘 품질을 뺍니다. 품질은 그 자리에서 아무도 항의하지 않는 유일한 항목이기 때문입니다. 날짜를 미루면 영업이, 범위를 줄이면 고객이 바로 반응하지만, 테스트를 건너뛴 것은 몇 주 뒤 장애로 나타나기 전까지 아무 소리도 내지 않습니다.

가장 잦은 오해는 이 문제들을 사람의 성실함이나 실력 문제로 읽는 것입니다. 마감을 못 지킨 팀과 지킨 팀이 눈앞에 함께 있으니 차이가 사람에게 있다고 보기 쉽습니다. 하지만 유형 세 가지는 모두 날짜와 범위와 인원이 맞물린 자리에서 생깁니다. 같은 사람을 다른 조건에 놓으면 결과가 달라집니다. 원인을 사람에게 돌리면 처방은 독려와 평가로 좁아지고, 팀은 문제를 숨기는 쪽으로 움직입니다. 막힌 일을 늦게 말할수록 대응할 시간은 줄어들고, 그다음 주기는 더 나빠집니다. 일정이 밀린 사실이 마감 이틀 전에 보고되는 조직은 대개 사람이 불성실한 쪽이 아니라 일찍 말한 사람이 손해를 본 전례가 쌓인 쪽입니다.

두 번째는 리스크를 목록으로 적어 두는 것만으로 관리했다고 여기는 것입니다. 문서에 항목이 적혀 있고 담당자와 날짜가 채워져 있으면 해야 할 일을 한 것처럼 보입니다. 그런데 목록에 적히는 순간 그 항목은 대개 그대로 멈춥니다. 실제로 달라지는 것은 계획을 세울 때 무엇을 덜어 냈는지, 무엇이 터졌을 때 누가 어디까지 결정할 수 있는지를 미리 정해 둔 경우뿐입니다. 적어 두기만 한 팀은 같은 문제가 터졌을 때 문서를 열어 보고 "역시 이게 문제였네" 라고 확인만 하게 됩니다. 목록이 일을 바꾸려면 항목마다 무엇이 관찰되면 계획을 고칠지가 함께 적혀 있어야 합니다. 예를 들어 계획에 없던 일이 두 주기 연속 30퍼센트를 넘으면 다음 주기 계획량을 그만큼 줄인다는 식입니다.