익스트림 프로그래밍

소프트웨어를 만드는 일이 건물을 짓는 일과 같다고 보던 시절이 있었습니다. 설계를 먼저 끝내고, 설계대로 짓고, 다 지은 다음 검사합니다. 이 순서 밑에는 전제가 하나 깔려 있었습니다. 늦게 바꿀수록 비싸진다는 것입니다. 기초를 다 부은 뒤에 기둥 자리를 옮기려면 처음부터 다시 해야 하니, 바꾸지 못하게 막아 두는 쪽이 합리적인 대응이었습니다.

그래서 절차는 변경을 막는 방향으로 자랐습니다. 요구사항 문서에 서명을 받고, 바꾸려면 변경 요청서를 쓰고, 승인 회의를 거치게 했습니다. 이 장치는 문서상으로는 잘 작동했지만 실제 대화는 늘 같은 자리에서 막혔습니다. 개발 여섯 달 차에 고객이 화면 하나를 다르게 써 오면 개발팀은 "그건 3월에 확정하신 내용인데요" 하고 답하고, 고객은 "그때는 이렇게 될 줄 몰랐죠" 하고 답합니다. 양쪽 다 틀린 말이 아니고, 그 대화가 끝나도 화면은 여전히 잘못돼 있습니다.

합치는 날도 같은 문제를 다른 얼굴로 보여 줬습니다. 각자 두 달씩 따로 작업하다가 하나로 합치는 주가 오면, 같은 파일을 서로 다르게 고쳐 둔 자리가 수십 군데씩 나왔습니다. 고치다 보면 지난달에 멀쩡하던 기능이 조용히 망가지는데, 확인이 사람 손으로 하는 검사뿐이라 어디서 깨졌는지를 찾는 데만 사흘이 걸렸습니다. 이런 일을 몇 번 겪은 팀은 자연스럽게 배포 횟수를 줄입니다. 위험하니까 덜 하는 것이고, 덜 하니까 한 번에 나가는 양이 커져서 더 위험해집니다. 두 달치를 모아 한 번에 내보내는 팀은 문제가 생겼을 때 원인 후보가 200건이지만, 하루치를 내보내는 팀은 후보가 세 건입니다. 같은 실수를 해도 찾는 데 드는 시간이 이만큼 갈립니다.

익스트림 프로그래밍은 이 고리를 반대쪽에서 끊습니다. 변경을 막는 대신 변경 비용 자체를 낮춥니다. 고치는 일이 싸고 안전해지면 고치지 못하게 막을 이유가 사라진다는 생각입니다. 1990년대 후반에 정리된 이 방법론은 그때까지 좋은 습관이라고 여겨지던 것들을 골라, 가끔 하지 말고 항상 하라고 요구합니다. 리뷰가 좋으면 짜는 내내 둘이 보고, 통합이 좋으면 하루에도 몇 번씩 합치고, 테스트가 좋으면 기능보다 먼저 씁니다. 이름에 붙은 극한이라는 말은 근무 강도가 아니라 이 요구의 정도를 가리킵니다. 좋은 습관을 가끔 하는 것과 예외 없이 하는 것은 정도의 차이가 아니라 성질의 차이입니다. 합치는 일을 두 달에 한 번 하면 그날 하루를 통째로 비워야 하지만, 하루에 세 번 하면 한 번에 5분이 걸리고 그래서 미룰 이유가 사라집니다.

상위 분야인 일하는 방식이 일곱 갈래로 나뉠 때 이 방법론이 프레임워크 갈래에 놓이는 이유도 여기 있습니다. 같은 갈래의 스크럼은 2주 같은 고정 주기와 회의·역할의 이름을 정하고, 칸반은 보드 위 흐름과 동시에 벌여 둘 수 있는 일의 개수를 정합니다. 둘 다 코드를 어떻게 쓰는지는 말하지 않습니다. 익스트림 프로그래밍은 정확히 그 빈자리를 채웁니다. 회의를 몇 번 여는지가 아니라 손이 코드를 만지는 방식을 규정하기 때문에, 스크럼으로 주기를 끊으면서 그 안의 개발 습관은 이쪽에서 가져오는 조합이 흔합니다. 뿌리는 애자일로 같습니다.

익스트림 프로그래밍 아래 묶인 용어는 실천법 한 갈래입니다. 실천법은 방법론이 팀에게 매일 시키는 구체적인 행동을 가리킵니다. 이 방법론이 규정하는 실천법은 원래 열두어 개이고, 그중 기능보다 테스트를 먼저 쓰는 테스트 주도 개발, 각자 작업을 하루에도 여러 번 합쳐 자동으로 검사하는 지속적 통합, 동작을 그대로 둔 채 구조만 손보는 리팩터링은 지금 엔지니어링 분야에서 따로 다룹니다. 여기 묶인 다섯은 사람과 코드의 관계를 정하는 쪽입니다. 앞의 셋은 누구와 함께 짜는지를, 뒤의 둘은 무엇을 어디까지 어떤 속도로 만드는지를 정합니다.

1. 페어 프로그래밍 — 두 사람이 한 화면을 보며 함께 코드를 씁니다. 한 사람이 타자를 치고 다른 사람이 방향을 보다가 수시로 자리를 바꿉니다. 리뷰를 나중에 받는 대신 짜는 동안 받는 셈이라, 합치기 전에 잡히는 문제가 줄어듭니다.
2. 몹 프로그래밍 — 팀 전체가 한 화면 앞에 모여 하나의 작업을 함께 진행합니다. 페어를 사람 수만큼 늘린 모양입니다. 매일 종일 하는 방식은 아니고, 아무도 구조를 모르는 새 영역을 열거나 결제처럼 한 번 틀리면 되돌리기 어려운 부분을 만질 때 하루씩 씁니다.
3. 코드 공동 소유 — 누구든 어느 코드든 고칠 수 있게 합니다. 결제 코드는 태오만 만진다는 식의 경계를 두지 않습니다. 담당자가 휴가를 가면 그 영역의 일이 전부 멈추는 상태를 없애려는 규칙이고, 대신 아무나 고쳐도 망가지지 않는다는 근거가 필요해서 자동 테스트와 짝으로 붙어 다닙니다.
4. 단순 설계 — 지금 필요한 만큼만 설계합니다. 나중에 결제 수단이 다섯 개로 늘 것 같아 미리 추상 구조를 깔아 두는 대신, 두 번째 수단이 실제로 들어올 때 그때 구조를 만듭니다. 오지 않은 요구에 맞춰 만든 구조는 대개 틀린 데다, 틀린 채로 남아 다음 사람이 읽어야 할 코드만 늘립니다.
5. 지속 가능한 속도 — 몇 년을 유지할 수 있는 강도로만 일합니다. 주 40시간 언저리를 기준으로 삼고, 급한 주에 한 번 늘리더라도 다음 주에 되돌립니다. 이 방법론이 나머지 실천법에서 요구하는 집중이 야근 상태에서는 나오지 않기 때문에 넣은 규칙입니다.

다섯은 골라 쓰는 메뉴가 아니라 서로를 붙듭니다. 공동 소유는 아무나 고쳐도 안전하다는 근거가 있어야 성립하고, 그 근거를 만드는 것이 테스트와 자주 합치는 습관입니다. 단순 설계도 마찬가지입니다. 나중에 고치는 일이 싸다는 확신이 있어야 미리 만들어 두려는 유혹을 견딜 수 있습니다. 페어와 몹은 한 사람만 아는 영역이 생기지 않게 막아 공동 소유를 떠받칩니다. 그래서 절반만 들여오면 효과가 절반 나는 것이 아니라 대개 아무것도 나지 않습니다. 도입 순서를 정할 때 이 맞물림을 먼저 그려 보는 팀과 눈에 띄는 것부터 집는 팀의 결과가 갈리는 지점이기도 합니다. 앞의 팀은 테스트와 합치는 습관을 먼저 깔고 그 위에 나머지를 얹지만, 뒤의 팀은 가장 사람 손이 많이 드는 것을 가장 먼저 켜고 가장 빨리 지칩니다.

"이 부분은 태오랑 페어로 갈게요. 결제 쪽은 혼자 짜면 리뷰에서 결국 다시 뜯게 되더라고요."

리뷰를 나중에 받느니 짜는 동안 같이 보겠다는 뜻입니다.

"우리가 지금 쓰는 건 XP 중에 두 개뿐이에요. 테스트 없이 공동 소유부터 켜면 겁나서 아무도 남의 코드를 안 고칩니다."

실천법을 낱개로 떼어 오면 서로를 떠받치던 근거가 빠져 제자리에서 돈다는 지적입니다.

"이번 주는 야근으로 메우지 맙시다. 다음 주 속도까지 같이 깎여요."

지금 무리해서 번 시간이 다음 주기에 더 큰 손해로 돌아온다는 뜻입니다.

페이지덱의 결제 모듈이 이 방법론을 처음 들여온 자리였습니다. 요금제를 바꾼 고객의 금액을 날짜로 쪼개 계산하는 부분에서 잘못된 청구가 두 달 연속 나왔고, 두 번 다 배포 다음 날 고객이 먼저 알려 줬습니다. 태오가 제안한 것은 검수 단계를 하나 더 붙이는 안이 아니라 그 모듈에 한해 짜는 방식을 바꿔 보자는 안이었습니다. 결제 코드는 항상 둘이 붙어서 쓰고, 금액을 계산하는 함수는 테스트를 먼저 쓴 다음 만들고, 작업 중인 것도 하루가 끝나기 전에 합치기로 했습니다.

첫 3주는 느렸습니다. 같은 분량을 두 사람이 붙어서 짜니 진행이 눈에 띄게 줄었고, 지현은 스프린트 두 번 동안 계획한 항목이 밀리는 것을 지켜봐야 했습니다. 넉 달째에 바뀐 것은 배포 뒤의 시간이었습니다. 그 전에는 결제 쪽 배포가 있는 주의 이틀을 문의 대응에 쓰고 있었는데, 그 이틀이 사라졌습니다. 잘못된 청구로 접수된 문의는 그해 남은 기간 동안 한 건이었습니다.

지금 페이지덱에서 이 방식이 적용되는 범위는 결제와 권한 처리 두 곳뿐입니다. 화면 문구를 고치거나 실험용으로 하루 만에 붙였다 떼는 기능에는 쓰지 않습니다. 태오가 기준으로 삼는 질문은 하나입니다. 여기가 틀렸을 때 고객의 돈이나 데이터가 상하느냐는 것입니다. 답이 그렇다면 둘이 붙어 짜는 값이 아깝지 않고, 아니라면 그 값은 다른 데 쓰는 편이 낫습니다.

이름 탓에 근무 강도를 극한까지 끌어올리는 방식으로 읽는 경우가 가장 많습니다. 극한이라는 말이 앞에 붙어 있으니 밤새워 짜는 팀을 떠올리게 되고, 짧은 주기로 자주 내보낸다는 설명이 거기에 겹치면 더 그럴듯해집니다. 하지만 이 방법론이 극한으로 밀어붙이는 대상은 사람이 아니라 습관입니다. 리뷰를 항상 하고 통합을 항상 하라는 뜻이지 항상 일하라는 뜻이 아닙니다. 오히려 다섯 실천법 중 하나가 지속 가능한 속도이고, 주 40시간을 넘기는 상태가 이어지면 그 자체를 고쳐야 할 문제로 봅니다. 이 오해를 그대로 두면 도입 논의가 시작도 전에 막힙니다. 개발자는 야근을 제도로 만들자는 제안으로 듣고, 관리자는 거꾸로 밀어붙일 명분으로 씁니다. 두 번째 쪽이 실제로 벌어진 팀에서는 반년 안에 사람이 나가고, 남은 사람들에게 이 이름은 다시 꺼내기 어려운 말이 됩니다.

실천법을 메뉴처럼 골라 쓸 수 있다고 보는 것도 자주 어긋납니다. 열두 개 중 우리 팀에 맞는 서너 개만 가져오자는 판단은 합리적으로 들립니다. 실제로 가장 자주 먼저 집는 것이 페어 프로그래밍인데, 눈에 보이고 도구가 필요 없고 내일부터 시작할 수 있기 때문입니다. 그런데 이 실천법들은 서로의 안전장치 노릇을 하고 있어서, 떼어 오면 지탱하던 것이 같이 빠집니다. 자동 테스트도 없고 하루에 한 번 합치지도 않는 팀이 페어만 켜면 두 사람이 붙어 있는 값은 그대로 치르면서 얻는 것은 리뷰가 조금 빨라지는 정도에 그칩니다. 여전히 합치는 날 충돌이 나고, 여전히 고친 곳이 다른 데를 망가뜨렸는지 알 수 없습니다. 그대로 두면 결론은 대개 같은 모양으로 납니다. 석 달쯤 뒤 회고에서 우리 팀에는 안 맞는다는 말이 나오고, 값을 두 배로 치른 기억만 남아 나머지 실천법까지 같이 닫힙니다. 무엇부터 시작할지를 고를 때 순서가 뒤집혀 있는 셈인데, 먼저 들여야 할 쪽은 자동으로 도는 테스트와 자주 합치는 습관입니다. 이 둘은 사람의 시간을 매일 더 쓰게 하지 않으면서도 나머지 실천법이 설 바닥을 만들어 줍니다. 나머지는 그 위에서만 값을 합니다. 한 번에 다 켤 수 없다면 두 분기로 나눠 바닥부터 까는 편이, 눈에 보이는 것을 먼저 켜고 석 달 뒤에 접는 것보다 남는 것이 많습니다.