내 Spring Boot Controllers는 괜찮아 보였지만… Presentation Layer를 이해하기 전까지
Source: Dev.to
🧠 프레젠테이션 레이어란? (쉽게 말하면)
프레젠테이션 레이어는 Spring Boot 애플리케이션의 진입점입니다. 역할은 다음과 같습니다:
- 클라이언트로부터 HTTP 요청을 받는다
- 요청을 올바른 엔드포인트에 매핑한다
- 입력 데이터를 받아 변환한다
- JSON/XML 형태로 응답을 반환한다
비즈니스 로직을 포함해서는 안 됩니다.
데이터베이스와 직접 통신해서도 안 됩니다.
역할은 간단합니다:
요청 처리 → 작업 위임 → 응답 반환
🏗️ 큰 그림: Spring Boot 프로젝트 구조
깨끗한 Spring Boot 웹 애플리케이션은 보통 다음과 같이 구성됩니다:
client
controller
service
dto
repository
entity
database핵심 규칙:
👉 컨트롤러는 서비스와 통신하고, 데이터베이스와는 직접 통신하지 않는다.
이 규칙을 따르면 코드가 하룻밤 사이에 깔끔해집니다.
🎮 컨트롤러: 프레젠테이션 레이어의 핵심
Spring MVC는 어노테이션 기반 프로그래밍 모델을 제공해 컨트롤러를 만들 수 있게 해줍니다.
중요한 어노테이션
@Controller– 뷰를 반환하는 전통적인 MVC 애플리케이션에서 사용합니다.@RestController–@Controller + @ResponseBody의 단축 형태입니다.@RestController안의 모든 메서드는 클라이언트에 JSON/XML을 직접 반환합니다. REST API에서는@RestController가 기본 선택입니다.
🔗 요청 매핑: 요청이 코드를 찾는 방법
Spring은 어떤 URL이 어떤 메서드에 매핑되는지 알아야 합니다. 여기서 요청 매핑이 사용됩니다.
@RequestMapping
다양한 매핑을 지원하는 일반적인 어노테이션:
- URL 경로
- HTTP 메서드
- 헤더
- 미디어 타입
실제 프로젝트에서는 더 깔끔한 대안을 주로 사용합니다.
🚦 HTTP 메서드‑별 매핑 (이것을 사용하세요)
Spring은 API를 읽기 쉽게 만들어 주는 단축 어노테이션을 제공합니다:
@GetMapping→ 데이터 조회@PostMapping→ 데이터 생성@PutMapping→ 데이터 업데이트@DeleteMapping→ 데이터 삭제@PatchMapping→ 부분 업데이트
이를 적절히 사용하면 API가 자체 설명적이 됩니다.
🌍 동적 URL: @PathVariable vs @RequestParam
@PathVariable
/employees/123값이 필수이며 리소스를 고유하게 식별할 때 사용합니다.
@RequestParam
/employees?id=123파라미터가 선택적일 때, 예를 들어 필터링, 정렬, 페이지네이션 등에 사용합니다.
이 차이를 이해하면 API 설계가 즉시 개선됩니다.
📦 @RequestBody 로 입력 데이터 처리하기
클라이언트가 데이터를 (JSON/XML) 전송하면 Spring은 @RequestBody 를 통해 이를 Java 객체로 변환합니다. 주로 다음 경우에 사용됩니다:
- POST
- PUT
- PATCH
Spring의 메시지 컨버터(예: Jackson)가 JSON을 자동으로 Java 객체로 변환합니다.
⚠️ 내가 저질렀던 실수
예전에는:
- 컨트롤러 안에 로직을 넣었다
- 데이터를 수동으로 검증했다
- 레포지토리를 직접 호출했다
이렇게 하면 관심사의 분리가 깨집니다. 프레젠테이션 레이어는 비즈니스 로직을 위한 곳이 아니다. 이 경계를 지키면 API가:
- 더 깔끔해지고
- 테스트하기 쉬워지고
- 유지보수가 쉬워진다
🚀 마무리 생각
프레젠테이션 레이어는 겉보기엔 단순하지만, 백엔드가 얼마나 깔끔해질지를 결정합니다.
컨트롤러가 깔끔하면:
- 서비스가 빛을 발하고
- 버그가 줄어들며
- 확장이 쉬워진다
이 레이어를 이해한 것이 내 Spring Boot 여정의 전환점이었습니다.
이 글은 Spring Boot와 백엔드 개발을 탐구하면서 진행한 공개 학습 여정의 일부입니다.