이 주제를 CS 이론으로 분류해야 할지 플젝 기록으로 분류해야 할지 고민했는데, Java Spring 특화 이야기기도 하고, 이론적인 공부보다는 경험에 기반하여 작성할 것 같아서 플젝 쪽으로 넣었다. 마음 바뀌면 어느 순간 카테고리가 바뀔지도 모른다.
Spring은 여러 클래스를 Spring Bean으로 등록하여 사용하도록 한다. Bean의 개념에 대해서는 Spring의 구조와 생명주기에 대한 이야기가 함께 설명되어야 하기 때문에 나중으로 미루고, 오늘은 레이어드 패턴에 기반한 Spring 어노테이션 활용에 대해 말해보자.
레이어드 패턴(혹은 레이어드 계층 아키텍처 패턴.. 뭐라고 부르든 간에)은 각 계층(레이어)의 구성요소가 딱 해당 계층의 기능만 수행하도록 하여 관심사를 분리하는 효율적인 아키텍처 패턴이다. 이렇게 계층 구조로 각 역할을 분명하게 구분해두면, AOP (관점지향 프로그래밍) 관점에서 관심사를 횡단으로 분리하여 묶는 작업에도 효율적이다.
Spring은 몇 가지 어노테이션을 통해 각 컴포넌트가 분명한 역할을 가지고 있음을 가시화해준다. @Controller, @Service, @Repository가 그것이다.
@Controller
컨트롤러 단에서는 api 형식과 구조를 정의한다. (REST api 기반한 설명이지만) 요청_Request로 받는 데이터와 응답_Response하는 데이터(보통 데이터 전달 객체 DTO 활용), 해당 요청과 응답이 맵핑된 api(url 주소와 파라미터, HTTP 메서드 등) 정보가 모두 컨트롤러에서 드러난다.
기본적으로 @Controller는 View를 반환하기 떄문에, 따로 프론트에 API를 제공하는 경우 텍스트를 전달할 수 있도록 JSON을 기본 응답 형식으로 제공하는 @RestController를 사용하는 것이 좋다. 컨트롤러의 많은 메서드가 View로 반환하지만 특정 메서드만 API 혹은 문자열 그대로 반환해야 할 때는 @Controller를 사용하되, 해당 메서드에 @ResponseBody를 붙여주는 것 또한 방법이다.
@Service
기능적인 부분은 전부 Service에 작성하는 게 일반적이다. 모듈을 정의하는 컨트롤러와 다르게 서비스에서는 해당 모듈의 실질적인 기능을 구현한다. 컨트롤러와 레포지토리의 중간에 있으며, 주로 의존성 주입으로 연결해서 사용하는데... 이건 나중에 의존성 얘기할 일이 있을 것이다. 간단하게, 컨트롤러에 서비스 빈을 의존성 주입하여 컨트롤러 메서드가 서비스 메서드를 호출할 수 있고, 서비스에는 레포지토리 빈이 의존성 주입되어 서비스 메서드가 레포지토리 메서드를 호출할 수 있다.
@Repository
레포지토리는 DB와 상호작용을 담당한다. CRUD에 해당하는 모든 작업은 DB에 반영되기 위해 레포지토리를 거치며, 반대로 DB에서 데이터를 가져올 때도 마찬가지이다. Java - Spring 환경이라면 ORM 기술 중에서도 사용이 간편한 JPA를 주로 사용하는데, 환경에 따라 Hibernate를 사용하기도 한다. 간혹 JDBC를 사용해 직접 SQL로 DB와 소통하는 프로젝트도 있지만 개인적으로는 선호하지 않는다.
ORM은 객체 관계 맵핑을 위한 기술로, 객체지향언어인 Java로 작성된 데이터 정의 및 수정 요구를 관계형 데이터베이스 RDBM의 언어로 자동 맵핑 해주는 일종의 프레임워크이다. SQL문을 작성할 수 있다면 직접 쿼리문을 작성하는 것도 어렵지는 않으나, JPA 등이 제공하는 기본 기능이 워낙 간편하고, DB 마다 조금씩 다른 SQL 규칙을 고려할 필요가 없다는 점 등에서 ORM 기술, 그중에서도 JPA가 선호되고 있는 추세이다.
프로젝트를 하면서 가장 많이 사용하게 되는 어노테이션을 꼽으라면 @Getter, @Setter와 함께 @Controller, @Service, @Repository가 아닐까 싶다. 이들은 @Bean이나 @Component가 가지는 빈 등록의 기능을 수행하면서 동시에 프로그래머에게도, Spring에게도 각 빈이 어떤 역할을 하고 있는지 분명하게 보여준다.
더워서 오전에 쓰고 끝내버린다는게 유튜브 보다가 12시에 가까워서야 끝이 나다니... 역시 더워서 집중력이 떨어진다. 도서관이나 청년 센터에 하루종일 있으면 좋겠는데 또 거기까지 가는게 덥다. 슬라임이 되어 버려...
'프로젝트 · 트러블 슈팅' 카테고리의 다른 글
[플젝기록] 생성자 관련 @어노테이션 (0) | 2025.07.03 |
---|---|
[플젝기록] 배포와 배포 자동화 CI/CD 고민의 흔적: Jenkins vs GitHub Actions (2) | 2025.07.01 |
[플젝기록/트러블슈팅] 서버 및 DB 배포(AWS)와 CI/CD 구성 (3) (1) | 2025.06.03 |
[플젝기록/트러블슈팅] 서버 및 DB 배포(AWS)와 CI/CD 구성 (2) (2) | 2025.05.29 |
[플젝기록/트러블슈팅] 서버 및 DB 배포(AWS)와 CI/CD 구성 (1) (0) | 2025.05.27 |