"내 로컬에선 되는데요?"라는 말이 가장 무서운 이유
안녕하세요, 여러분. 오늘은 좀 편하게 커피 한 잔 하면서 이야기하듯이 글을 써보려고 합니다. 개발자로 일한 지 벌써 10년이 넘어가네요. 돌이켜보면 제 개발 인생은 '환경과의 싸움'이었다고 해도 과언이 아닙니다. 아마 이 글을 읽고 계신 분들 중에서도 신입 시절, 팀장님께 코드 리뷰를 받거나 배포를 진행할 때 식은땀을 흘려본 경험이 있으실 겁니다. 특히 배포 직전에 로컬 환경에서는 기가 막히게 잘 돌아가던 코드가, 스테이징이나 프로덕션 서버에만 올라가면 에러를 뿜어내는 상황 말이죠. 저도 처음엔 그게 단순히 '서버 탓'인 줄 알았습니다.
솔직히 고백하자면, 제가 주니어 시절에 가장 많이 했던 변명이 바로 "어? 제 컴퓨터에서는 되는데요?"였습니다. 지금 생각하면 정말 부끄러운 말이죠. 서버는 제 맥북이 아니니까요. 운영체제 버전이 다를 수도 있고, 설치된 라이브러리의 마이너 버전이 미세하게 다를 수도 있습니다. 심지어 폰트 설정 하나 때문에 레이아웃이 깨지는 경우도 허다했으니까요. 그때는 이런 환경 차이를 맞추기 위해 쉘 스크립트를 수십 줄씩 짜고, 위키 문서에 '서버 세팅 가이드'를 빼곡히 적어두곤 했습니다. 하지만 사람이 하는 일이다 보니, 문서 업데이트가 하루만 늦어도 다음 사람은 지옥을 맛보게 되더군요.
그러다 도커(Docker)와 쿠버네티스(Kubernetes)를 본격적으로 도입하게 되면서 세상이 바뀌었습니다. 아니, 정확히 말하면 '고통의 종류'가 바뀌었습니다. 예전에는 환경 설정 때문에 고통받았다면, 이제는 컨테이너 오케스트레이션이라는 거대한 복잡성 때문에 머리를 싸매게 되었으니까요. 하지만 확실한 건, 이 기술들이 우리에게 가져다준 '일관성'이라는 가치는 정말 어마어마하다는 점입니다. 오늘은 제가 지난 수년간 실전 프로젝트에서 컨테이너 기반 인프라를 운영하며 겪었던 뼈아픈 실수들과, 그 과정에서 배운 노하우들을 아주 솔직하게 풀어보려 합니다. 교과서적인 이야기는 빼고, 진짜 '현장' 이야기를 해봅시다.
혹시 지금 도커를 단순히 '가상머신보다 가벼운 무언가' 정도로만 생각하고 계신가요? 혹은 쿠버네티스를 도입하면 모든 장애가 마법처럼 사라질 거라고 믿고 계신가요? 그렇다면 오늘 제 이야기가 꽤 도움이 될 겁니다. 제가 겪은 시행착오를 여러분은 겪지 않길 바라는 마음으로, 제가 깨달은 '진짜' 운영 팁들을 하나씩 꺼내보겠습니다.
도커 이미지를 구울 때 저지르기 쉬운 치명적 실수들
레이어 캐싱의 원리를 모르면 빌드 시간만 30분 걸립니다
처음 도커를 접했을 때 저는 Dockerfile을 그냥 '설치 스크립트'라고 생각했습니다. 그래서 평소 리눅스 서버 세팅하듯이 명령어를 위에서부터 아래로 의식의 흐름대로 적어 내려갔죠. 소스 코드를 복사하는 명령어를 맨 윗줄에 적고, 그 뒤에 라이브러리 설치 명령어를 적는 식의 실수를 저질렀습니다. 결과는 어땠을까요? 코드 한 줄, 주석 하나만 수정해도 전체 이미지를 처음부터 다시 빌드해야 했습니다. npm install이나 pip install 같은 무거운 작업이 매번 다시 실행되니, 배포 한 번 하려면 커피를 두 잔이나 마셔야 했죠.
도커 빌드 시스템은 '레이어(Layer)'라는 개념을 사용합니다. 각 명령어 한 줄 한 줄이 하나의 레이어가 되고, 변경 사항이 없는 레이어는 캐시(Cache)를 재사용합니다. 이게 핵심입니다. 변경이 잦은 부분일수록 Dockerfile의 아래쪽에 배치해야 합니다. 보통 소스 코드는 가장 자주 바뀌고, 라이브러리 의존성은 상대적으로 덜 바뀌죠. 그러니 의존성 설치 파일을 먼저 복사하고 설치를 진행한 뒤, 마지막에 소스 코드를 복사해야 합니다. 이 순서 하나만 바꿔도 빌드 시간이 10분에서 30초로 줄어드는 기적을 경험할 수 있습니다.
실제로 제가 맡았던 프로젝트 중 하나는 빌드 시간이 너무 길어서 CI/CD 파이프라인이 자주 타임아웃 되곤 했습니다. 동료들이 "도커 너무 느려, 다시 VM으로 가자"라고 불평할 정도였죠. 제가 Dockerfile을 열어보니, 세상에, 1GB가 넘는 모델 파일을 매번 COPY 명령어로 복사하고 있더군요. 이걸 외부 볼륨으로 빼고 레이어 순서를 최적화하자마자 전체 배포 시간이 획기적으로 줄어들었습니다. 원리를 이해하는 것이 이렇게 중요합니다.
'latest' 태그는 운영 환경의 시한폭탄입니다
이건 정말 강조하고 싶은 부분입니다. 편하다는 이유로 프로덕션 환경에서 이미지 태그를 latest로 지정하는 경우가 있습니다. "항상 최신 버전 쓰면 좋은 거 아냐?"라고 생각하실 수 있지만, 운영 관점에서는 재앙입니다. latest는 고정된 버전이 아닙니다. 오늘 배포된 latest와 내일 배포될 latest가 전혀 다른 내용을 담고 있을 수 있다는 뜻이죠.
한 번은 이런 일이 있었습니다. 금요일 오후에 긴급 패치를 하고 퇴근했는데, 주말 사이에 서버가 자동으로 스케일 아웃(Scale-out) 되면서 새로운 인스턴스가 떴습니다. 그런데 이 새로운 인스턴스들이 전부 시작하자마자 죽어버리는 겁니다. 알고 보니 그 사이에 베이스 이미지가 업데이트되면서 파이썬 특정 라이브러리 버전이 변경되었고, 우리 코드와 호환되지 않았던 거죠. 우리는 태그를 명시하지 않았기 때문에 묵시적으로 latest를 가져왔고, 서로 다른 버전의 컨테이너가 섞여 돌아가는 끔찍한 혼종 상태가 되었습니다.
이 사건 이후로 저는 팀 내 가이드라인에 못을 박았습니다. "프로덕션 배포 시에는 반드시 구체적인 버전 태그(예: v1.0.2)나 커밋 해시(SHA)를 사용한다." 이렇게 하면 1년 뒤에 다시 배포해도 정확히 똑같은 환경이 구성됩니다. 롤백(Rollback)하기도 훨씬 쉽고요. 불변성(Immutability)이야말로 컨테이너를 쓰는 가장 큰 이유라는 걸 잊
댓글
댓글 쓰기