일정 관리 앱 Develop_트러블 슈팅

과제 트러블 슈팅

 

문제 상황

일정 생성 API를 완성하고 Postman으로 테스트했지만 500 Internal Server Error가 발생했다.

문제 원인

코드에서 @EntityListeners 어노테이션이 잘못된 클래스를 참조하고 있었다.

잘못된 코드

@EntityListeners(EntityListener.class)

• 이로 인해 EntityListener가 제대로 동작하지 않아 오류가 발생했다.

해결 방법

@EntityListeners 어노테이션을 올바른 클래스인 AuditingEntityListener로 수정했다.

수정된 코드

@EntityListeners(AuditingEntityListener.class)

수정 후 Postman으로 다시 요청을 보냈고, 정상적으로 일정이 생성되었다.

결론

코드를 작성할 때 어노테이션이 참조하는 클래스가 올바른지 확인해야 한다는 점을 배웠다.
Spring JPA와 같은 프레임워크의 기능을 사용할 때는 관련 문서를 참고하여 정확히 이해하고 적용하는 것이 중요하다는 것을 깨달았다.

---

문제 상황

일정 수정 API를 구현한 후 Postman으로 요청을 보냈지만, 수정 후 다시 선택 일정 조회를 했을 때 내용이 바뀌지 않았다.

문제 원인

@Transactional 어노테이션을 사용하지 않아 트랜잭션이 적용되지 않는 문제가 발생했다.

• 데이터베이스에서 수정 작업이 제대로 반영되지 않았고, 수정 전의 데이터가 그대로 유지되었다.

해결 방법

@Transactional 어노테이션을 수정 메서드에 추가하여 트랜잭션 처리를 활성화했다.

• Postman으로 다시 요청을 보낸 후, 수정된 내용이 정상적으로 반영되었다.

결론

Spring에서 데이터 변경 작업에는 @Transactional 어노테이션을 활용해야 한다는 것을 배웠다.
트랜잭션은 데이터의 일관성을 보장하는 중요한 기능이며, 이를 통해 수정 작업이 데이터베이스에 올바르게 반영되도록 해야 한다는 점을 깨달았다.

---

문제 상황

일정 조회 시 멤버 정보도 함께 반환되도록 구현했으나, 전체 정보가 반환되면서 작성일과 비밀번호까지 노출되는 문제가 발생했다.

문제 원인

멤버 정보를 반환할 때, DTO(Data Transfer Object)를 사용하지 않고 Entity를 그대로 반환하면서 불필요한 정보가 함께 노출되었다.
Entity는 데이터베이스와 직접적으로 연결된 객체로, 민감한 정보를 포함할 가능성이 크다.

해결 방법

• MemberResponseDto를 만들어서 필요한 값만 반환하도록 수정했다.

{
    "id": 1,
    "title": "할일 제목",
    "contents": "할일 내용",
    "member": {
        "id": 1,
        "username": "회원 이름1",
        "email": "tmvkfmxk@email.com"
    }
}

• 일정 조회 시 MemberResponseDto를 사용해서 유저 정보를 반환하도록 구현했다.

결론

API에서 민감한 정보가 노출되지 않도록 DTO를 사용해 필요한 데이터만 전달하는 것이 중요하다는 것을 배웠다.
엔티티를 그대로 반환하면 보안 문제가 발생할 수 있으므로, 항상 DTO를 활용하여 데이터를 제어해야 한다는 점을 깨달았다.

---

문제 상황

구현한 코드를 튜터님께 확인받았는데, 불필요한 코드가 많다는 피드백을 받았다.
특히, 서비스에서 이미 로그인 처리를 완료했음에도 컨트롤러에서 다시 아이디를 반환받고, 이를 이용해 회원을 찾는 복잡한 로직이 문제로 지적되었다.

문제 원인

서비스 계층에서 로그인 처리가 완료되면 해당 작업이 끝나야 하지만,

• 컨트롤러에서 불필요하게 추가적인 로직(아이디 반환, 회원 재조회 등)을 수행하고 있었다.
• 이러한 구조는 코드가 지나치게 복잡해지고, 관심사 분리가 제대로 이루어지지 않은 상태였다.

해결 방법

컨트롤러, 서비스, 레포지토리 계층의 역할을 재구성하여 불필요한 작업을 제거하고,

• 서비스에서 로그인 처리 완료 시 필요한 데이터만 반환하도록 수정했다.
• 컨트롤러는 서비스에서 반환한 데이터를 그대로 클라이언트에 전달하는 역할로 단순화했다.
• 최종적으로 간결하고 효율적으로 작동하는 구조로 변경했다.

결론

간결하고 효율적인 코드 설계의 중요성을 깨달았다.
불필요한 로직은 코드 가독성을 떨어뜨리고 유지보수를 어렵게 만든다는 점을 경험했다.
각 계층의 역할을 명확히 나누고, 단일 책임 원칙에 따라 설계하는 것이 중요하다는 것을 배웠다.

---

문제 상황

댓글 생성 API 완성 후 Postman으로 실행했지만 NullPointException이 발생했다.

문제 원인

에러 메시지를 확인한 결과, comment.getMember( ) 호출 시 멤버 객체가 null인 상태였다.

• 코드를 다시 살펴본 결과, 회원 정보와 일정 정보가 등록되지 않은 상태에서 댓글을 생성하려고 했던 것이 원인이었다.
• 댓글을 생성하기 위해 필요한 유저(Member)과 일정(Todo)이 설정되지 않은 상태였다.

해결 방법

• 회원(Member)과 일정(Todo) 정보 등록
  • 댓글 생성 이전에, 회원과 일정 정보를 적절히 설정하고 데이터베이스에 저장했다.
• 댓글 생성 시, 등록된 회원과 일정 정보를 매핑하여 제대로 작동하도록 코드를 수정했다.
• Postman으로 테스트했을 때 정상적으로 댓글이 생성되었다.

결론

API를 구현할 때 필수적인 데이터가 제대로 설정되었는지 확인하는 습관이 중요하다는 것을 배웠다.
댓글과 같은 연관 관계가 많은 Entity에서는 데이터의 생성 순서와 의존성을 꼼꼼히 관리해야 한다는 점을 깨달았다.
에러 메시지를 잘 분석하면 문제를 해결하는 데 큰 도움이 된다는 점도 다시 한 번 경험했다.

---

문제 상황

유저를 생성한 후 일정과 댓글을 생성하고, 유저를 삭제하려고 시도했으나 SQLIntegrityConstraintViolationException이 발생했다.

문제 원인

유저와 일정 및 댓글 간의 외래키 참조 제약 조건으로 인해 문제가 발생했다.

• 유저를 삭제하려고 할 때, 해당 유저가 일정 및 댓글과 연관되어 있어 데이터 무결성을 위반했다는 의미다.

해결 방법

두 가지 방법 중 하나를 선택하여 해결 가능

1. Soft Delete
   • 유저 데이터를 완전히 삭제하지 않고, 삭제 여부를 나타내는 필드를 추가해 소프트 삭제 구현.
   • 연관된 데이터 무결성을 유지하면서 삭제된 것처럼 동작할 수 있음.
2. Hard Delete
   • 유저 삭제 시 관련 일정 및 댓글을 Cascade 옵션으로 함께 삭제하거나, 외래키 관계를 수동으로 해제 후 삭제.

현재 시간 부족으로 과제 제출 후 추가적으로 구현할 예정.

결론

데이터 간의 연관 관계(외래키 참조)를 설정할 때 삭제와 관련된 전략(Soft Delete vs. Hard Delete)을 사전에 고민해야 한다는 점을 배웠다.
삭제 처리 방식을 명확히 정의하고, 데이터 무결성과 사용 사례에 맞는 설계를 적용하는 것이 중요하다는 것을 깨달았다.
과제 이후, 적절한 삭제 전략을 선택하고 이를 구현할 계획이다.