확장성은 어디까지 고려해야 할까?

우테코에서 자동차 경주 미션을 하며 소스에 대한 피드백을 많이 받았다.

그중에는 리뷰어님과 참 오랜 시간동안 의견을 나눈 부분도 있는데, 바로 확장성에 대한 부분이다.

 

기존에 나는 모든 부분에서 확장성을 고려하서 설계하고, 구현했다. 이번 자동차 경주 미션을 보자.

 

자동차 경주 미션에서 자동차의 움직임 조건은, 랜덤으로 숫자를 하나 생성하고 그 수가 4 상이면 전진, 아니면 stop인 요구사항을 가지고 있다.

 

그래서 나는 아래와 같이 코드를 작성했다.

public interface MoveCondition {
    boolean isMovable();
}

public class RandomMoveCondition implements MoveCondition {
	...
    private final RandomUtils<Integer> randomUtils;

    public RandomMoveCondition(RandomUtils<Integer> randomUtils) {
        this.randomUtils = randomUtils;
    }

    @Override
    public boolean isMovable() {
    	...
    }
}

public class Car {
    private int position;
    private MoveCondition moveCondition;
    private CarName name;

    public Car(String name, MoveCondition moveCondition) {
        this.moveCondition = moveCondition;
        this.name = new CarName(name);
    }
    
    public void move() {
        if (!isMovable()) {
            return;
        }
            
        position++;
    }    
    ...
}

자동차가 움직일 수 있는지, 없는지의 상태 판단을 위한 MoveCondition interface를 정의하고 그 구현체를 만들었다. 그리고 랜덤한 수를 만들어 내는 역할을 가지고 있는 RandomUtils을 주입하고, 랜덤 값을 받고, 유효성을 검사하고, 그 랜덤 값이 4를 넘는지 확인한 후 boolean을 리턴하는 isMovable 메소드를 생성했다.

 

당연히 잘 만들었다고 생각했다. 이렇게 설계하면 randomUtils를 상속받은 구현체들을 통해 랜덤 값을 생성하는 방법을 여러가지로 만들 수 있고(예를 들면, 특정 수가 일정 확률로 더 잘 나오게 한다든지?->가챠.?) MoveCondition을 상속받은 구현체는 움직임 명세에 대해 유연하게 대처할 수 있다고 생각했기 때문이다.

 

하지만 리뷰어분으로 부터 아래와 같은 답이 왔다.

흠.. 뒷통수를 한대 얻어맞은 기분이었다. 당연히 모든 상황에서 유연하게 대처하는 설계가 좋다고 생각했는데, 요구사항의 분석 방향에 따라 또 그게 아닐수도 있다니...

 

시스템 설계를 진행할 때 확장성에 대한 고민을 지금까지 제대로 하지 못했던 것 같다. 확장성은 크면 클수록 좋다고 생각했기 때문이다.

하지만, 요구사항에 따라 높은 확장성은 오히려 쓸대없이 비용이 높아질 수 있다는 리뷰어님의 의견.....

이 둘 사이의 trade-off를 잘 생각 하는것도 앞으로는 많은 고민을 통해 정해야 할 것 같다.

 

정말.. 프로젝트를 바라보는 시각이 너무 다르다. 나는 언제쯤 나만의 울타리에서 벗어나 더 큰 눈으로 프로젝트를 볼 수 있게 되는걸까..?