스프링 개발

깃허브에서 다른 사람들의 코드를 살펴보면 패키지 구조가 각자 다른 걸 확인 해 볼 수 있다. 프로젝트의 패키지 구조를 잘 설계하는 것은 유지보수와 확장성에 매우 중요하다. 특히, Spring과 같은 프레임워크에서 어떻게 구조화하느냐에 따라 팀원 간의 협업 효율성과 코드

내가 프론트엔드를 했을 때, 서버로부터 오는 응답 형식이 매번 다르게 와 실제 API response가 어떻게 오는지 확인하고 그에 맞춰서 수정하고 적용하며 불편함을 겪었던 경험이 있었다. 애플리케이션 개발에서 API 응답의 일관성은 매우 중요하다. API 설계 시,

전 포스팅에서 공통 응답 통일화의 주제에 대해 정리하였다면 이번에는 예외처리에 관한 포스팅을 작성하려고 한다!! 개발에서 예외 처리는 매우 중요한 요소이다. 시스템이 오류를 제대로 처리하지 않으면, 사용자 경험이 저하될 뿐만 아니라, 애플리케이션의 신뢰성도 크게 떨어

보통 데이터를 관리할 때는 데이터베이스 테이블을 사용하는 게 일반적이다. 실제로 나도 이전에 공부할 때나 저번 프로젝트에서 당연스럽게 테이블에 저장했었다. 하지만, 이번 프로젝트에서는 야구장 구역 정보를 데이터베이스 테이블이 아닌 ENUM으로 관리하였다. 그리고 요청

'플리빗'이라는 유저 취향 공유 플랫폼의 개발 완료 후 유저테스트 중 하나의 포스팅에 반응하는 부분에서 문제가 생기게 되었다.포스팅에 좋아요 표시와 같은 반응 버튼을 누르면 올라가고 내려가야하는데 동시에 많은 요청을 하거나 마우스로 빠른 속도로 클릭 시 카운트가 무한히

API 설계를 하다 보면 한 가지 고민이 생긴다. > 에러 응답 시 HttpStatus만 주면 될텐데 왜 굳이 code(커스텀 에러 코드)를 추가로 주는 걸까? > > 나도 이전 프로젝트 최종 발표 중에 이 부분에 대해 피드백을 받았고, 여러 실무 사례와 자료를 찾아보

CustomException을 통한 공통 예외 처리하기 🚨 백엔드 학습을 처음 시작할 때 위의 블로그 글과 같이 하나의 CustomException을 통해서 공통 예외처리를 진행하였다. 작년 하반기에 백엔드를 처음 시작하여 머리박치기를 하며 프로젝트 진행을 했다면

Unique 제약 조건은 데이터 무결성을 지킬 수 있게 도와준다. 나는 이전까지는 @Column(unique = true)를 필드들에 직접 주어 설정해 왔었는데 최근 새로운 unique 적용 방법을 알게되었다. 이번 글에서는 이 두 가지 방법을 비교하고, 실무에서는

이번 게시글에선 "Controller 레이어와 문서화 (Swagger / OpenAPI) 어노테이션 분리 전략"에 대해서 말하려고 한다. ✅ 왜 Interface로 따로 분리해서 쓰는가? 1️⃣ 코드 가독성/책임 분리 컨트롤러 파일에 @Operation, @Param

📌 기존 프로젝트에서 다대다 연관관계를 사용할 때 내가 어떤식으로 했었는지를 생각해보았을 때 이론 학습 없이 바로 프로젝트에 머리 박치기를 했다보니 그냥 다대다 연관관계를 막 썼던 것 같다. 최근 인프런 김영한님의 강의를 들어 ManyToMany 다대다 매핑은 하면

깃허브의 다른 사람들이 작성한 코드들을 보면 바로 알 수 있듯이, 사람마다 모두 아키텍처 설계 방법과, 코드 구조 설계는 모두 다르다. 현재 Dataracy라는 플랫폼 개발에서 나도 어떻게 설계를 해야할 지 많은 고민을 하며 계속해서 바꾸어 나가고 있다. 처음에는 C

좋은 질문입니다. 실무에서 Web DTO ↔ Application DTO, Application DTO ↔ Domain Model, Domain Model ↔ JPA Entity 변환 로직을 어디에 두는지가 구조의 품질을 좌우합니다. 아래에 각 변환 책임의 위치와 이유

1️⃣ 문제 상황: form-data로 파일 + DTO 함께 보내기 요청 예시 (Swagger나 Postman) multipart/form-data 형식으로 요청 file → MultipartFile dto → JSON 문자열 예제 Controller java 복

문제: 조건 조합 폭발, 거대 메서드, JPA -> MyBatis 전환 등 문제해법: Predicate(조건), Sort(정렬), Score(인기 점수) 등을 파일로 분리하고 어댑터에서 선언적으로 조립한다. 효과: ✨ 변경 용이 · 🧪 테스트성 · 🧩 재사용성 ·

지금 진행중인 Dataracy 프로젝트에서 기존에는 @Slf4j 애노테이션을 클래스에 붙이고 직접 log.info, log.warn과 같이 에러 로그를 직접 남겼었는데 로그 시스템을 설계하고 공통 처리를 해주는 것이 더 효율적일 것 같다는 생각이 들었다. 1. 왜 운

Dataracy 프로젝트에서는 회원가입, 비밀번호 찾기, 비밀번호 재설정 과정에서 이메일 인증을 필수로 적용한다. 회원가입 시 사용자는 6자리 인증번호를 이메일로 수신하고, 해당 코드를 입력해 검증을 통과해야 가입이 완료된다. 비밀번호를 분실했을 경우에도 동일하게 이메

프런트에서 정렬 방식, 상태 값 같은 항목은 보통 정해진 목록에서만 들어와야 한다. 하지만 HTTP 요청으로 넘어오는 건 결국 문자열이라, 컨트롤러까지 들어와서야 잘못된 값인지 알게 되는 경우가 많다. 매번 if/else로 거르다 보면 중복도 생기고, 무엇이 가능한 값

본 글은 유저 식별자를 컨트롤러에 주입하는 방식을 헤더 직접 파싱 → SecurityContext 컨트롤러마다 직접 접근 → @CurrentUserId + HandlerMethodArgumentResolver 순서로 개선해 온 과정을 정리하고, 최종 설계와 적용 효과를

1️⃣ 왜 바꿨나 (배경과 문제점) 서비스 내부 직접 검사 방식의 한계가 있었다. 각 서비스/유스케이스마다 “요청자 == 작성자?”를 직접 조회하고 비교하다 보니, 엔드포인트가 늘수록 중복 코드와 누락 위험이 증가한다. 수정/삭제/복원처럼 비슷하지만 로직 조건이

프로젝트를 진행하면서 데이터 삭제 로직을 구현할 때 고민이 많았다. "사용자가 삭제 버튼을 누르면 DB에서 완전히 지워버릴까?" 처음엔 당연히 그래야 한다고 생각했는데, 조금만 생각해보니 문제가 보이기 시작했다.우리 프로젝트는 데이터 분석 플랫폼이다. 사용자들이 데이터