AI가 장애를 처리하면 엔지니어는 시스템과 멀어진다

저자는 머리가 좋지만, SRE들을 위한 장애 시뮬레이션에 시간을 쓸 회사는 거의 없을 것이다.

왜일까? AI 이전에도 백업 복구, 재해 복구, 자주 사용하지 않는 런북 연습, 다운타임 없이 시크릿을 순환시킬 수 있는지, 시스템을 다른 벤더의 클라우드/플랫폼에 재배포해 보는 것 등을 연습하는 회사는 거의 없었기 때문이다. 그것은 존재하는 운영 작업 중에서 가장 매력적이지 않은 작업이다. 어떤 임원도 이에 관심이 없다. 운영 조직은 다른 모든 사람들과 마찬가지로 화려한 작업을 추진한다: 새 프로젝트를 위한 새 인프라, 멋진 챗봇, 새롭고 화려한 대시보드, 차트를 오른쪽 위로 올리기 등.

항공사 조종사들은 정부가 그 훈련을 의무화하기 때문에 재난 시뮬레이션 훈련을 받는다. 그것이 조종사 면허 유지 조건이 아니라면, 어떤 회사도 비용을 지불하지 않을 것이다.

SRE들이 재난 훈련에 시간을 쓰길 원하는가? 한 걸음 물러서라. 전문 자격증을 지원하라. 그것을 자격증 유지 조건으로 만들어라. 작업을 전문직으로 만들지 않고서는 업계 전반의 전문적 행동을 얻을 수 없다. 면허 없이는 그렇게 되지 않을 것이다. 소비자에게 즉시 보이지 않는 모든 비용 절감이 추가 이익으로 이어지고, 경쟁이 심화되면 결국 경쟁에 뒤처지지 않고 사업을 유지하기 위해 그러한 비용 절감이 필요해지기 때문이다. 모든 업체가 면허를 취득하도록 강요하면 모든 업체가 이러한 비용을 부담해야 하므로 그러한 비용 절감이 금지된다.

AI 사용은 모래늪과 같다고 생각한다.

더 많이 사용할수록, 같은 시스템에서 변경/수정을 하기 위해 AI에 더 많이 의존해야 한다. 결국에는 텅 빈 느낌이 든다; "내가" 만들거나 고친 시스템에 대한 직관적 지식이 없다.

코드 리뷰는 중요하지만, AI 없이 소프트웨어 개발의 모든 단계를 수동으로 수행할 때 얻을 수 있는 정신적 모델을 대체하지는 못한다.

코드가 자율적으로 더 많이 작성될수록, 인간 소유자가 그 코드에 대해 갖는 직관은 줄어든다. 직관의 상실은 시간이 지남에 따라 커지는 기술 부채의 씨앗이다. 충분히 긴 시간이 지나면, 자신의 코드베이스를 보는 것이 첫 출근 날처럼 느껴질 수 있다 (때로는 자신이 시작한 회사에서).

다행히도 이를 완화하고 코드베이스가 "어때야" 하는지에 대한 인간의 직관을 에이전트를 위한 가드레일로 사실상 변환하는 방법이 있다. 그러나 그것 없이는, 각 파도가 이전 파도와 전혀 닮지 않은 확률적 바다에 돛을 펼치는 것이다.

항공 관련 의견이 때때로 나오는 것을 본다. 항공에서 실패는 치명적이며, 운영하는 시스템은 비행 중에 바뀌지 않는다 (말장난 의도).

아마도 SRE를 그런 식으로 훈련시킬 수는 있겠지만, 그렇게 가르치는 것은 효율적으로 _반응_하는 방법일 뿐, 이러한 실패의 독특한 근본 원인을 _고치는_ 방법은 아니다. 항공 비유는 비행 중 엔진 고장과 엔진 디버깅/엔진 재설계를 동시에 훈련하려는 항공기 엔지니어와 같을 것이다.

그것은 소프트웨어 엔지니어링에서 이치에 맞지 않았고, 앞으로도 그럴 것이다. 훈련에 보낸 1분은 미래 장애 가능성을 줄이기 위해 코드베이스를 재작업하는 데 더 잘 쓰일 수 있다. 이 글은 매우 SRE 중심적이다.

그러니까 AI에게 장애를 해결하게 하고, 엔지니어에게는 합성 장애 해결 훈련을 받는 데 돈과 시간을 지불하는 것 같다.

조종사와의 비교는 도메인이 회사와 제품마다 크게 다르기 때문에 좀 어긋난다. 모든 도메인에서 합성 시뮬레이션을 만드는 것은 같은 일에 돈을 두 번 지불하는 것과 같다. 처음부터 엔지니어가 실제 장애를 처리하게 두는 것이 어떨까? 사실 더 나은 시스템을 구축하는 데 더 많은 생각을 쏟는 것이 어떨까?

코드도 마찬가지다.

나는 프로그래머들과 일하는데, 그들이 과거에 작성한 코드에 대해 놀랄 만큼 상세하게 기억하는 것은 드문 일이 아니다.

누군가 발생한 문제를 언급하면, 그들은 잠시 허공을 응시하다가 실제로 그 문제가 코드에서 어디서 비롯되었는지 기억한다. 왜냐하면 약 8개월 전에 그 코드를 작성했던 것을 기억하기 때문이다.

AI가 모든 코드를 생성하게 되면 이러한 기술은 사라질 것이고, 우리는 AI가 코드를 확장하고 유지하기 위해 코드의 상태를 추적하게 하는 영원한 루프에 갇히게 될 것이다.

무작위 엔지니어가 프로덕션 장애 콜에 투입되고 엔지니어가 시스템에 익숙할 것으로 기대되지 않는 변형을 본 적이 있다.

그들은 "그냥 AI를 사용"하여 구성 요소를 이해하고, 문제를 분류하고, 수정 사항을 만들라고 요청받았다. 엔지니어는 AI가 제안한 잠재적으로 평범한 수정을 받아들일지, 아니면 AI를 활용할 줄 모르는 무능한 인력으로 비춰질 위험을 감수할지 선택해야 했다.

엔지니어가 무엇을 선택했는지 짐작할 수 있을 것이다. 수정은 나쁘지 않았지만 일부 엣지 케이스에는 차선책이었다. 우리는 나중에 그것을 수정해야 했다. 이런 상황이 충분히 쌓이면, 엔지니어는 결국 시스템을 상세히 이해하는 것을 포기하게 될 것이다.

능력 향상이 지금처럼 계속된다면, AI가 해결하지 못하는 장애는 인간이 아무리 연습해도 해결하지 못할 것이다.

기사의 비행기 예시가 마음에 들지만, 현실에서는 코드와 같을 것이라고 생각한다. 1.5년 전만 해도 엔지니어들은 기술을 날카롭게 유지하기 위해 여기저기서 여전히 손으로 코드를 작성한다고 말하는 것이 일반적이었는데, 지금은 그런 말을 거의 듣지 못한다.

SRE가 AI가 해결할 수 없는 상황에 직면하면, 그 SRE는 AI 시스템을 사용하여 추가로 분류하고, 다른 곳을 가리키는 식으로 할 것이다.

이것은 AI 이전 경험과 직관을 가진 SRE에게는 효과가 있지만, AI 이후에 들어온 신입에게는 덜 효과적일 수 있다. 이에 대한 해결책이 무엇인지 모르겠다. 어쩌면 연습 훈련이 그것일 수도 있지만, 다른 많은 엔지니어링 분야와 마찬가지로 전체 분야가 흡수될 것이라는 직감이 든다.

취향과 판단에 대한 필요성도 한계가 있으며, 그것조차 모델에 통합되기 전까지는 그렇다.

흥미로운 역학도 있다. 엔지니어가 AI의 출력을 읽고 문제의 근본 원인과 장애를 진단하는 방법을 이해하더라도, 그 학습을 내면화하여 다음에 새로운 장애에 적용하기는 어렵다. 결과적으로 엔지니어는 어쨌든 시스템과 멀어진다.

우리 뇌가 진정으로 시스템을 이해하려면 진단 중에 실패를 경험하고 스스로 이런 종류의 경로 탐색을 수행해야 하는 것 같다. 이것이 우리 뇌가 실제로 배우는 방식과 관련이 있는지 모르겠다.