크런치

정해진 날짜에 무언가를 내보내야 하는데 남은 일이 그 안에 들어가지 않는 상황은 어느 업계에나 있습니다. 소프트웨어에서 이 상황이 특히 잦은 것은 만들기 전에는 얼마나 걸릴지 정확히 알 수 없기 때문입니다. 4주로 잡은 기능이 실제로는 6주짜리였다는 사실은 대개 3주차에 드러납니다.

그때 손에 쥔 선택지는 셋뿐입니다. 날짜를 미루거나, 만들기로 한 것을 줄이거나, 시간을 더 쓰는 것입니다. 앞의 둘은 밖에 약속한 것을 고쳐야 해서 누군가 책임을 지고 말을 꺼내야 합니다. 세 번째는 아무에게도 알리지 않고 팀 안에서 시작할 수 있습니다.

그래서 현장에서는 세 번째가 기본값이 됐습니다. 발표를 2주 앞둔 회의는 대개 이렇게 끝납니다. "일단 이번 2주만 좀 달립시다." 아무도 무엇을 뺄지 정하지 않았고 날짜도 그대로인데 회의는 마무리됩니다.

크런치는 그 2주를 부르는 이름입니다. 게임 업계에서 출시 직전 몇 달을 가리키던 말이 넘어와, 지금은 소프트웨어 팀이 릴리스를 앞두고 몰아 일하는 기간 전반을 뜻합니다. 이름이 붙은 뒤에야 이 기간을 어쩔 수 없는 일이 아니라 관리할 대상으로 놓고 이야기할 수 있게 됐습니다.

부족한 것은 사람이나 실력이 아니라 남은 시간이므로, 한 사람이 하루에 쓰는 시간을 늘려 그 차이를 메웁니다. 하루 8시간 일하던 다섯 명이 2주 동안 12시간씩 일하면 계산상 1.5배의 시간이 생깁니다. 이 산수가 맞아떨어지는 동안에는 크런치가 실제로 통합니다.

다만 산수가 맞는 구간은 짧습니다. 시간이 늘어난 만큼 산출이 늘어나는 것은 대체로 첫 한두 주뿐이고, 그 뒤부터는 다음 세 가지가 동시에 일어납니다.

1. 실수가 늘어납니다. 피곤한 상태에서 짠 코드에는 평소보다 많은 결함이 들어가고, 그 결함을 찾아 고치는 시간이 늘어난 시간에서 다시 빠져나갑니다.
2. 나중에 갚을 빚이 쌓입니다. 급하니까 코드 리뷰를 건너뛰고 임시로 질러 둔 부분을 남깁니다. 이렇게 미뤄 둔 정리 작업을 기술 부채라고 부르는데, 크런치로 번 2주만큼의 빚은 다음 분기에 이자까지 붙어 돌아옵니다.
3. 회복이 안 됩니다. 셋째 주쯤부터는 주말을 쉬어도 월요일의 집중력이 돌아오지 않습니다. 그 상태가 더 이어지면 번아웃으로 넘어가고, 그 사람이 회복하는 동안 남은 사람의 몫이 다시 늘어납니다.

그래서 크런치는 시간을 빌려 오는 일에 가깝습니다. 없는 시간을 만들어 내는 것이 아니라 다음 주기에서 당겨 쓰는 것입니다. 한 번 쓰고 갚으면 쓸 만한 수단이고, 갚지 않은 채로 다시 쓰면 잔고가 줄어듭니다.

길이와 빈도가 실제 차이를 만듭니다. 1년에 한 번, 2주, 끝난 뒤 쉬는 기간이 붙는 크런치는 팀이 견딥니다. 분기마다 돌아오고 끝나도 쉬지 않는 크런치는 사람이 빠져나가는 결과로 이어집니다.

바깥과 맺은 약속에 날짜가 박혀 있을 때 가장 자주 나옵니다. 투자자 대상 발표, 전시회 출품, 기업 고객과 계약서에 적은 납기 같은 자리입니다. 이런 날짜는 팀이 정한 것이 아니라 밀 수 없다고 여겨지므로, 일정 압박이 그대로 크런치로 이어집니다.

장애가 터진 직후에도 비슷한 모양이 나타납니다. 다만 이쪽은 성격이 다릅니다. 서비스가 멈춰 있는 동안 밤새 고치는 일은 크런치가 아니라 소방 업무에 가깝습니다. 크런치는 계획된 결과물을 내기 위한 것이고, 소방 업무는 터진 것을 되돌리기 위한 것입니다.

말이 쓰이는 자리는 대개 둘 중 하나입니다. 하나는 시작을 알리는 자리입니다. "다음 2주는 크런치입니다" 라는 공지는 이 기간에 다른 일을 요청하지 말라는 뜻이기도 합니다. 다른 하나는 되돌아보는 자리입니다. 회고에서 "이번에도 크런치로 막았다" 는 말이 나오면, 같은 지점에서 반복해서 밀리고 있으니 원인을 찾자는 제안입니다.

채용 과정에서 지원자가 묻는 질문이기도 합니다. "크런치가 얼마나 자주 있나요" 라는 물음에 대한 답은 그 회사가 일정을 어떻게 다루는지를 보여 줍니다.

"이번 출시까지 2주는 크런치로 갑시다. 대신 끝나면 한 주 쉽니다."

몰아 일하는 기간을 명시적으로 열되 갚을 시점까지 같이 정하는 말입니다.

"크런치로 막을 수 있는 양이 아니에요. 범위를 줄여야 합니다."

시간을 늘려도 모자라니 만들기로 한 것을 깎자는 제안입니다.

"지난 분기에도 크런치였고 이번에도 크런치면 그건 추정이 틀린 겁니다."

한 번은 사고지만 반복되면 계획 방식의 문제라는 지적입니다.

페이지덱은 지난해 큰 기업 고객과 계약하면서 권한 관리 기능의 납기를 계약서에 적었습니다. 3주 전에 예상보다 일이 많다는 것이 드러났고, 태오와 개발팀은 2주 동안 매일 밤늦게까지 남아 기능을 맞췄습니다. 납기는 지켰습니다.

대신 다음 스프린트 두 개가 그때 질러 둔 부분을 정리하는 데 들어갔고, 지현은 그 두 주기에 계획했던 항목을 전부 뒤로 밀어야 했습니다. 규원은 그 뒤로 계약서에 날짜를 적기 전에 개발팀의 추정을 먼저 받기로 정했습니다. 크런치 자체를 금지한 것이 아니라 크런치를 부르는 자리를 하나 줄인 것입니다.

크런치를 팀의 헌신도로 읽는 경우가 가장 많습니다. 늦게까지 남아 있는 팀이 더 열심히 하는 팀처럼 보이기 때문입니다. 하지만 크런치가 필요해졌다는 사실 자체가 대개 추정이나 범위 조정이 제때 이뤄지지 않았다는 신호입니다. 헌신도로 읽기 시작하면 팀은 문제를 일찍 알리는 대신 늦게까지 남는 쪽을 택하게 되고, 밀린다는 사실은 더 늦게 드러납니다.

한 번 잘 통했으니 다음에도 쓸 수 있다고 보는 것도 흔한 오해입니다. 2주를 달려 납기를 맞춘 경험은 강하게 남습니다. 실제로는 그 방식이 통한 이유가 그 전까지 팀에 여유가 남아 있었기 때문인 경우가 많습니다. 연달아 쓰면 같은 2주를 달려도 나오는 양이 줄고, 대신 결함과 퇴사는 늘어납니다. 크런치를 계획에 미리 넣어 두는 팀에서는 그 여유가 처음부터 없습니다.