[우테코 7기 프리코스 3주 차] MVC

 

프리코스 3주 차, 잘못된 입력에 예외가 발생하면 다시 올바른 입력을 요청해야 한다는 요구 사항이 나를 막아세웠다.

 

1. 무엇이 잘못된 입력인가?
2. 이 경우 예외는 어떤 타입으로 던질 것인가?
3. 잘못된 입력을 검증하는 책임은 어디에 있는가?
4. 입력을 다시 요청하는 로직은 어디에 배치해야 하는가?

한 문제를 넘으면 또 다른 난관이 기다리고 있었다. 지금은 문제를 파악하고 해결했기에 넓은 시각으로 볼 수 있지만, 그 당시에는 올바르게 처리하고 있는지 끊임없이 확인하며 버거움을 느꼈다.

 

완벽함을 추구하는 욕심을 내려놓았다면 빠르게 구현할 수 있었겠지만, 포기할 리 있나.

 

---

 

MVC

 

 

소프트웨어 설계의 복잡성을 관리하는 방법 중 하나가 바로 MVC(Model-View-Controller) 패턴이다.

 

애플리케이션의 구조를 세 가지 주요 계층으로 나누어 설계하는 방식으로,

 

• Model은 데이터와 비즈니스 로직을,
• View는 사용자 인터페이스와 화면 출력을,
• Controller는 사용자 입력을 처리하며 Model과 View 사이의 중간 다리 역할을 한다.

이렇게 구조를 나누면 각 계층의 책임이 분명해지고 코드의 응집도가 높아지는 장점이 있다.

 

---

 

 

MVC 도입

 

“MVC 패턴을 도입할 때가 되었나?”

 

사실 지금까지 프리코스를 진행하며, 의도적으로 MVC 없이 설계를 진행해 왔었다. 없어도 되면 도입하지 않아도 된다고 생각했기에.

하지만 점점 다뤄야 할 로직이 많아지고 복잡성이 높아지면서, MVC 패턴을 사용하면 복잡한 구조를 정리할 수 있을 것 같았다.

 

MVC 패턴이 만능은 아니기에 각 계층의 역할을 얼마나 명확히 분리할 지부터가 고민의 시작이었다.

특히 Controller와 Model의 경계, 그리고 각 계층이 어떤 책임을 가져야 할지 정하는 것은 결코 쉬운 일이 아니었다.

 

---

 

DTO (Data Transfer Object)

 

MVC를 적용하면서 또 다른 선택지인 DTO에 대한 고민이 깊어졌다. 처음에는 도메인 객체를 계층 간의 이동에 사용할까 싶었는데, 점점 로직이 복잡해지면서 각 계층을 철저히 분리할 필요가 있다는 생각이 들었다.

 

따라서 도메인 객체를 직접 넘기는 것보다는 DTO를 통해 데이터를 전달하는 편이 더 명확한 구조를 만들 것 같았다.

 

물론, DTO를 추가하면서 코드가 다소 복잡해졌고, 가독성이 , 모든 계층이 독립성을 유지하고 변경에 유연하도록 하는 데 도움이 될 것이라 판단했다.

 

---

 

 

각 계층에 맞는 검증과 책임

 

 

MVC 패턴을 통해 애플리케이션의 로직을 계층별로 나누면서 예외 검증의 흐름을 체계적으로 관리할 수 있었다.

 

View

 

인풋 핸들러를 통해 기본적인 최소한의 검증을 처리하고, 주요 입력 데이터가 유효한지 1차적으로 확인했다.

이 단계에서의 검증은 단순한 유효성만 포함했다.

 

 

Controller

 

Controller는 View에서 전달된 입력을 받고, Model(Service)에 전달했다.

잘못된 입력에 대한 예외가 발생하면 Controller가 이를 감지하고, View에게 올바른 입력을 유도하는 메시지를 전달하도록 했다.

 

 

Model

 

계층 간 결합도를 낮추기 위해 DTO로 데이터를 입력받고, 반환하도록 설계했다. 도메인 객체는 자체적인 유효성 검증을 포함하며 비즈니스 로직에 집중할 수 있었다. 이를 통해 데이터는 필요한 최소한의 정보만 담은 상태로 이동하며, 각 계층의 역할도 명확히 구분할 수 있었다.

 

이러한 구조 덕분에 각 계층이 독립적으로 책임을 유지할 수 있었고, 유지보수성과 테스트 용이성도 크게 향상되었다. 예외 처리와 재입력 요청을 구조적으로 배치하면서, 각 계층의 독립성과 명확한 역할이 애플리케이션의 일관성을 보장하는 데 중요한 역할을 했음을 알게 되었다.

 

MVC 패턴은 모든 문제를 단번에 해결해 주진 않았지만, 로직을 계층별로 정리하며 얻은 인사이트는 설계의 시야를 넓히는 소중한 경험이 되었다.

 

---

 

마무리

 

 

스프링 프레임워크를 사용하며 계층의 역할을 이해했다고 생각했지만, 이렇게 명확히 각 계층의 책임을 구분하며 코드를 작성해 본 것은 처음이었다. MVC 패턴을 단순히 적용하는 것과, 계층 간 결합도를 낮추고 흐름을 체계적으로 관리하는 것은 분명 다른 차원의 작업이었다.

 

이번 경험을 통해 더 나은 설계를 향한 갈 길이 멀다는 것을 실감했다. 더욱 견고하고 일관성 있는 애플리케이션 설계를 위해서는 앞으로도 많은 고민과 학습이 필요할 것이다. 좋은 설계를 향한 길은 멀고도 험하지만, 이 과정에서 얻은 경험은 그 여정에 든든한 밑거름이 될 것이라 믿는다. 건물을 먼저 세워둔 뒤, 이제 와서 지반을 다지는 듯한 기분이 들기도 하지만