애자일

소프트웨어를 주문받아 만들던 시절의 순서는 정해져 있었습니다. 고객이 원하는 기능을 빠짐없이 적어 요구사항 명세서라는 문서를 만들고, 양쪽이 거기에 서명하고, 그 문서대로 설계하고 개발한 뒤, 맨 마지막에 한꺼번에 검수합니다. 문서에 없는 일을 하려면 변경 요청서를 따로 쓰고 승인을 받아야 했습니다. 단계가 위에서 아래로만 흐른다고 해서 이 방식을 워터폴이라고 부릅니다.

이 순서 자체가 잘못된 것은 아닙니다. 무엇을 만들지 처음부터 정확히 아는 일이라면 오히려 안전합니다. 다리를 절반쯤 놓은 뒤에 기둥 위치를 옮기자고 할 수는 없으니까요. 문제는 소프트웨어에서 그런 경우가 드물다는 데 있었습니다. 고객도 화면을 직접 써 보기 전에는 자기가 무엇을 원하는지 모르고, 만드는 쪽도 붙여 보기 전에는 무엇이 어려운지 모릅니다.

그래서 현장의 대화는 늘 같은 모양이 됐습니다. 개발 여섯 달째에 고객이 "써 보니 이 화면 순서는 반대가 낫겠다" 고 말하면, 만드는 쪽은 "그건 명세에 없어서 변경 요청을 주셔야 하고 승인까지 3주 걸립니다" 라고 답합니다. 양쪽 다 계약대로 맞는 말을 하는데 그사이 제품은 아무도 원하지 않는 방향으로 한 달치를 더 갑니다. 틀렸다는 사실을 가장 늦게, 돈과 시간을 거의 다 쓴 다음에 알게 되는 구조였습니다.

2001년에 이 구조를 바꾸자는 선언이 나왔습니다. 각자 다른 방식으로 일하던 개발자 열일곱 명이 모여 자기들이 공통으로 지키던 것을 네 문장으로 정리했고, 거기에 애자일이라는 이름을 붙였습니다. 뒤집은 지점은 하나입니다. 계획을 정확히 세우고 그대로 지키는 능력을 기르는 대신, 계획이 틀렸다는 것을 빨리 알아차리고 고치는 능력을 기르자는 것입니다. 그러려면 완성을 마지막으로 미루지 말고 몇 주마다 실제로 쓸 수 있는 조각을 내보여야 합니다.

애자일이 정하는 것은 여기까지입니다. 회의를 몇 번 열고 누가 무엇을 정하는지는 말해 주지 않습니다. 그래서 애자일을 도입한다는 말만으로는 내일 아침에 무엇이 달라지는지 알 수 없고, 팀이 실제로 따라 하는 규칙은 스크럼처럼 한 층 아래에 있는 프레임워크가 정해 줍니다. 태도와 규칙을 나눠 놓은 이 구조를 모르면 애자일과 스크럼을 같은 말로 쓰게 됩니다.

애자일 아래 묶인 용어는 네 갈래입니다. 이 태도의 근거가 어디에 적혀 있는지(근거), 태도를 행동으로 옮기면 무엇이 되는지(원리), 무엇을 대신하려고 나왔는지(대비 개념), 그리고 어디서 무너지는지(위험)입니다.

근거는 한 가지입니다. 애자일 선언은 2001년에 나온 한 쪽짜리 문서로, 네 가지 가치와 열두 개의 원칙이 적혀 있습니다. 가치는 무엇보다 무엇을 더 중시한다는 형태로 쓰여 있습니다. 포괄적인 문서보다 작동하는 소프트웨어를 중시한다는 식입니다. 뒤쪽을 버리라는 말이 아니라 둘이 부딪칠 때 앞쪽을 택하라는 말인데, 이 단서를 떼고 읽으면 문서를 쓰지 말라는 지침으로 오해됩니다. 팀이 방식을 두고 다툴 때 돌아가 볼 기준점이 여기입니다.

원리는 태도를 행동으로 옮긴 갈래입니다. 네 가지가 있고, 앞의 둘은 일을 어떻게 쪼개느냐를, 뒤의 둘은 팀을 어떻게 짜느냐를 정합니다.

1. 반복적 개발 — 같은 대상을 여러 번 돌면서 완성도를 높입니다. 검색 화면을 일단 거칠게 만들어 두고, 다음 주기에 정렬을 붙이고, 그다음 주기에 느린 부분을 손보는 식입니다.
2. 점진적 개발 — 쓸 수 있는 조각을 하나씩 덧붙여 키웁니다. 검색 화면을 먼저 완성해 내보내고, 다음 주기에 필터 화면을 통째로 붙이는 식입니다. 초상화에 빗대면 반복적 개발은 전체를 흐릿하게 그려 놓고 여러 번 덧칠해 선명하게 만드는 쪽이고, 점진적 개발은 왼쪽 눈부터 완성해 나가는 쪽입니다. 실제 팀은 둘을 섞어 씁니다.
3. 자기 조직화 팀 — 무엇을 할지는 밖에서 오더라도 어떤 순서로 어떻게 할지는 팀이 정합니다. 위에서 사람별로 할 일을 배분하면 막힌 사람을 옆자리가 돕지 않게 되고, 계획을 고칠 권한도 함께 사라집니다.
4. 교차 기능 팀 — 출시까지 필요한 직군을 한 팀 안에 모읍니다. 기획과 디자인과 개발이 각각 다른 팀에 흩어져 있으면 2주 안에 무엇을 내보내는 일이 애초에 불가능합니다. 화면 하나를 고치는 데 세 팀의 일정이 맞아떨어져야 하기 때문입니다.

대비 개념은 애자일이 무엇을 대신하려 했는지를 보여 주는 자리입니다. 워터폴이 여기 들어갑니다. 둘을 옳고 그름으로 가르면 잘못 읽게 됩니다. 요구사항이 법으로 정해져 있고 중간에 바뀔 일이 없는 일, 예를 들어 정해진 양식의 규제 보고서를 만드는 일에서는 순서대로 한 번에 끝내는 쪽이 낭비가 적습니다. 애자일이 유리한 조건은 만들면서 알아 가야 하는 일입니다.

위험은 이 태도가 형식만 남았을 때 생기는 상태를 모아 둔 갈래입니다. 무늬만 애자일이 여기 하나 있습니다. 회의 이름과 보드는 그대로 들여왔는데 계획을 고칠 권한은 아무도 갖지 못한 상태를 말합니다. 매일 아침 15분씩 모이지만 막힌 것을 아무도 말하지 않고, 2주마다 돌아보는 자리를 열지만 거기서 나온 개선안이 다음 주기에 반영되지 않는 팀이 그렇습니다.

네 갈래는 순서대로 얽혀 있습니다. 근거가 태도를 정하고, 태도는 일을 쪼개는 방식과 팀을 짜는 방식으로 내려오고, 그 둘 중 하나라도 빠지면 대비 개념과 다를 바 없는 상태로 되돌아갑니다. 2주마다 내보내기로 했는데 팀에 개발자만 있으면 기획과 디자인을 기다리느라 주기가 무너지고, 남는 것은 회의 일정뿐입니다.

"이건 처음부터 다 설계하지 말고 애자일하게 가죠. 2주 안에 붙일 수 있는 만큼만 내보고 반응 보고 정합시다."

정답을 정해 두고 시작할 수 없는 일이니 판단 근거를 먼저 만들자는 제안입니다.

"애자일 한다면서 분기 초에 열두 개 기능이 날짜까지 다 박혀 있으면 그게 무슨 뜻이에요?"

형식만 가져오고 계획을 고칠 여지는 주지 않은 상태를 지적하는 말입니다.

"저희는 스크럼은 안 씁니다. 그래도 애자일하게 일해요. 2주마다 내보내고 매주 우선순위를 다시 봅니다."

애자일은 특정 프레임워크의 이름이 아니라서 정해진 회의 구성을 그대로 따르지 않아도 된다는 뜻입니다.

페이지덱은 무료로 쓰던 팀을 유료 플랜으로 넘어오게 하는 기능을 두고 이 단어를 자주 꺼냅니다. 규원이 분기 시작 전에 열두 개 기능을 날짜까지 박아 둔 계획표를 들고 오자, 지현은 앞의 두 개만 날짜를 정하고 나머지는 순서만 두자고 했습니다. 근거는 지난 분기였습니다. 그때 미리 확정해 둔 아홉 개 가운데 셋은 만들고 나서 아무도 쓰지 않았고, 정작 사용자가 가장 많이 요청한 기능은 계획표에 없다는 이유로 다음 분기로 밀렸습니다.

그래서 이번에는 지현과 민서와 태오가 한 팀으로 붙어 2주 만에 초대 화면 하나만 내보냈습니다. 세 번째 주기에 알게 된 것은 유료 전환을 막는 것이 초대 절차가 아니라 결제 담당자를 따로 지정할 수 없다는 점이었습니다. 원래 계획표에서 그 기능은 열한 번째였습니다. 날짜를 두 개까지만 박아 둔 덕에 순서를 바꿔 그것을 먼저 만들 수 있었습니다.

가장 흔한 오해는 애자일이 계획을 세우지 않는 방식이라는 것입니다. 선언에 계획을 따르기보다 변화에 대응한다는 문장이 있고 문서보다 작동하는 소프트웨어를 앞세우니 그렇게 읽힐 만합니다. 실제로는 계획을 덜 세우는 것이 아니라 더 자주 세웁니다. 한 번 세운 계획을 열여덟 달 동안 들고 가는 대신 2주마다 다시 세우니 계획을 다루는 회의는 오히려 늘어납니다. 이 오해를 그대로 두면 팀은 우선순위 목록도 없이 들어오는 요청을 오는 순서대로 처리하는 상태가 되고, 석 달 뒤에 무엇을 왜 만들었는지 설명하지 못하게 됩니다. 애자일이 버린 것은 계획이 아니라 계획을 바꿀 수 없다는 전제입니다.

두 번째는 애자일을 빨리 만드는 방법으로 읽는 것입니다. 짧은 주기라는 말이 속도처럼 들리고, 도입하자고 설득할 때도 대개 빠르다는 말이 먼저 나오기 때문입니다. 그러나 같은 기능을 만드는 데 드는 시간은 줄지 않습니다. 줄어드는 것은 틀린 방향으로 가고 있다는 사실을 알아차리기까지 걸리는 시간입니다. 열여덟 달 뒤가 아니라 3주 뒤에 알게 되니 버리는 양이 적어지는 것이지, 손이 빨라지는 것이 아닙니다. 이 오해를 가진 조직에서는 주기를 2주에서 1주로 줄이고 회의를 두 배로 늘리는 일이 벌어집니다. 그러면 나가는 결과물이 아니라 압박만 늘고, 팀은 주기 안에 끝난 것처럼 보이도록 작업을 잘게 쪼개는 쪽으로 움직입니다.