어제 오늘 내일

과거에 MyBatis나 JDBC를 쓸 때는 개발자가 직접 SQL을 한 땀 한 땀 짰습니다. "DB에 저장해!" 하면 INSERT 쿼리를 날리고, "수정해!" 하면 UPDATE 쿼리를 날렸죠.하지만 JPA(ORM)의 세계는 다릅니다.우리는 그저 자바 객체(Entity)를 다루기만 하면 됩니다. 그러면 JPA가 알아서 적절한 SQL을 생성해 DB에 날려줍니다.이 모든 것을 가능하게 하는 JPA의 심장, '영속성 컨텍스트'에 대해 알아볼까요? 1. 영속성 컨텍스트가 뭔가요?쉽게 말해 "애플리케이션과 데이터베이스 사이에 있는 중간 관리자(캐시)"입니다.우리가 객체를 저장하거나 조회할 때, 바로 DB로 가는 게 아닙니다. 먼저 이 영속성 컨텍스트라는 곳에 보관됩니다. 그리고 JPA는 이 컨텍스트에 있는 정보를 ..

"이메일 형식이 아닙니다.", "비밀번호는 8자 이상이어야 합니다."회원가입 할 때 이런 메시지 많이 보셨죠? 프론트엔드에서도 막을 수 있지만, 백엔드에서의 검증은 필수입니다. (해커들은 프론트엔드를 우회해서 요청을 보내니까요!)오늘은 if문 도배 없이, 어노테이션 몇 개로 깔끔하게 데이터를 검증하는 Bean Validation을 알아보겠습니다. 1. 의존성 추가부터! (build.gradle)Spring Boot 2.3 버전 이상부터는 별도의 라이브러리를 추가해야 합니다.dependencies { implementation 'org.springframework.boot:spring-boot-starter-validation'} 2. DTO에 규칙 정하기 (어노테이션의 마법)데이터를 받는 객체..

개발하다 보면 비즈니스 로직보다 예외 처리 코드가 더 길어지는 주객전도 현상을 자주 겪게 됩니다.try { // 로직 수행...} catch (IllegalArgumentException e) { return ResponseEntity.badRequest().build();} catch (Exception e) { return ResponseEntity.internalServerError().build();}모든 컨트롤러마다 이런 코드를 복사-붙여넣기 하고 계신가요? 오늘은 Spring Boot가 제공하는 강력한 예외 처리 메커니즘으로 코드를 획기적으로 줄이는 방법을 소개합니다. 1. 컨트롤러 안에서 해결하기: @ExceptionHandler특정 컨트롤러 안에서 발생하는 에러만 잡고 싶..

개발하다가 에러가 나면 습관적으로 sysout을 치시나요?System.out.println("여기까지 실행됨: " + data);이 한 줄의 코드가 운영 서버에서는 치명적인 성능 저하를 일으킬 수 있다는 사실, 알고 계셨나요? 오늘은 진짜 개발자가 되기 위한 첫걸음, 로깅(Logging)에 대해 알아보겠습니다. 1. 왜 System.out.println은 안 되나요?이유는 간단합니다. 성능과 관리 때문입니다.블로킹(Blocking) I/O: System.out은 출력하는 동안 프로그램이 잠시 멈춥니다(Block). 요청이 폭주하는 서버에서 모든 스레드가 멈칫멈칫한다면? 전체 성능이 뚝 떨어집니다.정보 부족: 언제(Time), 누가(Thread), 어디서(Class) 로그를 남겼는지 알 수 없습니다.제어..

애플리케이션을 개발할 때 가장 골치 아픈 것 중 하나가 바로 환경(Environment) 관리입니다.Local: 내 컴퓨터 (가벼운 H2 DB, 디버그 로그 콸콸)Dev: 개발 서버 (팀원들과 공유하는 DB)Prod: 운영 서버 (실제 서비스 DB, 로그는 에러만)이때마다 코드를 수정해서 다시 빌드한다면? 상상만 해도 끔찍하죠. 오늘은 Spring Boot가 제공하는 강력한 설정 파일(yml) 관리와 프로파일(Profile) 기능을 완벽하게 정리해 드립니다. 1. properties vs YAML(.yml): 무엇을 써야 할까?Spring Boot는 기본적으로 application.properties 파일을 만들어주지만, 실무에서는 90% 이상 YAML(야믈, .yml) 형식을 선호합니다. 이유는 가독..

Spring Boot를 처음 접할 때 가장 놀라워하는 점은 "설정할 게 거의 없다"는 것입니다. 과거 Spring Legacy 시절에는 XML 파일에 수백 줄의 설정을 적어야 했는데, 지금은 build.gradle에 라이브러리 한 줄만 추가하면 끝납니다.이게 가능한 이유는 바로 @SpringBootApplication 어노테이션 속에 숨겨진 자동 설정(Auto Configuration) 덕분입니다. 오늘은 이 '마법' 뒤에 숨겨진 '과학(로직)'을 알아보겠습니다. 1. 비밀의 열쇠: @SpringBootApplication프로젝트를 생성하면 메인 클래스 위에 딱 하나 붙어있는 이 어노테이션, 다들 보셨죠?@SpringBootApplicationpublic class MyServerApplication ..

지난 시간, 우리는 new 키워드 없이 스프링 컨테이너가 객체(Bean)를 대신 관리해 주는 의존성 주입(DI)에 대해 알아봤습니다. 그렇다면 스프링은 이 빈들을 언제 만들고, 언제 없앨까요?오늘은 애플리케이션의 성능과 안정성에 직결되는 빈의 생명주기(Lifecycle)와 스코프(Scope)에 대해 명쾌하게 정리해 드립니다. 1. 스프링 빈의 생명주기 (Lifecycle)일반적인 자바 객체는 new로 생성하고 더 이상 쓰지 않으면 가비지 컬렉터(GC)가 알아서 수거해 갑니다. 하지만 스프링 빈은 조금 더 복잡하고 정교한 과정을 거칩니다.빈이 생성되고 소멸되는 순서스프링 컨테이너가 구동될 때 다음과 같은 흐름으로 빈이 관리됩니다.스프링 컨테이너 생성스프링 빈 생성 (객체화)의존관계 주입 (DI - Set..

Spring Boot를 공부하다 보면 "DI(Dependency Injection, 의존성 주입)"라는 단어를 정말 많이 듣게 됩니다.면접 단골 질문이기도 하고, 좋은 객체지향 설계를 위해 반드시 이해해야 하는 개념이죠.오늘은 DI가 도대체 무엇인지, 그리고 왜 필드 주입보다 생성자 주입을 권장하는지 명쾌하게 정리해 드리겠습니다. 1. 의존성 주입(DI)이 뭔가요?요리를 한다고 상상해 봅시다.DI가 없는 경우: 요리사가 요리할 때마다 직접 농장에 가서 재료를 캐오고, 칼을 대장간에서 만들어옵니다. (객체가 의존 객체를 직접 생성 new)DI가 있는 경우: 요리사는 요리에만 집중하고, 누군가가 손질된 재료와 좋은 칼을 주방에 딱 놔줍니다. (외부에서 의존 객체를 주입)프로그래밍에서 DI(Dependenc..

협업을 하다 보면 "다른 브랜치에 있는 저 기능 딱 하나만 가져오고 싶은데..." 라는 생각이 들 때가 있습니다. 브랜치 전체를 병합(Merge)하기엔 아직 미완성된 코드가 많아 부담스러울 때가 있죠.이럴 때 사용하는 기능이 바로 Git Cherry-pick입니다. 말 그대로 체리 바구니에서 맛있는 체리(커밋)만 쏙 골라내는 것처럼, 특정 커밋만 내 브랜치로 가져오는 기술입니다.이번 포스팅에서는 cherry-pick의 개념과 실전 사용법, 그리고 충돌 해결 꿀팁까지 정리해 드리겠습니다. 보통 브랜치를 합칠 때는 merge를 사용합니다. 하지만 merge는 브랜치의 모든 역사를 가져오기 때문에, 특정 버그 수정 사항만 긴급하게 배포 브랜치로 가져와야 할 때는 부적절할 수 있습니다.이때 cherry-pic..

프로젝트를 진행하다 보면 기능 추가(feature), 버그 수정(hotfix) 등으로 인해 수많은 브랜치(Branch)가 생겨나게 됩니다. 할 일을 다 마친 브랜치를 방치하면 나중에 "feature-login이 최신인가? 아니면 feature-login-new가 최신인가?" 하며 헷갈리는 순간이 오죠.이번 포스팅에서는 다 쓴 브랜치를 깔끔하게 삭제하는 방법을 로컬(Local)과 원격(Remote)으로 나누어 완벽하게 정리해 드리겠습니다. 브랜치 삭제는 크게 내 컴퓨터에 있는 '로컬 브랜치'와 GitHub 같은 서버에 있는 '원격 브랜치' 삭제로 나뉩니다. 명령어 한 줄이면 프로젝트가 훨씬 쾌적해집니다! 1. 로컬(Local) 브랜치 삭제하기내 컴퓨터에 저장된 브랜치를 지우는 방법입니다. Git은 안전..