워터폴

큰 시스템을 여러 해에 걸쳐 만들던 시절에는 순서대로 끝내는 방식이 당연했습니다. 건물을 짓는 절차에서 온 생각입니다. 설계 도면이 확정된 뒤에 착공하고, 골조가 올라간 뒤에 내부 공사를 합니다. 순서를 뒤집으면 벽을 부수고 다시 세워야 하니 앞 단계를 확실히 끝내는 편이 싸게 끝납니다.

소프트웨어에서 이 전제가 흔들리는 지점은 요구사항입니다. 사람은 무엇을 원하는지 처음에 다 말하지 못합니다. 만들어진 화면을 실제로 눌러 본 뒤에야 자기가 원했던 것이 그게 아니었음을 압니다.

페이지덱이 공공기관 납품용 기능을 이 방식으로 만들며 그 차이를 겪었습니다. 요구사항 문서 40쪽을 두 달에 걸쳐 확정하고 넉 달을 들여 만들어 냈습니다. 검수에서 나온 지적이 열두 개였고 그중 아홉이 같은 성격이었습니다. 문서에 적힌 대로 만들었는데 실제 업무 흐름과 맞지 않는다는 것이었습니다. 문서를 쓸 때 담당자도 그 흐름을 정확히 몰랐고, 화면이 나온 뒤에야 알게 된 것입니다.

계획을 한 번에 고정하지 않고 짧게 반복하며 방향을 고쳐 가는 애자일 아래에서 워터폴은 대비 개념 자리를 맡습니다. 무엇을 대신하려고 애자일이 나왔는지를 보여 주는 자리이고, 옳고 그름이 아니라 조건의 문제로 읽어야 합니다.

단계는 다섯이고, 각 단계가 산출물로 끝나며 승인을 받아야 다음으로 넘어갑니다.

1. 요구사항 분석입니다. 무엇을 만들지 전부 적습니다. 이 문서가 나중에 검수와 계약의 근거가 되므로, 적히지 않은 것은 만들지 않고 적힌 것은 반드시 만듭니다.
2. 설계입니다. 화면 구성과 데이터 구조를 확정합니다. 이 단계 산출물을 보고 개발 기간과 인원을 계산해 일정표를 만듭니다.
3. 구현입니다. 설계대로 만듭니다. 이 단계가 전체 기간의 절반쯤을 차지하고, 이 기간에는 밖에서 볼 수 있는 결과물이 거의 나오지 않습니다.
4. 시험입니다. 만든 것을 1번 문서와 한 줄씩 대조합니다. 문서에 적힌 항목이 전부 동작하는지가 통과 기준입니다.
5. 인수와 운영입니다. 고객이 검수하고, 통과하면 넘기고 그 뒤로는 고치는 일만 남습니다.

이 절차의 성질은 되돌아가는 비용이 단계마다 불어난다는 데 있습니다. 요구사항 단계에서 한 줄을 고치는 일은 문서를 고치면 끝입니다. 같은 한 줄을 시험 단계에서 고치려면 설계와 코드와 시험 항목을 함께 고쳐야 하고, 이미 만든 다른 부분이 그 줄에 기대고 있으면 그것까지 손봐야 합니다. 그래서 앞 단계에 시간을 많이 씁니다. 두 달을 요구사항에 쓰는 것이 낭비가 아니라 이 구조에서는 가장 싼 선택입니다.

맞는 자리가 분명히 있습니다.

1. 요구사항이 밖에서 정해지고 바뀌지 않는 일입니다. 정해진 양식의 규제 보고서를 만드는 일이 그렇습니다. 만들면서 더 나은 양식을 발견해도 바꿀 수 없으니, 반복해서 확인할 이유가 없습니다.
2. 계약이 산출물 단위로 묶인 일입니다. 검수 기준이 문서이고 대금이 단계별로 지급되는 구조에서는 단계를 나누지 않으면 정산이 안 됩니다.
3. 되돌리기 비용이 극단적으로 큰 일입니다. 한 번 나가면 회수할 수 없는 장비에 넣는 소프트웨어가 여기 해당합니다.

한계도 같은 자리에서 나옵니다.

1. 만들면서 알아 가야 하는 일에는 맞지 않습니다. 사용자가 무엇을 쓸지 모르는 새 제품이 그렇습니다.
2. 동작하는 결과물이 맨 마지막에 나옵니다. 그때까지는 방향이 틀렸는지 확인할 방법이 없고, 확인했을 때는 고치는 비용이 가장 큰 시점입니다. 같은 대상을 여러 번 돌며 완성도를 높이는 반복적 개발이 이 자리를 노려 나왔습니다.
3. 문서와 실제가 갈라집니다. 구현 중에 바뀐 판단이 문서에 반영되지 않으면 4번 단계의 대조 기준이 낡은 문서가 됩니다.
4. 실무에서는 대개 섞어 씁니다. 계약과 단계 구분은 워터폴로 두고 내부 진행은 짧게 반복하는 방식이 흔합니다. 쓸 수 있는 조각을 하나씩 덧붙이는 점진적 개발로 안을 채우고, 밖으로는 단계별 산출물을 내는 식입니다.

"이건 요구사항이 법으로 정해져 있어서 워터폴로 가는 게 맞아요."

방식을 조건으로 고르는 말입니다.

"계약은 단계별인데 내부는 2주 주기로 돌립니다."

밖의 절차와 안의 절차를 분리하는 경우입니다.

"지금 요구사항 고치면 문서만 바뀌는데, 시험 들어가서 고치면 두 달입니다."

되돌아가는 비용이 단계마다 다르다는 지적입니다.

페이지덱에서 이 방식은 공공기관과 대기업 납품 건에만 씁니다. 규원이 계약 구조를 보고 방식을 정하고, 지현이 요구사항 문서를 담당자와 함께 씁니다. 40쪽을 두 달에 걸쳐 쓰는 동안 지현이 하는 일의 절반은 문서를 쓰는 것이 아니라 종이 화면을 그려 담당자에게 보여 주는 것입니다. 문서만으로는 담당자도 자기 업무 흐름을 정확히 적을 수 없다는 것을 첫 건에서 배웠기 때문입니다.

워터폴은 낡은 것이고 애자일이 옳다고 보는 경우가 가장 많습니다. 시간 순서로 뒤에 나온 방식이 더 낫다는 인상이 자연스럽게 붙습니다. 하지만 두 방식이 다루는 조건이 다릅니다. 만드는 대상이 바뀌지 않고 되돌아갈 이유가 없는 일에서는 순서대로 한 번에 끝내는 쪽이 낭비가 적습니다. 반복 주기를 돌리는 데도 비용이 들기 때문입니다. 판단 기준은 새것과 옛것이 아니라 하나입니다. 만들어 보지 않고도 무엇을 만들지 알 수 있는 일인지입니다.

문서를 많이 쓰면 워터폴이라고 여기는 것도 흔합니다. 문서를 줄이라는 말이 애자일 쪽에서 자주 인용되기 때문입니다. 그런데 애자일 선언의 문장은 문서를 쓰지 말라는 것이 아니라 문서와 작동하는 소프트웨어가 부딪칠 때 뒤쪽을 택하라는 것입니다. 두 방식을 실제로 가르는 것은 문서의 양이 아니라 단계를 되돌아갈 수 있는지입니다. 요구사항 문서를 40쪽 쓰고도 2주마다 그 문서를 고치며 가는 팀은 워터폴이 아니고, 문서 한 장 없이 순서대로 한 번에 끝내고 되돌아가지 않는 팀은 워터폴입니다.