프로그램을 컨테이너로 실행하면 환경 문제가 정리될 것 같다. 그런데 실행이 끝난 뒤 파일이 보이지 않거나, 다시 시작했는데 예전 상태가 남아 있으면 무엇을 확인해야 할지 막막해진다. 컨테이너라는 단어 하나로 묶어 생각하던 것을 조금 나눌 필요가 생긴다. 무엇을 준비했고, 무엇이 실행 중이며, 무엇을 남기기로 했는지의 문제다.
2026년 10월 22일에 올라온 Docker is weird는 직접 런타임을 만들어보며 익숙한 추상화를 다시 바라본 글이다. 다만 짧은 비유를 세부 동작 전체의 설명으로 받아들이면 오해가 생길 수 있다. Docker의 공식 컨테이너 안내도 함께 보면, 컨테이너를 필요한 파일과 격리된 실행 환경을 가진 프로세스로 생각하는 출발점을 얻을 수 있다.
보고서 한 장을 만든다는 가정
가상의 작업은 입력 파일을 읽어 보고서를 만드는 프로그램이다. 이 예시를 실제로 실행하거나 컴퓨터 설정을 바꾸지는 않았다. 프로그램과 필요한 도구를 담은 준비물, 실행 한 번의 상태, 다음에도 보관할 입력과 결과를 종이 위에서 나눠보려 한다. 이 셋이 어느 위치에 있는지부터 적으면 된다.
이미지는 실행을 시작하기 위한 바탕이라고 생각할 수 있다. 하지만 이미지 이름을 안다고 지금 어떤 실행이 돌아가는지까지 알 수 있는 것은 아니다. 같은 준비물을 바탕으로 여러 실행을 만들 수 있기 때문이다. 어떤 입력으로 시작했고 언제 끝났는지는 각각의 실행에서 확인해야 한다. 준비된 것과 진행 중인 일 사이에 경계가 생긴다.
보고서 프로그램이 정상 종료했다는 사실도 결과 파일을 원하는 곳에서 찾을 수 있다는 뜻은 아니다. 출력 경로가 어디인지, 그 경로를 다음 실행이나 호스트에서 어떻게 볼 것인지 정해야 한다. 터미널에 성공 문장이 보였다는 이유만으로 보관해야 할 결과가 남았다고 간주하면, 나중에야 다른 문제를 발견하게 된다.
그래서 작업 설명에는 입력을 읽는 위치와 결과를 남기는 위치를 서로 다른 항목으로 적는 편이 좋다. 읽기만 해야 하는 자료를 변경할 필요가 있는지, 결과를 새 이름으로 만들지 기존 파일에 덮어쓸지도 미리 정한다. 실행 환경을 분리해도 파일에 대한 약속이 저절로 정해지는 것은 아니다.
실패한 장면에서 거꾸로 묻기
가상의 프로그램이 파일을 찾지 못했다면 설치를 다시 시작하기 전에 질문을 좁혀볼 수 있다. 실행 중인 프로그램이 찾는 경로는 무엇인가. 그 경로에 자료가 보이도록 연결했는가. 자료 이름과 권한은 예상과 같은가. 호스트에서 보인다는 말과 실행 환경 안에서 보인다는 말을 구분해야 한다.
프로그램이 중간에 멈췄다면 어느 실행의 기록을 읽고 있는지도 중요하다. 비슷한 이름의 이전 실행을 보고 있으면 현재 문제와 맞지 않는 설명을 하게 된다. 실행 식별자와 시작 시각, 사용한 이미지와 입력을 한 묶음으로 남기면 혼동을 줄일 수 있다. 로그의 마지막 줄만 복사하기보다 그 줄이 어느 작업에서 나왔는지 붙이는 것이다.
결과가 예상과 다르다면 준비물과 입력 중 무엇이 바뀌었는지 나눠볼 수 있다. 프로그램 버전은 같지만 입력이 바뀌었을 수 있고, 같은 입력인데 준비한 환경이 달라졌을 수도 있다. 둘을 동시에 바꾸면 어느 쪽이 차이를 만들었는지 설명하기 어렵다. 비교하려는 동안에는 한쪽을 고정하는 편이 원인을 좁히기 쉽다.
이런 질문을 한다고 컨테이너가 완전한 보안 경계가 된다는 뜻은 아니다. 공식 안내에 나오는 격리라는 표현을 모든 위험이 사라졌다는 보장으로 넓혀 읽지 않아야 한다. 특히 권한과 외부 연결, 호스트 자료 접근은 실제 구성에 따라 확인할 부분이 다르다. 이 글의 개념 정리만으로 운영 환경의 안전성을 판단할 수는 없다.
끝난 뒤 무엇을 남길지
작업을 설계할 때에는 끝난 실행을 어떻게 정리할지보다 무엇을 먼저 보존해야 하는지 생각해볼 수 있다. 보고서 원본, 실행 조건, 실패 기록이 다음 판단에 필요하다면 먼저 별도로 남겨야 한다. 자료가 남아 있는 위치를 확인하지 않은 상태에서 정리 명령부터 실행하는 것은 피하는 편이 좋다. 여기서는 실제 삭제 명령을 제시하지 않는다.
처음 배우는 사람이라면 복잡한 서비스를 한 번에 띄우기보다 작은 작업 하나의 생애를 그려볼 수 있다. 준비물을 고르고, 입력을 연결하고, 실행을 시작하고, 결과를 확인하고, 남길 자료를 분리한다. 각 단계 옆에 무엇으로 완료를 확인할지 한 문장씩 적는다. 화면이 열렸다는 사실과 작업 결과가 남았다는 사실을 따로 확인할 수 있게 된다.
이미 알고 있는 사람에게도 이 종이는 인수인계 자료가 될 수 있다. 도구를 설치하는 순서만 긴 문서보다, 실패했을 때 어디를 볼지 적힌 짧은 설명이 도움이 되는 경우가 있다. 단, 구성 변경 뒤에는 실제 동작과 문서가 여전히 맞는지 확인해야 한다. 한 번 잘 그린 그림도 현재 실행을 대신하지는 않는다.
Docker를 이해하는 첫걸음이 반드시 더 많은 명령을 외우는 일일 필요는 없다. 준비된 것, 지금 실행되는 것, 계속 남겨야 할 것을 나눠보면 막연했던 실패가 조금 다른 질문으로 바뀐다. 다음에 결과 파일 하나를 찾지 못했을 때, 다시 설치하기 전에 그 파일이 어느 경계 안에 있어야 했는지부터 물어볼 수 있을 것 같다.
관련 글은 Docker에서 이어 읽을 수 있습니다.
공개 원문을 참고해 AI의 도움으로 구성·작성한 글입니다. 본문의 가상 예시는 실제 수행 결과와 구분했으며, 표지는 Google Gemini로 만든 개념 일러스트입니다.
