Spring Boot

일반

약 1개월 전

자바 ClassLoader: 클래스는 언제 살아나는가?

자바 ClassLoader: 클래스는 언제 살아나는가 ClassLoader는 이름 그대로 .class 파일을 찾아 JVM 메모리에 올리는 존재다. 하지만 단순한 파일 로더라기보다, 자바에서 다음을 결정하는 핵심 장치다. “어떤 클래스를, 누가, 언제 메모리에 올리고 초기화할 것인가?” 자바 프로그램이 실행되는 순간 다음 코드가 있다고 하자. java public class Main { public static void main(String[] args) { User user = new User(); } } JVM이 처음부터 모든 클래스를 읽는 것은 아니다. 필요한 순간에 클래스를 찾아 로딩한다. mermaid flowchart TD A["Main 실행"] --> B["Main.class 탐색"] B --> C["JVM 메모리에 로딩"] C --> D["static 영역 초기화"] D --> E["main() 실행"] E --> F["User가 필요해짐"] F -->

중년개발자

@loxo

아키텍처

약 1개월 전

WebSocket 채팅으로 이해하는 Kafka Pub/Sub 오해

WebSocket 채팅으로 이해하는 Pub/Sub과 Kafka Kafka를 처음 이해할 때는 Pub/Sub(발행–구독) 구조로 접근하는 것이 가장 쉽습니다. 다만 Kafka의 진짜 강점은 Pub/Sub을 넘어, 메시지를 보관하고 다시 읽을 수 있는 분산 이벤트 로그라는 데 있습니다. Pub/Sub의 핵심 개념 일반적인 프로그램은 보내는 쪽이 받는 쪽을 직접 지정합니다. text 철수 → 영희에게 메시지 전송 Pub/Sub에서는 메시지를 특정 사람에게 보내지 않고 주제(Topic)에 발행합니다. text 철수 → "개발자 채팅방"에 메시지 발행 영희·민수·지수 → "개발자 채팅방"을 구독 mermaid flowchart LR P["Publisher<br/>철수"] -->|메시지 발행| T["Topic<br/>room:developer"] T --> S1["Subscriber<br/>영희"] T --> S2["Subscriber<br/>민수"] T -->

중년개발자

@loxo

6개월 전

#14 - JPA 실무 가이드 3부: 메소드 자동 생성과 조회 패턴의 모든 것

JPA 실무 가이드 3부: 메소드 자동 생성과 조회 패턴의 모든 것 "쿼리를 안 쓴다고? 아니다. 이름으로 쿼리를 작성하는 것이다." JPA Repository의 본질 많은 사람들이 착각한다. “JPA는 쿼리를 안 써도 된다” ❌ 틀렸다. 정확한 표현은 이거다. “쿼리를 코드가 아니라 ‘메소드 이름’으로 작성한다” Spring Data JPA는 Repository 인터페이스만 정의하면 👉 내부적으로 JPQL을 자동 생성한다. 가장 기본: CRUD는 이미 다 만들어져 있다 java public interface OrderRepository extends JpaRepository<Order, Long> { } 이 한 줄로 이미 다음이 존재한다. 기본 제공 메소드 java save(entity) // insert or update findById(id) // 단건 조회 findAll() // 전체 조회 delete(entity) // 삭제 count() // 개수

140

중년개발자

@loxo

#13 - JPA 실무 가이드 2부 - FK, PK 관리

JPA 실무 가이드 2부: 연관관계와 복합키의 모든 것 Spring Boot 4 & PostgreSQL 환경에서의 실용주의(Pragmatic) 고급 매핑 "왜 객체를 넣으면 ID가 저장될까요? 원리를 파헤칩니다." 연관관계의 핵심: "객체는 외래키(FK)를 모른다" 데이터베이스(DB) 세상에서는 "외래키(FK)"를 사용해 테이블을 연결합니다. 하지만 객체 세상에서는 "참조(Reference)"를 사용해 연결합니다. DB: SELECT FROM orders WHERE member_id = 1 Java: order.getMember() JPA의 역할은 이 패러다임의 불일치를 해결하는 것입니다. 우리가 order.setMember(member)라고 하면, JPA가 알아서 INSERT INTO orders (member_id) VALUES (1)로 통역해 줍니다. @ManyToOne 단방향: 실무 최강의 조합 가장 많이 쓰는 패턴은 "다대일(N:1) 단방향"입니다. 주문(Order)

157

중년개발자

@loxo

#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,

146

중년개발자

@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

141

중년개발자

@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) { ... }

136

중년개발자

@loxo

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

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

130

중년개발자

@loxo

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

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

125

중년개발자

@loxo

일반

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

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

113

중년개발자

@loxo

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

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

120

중년개발자

@loxo