"내 컴퓨터에서는 됐는데"는 소프트웨어 세계에서 가장 오래된 변명이에요. 컨테이너는 바로 그 변명을 끝낸 물건이에요.
컨테이너가 해결하는 문제는 이렇습니다. 소프트웨어는 진공 속에서 돌아가지 않아요. 특정 버전의 언어, 특정 보조 라이브러리, 특정 설정이 모두 맞아야 해요. 내 노트북에는 한 가지 구성이 있고, 실제 운영 서버에는 조금 다른 구성이 있고, 팀원 컴퓨터는 또 달라요. 그래서 내 환경에서 완벽하게 돌아가던 코드가 다른 곳에서 죽는 거예요. 코드가 바뀐 게 아니라, 코드를 둘러싼 주방이 바뀐 거죠.
푸드트럭 비유. 일반 레스토랑 주방은 건물에 고정되어 있어요. 요리사를 다른 건물로 옮기면 오븐도 낯설고, 가스 배관도 다르고, 손이 가는 곳에 아무것도 없어요. 푸드트럭은 이 문제를 다르게 풀어요. 가스레인지, 냉장고, 모든 도구, 레이아웃 그대로를 바퀴 달린 상자 하나에 전부 싣는 거예요. 축제 현장이든, 주차장이든, 다른 도시든 트럭을 파킹하면 요리사는 올라타서 그대로 요리해요. 상자가 같으니 주방도 같고, 어디에 세워도 결과가 같아요.
컨테이너는 앱을 위한 그 푸드트럭이에요. 코드와 그것이 필요로 하는 전체 환경, 즉 언어 버전, 보조 라이브러리, 설정까지 모두 하나의 상자에 봉인해요. 그 상자를 내 노트북에서 실행하든, 팀원 컴퓨터에서 실행하든, 버지니아의 대형 서버에서 실행하든 동일하게 동작해요. 주방이 코드와 함께 이동하기 때문이에요.
Docker는 그 푸드트럭 브랜드 중 가장 널리 쓰이는 것이에요. 워낙 널리 퍼지다 보니 브랜드 이름이 동사가 됐어요. "Dockerize해"는 "이 앱을 어디서든 똑같이 돌아가도록 컨테이너로 포장해"라는 뜻이에요. "컨테이너"와 "Docker"가 같이 나오면 같은 트럭을 가리킨다고 보면 돼요.
직접 컨테이너를 만들 일이 없어도 알아야 하는 이유가 있어요:
- 현대 배포가 안정적인 이유가 여기에 있어요. 코드만 달랑 올리고 서버 환경이 내 노트북과 맞기를 기도하는 게 아니라, 트럭째 보내는 거니까요.
- 에이전트가 새 머신에서 프로젝트를 바로 실행할 수 있는 이유도 여기에 있어요. 자기 주방을 가져왔으니까요.
- 서버리스와도 직결돼요. 코드가 실행되는 반 초 동안 프로바이더가 꺼내 쓰는 그 머신들은, 대부분 앱을 컨테이너로 실행해요. 필요할 때 트럭을 파킹했다가, 끝나면 몰고 가는 거예요.
규모 감각을 하나 덧붙이면, 컨테이너는 봉인된 주방이지 건물 전체를 임대하는 게 아니에요. 서버 한 대를 통째로 빌리는 것보다 훨씬 가벼워요. 그래서 한 머신에서 트럭 열두 대를 동시에 돌릴 수 있어요. 가볍다는 것 자체가 핵심이에요.
컨테이너는 주방 전체를 트럭에 싣고, 어디에 세워도 똑같이 요리해요. "내 컴퓨터에서는 됐는데"는 조용히 "어디서나 된다"로 바뀌는 거예요.