Refactor[API]: axios 기반 API 구조 리팩터링

[MatchaKim]

수정 사유 Reason for modification

소스를 수정한 사유가 무엇인지 체크해 주세요. Please check the reason you modified the source. ([X] X는 대문자여야 합니다.)

• 버그수정 Bug fixes
• 기능개선 Enhancements
• 기능추가 Adding features
• 기타 Others

수정된 소스 내용 Modified source

검토자를 위해 수정된 소스 내용을 설명해 주세요. Please describe the modified source for reviewers.

기존 fetch 기반에서 Axios로 전환하기 위해 일부 컴포넌트를 우선 리팩터링하였습니다.

컴포넌트 내부의 Server 로직과 UI 로직을 분리하기 위해 API 모듈을 정의하였으며,
src/api/services/{컴포넌트명} 경로에 컴포넌트명과 동일한 이름으로 구성하여 구조적 일관성을 유지했습니다.

Axios 도입으로 얻은 이점은 다음과 같습니다.

1. Interceptor 분리
   모든 API 요청에서 중복되는 Auth, Error 처리를 interceptor에서 일관적으로 제어할 수 있습니다.

2. 자동 JSON 파싱
   fetch는 await res.json() 호출이 필요하지만, Axios는 response.data로 바로 접근 가능합니다.

3. 쿼리 파라미터 직렬화 편의성
   params 옵션으로 객체를 전달해 직관적이고 간단하게 관리할 수 있습니다.

   axios.get('/user', { params: { id: 123, role: 'admin' } })
   // => /user?id=123&role=admin
   

JUnit 테스트 JUnit tests

테스트를 완료하셨으면 다음 항목에 [대문자X]로 표시해 주세요. When you're done testing, check the following items.

• [] JUnit 테스트 JUnit tests
• 수동 테스트 Manual testing

테스트 브라우저 Test Browser

테스트를 진행한 브라우저를 선택해 주세요. Please select the browser(s) you ran the test on. (다중 선택 가능 you can select multiple) [X] X는 대문자여야 합니다.

• Chrome
• Firefox
• Edge
• Safari
• Opera
• Internet Explorer
• 기타 Others

테스트 스크린샷 또는 캡처 영상 Test screenshots or captured video

테스트 전과 후의 스크린샷 또는 캡처 영상을 이곳에 첨부해 주세요. Please attach screenshots or video captures of your before and after tests here.

[eGovFrameSupport]

표준프레임워크에 대한 지속적인 참여에 대단히 감사드립니다.
다만 fetch → axios 전환이라는 본 PR의 핵심은 아래 사유로 수용하기 어렵다고 판단했습니다.

1. 현재 상태로는 빌드가 되지 않습니다.

공통 래퍼인 src/api/egovFetch.jsx를 삭제하셨는데, 이를 import * as EgovNet from "@/api/egovFetch" 로 사용하는 파일이
28개 남아 있습니다. 전환된 컴포넌트는 4개(Header / AdminBoardList / LoginContent / Main)뿐이라, 나머지 28개가 의존하던
모듈이 사라져 번들러가 모듈을 해석하지 못합니다. 부분 전환 과정에서 공통 기반을 먼저 제거한 형태라 앱이 기동되지
않습니다.

2. axios 도입을 정당화할 기술적 우위가 없습니다.

말씀해 주신 이점(Interceptor를 통한 Auth/Error 일원화, 자동 JSON 파싱, 쿼리 직렬화)은 모두 삭제 대상인 egovFetch 래퍼
안에서, 또는 네이티브 API로 이미 달성 가능합니다. egovFetch가 본래 요청/에러 처리를 중앙화하던 래퍼이고, JSON 파싱은
래퍼 1줄 캡슐화, 쿼리 직렬화는 URLSearchParams로 해결됩니다. 현행 fetch 기반이 정상 동작하는 상황에서 의존성을 추가해
대체할 근거로는 "편의성" 이상이 보이지 않습니다.

이상의 이유로 본 PR은 close 하겠습니다.