DRY 원칙

무언가를 만들 때 복사는 늘 가장 빠른 길입니다. 이미 돌아가는 코드가 옆에 있는데 처음부터 다시 쓸 이유가 없고, 붙여 넣고 숫자 하나만 바꾸면 그날의 일은 끝납니다. 그래서 복사는 잘못된 선택처럼 보이지 않습니다. 비용이 그 자리에서 청구되지 않기 때문입니다.

값은 몇 달 뒤 고칠 때 한꺼번에 청구됩니다. 페이지덱에서 실제로 그랬습니다. 무료 플랜이 문서 20개까지 만들 수 있다는 규칙이 코드 안 네 곳에 흩어져 있었습니다. 문서를 새로 만들 때 막는 자리, 화면에 남은 개수를 보여 주는 자리, 안내 문구를 만드는 자리, 그리고 한 달에 한 번 사용량을 집계하는 자리였습니다.

한도를 30개로 올리기로 했을 때 태오가 세 곳을 찾아 고쳤습니다. 네 번째는 집계 쪽에 있어서 눈에 띄지 않았습니다. 그 결과 사용자는 문서 스물다섯 개를 만들 수 있게 됐는데 화면에는 여전히 "20개 중 25개 사용" 이라는 문구가 떴고, 월말 집계는 20개를 넘긴 계정을 전부 초과 사용으로 잡았습니다. 고치는 데 든 시간보다 어긋난 상태를 찾아내고 되돌리는 데 든 시간이 훨씬 길었습니다.

DRY 원칙은 이런 자리를 만들지 말자는 약속입니다. 처음 쓸 때 조금 더 들이더라도 나중에 고칠 곳이 한 군데로 남게 해 두자는 것이고, 이름도 "같은 말을 반복하지 말라" 는 문장의 머리글자에서 왔습니다.

핵심은 겹치는 코드가 아니라 겹치는 지식입니다. 같은 사실이 시스템 안에 두 번 적혀 있으면 그것이 중복이고, 생김새가 비슷한 코드가 두 곳에 있다는 것만으로는 중복이 아닙니다.

둘을 가르는 질문은 하나뿐입니다. 이 두 곳이 앞으로 같은 이유로 바뀌는가. 문서 한도 20이 네 곳에 있던 경우는 요금 정책이 바뀌면 네 곳이 한꺼번에 바뀌어야 하니 같은 지식입니다. 반대로 두 화면에서 우연히 같은 세 줄을 쓰고 있지만 한쪽은 결제 규칙 때문에, 다른 쪽은 알림 규칙 때문에 바뀔 예정이라면 둘은 남남입니다.

한 곳으로 모으는 방법은 대상에 따라 다릅니다.

1. 값은 이름을 붙여 한 군데에 둡니다. 20이라는 숫자를 코드 곳곳에 쓰지 않고 이름 있는 상수 하나로 두고 모두가 그것을 가져다 씁니다.
2. 계산은 함수로 묶습니다. 부가세를 붙이는 계산이 결제와 정산과 영수증에 각각 적혀 있으면, 세율이 바뀌는 날 세 곳을 찾아야 합니다.
3. 화면 조각은 부품으로 만듭니다. 같은 모양의 알림 상자를 여섯 화면에 각각 그려 두면 색 하나 바꾸는 일이 여섯 번 반복됩니다.
4. 코드 밖도 같습니다. 비밀번호 규칙이 코드와 도움말 문서에 따로 적혀 있으면 그것도 중복이고, 규칙이 바뀌는 날 한쪽만 바뀌어 사용자가 문서대로 했는데 거부당합니다.

모아 두는 작업 자체는 리팩터링에 해당합니다. 겉으로 보이는 동작은 그대로 두고 구조만 바꾸는 작업이라, 한도 숫자를 한 곳으로 모은 뒤에도 사용자 화면은 하나도 달라지지 않아야 합니다.

가장 자주 불려 나오는 자리는 코드 리뷰입니다. "이 계산 저쪽에도 있지 않나요" 라는 지적이 이 원칙의 이름을 달고 나옵니다. 같은 내용이 여러 파일에 복사돼 있는 상태는 코드 스멜, 곧 당장 고장은 아니지만 구조가 나빠졌다는 신호의 대표적인 예이기도 합니다.

코드 밖에서도 같은 원칙이 쓰입니다. 색과 간격 값을 디자인 토큰으로 한 벌 정해 두고 화면마다 그것을 가져다 쓰는 방식이 그렇습니다. 브랜드 색이 바뀔 때 고칠 곳이 한 군데로 남습니다. API 문서를 손으로 쓰지 않고 코드에서 자동으로 뽑아내는 것도, 서버 주소 같은 값을 소스마다 적지 않고 환경 설정 한 곳에 두는 것도 같은 생각입니다.

지키지 못한 자리는 기술 부채로 쌓입니다. 미뤄 둔 정리가 나중에 더 큰 비용으로 돌아온다는 뜻인데, 중복은 그중에서도 이자가 눈에 잘 띄는 종류입니다. 같은 규칙이 네 곳에 있으면 그 규칙과 관련된 모든 수정이 네 배로 무거워지고, 한 곳을 빠뜨릴 확률은 수정할 때마다 새로 생깁니다.

"이 계산 결제랑 정산에도 똑같이 들어가 있어요. 하나로 뽑죠."

같은 지식이 여러 곳에 흩어져 있으니 한곳으로 모으자는 제안입니다.

"DRY 맞추겠다고 억지로 묶지 마세요. 이건 곧 갈라질 것들이에요."

지금 닮아 보일 뿐 바뀌는 이유가 다르니 합치면 안 된다는 반대입니다.

"문구가 코드랑 도움말 문서에 따로 있어서 또 어긋났어요."

중복이 코드 안에만 있는 문제가 아니라는 지적입니다.

페이지덱에서는 문서 한도 사건 이후로 규칙 하나가 생겼습니다. 요금제에 걸린 숫자는 한 파일에만 두고, 화면이든 집계든 안내 문구든 모두 그 파일을 읽어 가게 했습니다. 태오가 그 파일을 만들면서 값마다 "무엇을 제한하는 숫자인지" 를 한 줄씩 적어 뒀습니다.

효과는 다음 요금제 개편 때 드러났습니다. 지현이 세 플랜의 한도를 한꺼번에 조정했는데, 고칠 파일이 하나였고 화면과 집계가 저절로 따라왔습니다. 개편 전에 예상했던 이틀치 작업이 오전 안에 끝났습니다.

겹쳐 보이는 코드는 무조건 합쳐야 한다고 읽는 경우가 가장 많습니다. 원칙의 이름이 반복하지 말라는 문장이라 그렇게 들립니다. 하지만 합치는 순간 두 곳은 한 몸이 되고, 나중에 한쪽만 달라져야 할 때 그 몸을 다시 갈라야 합니다. 대개는 가르는 대신 조건을 하나 붙이는 쪽을 택하게 되고, 그런 조건이 다섯 개쯤 붙은 함수는 복사본 두 개보다 읽기 어렵습니다. 세 번째로 같은 것을 쓰게 될 때까지 기다렸다가 합치라는 경험칙이 여기서 나왔습니다.

이 원칙이 코드에만 해당한다고 아는 것도 흔합니다. 이름이 개발 현장에서 나왔으니 자연스러운 이해입니다. 실제로 가장 비싸게 치르는 중복은 코드와 코드 밖 사이에서 생깁니다. 환불 가능 기간이 코드에는 7일로, 약관에는 14일로 적혀 있는 상태가 그렇습니다. 코드 안의 중복은 테스트가 잡아 줄 여지라도 있지만, 코드와 문서 사이의 어긋남은 아무 도구도 잡아 주지 않고 고객이 먼저 발견합니다.