Request 와 designatedRequest, Estimate ERD 문제 수정
첫 번째로, ERD 설계 문제가 있었습니다. 초기에는 Request와 Estimate를 같은 모델로 관리하다 보니, 하나의 고객 요청에 대해 여러 기사님의 견적을 생성할 수 없었고, 기사별 지정 견적 요청을 구분할 수도 없었습니다. 이를 해결하기 위해 데이터베이스 모델을 재설계하여 Request, DesignatedRequest, Estimate 세 가지 모델로 분리하였고, 그 결과 요청과 견적 간의 관계를 명확히 표현할 수 있었으며 확장성과 유지보수성이 크게 개선되었습니다.
서버시간과 현재시간 - date-fns를 이용해 통일
두 번째로, 시간 처리 문제가 발생하였습니다. 일부 로직은 UTC를, 또 다른 일부는 KST를 사용하면서 견적 시간이 불일치하는 문제가 있었고, 그로 인해 사용자가 내일로 입력한 이사 일정이 서버에서는 오늘 일정으로 인식되어 기사님이 견적 요청을 확인하지 못하는 오류가 발생하였습니다. 이를 해결하기 위해 date-fns를 활용하여 모든 시간 데이터를 동일한 기준으로 처리하도록 통일하였고, 덕분에 시간차로 인한 오류를 제거할 수 있었습니다.
DeepL을 미들웨어 → 유틸로 바꾸고 서비스단에 직접 사용, delay, size, cache 사용
세 번째로, DeepL API 구조 문제가 있었습니다. 초기에 번역 기능을 미들웨어에서 처리하면서 **res.json**을 비동기 함수 안에서 호출하도록 구현했는데, 이 방식은 Express가 응답이 완료되었다고 잘못 인식하거나 응답 완료 시점이 비동기적으로 지연되는 문제가 있었습니다. 이로 인해 응답이 누락되거나 불완전하게 전송되는 현상이 발생하기도 했습니다. 이를 해결하기 위해 번역 로직을 미들웨어에서 분리하여 translation.util.ts로 옮겼고, 필요한 경우 서비스 단에서 직접 호출하도록 리팩토링하였습니다. 이 과정에서 응답 흐름을 안정적으로 관리할 수 있었고, Express의 응답 구조와 충돌하던 문제를 해결할 수 있었습니다.
DeepL API 의 "429 Too Many Requests"와 같은 속도 제한 오류 발생
마지막으로, DeepL API 속도 제한(429 오류) 문제가 있었습니다. 대량의 데이터를 비동기적으로 처리하는 과정에서 속도 제한 오류가 발생하여 번역문 대신 원문이 그대로 반환되는 상황이 생겼습니다. 이를 방지하기 위해 번역 요청 사이에 delay를 적용하고, 요청 단위를 제한하는 동시에 캐시를 도입하여 동일 문장은 중복 번역하지 않도록 개선하였습니다. 이를 통해 API 호출 횟수와 비용을 줄일 수 있었으며, 안정적인 번역 기능 제공이 가능해졌습니다.