1. @RestController란?`@Controller` + `@ResponseBody`를 결합한 어노테이션View가 아닌 HTTP 응답 본문으로 객체를 직접 반환주로 RESTful API, JSON 응답에 사용 내부 동작 과정HTTP 요청이 들어오면, 내부적으로는 다음과 같은 흐름으로 처리된다.클라이언트 → `DispatcherServlet``HandlerMapping`: 요청 URI에 맞는 Controller 탐색`HandlerAdapter`: 실행 준비 및 핸들러 호출`ArgumentResolver`: 요청 파라미터 처리@RequestBody, @RequestParam, @ModelAttribute 등을 보고 요청 데이터를 Java 객체로 변환@RequestBody, HttpEntity인 경우 ..

최근 멘토님께 코드 리뷰를 받던 중, 다음과 같은 피드백을 받았다.❝ catch에서는 IOException ClassNotFoundException으로 잡고, 예외를 던지는 부분에서 RuntimeException으로 던지는데, 이런 경우, 정보전달이 제대로 되지 않습니다. 그래서 throw new RuntimeExceptino 보다는 throw new IOException | throw new ClassNotFoundException이 더 정확한 예외 처리 입니다.❞솔직히 `IOException`, `ClassNotFoundException`을 그대로 던지면 Repository → Service → Controller까지 전부 `throws`를 선언해야 해서 번거롭다고 생각했다.그래서 난 그냥 `Runt..

최근 멘토님께 코드 리뷰를 받던 중, 다음과 같은피드백을 받았다.“이렇게 생성자를 정의하는 것도 좋은 방법이지만, Lombok에서 제공하는 @RequiredArgsConstructor 어노테이션을 사용하는 것이 좀 더 좋고, 실무에서도 이 방식을 더 많이 선호합니다.”사실 그동안은 생성자를 직접 정의하는 게 더 명시적이고 안전하다고 생각했다.하지만 이 피드백을 계기로 왜 실무에서는 `@RequiredArgsConstructor`를 더 선호하는지, 어떤 경우에 사용하는 것이 더 적절한지 정리해보게 되었다.✨ 예제 코드로 보는 비교아래는 내가 작성했던 기존 코드이다:@RestController@RequestMapping("/v1/login")public class AuthController { priv..

최근 멘토님께서 코드 리뷰 중 아래와 같은 피드백을 주셨다.“이런 경우엔 `@AllArgsConstructor`보다는 `@RequiredArgsConstructor`가 더 적합합니다.”사실 그동안 나는 DTO 클래스에서 습관처럼 `@AllArgsConstructor`를 사용해왔기 때문에, 왜 그런지 한 번도 고민해보지 않았다. 그래서 이번 기회에 Lombok의 두 생성자 어노테이션의 차이와 언제 어떤 것을 사용해야 하는지 정리해보게 되었다.🔍 TL;DR — 결론부터 말하자면`@RequiredArgsConstructor`는 의무적으로 필요한 필드만 생성자에 포함시키기 때문에,불변성 유지와 의도 명확화 측면에서 DTO에 더 적합한 선택이다.👉 `@NotNull`, `final` 필드만 생성자 파라미터로 ..

📌 IntroSpring에서는 웹 요청을 처리하기 위해 @Controller, @RestController와 같은 어노테이션을 사용한다.이번 글에서는 이 두 어노테이션의 차이를 이해하기 위해 Spring MVC의 핵심 구조를 먼저 살펴보고, 그 위에서 각 어노테이션의 처리 흐름과 용도를 비교해보자. 1. Spring MVC 구조의 핵심: DispatcherServletSpring MVC는 다음과 같은 프론트 컨트롤러 패턴(Front Controller Pattern)을 따른다.더보기여기서 프론트 컨트롤러 패턴은 사용자의 모든 요청을 한 곳(중앙 컨트롤러)에서 먼저 받아서, 이후 어떤 로직(컨트롤러, 서비스 등)으로 넘길지를 결정하는 방식을 의미한다.이 패턴에서 모든 요청은 중앙 진입점인 `Dispatc..

📌 Intro객체지향 프로그래밍(OOP)은 역할과 책임을 기준으로 코드를 잘게 나눠 설계할 수 있게 해준다.하지만 실제 애플리케이션에서는 핵심 로직 외에도 다음과 같은 공통 기능이 자주 등장한다.로깅(logging)트랜잭션(transaction) 처리보안(security) 검사성능 측정예외 처리이러한 기능들은 비즈니스 로직과 직접적인 관련은 없지만,여러 클래스에 걸쳐 반복적으로 사용되며 시스템 전체에 영향을 준다.→ 이처럼 가로지르는 관심사를 "횡단 관심사(Cross-cutting concern)" 라고 한다.❗ 문제는?OOP만으로 이 모든 관심사를 해결하려고 하면 다음과 같은 문제가 발생한다:로깅/보안/트랜잭션 코드를 모든 클래스에 직접 작성해야 한다비즈니스 로직이 공통 코드에 의해 오염되어 가독성..

Component Scan vs Java Config vs XML 설정📌 IntroSpring Boot에서는 다양한 방식으로 Bean(빈)을 등록하여 객체를 스프링 컨테이너에서 관리할 수 있다.이번 글에서는 Spring에서 자주 사용되는 3가지 Bean 등록 방식을 비교하고,각 방식의 장단점과 사용 용도를 정리해보고자 한다.잠깐! Bean이란?Bean이란, Spring 컨테이너가 생성하고 관리하는 객체를 의미한다.개발자가 만든 클래스가 Spring의 생명주기를 따라야 할 때, Bean으로 등록해야 한다.즉, Spring이 직접 관리하게 만들려면 Bean으로 등록해야 한다. Bean 등록 vs Bean 주입 (이건 헷갈리면 안 된다!)구분설명예시 애노테이션Bean 등록Spring 컨테이너에 객체를 등록하..

📌 Intro웹 서비스 아키텍처를 이해하려면 꼭 구분해야 할 개념이 있다.바로 웹 서버(Web Server)와 WAS(Web Application Server)다.이번 글에서는두 개념의 차이를 명확히 정리하고Spring Boot의 내장 Tomcat은 어디에 속하는지도 함께 살펴보려고 한다.📌 웹 서버 vs WAS 개념 먼저 정리하기구분웹 서버 (Web Server)WAS (Web Application Server)정의정적인 콘텐츠(HTML, CSS, 이미지 등)를 클라이언트에게 제공동적인 콘텐츠(애플리케이션 실행 결과)를 생성하고 제공역할클라이언트 요청 수신 → 정적 파일 찾아 응답요청 처리 → 비즈니스 로직 실행 → DB 연동 후 결과 반환주 사용 기술Apache, Nginx, IISTomcat, ..

복잡한 EJB 시대를 넘어, 가볍고 유연한 대안을 찾다📌 Intro오늘날 많은 기업과 개발자들이 사용하는 Spring Framework.그 출발점은 단순한 기능 구현이 아니라,"복잡하고 무거운 Java EE, 특히 EJB의 한계를 극복하려는 문제의식"에서 시작되었다.이번 글에서는 Spring Framework가 탄생하게 된 배경,그리고 이를 통해 해결하고자 했던 문제점들을 정리해보려고 한다.1. 당시 표준이었던 EJB는 어떤 문제를 안고 있었을까?EJB(Enterprise JavaBeans)는 2000년대 초,Java EE 기반 기업 애플리케이션 개발의 표준 서버 컴포넌트 모델이었다.하지만 현실에서는 다음과 같은 문제가 있었다항목문제점🧱 복잡한 구조단순한 로직도 여러 개의 클래스를 만들어야 함 (Ho..