The Nirsa Way

최근 AX 직무 면접을 보며 느낀 이야기 - 개발자가 없는 개발팀최근 AX(AI Transformation) 관련 포지션의 면접을 여러 차례 경험했습니다.기업마다 AX를 정의하는 방식은 조금씩 달랐지만, 면접을 거듭할수록 비슷한 이야기를 반복해서 듣게 되었습니다.AI를 적극적으로 활용합니다.최대한 빠르게 제품을 만듭니다.한 사람이 하나의 제품을 책임집니다.가능하면 한 달 안에 결과물이 나와야 합니다.그리고 어떤 조직에서는 코드 품질이나 협업 방식은 현재 중요한 문제가 아니라고 이야기하기도 했습니다.처음에는 단순히 개발 방식의 차이라고 생각했습니다.하지만 비슷한 이야기를 계속 듣다 보니 한 가지 의문이 생겼습니다."AI를 이용해 제품을 빠르게 만드는 것과, 그 제품을 몇년동안 유지하고 운영하는 것은 같은 ..

Codex App + Hermes Desktop으로 AI 개발 환경 구축하기 (1) - Hermes란? Codex와 함께 사용하는 이유최근 AI를 활용한 개발 방식은 빠르게 변화하고 있습니다.과거에는 ChatGPT에 코드를 붙여 넣고 질문하거나, IDE의 AI 플러그인을 이용해 코드를 생성하는 것이 일반적이었습니다. 하지만 최근에는 AI가 프로젝트를 직접 이해하고, 코드를 수정하며, 테스트와 Git 작업까지 수행하는 AI Agent 형태의 개발 방식이 등장하고 있습니다.대표적인 예가 OpenAI의 Codex App입니다.Codex App은 단순히 코드를 생성하는 도구를 넘어 프로젝트를 분석하고, 필요한 변경 사항을 적용하며, 실제 개발 업무를 수행할 수 있는 AI 개발 도구입니다.하지만 프로젝트 규모가 ..

[Java GC] Old Generation은 어떻게 수집될까: Parallel GC와 Full GC, 할당 성능이전 포스팅에서는 Young Generation에서 객체가 어떻게 할당되고, Young GC에서 살아남은 객체가 Survivor Space를 거쳐 Old Generation으로 승격되는 과정을 살펴봤습니다.이번 글에서는 그다음 단계인 Old Generation을 다룹니다.Old Generation에는 Young GC에서 여러 번 살아남았거나, Survivor Space에 보관하기 어려워 승격된 객체가 주로 저장됩니다. 이러한 객체는 Young Generation의 객체보다 오래 살아 있을 가능성이 높으므로, Young GC와 같은 복사 방식만으로 설명하기 어렵습니다.또한 Old Generati..

Young Generation의 객체 할당과 수집: TLAB과 Survivor Space의 복사 수집새로운 객체는 Young Generation 안에서 실제로 어떻게 만들어질까요? 여러 스레드가 동시에 객체를 생성하면 같은 메모리 공간을 두고 충돌하지는 않을까요?또한 Young GC가 발생했을 때 살아남은 객체는 어디로 이동하며, Survivor 영역을 두 개 사용하는 이유는 무엇일까요?이 질문을 이해하려면 다음 두 가지 구조를 함께 봐야 합니다.TLAB : 여러 스레드가 객체를 빠르게 할당하기 위한 구조Survivor Space의 복사 수집 : Young GC에서 살아남은 객체를 다른 Survivor Space나 Old Generation으로 이동시키는 방식먼저 정리하자면 아래와 같습니다.대부분의 새 ..

객체 수명과 약한 세대 가설: 힙을 세대로 나누는 이유자바의 가비지 컬렉션을 공부하다 보면 다음과 같은 용어가 반복해서 등장합니다.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 코딩 도구는 주어진 입력을 바탕으로 구현을 진행합니다. 입력이 명확하면 꽤 좋은 결과를 만들 수 있지만, 스펙이 애매하거나 ..