[CRM 개발일지 #1] 관리자 사용자 API 연결 및 응답 구조 개선

🚀 TODAY WORK

Backend

• 관리자 사용자 조회 API 및 권한 기반 응답 구조 정리
• ApiResponse 기반 공통 응답 스펙 구조 개선
• UserResponseDto 분리를 통한 응답 모델 계층 정리
• Spring Security 관리자 접근 권한 설정 수정

Frontend

• 관리자 사용자 페이지 API 연동
• auth / admin API 모듈 구조 정리
• 사용자 목록 데이터 연동 및 응답 구조 매핑

---

🚨 TODAY ISSUE

1. API 응답 스펙 공통화

기존에는 API 마다 응답 형식이 조금씩 달라
프론트 단에서 상태 처리 및 예외 분기 로직이 분산되는 문제가 있었다.

 

이를 개선하기 위해 ApiResponse 기반의 공통 응답 구조로 통일했다.

```json
{
"success": true,
"message": "조회 성공",
"data": {}
}

응답 스펙을 공통화하면서
프론트 단의 상태 처리 흐름도 일관성 있게 정리할 수 있었고,
추후 API 확장 시에도 동일한 응답 포맷을 유지할 수 있도록 구조를 맞췄다.

 

 

2. 응답 DTO 계층 분리

초기에는 User 엔티티를 그대로 응답으로 반환하고 있었지만,
엔티티를 직접 노출할 경우 응답 스펙 변경이 도메인 구조 변경으로 이어질 수 있어
응답 전용 DTO 계층으로 분리했다.

 

또한 불필요한 필드 노출을 방지하고
API 응답 데이터를 명확하게 제어할 수 있도록 구조를 정리했다.

 

이번 작업을 통해 다시 느낀 점은
응답 DTO는 단순 데이터 전달 객체가 아니라
API 스펙을 안정적으로 유지하기 위한 중요한 계층이라는 점이다.

 

 

3. Spring Security 권한 흐름 정리

관리자 API 접근 제어를 정리하면서
Spring Security 설정도 함께 수정했다.

 

권한 설정 이슈는 대부분 프론트에서는 단순 403 응답으로만 보이기 때문에,
실제 원인을 파악하기 위해 Security FilterChain 흐름과 URL 권한 매핑을 다시 점검했다.

 

이번 작업에서는 관리자 전용 API와 일반 사용자 API의 접근 범위를 분리하는 방향으로 구조를 정리했다.

---

⚡ TODAY TROUBLE

CodeRepository Bean 등록 오류

Consider defining a bean of type 'CodeRepository'

원인 분석

• Repository Bean 등록 누락
• MyBatis Mapper 설정 미적용
• Repository 계층과 Mapper 계층 구조 혼재

현재 공통 코드(code\_mng) 영역 구조를 정리하는 과정에서 발생한 문제이며,
내일 Repository / Mapper 역할을 명확하게 분리하면서 함께 정리할 예정이다.

---

💭 TODAY REVIEW

이번 작업에서는 단순 CRUD 구현보다
API 응답 구조와 계층 간 역할 분리에 더 집중했다.

특히 :

• 응답 스펙 공통화
• DTO 계층 분리
• Security 권한 흐름
• 프론트 응답 처리 구조

이런 부분들은 기능 구현 이후 유지보수성과 확장성에 직접적인 영향을 준다는 걸 다시 느꼈다.

 

조금씩이지만 프로젝트가 단순 기능 구현 단계에서
실제 서비스 구조 형태로 정리되어 가는 느낌이다.

---

📅 NEXT TODO

• 공통 코드(code\_mng) 구조 설계
• CodeRepository / Mapper / Service 계층 정리
• 코드 그룹 조회 API 구현
• 프론트 공통 코드 연동
• 코드 캐싱 및 재사용 구조 검토