GC(Garbage Collection)를 처음 접하면 흔히 '사용하지 않는 메모리를 자동으로 지워 주는 기능'이라고 생각하기 쉬워요. 틀린 말은 아니지만, 이 설명만으로는 GC의 진짜 핵심을 놓칠 수 있습니다. GC의 진정한 출발점은 메모리를 비우는 동작 자체가 아니라, 무엇을 회수 대상으로 볼 것인지 판단하는 일에 있기 때문이죠. 메모리에서 어떤 객체를 회수하려면 먼저 그 객체가 더 이상 쓰이지 않는다고 판정해야 해요. 즉, GC를 제대로 이해하려면 가장 먼저 죽은 객체란 무엇인가?를 정의해야 합니다.이 판정 기준이 명확히 서야 비로소 실제 수거 알고리즘이 의미를 가지거든요. 이번 글에서는 객체의 생사 판정 기준을 시작으로, JVM의 메모리 관리 전략을 단계별로 알아볼게요. 💡 이 글에서 다룰 내용..

💡 이 글을 읽으면 알 수 있는 것메모리 장애가 발생했을 때 힙부터 의심하는 습관에서 벗어날 수 있어요.OutOfMemoryError와 StackOverflowError의 차이와 발생 원인을 명확하게 이해할 수 있어요.힙, 스택, 메서드 영역, 다이렉트 메모리처럼 JVM 메모리 영역별 문제의 특징과 대응 방향을 정리할 수 있어요. JVM에서 발생하는 메모리 문제가 모두 같은 종류는 아니에요.힙에 객체가 과도하게 쌓이면 OutOfMemoryError가 발생하고, 호출 스택이 지나치게 깊어지면 StackOverflowError가 발생해요.때로는 다이렉트 메모리처럼 힙 바깥 영역이 한계에 도달하면서 문제가 드러나기도 해요. 실무에서는 이런 장애를 만나면 흔히 “메모리가 부족하다”라고 해석하기 쉬워요.하지만 ..

💡 이 글에서 다루는 내용new 키워드가 실행될 때 JVM 내부에서 어떤 과정이 순서대로 일어나는지 살펴봐요.자바 객체가 단순한 필드 값의 묶음이 아니라, 객체 헤더와 패딩까지 포함한 구조라는 점을 이해해요.객체의 실제 메모리 구조를 바탕으로 GC가 어떻게 동작하는지, 메모리 누수가 왜 생기는지 추정하는 감각을 익혀봐요.이전 글에서는 JVM 메모리 영역의 큰 그림을 살펴봤어요.메서드 영역에는 클래스 메타데이터가 올라가고, 스택에는 메서드 호출 문맥이 쌓이며, 힙에는 객체와 배열이 생성돼요. 하지만 “객체는 힙에 생성된다”는 설명만으로는 객체를 충분히 이해하기 어려워요.객체는 힙의 한 칸에 놓인 단순한 데이터 덩어리가 아니에요.JVM은 객체를 만들 때 먼저 어떤 클래스의 인스턴스인지 확인하고, 필요한 메..

💡 이 글을 읽으면 알 수 있는 것OOM이나 StackOverflowError가 발생했을 때, 힙 외에 어떤 영역을 확인해야 하는지 알 수 있어요.스레드마다 따로 만들어지는 영역과 모든 스레드가 함께 사용하는 영역의 차이를 이해할 수 있어요.JVM이 자바 프로그램을 실행할 때 메모리를 어떻게 나누어 관리하는지 전체 그림을 그릴 수 있어요.자바 메모리를 이야기할 때 가장 먼저 떠오르는 것은 보통 힙(Heap)과 가비지 컬렉션(Garbage Collection, GC)이에요.실제로 많은 객체가 힙에 생성되고, GC도 주로 힙을 기준으로 동작하므로 이 관점은 중요해요. 하지만 자바 프로그램의 실행 과정을 힙만으로 설명하기는 어려워요.메서드 호출은 스택(Stack)에서 관리하고, 현재 실행 중인 명령어 위치는..

여러분은 바이브 코딩 즐겨 하시나요?바이브코딩은 빠르고 편리하지만, 반복적으로 같은 문제에 부딪히곤 해요.의도와 다른 결과물이 생성되요끝없이 수정을 반복하게 되요언제 내 작업이 완료되는가에 대한 기준이 사라져요 BDD 스타일의 인수테스트를 활용하면 AI에게 객관적인 검증 기준을 줄 수 있고, 이런 문제를 효과적으로 해결할 수 있어요. 이 글을 읽고 나면 아래와 같은 효과를 가질 수 있을거에요바이브코딩에서 품질 문제가 반복되는 원인을 이해해요.BDD(행동 주도 개발) 스타일의 인수테스트가 이 문제를 어떻게 해결하는지 파악해요.Python-behave를 사용해 인수테스트를 직접 작성하고 실행해요.인수테스트를 AI에게 검증 기준으로 넘겨서 바이브코딩 결과물의 품질을 높일 수 있어요. 바이브 코딩의 품질 문제바..

이 글에서는 Kotlin의 핵심 설계 철학이 JPA와 만나면서 어떤 부분에서 구조적인 타협이 생기는지 정리해요. 내용은 이론보다 실제 적용하면서 겪은 경험을 바탕으로 설명할게요. 이 글의 목적은 JPA를 쓰지 말자가 아니에요. Kotlin + JPA 조합이 어떤 비용을 포함하는지를 미리 알고, 그걸 감안한 상태에서 선택할 수 있도록 돕는 데 있어요. Kotlin이 지키고자 하는 핵심 가치Kotlin은 단순히 Java의 문법을 개선하는 데 그치지 않고, 코드를 더 안전하고 예측 가능하게 만드는 방향을 강하게 지향해요.이를 위해 다음과 같은 핵심 가치를 중심에 두고 설계되었어요. 이 지점들이 JPA와 만날 때 종종 타협 포인트가 돼요. JPA 사용 시 발생하는 구조적 충돌1. Null 안정성 약화JPA는 엔..