<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://xoruddl.github.io/</id><title>eta_kyung.blog</title><subtitle>eta_kyung의 개발 블로그입니다.</subtitle> <updated>2026-08-17T21:21:52+09:00</updated> <author> <name>eta_kyung</name> <uri>https://xoruddl.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://xoruddl.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="ko-KR" href="https://xoruddl.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 eta_kyung </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Docker (7) - 컨테이너 생명주기와 실행 옵션 정리</title><link href="https://xoruddl.github.io/posts/Docker-7-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EB%8B%A4%EB%A3%A8%EA%B8%B0/" rel="alternate" type="text/html" title="Docker (7) - 컨테이너 생명주기와 실행 옵션 정리" /><published>2026-08-17T20:45:00+09:00</published> <updated>2026-08-17T20:45:00+09:00</updated> <id>https://xoruddl.github.io/posts/Docker-7-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EB%8B%A4%EB%A3%A8%EA%B8%B0/</id> <content type="text/html" src="https://xoruddl.github.io/posts/Docker-7-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EB%8B%A4%EB%A3%A8%EA%B8%B0/" /> <author> <name>eta_kyung</name> </author> <category term="Docker" /> <summary>1. 개요 Docker(2)에서 docker run으로 컨테이너를 간단히 띄워봤지만, 실제로는 컨테이너가 어떤 상태를 거쳐 살아있고 사라지는지, run의 옵션들이 각각 무엇을 하는지, 컨테이너 내부와 파일을 어떻게 주고받는지를 알아야 제대로 다룰 수 있다. 이번 글에서는 이미지와 컨테이너의 관계부터 시작해서, 컨테이너의 생명주기, docker run 옵션, 파일 공유, exec/commit까지 컨테이너를 다루는 데 필요한 명령어들을 한 번에 정리한다. 2. 컨테이너란 무엇인가 이미지는 읽기 전용의 불변 값이고, Docker 엔진은 이 이미지 위에 읽고 쓰기 가능한 레이어를 하나 더 얹어서 컨테이너를 만든다. 즉 컨테이너는 이미지의 스냅샷이라고 볼 수 있다. 컴퓨터에서 동작하는 애플리케이션이 프...</summary> </entry> <entry><title>Docker (6) - 이미지를 파일로 저장하고 관리하기</title><link href="https://xoruddl.github.io/posts/Docker-6-%EC%9D%B4%EB%AF%B8%EC%A7%80-%ED%8C%8C%EC%9D%BC-%EA%B4%80%EB%A6%AC/" rel="alternate" type="text/html" title="Docker (6) - 이미지를 파일로 저장하고 관리하기" /><published>2026-08-17T20:10:00+09:00</published> <updated>2026-08-17T20:47:35+09:00</updated> <id>https://xoruddl.github.io/posts/Docker-6-%EC%9D%B4%EB%AF%B8%EC%A7%80-%ED%8C%8C%EC%9D%BC-%EA%B4%80%EB%A6%AC/</id> <content type="text/html" src="https://xoruddl.github.io/posts/Docker-6-%EC%9D%B4%EB%AF%B8%EC%A7%80-%ED%8C%8C%EC%9D%BC-%EA%B4%80%EB%A6%AC/" /> <author> <name>eta_kyung</name> </author> <category term="Docker" /> <summary>1. 개요 지금까지는 이미지를 항상 Docker Hub 같은 레지스트리에서 pull로 받아서 사용했다. 그런데 인터넷이 안 되는 폐쇄망이거나, 레지스트리를 거치지 않고 이미지를 바로 다른 서버로 옮기고 싶을 때는 이미지를 파일(tar)로 통째로 내보내고 다시 불러오는 방법이 필요하다. 이번 글에서는 이미지를 파일로 저장(save)하고 불러오는(load) 방법과, 더 이상 쓰지 않는 이미지를 정리하는 방법을 정리한다. 2. 이미지를 tar 파일로 저장하고 불러오기 docker image save는 이미지의 레이어 구조까지 그대로 보존한 상태로 tar 파일로 압축해준다. 단순히 파일 하나로 묶는 게 아니라, 원본 이미지와 동일하게 복원할 수 있는 형태로 저장된다는 점이 핵심이다. # 저장 dock...</summary> </entry> <entry><title>스프링 핵심 원리 (13) - List, Map으로 전략 패턴 구현하기와 자동/수동 등록 기준</title><link href="https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-13/" rel="alternate" type="text/html" title="스프링 핵심 원리 (13) - List, Map으로 전략 패턴 구현하기와 자동/수동 등록 기준" /><published>2026-08-17T09:00:00+09:00</published> <updated>2026-08-17T09:00:00+09:00</updated> <id>https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-13/</id> <content type="text/html" src="https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-13/" /> <author> <name>eta_kyung</name> </author> <category term="Spring" /> <category term="스프링 핵심 원리 기본편" /> <summary>1. 개요 앞 글에서는 같은 타입의 빈이 여러 개일 때 그중 하나만 골라서 주입받는 방법을 다뤘다. 그런데 반대로 같은 타입의 빈을 하나만 고르는 게 아니라 전부 다 받아서 써야 하는 경우도 있다. 스프링은 이럴 때 List나 Map으로 한 번에 주입받는 방법을 지원한다. 이번 글에서는 이 기능으로 전략 패턴을 얼마나 간단하게 구현할 수 있는지 살펴보고, 마지막으로 컴포넌트 스캔 같은 자동 등록과 @Configuration 기반의 수동 등록을 실무에서 각각 어떤 기준으로 나눠 쓰면 좋을지 정리한다. 2. 같은 타입의 빈을 전부 주입받기 - List, Map 할인 정책을 예로 들어보자. 지금까지는 DiscountPolicy 구현체 중 하나만 골라서 주입받았지만, 이번에는 클라이언트가 요청할 때마...</summary> </entry> <entry><title>스프링 핵심 원리 (12) - 조회 빈이 2개 이상일 때, @Qualifier와 @Primary</title><link href="https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-12/" rel="alternate" type="text/html" title="스프링 핵심 원리 (12) - 조회 빈이 2개 이상일 때, @Qualifier와 @Primary" /><published>2026-08-17T08:30:00+09:00</published> <updated>2026-08-17T08:30:00+09:00</updated> <id>https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-12/</id> <content type="text/html" src="https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-12/" /> <author> <name>eta_kyung</name> </author> <category term="Spring" /> <category term="스프링 핵심 원리 기본편" /> <summary>1. 개요 @Autowired는 타입을 기준으로 스프링 빈을 찾아서 주입한다. 지금까지 예제에서는 인터페이스를 구현한 빈이 하나뿐이었기 때문에 문제가 없었지만, 실무에서는 같은 인터페이스를 구현한 빈이 여러 개 등록되는 경우가 흔하다. 이번 글에서는 타입으로 조회했을 때 빈이 두 개 이상 걸리면 왜 오류가 나는지, 그리고 이를 해결하는 세 가지 방법인 필드명 매칭, @Qualifier, @Primary를 각각 언제 쓰는 게 좋은지 정리한다. 2. 타입 조회의 한계 - 빈이 2개 이상일 때 @Autowired는 내부적으로 타입을 기준으로 컨테이너에서 빈을 찾는다. 즉 다음 코드는 대략 getBean(DiscountPolicy.class)를 호출하는 것과 비슷하게 동작한다. @Autowired ...</summary> </entry> <entry><title>스프링 핵심 원리 (11) - 롬복과 최신 트렌드</title><link href="https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-11/" rel="alternate" type="text/html" title="스프링 핵심 원리 (11) - 롬복과 최신 트렌드" /><published>2026-08-16T15:20:00+09:00</published> <updated>2026-08-16T15:20:00+09:00</updated> <id>https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-11/</id> <content type="text/html" src="https://xoruddl.github.io/posts/%EC%8A%A4%ED%94%84%EB%A7%81%ED%95%B5%EC%8B%AC%EC%9B%90%EB%A6%AC-11/" /> <author> <name>eta_kyung</name> </author> <category term="Spring" /> <category term="스프링 핵심 원리 기본편" /> <summary>1. 개요 앞 글에서 생성자 주입을 기본으로 써야 하는 이유를 정리했다. 그런데 막상 실무 코드를 짜보면 대부분의 의존관계가 final 필드이고, 그 필드들을 그대로 받아 대입해주는 생성자를 매번 손으로 채워 넣어야 한다. 필드가 늘어나면 생성자 파라미터도, 대입 코드도 같이 늘어나는 반복 작업이다. 이번 글에서는 이 반복을 롬복(Lombok)으로 줄이는 방법과, 그 결과 최근 스프링 코드가 어떤 모습으로 수렴하고 있는지를 정리한다. 2. 반복되는 생성자 코드 생성자가 하나뿐이면 @Autowired는 생략할 수 있다는 것을 앞 글에서 확인했다. 그래도 아래처럼 필드 선언, 생성자 시그니처, 대입문을 다 손으로 써야 하는 건 여전하다. @Component public class OrderSer...</summary> </entry> </feed>
