점진적 개발

만들기로 한 것을 목록대로 전부 끝낸 다음에야 내보내던 시절이 있었습니다. 문서 편집기라면 편집과 공유와 댓글과 검색과 권한 설정을 모두 갖춘 뒤에 한 번에 공개하는 식입니다. 열 달이 걸리는 일이면 열 달 동안 쓰는 사람이 없고, 만든 것이 맞는지 알려 주는 신호도 없습니다. 단계를 순서대로 끝내고 넘어가는 워터폴에서는 이 공백이 당연하게 여겨졌습니다.

대가는 마지막 달에 한꺼번에 치릅니다. 공개하고 나서야 댓글은 아무도 안 쓰고 정작 필요했던 것은 문서를 폴더로 묶는 기능이었다는 사실이 드러나고, 열 달치 일 가운데 석 달어치가 헛일이었다는 계산이 그제야 나옵니다.

당시 회의는 늘 같은 자리에서 멈췄습니다. "지금 상태로 한번 내보내 보면 안 될까요" 하고 물으면 "아직 절반밖에 안 됐는데요" 하는 답이 돌아왔습니다. 문제는 그 절반이라는 말이었습니다. 다섯 기능 중 두 개가 완성된 상태와 다섯 기능이 전부 반쯤 되다 만 상태는 전혀 다른데 둘을 같은 말로 불렀습니다. 앞쪽이면 두 개는 당장 내보낼 수 있고, 뒤쪽이면 내보낼 것이 없습니다.

점진적 개발은 앞쪽 상태를 의도적으로 만드는 방식입니다. 쪼갠 조각 하나를 끝까지 완성해 내보내고 그 위에 다음 조각을 붙입니다. 진척을 몇 퍼센트로 말하는 대신 이미 쓰이고 있는 기능의 개수로 말하게 된 것이 이 방식이 바꾼 지점입니다.

만들 것을 사용자가 처음부터 끝까지 해낼 수 있는 일 하나를 기준으로 자릅니다. 화면과 서버와 데이터베이스로 층을 나눠 각 층을 통째로 먼저 만드는 것과 반대 방향입니다. 층으로 나누면 세 층이 다 끝나는 날까지 아무것도 동작하지 않지만, 일을 기준으로 자르면 그 일에 필요한 화면과 서버와 저장이 얇게 한 줄로 딸려 나와 첫 조각부터 돌아갑니다.

순서는 네 단계입니다.

1. 사용자가 해내고 싶은 일 단위로 쪼갭니다. 검색이라면 제목으로 찾기, 본문으로 찾기, 작성자로 걸러 보기가 각각 한 조각입니다. 요구를 한 문장으로 적는 유저 스토리가 이 쪼개기의 기본 형식으로 쓰입니다.
2. 조각의 순서를 정합니다. 기준은 크기가 아니라 없을 때 가장 아쉬운 것입니다. 문서가 3천 건 쌓인 팀에서 제목 찾기가 없으면 매일 곤란하지만, 작성자로 걸러 보기는 한 달에 한 번 아쉽습니다.
3. 고른 조각 하나만 끝까지 완성합니다. 완성은 완료 정의를 채운 상태, 곧 코드 리뷰를 통과하고 테스트가 돌고 실제 사용자가 쓸 수 있는 곳에 올라간 상태를 말합니다.
4. 내보낸 뒤 반응을 보고 다음 조각을 고릅니다. 정해 둔 순서를 그대로 따를 수도 있고, 제목 검색만 붙였는데 문의가 끊겼다면 남은 두 조각의 순위를 내릴 수도 있습니다.

조각의 크기는 한 스프린트 안에 완성할 수 있는 정도로 잡습니다. 2주 주기라면 2주 안에 내보낼 크기입니다. 더 커지면 주기가 끝나도 내보낼 것이 없고, 너무 잘면 내보내는 검수와 공지 비용이 만드는 비용보다 커집니다.

가장 먼저 만나는 자리는 MVP입니다. 가설을 검증할 수 있는 최소한의 제품이라는 뜻인데, 그 최소한을 무엇으로 잡느냐가 곧 첫 조각을 고르는 일입니다. 제품 전체를 얇게 흉내 내는 대신 한 가지를 제대로 동작하게 만드는 쪽이 여기서 나옵니다.

릴리스 계획에도 그대로 들어갑니다. 한 해에 한 번 크게 내보내는 대신 2주마다 하나씩 내보내면 잘못 만든 것을 알아차리는 시간이 열 달에서 2주로 줄고, 한 번에 바뀌는 양이 적어 원인을 찾기도 쉽습니다.

받쳐 주는 장치도 함께 따라옵니다. 피처 플래그는 코드를 올려 둔 채 기능만 켜고 끄는 스위치라서, 아직 다 안 된 조각을 사용자에게만 감춰 둘 수 있게 해 줍니다. 팀 구성도 걸립니다. 조각 하나를 끝까지 완성하려면 기획과 디자인과 개발이 한 팀에 있어야 해서, 교차 기능 팀이 아니면 2주 안에 완성이 성립하지 않습니다.

"이번 주기에는 제목 검색만 내보내고 필터는 다음으로 미루죠."

기능을 절반씩 만드는 대신 한 조각을 완성해 내보내자는 제안입니다.

"이거 세로로 쪼갤 수 있나요? 지금은 화면만 나오고 동작이 없어서요."

사용자가 끝까지 해낼 수 있는 단위로 다시 나눠 달라는 요청입니다.

"1번 조각만으로도 쓸 만한지부터 보고 2번을 만들지 정합시다."

다음 조각을 만들지 말지를 반응을 보고 정하겠다는 뜻입니다.

페이지덱에서 문서 검색을 새로 만들 때 이 말이 오갔습니다. 처음 기획은 제목과 본문과 첨부 파일을 한꺼번에 뒤지고 작성자와 기간으로 걸러 내는 것까지 한 묶음이었고 예상 기간은 7주였습니다. 지현이 세 조각으로 나눠 제목 검색을 첫 주기에 내보내자고 했고, 태오가 첨부 파일은 저장 구조를 손봐야 한다며 맨 뒤로 보냈습니다.

제목 검색만 나간 뒤 2주 동안 검색을 쓴 사람이 전체의 절반을 넘었습니다. 팀은 본문 검색을 예정대로 만들었고, 세 번째 조각인 첨부 파일 검색은 요청이 거의 없어 그해에 만들지 않았습니다. 7주로 잡았던 일이 4주에 끝났는데, 빨리 만들어서가 아니라 안 만들어도 되는 조각을 알아냈기 때문입니다.

덜 만든 것을 내보내는 방식이라는 오해가 가장 흔합니다. 조각이라는 말에 일부만 내보낸다는 설명이 붙으니 품질을 깎아 속도를 얻는 것처럼 들립니다. 실제로는 반대입니다. 내보내는 조각 하나하나는 완료 정의를 채운 완성품이고, 줄이는 것은 완성도가 아니라 범위입니다. 이 구분을 놓치면 테스트를 건너뛰고 급히 올린 기능에 점진적 개발이라는 이름이 붙고, 몇 주 뒤에는 앞서 내보낸 조각을 고치느라 새 조각을 만들지 못하게 됩니다.

설계를 미리 하지 않아도 된다는 오해도 따라옵니다. 하나씩 붙여 갈 테니 전체 그림은 나중에 그려도 된다고 생각하기 쉽습니다. 그러나 붙여 나갈 자리를 정하는 일은 첫 조각을 만들기 전에 끝나 있어야 합니다. 제목 검색을 만들 때 나중에 첨부 파일까지 뒤질 것을 알면 저장 구조를 그에 맞게 잡아 두지만, 모르고 만들면 두 번째 조각에서 첫 조각을 통째로 다시 만듭니다. 뼈대는 미리 세우고 살은 하나씩 붙이는 쪽이 실제 모습에 가깝습니다.