4. 소스를 수정하면 Docker는 어떻게 동작할까?

 

📚 Docker & Kubernetes 시리즈

이전 글에서는 Dockerfile을 이용해 Spring Boot 애플리케이션을 Docker Image로 만드는 과정을 알아봤다.

그런데 개발을 하다 보면 자연스럽게 이런 의문이 생긴다.

"소스를 수정했는데 실행 중인 Docker Container에도 자동으로 반영될까?"

 

 

정답은 아니다.

Docker를 이해할 때 가장 중요한 개념은 Docker Image는 변경되지 않는다는 것(Immutable) 이다.

 

즉, 소스를 수정했다고 해서 기존 Image가 변경되는 것이 아니라, 변경 사항을 반영한 새로운 Image를 생성해야 한다.

이번 글에서는 이 개념을 중심으로 Docker가 실제로 어떻게 동작하는지 알아보자.

 

 

---

Docker Container는 Image를 기반으로 생성된다

Docker의 실행 과정은 다음과 같다.

Spring Boot 프로젝트
        │
        ▼
Gradle Build
        │
        ▼
JAR 생성
        │
        ▼
docker build
        │
        ▼
Docker Image 생성
        │
        ▼
docker run
        │
        ▼
Container 실행

 

여기서 중요한 점은 Container는 Docker Image를 기반으로 생성된다는 것이다.

 

즉,

• Dockerfile은 Image를 만들 때만 사용된다.
• Container는 이미 만들어진 Image를 그대로 실행한다.

 

Container가 실행된 이후에는 Dockerfile이나 프로젝트 소스를 다시 확인하지 않는다.

 

 

---

소스를 수정해도 Container는 변하지 않는다

예를 들어 현재 실행 중인 애플리케이션이 있다고 가정해 보자.

Spring Boot 프로젝트

↓

Docker Image A

↓

Container A 실행

 

이 상태에서 Controller의 코드를 수정했다고 해보자.

 

 

기존 코드

@GetMapping("/hello")
public String hello() {
    return "Hello Docker!";
}

 

 

수정 후

@GetMapping("/hello")
public String hello() {
    return "Hello World!";
}

 

소스를 수정했더라도 실행 중인 Container에는 아무런 변화가 없다.

왜냐하면 현재 실행 중인 Container는 기존 Docker Image A를 기반으로 만들어졌기 때문이다.

프로젝트 소스를 수정했다고 해서 이미 생성된 Image나 실행 중인 Container가 자동으로 변경되지는 않는다.

 

 

---

변경 사항을 반영하려면?

소스를 수정했다면 다음 과정을 다시 수행해야 한다.

 

1. 프로젝트 빌드
2. 새로운 Jar 생성
3. 새로운 Docker Image 생성
4. 기존 Container 종료
5. 새로운 Container 실행

 

흐름으로 보면 다음과 같다.

Spring Boot 소스 수정
        │
        ▼
Gradle Build
        │
        ▼
새로운 JAR 생성
        │
        ▼
docker build
        │
        ▼
새로운 Docker Image 생성
        │
        ▼
기존 Container 종료
        │
        ▼
새 Container 실행

 

즉, 변경 사항을 적용하려면 새로운 Image를 생성한 후 새로운 Container를 실행해야 한다.

 

 

---

왜 docker build를 다시 해야 할까?

Docker를 처음 접하면 이런 생각을 하기 쉽다.

"Container만 다시 실행하면 되는 거 아닌가?"

 

 

하지만 docker run은 Image를 실행하는 명령어일 뿐이다.

Image 자체가 변경되지 않았다면 새로운 Container를 만들어도 이전 코드가 그대로 실행된다.

 

 

예를 들어,

docker run my-app

 

을 다시 실행하더라도 사용되는 것은 여전히 기존 Image이다.

 

 

따라서 먼저 새로운 Image를 만들어야 한다.

./gradlew bootJar

docker build -t my-app .

 

그 후 새로운 Image를 기반으로 Container를 실행해야 수정된 코드가 반영된다.

 

 

---

개발 환경에서는 매번 Build를 하지 않을까?

매번 Build를 수행하면 개발 속도가 느려질 수 있다.

그래서 개발 환경에서는 Bind Mount(볼륨 마운트) 기능을 사용하는 경우가 많다.

Bind Mount를 사용하면 호스트의 소스 코드와 Container 내부를 연결하여 파일 변경 사항을 바로 확인할 수 있다.

 

반면 운영 환경에서는 소스 코드를 직접 연결하지 않는다.

항상 새로운 Docker Image를 생성한 뒤 배포하는 방식을 사용한다.

 

 

즉,

• 개발 환경 → Bind Mount 등을 활용해 빠르게 개발
• 운영 환경 → 새로운 Docker Image를 생성하여 배포

 

라는 차이가 있다.

 

 

---

실무에서는 어떻게 배포할까?

실무에서는 개발자가 직접 docker build 명령을 실행하여 운영 서버에 배포하는 경우는 많지 않다.

일반적으로 CI/CD 파이프라인을 이용해 빌드와 배포를 자동화한다.

Git Push
        │
        ▼
Jenkins
        │
        ▼
Gradle Build
        │
        ▼
Docker Build
        │
        ▼
Docker Registry
        │
        ▼
Argo CD
        │
        ▼
Kubernetes
        │
        ▼
새로운 Pod 생성
        │
        ▼
Health Check
        │
        ▼
서비스 반영

 

개발자가 Git에 코드를 Push하면 Jenkins가 자동으로 프로젝트를 빌드하고 새로운 Docker Image를 생성한다.

생성된 이미지는 Docker Registry에 저장되고, Argo CD는 변경된 이미지를 감지하여 Kubernetes에 배포를 수행한다.

Kubernetes는 새로운 Pod를 생성한 뒤 Health Check를 수행하며, 애플리케이션이 정상적으로 기동된 것이 확인되면 기존 Pod를 종료하고 새로운 Pod로 서비스를 전환한다.

이러한 방식 덕분에 서비스 중단을 최소화하면서 안정적으로 배포할 수 있다.

 

 

---

정리

Docker에서 가장 중요한 개념 중 하나는 Docker Image는 변경되지 않는다(Immutable) 는 것이다.

소스를 수정했다고 해서 실행 중인 Container가 자동으로 변경되지는 않는다.

변경 사항을 적용하려면 다음 과정을 다시 수행해야 한다.

소스 수정
        │
        ▼
프로젝트 Build
        │
        ▼
새로운 JAR 생성
        │
        ▼
docker build
        │
        ▼
새로운 Docker Image 생성
        │
        ▼
docker run
        │
        ▼
새로운 Container 실행

 

즉, Docker는 기존 Image를 수정하는 방식이 아니라 새로운 Image를 생성하고, 그 이미지를 기반으로 새로운 Container를 실행하는 방식으로 동작한다.

이러한 구조 덕분에 개발 환경과 운영 환경에서 동일한 실행 환경을 유지할 수 있으며, 안정적인 배포가 가능하다.

 

 

---

다음 글

지금까지 Docker Image와 Container의 동작 원리를 알아봤다.

Docker에서 소스를 수정하면 새로운 Docker Image를 생성해야 한다는 것도 확인했다.

그렇다면 또 하나의 궁금증이 생긴다.

 

"생성한 Docker Image는 어디에 저장하고 관리할까?"

 

 

개발 환경에서는 로컬에 이미지를 저장할 수 있지만, 여러 개발자가 함께 작업하거나 운영 서버에 배포하려면 이미지를 저장하고 공유할 수 있는 저장소가 필요하다.

다음 글에서는 Docker Registry란 무엇인지, 그리고 Docker Hub를 비롯한 이미지 저장소의 역할과 사용 방법을 알아보겠다.