컨테이너

개발자 사이에서 가장 오래된 말다툼 중 하나가 "제 컴퓨터에서는 되는데요" 입니다. 만든 사람의 노트북에서 멀쩡히 돌던 프로그램이 서버에 올리면 뜨지 않습니다. 코드는 한 글자도 다르지 않은데 결과가 다릅니다.

원인은 대개 코드 밖에 있었습니다. 노트북에는 언어 버전이 3.11인데 서버에는 3.9가 깔려 있고, 이미지 처리에 필요한 라이브러리가 노트북에는 오래전에 설치돼 있고 서버에는 없습니다. 서버가 여러 대면 그 차이가 대수만큼 늘어납니다. 2년 전에 만든 1번 서버와 지난달에 만든 5번 서버는 설정이 미묘하게 다르고, 그 다름을 적어 둔 사람은 없습니다. 같은 프로그램을 다섯 대에 올렸는데 그중 한 대에서만 오류가 나면 원인을 찾는 데 하루가 갑니다.

그전까지의 해법은 설치 절차를 문서로 남기는 것이었습니다. 문서는 금방 낡습니다. 누가 급해서 손으로 하나 바꿔 놓고 문서에 적지 않으면 그 순간부터 문서와 서버가 갈라지고, 다음 사람은 문서대로 했는데 안 되는 상황을 만납니다. 컨테이너는 절차를 적어 두는 대신 결과물을 통째로 묶어 옮기자는 발상에서 나왔습니다. 무엇을 어떻게 설치하라고 설명하지 않고, 설치가 끝난 상태 자체를 한 덩어리로 만들어 그 덩어리를 옮깁니다.

묶은 내용이 고정되어 있다는 성질 하나에서 세 가지가 따라 나옵니다.

1. 환경 차이 — 프로그램, 언어 런타임, 라이브러리, 설정 파일이 한 덩어리 안에 들어갑니다. 덩어리 밖에서 가져다 쓰는 것은 운영체제의 핵심 부분뿐입니다. 그래서 노트북에서 뜨던 덩어리는 서버에서도 같은 모양으로 뜹니다. 환경은 개발·스테이징·운영처럼 목적이 다른 실행 공간을 가리키는 말인데, 세 곳에 같은 덩어리를 올리면 "스테이징에서는 됐는데 운영에서 안 된다" 는 종류의 문제가 줄어듭니다.
2. 배포 시간 — 새 버전을 올리는 일이 파일을 복사하고 설치 명령을 줄줄이 실행하는 작업에서 덩어리를 내려받아 바꿔 끼우는 작업으로 바뀝니다. 몇 분 걸리던 일이 몇 초가 되고, 잘못됐을 때 이전 덩어리로 되돌리는 일도 같은 속도로 됩니다. CI/CD처럼 코드 변경을 자동으로 검증하고 배포까지 잇는 체계가 널리 퍼진 데에는 이 덩어리가 옮기기 쉬웠다는 사정이 있습니다.
3. 한 대에 올리는 밀도 — 운영체제를 통째로 켜지 않으니 시작에 몇 초면 되고 메모리도 프로그램이 쓰는 만큼만 듭니다. 서버 한 대에 수십 개를 얹을 수 있습니다. 기능별로 쪼개 따로 배포하는 마이크로서비스 구조가 현실적으로 돌아가게 된 것도 작은 조각 하나마다 서버 한 대씩을 붙이지 않아도 됐기 때문입니다.

모든 프로그램이 이 방식으로 돌아야 하는 것은 아닙니다. 쓰이는 선택지가 셋 더 있습니다.

1. 서버에 직접 설치 — 기계 한 대에 필요한 것을 손으로 깔고 프로그램을 띄웁니다. 중간 단계가 없어서 가장 단순하고, 서버가 한두 대이고 배포가 한 달에 한 번인 팀이라면 이 방식이 오히려 빠릅니다. 덩어리를 만들고 저장소에 올리고 내려받는 절차 자체가 관리할 일이기 때문입니다.
2. 가상 머신 — 물리 서버 위에 만든 가상의 독립 컴퓨터입니다. 운영체제를 통째로 갖고 있어 격리 수준이 더 높습니다. 고객사마다 완전히 분리된 공간을 계약으로 약속했거나, 운영체제 자체가 달라야 하는 프로그램을 돌려야 하면 이쪽이 맞습니다. 대신 시작에 1~2분이 걸리고 메모리도 먼저 크게 나갑니다.
3. 서버리스 — 서버를 직접 관리하지 않고 함수 단위로 실행하는 방식입니다. 요청이 올 때만 깨어나 돌고 끝나면 사라지므로 하루에 몇 번 도는 작업에 잘 맞습니다. 다만 쉬고 있던 실행 환경이 깨어나며 첫 응답이 느려지는 콜드 스타트가 따라오고, 한 번 실행에 쓸 수 있는 시간과 메모리에 상한이 걸립니다.

고르는 기준은 배포 횟수와 서버 대수입니다. 한 달에 한 번 올리는 서버 두 대짜리 서비스에 이 방식을 얹으면 얻는 것보다 관리할 것이 많아집니다. 매주 여러 번 올리고 서버가 열 대를 넘어가는 순간부터는 반대가 됩니다.

"로컬에서는 되는데 스테이징에서 안 됩니다. 이미지 다시 빌드해서 올려 볼게요."

묶은 덩어리를 새로 만들어 환경 차이를 지워 보겠다는 말입니다.

"이건 컨테이너 안에서 돌리고 데이터베이스는 밖에 두죠."

상태가 남아야 하는 것은 이 방식에 담지 않겠다는 판단입니다.

"한 대에 여덟 개까지는 올라가요. 그 이상은 메모리가 안 받쳐 줍니다."

서버 한 대가 감당하는 개수를 실측으로 말하는 대목입니다.

페이지덱이 문서 미리보기 기능을 붙이던 분기에 태오가 겪은 일입니다. 미리보기는 문서를 그림으로 바꾸는 라이브러리를 쓰는데, 그 라이브러리가 운영체제에 따라 글꼴을 다르게 잡았습니다. 태오의 노트북에서는 한글이 제대로 나왔고 운영 서버에서는 네모 상자로 나왔습니다.

글꼴 파일을 덩어리 안에 함께 묶고 나서 그 차이가 사라졌습니다. 서버에 글꼴을 설치하는 절차를 문서에 적어 두는 방법도 있었지만, 태오가 덩어리 쪽을 고른 이유는 반년 뒤에 서버를 새로 만드는 사람이 그 문서를 읽지 않을 것이 분명했기 때문입니다.

가벼운 가상 머신이라고 이해하는 경우가 가장 많습니다. 둘 다 프로그램을 따로 떼어 돌리는 것처럼 보이니 자연스러운 오해입니다. 하지만 이 방식은 운영체제의 핵심 부분을 아래에서 나눠 씁니다. 완전히 분리된 컴퓨터가 아니라 한 운영체제 안에서 서로 안 보이게 갈라 둔 상태에 가깝습니다. 이 차이를 모르면 격리 수준을 실제보다 높게 잡게 되고, 한 덩어리에서 생긴 문제가 같은 기계의 다른 덩어리에 번질 수 있다는 사실을 설계에서 빼먹게 됩니다.

이것만 도입하면 운영이 자동으로 해결된다는 기대도 흔합니다. 덩어리 하나를 띄우는 일은 쉬워지지만 수백 개가 되면 어느 기계에 몇 개를 얹을지, 죽은 것을 어디에 다시 띄울지가 새 문제로 남습니다. 그 판단은 다른 도구가 맡습니다. 이 사실을 모른 채 규모를 키우면 덩어리를 띄우고 죽이는 일을 사람이 손으로 하게 되고, 결국 문서로 절차를 남기던 시절과 같은 자리로 돌아갑니다.