오버엔지니어링을 막는 되돌릴 수 있는 설계

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

현재 요구사항이 10이라면 10은 만들어야 한다. 설계는 어디까지 앞을 봐야 할까? 내 거친 답은 12.5다. 뻔한 막다른 길을 피할 만큼은 보되 앞으로 여러 번 꺾일 길을 이미 안다고 생각할 만큼 구조를 만들지는 않는다.

숫자는 산정 공식이 아니라 비유다. 실제 기준은 확장하기 쉽고 축소하기도 쉬운 상태를 유지하는가이다.

미래 경로는 직선으로 이어지지 않는다

오버엔지니어링은 다음 요구사항이 현재 요구사항의 더 큰 버전이라고 가정할 때 자주 생긴다. A, B, C를 보고 Z까지 미리 만든다. 하지만 비즈니스는 C 다음에 예상하지 못한 다른 길을 고를 수 있다. 공들여 준비한 Z는 쓰이지 않는 구조나 부채가 된다.

그래서 요구가 10인데 20을 구현하는 일은 위험하다. 지금의 시간을 쓰고, 아직 사용자에게 아무 일도 하지 않는 개념을 다음 개발자가 이해하게 만든다. 그 구조가 모델을 제약하면 실제 다음 방향으로 움직이기까지 더 어려워진다.

멀리 갔더라도 되돌리기 쉽다면 위험은 줄어든다. 설계가 15까지 갔지만 적은 비용으로 12 수준으로 돌아올 수 있다면 실험으로 받아들일 수 있다. 얼마나 많이 만들었는지만이 아니라 추측이 틀렸을 때 제거 비용이 얼마인지가 중요하다.

현재 요구사항에 주문과 주문 항목만 필요하다고 하자. 미래를 추측한 설계는 패키지 ID와 묶음 개념, 여러 배송 방식을 위한 컬럼을 미리 넣을 수 있다. 준비된 모델처럼 보이지만 지금의 행위는 ‘패키지’가 실제로 무엇인지 증명하지 않는다.

먼저 주문과 주문 항목을 만든다. 패키지 주문이 현실이 되면 규칙을 알게 된 시점에 그 위나 옆에 개념을 추가할 수 있다. 잘못된 개념을 처음부터 들고 가는 것보다 나중에 추가하는 편이 더 싼 경우가 많다.

불확실한 커스텀 주문 기능도 비슷하다. 데이터를 분리해 두면 기능이 사라질 때 쉽게 삭제할 수 있다. 그러나 테이블을 먼저 나누는 일 자체가 오버엔지니어링일 수도 있다. 제거 가능성이 얼마나 높고 지금 분리하는 비용이 얼마인지에 따라 답이 달라진다.

이 긴장은 구호로 해결되지 않는다. 현재 요구사항을 이해하고, 가장 싼 되돌릴 수 있는 경계를 찾은 뒤 거기서 멈춰야 한다.

미래를 위한 추상화를 추가하기 전에 묻는다.

경험이 쌓이면 과거의 과잉이 눈에 보인다. 아무도 쓰지 않는 필드, 동료를 헷갈리게 한 추상화, 사라진 기능을 위해 만든 테이블이 판단의 재료가 된다. 설계를 하지 말자는 교훈이 아니다. 불확실성을 드러내고 추측을 비싼 제약으로 굳히지 말자는 것이다.

오래 가는 설계는 현재 요구사항을 담백하게 표현하면서 저렴하게 진화할 자리를 남긴다. 10을 만들고 10 바로 너머를 살피며 방향을 바꿀 능력을 지키자. 비즈니스가 방문하지 않을 미래에 먼저 도착하는 것보다 유용하다.