잘된 설계란 무엇일까요?
개발자들 사이에서 끊임없이 논의되는 주제입니다.
잘된 설계와 잘못된 설계, 그리고 어떻게 설계하면 되는지에 대해 이야기해보겠습니다.
잘된 설계의 특징:
-
말로 설명할 수 있는 설계
잘된 설계는 복잡한 기술 용어 없이도 쉽게 설명할 수 있어야 합니다.
사람이 말로 설명하는 과정이 그대로 구현되는 구조가 이상적입니다.
말로 설명하기 복잡한 기능은 실제로 구현하면 훨씬 더 난해한 기능이 되기 마련입니다. -
문제가 되는 부분을 분리하여 재구현할 수 있는 설계
잘된 설계는 특정 부분에 문제가 생겼을 때 전체 시스템에 영향을 주지 않고 해당 부분만 수정할 수 있어야 합니다.
특정 부분에 문제가 생기거나 기능 추가가 필요하면 그 부분만 분리해서 다시 만드는게 낫습니다.
코드 품질이 우수하고 통으로 만들어진 시스템과 코드 품질은 엉망인데 분리가 잘 되어있는 시스템은 후자가 훨씬 관리하기 편합니다. -
필요한 만큼만 간단하게 구성한 설계
잘된 설계는 당장 필요한 요구사항만을 만족시켜야 합니다.
필요할거 같다고 불필요한 내용을 미리 만들게 되면 쓸데없이 복잡도만 올라가게 됩니다.
반면, 잘못된 설계의 특징은 다음과 같습니다:
-
예쁘게 구성한 설계
깔끔하게 떨어지고 아름답게 연결되는것에 집착하는 개발자들이 많습니다.
단순히 보기 좋은 코드나 구조에 집착하는 것은 위험합니다.
아름다운 구조에 매달리다 실제 기능 구현이나 성능 최적화를 놓치는 경우가 많습니다. -
하나 수정하려면 모든 프로세스를 수정해야 하는 설계
이는 높은 결합도를 가진 설계의 전형적인 문제점입니다.
작은 변경사항이 전체 시스템에 영향을 미치는 구조는 유지보수를 어렵게 만들고 버그 발생 가능성을 높입니다. -
아직 필요 없지만 나중에 필요할 것 같아서 기능을 추가한 설계
미래의 가능성을 위해 현재 불필요한 기능을 미리 구현하는 것은 복잡도만 높이는 결과를 낳습니다.
이는 YAGNI(You Aren't Gonna Need It) 원칙에 위배되며, 시스템을 불필요하게 복잡하게 만듭니다.
나중에 필요할거 같은건 나중에 만드는게 낫습니다.
그렇다면 설계를 잘하려면 어떻게 해야 할까요?
-
요구조건을 명확한 언어로 기술
모호한 표현을 피하고 구체적이고 명확한 언어로 요구사항을 정의합니다.
말로 설명하기 복잡하지만 크게 중요하지 않은 기능이 있다면 초기 설계에서는 빼고 만드는게 낫습니다. -
기능을 그림으로 그려보기
말로 설명한 기능을 그림으로 그려봅시다.
처음에는 UML이 아닌 간단한 순서도 정도로 그리는게 좋습니다.
UML을 처음부터 그리게되면 객체간의 관계가 복잡해져서 한눈에 파악하기 어려울 수 있습니다. -
각 기능들이 독립적으로 구현될 수 있도록 설계
기능 간 의존성을 최소화하고 모듈화합니다.
프로그램은 언제나 문제를 일으킵니다.
문제가 발생했을 때 시스템 전체가 아니라 해당 모듈만 고칠수 있어야 합니다. -
필요한 게 아니라 필요할 것 같은 기능은 추가하지 말 것
현재의 요구사항에 집중하고, 불확실한 미래의 기능은 배제합니다.
필요할 때 확장하는 것이 대부분의 경우에 더 효율적입니다.
굳이 넣고자 하면 넣는 자리 정도만 만들고 세부 구현까지는 하지 않는게 좋습니다.
결국 잘된 설계란 필요한 기능이 잘 나눠서 만들어진 프로세스라고 볼 수 있습니다.
