우테코 프리코스 1주차 회고

서론

우테코 프리코스를 처음 참여하게 되어 다른 사람들은 어떤 식으로 코드를 작성하는지에 대한 궁금증이 있었다.

인터넷에 우테코 프리코스 회고를 정리해 놓은 블로그들이 많이 있었고, 다른 사람들의 코드를 찾아본 결과 대부분의 사람들이 MVC 패턴으로 개발을 진행하는 것을 보고 나도 MVC로 개발을 해봐야겠다는 생각에 MVC를 찾아보게 되었다.

 

프리코스 이전에는 MVC가 무엇인지는 알고 있었지만, 왜 써야 하는 것인지 어떻게 사용하는 것인지 정확하게 모르고 스프링에서 MVC로 개발하는 레퍼런스들을 보면서 따라만 했던 것 같다.

그래서 이번 기회에 MVC를 왜 사용하는가? 어떻게 적용하는가? 에 대해서 고민해 보았고, 4주 차 프리코스를 마친 현재의 내가 생각하는 MVC에 대해 기록해 본다.

 

 

MVC가 무엇이고,  왜 사용하는가?

MVC 패턴은 Model, View, Controller로 역할과 책임을 분리하여 가독성 및 유지 보수와 확장성을 높이기 위해 사용한다.

각각의 요소가 연관성 있는 내용만을 가지게 됨으로써 응집도가 높아지게 되는데, 1주 차 미션 문제인 숫자야구를 예로 들었을 때 숫자야구의 모델인 컴퓨터와 플레이어가 모델로써 플레이어는 플레이어의 로직만, 컴퓨터는 컴퓨터의 로직만을 독립적으로 수행한다. 

이때 독립적이라는 말은 컴퓨터가 컴퓨터의 로직을 처리할 때 플레이어에 의존하지 않는다는 뜻으로 컴퓨터의 로직을 파악할 때는 컴퓨터 클래스만 보면 되도록 구성해야 한다.

 

역할과 책임

로직이라는 말이 참 헷갈렸는데, 컨트롤러도 로직을 처리하고 모델도 로직을 처리하면 도대체 비즈니스 로직을 처리하는 코드를 어디서 작성하는 것인지에 대한 의문이 있었다.

그 이유는 평소 객체를 현실에 비유하는 경향이 있었는데, 모델이 스스로 로직을 처리하는 것이 말이 되는가?라는 생각이었다.

컴퓨터가 가지는 랜덤 수를 컴퓨터가 스스로 생성하는 것이 맞을까? 컨트롤러가 랜덤 수를 주입해 주는 것이 맞을까?라는 고민을 예로 들면, 컨트롤러가 비즈니스 로직을 제어해야 하니까 숫자야구의 핵심인 랜덤 수와 그 숫자를 비교하는 로직은 컨트롤러이고, 모델은 그 데이터를 가지고 컨트롤러가 비즈니스 로직을 처리하는 것을 도와주기 위한 기능들로 구성해야 한다고 생각했다.

 

그러나 MVC에 대해 검색해 본 결과 모델이 비즈니스 로직을 처리해야 하고, 컨트롤러는 직접적인 로직을 처리하는 것이 아닌 전체적인 로직을 처리하도록 도와주는 매니저 역할이라는 내용들이 많았고, "객체지향의 사실과 오해"라는 책을 읽고 많은 사람들이 객체를 현실에 있는 개념을 소프트웨어적으로 풀어낸 것이라 설명하지만, 실제 객체는 숫자 객체가 스스로 자신을 검증을 할 수 있는 것처럼 현실과는 다르다는 내용을 통해 지금까지 잘못 생각하고 있었다는 것을 깨달았다.

 

비즈니스 로직

1주 차 당시에는 아직 정확히 와닿지 않았지만, 일단은 모델의 역할이 상태(데이터) 관리와 직접적인 비즈니스 로직이라는 것을 인지만 한 상태로 과제를 제출하고 2주 차로 넘어갔고, 2주 차 요구 사항인 테스트 코드 작성을 통해 이 부분을 이해할 수 있었다.

 

그 이유는 컨트롤러에서 비즈니스 로직을 처리했을 때, 컴퓨터에만 해당하는 비즈니스 로직과 플레이어에만 해당하는 비즈니스 로직이 둘 다 컨트롤러에 작성되어 있으므로 MVC의 핵심인 역할 분리, 즉 하나의 클래스 파일이 하나의 역할만을 가져야 한다는 점을 위배하였고, 이로 인해 만약 플레이어의 기능에 대한 단위 테스트를 작성할 때 플레이어와 컴퓨터를 모두 가진 컨트롤러 객체를 생성하고, 컨트롤러에서 컴퓨터의 랜덤 수까지 지정해 주고 나서야 플레이어의 기능을 테스트할 수 있었다.

이렇듯 의존성이 높아져서 단위 테스트를 진행할 때 불필요한 부분까지 작성을 해야 하는 경험을 통해 직접적인 비즈니스 로직에 대한 처리를 해당 모델에서 처리해야 한다는 것을 느낄 수 있었다.

 

검증

위 내용은 검증에 대해서도 똑같이 적용된다. 모델에 직접적인 검증, 플레이어의 숫자에 대한 검증은 로직 처리와 같은 이유로 플레이어 객체에서 진행하는 것이 맞다.

만약 특정 모델에 종속적인 검증이 아니라면, 컨트롤러와 뷰에서 검증이 이루어질 수 도 있다.

입력한 값이 숫자가 맞는지 아닌지에 대한 검증은 다른 모델에서도 중복적으로 사용될 수 있는 검증 로직이다. 이런 경우에는 컨트롤러에서 해당 검증을 처리하는 것이 맞다고 생각하며, 뷰가 프론트엔드 페이지라면 입력 값을 이메일 형식을 지키도록 하는 등의 검증을 처리할 수 있다.

 

 

마무리

이 내용은 최근 인턴을 진행하면서 이때까지 해온 토이 프로젝트 보다 큰 규모의 프로젝트에서 수많은 파일과 코드를 보면서 더 크게 느낄 수 있었다.

하나의 기능을 구현하라는 업무를 받았을 때 코드를 작성하는 시간이 1이라면, 그 코드를 구현하기 위해 다른 기존 코드를 찾아보는 시간이 3~5 정도 되었다.

개발자가 프로젝트의 모든 코드를 알고 있기는 힘들기 때문에 어떤 기능을 추가하거나 변경하게 되었을 때 해당하는 부분의 코드만 보면 되도록 코드를 작성하여야 시간을 단축할 수 있으며, 더불어 스트레스도 줄일 수 있다는 것을 느꼈다.

내가 생각하는 MVC는 바로 이런 문제를 해결하기 위한 디자인 패턴이다.

 

 

구현 코드

코드 링크 👇

GitHub - jchyng/wooteco_baseball: 우테코 6기 프리코스 숫자야구