첫 저장에서 좌표 위치가 안 맞던 이유
문제 상황
도면에서 마커/결함을 생성하고 저장하면, 첫 재진입에서 위치가 틀어졌다.
이상한 점은 두 번째 수정부터는 정상 저장된다는 것이었다.
처음에는 좌표 필드(xratio, xRatio) 문제를 의심했다. 대소문자나 변환 로직이 꼬이면 위치 저장이 실패할 수 있기 때문이다.
처음 가설: 좌표 포맷 문제
요청 payload를 먼저 확인했다. 저장 시점의 좌표 값 자체는 정상으로 보였다.
- 저장 요청에 좌표 값은 들어간다
- 값 범위도 비정상적이지 않다
- 첫 저장 실패/두 번째 성공 패턴이 좌표 계산 버그와는 잘 맞지 않는다
이 단계에서 "좌표 계산"보다 "저장 순서와 상태 전이" 쪽을 의심해야 했다.
네트워크에서 본 실제 흐름
네트워크 탭을 확인하니 저장 시 다음 요청만 호출됐다.
POST /markersPUT /markers/{id}/position
반면, 결함그룹 위치를 갱신하는 API는 첫 저장 시점에 호출되지 않았다.
즉, 마커 위치는 갱신되지만 결함그룹 위치는 갱신되지 않아 화면 재진입 시 어긋난 상태가 만들어졌다.
핵심 원인: 좌표가 아니라 ID 라이프사이클
콘솔 상태를 비교하니 원인이 명확했다.
- 첫 생성 직후:
defectGroupId = -1(임시 ID) - 재진입 후:
defectGroupId = 실제 ID
첫 저장 시점에는 결함그룹의 실제 ID가 아직 없어서, 결함그룹 위치 수정 API를 호출할 수 없었다.
결론은 좌표 계산 문제가 아니라 tempId -> realId 매핑 누락이었다.
해결 방법
백엔드와 계약을 맞춰 POST /markers 응답에 defectGroupId를 포함하도록 수정했다.
그리고 저장 흐름을 다음 순서로 고정했다.
- 마커 생성 (
POST /markers) - 응답에서 실제 ID 확보 (
markerId,defectGroupId) - 마커 위치 수정 (
PUT /markers/{id}/position) - 결함그룹 위치 수정 (group position API)
핵심은 "값을 먼저 계산"이 아니라 "식별자를 먼저 확정"이다.
실무에서 얻은 교훈
프론트 저장 버그는 좌표/포맷 같은 값 문제로 보일 때가 많다.
하지만 실제로는 ID 생성 시점, 임시 ID, 응답 매핑, 후속 API 호출 조건 같은 라이프사이클 이슈가 더 자주 원인이 된다.
특히 아래 체크리스트는 재발 방지에 효과가 있었다.
- 생성 API 응답에 후속 작업에 필요한 ID가 모두 포함되는가?
tempId를 쓰는 동안 어떤 API가 호출 불가능한가?- "첫 저장만 실패" 패턴이 있으면 상태 전이(초기 생성 -> 실제 ID 반영)를 먼저 의심했는가?
정리
이번 이슈의 포인트는 단순하다.
- 틀린 가설: 좌표 포맷 문제
- 실제 원인:
tempId -> realId매핑 누락 - 해결 방식: ID 확보 이후 위치 수정 API 체인 실행
앞으로 비슷한 버그를 보면, 값 포맷보다 ID 라이프사이클부터 확인할 것이다.