직접 겪으며 정리해본 도커 사용 이유와 잘 쓰기 위해 생각해볼 점

Description: Docker를 몇년 정도 써보면서 겪고 느꼈던점을 기록해봅니다. 도커의 경우 요즘 개발환경의 추세이기도하고 편리해서 잘 쓰는 것 같네요

현재 노트: KR-020.10 a
상위 분류: KR-020.10 Docker

#Docker #Ops

엉망진창 개발 환경, 도커가 등장한 뒤 (feat. 라마, 깃랩)

도커(Docker) 에 대한 이야기를 해보려고 합니다. 교과서적인 도커 설명보다는 제가 직접 겪고 굴러본 생생한 경험을 바탕으로, 도커가 왜 '필수템'인지, 그리고 어떻게 하면 더 잘 써먹을 수 있는지에 대해 정리해보았습니다.

🚫 "왜 내 코드만 안 돌아가?" - 지옥 같던 과거

여러분, 이런 경험 있으신가요? 분명 어제까지 잘 돌아가던 코드가, 다음 날 갑자기 에러를 뿜어내고, 심지어 팀원 컴퓨터에서는 멀쩡히 돌아가는 상황.
특히 기억에 남는 건, Python 및 라이브러와 프레임워크 버전 관리로 밤새도록 삽질했던 기억이네요. 분명히 똑같은 코드인데, 왜 내 컴퓨터에서만 안 되는 건지, 원인 찾다가 날밤 새고 다음날 퀭한 모습으로 출근했던 기억이 새록새록 떠오르네요. 권한 문제, 포트 충돌, OS 호환성 문제, 환경 변수 꼬임... 생각만 해도 끔찍합니다.

💡 도커, 일관된 구현 환경 제공

처음에는 이게 뭔지도 몰랐죠. 그냥 '컨테이너'라는 신기한 단어에 끌렸을 뿐입니다. 하지만 도커를 사용하면서, 저는 이전까지 겪었던 '왜 내 코드만 안 돌아가?'라는 고질적인 문제에서 벗어날 수 있었습니다.

도커는 '환경'이라는 녀석을 코드처럼 관리할 수 있게 해주는 마법 같은 존재였습니다. 마치 사진 처럼 원하는 환경을 이미지로 만들고, 이 이미지를 어디서든 똑같이 실행할 수 있게 된 거죠.

🛠️ 나의 도커 사용기: 라마, 깃랩, 그리고 삽질의 역사

저는 다양한 프로젝트에서 도커를 사용해왔지만, 특히 기억에 남는 두 가지 경험을 자세히 이야기해볼게요.

  1. ragflow, llamindex 프로젝트: 개인적으로 AI/LLM 분야에 관심이 많아서 관련 프로젝트를 자주 만지작거립니다. 이런 프로젝트는 특히 의존성 관리가 중요한데, 도커 덕분에 복잡한 라이브러리들을 하나의 이미지로 묶어서 어디서든 동일한 환경에서 코드를 돌릴 수 있게 되었습니다. 이제 맘 놓고 코드와 기능 개발에 집중할 수 있게 됐죠! 요즘은 대부분의 프로젝트가 로컬 소스코드 외에도 도커 이미지 형태로 배포되는 추세이기도 하구요.

  2. 깃랩(GitLab) 기반 프로젝트: 회사에서 사용하던 VCS인 깃랩 서버 개발 환경을 도커 컴포즈(docker-compose)를 활용해 구축했습니다. 그 결과, 팀원들이 모두 동일한 환경에서 개발할 수 있었고, 클라이언트 배포 시에도 일관된 환경을 제공할 수 있었죠. 특히 환경 변수와 같은 커스텀 설정은 docker-compose.yaml에서 관리하면서 환경 세팅의 일관성을 크게 높일 수 있었습니다.

🤔 도커, 그냥 쓰면 끝? 🙅‍♂️ 아닙니다!

도커가 만능 해결사처럼 보일 수도 있지만, 제대로 활용하려면 노하우가 필요합니다. 단순히 도커 파일 몇 개 만들어서 돌린다고 끝이 아니죠. 그래서 제가 직접 경험하고 느낀 도커 활용 꿀팁 세 가지를 공개합니다.

  1. 다양한 도커 이미지 파일 사용해보기: 도커의 세계는 정말 넓고 깊습니다. 단순히 기본 이미지 몇 개만으로는 도커를 제대로 이해할 수 없습니다. 저는 다양한 프로젝트에서 여러 도커 이미지를 사용해보면서, 어떤 상황에 어떤 이미지가 적합한지, 그리고 각각의 장단점이 무엇인지를 몸소 익혔습니다. 예를 들어, 빠르고 가벼운 동작에는 alpine:linux가 좋지만, 기능이 부족할 때는 직접 git을 설치하거나, ArgoCD 같은 특정 툴이 설치된 커스텀 이미지를 만들어 써야 하죠. 결국, 이것저것 만들고 편집하고 섞어보면서 실력이 늘더군요.

  2. 이미지 용량 줄이기에 힘쓰기: 처음에는 도커 이미지를 그냥 막 만들었습니다. 그러다 보니 어느 순간 이미지 용량이 수백 기가에 달하는 괴물이 되어 있더군요. 이미지 용량이 커지면 빌드, 푸시, 풀링 속도가 느려져서 개발 생산성이 뚝 떨어집니다. 저는 멀티 스테이지 빌드를 적극적으로 활용해서 이미지 용량을 줄였습니다. 마치 다이어트처럼 불필요한 부분을 덜어내니 훨씬 가볍고 날렵하게 사용할 수 있었습니다.

  3. 도커 생태계 탐험하기: 도커 허브만으로는 도커의 모든 것을 알 수 없습니다. Amazon ECR, Harbor 같은 다른 컨테이너 레지스트리나 kaniko, containerd 같은 다른 컨테이너 런타임을 사용하면서 도커의 한계점과 다른 도구들의 장점을 배웠습니다. 마치 게임을 할 때, 다양한 캐릭터를 사용해봐야 어떤 캐릭터가 나에게 맞는지 알 수 있는 것처럼요.

👋 마치며...

도커는 단순한 '개발 도구'가 아닙니다. **개발 환경을 관리하는 '새로운 패러다임'**이라고 생각합니다. 도커 덕분에 저는 개발 환경 설정에 쏟던 시간을 코딩에 집중할 수 있게 되었습니다.

이 글이 조금이나마 여러분의 개발 여정에 도움이 되었으면 좋겠습니다. 감사합니다