<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://w00lam.github.io/</id><title>WooLam</title><subtitle>설명 가능한 경험을 쌓는 공간. 백엔드 개발자 WooLam의 기술 블로그입니다. Spring, JPA, 동시성 제어 등 백엔드 핵심 주제를 다룹니다.</subtitle> <updated>2026-05-14T12:27:31+09:00</updated> <author> <name>woolam</name> <uri>https://w00lam.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://w00lam.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="ko-KR" href="https://w00lam.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 woolam </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Docker 이미지는 정말 OS일까?</title><link href="https://w00lam.github.io/posts/docker-image-not-os/" rel="alternate" type="text/html" title="Docker 이미지는 정말 OS일까?" /><published>2026-05-14T00:00:00+09:00</published> <updated>2026-05-14T00:00:00+09:00</updated> <id>https://w00lam.github.io/posts/docker-image-not-os/</id> <content type="text/html" src="https://w00lam.github.io/posts/docker-image-not-os/" /> <author> <name>woolam</name> </author> <category term="Infrastructure" /> <category term="Docker" /> <summary>들어가면서 이전 포스트들에서 VM과 컨테이너의 근본적인 차이와 컨테이너가 어떻게 격리되는지 살펴보았다. 컨테이너는 호스트 OS의 커널을 공유하며 가볍게 동작한다고 했는데, 그렇다면 우리가 흔히 사용하는 ubuntu나 alpine 같은 Docker 이미지는 정말 운영체제(OS)일까? 많은 개발자가 Docker 이미지를 “작은 VM”이나 “OS가 통째로 들어있는 것”으로 오해하곤 한다. 이번 글에서는 이러한 오해를 풀고, Docker 이미지의 본질이 무엇인지, 그리고 이미지와 컨테이너의 관계를 명확히 이해하고자 한다. 이 글의 목표 Docker 이미지의 본질을 이해한다. 이미지와 컨테이너 차이를 설명할 수 있다. 1. 문제 제기: Docker 이미지는 OS인가? 우리는 dock...</summary> </entry> <entry><title>컨테이너는 어떻게 격리될까?</title><link href="https://w00lam.github.io/posts/container-isolation/" rel="alternate" type="text/html" title="컨테이너는 어떻게 격리될까?" /><published>2026-05-13T00:00:00+09:00</published> <updated>2026-05-13T00:00:00+09:00</updated> <id>https://w00lam.github.io/posts/container-isolation/</id> <content type="text/html" src="https://w00lam.github.io/posts/container-isolation/" /> <author> <name>woolam</name> </author> <category term="Infrastructure" /> <category term="Docker" /> <summary>들어가면서 이전 포스트인 VM과 컨테이너는 무엇이 다를까?에서 컨테이너가 VM보다 가볍고 빠르게 동작하는 이유를 구조적 차이에서 살펴보았다. 컨테이너는 호스트 OS의 커널을 공유하면서도 독립적인 실행 환경을 제공하는데, 이때 핵심적인 역할을 하는 것이 바로 Linux Namespace와 Cgroup이다. “컨테이너는 OS를 새로 띄우지 않는데 어떻게 이렇게 완벽하게 분리된 것처럼 보일까?” 이번 글에서는 이 질문에 답하며 컨테이너 격리의 실제 동작 원리를 깊이 있게 파헤쳐 보고자 한다. 이 글의 목표 컨테이너 격리의 실제 동작 원리를 이해한다. namespace와 cgroup의 역할을 설명할 수 있다. 1. 문제 제기: 컨테이너는 어떻게 독립성을 얻을까? 컨테이너를 실행하...</summary> </entry> <entry><title>VM과 컨테이너는 무엇이 다를까?</title><link href="https://w00lam.github.io/posts/vm-container-diff/" rel="alternate" type="text/html" title="VM과 컨테이너는 무엇이 다를까?" /><published>2026-05-12T00:00:00+09:00</published> <updated>2026-05-12T00:00:00+09:00</updated> <id>https://w00lam.github.io/posts/vm-container-diff/</id> <content type="text/html" src="https://w00lam.github.io/posts/vm-container-diff/" /> <author> <name>woolam</name> </author> <category term="Infrastructure" /> <category term="Docker" /> <summary>들어가면서 수업을 통해 가상화 기술을 학습하던 중, 오래전에 자바의 구동 원리를 정리하며 JVM이라는 가상 머신에 대해 고민했던 기억이 떠올랐다. 또한, 과거 Testcontainers를 활용한 통합 테스트 환경을 구축하면서 Docker를 사용했지만, 당시에는 VM과 컨테이너의 구조적 차이를 깊이 이해하지 못한 채 적용하며 겪었던 어려움이 있었다. 이번 학습을 통해 VM과 컨테이너의 본질적인 차이를 명확히 이해하고, 그때의 의문들을 해소하고자 한다. “컨테이너는 작은 VM”이라는 말이 과연 맞을까? 왜 Docker는 이렇게 많이 쓰이고, VM은 무겁다고 이야기할까? 이 글에서는 이러한 질문들에 답하며 VM과 컨테이너의 본질적인 차이를 깊이 있게 탐구해보고자 한다. 이 글의 목표 VM과 컨테...</summary> </entry> <entry><title>AOP 기반 로깅 전략 — 이력 파이프라인으로 확장 가능한 시스템 설계</title><link href="https://w00lam.github.io/posts/aop-logging-pipeline/" rel="alternate" type="text/html" title="AOP 기반 로깅 전략 — 이력 파이프라인으로 확장 가능한 시스템 설계" /><published>2026-05-11T00:00:00+09:00</published> <updated>2026-05-11T00:00:00+09:00</updated> <id>https://w00lam.github.io/posts/aop-logging-pipeline/</id> <content type="text/html" src="https://w00lam.github.io/posts/aop-logging-pipeline/" /> <author> <name>woolam</name> </author> <category term="Backend" /> <category term="Spring" /> <category term="Architecture" /> <summary>들어가면서 이전에 AOP를 정리하면서 “공통 로직은 어디에 있어야 할까?”에 대해 고민했었다. 실무에서 이 질문에 대한 가장 첫 번째 대답이자, AOP를 가장 먼저 적용하게 되는 곳이 바로 ‘로깅(Logging)’이라고 한다. 처음에는 단순히 에러가 났을 때 콘솔 창을 확인하기 위해 log.info()나 System.out.println()을 쓰는 정도로만 생각했다. 그런데 이런 조언을 들었다. “나중에 로깅 시스템으로 이력 파이프라인을 만드는 것으로 확장도 가능하니, 로깅으로 남기는 방법을 제대로 알아보세요.” 단순히 에러 확인용이 아니라, 이력 파이프라인이라니. 그래서 로깅을 시스템 아키텍처 관점에서 어떻게 설계하고 확장할 수 있는지 알아보았다. 기존 방식의 한계: 코드에 흩어진...</summary> </entry> <entry><title>EntityGraph와 페이징을 같이 사용할 때 주의할 점</title><link href="https://w00lam.github.io/posts/entitygraph-paging/" rel="alternate" type="text/html" title="EntityGraph와 페이징을 같이 사용할 때 주의할 점" /><published>2026-05-08T00:00:00+09:00</published> <updated>2026-05-08T00:00:00+09:00</updated> <id>https://w00lam.github.io/posts/entitygraph-paging/</id> <content type="text/html" src="https://w00lam.github.io/posts/entitygraph-paging/" /> <author> <name>woolam</name> </author> <category term="Backend" /> <category term="JPA" /> <summary>들어가면서 처음에는 단순히 이렇게 생각했다. “EntityGraph랑 Pageable 같이 쓰면 안 되는 거 아닌가?” 실제로 JPA를 공부하다 보면: fetch join + pagination 주의 컬렉션 fetch join 페이징 문제 메모리 페이징 발생 가능 같은 이야기를 자주 보게 된다. 그래서 처음에는 EntityGraph 자체가 페이징과 충돌한다고 생각했다. 그런데 흐름을 다시 따라가 보니, 문제의 본질은 조금 달랐다. 결론부터 정리하면 EntityGraph 자체는 Pageable과 함께 사용할 수 있다 문제는: 컬렉션(ToMany)을 fetch 하는 순간 발생한다 즉, ManyToOne OneToOne 같은 ToOn...</summary> </entry> </feed>
