도커 없이 브라우저에서 컨테이너 이미지를 빌드한다고? 실험적 시도가 흥미롭다

컨테이너 빌드, 꼭 서버에서만 해야 할까

도커 이미지를 빌드해 본 분이라면 다들 비슷한 경험이 있을 거예요. 로컬에서는 Docker Desktop이 메모리를 4GB쯤 잡아먹고, CI/CD에서는 빌드 머신 위에 도커 데몬이 또 돌아가고, 클라우드에서도 별도의 빌드 서버가 필요하죠. 그런데 한 개발자가 "잠깐, 컨테이너 이미지가 결국 tar 파일 묶음에 메타데이터 좀 붙인 거 아닌가?"라는 생각으로 출발해서, 브라우저 안에서 완전히 클라이언트 사이드로 컨테이너 이미지를 빌드하는 실험을 해봤다는 글이 올라왔어요. 결과부터 말씀드리면, 진짜로 됩니다. 그리고 그 과정이 컨테이너의 본질을 이해하는 데 굉장히 좋은 교재가 되거든요.

컨테이너 이미지의 실체

먼저 컨테이너 이미지가 뭔지 잠깐 짚고 갈게요. 우리가 docker pull nginx 할 때 받아오는 그 이미지는 사실 마법의 박스가 아니에요. 그냥 여러 개의 tar 파일 레이어와, 그 레이어들을 어떻게 합쳐서 쓸지 알려주는 JSON 매니페스트의 모음입니다. OCI(Open Container Initiative)라는 표준이 이 구조를 정의해두고 있어요. 그러니까 이론적으로는 도커 데몬 없이도, 이 구조에 맞게 파일을 만들고 묶기만 하면 그게 컨테이너 이미지인 거죠.

글쓴이는 이걸 브라우저에서 해보자고 결심합니다. 사용한 도구는 WebAssembly로 컴파일된 도구들이에요. 파일 시스템 작업은 브라우저 메모리상에서 처리하고, tar 압축은 자바스크립트나 wasm 라이브러리를 사용해서 해결했어요. 그리고 완성된 이미지를 OCI 레지스트리(예: Docker Hub, GitHub Container Registry)에 푸시하는 것까지 브라우저에서 직접 합니다. fetch API로 HTTP 요청만 잘 보내면 되거든요.

어떻게 동작하는가

흐름을 풀어보면 이래요. 사용자가 브라우저에서 "이런 베이스 이미지에, 이 파일들을 추가하고, 이런 명령어를 엔트리포인트로 설정해줘"라고 명세를 줍니다. 그러면 브라우저 사이드 코드가 베이스 이미지 레이어를 레지스트리에서 직접 pull 해와요. HTTP GET 요청이니까 CORS만 통과되면 가능하죠. 받아온 레이어 위에 사용자가 추가하려는 파일들을 새 tar 레이어로 만들어서 얹습니다. 그리고 매니페스트 JSON을 새로 생성해서 모든 레이어의 SHA256 해시와 함께 정리해요. 마지막으로 이걸 다시 레지스트리에 PUT 요청으로 푸시하면 끝입니다.

물론 완전히 쉬운 건 아니에요. CORS 문제가 큰 걸림돌인데, 많은 레지스트리가 브라우저에서의 직접 접근을 허용하지 않거든요. 그래서 어떤 레지스트리는 가능하고 어떤 건 프록시가 필요합니다. 또 인증 토큰을 어떻게 안전하게 다룰지도 골치 아픈 문제죠. 그리고 RUN 명령어 같은 "임의 명령 실행"은 브라우저에서 불가능합니다. 새 파일을 추가하거나 메타데이터를 바꾸는 정도의 빌드만 가능해요.

기존 도구들과 뭐가 다른가

비슷한 시도들이 이미 있긴 합니다. Buildah, Kaniko, img 같은 도구들은 도커 데몬 없이 컨테이너 이미지를 빌드할 수 있게 해줘요. 하지만 이들도 결국 리눅스 서버 위에서 돌아갑니다. 구글에서 만든 Jib은 자바 앱을 도커 없이 이미지로 패키징해주는데, JVM 환경이 필요하죠. 이번 실험의 차별점은 "어떤 런타임도 설치하지 않은 일반 브라우저"에서 작동한다는 점이에요. CDN에 정적 파일로 호스팅된 한 페이지짜리 앱이 컨테이너 이미지를 만들어내는 거니까요.

실용적인 활용처를 상상해 볼까요. 예를 들어 노코드 플랫폼에서 사용자가 만든 설정을 컨테이너 이미지로 즉시 배포하고 싶다면, 서버에 빌드 인프라를 구축할 필요 없이 브라우저에서 바로 처리할 수 있어요. 또 교육용으로도 좋습니다. 학생들이 도커를 설치하지 않고도 컨테이너의 내부 구조를 직접 만져볼 수 있으니까요.

한국 개발자에게 주는 시사점

당장 회사 프로덕션에 도입할 기술은 아닐 거예요. 하지만 이 실험이 보여주는 통찰은 가치가 있습니다. 우리가 너무 당연하게 "도커가 필요하다"고 생각하지만, 사실 컨테이너는 표준이고 그 표준만 지키면 어디서든 만들 수 있다는 점이죠. 사내 빌드 파이프라인을 단순화하고 싶을 때, 또는 특정 사용 사례(예: 매우 단순한 이미지를 동적으로 생성)에서 도커 데몬을 빼는 선택을 할 수도 있어요. WebAssembly의 가능성을 다시 한번 보여주는 사례이기도 합니다. 점점 더 많은 "서버에서만 돌던 도구"들이 브라우저로 들어오고 있거든요.