Ⅰ. 서 론

현대 소프트웨어 개발에서는 개발한 결과물을 빠르 고 일관적인 배포가 중요하게 자리 잡고 있다. 이러한 기술들을 충족하기 위하여 가상화(virtualization) 기술 중의 하나인 컨테이너(container) 기술이 널리 사용되고 있다. 특히 2013년 Docker사에서 출시한 도커(docker) 는 컨테이너 기반의 애플리케이션 배포를 자동화하고 일관성을 유지하는 도구로 자리 잡고 있다^[1].

클라우드 컴퓨팅 분야에서 이미 많이 활용되고 있는 도커는 인공지능 기술을 활용하여 다양한 도메인에서 관련 서비스를 개발하면서부터 그 활용도는 더욱 커지 기 시작하였다. 다양한 도메인에서 사용되는 하드웨어 와 소프트웨어의 이질성을 극복하고, 개발한 인공지능 서비스를 쉽고 빠르게 도입하기 위해서 도커는 인공지 능 서비스 운용에 필요한 파일과 설정을 한개의 도커 이미지(docker image)에 담아서 처리한다. 도커파일 (dockerfile)은 도커 이미지를 정의하는 파일로 효율적 인 도커 이미지의 생성과 배포의 시작이 된다. 하지만 도커파일을 잘못 구성하면 도커 이미지 크기가 불필요 하게 커질 수 있고 그로 인한 빌드 시간과 배포 속도에 영향을 미칠 수 있다^[4].

도커 이미지 크기와 빌드 시간이 커질수록 애플리케 이션의 배포와 운영에 여러 문제가 발생하게 된다. 크기 가 큰 도커 이미지는 전송할 때 시간이 더 소요되고 불필요한 리소스를 차지하게 되는 등 배포 주기를 지연 시키게 된다. 또, 보안에서도 도커 이미지가 클수록 잠 재적인 취약점이 증가하게 된다. 이런 문제는 클라우드 환경에서 여러 컨테이너를 동시에 운영할 때 취약해지 고 전체적인 시스템의 효율성을 저하시킨다. 따라서 도 커 이미지의 경량화는 소프트웨어 배포 효율성 뿐만 아 니라 보안성, 운영비용 절감 측면에서도 중요한 과제가 될 수 있다^[9].

또한, 인공지능 서비스가 자원 제약적 디바이스에서 운영되는 경우, 도커 이미지의 경량화는 더욱 중요한 문제가 된다. 예를 들어, GPU가 없는 저사양 디바이스 에서는 처리 속도를 높이기 위해 도커 이미지의 크기를 최소화하는 것이 필수적이다. 경량화된 도커 이미지는 자원 제약적인 환경에서 더 빠르게 실행될 수 있으며, 제한된 자원에서 최적의 성능을 발휘하도록 도와준다.

본 연구에서는 도커 이미지를 만들 때 사용되는 다양 한 베이스 이미지를 활용한 빌드 시간, 이미지 크기, 성능 등을 비교하고 분석한다. 이를 통해 각각의 베이스 이미지의 장단점을 도출하고 python 기반 애플리케이 션을 개발하는 상황에서 가장 가볍고 사용하기 좋은 베이스 이미지를 선출하고 도커 이미지를 경량화하기 위한 도커파일의 구성 방안을 제시하고자 한다. 먼저 2장에서는 도커의 작동 방식과 구성, 도커 이미지에 관 한 내용을 기술한다. 3장에서는 도커 이미지 경량화를 위한 실험을 수행하고, 다양한 방법을 적용하여 도커 이미지 크기를 줄이는 과정과 그 결과에 대해 서술한다. 4장에서는 실험 결과를 바탕으로 캐싱 전략, 베이스이 미지 선택, 레이어 최적화, 불필요한 캐시 제거, 다단계 빌드의 활용 등 도커 이미지 최적화의 중요성에 대해 고찰한다. 마지막 5장에서는 연구의 결론을 도출하고, 향후 연구에 관해 기술한다.

Ⅱ. 기술 배경

2.1 도커

도커는 컨테이너 기술을 기반으로 애플리케이션을 일관성 있게 해주는 오픈 소스 플랫폼이다^{[1, 9]}. 도커를 사용하면 개발, 테스트 과정에서 발생하는 오류를 최소 화 할 수 있다. 이런 도커의 특성 덕분에 다양한 오픈 소스 프로젝트들이 도커를 기반으로 운영되고 있다.

그림 1처럼 도커는 클라이언트-서버 구조로 나누어 져 있고 클라이언트에서 명령어를 실행하면 도커 데몬 (daemon)이 컨테이너, 이미지 등을 관리하며 돌아가게 된다^[1].

도커 기술을 활용한 대표적인 예로 EdgeX Foundry 와 ROS(Robot Operating System)를 들 수 있다. EdgeX Foundry에서 배포되는 소프트웨어는 에지 컴퓨 팅 환경에서 소프트웨어를 쉽고 빠르게 배포하기 위하 여 마이크로서비스 기반의 다수의 도커 이미지를 기반 으로 구성되어 있다. ROS는 로봇 뿐만 아니라 자율주 행 분야에서 소프트웨어를 효율적으로 배포하기 위하 여 도커 이미지로 개발되고 있다. 그림 2와 그림 3에서 보는 것과 같이 여러 오픈소스와 플랫폼에서 도커를 사 용하는 것을 확인할 수 있다.

2.2 도커 이미지

도커 이미지는 애플리케이션을 실행하기 위한 모든 파일과 설정을 포함하는 파일 시스템이다. 도커 이미지 는 도커파일을 기반으로 빌드되고 여러 레이어(Layer) 를 쌓는 형태로 구성되어 있다. 도커 이미지는 컨테이너 를 실행하는 템플릿 역할을 하며 여러 컨테이너에서 동 일한 이미지를 재사용할 수 있다.

2.3 도커 컨테이너

도커 컨테이너는 도커 이미지를 기반으로 실행되는 독립적인 환경이다. 도커 컨테이너는 환경에 필요한 모 든 종속성을 포함하고 있고 필요한 리소스만 사용하여 가상환경보다 경량화 되어 있으며 효율을 극대화할 수 있다^[2].

2.4 베이스 이미지

모든 도커 이미지는 베이스 이미지로 시작된다. 베이 스 이미지는 OS(Operating System), 런타임, 라이브러 리 등 기본 환경을 제공하고 거기에 더해 애플리케이션 코드와 추가적인 설정을 더해주면 최종 도커 이미지를 완성할 수 있게 된다. 상황에 맞는 적절한 베이스 이미 지를 선택하는 것이 도커 이미지의 크기, 빌드 시간, 성능에 크게 영향을 줄 수 있다^[3].

2.5 도커파일

도커파일에서 명령어를 읽어서 도커 이미지를 빌드 한다. 도커파일은 소스코드를 빌드하기 위한 명령어가 들어있는 텍스트 파일이다^[4].

Ⅲ. 도커 이미지 경량화를 위한 실험

3.1 도커파일에서 캐싱(caching)을 활용하여 재빌드 시 빌드 속도 최적화

도커파일 명령어가 한 줄 씩 실행될 때마다 새로운 레이어가 생성되는데, 도커 이미지를 빌드할 때 자주 변경되는 부분이 도커파일의 상단에 위치하면 레이어 캐싱을 제대로 활용하지 못하게 된다. 이를 방지하려면 자주 변경되는 부분을 도커파일의 하단에 배치해야 하 며, 이를 통해 이전에 빌드된 레이어의 캐싱을 활용하여 재빌드 시간을 단축할 수 있다^[5].

그림 4는 레이어 캐싱이 잘 적용된 도커파일을 보여 준다. 여기서는 자주 변경되지 않는 파일을 상단에 배치 하여, 재빌드 시 레이어 캐싱을 활용해 빌드 시간을 단 축할 수 있다.

반면,그림 5는 레이어 캐싱이 제대로 적용되지 않은 도커파일을 나타낸다. 예를 들어, ‘requirements.txt’와 같은 의존성 파일은 자주 변경되지 않지만, ‘test.py’와 같은 애플리케이션 코드 파일은 상대적으로 자주 변경 된다. 만약 도커파일이 그림 5처럼 구성되어 있다면, ‘test.py’와 같은 자주 변경되는 파일이 상단 부분에 위 치하게 된다. 그러면 애플리케이션 파일이 수정될 때 마다 도커는 그 아래의 모든 명령어(예: ‘requirements.txt’를 추가한 후 ‘pip install’을 실행하는 과정)를 반복하게 된다. 그 결과, 매번 ‘pip install -r requirements.txt’명령이 실행되어 의존성 설치 과정이 반복되고, 빌드 시간이 불필요하게 길어질 수 있다.

그림 6과 그림 7은 각각 그림 4와 그림 5의 도커파일 을 재빌드한 결과를 보여준다. 자주 변경되지 않는 부분 을 상단에 배치하고, 자주 변경되는 부분을 하단에 배치 하면, 자주 변경되지 않은 레이어는 캐싱되어 재사용되 고, 변경된 부분만 새로 빌드할 수 있다. 이로 인해 빌드 시간이 크게 줄어든 것을 확인할 수 있었다.

첫 번째 빌드에서는 모든 레이어가 새로 생성되므로 빌드 시간이 길어지지만, 이후 빌드에서는 변경되지 않 은 레이어가 캐시로 재사용되어 빌드 시간이 크게 단축 되는 것을 확인할 수 있었다(그림 6, 그림 7참고). 이를 통해 도커파일의 레이어 구조를 최적화하여, 반복 빌드 에서 효율성을 극대화할 수 있음을 실험적으로 확인할 수 있다.

3.2 최적의 경량화 베이스 이미지 선정 및 빌드 시간, 이미지 크기 비교

본 연구에서 사용하는 베이스 이미지는 다음과 같다

· python:3.8 : python 기반의 표준 이미지로 일반 적인 개발 환경에 적합하다. 다양한 라이브러리와 도구가 포함되어 있어 대부분의 python 애플리케 이션 개발에 사용된다^[6].

· python : 3.8-slim : 경량화된 python 이미지로 최 소한으로 필요한 라이브러리만 포함되어 있다. 이 미지 크기를 줄이고 불필요한 패키지를 제거해 최 적화된 개발 환경을 제공한다^[6].

· python : 3.8-alpine : Alpine Linux 기반의 경량화 된 python 이미지로 이미지 크기가 매우 작아 배 포와 네트워크 전송 시 효율적이다^[6].

Python 애플리케이션에서 가장 경량화된 베이스 이 미지를 선정하기 위해 간단한 코드인 (print(‘Hello World’))가 실행이 될 수 있게 작성하고(‘test.py’), 위 베이스 이미지를 사용하여 빌드한 후,각 이미지의 빌드 시간과 최종 이미지 크기를 비교 분석한다.

실험의 통일성을 위해 그림 8처럼‘requirements.txt’ 를 동일하게 맞춰주었다.

그림 9는 python:3.8 베이스 이미지를 사용한 도커파 일를 보여준다. 도커파일에서는 기본 python 베이스이 미지를 사용하여 간단한 print('Hello World') 코드를 실행할 수 있도록 설정되어 있다. 일반적인 python 환 경을 제공한다^[6].

그림 10은 python:3.8 베이스 이미지를 기반으로 한 도커파일(그림 9)을 빌드하는 과정에서의 출력 로그를 보여준다. 그림 10을 보면 빌드 시간이 147.1초 걸린 것을 확인할 수 있다.

그림 11을 보면 그림 10이 빌드된 후 최종적으로 생 성된 도커 이미지의 크기를 보여준다. 이 도커 이미지의 크기는 3.05GB으로 나온 것을 확인할 수 있다.

그림 12는 python:3.8-slim 베이스 이미지를 사용한 도커파일을 보여준다. python:3.8 베이스 이미지보다 경량화된 python:3.8-slim 베이스 이미지는 불필요한 라이브러리와 패키지를 제거하여 필요한 최소한의 환 경만을 포함하고 있다. 도커파일은 동일하게 print('Hello World') 코드를 실행할 수 있도록 설정되 어 있다.

그림 13은 python:3.8-slim 베이스 이미지를 기반으 로 한 도커파일(그림 12)을 빌드하는 과정에서의 출력 로그를 보여준다. 그림 13을 보면 빌드 시간이 164.9초 걸린 것을 확인할 수 있다.

그림 14를 보면 그림 13이 빌드된 후 최종 생성된 도커 이미지의 크기를 보여준다. 이 도커 이미지의 크기 는 1.93GB로, 표준 python:3.8 베이스 이미지보다 상당 히 작은 크기임을 확인할 수 있고 python:3.8베이스 이미지보다 python:3.8-slim 베이스 이미지가 경량화에 얼마나 효과적인지를 나타낸다.

그림 15는 python:3.8-alpine 베이스 이미지를 사용 한 도커파일을 보여준다. python:3.8-alpine 베이스 이 미지는 Alpine Linux 기반으로 매우 작은 크기의 경량 화된 python 베이스 이미지를 제공한다. 도커파일은 동 일하게 print('Hello World') 코드를 실행할 수 있도록 설정되어 있다.

그림 16은 python:3.8-alpine 베이스 이미지를 사용 하여 도커파일(그림 15)을 빌드하는 과정에서의 출력 로그를 보여준다. 그림 16을 보면 빌드 시간이 2,423.1 초 걸린 것을 확인할 수 있다.

그림 17을 보면 그림 16이 빌드된 후 최종 생성된 도커 이미지의 크기를 보여준다. 이 도커 이미지의 크기 는 700MB로, 실험한 모든 베이스 이미지 중에서 가장 작은 크기를 가지고 있다.

많은 python 라이브러리는 내부적으로 C로 구현되 어 있으며, 인터페이스만 python으로 제공되어 있는 경 우가 많다. 대표적으로 NumPy, Keras, Pandas와 같은 라이브러리들이 이에 해당된다. python을 돌리기 위해 서는 glibc 라는 C언어 컴파일을 위한 시스템 라이브러 리를 가지고 있어야 하지만 python:3.8-alpine은 glibc 를 사용하지 않고 musl를 사용하고 있다. py- thon:3.8-alpine 버전을 사용하면 binary wheel을 사용 하지 못하므로 모든 python 패키지의 C코드를 컴파일 해야 한다. 그래서 빌드 시간이 가장 많이 걸린다^{[7, 8]}.

3.3 도커파일 경량화 실험

3.3.1 & 연산자를 사용하여 레이어 수 줄이기

& 연산자는 여러 명령어를 하나의 RUN 명령어로 결합하여 레이어 수를 줄이는 데 사용된다. 이는 도커 이미지의 크기를 줄이는 데에 큰 도움을 줄 수 있다.

그림 18은 RUN 명령어가 독립적으로 실행되며 각 명령어가 새로운 레이어를 생성한다.

그림 19는 RUN 명령어를 &으로 결합하여 여러 줄의 명령어를 하나의 레이어로 묶어 실행되도록 한 것 이다.

그림 20은 & 연산자를 사용하지 않는 도커파일을 빌드한 결과를 보여준다.

그림 21은 & 연산자를 사용하여 여러 명령어를 하나의 RUN 명령어로 결합한 도커파일을 빌드한 결과 를 보여준다. 명령어들이 하나의 레이어로 결합되어 빌 드되며, 이로 인해 빌드 시간이 줄어드는 것을 보여준 다.

본 3-3-1절 실험을 통해 & 연산자를 사용하여도 커파일의 레이어 수를 줄이면 빌드 시간이 대략 36초 단축되는 것을 확인했다. 또한, 그림 22의 결과를 보면 & 연산자를 사용한 도커파일의 도커 이미지(2.43GB) 가 & 연산자 사용하지 않은 도커파일의 도커 이미지 (2.5 GB)에 비해 0.07GB만큼 이미지 크기가 더 작아지 는 결과를 볼 수 있다.

3.3.2 불필요한 캐시를 삭제하는 실험

도커 이미지의 크기를 줄이기 위한 방법 중 하나는 불필요한 캐시 파일을 삭제하는 것이다. 캐시는 rm -rf /var/lib/apt/lists/* 명령어를 통해 삭제할 수 있다. 도커 파일에서 apt-get update 명령어를 사용하여 패키지 목 록을 업데이트하고, apt-get install 명령어로 패키지를 설치한 후, 패키지 목록이 /var/lib/apt/lists/ 디렉토리에 저장되는데 이 디렉토리의 내용은 패키지 설치가 끝난 후 더 이상 필요하지 않으므로, 이 캐시 파일을 삭제하 여 도커 이미지의 크기를 줄이는 데에 도움을 준다.

그림 23은 apt-get update와 apt-get install 명령어를 사용한 후, 캐시 파일을 삭제하지 않은 도커파일을 보여 준다. 이러한 도커파일은 불필요한 캐시 파일을 포함하 여 최종 이미지의 크기가 불필요하게 커질 수 있다.

그림 24는 apt-get update와 apt-get install 명령어를 사용한 후, rm -rf /var/lib/apt/lists/* 명령어를 추가하여 캐시 파일을 삭제한 도커파일을 보여준다. 이러한 도커 파일은 불필요한 파일을 제거하여 최종 이미지의 크기 를 줄이는데 도움을 줄 수 있다.

그림 25는 그림 23의 도커파일를 빌드한 모습이다. 불필요한 캐시 파일이 포함된 상태로 빌드되어 최종이 미지의 크기가 불필요하게 커질 수 있다. 실제로 최종 이미지 크기는 2.55GB가 나왔다.

그림 26은 그림 24의 도커파일를 빌드한 모습이다. 불필요한 파일이 제거된 상태로 빌드되어 최종 이미지 의 크기가 작아지게 도움을 준다. 실제로 최종 이미지 크기는 2.53GB가 나왔다.

그림 27의 이미지 크기를 보면 불필요한 캐시 파일 을 삭제한 도커파일이 그렇지 않은 경우에 비해 최종 이미지 크기가 더 작아진 것을 확인할 수 있었다. 불필 요한 캐시파일을 삭제하지 않은 경우 이미지 크기는 2.55GB로 나왔고 불필요한 캐시 파일을 삭제한 경우의 이미지 크기는 2.53GB로 줄어든 걸 확인할 수 있다.

3.3.3 다단계 빌드를 활용한 실험

다단계 빌드는 빌드 과정에서 필요한 도구와 라이브 러리는 중간 단계에서만 사용하고, 최종 도커 이미지에 꼭 필요한 것만 남기기 때문에 도커 이미지 크기를 경량 화 시킬 수 있다.

그림 28은 다단계 빌드를 사용하지 않은 도커파일을 보여주고 있다. 모든 빌드 도구와 라이브러리가 최종 이미지에 포함되어 있다.

그림 29는 다단계 빌드를 사용한 도커파일을 보여주 고 있다. 중간 단계에서는 코드 빌드에 필요한 모든 도 구와 라이브러리가 포함되지만, 최종 단계에서는 꼭 필 요한 파일만 포함되어 있기 때문에 최종 도커 이미지의 크기 경량화하는 것에 도움을 준다.

그림 30을 보면 다단계를 이용하지 않은 도커 이미 지보다 다단계를 이용한 도커 이미지의 크기가 훨씬 작아진 걸 확인할 수 있다. 실제로 다단계 빌드를 사용 하지 않는 도커 이미지의 크기는 1.91GB가 나왔고 다 단계 빌드를 사용한 도커 이미지의 크기는 209MB로 도커 이미지의 크기가 크게 경량화된 것을 확인할 수 있었다.

Ⅳ. 도커 이미지 경량화 실험에 대한 고찰

4.1 캐싱의 중요성

도커는 빌드 과정에서 각 단계의 결과를 캐시하여 빌드 시간을 단축할 수 있다. 이 캐싱은 동일한 도커파 일이 반복될 때 매우 유용하지만, 캐시를 효과적으로 활용하려면 명령어의 순서가 중요하다. 자주 변경되지 않는 명령어는 상단에 배치하고, 자주 변경되는 명령어 는 하단에 배치하여 레이어 캐시를 효율적으로 활용할 수 있다. 예를 들어, 종속성 설치와 같은 작업을 먼저 수행하고, 이후 애플리케이션 소스 코드를 복사하면 종 속성 변경에 따라 전체 도커 이미지를 재빌드하지 않아 도 되는 것을 확인할 수 있었다^[5].

4.2 베이스 이미지의 중요성

· 이미지 크기: python:3.8-alpine 베이스 이미지는 가장 작은 크기를 제공하여, 저장 공간 측면에서 가장 효율적이다. python:3.8 베이스 이미지는 상 대적으로 큰 베이스 이미지의 크기를 가지고 있는 것을 확인했다.

· 빌드 시간: python:3.8-alpine 베이스 이미지는 가 장 긴 빌드 시간을 기록했다. 이는 Alpine Linux의 musl 사용으로 인해 많은 라이브러리의 C 코드 컴 파일이 필요하기 때문이다^[7]. python:3.8 베이스

이미지의 빌드 시간은 상대적으로 짧은 것을 확인 했다.

표 1은 3-3-2절에 있는 실험의 도커 python 베이스 이미지의 크기와 빌드 시간을 비교한 것이다. py- thon:3.8 베이스 이미지와 python:3.8-slim 베이스 이미 지는 상대적으로 짧은 빌드 시간을 나타냈다. 따라서, python:3.8-slim 베이스 이미지는 빌드 시간과 이미지 크기 간의 균형을 잘 맞춘 옵션으로, 대부분의 일반적인 python 애플리케이션에 적합하다. python:3.8-alpine 베이스 이미지는 가장 경량화된 이미지이지만, C 라이 브러리와의 호환성 문제로 인해 긴 빌드 시간을 고려해 야한다. python:3.8 베이스 이미지는 기능이 풍부하지 만, 도커 이미지 크기 면에서 가장 무겁다^[7,8].

· python:3.8 베이스 이미지의 크기는 3123.2MB로 가장 크고 빌드 시간은 147초 가장 짧게 나왔다.

· python:3.8-slim 베이스 이미지의 크기는 1979.52MB로 상대적으로 작게 나왔고 빌드 시간 은 164초로 나왔다.

· python:3.8-alpine 베이스 이미지의 크기는 700MB로 가장 작게 나왔지만 빌드 시간은 2423.1 초로 가장 길게 나왔다.

표 2는 표 1의 데이터를 시각적으로 표현한 그래프 이다.

4.3 레이어 최적화의 중요성

도커파일은 RUN, COPY, ADD 명령어마다 새로운 레이어를 생성된다. 레이어 수를 줄이는 것은 도커 이미 지의 경량화 뿐만 아니라 빌드 속도에도 영향을 주고 있다. 여러 RUN 명령어를 & 연산자를 사용하여 하 나로 결합하면 레이어 수를 줄일 수 있다.

4.4 불필요한 캐시 제거의 중요성

도커 이미지의 최종 크기를 줄이는 데 있어 불필요한 캐시 제거는 효과적인 방법이다. --no-cache-dir 플래그 를 사용하여 pip 다운로드 캐시를 제거하면, 최종 이미 지에서 불필요한 파일이 줄어들어 경량화 할 수 있다.

4.5 다단계 빌드 활용의 중요성

다단계 빌드는 복잡한 빌드 환경을 단순화하고 최종 도커 이미지를 경량화 하는 데 유용하다. 필요한 도구와 파일을 빌드 과정에서만 사용하고 최종 도커 이미지에 서 제외할 수 있기 때문에 도커 이미지의 크기가 줄어드 는 것을 확인할 수 있다.

Ⅴ. 결 론

본 논문에서는 자원 제약적 디바이스에서 도커를 활 용하기 위한 도커 이미지 경량화 연구를 통해 도커 이미 지의 경량화와 빌드 성능 최적화를 위한 다양한 전략의 효과를 확인할 수 있었다. 캐싱을 효율적으로 활용하기 위해 명령어 순서를 최적화하여 빌드 시간을 단축할 수 있음을 확인하였다. 자주 변경되지 않는 명령어를 상단 에 배치하고, 자주 변경되는 명령어를 하단에 배치함으 로써 캐시를 효과적으로 활용할 수 있었다. 또한, 적절 한 베이스 이미지를 선택하는 것이 중요하다는 것을 확 인할 수 있었다. 예를 들어, python:3.8-alpine 베이스 이미지는 가장 작은 크기를 제공하지만 빌드 시간이 길 다는 단점이 있다. 반면, python:3.8-slim 베이스 이미 지는 빌드 시간과 이미지 크기 간의 균형을 잘 맞춘 옵션으로, 대부분의 일반적인 python 애플리케이션에 적합하다. RUN 명령어를 & 연산자로 결합하여 레이 어 수를 줄임으로써 도커 이미지의 크기와 빌드 속도를 개선할 수 있었다. apt 패키지 관리자의 캐시 파일을 삭제하여 도커 이미지의 크기를 줄이는 효과를 확인하 였다. 또한, 다단계 빌드를 활용하여 빌드 과정에서만 필요한 도구와 파일을 최종 이미지에서 제외함으로써 도커 이미지의 크기를 크게 줄일 수 있었다.

향후 연구에서는 객체 인식과 같은 무거운 python 기반 딥러닝/머신러닝 애플리케이션을 대상으로 한 도 커 이미지 최적화 방안에 대해 연구할 필요가 있다고 생각한다. 이러한 애플리케이션은 더 많은 라이브러리 와 종속성을 필요로 하므로, 더욱 효율적인 캐싱 전략 과 레이어 최적화 방안이 요구된다. 이를 통해 도커 이미지를 더욱 경량화하고 빌드 성능을 최적화할 수 있을 것이다.