소프트웨어 설계가 처음이라면 이 5가지 질문부터 던지는 편이 낫다

소프트웨어 설계를 처음 배울 때 많은 사람이 “어떤 클래스를 몇 개 만들어야 하지?”부터 고민한다. 하지만 설계의 출발점은 클래스 수가 아니다. 더 먼저 필요한 것은 무엇을 나눠야 하는가를 묻는 질문들이다.

처음 설계할 때 도움이 되는 질문은 의외로 단순하다. 그리고 이 질문들은 파나스의 정보 은닉 원칙이나 Fowler의 YAGNI처럼 오래 살아남은 설계 원칙과도 잘 맞닿아 있다.

이 시스템의 핵심 책임은 무엇인가

설계는 대상을 많이 만드는 일이 아니라 책임을 분리하는 일이다. 예를 들어 카드 게임을 만든다면 플레이어, 카드, 턴, 점수 중 무엇이 시스템의 핵심 책임인지 먼저 봐야 한다.

이 질문이 중요한 이유는, 책임이 보이지 않으면 클래스만 늘어나기 쉽기 때문이다. 이름은 많아지는데 실제 역할은 겹치고, 변경도 함께 번진다.

두 번째 질문은 구조보다 흐름에 가깝다.

이 흐름이 보이면 설계는 절반쯤 정리된다. C4 모델이 시스템과 컨테이너, 컴포넌트를 단계적으로 보게 하는 것도 결국 이 질문을 쉽게 만들기 위해서다.

파나스가 강조한 정보 은닉의 핵심은 자주 바뀔 설계 결정을 숨기라는 데 있다. 입문자가 이 원칙을 이해하면 설계가 훨씬 현실적으로 바뀐다.

예를 들면 이런 것들이다.

이런 부분을 미리 찾아서 경계를 잡으면, 나중에 변경이 들어와도 전체를 뜯지 않아도 된다.

입문 설계가 가장 자주 실패하는 지점은 미래를 너무 많이 상상하는 데 있다. 아직 필요하지 않은 확장 포인트와 추상화를 미리 다 넣어 두면, 설계는 금방 무거워진다.

그래서 YAGNI는 초보자에게 특히 유용하다. 지금 필요하지 않은 것은 만들지 말라는 원칙은 게으름이 아니라, 검증되지 않은 복잡성을 늦추는 태도다.

처음에는 간단한 구조로 시작하고, 실제 변경이 들어올 때 리팩터링하는 쪽이 더 안전하다.

좋은 설계는 작성자 머릿속에서만 완결되지 않는다. UML이든 C4든, 혹은 간단한 메모든, 다른 사람에게 짧게 설명할 수 있어야 한다.

설명을 해 보면서 금방 드러나는 것들이 있다.

즉 설명 가능성은 설계 품질을 확인하는 가장 빠른 테스트 가운데 하나다.

소프트웨어 설계 입문에서 중요한 것은 멋진 다이어그램보다 좋은 질문이다. 핵심 책임은 무엇인지, 데이터는 어디를 통과하는지, 무엇이 자주 바뀌는지, 지금 필요한 만큼만 만들고 있는지, 그리고 이 구조를 짧게 설명할 수 있는지를 먼저 물어야 한다.

이 다섯 질문이 선명해지면 클래스와 패턴은 그다음에 따라온다. 설계는 도구를 많이 아는 사람이 잘하는 것이 아니라, 문제를 나눠서 설명할 수 있는 사람이 잘한다.