스프링(Spring)의 층(Layer)

내가 그동안 계속 리액트와 프론트앤드 관련 기록을 남겨왔는데, 왜 백엔드도 하는지 궁금하다면…
불과 몇 개월 전, AI로 인해 특정 직종의 경계가 희미해지는 것을 목격하며 많은 생각이 들었다.
"다음은 무엇이 될까?"라는 불안함보다는, "더 넓은 영역을 이해하는 개발자가 되자"라는 결심이 섰다.
재작년 부트캠프에서 배웠던 자바를, 리액트 실무를 경험한 지금 다시 공부해보니 또 다르다!

리액트는 보통 API 호출 → State 저장 → UI 렌더링으로 흐름이 명확하다.
그런데 스프링은 비교적 이렇게 층(Layer)이 많고 복잡하다

스프링의 4단계 계층 구조: 책임의 분리

백엔드가 하는 역할 중 하나는 프론트엔드에게 데이터를 전달해주는 것!

1. Entity

   @Entity, @Table
   가장 깊숙한 곳, DB 안의 테이블과 1:1로 매핑되는 원본 모델이다.

   • @Id, @Column을 통해 무엇이 고유 번호(PK)인지 정의.
   • 리액트의 인터페이스 정의와 닮았지만, 훨씬 더 엄격하게 DB 구조를 대변(자바가 엄격하다)

2. Repository

   interface Repository extends JpaRepository<...>

   인터페이스인데 일단 데이터를 갖고온다.

   어디에 쓸건지는 모른다. 갖고오는 것만 정의해둔다.

   놀라운 점은, JpaRepository를 상속받는 것만으로도 스프링이 findAll, save 같은 복잡한 SQL 문장을 알아서 척척 만들어준다는 것.

3. Service

   데이터를 필요한 형태로 가공하는 곳이다.

   Null 처리 혹은 비즈니스 로직이 여기서 처리된다.

   @Transactional: 가장 인상 깊었던 안전장치인데, 여기서 일어나는 로직은 하나의 세트처럼, 만약 중간에 하나라도 실패하면? 전부 없던 일로 취소한다. (데이터의 무결성)

4. VO / DTO

   @Builder, @Getter
   서고의 원본 문서(Entity)를 손님에게 직접 보여주는 건 보안상 위험하다.

   그래서 프론트엔드에 보내기 위한 형식으로 DTO(Data Transfer Object)로 보낸다.

   @Builder를 통해 필요한 데이터만 골라 담고, @Getter로 조회할 수 있게 한다.

5. Controller

   @RestController, @GetMapping, @PostMapping

   • /api/v1/... 같은 주소를 정의하고, 요청에 따라 적절한 서비스를 호출.
   • @Schema를 통해 어떤 형태의 JSON이 오가는지 명시한다. 로직엔 영향이 없지만, 문서화 도구(Swagger)에 친절하게 표시된다!

결론

그동안 스웨거(Swagger)에서 보던 데이터가 어떠한 예외 처리와 안전장치를 거쳐 전달되는지 이해했다.
단순히 데이터를 가져오는 것을 넘어, 보호되고 가공되는 과정을 아는 것이 백엔드 공부의 핵심임을 깨달았다.