[내일배움캠프] - DAY15 일정관리 앱 만들기

프로젝트 목표

이번 시간에는 Spring Boot와 JPA를 활용하여 일정을 관리하는 앱을 만들어볼려고 합니다. 일정 관리앱에는 일정을 생성(Create) / 조회(Read) / 수정(Update) / 삭제(Delete) 할 수 있는 REST API 서버를 구현할 예정입니다.

---

1. Entity 설계

일정 데이터를 데이터베이스에 저장하기 위해 ScheduleEntity를 설계하였습니다. 각 일정은 고유 식별자(ID)를 가지며, 제목/내용/작성자/비밀번호/생성일/수정일 정보를 포함합니다.

 

요구 사항 

• 일정 제목
• 일정 내용
• 작성자명
• 비밀번호
• 생성일/수정일
• ID 자동 생성
• 수정일 자동 갱신

 

---

2. DTO 분리 설계

요구사항에서 API응답에 비밀번호를 제외해야한다고 하여 Entity를 직접 반환하지 않고 DTO를 사용하여 아래와 같이 Request DTO와 Response DTO로 나누었습니다.

 

 

Request DTO

• 생성 요청: CreateScheduleRequest
• 수정 요청: UpdateScheduleRequest
• 삭제 요청: DeleteScheduleRequest (password 포함)

 

Response DTO

• password 필드 제외

---

3. Service 계층 구현

비즈니스 로직은 Service에서 처리하도록 설계하였습니다.

 

일정 생성

 

일정 생성 기능은 @Transactional을 사용하여 데이터 저장 과정이 하나의 트랜잭션으로 처리되도록 구현했습니다.

클라이언트로부터 전달받은 CreateScheduleRequest DTO의 값을 이용해 ScheduleEntity 객체를 생성한 뒤, repository.save()를 통해 데이터베이스에 저장합니다. 저장이 완료되면, 저장된 엔티티의 ID와 주요 정보들을 CreateScheduleResponse DTO로 변환하여 반환함으로써 클라이언트가 생성된 일정 정보를 즉시 확인할 수 있도록 구성했습니다. 즉, 요청 DTO → Entity 변환 → DB 저장 → Response DTO 반환 흐름으로 동작합니다.

 

일정 조회

 

조회 기능은 데이터 변경이 발생하지 않기 때문에 @Transactional(readOnly = true) 옵션을 적용하여 성능을 최적화했습니다. 작성자(author) 값이 전달된 경우에는 findAllByAuthorOrderByUpdatedAtDesc()를 사용하여 특정 작성자의 일정만 최신 수정순으로 조회하고, 작성자 값이 없는 경우에는 findAllByOrderByUpdatedAtDesc()를 호출하여 전체 일정을 최신순으로 조회하도록 분기 처리했습니다. 조회된 엔티티 리스트는 stream()을 활용해 GetOneScheduleResponse DTO로 변환 후 반환하여, 엔티티를 직접 노출하지 않고 필요한 데이터만 전달하도록 설계했습니다. 즉, 조건 분기 → 목록 조회 → DTO 변환 → 반환 구조입니다.

 

일정 수정

 

수정 기능 또한 데이터 변경이 발생하므로 @Transactional을 적용했습니다. 먼저 repository.findById()를 통해 수정할 일정을 조회하고, 존재하지 않는 경우 예외를 발생시켜 잘못된 접근을 방지했습니다. 이후, 일정 생성 시 저장해두었던 비밀번호와 요청 값의 비밀번호를 비교하여 작성자 본인 여부를 검증합니다. 비밀번호가 일치하지 않으면 수정이 불가능하도록 예외를 발생시킵니다. 검증이 완료되면 엔티티의 update() 메서드를 호출하여 값을 변경하고, 수정된 결과를 UpdateScheduleResponse DTO로 반환합니다. 즉, 조회 → 비밀번호 검증 → 값 변경 → 결과 반환
흐름으로 동작합니다.

 

일정 삭제

 

삭제 기능 역시 데이터 변경 작업이므로 @Transactional을 적용했습니다. 먼저 ID를 통해 삭제할 일정을 조회하고, 존재하지 않을 경우 예외를 발생시킵니다. 수정 기능과 동일하게 비밀번호 검증을 통해 작성자 본인만 삭제 가능하도록 보안 로직을 추가했습니다. 비밀번호가 일치하면 repository.delete()를 호출하여 해당 엔티티를 데이터베이스에서 제거합니다. 삭제 성공 시 별도의 데이터를 반환하지 않으며, HTTP 204 No Content 응답으로 처리됩니다. 즉, 조회 → 비밀번호 검증 → 삭제 수행 구조입니다.

---

4. API 테스트

POST

 

POST 요청 후 응답 상태 코드로 201 Created가 반환되는 것을 확인할 수 있습니다. 이는 일정이 정상적으로 생성되었음을 의미하며, 실제로 데이터베이스 테이블에서도 요청한 데이터가 저장된 것을 확인할 수 있습니다.

 

GET

 

GET 요청 시 응답 상태 코드 200 OK가 반환되며, 요청이 정상적으로 처리되었음을 확인할 수 있습니다. 생성된 일정 데이터는 리스트(List) 형태로 반환되며, 특정 작성자(ex: "이지천")를 기준으로 해당 작성자가 등록한 모든 일정을 조회할 수 있습니다.

 

PUT

 

PUT 요청 시에는 일정 수정을 위해 비밀번호 검증이 필요하므로, 요청 Body에 password 값을 함께 포함하여 전송합니다. 요청을 보내면 위 화면과 같이 200 OK 응답이 반환되며, 이는 수정이 정상적으로 처리되었음을 의미합니다.

이후 다시 조회(GET)를 수행하면, 아래 화면처럼 변경된 내용이 정상적으로 반영된 것을 확인할 수 있습니다.

 

 

DELETE

 

DELETE 요청 역시 PUT과 동일하게 비밀번호 검증을 위해 요청 Body에 password 값을 포함하여 전송합니다. 요청이 정상적으로 처리되면 위 화면과 같이 204 No Content 응답이 반환되며, 이는 데이터가 성공적으로 삭제되었음을 의미합니다. 이후 다시 GET 요청을 수행하면, 아래 화면처럼 해당 일정이 더 이상 조회되지 않는 것을 통해 삭제가 정상적으로 완료된 것을 확인할 수 있습니다.

---

5. 트러블 슈팅

 

5-1. 일정 수정/삭제 시 보안 검증 필요성

 

문제

초기 구현에서는 문제 요구와 다르게 비밀번호 검증 없이 누구나 다른 작성자의 일정을 수정/삭제가 가능했습니다.

 

원인

작성자 인증 로직이 존재하지 않아 ID만 알고있어도 다른 작성자가 생성한 일정을 변경할 수 있었습니다.

 

해결

Service 계층에서 비밀번호 비교로직을 추가하여 검증을 통해 인증된 사용자만 일정 수정/삭제가 가능하도록 하였습니다.

 

 

이번 트러블 슈팅을 통해 배운점

단순 CRUD라도 비즈니스 로직(Service)에서 권한 검증이 반드시 필요하다는것을 배웠습니다.

 

5-2. 조회 성능 최적화 필요성

 

문제

조회 API에서도 기본 @Transactional 을 사용하고 있었습니다.

 

원인

읽기 전용 작업인데도 쓰기 트랜잭션이 생성되어 불필요한 오버헤드가 발생하였습니다.

 

해결

조회 메서드에 readOnly = true 옵션을 추가하여 문제를 해결하였습니다.

 

 

이번 트러블 슈팅을 통해 배운점

조회는 readOnly 옵션을 통해 성능 최적화 및 변경 방지 효과를 얻을 수 있다는 것을 배웠습니다.

---