웹 애플리케이션의 구조와 계층형 패키지 (Spring)

들어가며

이번 포스팅에서는 SOPT의 마지막 키워드 과제였던 " Controller, Service, Repository, Domain 은 각각 어떤 역할을 하나요 ? " 라는 키워드에 대해 학습했던 내용을 다뤄보려고 한다. 먼저 해당 주제를 이해하기 위해서는 웹 애플리케이션의 기본 구조, 그중에서도 MVC 패턴에 대해 알아야 한다. MVC 패턴은 소프트웨어 개발에서 코드의 유지보수성과 가독성을 높여주어서, 각 계층이 맡은 역할을 명확하게 정의할 수 있게 해준다. 이번 포스팅에서는 MVC 패턴의 기본 개념부터 시작하여, 계층형 패키지 구조가 가진 장단점과 함께 언제 이 구조를 선택해 구현해야하는지 함께 다루어보려고 한다

Web Application 아키텍쳐

---

본론

---

웹 애플리케이션의 기본 구조 – MVC 패턴

이미지로 보는 MVC 패턴

웹 애플리케이션에서 유저와의 인터랙션을 처리하기 위해 MVC(Model-View-Controller) 아키텍처를 흔하게 사용한다. 

1. Model (모델): 애플리케이션의 핵심 데이터와 그 데이터를 처리하는 비즈니스 로직을 담당한다. 데이터베이스와의 상호작용, 유효성 검증 등 데이터의 상태를 관리하는 역할을 한다
2. View (뷰): 사용자에게 정보를 보여주는 역할을 하며, 데이터를 시각적으로 표현하는 컴포넌트로, 화면에 출력될 정보를 책임지고 있으므로, 사용자는 데이터를 직관적으로 파악할 수 있다
3. Controller (컨트롤러): 사용자의 요청을 받아 적절한 비즈니스 로직이 실행되도록 중계하는 역할을 한다. 이 과정에서 요청 데이터를 해석하고, 결과를 뷰로 전달하는 다리 역할을 수행한다

MVC 패턴을 적용하면 코드의 모듈성이 높아지고, 위에서도 다루었듯이 각각의 구성 요소가 독립적으로 변경될 수 있어, 유지보수가 용이해진다는 장점을 얻을 수 있다. 이러한 기본 원리를 기반으로 하는 세부적인 주요 구성요소들의 역할을 좀 더 자세히 설명해보겠다

---

계층형 패키지 구조

스프링 프레임워크와 같은 현대적 웹 프레임워크에서 MVC 패턴을 확장한 형태인, 아래와 같은 계층형 패키지 구조를 사용할 수도 있다

project
 ┣ controller
 ┣ service
 ┣ repository
 ┣ domain (or entity)
 ┗ dto

다음으로는 위 계층형 구조의, 각 계층의 역할과 책임에 대해 자세히 설명해보려고 한다

---

Controller, Service, Repository, Domain의 역할과 책임

1. Controller의 역할 : Controller는 사용자의 요청을 가장 먼저 받아들이는 계층입니다. 사용자가 웹 브라우저나 모바일 앱에서 요청을 보내면, 이 요청은 컨트롤러로 전달된다. 컨트롤러는 요청을 분석한 후, 이를 처리할 적절한 서비스 로직을 호출해준다 이때 Controller는 직접 비즈니스 로직을 수행하기 보다는 Service에 위임해준다는 점이 중요하다고 생각한다
2. Service의 역할 : Service는 애플리케이션의 핵심 비즈니스 로직을 담당한다. 서비스단에서는 사용자가 보내는 요청에 대해 단순히 데이터를 전달받아 Repository에 위임하는 것이 아니라, 비즈니스 로직을 통하여 데이터의 무결성을 보장하고, Service는 트랜잭션 관리와 같은 부가적인 로직을 포함할 수 있으며, 여러 도메인 객체들을 조합하여 복잡한 처리를 수행해준다
3. Domain (Entity)의 역할 : Domain 혹은 Entity 계층은 시스템의 핵심 데이터와 비즈니스 규칙을 담고 있는 객체들로 구성되는데, 여기서 데이터의 상태 및 행동을 스스로 관리하도록 설계된다 (ex. 유효성 검사 등)
4. Repository의 역할 : 데이터의 영속성을 담당하는 계층으로 데이터베이스와의 직접적인 상호작용을 통해, 데이터를 저장, 수정, 삭제 및 조회하는 역할을 수행해준다. Repository에서는 비즈니스 로직을 포함하지 않으며, 오직 데이터 관리에 집중해야한다. 스프링 데이터 JPA와 같은 기술을 활용할 경우, Repository는 인터페이스 형태로 선언되어 CRUD 기능을 자동으로 제공받을 수 있고, 비즈니스 로직과 데이터 접근 로직이 명확히 분리되며, 유지보수성이 향상될 수 있다

---

마치며

계층형 구조는 말 그대로 계층별로 역할이 분리되어 있기 때문에, 애플리케이션의 전체적인 흐름을 한 눈에 파악할 수 있고, 각 계층은 서로 다른 관심사를 다루므로, 코드의 역할이 분명해지고 협업 시에도 효율적으로 가능하다는 장점을 가진다. 따라서 계층형 구조는 규모가 작고, 도메인이 적은 프로젝트에서 특히 유리하다는 장점을 가지지만, 반대로 프로젝트 규모가 커지면서 유스케이스 중심의 코드 구성이 필요할 때 계층형 패키지는 그 한계가 드러날 수 있다는 생각이 들었다. 

계층형 구조 외에도 도메인 주도 설계(DDD)나 클린 아키텍처 등 다양한 패키지 구성 방식이 존재한다. 해당 내용을 깊게 공부하며 본인이 하는 프로젝트에 볼륨과 팀의 역량 등등의 실제 상황에 맞춰서 알맞는 패키지 구조를 선택해서 프로젝트를 하는 것이 중요하다고 생각했다