DevOps의 탄생은 클라우드의 전성시대보다 앞서있었고, 클라우드와 함께 시너지를 내며 만개했음.
DevOps는 결국 어떤 요구사항을 만족 시키는 것에 집중.
업무 자동화, 변경되는 지표와 트래픽 사이에 변화, 고객들의 변화들을 객관적인 지표로 측정해야 함. 이렇게 축적된 데이터들을 사용하는 것이 결국 빅데이터고, AI의 Foundation Model이 되기도 함. 그래서, DevOps는 이런 객관적인 지표들을 어떻게 하면 잘 축적할 수 있을지에 대한 문화이자, 철학, 방법론, 기술임.
DevOps 엔지니어의 역할
현재 한국의 IT Industry는 문제가 났을 때 잘 해결하는 사람을 높게 평가함. 문제를 사전에 방지할 수 있는 사람보다 더 고평가 되기도 함.
이런 문화를 고치는 것조차 DevOps 엔지니어의 역할임.
사람 + 자본이 늘어나면 비례해서 일의 속도 + 양도 함께 증가함. 대부분의 기업 현실이 사람 + 자본이 늘어날 수록 일의 속도는 더뎌짐. (원인 : 정치, 잡음이 많아짐) 이런 것들을 근본적으로 해결할 수 있는 직군이 DevOps임.
컨테이너와 VM의 차이, 그리고 쿠버네티스
컨테이너와 VM의 차이를 근본적으로 이해하고 있지 못하는 엔지니어들도 많음. 컨테이너는 단순히 프로세스, VM은 Host OS 위에서 하이퍼바이저를 통해 동작하는 Guest OS임. 결국 과거 VM에서 처리하던 작업들을 경량화해 컨테이너로 배포하기 시작한 것임. 이러한 컨테이너의 수가 늘어나 복잡도가 높아지자 오케스트레이션 툴이 필요했고, 이것이 'Kubernetes'임.
Kubernetes의 3대 철학 Immutable : 시스템 상태를 직접 변경하지 않고, 항상 새로운 오브젝트로 교체함으로써 일관성과 재현성을 확보 Declarative : 사용자는 원하는 최종 상태(desired state)만 선언하고, 실제 적용 방식은 Kubernetes가 자동으로 처리 Self-Healing : 클러스터 내에서 리소스에 장애가 발생하면, Kubernetes가 자동으로 상태를 감지하고 복구 작업을 수행
하늘이 무너져도 솟아날 구멍은 있다
개인적인 준비와 성장의 기회가 한계가 있다고 생각하지 말길. 생각보다 많은 회사들은 도전을 막고 있지 않음. 특히나 IaC 도구, Github 등은 무료로 제공되며 오히려 저렴하고 배우기 쉬운 기술들이 대부분임. 또한 IT Fundamental(리눅스의 cgroup, namespace가 컨테이너에서 어떻게 사용되는지 등)를 이해하는 것이 중요함.
회사가 더 작을수록 더 많은 일을 하는 도전을 해야 됨. 회사가 망할 때 같이 망하는 사람이 아니라, 살아남는 사람이 되어야 함.
결국 인프라는 비즈니스에 맞춰 성장해야 한다.
어떠한 규모의 사업이든 비용이 문제라면, 그것에 맞춰 구성하는 것이 맞음. 심지어 EC2 2대 밖에 사용이 불가능하다면, 한 인스턴스에 Backend + DB를 몽땅 박아놔도 됨. 대신, 끊임없는 PoC와 학습을 통해 얼마만큼 빨리 확장 가능한 형태로 바꿀 수 있는지가 중요함. 이것이 곧 실력임. (8시간? 4시간? 2시간? 1시간? ...)
표준 구성에 너무 집착하지 않아야 함. 결국 표준은 제일 마지막에 완성되는 것이고, 보안 - 신뢰성 - 효율성 - 자동화 - 표준 구성 순으로 나아가야 함.
후기(회고)
인프라는 비즈니스에 맞춰 성장해야 한다. 는 식으로 강연해 주셨는데, 너무 공감했다. 평소에 내가 공부하고 있는 기술들은 비즈니스를 위해 존재한다고 생각하고 있었기 때문이다.
회사가 더 작을수록 많은 일을 하는 도전을 해야 된다. 는 말이 매우 와닿았다. 요즘 시스템 엔지니어로, 혹은 클라우드 엔지니어로, 어떤 걸로 나아가야 훌륭한 인프라 엔지니어가 될 수 있을까? 라는 고민을 스스로에게 많이 던졌었다. 정답은 결국, 직업에 있는 것이 아니라 내가 어떤 신념을 갖고 일하고, 어떤 IT Fundamental 를 구축하며 나아갈 것이냐에 있다.
더더욱 취업하고 싶어졌고, 실무 환경 속에서 성장하고 싶다는 강한 욕구가 든다. 항상 그래왔듯, 최고보다는 최선을 다 해야겠다.
