애자일 선언

1990년대 소프트웨어 개발은 문서에서 시작해 문서로 끝났습니다. 요구사항을 수백 쪽으로 먼저 확정하고, 결재를 받고, 그대로 만들고, 다 만든 뒤에야 고객에게 보여 주는 워터폴 방식이 표준이었습니다.

걸리는 것은 그 사이의 시간이었습니다. 요구사항을 확정한 날과 결과물을 처음 보여 주는 날이 1년 넘게 벌어지는 일이 흔했고, 그동안 경쟁 제품도 고객 사정도 바뀌었습니다. 바뀐 것을 반영하려면 승인받은 문서를 다시 열어 결재를 받아야 했고, 대부분은 그 몇 주를 쓰는 대신 틀린 줄 알면서 그대로 만들었습니다.

그 불편은 회의실에서 같은 대사로 나타났습니다. 고객이 지금 필요한 것을 말하면 개발팀은 "그건 요구사항 문서에 없습니다" 하고 답하고, 고객은 "그때는 맞았지만 지금은 아닙니다" 하고 답합니다. 문서를 지킨 팀은 쓸모없는 것을 제때 만들어 냈고, 문서를 어긴 팀은 약속을 어긴 팀이 됐습니다.

1990년대 후반에 이 방식을 벗어나려는 팀들이 따로 생겨났고, 2001년 2월에 그 사람들이 미국 유타의 한 스키 리조트에 모여 사흘 만에 이 문서를 내놓았습니다.

문서는 네 문장짜리 가치 선언과 열두 개 원칙, 두 덩어리입니다. 가치는 모두 "A 보다 B" 형태입니다.

1. 공정과 도구보다 개인과 상호작용 — 누가 어떤 절차를 따랐는지보다 사람들이 실제로 말을 섞었는지를 봅니다.
2. 포괄적인 문서보다 작동하는 소프트웨어 — 설계서 90쪽보다 지금 눌러 볼 화면 하나가 진척의 증거입니다.
3. 계약 협상보다 고객과의 협력 — 범위를 두고 책임을 다투는 대신 무엇이 지금 필요한지를 함께 정합니다.
4. 계획을 따르기보다 변화에 대응하기 — 계획에서 벗어난 상황을 사고가 아니라 정보로 취급합니다.

네 문장 밑에는 단서가 한 줄 붙어 있습니다. 왼쪽을 더 중시하지만 오른쪽에 적힌 것에도 가치가 있다는 문장입니다. 둘 중 하나를 버리라는 말이 아니라 부딪칠 때 어느 쪽을 택할지 정해 둔 것입니다.

열두 원칙은 네 문장을 행동 수준으로 내린 목록이고, 묶으면 세 갈래입니다.

1. 무엇을 언제 내보내는가 — 짧은 주기로 쓸 수 있는 결과물을 자주 인도하고, 진척은 진도율이 아니라 작동하는 소프트웨어로 잽니다. 같은 대상을 여러 번 돌며 완성도를 높이는 반복적 개발과 쓸 수 있는 조각을 하나씩 덧붙이는 점진적 개발이 여기서 나옵니다.
2. 변화를 어떻게 다루는가 — 후반에 도착한 요구사항 변경도 받아들이고, 단순함을 지키고, 나중에 고치기 쉽게 잘 만들어 둡니다. 급한 일정에 코드를 급조하면 다음 변경을 받아들일 여력이 사라지므로 이 셋은 한 묶음입니다.
3. 팀을 어떻게 짜는가 — 동기가 붙은 사람들에게 맡기고, 필요한 직군을 한자리에 모아 얼굴을 보고 이야기하고, 무리하지 않는 속도를 유지합니다. 자기 조직화 팀과 교차 기능 팀이 여기서 나온 말이고, 일정한 간격으로 팀이 스스로를 돌아보라는 마지막 원칙이 회고의 근거입니다.

작성한 쪽은 회사도 표준화 기구도 아닌 개인 열일곱 명입니다. 각자 자기 방법론을 들고 온 터라 합의할 수 있는 범위가 좁았고, 그래서 문서가 한 쪽으로 끝났습니다. 이 출신이 문서의 성격을 정합니다. 인증 기관도 감사 절차도 개정판도 없고, 2001년 문장이 지금까지 한 글자도 바뀌지 않았습니다.

강제력이 없다는 점은 약점이 아닙니다. 지킬 규칙이 아니라 판단이 갈릴 때 돌아가 볼 기준점이기 때문입니다. 펼치게 되는 자리는 대개 둘입니다.

1. 새로 합류한 사람이 왜 이렇게 일하는지 물을 때. 스크럼 같은 프레임워크는 어떤 회의를 며칠마다 열지까지 정해 주지만 왜 그 순서여야 하는지는 적어 두지 않습니다.
2. 방식을 두고 팀이 다툴 때. 기획서를 어디까지 쓸지 같은 문제는 취향으로 결론이 나지 않습니다. 무엇을 더 중시하기로 했는지 적힌 문장이 있으면 그 자리에서 기준을 꺼냅니다.

"문서를 쓰지 말자는 얘기가 아닙니다. 선언문에도 오른쪽에 있는 것에 가치가 있다고 적혀 있어요."

가치 문장을 앞부분만 잘라 읽은 상대에게 단서 한 줄을 꺼내는 말입니다.

"선언문에 2주짜리 주기를 돌리라는 말은 없어요. 그건 우리가 고른 프레임워크가 정한 겁니다."

지금 다투는 규칙이 원칙에서 온 것인지 도구에서 온 것인지 가르는 말입니다.

"이번 분기 회고에서는 열두 원칙 중에 우리가 제일 못 지키는 걸 하나만 골라 봅시다."

막연한 개선 논의 대신 이미 적힌 목록을 점검표로 쓰자는 제안입니다.

페이지덱에서 이 문서가 나온 자리는 기획서 분량을 두고 태오와 지현이 부딪쳤을 때였습니다. 태오는 화면 시안과 항목 정의만 있으면 시작할 수 있다고 했고, 지현은 예외 처리까지 적힌 문서라야 나중에 되묻는 일이 줄어든다고 했습니다.

정리를 만든 것은 두 번째 가치 문장이었습니다. 질문이 "문서를 몇 쪽 쓸까" 에서 "이번 주기에 눌러 볼 화면을 내려면 문서가 어디까지 필요할까" 로 바뀌었고, 팀은 예외 처리를 화면이 나온 뒤에 정하기로 했습니다. 문서가 답을 준 것이 아니라 무엇을 두고 다투는 중인지를 정해 준 것입니다.

가장 흔한 오해는 이 문서가 문서를 쓰지 말라고 했다는 것입니다. 두 번째 가치 문장이 앞부분만 떼어 돌아다니니 그렇게 읽히기 쉽습니다. 실제로는 둘이 부딪칠 때의 우선순위를 정한 문장이고 바로 아래 줄에 오른쪽에도 가치가 있다고 못 박혀 있습니다. 그대로 두면 인수인계 문서도 기능 명세도 남지 않고, 반년 뒤 담당자가 바뀌면 코드를 읽어 추측하는 시간이 기능을 만드는 시간보다 길어집니다.

두 번째 오해는 이 한 쪽을 읽으면 애자일을 시작할 수 있다는 것입니다. 분량이 짧고 문장이 쉬워 다 이해한 기분이 들기 때문입니다. 하지만 회의를 며칠마다 열라거나 작업을 어떤 단위로 쪼개라는 내용은 문서에 없습니다. 그건 스크럼이나 칸반이 맡는 자리입니다. 반대로 프레임워크만 들여오고 이 문서를 건너뛰면 회의 이름과 보드는 그대로인데 계획을 고칠 권한은 아무도 갖지 못한 무늬만 애자일로 굳습니다.