백오피스 파일 수정 디버깅 과정

1. 문제 상황

이벤트 관리 페이지에 첨부파일을 저장/삭제/수정할 수 있는 기능을 개발하고 있었다.
파일 저장과 삭제는 정상적으로 동작했지만, 수정 과정에서 문제가 발생했다.

구체적으로는, 기존에 업로드된 파일을 지운 뒤 새 파일을 저장하거나, 저장 버튼을 연속으로 클릭했을 때 이벤트 DB에 잘못된 값이 들어갔다. 특히, fileSeq 값이 0으로 업데이트되는 현상이 나타났다.

---

2. 문제 현상 재현

문제를 재현해보면 다음과 같은 흐름이었다.

1. 기존 파일을 삭제한다.
2. 새로운 파일을 추가하고 저장 버튼을 클릭한다.
3. DB에서 확인해보면 새로 저장된 파일의 fileSeq 값이 0으로 기록된다.

처음에는 단순한 UI 버그처럼 보였지만, 실제 DB 값까지 잘못 들어가는 걸 보니 로직 쪽 문제임을 확인할 수 있었다.

---

3. 원인 분석 과정

우선 클라이언트 쪽 로직을 추적했다.

디버깅 과정에서 "multipartFile is null"이라는 오류가 발생했는데, 이는 파일 업로드를 시도했지만 파일 관련 정보가 전달되지 않아 발생한 문제였다. 확인해보니 파일 업로드 객체를 생성할 때 index 값이 올바르게 매겨지지 않았고, 그 결과 input files 객체에 값이 제대로 담기지 않았다. 이 상태에서 파일 삭제와 추가가 반복되면서 index 값과 실제 파일 목록 간에 불일치가 생겼다.

그 다음 서버 응답을 살펴봤다.

• 파일 플래그가 i일 때는 정상적으로 fileList를 반환한다.
• 하지만 삭제하거나 기존과 동일한 파일을 저장할 때는 fileList 객체가 내려오지 않아 fileSeq 값이 없었다.
• 이 때문에 이벤트 테이블에 있는 fileSeq 값이 갱신되지 못하고 0으로 업데이트되는 문제가 발생했다.

즉, 클라이언트와 서버 양쪽에서 작은 오류가 겹쳐져서 발생한 문제였다.

---

4. 해결 방법

• 클라이언트 측에서는 파일 객체를 생성할 때 index가 꼬이지 않도록 로직을 수정했다.
• 서버 응답 구조도 보완해서, 삭제나 동일 파일 저장 시에도 fileSeq 값이 누락되지 않도록 처리했다.

---

5. 회고

이번 문제를 통해 배운 점은 다음과 같다.

• 파일 업로드/수정/삭제 같은 기능은 단순히 화면에서 잘 보이는지 확인하는 걸로 끝나는 게 아니라, 클라이언트-서버 간 key 값 동기화가 핵심이라는 점.
• 특히 “삭제 후 재생성”과 “기존 파일 수정”은 흐름이 다르기 때문에, 이벤트 처리 로직을 명확히 정의하지 않으면 쉽게 꼬일 수 있다.
• 디버깅할 때는 UI에서 보이는 현상뿐 아니라, 서버에서 내려오는 응답 값과 최종적으로 DB에 기록되는 데이터를 반드시 함께 확인해야 한다.