Language60

• 

  Java 개발자라면 반드시 알아야 할 GC의 동작 원리와 실무에서의 성능 영향 들어가며: "왜 Spring Batch 테스트가 OOM으로 터졌을까?"어느 날 Spring Batch 통합 테스트를 돌리다 갑자기 빌드가 java.lang.OutOfMemoryError: Java heap space로 실패했다.메모리 누수도 없고, 데이터도 적은데 왜 떨어지는 걸까. 며칠간 삽질한 끝에 알게 된 사실은 충격적이었다. Context 캐싱 한계로 Spring TestContext Framework가 새로운 Application Context를 계속 생성했고, GC가 충분히 빠르지 못해 메모리가 쌓여가고 있었던 것이다.그때 느낀 것이다.GC를 모르면, Java 개발자는 왜 느린지, 왜 터지는지 원인을 절대 알 수 없다.이 글에서는 GC의 동작 원리를 실제 운영 관점에서 설명하고, OOM 같은 .. Language/Java & Kotlin 2026. 7. 17.

• 

  Java 개발자라면 알아야 할 JVM의 모든 것: 클래스 로더부터 실행 엔진까지 Java의 탄생 배경Java는 1991년 썬 마이크로시스템즈(이하 썬)의 제임스 고슬링과 아서 밴 호프를 주축으로 한 엔지니어들이 플랫폼으로부터 독립적으로 실행 가능하도록 개발한 언어입니다. 참고로 여기서 플랫폼이란 운영체제와 CPU 아키텍처를 말합니다. 대표적으로 Windows, Linux, Mac 그리고 x86과 핸드폰에 주로 쓰이는 arm이 있습니다. 90년대 초는 C와 C++의 사용률이 높았던 시절입니다. 썬의 개발자들이 당시 핫했던 C나 C++를 사용하지 않은 이유는 무엇일까요? 객체지향 프로그래밍은 C++로도 가능했지만, C++는 플랫폼에 따라 컴파일러에 차이가 있어 플랫폼 간 실행파일의 호환성이 보장되지 않았습니다. 이는 인터넷의 발전으로 다양한 환경에서 실행될 가능성이 높아진 프로그램들을 .. Language/Java & Kotlin 2026. 7. 17.

• 

  배포 후 첫 5분이 느린 이유: JVM 워밍업 없이 트래픽을 받으면 안 되는 이유 들어가며: 이 글은 어떤 질문에서 시작됐나Spring 서버를 배포하고 로드밸런서에 붙인 지 1분이 채 안 돼 모니터링을 보면, 같은 API 요청의 응답 시간이 200ms에서 50ms로 뚝 떨어진다. 처음엔 캐시 워밍업이라고 생각했는데, 알고 보니 JIT 컴파일러 때문이었다.이 글은 "JIT가 뭐죠?" 하는 면접 답변 수준을 넘어서, 실무에서 서버 성능을 직접 다루는 엔지니어가 알아야 할 JIT의 원리를 다룬다. 특히 다음 질문들에 답한다:왜 처음엔 느리고 계속 실행하면 빨라지나?C1, C2 컴파일러는 뭐가 다른가?배포 직후 응답 지연을 어떻게 피할까?문제 상황: 실무에서는 어디서 헷갈리나상황 1: 배포 후 초기 응답 지연서버를 Kubernetes로 무중단 배포하는 상황을 생각해보자.시간 API 응.. Language/Java & Kotlin 2026. 7. 17.

• 

  Python 실행 원리: CPython, Bytecode, PYC, VM, JIT 정리 1. 문서 제목Python 실행 원리: CPython, Bytecode, PYC, VM, JIT 정리2. 기술 개요 요약Python을 “인터프리터 언어”라고만 설명하면 반쪽짜리 답이 된다. 표준 구현체인 CPython은 .py 소스코드를 바로 한 줄씩 실행하는 것이 아니라, 먼저 bytecode로 컴파일한 뒤 CPython VM이 그 bytecode를 해석하며 실행한다. 다만 Java처럼 별도 컴파일러 산출물인 .class를 배포하는 모델과 달리, CPython의 .pyc는 주로 import 성능을 위한 bytecode cache다.CPython bytecode는 CPython 내부 구현에 가까워 Python 버전 간 안정적인 배포 포맷으로 간주되지 않는다. 또한 표준 CPython은 HotSpot JV.. Language/Python 2026. 7. 11.

• 

  왜 우리는 Vite를 쓰는가? (esbuild, Turbopack, Rolldown 비교) 1. 문서 제목왜 우리는 Vite를 쓰는가? (esbuild, Turbopack, Rolldown 비교)2. 기술 개요 요약프론트엔드 빌드 도구는 성능과 개발 경험(DX)을 중심으로 빠르게 진화해왔습니다.esbuild는 Go 기반의 초고속 번들러로 “속도 혁명”을 이끌었고,Vite는 이를 활용해 개발 서버 경험을 극적으로 개선한 도구입니다.이후 Turbopack은 Rust 기반의 증분 빌드 전략으로 새로운 접근을 제시했고,최근에는 Vite의 구조적 한계를 해결하기 위해 Rolldown이 등장했습니다.핵심 흐름은 다음과 같습니다:Webpack → esbuild (속도 혁명) → Vite (DX 혁신) → Turbopack (증분 빌드) → Rolldown (통합 엔진)3. 핵심 개념 정리3.1 Vite의 .. Language/JS(Node.js) 2026. 3. 22.

• 

  Node.js + TypeScript에서 esbuild로 단일 파일 번들링 완벽 가이드 1. 문서 제목Node.js + TypeScript에서 esbuild로 단일 파일 번들링 완벽 가이드2. 기술 개요 요약esbuild는 Go로 작성된 초고속 번들러로, Node.js 및 TypeScript 프로젝트를 단일 JavaScript 파일로 번들링할 수 있다. 단순한 번들러를 넘어, 병렬 처리, 메모리 최적화, AST 처리 전략 등 컴파일러 수준의 설계 최적화를 통해 기존 JavaScript 기반 번들러 대비 수십~수백 배 빠른 성능을 제공한다.3. 핵심 개념 정리3.1 esbuild의 핵심 특징Go 기반 네이티브 실행멀티코어 병렬 처리자체 구현된 컴파일 파이프라인최소 패스 AST 처리고효율 메모리 사용4. 왜 esbuild는 빠른가? (Deep Dive)4.1 Go 기반 네이티브 실행문제: Ja.. Language/JS(Node.js) 2026. 3. 21.

• 

  트리 쉐이킹(Tree Shaking)의 내부 동작 원리: 번들러는 어떻게 죽은 코드를 찾아낼까? 현대 자바스크립트 생태계에서 '트리 쉐이킹(Tree Shaking)'은 선택이 아닌 필수가 되었습니다. 프론트엔드의 로딩 속도 최적화는 물론이고, 백엔드의 서버리스(Serverless) 콜드 스타트 시간을 단축하기 위해서도 이 기술은 핵심적인 역할을 합니다.그렇다면 Webpack, Rollup, esbuild 같은 번들러들은 도대체 무슨 수로 우리가 작성한 수많은 파일 속에서 '쓰이는 코드'와 '버려야 할 코드'를 정확히 구분해 내는 걸까요? 그 내부 동작 원리를 깊이 있게 알아봅니다.1. 전제 조건: 왜 반드시 ESM(ES Modules)이어야 할까?트리 쉐이킹의 원리를 이해하기 위한 첫 번째 열쇠는 정적 분석(Static Analysis)입니다.과거의 CommonJS(require)는 코드가 실행되는.. Language/JS(Node.js) 2026. 3. 21.

• 

  Express + React 보일러플레이트를 TypeScript로 전환하며 고려한 기술적 사항들 들어가며기존에 Node.js(Express) + React로 작성된 인증 보일러플레이트를 TypeScript로 전환하는 작업을 진행했습니다. 단순히 파일 확장자를 바꾸는 것이 아니라, 프로젝트 구조 재설계, 비동기 패턴 현대화, React 메이저 버전 업그레이드까지 한 번에 수행한 과정에서 마주친 기술적 고민들을 정리합니다.전환 전 상태:백엔드: Express 4.17, Mongoose 5.11 (콜백 스타일), JWT 인증, 하드코딩된 설정값프론트엔드: React 17, CRA (react-scripts 5), Redux 4, React Router v5TypeScript, 테스트, 환경변수 설정 모두 없음1. 백엔드 tsconfig.json 설계: NodeNext를 선택한 이유{ "compilerO.. Language/Typescript 2026. 3. 21.

• 

  [Node.js] 멀티코어 전략과 비동기 모델의 진화 Java 개발자가 Node.js를 파헤치다 — Week 2: 멀티코어 전략과 비동기 모델의 진화Week 1에서 Node.js의 싱글스레드 + 이벤트 루프 모델을 이해했다. 이번 주에는 "싱글스레드의 한계를 어떻게 극복하는가"를 다룬다. Worker Threads, Cluster 모듈로 Node.js가 멀티코어를 활용하는 방법을 살펴보고, Java 진영의 Spring WebFlux와 Virtual Threads까지 비교하며 두 생태계의 비동기 모델이 어떻게 진화해왔는지 정리한다.1. Worker Threads — Node.js도 멀티스레드가 된다싱글스레드의 치명적 약점: CPU-boundWeek 1에서 Node.js의 싱글스레드 모델이 I/O-bound 작업에 효율적이라고 했다. 하지만 CPU를 많이 쓰는.. Language/JS(Node.js) 2026. 3. 5.

• 

  [Node.js] 비동기 프로그래밍 깊게 파기: Promise부터 동시성 제어까지 [Node.js] 비동기 프로그래밍 깊게 파기: Promise부터 동시성 제어까지1. Promise의 내부 상태와 에러 전파의 원리Promise는 단순한 콜백 헬 해결사가 아닙니다. 이는 비동기 작업의 상태를 관리하는 객체입니다.3가지 상태: Pending, Fulfilled, Rejected. 한 번 결정된 상태는 바뀌지 않습니다(Immutability).에러 버블링: .then() 체인 내부에서 발생한 에러는 중간에 .catch()가 없다면 계속 뒤로 전파됩니다.Unhandled Rejection: 최신 Node.js 환경에서는 .catch()하지 않은 에러가 발생하면 프로세스가 종료될 수 있습니다. 반드시 최종 단계에서 예외 처리가 필요합니다.2. async/await: 문법적 설탕 그 이상의 가치.. Language/JS(Node.js) 2026. 3. 2.

• 

  [Node.js] 동시성 모델의 모든 것 Spring/Java 환경에서 일하다가 NestJS/Node.js를 병행하게 되면서, 그동안 "그냥 되니까" 넘어갔던 Node.js의 내부 동작 원리를 제대로 공부하기로 했다. Week 1에서는 Java와 Node.js의 동시성 모델 차이, 이벤트 루프의 실체, 그리고 실무에서 주의할 점까지 정리한다.1. 두 세계의 출발점: 요청을 어떻게 처리할 것인가웹 서버의 본질은 간단하다. 요청이 들어오면 처리하고 응답한다. 문제는 요청이 동시에 수천 개씩 들어올 때다. Java와 Node.js는 이 문제를 완전히 다른 방식으로 풀었다.Java: Thread-per-RequestJava의 전통적인 방식(Spring MVC + Tomcat)은 요청 하나당 스레드 하나를 할당한다.Client A ──→ [Thread-.. Language/JS(Node.js) 2026. 3. 2.

• npm i (npm install)와 npm ci (npm clean-install) npm ci와 npm i는 모두 Node.js 프로젝트의 의존성 패키지를 설치하는 명령어이지만, 사용 목적과 동작 방식에 명확한 차이가 있습니다. 결론부터 말하면, 개발 환경에서는 npm i를, 배포나 협업 환경에서는 npm ci를 사용하는 것이 일반적입니다.주요 차이점구분npm i (npm install)npm ci (npm clean-install)기준 파일package.jsonpackage-lock.jsonpackage-lock.json의존성 변경 시 업데이트수정하지 않음 (불일치 시 오류)node_modules기존 폴더에 추가/변경항상 기존 폴더를 삭제 후 새로 설치속도상대적으로 느릴 수 있음일반적으로 더 빠름주요 용도개발 중 새로운 패키지 추가/업데이트CI/CD 파이프라인, 팀원 간 동일 환경 .. Language/JS(Node.js) 2025. 9. 23.