도커 이미지는 어디에 저장될까? 컨테이너 이미지 저장소(Registry) 완벽 이해

애플리케이션 개발을 마치고 실제 운영 서버에 배포할 때, 최근 실무 환경에서는 대부분의 애플리케이션을 도커(Docker) 이미지로 구워내어 컨테이너 환경에 배포하곤 합니다. 코드를 압축해서 서버에서 실행할 수 있는 독립적인 패키지로 만드는 과정이죠.

그런데 여기서 한 가지 의문이 생기지 않으시나요? 내 로컬 컴퓨터에서 열심히 빌드해서 만든 이 무거운 도커 이미지들을 서버에 배포하려면, 대체 어디에 올려두어야 할까요? 코드는 깃허브(GitHub)에 올리면 되는데, 도커 이미지는 대체 어디로 가야 하는 걸까요?

오늘은 이 궁금증을 해결해 줄 핵심 인프라, '컨테이너 이미지 저장소(Container Registry)'에 대해 확실하게 짚고 넘어가 보겠습니다.

1. 컨테이너 이미지 저장소(Registry)란 무엇인가요?

가장 쉽게 이해하는 방법은 우리 개발자들에게 친숙한 'Git'과 비교해 보는 것입니다.

우리가 작성한 소스 코드를 다른 팀원과 공유하거나 서버로 가져가기 위해 GitHub나 GitLab 같은 '소스 코드 저장소'에 올리죠? 컨테이너 이미지 저장소도 이와 완전히 똑같은 역할을 합니다. 단지 보관하는 내용물이 소스 코드가 아니라, 실행 가능한 상태로 압축된 '도커 이미지'라는 점만 다릅니다.

로컬에서 개발을 마치고 도커 이미지를 빌드한 뒤, 이 저장소에 이미지를 밀어 넣습니다(Push). 그리고 실제 운영될 서버(AWS EC2, Kubernetes 등)에서는 이 저장소에 접속해 이미지를 당겨와서(Pull) 실행하게 됩니다. 즉, 개발 환경과 운영 환경 사이에서 완성된 애플리케이션을 안전하게 보관하고 전달해 주는 물류 창고 역할을 하는 셈입니다.

2. 퍼블릭(Public) 저장소 vs 프라이빗(Private) 저장소

이미지 저장소는 접근 권한에 따라 크게 두 가지로 나뉩니다.

퍼블릭(Public) 저장소

누구나 접근해서 이미지를 다운로드할 수 있는 개방된 창고입니다. 가장 대표적인 곳이 바로 Docker Hub(도커 허브)입니다. 우리가 처음 도커를 배울 때 터미널에 docker pull nginx나 docker pull postgres를 입력하면 이미지가 스르륵 다운로드되는데, 이때 이미지를 가져오는 출처가 바로 도커 허브라는 퍼블릭 저장소입니다.

오픈소스 프로젝트나 누구나 써도 되는 공용 이미지를 배포할 때는 아주 유용합니다. 하지만 우리 회사의 핵심 비즈니스 로직이 담긴 애플리케이션 이미지를 이곳에 올린다면 어떻게 될까요? 전 세계 누구나 우리 시스템의 코드를 뜯어볼 수 있게 되는 대참사가 벌어지겠죠.

프라이빗(Private) 저장소

그래서 실제 기업의 실무 환경에서는 반드시 프라이빗 저장소를 사용합니다. 인가된 사용자나 인증된 서버 시스템만이 접근해서 이미지를 올리거나 받을 수 있도록 철저하게 권한이 통제된 창고입니다.

직접 서버를 구축해서 프라이빗 저장소를 만들 수도 있지만, 관리 포인트가 늘어나기 때문에 보통은 클라우드 제공자(CSP)가 서비스하는 관리형 프라이빗 저장소를 많이 사용합니다.

• AWS: ECR (Elastic Container Registry)
• Google Cloud: GAR (Artifact Registry)
• Azure: ACR (Azure Container Registry)

3. 실무에서 클라우드 프라이빗 저장소(ECR, GAR)를 선호하는 이유

보안 때문이라면 도커 허브의 유료 프라이빗 플랜을 쓰거나, 사내 서버에 직접 구축해도 될 텐데 왜 굳이 AWS ECR이나 GCP GAR 같은 클라우드 저장소를 사용할까요?

첫째, 네트워크 전송 속도와 비용 때문입니다. 이미지는 텍스트인 코드와 달리 용량이 수백 메가바이트에서 기가바이트 단위에 이릅니다. 만약 서버는 AWS 서울 리전에 있는데, 이미지 저장소는 외부에 있다면 배포할 때마다 거대한 용량의 이미지를 외부 인터넷을 통해 다운로드해야 합니다. 속도도 느리고 네트워크 트래픽 비용도 발생하죠. AWS ECR을 사용하면 같은 AWS 내부망을 타기 때문에 배포 속도가 비약적으로 빠르고 비용도 절약됩니다.

둘째, 강력한 권한 관리(IAM)와의 연동입니다. 실무에서는 CI/CD 파이프라인(예: GitHub Actions)이 자동으로 이미지를 푸시하고, 쿠버네티스(Kubernetes) 노드들이 자동으로 이미지를 풀(Pull) 합니다. 클라우드 저장소를 사용하면 클라우드의 자체 권한 관리 시스템(IAM)을 통해 "A 서버는 읽기만 가능, B 파이프라인은 쓰기 가능"과 같이 매우 정교하고 안전하게 권한을 부여할 수 있습니다.

4. 마치며: 이미지를 모아두는 것만으로는 부족하다

오늘은 개발이 완료된 애플리케이션이 도커 이미지로 변환된 후, 어디에 어떻게 보관되는지 '이미지 저장소(Registry)'의 개념에 대해 알아보았습니다. 코드를 깃허브에 올리듯, 이미지는 ECR이나 GAR 같은 프라이빗 저장소에 안전하게 보관한다는 점을 꼭 기억해 두시면 좋겠습니다.

그런데 실무에서는 단순히 이미지를 저장소에 올리는 것만으로 작업이 끝나지 않습니다. 프로젝트가 진행될수록 수십, 수백 개의 이미지가 저장소에 쌓이게 되는데, 이 수많은 이미지들을 어떻게 구분해야 할까요? 만약 배포에 실패해서 이전 버전으로 롤백해야 한다면, 어떤 이미지가 안전한 이전 버전인지 어떻게 확신할 수 있을까요?

이 과정에서 가장 빈번하게 일어나는 실수가 바로 :latest 태그를 남용하는 것입니다. 운영 환경에서 태그를 잘못 관리하면 돌이킬 수 없는 배포 사고로 이어지게 됩니다.

다음 포스팅에서는 이 이미지들을 어떻게 구분하고 관리해야 배포 사고를 막을 수 있는지, 실무에서 사용하는 '이뮤터블 태그(Immutable tags) 설정'과 '롤백을 위한 안전한 이미지 태그 관리 전략'에 대해 깊이 있게 다뤄보겠습니다. 감사합니다!