Spring Boot와 Spring Data JPA

이번 실습에서는 Spring Boot와 Spring Data JPA를 사용해 간단한 Item API를 개발했다.
처음에는 Controller, Service, Repository가 각각 어떤 역할을 하는지 명확하게 이해되지 않았지만, 직접 코드를 작성하고 오류를 해결하는 과정을 반복하면서 계층 구조를 조금씩 이해할 수 있었다.

이번에 구현한 기능은 다음과 같다.

- Item 목록 조회

- Item 단건 조회

- Item 저장

전체 구조는 Controller → Service → Repository → Database 흐름으로 구성했다.
ItemController에서 클라이언트 요청을 받고, ItemService에서 비즈니스 로직을 처리한 뒤, ItemRepository를 통해 데이터베이스에 접근하도록 설계했다.

개발 과정에서는 여러 오류를 경험했다.

가장 먼저 발생한 문제는 findByItemId 메서드 오류였다.
원인을 확인해보니 Repository에 선언한 메서드 이름과 Service에서 호출한 메서드 이름이 서로 달랐다. Spring Data JPA는 메서드 이름 기반으로 동작하기 때문에 이름이 일치하지 않으면 오류가 발생한다는 점을 알게 되었고, Repository와 Service의 메서드명을 동일하게 수정하여 해결했다.

또 다른 오류는 getAllItems() 메서드 관련 문제였다.
Controller에서는 getAllItems()를 호출하고 있었지만, Service에는 해당 메서드가 정의되어 있지 않아 오류가 발생했다. 이를 해결하기 위해 Service에 getAllItems() 메서드를 추가하고, 내부에서 repository.findAll()을 호출하도록 수정했다.

Repository 관련 구조 문제도 있었다.
처음에는 Controller에서 repository.save(item)을 직접 호출하려고 했는데, Controller에는 Repository 객체가 선언되어 있지 않아 오류가 발생했다. 이 문제를 해결하는 과정에서 Controller가 Repository를 직접 사용하는 것보다 Service 계층을 통해 호출하는 구조가 더 적절하다는 점을 이해하게 되었다. 이후 저장 기능 역시 Controller → Service → Repository 흐름으로 수정했다.

Swagger 실행 과정에서도 문제가 발생했다.
Swagger 주소 자체는 맞았지만 서버가 정상적으로 실행되지 않아 접속할 수 없었다. 로그를 확인해보니 Not a managed type 오류가 발생하고 있었는데, 원인은 Item 엔티티가 Spring Boot의 기본 스캔 범위 밖에 위치해 있었기 때문이었다. 이를 해결하기 위해 Item 클래스를 com.example.spring_data_jpa.domain 패키지로 이동시키고 import 경로를 수정했다.

이후에는 8080 포트 충돌 문제도 발생했다. 이미 실행 중인 Java 프로세스가 포트를 사용하고 있었기 때문에 서버 실행이 되지 않았고, 기존 프로세스를 종료한 뒤 다시 실행하니 Swagger가 정상적으로 동작했다.

이번 실습을 통해 단순히 코드를 따라 작성하는 것보다, 직접 오류를 확인하고 해결하는 과정이 훨씬 중요하다는 것을 느꼈다.
특히 Spring Boot에서는 패키지 구조, 메서드 이름 규칙, 그리고 계층 간 역할 분리가 매우 중요하다는 점을 배울 수 있었다.