확장성보다 먼저 오는 건 단순함

확장성보다 먼저 오는 건 단순함

시스템을 설계할 때 “나중에 커지면 어떻게 하지?”라는 질문은 거의 본능처럼 따라온다. 트래픽이 급증하면? 사용자가 수십 배로 늘어나면? 데이터가 폭발적으로 증가하면? 이런 상황을 미리 대비하는 건 분명 중요해 보인다. 그래서 처음부터 분산 구조를 도입하고, 복잡한 추상화를 만들고, 확장을 고려한 아키텍처를 설계하려는 시도가 자주 등장한다.

문제는 이 접근이 생각보다 높은 비용을 요구한다는 점이다. 아직 발생하지도 않은 문제를 해결하기 위해 시스템은 불필요하게 복잡해지고, 그 복잡도는 곧 개발 속도와 유지보수 비용에 직접적인 영향을 준다. 결국 “확장성을 고려했다”는 이유로 현재의 생산성을 희생하는 상황이 만들어진다.

이 지점에서 자주 언급되는 개념이 바로 YAGNI(You Aren’t Gonna Need It)다. 지금 당장 필요하지 않은 기능이나 구조는 만들지 말라는 원칙이다. 미래에 필요할 가능성이 있다는 이유만으로 설계를 확장하면, 실제로는 사용되지 않는 코드와 구조가 쌓이게 된다. 그리고 이런 요소들은 시간이 지날수록 시스템을 이해하기 어렵게 만든다.

비슷한 맥락에서 premature optimization(조기 최적화)도 중요한 경고다. 성능 문제나 확장 문제는 실제로 발생했을 때 해결해도 늦지 않은 경우가 많다. 그런데 이를 미리 해결하려고 하면, 복잡한 캐싱 전략이나 분산 처리 구조가 도입되고, 그 자체가 새로운 문제를 만들어낸다. 결국 최적화를 위한 코드가 오히려 전체 시스템의 발목을 잡게 된다.

실제 현장에서는 “확장성을 고려한 설계”가 오히려 병목이 되는 경우도 적지 않다. 예를 들어 단일 서버로 충분히 처리 가능한 트래픽임에도 불구하고, 처음부터 마이크로서비스 구조를 도입했다면 서비스 간 통신, 배포, 모니터링, 장애 대응까지 모든 과정이 복잡해진다. 이 복잡도는 기능 개발 속도를 떨어뜨리고, 작은 변경에도 큰 비용을 요구하게 만든다.

반대로 단순한 구조로 시작한 시스템은 훨씬 빠르게 진화할 수 있다. 하나의 서비스, 하나의 데이터베이스, 명확한 흐름. 이 상태에서는 문제를 이해하기 쉽고, 수정도 빠르다. 그리고 실제로 확장이 필요한 시점이 오면, 그때 필요한 부분만 선택적으로 개선할 수 있다. 이 접근은 결과적으로 더 현실적이고 지속 가능한 방향이 된다.

여기서 중요한 건 “확장을 고려하지 말자”는 것이 아니다. 확장은 필요하다. 다만 그 시점과 방식이 중요하다. 실제로 문제가 발생하고, 병목이 명확하게 드러난 이후에 대응하는 것이 훨씬 효율적이다. 그때의 최적화는 구체적인 근거 위에서 이루어지기 때문에, 불필요한 복잡도를 최소화할 수 있다.

또한 단순한 설계는 팀 전체의 이해도를 높인다. 새로운 사람이 들어와도 빠르게 구조를 파악할 수 있고, 변경에 대한 두려움도 줄어든다. 이는 장기적으로 유지보수 비용을 낮추고, 시스템의 수명을 늘리는 데 큰 역할을 한다.

결국 좋은 설계는 “모든 상황을 대비하는 설계”가 아니라, “현재 문제를 가장 단순하게 해결하는 설계”다. 그리고 그 단순함 위에서 점진적으로 확장해 나가는 것이 더 강한 시스템을 만든다.

그래서 시스템을 설계할 때 한 번쯤은 이렇게 물어볼 필요가 있다.
지금 이 복잡함이 정말 필요한가, 아니면 아직 오지 않은 미래를 과하게 걱정하고 있는가.
그 질문에 솔직하게 답하는 순간, 설계의 방향은 훨씬 명확해진다.