Spring Boot

약 7시간 전

#12 - JPA 실무 가이드 1부 — 입문자 기준 쉽게 이해하기(30분 JPA 정복)

JPA 실무 가이드 1부 — 입문자 기준 쉽게 이해하기 SQL을 직접 작성하던 시절, 개발자는 항상 DB 구조에 맞춰 움직여야 했습니다. 그래서 JPA는 복잡하고 어려운 기술처럼 느껴질 수 있습니다. 하지만 실무에서 제대로 사용해보면, JPA는 객체 중심으로 개발을 단순화해주는 도구입니다. 이 문서는 불필요한 이론을 걷어내고, 실무에 꼭 필요한 핵심만 정리한 30분 요약 가이드입니다. JPA가 무엇인가요? JPA (Java Persistence API, 자바 영속성 API)는 자바 객체(Object)를 데이터베이스(DB)에 저장하고 관리하는 기술입니다. 조금 더 쉽게 말하면, 우리가 객체(Object)를 만들고 값을 바꾸면 JPA가 알아서 SQL을 만들어 DB에 반영해 줍니다. 여기서 중요한 개념이 바로 ORM (Object Relational Mapping, 객체-관계 매핑) 입니다. 객체(Object)와 테이블(Table)을 연결해주는 기술이 ORM입니다. 엔티티(Entity,

중년개발자

@loxo

#11 - Service가 반드시 해야 할 일

Service 실무 가이드: Service가 반드시 해야 할 일 (Standard Responsibilities) Spring Boot 4 Service Layer Standard Guide "Service에만 넣어야 하는 로직과 그 이유" Service의 정의: 비즈니스 규칙의 최종 심판 Service는 단순히 Repository를 호출하는 패스스루(Pass-through)가 아닙니다. Service의 존재 이유는 "상태를 변경하기 전, 모든 규칙을 검사하고 확정 짓는 것"입니다. 트랜잭션의 시작과 끝을 책임진다 (@Transactional) Spring Boot에서 트랜잭션 경계는 Service 메서드입니다. Controller나 Repository가 아닙니다. ✅ 표준 패턴: 읽기 전용과 쓰기 분리 java @Service @RequiredArgsConstructor @Transactional(readOnly = true) // 기본은 읽기 전용 (성능 최적화) public

중년개발자

@loxo

#10 - Service에서 하지 말아야 할 것들

Service 실무 가이드: Service에서 하지 말아야 할 것들 Spring Boot에서 Service 레이어를 순수하게 유지하기 위한 "금지 목록" Web 기술을 Service로 가져오지 않는다 Service는 어떤 환경(Web, Console, Batch)에서도 실행 가능해야 한다. Controller가 처리해야 할 HTTP 관련 객체가 Service 메서드 파라미터나 반환값에 등장하면 안 된다. ❌ 절대 금지: Web 객체 의존 java // BAD public void createOrder(HttpServletRequest req) { ... } public ResponseEntity<Order> getOrder(Long id) { ... } ✅ 올바른 방법: POJO(Plain Old Java Object) 사용 java // GOOD public void createOrder(Long userId, CreateOrderCommand command) { ... }

중년개발자

@loxo

#9 - Controller 코딩 레벨 에서 순서 및 설명

Controller 실무 가이드 Spring Boot에서 Controller를 실제로 어떻게 작성하는가 어노테이션, 클래스, Response 설계를 코딩 순서대로 정리한다 이 문서의 목적 Controller를 설명할 때 가장 많이 나오는 말은 이것이다. “Controller는 얇아야 한다” 하지만 실무에서는 곧바로 이런 질문이 나온다. 그래서 뭐를 쓰고, 뭐를 어디까지 작성하라는 건데? 이 문서는: Controller에서 반드시 알아야 할 클래스와 어노테이션을 실제 코딩 순서에 맞게 설명하고 특히 Response 설계를 실무 기준으로 정리한다. Controller 작성 순서 (이 순서를 지키면 흔들리지 않는다) Controller는 보통 아래 순서로 작성한다. Controller 선언 Request 매핑 정의 요청 데이터 바인딩 검증 선언 Service 위임 Response 반환 이 순서를 기준으로 하나씩 정리한다. Controller 선언에 필요한 어노테이션

중년개발자

@loxo

#8 - Controller에서 하면 안 되는 것들 — Spring Boot 실무 설계 기준과 코드

Controller를 입구로 설계한다는 것 Spring Boot에서 Controller를 가장 실무적으로 사용하는 기준 "의심한다"는 명제를 코드로 구현하는 방법 이 문서를 읽는 기준 1️⃣ “의심한다”는 명제를 추상적으로 말하지 않는다 의심을 구체적인 책임 목록으로 풀어낸다 → 해석 / 검증 / 자격 확인 반대로 의심과 무관한 행동을 금지 목록으로 명확히 제시한다 이렇게 하면 “Controller에서 뭘 하면 안 되는지”가 감각이 아니라 기준이 된다. 2️⃣ 가장 많이 헷갈리는 질문을 정면으로 다룬다 현장에서 반복되는 질문은 늘 같다. Service를 여러 번 호출해도 되는가? Service에서 받은 데이터를 Controller에서 편집해도 되는가? 3️⃣ Spring Boot의 ‘사상’에 맞게 정렬한다 Spring이 기대하는 Controller는 다음이 아니다. orchestration 계층 ❌ 판단 계층 ❌ 가공 계층 ❌ → 입구 계층이다. 그래서 이 문서는 마지막에 이

중년개발자

@loxo

일반

10일 전

우리는 while 안에서 살고 있었다

while 안에서 살고 있던 우리 python으로 TUI 프로그램을 만들다가 문득 그런 생각이 들었다. 프로그램이라는 건 결국 loop 안에서 돌아간다는 사실. while True: 그 한 줄 안에서 입력을 받고, 판단하고, 출력하고, 다시 처음으로 돌아간다. 끝날 때까지. 아니, 보통은 끝나지 않게 설계한다. C 수업에서 처음 배웠던 while 문. 그땐 너무 당연해서 깊게 생각하지 않았다. “아, 반복문이구나.” 그 이상도 이하도 아니었다. 프레임워크는 친절하지만, 진실을 가려준다 Spring Boot를 쓰면 우리는 컨트롤러를 만들고, 어노테이션을 붙이고, 요청이 오면 알아서 처리된다고 믿는다. 그게 틀렸다는 건 아니다. 하지만 그 안에서 무슨 일이 일어나는지는 점점 관심 밖으로 밀려난다. 어느 순간부터 우리는 “왜 이렇게 되는지”보다 “이렇게 하면 된다”에 익숙해진다. 매뉴얼 개발자. 나쁘게 말하면 그렇고, 좋게 말하면 효율적인 시대의 산물이다. 하지만 while 문을 직접

중년개발자

@loxo

17일 전

#7 - Spring Boot 4 실습: 환경 준비부터 서버 실행까지

Spring Boot 4 실습: 환경 준비부터 서버 실행까지 이 실습의 목적은 강의를 따라 실제로 서버를 실행해보는 것이다. 단순히 코드를 읽는 것이 아니라, "내 로컬에서, 내가 이해한 구조로, 서버가 뜬다" 라는 경험을 만드는 것이 목표다. 눈으로만 코딩은 아무 도움이 되지 않습니다. 오직 손으로 직접 코딩만이 당신의 실력을 키워 줍니다. AI가 코딩해도 이해 기반 손코딩은 여전히 필요합니다. 단순히 아래 글을 눈으로 지나치지 마시고, 중간 가이드 문서도 꼼꼼히 보셔야 따라 올 수 있습니다. 사전 준비: 왜 VS Code + Antigravity 인가 0.1 IntelliJ에서 Antigravity로 갈아탄 이유 IntelliJ는 여전히 훌륭한 IDE다. 하지만 이 강의에서는 VS Code + Antigravity를 기준으로 한다. 이유는 단 하나다. AI 개발 경험 AI 없이는 이제 코딩하기 힘들다. 노가다 코딩을 줄여주기 때문에 이전으로 못 돌아간다. 때로는 공부도 된다.

중년개발자

@loxo

20일 전

#6 - Controller에 오기 전, 서버 안에서 벌어지는 일

Controller에 오기 전, 서버 안에서 벌어지는 일 Spring Boot 4 초보자를 위한 진짜 서버 이야기 "요청은 Controller로 바로 오는 게 아니다" 이 강의의 목표 이 강의의 목표는 단순하다. Controller 메서드 한 줄이 실행되기까지, 서버 안에서 어떤 일이 벌어지는지 이해한다. Spring을 전혀 몰라도 이해할 수 있어야 한다 "왜 여기서 막히는지"를 구조로 설명할 수 있어야 한다 Filter / Security / DispatcherServlet의 경계가 명확해야 한다 먼저 큰 그림부터 요청은 이렇게 이동한다. text [사용자] ↓ [웹 서버 / WAS (Tomcat)] ↓ [Servlet Filter 영역] ↓ [Spring Context 영역] ↓ [DispatcherServlet] ↓ [Interceptor] ↓ [Controller] 👉 Controller는 맨 마지막이다. 👉 대부분의 일은 Controller에 오기 전에 이미 끝난다.

중년개발자

@loxo

22일 전

#5 - Controller에 들어가기 전에 반드시 알아야 할 것

API URL 네이밍 규칙과 리소스 중심 백엔드 설계 왜 Controller 코드를 쓰기 전에 URL부터 배워야 할까? 초보 개발자는 보통 이렇게 시작한다. text /login /getUser /saveOrder /updateProfile 처음엔 아무 문제 없어 보인다. 하지만 API가 10개, 50개, 200개로 늘어나는 순간 이 백엔드는 스스로 설명하지 못하는 시스템이 된다. 👉 URL은 단순한 주소가 아니라, 백엔드의 사고방식이 드러나는 설계 문서다. Controller는 코드이기 전에 계약(Contract) 이다. 업계 표준의 핵심: "행동이 아니라 리소스를 표현한다" ❌ 잘못된 사고 (동사 중심) text /getUser /createUser /deleteUser 이 설계는 항상 질문을 만든다. getUser는 조회인가? 상세인가? createUser는 POST인가? GET인가? deleteUser는 여러 개면? ✅ 올바른 사고 (리소스 중심) text /users

중년개발자

@loxo

24일 전

#4 - 테스트, 트랜잭션 경계

테스트: 불신을 코드로 고정하는 방법 테스트는 기능을 증명하는 도구가 아니다. 테스트는 "믿지 않겠다는 약속"을 코드로 고정하는 장치다. 1.1 Controller 테스트는 얇아야 한다 Controller 테스트의 목적은 단 하나다. 잘못된 요청은 절대 안으로 들어오지 못한다 java @WebMvcTest(OrderController.class) class OrderControllerTest { @Test void 수량이음수면400을_반환한다() throws Exception { mockMvc.perform(post("/orders") .contentType(MediaType.APPLICATION_JSON) .content("{\"productId\":1, \"quantity\":-1}")) .andExpect(status().isBadRequest()); } } 👉 Controller 테스트는 신뢰 경계 테스트다. 10.2 Service 테스트는 규칙을 증명한다 Service

중년개발자

@loxo

24일 전

#3 - 사고방식을 코드로 옮긴다는 것

사고방식을 코드로 옮긴다는 것 Spring 전문가 관점에서 본\ "프론트를 믿지 않는 백엔드"를 Spring Boot 4로 구현하는 방법 Spring Boot는 구조를 강요하지 않는다 (그래서 더 위험하다) Spring Boot는 빠르게 만들 수 있게 해주지만,\ 올바르게 만들게 강제하지는 않는다. 그래서 초보 단계에서는 흔히 이런 구조가 나온다. controller └── service └── repository 그리고 모든 검증, 모든 판단, 모든 예외가 Service 하나에 쌓이기 시작한다. 👉 이 순간부터 사고방식과 구조가 어긋난다. 사고방식 → 구조 변환의 핵심 원칙 백엔드 사고방식을 Spring Boot 구조로 옮길 때 전문가들이 공유하는 핵심 원칙은 단순하다. ✅ 원칙 1. "의심은 가장 바깥에서 시작한다" HTTP 요청은 가장 위험하다 따라서 Controller 레벨에서 1차 방어가 필요하다 ✅ 원칙 2. "비즈니스 규칙은 중앙에 둔다" Service는 흐름

중년개발자

@loxo