회고 | 도커, 내가 겪은 인프라 자동화(IaC)

작년이었던 것 같은데, 맛나보이는 조개 구이!

들어가기 앞서...

최근 유튜브 추천 영상 목록에 도커에 대한 영상이 자주 보인다.

알고리즘에 이끌려 몇 개를 보게 되었는데, 거의 공통적으로 초반에 다음과 같은 질문으로 시작한다.

도커가 무엇인가?

 

물론 도커를 처음 접하는 사람에게 반드시 필요한 주제다.
다만 대부분의 영상에서는 가상화와 도커를 비교하며 성능상의 장점만을 강조하는 인상을 받았다.

하지만 개인적으로는,

도커의 본질은 성능 향상보다는 “어플리케이션 실행 환경의 의존성 문제를 해소하는 것”에 더 가깝다고 생각한다.
이 부분이 상대적으로 덜 강조되고 있다는 느낌을 받아, 이 포스팅을 작성하게 되었다.

 

예를 들어 다음과 같은 상황은 꽤 흔하다.

(예) 개발자의 노트북에서는 최신 Python 3.10 환경에서 정상 동작하던 코드가 서버에 설치된 Python 3.6 환경에서는 실행되지 않을 수 있다.

---

Lagacy (Unix/Linux)

과거에는 서버에 Unix/Linux 운영체제를 직접 설치하고, 그 위에 어플리케이션을 구성하여 운영하는 방식이 일반적이었다.
지금도 완전히 사라진 방식은 아니지만, 예전보다는 빈도가 줄었다고 봐야한다.

보통은 개발 서버와 운영 서버를 분리하여 구성하게 되는데,

초기 구축 단계에서는 두 서버를 거의 동시에 구성하는 경우가 많아 설정이 매우 유사하다.

특히 고도화 사업처럼 하드웨어가 한 번에 납품되어 신규 구축을 진행하는 경우가 그렇다.

다만 아무리 동시에 구성하더라도 예상치 못한 사소한 차이가 쉽게 발생한다.

예를 들어 개발 서버 구성 시에는 문제가 없었지만,

운영 서버 구성 중 사소한 에러로 인해 추가 설정을 하는 경우가 있다.

이렇게 초반부터 조금씩 차이가 생기기 시작하고,

시간이 지나면서 관리 인원이 변경되거나 운영 이슈가 누적되면서 두 서버의 구성은 점점 더 일그러지게 된다.

---

IaC (Infrastructure as Code) 시초 Vagrant

클라우드 서비스가 대중적으로 알려지기 시작하던 시기에,

가상 머신을 활용해 어플리케이션 실행 환경 자체를 고정하려는 시도들이 등장했다.

그중 개인적으로 가장 기억에 남는 도구가 Vagrant다.
(물론 다른 도구들도 있었지만, 당시에는 Vagrant가 가장 인상 깊었다)

Vagrant는 로컬 환경에서 가상 머신을 실행하고, 운영체제 이미지 위에 스크립트(Shell)를 통해 추가 구성을 자동화하는 방식이었다.

지금 돌이켜보면, 이 시도가 현재 말하는 IaC (Infrastructure as Code)의 시초에 가깝지 않았나 싶다.

하지만 단점도 명확했다.

로컬에서 무거운 가상 머신을 실행해야 했고 초기 구성에 시간이 많이 소요됐으며 무엇보다 어플리케이션 의존성 문제를 완전히 해결해주지는 못했다

스크립트를 코드로 관리하긴 했지만, 실행 시점의 네트워크 상태나 외부 저장소(yum, apt, npm 등)의 패키지 버전 변화에 따라
“어제는 성공했던 스크립트가 오늘은 실패하는” 일이 빈번했다.

즉, 코드는 같아도 결과는 같지 않은 상황이 반복되었다.

그리고 로컬에서 가상 머신을 띄우다 보면 CPU 팬이 미친 듯이 돌아가며 “비행기 이륙 소리 난다”는 농담이 자연스럽게 나올 정도였다.

---

 

Configuration Management (Cloud)

Vagrant와 비슷한 시기에, 클라우드 환경에서 인스턴스(가상 머신)를 생성한 뒤 원격으로 어플리케이션 구성을 자동화하려는 접근 방식도 등장했다.

 

대표적인 도구들은 다음과 같다.

• Terraform
• Ansible
• Puppet
• Chef

이 접근법은 “이미 배포된 서버를 어떻게 구성할 것인가”에 초점을 맞췄던 것으로 보인다.

개인적으로 적극 활용해보지는 않았지만, 로컬 가상 머신을 사용하는 Vagrant에 비해 훨씬 가볍고 실용적이었을 것이라 생각한다.

다만 운영 관점에서는, 문제가 생긴 서버를 고쳐 쓰기보다는 지우고 새로 만드는 것이 더 효율적이라는 인식이 점점 강해졌던 것 같다.

이는 흔히 말하는 Phoenix Server Pattern과도 닮아 있다.
장애를 해결하는 대신, 서버 자체를 교체해 서비스 복구를 하는 방식이다.

또 하나의 단점은, 클라우드 인스턴스에 외부에서 접근해야 하므로 Unix/Linux 접근 키를 별도로 관리해야 한다는 점이었다.

---

Docker

그리고 2013년 즈음, Docker를 처음 접하게 되었다.
당시에는 도커는 물론이고 “컨테이너”라는 개념 자체가 생소했던 시기였다.

이후 1~2년 정도가 지나서야, 도커가 무엇을 해결하려 했는지 이해하게 되는 계기가 찾아왔다.

바로 Immutable Infrastructure(불변 인프라)라는 개념이었다.

이는 “한 번 생성되면, 그 내부를 변경하지 않는다”는 철학에 가깝다.
이미 완결된 상태로 존재하며, 수정이 필요하면 새로 만든다.

 

결국 도커는,
어플리케이션 실행 환경을 통째로 박제한 것이다.

 

Vagrant가 ‘레시피(스크립트)’를 공유하는 방식이었다면, Docker는 ‘완성된 요리(이미지)’를 그대로 전달하는 방식이다.

이제는 구성할 때마다 “제발 에러 나지 마라” 하고 기도할 필요 없이, 이미 검증된 이미지를 그대로 가져와 실행만 하면 된다.

실행 환경 자체를 통째로 고정해버렸기 때문에, 오랫동안 개발자들을 괴롭혀온 “내 컴퓨터에서는 되는데, 왜 서버에서는 안 되지?”

라는 논쟁은 도커의 등장과 함께 비로소 종말을 맞이하게 되었다.

---

마무리

인프라 자동화의 흐름을, 개인적인 경험을 바탕으로 간단히 정리해보았다.

Mesos(Mesosphere)나 Kubernetes까지 이어지는 이야기는 분량이 길어질 것 같아, 추후 포스팅에서 다뤄보려고 한다.

다만 이 글은 과거의 기억에 의존해 작성되었다는 점을 미리 밝힌다.
경험 기반이다 보니 실제 역사적 사실과 다른 부분이 있을 수 있다.

 

혹시 잘못된 내용이나 보완할 점이 있다면 피드백 주시면 확인 후 수정하겠다.