The Nirsa Way

객체 수명과 약한 세대 가설: 힙을 세대로 나누는 이유자바의 가비지 컬렉션을 공부하다 보면 다음과 같은 용어가 반복해서 등장합니다.Eden 영역Survivor 영역Old GenerationMinor GC객체 승격힙을 여러 영역으로 나누는 이유는 객체마다 살아남는 시간이 다르기 때문입니다.어떤 객체는 생성된 직후 잠깐 사용되고 사라집니다. 반면 애플리케이션이 실행되는 동안 계속 참조되면서 오랫동안 살아남는 객체도 있습니다.public void process() { String message = "임시 메시지"; User user = userRepository.findById(1L);}위 코드에서 message처럼 메서드 내부에서 잠깐 사용하는 객체는 비교적 빠르게 필요 없어질 수 있습니다.반면 ..

핫스팟의 객체 표현과 가비지 컬렉션 루트가비지 컬렉션은 힙에 생성된 객체 중 더 이상 사용할 수 없는 객체가 차지한 메모리를 회수합니다.그렇다면 JVM은 힙에 있는 객체를 어떤 형태로 관리하고, 어떤 객체가 살아 있는지 어디서부터 확인할까요?이 질문에 답하려면 다음 두 가지를 구분해서 이해해야 합니다.객체 표현→ 힙에 생성된 객체가 어떤 구조로 저장되는가객체 탐색→ 가비지 컬렉터가 어디서부터 객체를 찾아가는가핫스팟 JVM에서는 힙의 객체를 내부적으로 OOP라는 구조를 통해 다룹니다. 객체의 앞부분에는 객체 상태와 클래스 정보를 담는 객체 헤더가 위치합니다.가비지 컬렉터는 객체 구조만 보고 생존 여부를 판단하지 않습니다. GC Root라고 부르는 시작점에서 객체 참조를 따라가며 도달 가능한 객체를 찾습니다..

가비지 컬렉션은 왜 필요한가: 활성 객체와 Mark and Sweep자바에서는 객체를 생성할 때 개발자가 직접 메모리를 할당하거나 반환하지 않습니다.User user = new User();위 코드처럼 new 키워드를 사용하면 객체가 생성되지만, C나 C++처럼 사용이 끝난 메모리를 직접 해제하는 코드는 작성하지 않습니다.이러한 메모리 관리를 대신 수행하는 기능이 가비지 컬렉션(Garbage Collection, GC)입니다.하지만 가비지 컬렉션을 단순히 “사용하지 않는 객체를 자동으로 삭제하는 기능”이라고만 이해하면 다음과 같은 의문이 생길 수 있습니다.JVM은 어떤 객체가 사용 중인지 어떻게 판단할까요?변수가 null이면 객체가 바로 제거될까요?객체끼리 서로 참조하고 있다면 계속 살아남을까요?객체가 ..

[Spring Security] BCrypt Salt의 이해: 로그인 검증이 가능한 이유와 Pepper를 고려하는 상황비밀번호 저장을 처음 구현할 때 흔히 "BCryp로 암호화해서 저장한다"라고 표현하지만 정확히는 아래와 같은 단방향 해싱 흐름입니다.[회원가입] 사용자 비밀번호 → BCrypt 해싱 → DB 저장[로그인] 사용자 입력 비밀번호 → DB의 BCrypt 해시와 비교 그런데 BCrypt를 조금 더 들여다보면 BCrypt는 매번 랜덤 Salt를 생성하므로 같은 비밀번호도 매번 다른 Hash가 나오게 됩니다. 그렇다면 로그인이 성공 가능한 이유는 무엇일지 의문이 생깁니다.이번 글은 위의 질문에서 출발하며 먼저 요약한 결론은 다음과 같습니다.1. BCrypt는 암호화가 아니라 단방향 해시다.2. B..

AGENTS.md와 이슈, 스펙, CodeRabbit으로 만드는 AI 개발 사이클최근에는 AI에게 단순히 “이 기능 구현해줘”라고 요청하지 않습니다. 먼저 Issue를 만들고, 필요한 경우 Spec을 작성한 뒤, AGENTS.md와 작업 프롬프트를 기준으로 개발 흐름을 고정합니다. 현재 제가 사용하는 흐름은 다음과 같습니다.이슈 생성스펙 생성 또는 확인구현테스트 및 정적 검사PR 생성CodeRabbit 리뷰 요청리뷰 타당성 검토필요한 내용만 반영CodeRabbit 재리뷰최종 diff 검토이 흐름은 AI가 임의로 정한 방식이 아닙니다. 프로젝트 루트에 있는 AGENTS.md, 제가 사용하는 작업 프롬프트, Issue, Spec, CodeRabbit이 함께 작동하면서 만들어지는 방식입니다. 왜 이슈를 먼저 ..

SpecGuard 소개: AI 코딩 전에 스펙을 먼저 검사하는 도구최근 Codex, Claude Code 같은 AI 코딩 도구를 사용하면서 개발 방식이 많이 바뀌고 있습니다.간단한 기능은 설명 몇 줄만으로도 빠르게 구현되고, 익숙하지 않은 코드베이스에서도 에이전트가 생각보다 많은 작업을 처리해줍니다. 저 역시 이런 도구를 사용하면서 개발 속도가 빨라지는 경험을 했습니다. 그런데 여러 번 사용해보니 문제가 단순히 “AI가 코드를 잘 짜느냐”에만 있지 않았습니다. 오히려 더 자주 부딪힌 문제는 AI에게 넘긴 스펙 자체가 불완전하다는 점이었습니다.문제는 코드가 아니라 입력물에 있었다AI 코딩 도구는 주어진 입력을 바탕으로 구현을 진행합니다. 입력이 명확하면 꽤 좋은 결과를 만들 수 있지만, 스펙이 애매하거나 ..

내가 프로젝트에서 사용하는 개발 방식 - IDAD (Issue-Driven Agent Development)AI 코딩 에이전트를 프로젝트에 사용하기 시작하면서 개발 방식이 조금씩 바뀌었습니다.처음에는 단순히 “AI에게 코드를 작성하게 한다” 정도로 생각했습니다. 하지만 실제 프로젝트에 적용해보니 중요한 것은 AI에게 코드를 얼마나 잘 쓰게 하느냐가 아니었으며 가장 중요한 것은 AI가 무엇을 기준으로 코드를 작성하게 할 것인가였습니다. 이러한 방식으로 인해 스펙 주도 개발이 유행하였고, 대부분의 개발자가 이 기준을 스펙으로 진행하고 있습니다.하지만 저는 프로젝트에서 이 기준을 이슈로 잡아 진행하고 있으며 이 방식을 개인적으로 IDAD(Issue-Driven Agent Development)라고 부릅니다.말..

개인 OSS 프로젝트 SpecGuard를 진행하며 겪은 AI 코딩 에이전트와의 작은 오해개인적으로 진행 중인 OSS 프로젝트 SpecGuard를 진행하며 오늘 있었던 일에 대해 작성하려 합니다. SpecGuard는 제가 개인적으로 만들고 있는 오픈소스 프로젝트입니다.github : https://github.com/KoreaNirsa/spec-guard프로젝트를 진행하면서 GitHub 이슈를 정리하고, 기능 우선순위를 판단하고, 새로운 아이디어가 프로젝트 방향과 맞는지 검토하는 과정에서 에이전트 AI를 함께 사용하고 있습니다.오늘도 평소처럼 AI에게 현재 열린 이슈를 기준으로 우선순위를 정하고, 특정 기능 아이디어가 프로젝트에 적절한지 검토해 달라고 요청했습니다.그런데 AI의 답변이 제가 기대한 방향과 ..

※ 해당 포스팅은 Matt pocock의 발표 영상(https://youtu.be/v4F1gFy-hqg?si=7M0lPIfwYiBs4Yfs)을 정리하고, 저의 생각을 추가한 작성한 글입니다. AI 시대, 왜 소프트웨어 기본기가 더 중요해졌는가?최근 AI 코딩 도구가 빠르게 확산 되면서 개발 방식도 크게 달라지고 있습니다. 이제는 개발자가 직접 모든 코드를 작성하지 않아도 AI에게 요구사항을 전달하고 코드를 생성하게 만들 수 있습니다.하지만 Matt Pocock은 이런 흐름 속에서도 소프트웨어 기본기, 즉 Software Fundamentals가 그 어느때보다 중요해졌다고 강조합니다.핵심은 단순한데, "AI에게 스펙을 전달하고 코드를 생성하게 하는 방식만으로는 좋은 시스템을 만들기 어렵다" 입니다. 코드베..

[이런 저런 이야기] 2025 표준프레임워크 컨트리뷰션 후기 (feat. 굿즈 개봉)올해는 2025 표준프레임워크 컨트리뷰션에 참여하였고 오늘 감사장과 굿즈를 배송 받아 후기를 남깁니다. 1. 참여한 계기올해는 유독 일을 오래 쉬었다보니 시간 부자가 되어서 평소에 관심있던 오픈소스에 기여를 해보자라는 생각을 가지게 되었습니다.그중에서 spring-boot, spring-petclinic, spring-ai, 표준프레임워크 이렇게 4가지 정도로 정리가 되었는데, 결과적으로는 spring-ai와 표준 프레임워크를 선택하게 되었습니다.spring-ai는 학습하는 과정에서 일부 중복이나 성능 개선이 가능한 코드를 아주 조금 수정하고 표준프레임워크에서는 레거시한 코드 구조와 스웨거를 명확히 출력 하도록 개선하기..