1주차 (Ch1~2)

1장. AI 시대, 개발자의 인프라

데브옵스 문화가 가져다 준 변화

“만든 사람이 운영한다”

이 원칙은 인프라 전담 팀이 없는 스타트업에서 기본 문화로 자리 잡고 있다. 이로 인해 개발자는 서비스에 대한 전반적인 개발과 운영을 동시에 진행한다.

또한, 팀에서 축적해 둔 시스템 구성 지식을 YAML 이나 테라폼과 같이 선언형 코드로 깃에서 관리하는 전략을 사용하여 변경 이력을 관리한다.

이 문화가 자리 잡은 현재의 개발자는 기능 구현에만 중점을 두지 않고 서비스 전반의 운영 관점에서 나오는 질문도 스스로 답변할 수 있어야 한다.

즉, 개발자가 다루어야 하는 범위가 확장됨에 따라 인프라 지식도 하나의 소양으로 자리 잡았다.

개발자가 인프라를 배워야 하는 건 알겠는데, 왜 쿠버네티스를 배우는 걸까?

서비스 장애 지점을 최소화하기 위해 노력을 기울인 회사들이 늘어나며 MSA 와 같은 프로젝트를 다루는 개발자들이 많아졌다.

그렇기 때문에 무수히 많은 서비스를 쉽게 관리할 수 있는 표준에 가까운 도구를 선택하게 되는데, 그 기반이 쿠버네티스이며 특정 클라우드에 종속되지 않는다.

클라우드 안에서 쿠버네티스를 구축하지만, 세부적인 내용은 작은 클라우드에 빗대어 표현하고 있다. 예를 들어, ingress 설정과 맞닿아 있는 로드밸런서처럼 개념이 비슷하다.

쿠버네티스를 구성하게 되면 클라우드에서 어떻게 구성해야 하는지와 개념이 비슷하기 때문에, 인프라 전반의 내용을 상대적으로 가볍게 습득할 수 있다.

러닝 커브를 고려하여 기술을 우회하던 의사 결정은 이제 AI 앞에서 핑계거리다

쿠버네티스를 사용하기로 마음먹었다면, 당장 클러스터를 설치했다고 끝이 아니다.

클러스터를 관리하는 관측성 도구, 자동화 배포 도구, 암호화 도구, 로그 관리 도구 등 굉장히 많은 부가 도구들을 활용해야만 서비스를 운영할 때 사용자 편의성을 누릴 수 있다.

지금은 급변하는 시대에 맞게 AI 가 업무에서 많은 역할을 대행해 주고 있고, 인프라도 예외는 아니다.

복잡한 구현처럼 “어떻게” 해야 하는지는 AI 에게 맡기고, 우리는 “무엇을” 할 것인지에 집중하게 되어, 쿠버네티스처럼 러닝 커브가 가파른 기술도 우리의 호기심만으로 지식을 얻을 수 있게 되었다.

GitAIOps

GitOps 는 인프라의 상태를 선언적으로 관리하는 방법이며, 깃으로 선언 내용만 관리할 뿐 상태 변경은 관련 도구가 맡는다.

GitOps 를 통해 얻을 수 있는 장점

• 깃 저장소에 푸시하는 것만으로 자동으로 배포된다.
• 배포한 이력을 관리할 수 있다.
• 롤백이 자유롭다.
• 깃허브를 통한 배포 프로세스(코드 리뷰, 이슈 관리 등)를 지원한다.
• 인프라 상태를 언제든 새롭게 다시 구성할 수 있다.

GitOps 가 여전히 생산성을 높이고 있는 걸까?

디플로이먼트 하나를 작성할 때도 YAML 매니페스트를 구성하거나 헬름 차트를 관리하는 등 여전히 작업자 개인이 시스템 구성을 도맡아 작성해야 한다.

만약 배포한 시스템이 정상적으로 기동되지 않고 오류 메시지만 잔뜩 뿜어내고 있다면, 그 원인 파악도 작업자 본인의 몫이 된다.

이렇게 작업자 개인이 코드 단위의 수정을 하다 보면, 촉박한 일정 탓에 문서화를 빠트리거나 과거 작업 내용에 대한 근거를 찾지 못하는 등 시스템을 설명하기 어려운 상황에 도달할 수 있다.

이 작업들은 소규모 인프라 전문 조직이 모두 감당하기에 시간이 절대적으로 부족하기 때문에, 업무 환경 내에서 적절한 지점을 타협하기 마련이다.

GitOps 의 PainPoint 를 개선하기 위한 AI 활용

앞으로 우리가 마주할 GitAIOps

깃허브로 인프라 구성을 코드로 관리하는 전략은 같지만, AI 를 통해 시스템 전체 관점에서 무엇을 구성해야 하는지를 자연어 기반으로 작성하게 된다.

더 이상 작업자는 문서화, 오류 검증, 보일러플레이트 코드 작성 등을 일일이 진행하지 않게 되면서 업무의 추상화가 한 단계 더 높아지게 된다.

AI 가 자유롭게 활동하지 못하게 막는 규율은 왜 필요한가?

AI 는 사용자가 요구하는 문제를 단편적인 관점에서 해결하려는 성향이 있다.

과거에 대표적으로 나타났던 문제는, DB 에 값이 잘못 적재되고 있는 상황을 주었을 때 코드 레이어에서 어느 정도 수정을 한 뒤 DB 를 모두 삭제하고 시나리오를 검증하려고 했던 일이다.

또한 사내에서 ElasticSearch 개발 환경 데이터를 조작할 일이 있었는데, 그때 색인되어 있던 데이터를 일괄 삭제하고 재색인하는 것을 보고 깜짝 놀랐었다.

결론적으로 AI 는 너무 많은 지식을 갖고 있는 반면, 사용자가 요구한 사항만 준수했는지에 대한 정확한 검증이 필요하다. 이 가드레일 시스템은 앞으로 AI 가 잘못된 방향으로 나아가지 않도록 바로잡아 준다.

예전 향로님이 언급했던, AI 를 설명하는 말 중 하나는 “어린아이에게 칼을 쥐여준 것과 같다”였는데 이 부분이 딱 들어맞는 느낌이다. 칼을 다룰 줄 모르는 어린아이는 쉽게 휘두르지만, 사용법을 정확히 아는 어른은 쉽게 휘두르지 않는다. AI 는 현재 칼을 든 어린아이와 같으니 함부로 휘두르지 못하게 막아야 한다.

2장. 환경 구성

이 장은 환경 구성을 중점으로 진행되며, 클로드 코드 설치, gcloud CLI 설치와 더불어 클러스터 설정 및 애플리케이션 구성까지 모두 한 번에 클로드를 통해 진행된다.

위 이미지처럼 실습을 단계별로 진행하고, 끝날 때마다 체크리스트로 어디까지 완성되었는지 검증을 거치며, 스스로 생각해 보지 못했던 질문 거리들을 툭 던져주기도 한다.

이 장을 진행하다 보면 점점 책과 거리가 멀어지고 AI 세션과 나만 남아 과정을 전부 진행하게 되는데, 로드맵 설정이 워낙 잘 되어 있어서인지 명령어 한두 줄만 입력하면 곧바로 설정이 완성된다.

또한 statusline 이라는 개념을 알지 못했었는데, 이 설정을 통해 AI 가 어떤 작업을 진행하고 있는지와 관련 상황을 눈으로 보면서 진행하니 훨씬 흥미로웠다.