Devops 교육 완강 후기

Devops 는 어떤 미래를 꿈을 꿀 수 있을까?

커리큘럼과 중반까지에 대한 내 감상은 다른 포스트에서 다루었다. → 🔗Devops 교육을 들으며 중간 정리

순수 영상 재생 시간. 실습, 메모, 모르는 개념을 찾는걸 포함 더 많은 시간을 투자했다.

후반부 커리큘럼은 다음과 같다.

1. 도커와 쿠버네티스를 이용한 배포구성 및 운영
2. Jenkins / AWS Build Series / Github Actions / Circle CI를 이용한 실습
3. Argo 를 이용한 쿠버네티스 배포구성
4. Prometheus+Grafana, CloudWatch를 활용한 모니터링 데이터 수집 구성 및 모니터링 라인 구성, SNS 연동
5. ELK Stack 구성, 데이터 수집 및 시각화
6. IAM(Assume, IRSA), Session Manager, 골든이미지 구성 파이프라인, Inspector, Endpoint (Produce, Consume),GWLB, ANF, AWS WAF, CloudTrail, GardDuty, Security Hub 등 보안 서비스를 네트워크에 적용하기

커리큘럼에 대한 해제

자세히 보면 똑같은 기능에 대해 여러 가지 툴을 이용해 진행한 내용이 한 것이 많다. 각 툴들의 컨셉을 비교함으로서 차이와 공통점을 몸으로 이해하도록 해놓은 구성이다. 실제로 사용할 때는 더 깊은 기능과 작동 원리와 절차에 대한 더 깊은 이해가 필요할 텐데 그땐 학습자가 문서를 읽어보며서 하면 될 일이라고 본 것 같다. 그리고 나도 그런 점에 공감한다. T자 학습의 구조인데, 여러 가지 워크플로를 몸으로 익히고 생소한 단어와 개념에 익숙해지는 게 커뮤니케이션의 시작이라고 생각하기 때문이다. (일단 팀에 들어가면 아키텍트를 봐야 하니)

쿠버네티스 쇼크

전반부 파트에서 나에게 가장 충격을 준 툴이 Ansible 이었다면 후반부에서 가장 충격을 준건 받은 부분은 kubernetes 였다. 도커만 해도 컨테이너로 관리와 배포를 혁신적으로 할 수 있어서 큰 변화라고 느꼈었고 앤서블도 매니페스트 기반으로 인프라 작업의 Reusable을 획기적으로 개선했는데 쿠버네티스는 거기서 더 나아가 인텔리전트까지 갖추었기 때문이다.

파드를 노드에 배치하고 네트워크와 연결하는 부분은 문서로서 정의해놓으면 나머지는 쿠버네티스가 유연하게 적용함으로써 한 사람이 할 수 있는 작업의 양과 정확도, reusable 이 폭발적으로 증가하게 된다. 테스트 베드나 다른 리전에 서비스를 하고 싶을때도 코드를 복사해 테넌트 이름만 바꾸는 것으로 구성할 수 있는 점도 지적하고 싶다. 거기에 Lens처럼 웬만한 건 다 GUI에서 신속하게 처리할 수 있는 툴까지 합치면 왜 이 툴이 그렇게 주목받는지 이해가 되었다.

SaaS의 엄청난 효율성

그리고 Part8 AWS 보안, EKS 내용을 보면 Devops는 AWS가 만들어놓은 베스트프랙티스 서비스를 SaaS란 이름으로 구매해 회사의 비즈니스 로직과 연결하는 역할로 보일 수도 있다고 생각한다. 10명의 사람들이 직접 만들어서 했어야 할 서비스를 빌려와서 할 수 있는 현실에. 그 한 사람이 되기 위해 무언가 공부를 한다는게 경제적으로 이치는 맞는 말이지만 뭔가 SaaS를 연결하는 게, glue Coding이 직업이라고 단면적으로 해석하면 뭔가 쓸쓸하게 느껴지지 않는다고 하면 거짓말이라고 생각한다.

실제로 일을 하다 보면 결국 거기서도 커뮤니케이션적인 측면과 도구를 사용하는 방법과 정책에 있어 사람과 사람사이엔 결과물의 차이가 생기겠지만 클라우드 SaaS 사업자는 그런 차이를 줄여 균일한 서비스를 체험할 수 있도록 베스트프랙스트를 매일 생산해내고 있다. 예를 들어 EKS는 컨트롤 플레인에 대한 염려를 때어놓을 수 있게 했고. EKS에서도 EC2대신 쓸 수 있는 파게이트는 데이터 노드에 대한 걱정도 때어놓게 만들었다. 그 다음은 무엇이 될까?

다극화니 뭐니 하지만 인터넷 공간은 더 좁아지고 있다. 하나된 미래가 온다

목을 내어놓고 있다는 느낌을 지울 수 없다.

우리는 1년 뒤엔 인도에 있는 24*7 근무 MSP(Managed service provider) 조직에 AWS 계정을 맡기는 CTO를 만나게 될지도 모른다. 그 회사에서 CTO는 비즈니스 로직이 들어간 repository와 개발자들의 사기를 관리하는 일을 보고 남은 시간 동안 다른 CEO들에게 디지털이 주도하는 비즈니스를 어필하는데 자신의 중요성을 어필하는데 집중하게 될 것이다. 그리고 가끔 인도인들이 돈을 헛되게 쓰고 있지 않은지 비용분석 회사의 컨설팅 보고서를 읽는다.

자본주의가 효율적일수록 사람과 사람 사이에 일의 퀄리티에 차이가 없을수록 클라우드 회사들이 열심히 그들의 성공 케이스를 적용할수록 그 미래는 더 빨리 올 것이다. 그때 나를 포함한 전 세계의 데브옵스들은 24*7 근무를 수용한 절박한 인도인과 무슨 차별점을 가지게 될까?

이건 망상이 아니다. 이 추론은 ITO 외주가 일상이었던 지난 업계의 질서의 연장이자 확장이다. 회사가 모든걸 다 하려고 할때는 보다 쪼개고 나누어줄때 더 효과적이었고 동작하는 모델이었다. 적어도 오늘까지는.

(생각해보면 아마존은 그러지 않았다. 아마존은 자신의 ITO 외주를 하는 대신 전 세계의 회사들이 각자 개발하고 있을 인프라 시스템을 세계인이 API로 쓴다는 생각을 실천에 옮겼다. 그리고 후발주자들은 그 아이디어를 카피했다.)

난 이런 욕망을 가진 사람이구나

이런 내 걱정과 싸늘한 감각엔 일을 통해 긍지를 얻고 존중받고 싶다는 욕망, 도저히 내 인생에서 지워낼 수 없는 그 욕망이 근거하고 있다. 이 강의를 들으며 그 감히 두려워 입에 담을 수 없었던 그 욕망을 다시 발굴해낸 점이 이 강의에서 얻어낸 가장 큰 소득이라고 생각한다.

다만 이 생각은 수강을 마무리하는 시점에 묘하게 싸늘한 그 감정을 쏟아낸 것에 불가하다. 나 혼자만의 생각이니 다른 사람들과 토론하고 관련된 사람들의 책을 읽어봄으로써 발전시켜나가야 한다. 성급한 결론은 내리지 않는 것으로 하고 이것으로 마무리한다.