[학습 로그] 요구사항과 확장성은 어디까지 고려해야 할까

PROLOG - 요구사항과 확장성은 어디까지 고려해야 할까

우아한테크코스 학습로그 저장소

서론

미션을 진행하면서 요구사항 지키기는 필수다.
요구사항을 기준으로 기능을 나누고, 기능을 구현하고, 리팩토링 해야 한다.

 

그렇다면 요구사항만 지키면 끝일까?
우리는 사용자 친화적인 서비스를 만들기 위해 학습하고, 미션을 진행하고 있다.
서비스는 항상 변화하고, 그렇기 때문에 확장성에 신경을 써야 한다.

 

이런 경우 확장성은 어디까지 고려해야 할까.

사다리 미션에서

이번 미션에서 사다리를 이동시키고 출력하는 방법은 사람마다 다를 것이다.
요구사항을 보고 어떻게 구현하면 좋을지 고민하다가 3가지의 방식을 떠올렸다.

 

1. 사다리 생성 후
   → Users를 전부 사다리 이동해서 User-결과 매핑하고, 원하는 User 검색이 들어오면 해당하는 결과 값 찾아서 출력하는 방식
2. 사다리 생성 후
   → 원하는 User 검색이 들어오면, 그 때 해당하는 User만 사다리 이동하고 바로 출력하는 방식
3. 사다리 생성 후
   → 원하는 User 검색이 들어오면, User-결과 매핑에서 값이 있는지 확인하고 (캐시처럼)
   → 없으면 사다리 이동해서 결과 값 찾아서 저장 + 출력
   → 있으면 결과 값 바로 캐시에서 찾아서 출력

2번과 3번은 유사하니, 1번과 3번을 비교해보면

 

1번의 경우에는 User가 많아질 경우 필요없는 사다리 이동까지 수행해서 시간이 길어질 수 있다는 단점이 있지만,
지금 2단계 요구사항에서는 all을 입력해야 게임이 종료되기 때문에 무조건 User 결과를 전부 출력해야 해서 단점이 의미가 없다.

 

3번의 경우에는 1번의 경우보다 캐시에 값이 있는지 확인하는 시간이 더 필요하다는 단점이 있지만,
만약 게임이 all 입력을 하기 전에 끝낼 수 있도록 변경된다면 최악의 경우만 아니면 1번보다 훨씬 시간을 아낄 수 있다.

 

그러면 결국 요점은 all 입력 전에 게임을 끝낼 수 있는 기능이 추가될 것을 고려하느냐 안하느냐,
현재 요구사항만 생각할 것인지 확장성까지 고려할 것인지의 문제라고 볼 수 있다.

현업에서는?

위와 같은 고민을 리뷰어와 같이 하면서 리뷰어의 의견도 들어보았다.

 

 

리뷰어의 의견을 요약하자면, 현업의 입장에서는 최대 사용 인원을 100명으로 제한하는 등의 방식으로 사용에 제약을 거는 선택을 할 것 같다고 말씀하셨다.
일반적인 사다리 게임은 많아야 20명 정도의 사람만 사용하고, 서비스의 성능에 영향을 미칠만한 수준으로 사용자가 늘어나는 경우는 0.xx% 수준일 것이기 때문에 오히려 이런 부분에 집중해서 제약을 걸 것이라는 의견이었다.

결론

사실 이 부분은 정답이 없을 것이다.
위에서 본 현업의 입장에서도 확장성을 생각하지 말고 요구사항대로 해! 라는 말이 아니다. 오히려 확장성을 고려하되 서비스의 배경과 유저 행동 패턴 등까지 고려해서 제약 사항을 추가하는 방식도 있다는 뜻이다.

 

개인적인 의견으로는 우리는 끊임없이 변화하는 서비스를 만들어야 하는 사람으로서 요구사항만 생각하기보다는 확장성까지 고려하는 것이 더 올바른 방향이라고 생각한다.
정답은 없지만 여러 분석을 통해 요구사항과 확장성에 대한 트레이드 오프를 고려하고 올바른 방향을 선택하는 것이 좋은 개발자가 되는 길이지 않을까 생각한다.