YAGNI

미리 만들어 두면 나중에 편하다는 생각은 자연스럽습니다. 지금 한 가지만 필요하더라도 여러 경우를 받아들일 수 있게 설계해 두면, 다음에 요구가 들어왔을 때 손을 덜 대게 됩니다. 확장을 염두에 둔 설계라는 말이 칭찬으로 쓰이는 이유입니다.

페이지덱에서 그 판단을 해 본 적이 있습니다. 알림을 메일로 보내는 기능을 만들면서, 나중에 다른 채널도 붙일 것이라고 보고 채널을 갈아 끼울 수 있는 구조를 먼저 만들었습니다. 3주가 더 걸렸습니다.

1년 반 동안 붙은 채널은 없었습니다. 그리고 실제로 다른 채널을 붙이기로 한 날, 그 구조가 맞지 않았습니다. 미리 상상한 채널은 메일처럼 한 번에 보내는 것이었는데, 실제로 필요해진 채널은 사람마다 연결을 따로 맺고 실패하면 다시 시도해야 하는 것이었습니다. 3주를 들여 만든 구조를 걷어 내고 다시 짰습니다.

미리 만들어 둔 것의 값은 만드는 시간만이 아니었습니다. 그 1년 반 동안 그 코드를 읽은 모든 사람이 쓰이지 않는 갈래를 함께 읽었고, 잘못된 가정이 구조로 굳어 실제 요구가 왔을 때 오히려 방해가 됐습니다.

판단 기준은 하나입니다. 지금 쓰이는가입니다. 다음 주에 쓰일 예정인 것도 지금은 만들지 않습니다.

미리 만드는 쪽에 붙는 값이 셋이라는 것이 이 원칙의 근거입니다.

1. 만드는 시간. 눈에 가장 잘 보이는 값이고 실제로는 가장 작습니다.
2. 읽고 유지하는 값. 쓰이지 않는 갈래도 코드에 남아 있는 동안은 계속 읽히고, 다른 곳을 고칠 때 함께 검토되고, 검사도 함께 돌아갑니다. 이 값은 지우기 전까지 매달 나갑니다.
3. 틀린 가정이 굳는 값. 셋 중 가장 큽니다. 실제 요구가 상상과 다르게 들어오면 미리 만든 구조가 그 요구를 막습니다. 아무것도 없는 상태에서 만드는 편이 잘못된 구조를 고치며 만드는 편보다 빠릅니다.

무조건 미루는 원칙은 아닙니다. 가르는 잣대는 나중에 바꾸는 비용입니다. 화면 구성이나 함수 하나는 필요해질 때 바꾸면 되니 미룹니다. 반대로 미루지 않는 것이 셋 있습니다. 데이터를 어떤 구조로 저장할지, 외부에 공개한 규격, 그리고 권한과 보안입니다. 데이터가 쌓인 뒤에 구조를 바꾸려면 쌓인 것을 함께 옮겨야 하고, 공개한 규격을 바꾸면 이미 연동한 쪽이 멈춥니다.

이 원칙이 성립하려면 조건이 하나 붙습니다. 나중에 만들기가 쉬워야 합니다. 검사가 깔려 있고 단위가 작게 나뉘어 있으면 필요해진 날에 붙이는 일이 사흘로 끝나지만, 그렇지 않으면 3주가 됩니다. 그래서 이 원칙은 코드를 대충 짜도 된다는 말과 정반대 자리에 있습니다. 지금 만들지 않기 위해 나중에 만들 수 있는 상태를 유지해야 합니다.

경우를 다 만드는 것과 확장 지점을 하나 두는 것도 구분합니다. 앞엣것이 이 원칙이 막는 대상이고, 뒤엣것은 값이 싸서 넣어도 됩니다. 함수 하나를 갈아 끼울 수 있게 두는 일은 한 시간이지만 세 가지 채널을 다 만드는 일은 3주입니다.

가장 자주 나오는 자리는 설계를 논의하는 회의입니다. 나중에 여러 경우를 받아들일 수 있게 만들자는 말이 나오면, 그 여러 경우가 지금 어디에 있는지를 묻습니다. 고객이 요청한 문서가 있는지, 로드맵에 올라 있는지, 짐작인지에 따라 답이 갈립니다.

두 번째는 합치기 전에 동료가 읽는 코드 리뷰입니다. 한 곳에서만 쓰이는 추상화, 값이 하나뿐인 설정, 호출되지 않는 옵션이 눈에 걸립니다. 지금 쓰이지 않는 갈래가 들어왔는지가 확인 항목이 됩니다.

세 번째는 요구사항을 적는 자리입니다. 이번에 하지 않기로 한 것을 적어 두는 범위 밖 칸과 짝을 이룹니다. 문서에서 안 하기로 한 것이 코드에 구조로 들어와 있는 상태가 생각보다 흔합니다.

네 번째는 설정 항목입니다. 나중에 바꿀 수 있게 값을 설정으로 빼 두는 결정이 쌓이면 설정이 스무 개가 되고, 그중 절반은 아무도 바꾼 적이 없는 채로 조합의 수를 늘립니다. 설정 하나는 검사해야 할 경우의 수를 두 배로 만듭니다.

다섯 번째는 만들 것의 범위를 좁히는 자리입니다. 가설을 확인할 최소한의 제품인 MVP를 정의하는 일과 방향이 같고, 앞엣것은 제품 범위에 뒤엣것은 코드 구조에 적용됩니다.

"그건 YAGNI 아닌가요? 지금 채널이 하나뿐인데요."

쓰이지 않는 갈래를 미리 만들지 말자는 지적입니다.

"데이터 구조는 미리 잡읍시다. 이건 나중에 바꾸기 어려워요."

되돌리는 비용이 큰 항목은 예외라는 말입니다.

"설정으로 빼지 말고 값을 박아 두죠. 바꿀 사람이 없어요."

미래의 유연함보다 지금의 단순함을 고르자는 제안입니다.

페이지덱에서는 태오가 설계 문서에 한 줄을 넣습니다. 지금 만들지 않는 것과 그 이유를 적는 줄입니다. 나중에 같은 논의가 다시 열릴 때 그 줄이 있으면 처음부터 다시 이야기하지 않고, 그때의 판단이 여전히 맞는지만 봅니다.

미리 만든 것을 지우는 일도 같은 원칙에 들어갑니다. 반년 동안 쓰이지 않은 갈래가 보이면 기술 부채 목록에 올려 두고 지웁니다. 지우는 쪽이 만드는 쪽보다 판단이 쉽습니다. 쓰인 기록이 없다는 사실이 근거가 되기 때문입니다.

계획하지 말자는 말로 읽는 경우가 가장 많습니다. 미리 만들지 않는다는 문장이 미리 생각하지 않는다는 말로 들리기 때문입니다. 하지만 이 원칙이 다루는 것은 만드는 시점입니다. 앞으로 어떤 요구가 올지 예상하는 일과 그 요구를 지금 코드로 만들어 두는 일은 다릅니다. 예상은 해 두고, 그 예상이 맞았을 때 붙이기 쉬운 구조를 유지하고, 실제 요구가 오기 전까지는 만들지 않습니다. 이 셋을 한꺼번에 하는 것이 이 원칙의 실제 모습입니다.

어떤 경우에도 나중으로 미루는 규칙이라고 보는 것도 흔합니다. 이름이 단정적이라 그렇게 읽힙니다. 그런데 미루는 값이 싼 것과 비싼 것이 있습니다. 데이터를 저장하는 구조를 나중에 바꾸려면 쌓인 데이터를 함께 옮겨야 하고, 그 작업은 사용자가 쓰는 동안 해야 해서 며칠짜리 계획이 됩니다. 이 원칙을 예외 없이 적용한 팀은 반년 뒤에 그 며칠을 쓰게 됩니다.