일정 관리 앱 과제_트러블 슈팅

과제 트러블 슈팅

 

문제 상황

IntelliJ에서 코드를 작성하는 중, import를 수행할 때 코드의 맨 위로 추가되지 않고 작성 중인 해당 줄에 import문이 추가되는 문제가 발생했다.

문제 원인

문제의 정확한 원인은 파악하지 못했다.
하지만 import 시도 시 IntelliJ 우측 하단에 IDE Error 메시지가 지속적으로 나타난 것을 보아 IntelliJ 자체의 문제로 판단했다.
여러 플러그인을 설치하는 과정에서 설정이 꼬였거나 잘못된 변경이 이루어진 것으로 생각하고 있다.

해결 방법

• 튜터님과 함께 다양한 시도
  • IntelliJ 설정 변경
  • 캐시 삭제
• 그러나 여러 방법을 시도해도 여전치 IDE Error 메시지가 발생하여 문제를 해결하지 못했다.
• 최종 해결
  • IntelliJ를 완전히 삭제한 후 재설치 진행
  • 재설치 후 기본 상태를 유지하며, 꼭 필요한 플러그인만 설치

결론

IntelliJ를 재설치한 후 문제 없이 정상 작동하는 것을 확인했다.
앞으로 플러그인을 설치할 때 신중하게 선택하고, 불필요한 변경을 최소화해서 IDE의 안정성을 유지해야겠다고 생각했다.

---

문제 상황

과제의 요구사항에서는 비밀번호를 반환하지 않아야 한다고 작성되어 있지만, 일정을 생성할 때 비밀번호가 함께 반환되는 문제가 발생했다.

문제 원인

TodoResponseDto 클래스는 데이터를 반환하는 역할을 담당하는데, 강의 실습 코드를 참고하여 코드를 작성하는 과정에서 모든 데이터를 반환하도록 설정했다.
결과적으로 password 필드도 함께 반환값에 포함되면서 문제가 발생했다.

문제 코드

public TodoResponseDto(Todo todo) {
    this.id = todo.getId();
    this.title = todo.getTitle();
    this.content = todo.getContent();
    this.writer = todo.getWriter();
    this.password = todo.getPassword();
    this.created_date = todo.getCreated_date();
    this.updated_date = todo.getUpdated_date();
}

해결 방법

password 필드를 반환하지 않도록 코드를 수정했다.

public TodoResponseDto(Todo todo) {
    this.id = todo.getId();
    this.title = todo.getTitle();
    this.content = todo.getContent();
    this.writer = todo.getWriter();
    this.created_date = todo.getCreated_date();
    this.updated_date = todo.getUpdated_date();
}

수정 후 비밀번호가 더 이상 반환되지 않았고 과제 요구사항을 충족할 수 있었다.

결론

강의 코드를 참고하여 작성하는 것은 효율적이지만 요구사항에 따라 적절히 수정하고 활용하는 것이 더 중요하다는 것을 배웠다.
복사-붙여넣기만으로는 문제가 생길 수 있기 때문에 코드를 작성할 때 상황에 맞는 변경과 판단 능력이 필요함을 깨달았다.

---

문제 상황

강의 실습 코드를 참고하며 TodoScheduleService와 TodoScheduleController를 작성하던 중에 두 클래스에서 의존성을 주입받는 필드 객체가 잘못 설정되어 있는 것을 발견했다.

문제 원인

Interface를 주입받아야 하는데 구현 클래스를 직접 주입받고 있었다.
이것은 DI(Dependency Injection) 원칙에 어긋나는 코드로, 추후 확장성 및 유지보수에 문제가 발생할 수 있다.

문제 코드

// TodoScheduleService
private final TodoScheduleRepository todoScheduleRepository;

// TodoScheduleController
private final TodoScheduleService todoScheduleService;

해결 방법

의존성 주입 시, Interface를 주입받을 수 있도록 코드를 수정했다.
이렇게 하면 추후 구현체 변경이 필요한 경우에도 유연하게 대처할 수 있다.

// TodoScheduleService
private final TodoRepository todoRepository;

// TodoScheduleController
private final TodoService todoService;

수정 후 의존성 주입 원칙에 맞게 Interface를 주입받도록 개선되었다.

결론

코드를 작성할 때는 import하는 대상이 올바른지와 주입받아야 할 객체의 역할을 정황히 이해하고 작성해야 한다는 것을 배웠다.
DI 원칙을 준수하면 코드를 좀 더 유연하고 유지보수 가능하도록 만들 수 있다는 점도 깨달았다.

---

문제 상황

과제의 요구사항에서는 수정일과 작성자명을 기반으로 일정 목록을 모두 조회해야 했다.
처음에는 수정일로 조회할 때 SQL의 LIKE 연산자를 사용하면 될 것이라고 생각하고 코드를 작성했지만 데이터를 조회할 수 없었다.
작성자명만 사용하여 조회했을 때는 정상적으로 데이터가 반환되었다.

문제 원인

LIKE를 사용할 때 날짜를 조회하려면 "YYYY-MM-DD%" 형식으로 입력값을 전달해야 하지만, "YYYY-MM-DD" 형식으로 조회를 시도했다.
이로 인해 수정일의 시간 정보까지 일치하지 않아 조회 결과가 반환되지 않았다.

해결 방법

입력값에 % 와일드카드를 추가하여 "YYYY-MM-DD%" 형식으로 수정했다.
수정 후, 수정일을 기준으로 일정 목록이 정상적으로 조회되는 것을 확인했다.

결론

SQL을 사용할 때 LIKE 연산자를 올바르게 활용하려면 입력값의 형식과 패턴을 정확히 이해해야 한다는 것을 배웠다.
날짜와 시간 데이터를 다룰 때는 포맷에 주의하고, 쿼리를 작성할 때 예상 결과와 비교하며 확인하는 습관이 중요하다는 점을 깨달았다.

 

---

문제 상황

수정일을 조건으로 일정 목록을 조회하려고 했으나, 조건을 추가해도 데이터베이스에 저장된 모든 일정이 조회되는 문제가 발생했다.
작성자명 조건을 함께 추가하면 정확히 조건에 맞는 일정이 반환되었다.
이 문제는 수정일 조건만 사용할 경우에 발생했다.

문제 원인

LIKE "YYYY-MM-DD%" 방식으로 수정일 조건을 작성했지만 updated_date 필드가 날짜와 시간을 포함하고 있어서 입력값이 정확히 매칭되지 않았다. 수정일 조건이 제대로 작동하지 않아서 전체 데이터가 반환되었다.

해결 방법

LIKE 대신 DATE(updated_date) 함수를 사용하여 updated_date 필드의 날짜 부분만 비교하도록 SQL 쿼리를 수정했다.
수정 후 조건에 맞는 일정만 정상적으로 조회되었다.

결론

코드에는 정답이 없기 때문에 문제를 해결할 때 한 가지 방법만 고집하지 않고 다양한 접근법을 시도하는 것이 중요하다는 점을 배웠다.
데이터베이스 작업에서는 쿼리 작성 시 데이터 타입과 함수 활용에 유의해야 하며, 상황에 따라 더 적합한 방법을 선택할 수 있어야 한다는 점을 깨달았다.

---

문제 상황

선택한 일정을 수정하는 기능을 구현하고 Postman을 이용해 API를 호출했지만 계속 404 NOT_FOUND 응답이 반환되었다.
이로 인해 일정을 수정할 수 없었다.

문제 원인

데이터베이스에 저장된 값을 확인한 결과, 비밀번호 필드에 작성자명이 저장되어 있었다.
일정을 저장하는 코드에서 비밀번호를 잘못 처리한 로직으로 인해 발생한 문제였다.
수정 시 입력된 비밀번호와 데이터베이스의 비밀번호가 일치하지 않아서 조건에 맞는 일정을 찾을 수 없었고 404 NOT_FOUND가 반환되었다.

해결 방법

일정을 저장하는 코드를 수정하여 비밀번호가 정상적으로 저장될 수 있게 했다.
코드를 수정한 후, Postman을 이용해 다시 요청을 보냈더니 정상적으로 일정이 수정되었다.

결론

코드를 작성한 후에는 반드시 세부 로직과 데이터 흐름을 꼼꼼히 검토해야 한다는 것을 배웠다.
데이터베이스에 저장되는 값을 확인하고, 입력값과 저장된 값의 일치를 신중하게 검토해야 한다는 점을 배웠다.