[Backend]스프링 부트 패키지 구조로 보는 백엔드 개발의 기본 구조

서버와 클라이언트 구조를 배운 후 뭘 공부해야 할까?

바로 MVC이다.

스프링 부트 책이든, 영상이든 모든 교육자료가 말하는 백엔드 개발의 진정한 입문은 지금부터였다.

개인적으로 이 부분은 정말 오래도록 이해가 가지 않았다.

갑자기 이게 작동 과정입니다 하는데, 완전한 노베이스였던 나는 이해를 제대로 하지 못했었다.

지금은 나만의 머릿속 정리가 어느 정도 끝났기에 괜찮지만,

내 스터디 팀원들이 이 글을 본다면 말해주고 싶다.

난 이 내용을 정확히 이해하기까지 2달이 걸렸다.

( 물론 그동안 이것만 공부한 건 아니라 뒤 진도를 계속 나가다가 딱 깨달은 시점이 2 달이다. 알려주는 사람 없이 혼자 경험하면서 배우면... 아쉽지만 오래 걸린다.)

 

대충 이런게 있구나는 누구나 알지만, 이게 정확히 어떤 역할을 하는지는 지금도 내가 정답이라 하긴 힘들다고 생각한다.

특히 실습 과정에서의 패키지 구조는 개인별로 많이 다르다고 한다. 기존에 개인이 쓰던 방식이 있어도 사전 설정을 맞추는 과정에서 팀원들과 맞추는 거라고 한다.

 

이러한 사전 상황을 알고 밑을 읽어주길 바란다.

이 글에서는 웹 애플리케이션에서 가장 널리 쓰이는 MVC 아키텍처를 먼저 설명하고, 그 안에서 각 구성 요소의 역할과 서버에서 데이터가 처리되는 흐름을 단계별로 소개하겠다.

 

 

---

1. MVC란?

MVC는 Model-View-Controller의 약자로,
웹 애플리케이션을 구조화하는 데 가장 널리 쓰이는 아키텍처이다.

 

간단히 정리하면 아래와 같다.

 

이렇게 들으면 이게 뭐지 할 수도 있다.

그렇기에 서버에서 MVC의 흐름을 글과 이미지로 함께 보자.

 

1. 사용자가 웹에서 버튼 클릭 → HTTP 요청 발생
2. Controller가 요청을 받아 처리 시작
3. Controller는 필요한 로직을 Service에 전달
4. Service는 필요한 데이터를 Repository를 통해 DB에서 조회 또는 수정
5. 가공된 데이터를 DTO로 변환해 다시 Controller로 전달
6. Controller는 그 데이터를 클라이언트(View)에게 반환

 

위 내용을 간략히 정리하면 컨트롤러는 지휘부이다.

클라이언트에서 요청을 받으면 서비스 계층에서 그에 맞는 비즈니스 로직 실행을 지시한다.

서비스 계층에서 비즈니스 로직, 즉 알고리즘을 실행하려면 데이터가 필요하다.

그러한 데이터가 어디 있을까? 바로 DB이다.

그렇기에 DB에서 필요한 데이터를 받아 서비스 계층에서 열심히 동작한 후 컨트롤러에 말한다. " 나 일 다했다 인마"

그럼 컨트롤러는 서비스 계층에서 일한 결과물을 클라이언트에 반환(응답)한다.

 

이 과정을 다르게 말하면 스프링 부트 패키지 구조의 실행 과정이다.

 

---

2. 스프링 부트 패키지 구조

 

굳이 스프링 부트 패키지 구조라고 말하는 이유는 밑의 서버 실행 과정이 백엔드 서버의 작동 과정이고, 데이터의 흐름 순서이기 때문이다.  좀 더 명확하게 말하면 그게 스프링 부트에서 일어나고, 이 실행 과정에 맞게 우린 스프링 부트 패키지를 설정하기 때문이다.

즉 이 스프링 부트 패키지 구조는 곧 해당 서버의 작동 과정이기도 하다.

 

아래 이미지는 원래 목적과 다르지만 난 이것을 스프링 부트 패키지 구조라고 표현한다.

위 이미지에서 보이는 각 구성요소들은 서버 안에서 책임이 분리된 형태로 동작한다.
이를 MVC 기반의 스프링 부트 구조라고도 하며, 각 계층은 다음과 같은 역할을 한다.

 

1, DTO-> 데이터 전달을 위한 객체

 

• 클라이언트와 서버, 서버 내부 계층 간에 데이터를 전달할 때 사용하는 객체이다.
• Entity와 달리, DB와 직접 연결되지 않고, 필요한 필드만 담아 가볍게 전달한다.
• 데이터 검증이나 직렬화에 유리하며, 보안상 감춰야 할 정보를 제외할 수 있다.

2, Controller-> 요청을 받아 처리 흐름을 시작하는 관문

 

• 클라이언트의 요청(Request)을 가장 먼저 받는 계층이다.
• 요청을 분석하고 필요한 DTO로 변환한 후, 서비스 계층에 처리를 위임한다.
• 응답(Response) 또한 여기서 구성해서 클라이언트에게 돌려준다.

3, Service-> 비즈니스 로직을 담당하는 중간 관리자

 

• 컨트롤러에서 받은 요청을 처리하는 실질적인 로직이 들어간다.
• 예: 회원가입 시 비밀번호 암호화, 중복 확인 등
• DB와 직접 연결되지 않고, Repository를 통해 데이터에 접근한다.

4, Repository-> DB와 직접 연결되어 데이터를 활용하는 계층

 

• JPA, MyBatis 등 ORM 기술을 활용해 실제 SQL 없이 데이터 접근이 가능하게 해 준다.
• Service 계층이 데이터를 얻거나 저장하고 싶을 때 호출한다.

5, DB-> 실제 데이터가 저장되는 공간

 

• 영구적인 데이터 저장소이며, 테이블 형태로 데이터를 유지한다.
• Repository가 실행한 SQL 또는 ORM 쿼리가 여기서 작동하게 된다.

---

이처럼 DTO, Controller, Service, Repository, DB는 각각 역할을 명확히 나누어 구성된다.
이 구조 덕분에 유지보수에 강하고, 테스트가 쉬우며, 협업 시 역할 분담이 명확한 애플리케이션을 만들 수 있다.

실제 프로젝트에서도 이 구조는 거의 표준처럼 사용되며,
Spring Boot를 처음 배운다면 반드시 익혀야 할 설계 흐름이다.