생성형 AI가 시스템 관리자를 위해 할 수 있는 6가지

생성형 AI와 AI 전반에 대해 언급할 때, 우리의 목표는 단순히 비용을 절감하는 것이 아니라 사람들의 삶을 개선하는 것이어야 한다는 점을 분명히 해야 한다. 필자의 관점에서 AI는 제품이 아니라 지원 기술이다. 정말 스트레스가 많은 직업을 가진 똑똑한 사람들이 어떻게 이 기술을 활용할 수 있는지에 초점을 맞춰야 하는 기술이다. 바로 시스템 관리자, 사이트 안정성 엔지니어, 엔터프라이즈 아키텍트, 네트워크 관리자, 데이터베이스 관리자 등이다. 통칭해 운영 인력이라고 부르기도 하는 이 사람들이 필자에게 중요하기 때문에 AI로 이들의 고민을 해결하는 방법을 알아보겠다.
 

생성형 AI 기술은 날로 성숙하고 있다. 우리는 이 기술을 잠시 사용해 봤고, 언제, 무엇을 위해, 무엇을 위해 사용해야 하고 사용하지 말아야 하는지 알게 됐다. 시스템 관리자와 같은 운영 담당자에게 생성형 AI는 시간과 좌절감을 줄여줄 뿐만 아니라 자신감을 높여줄 수 있는 잠재력을 가지고 있다. 생성형 AI와 LLM을 통해 시스템 관리자의 생산성과 정확성을 높일 수 있는 5가지 방법을 소개한다.
 

로그 분석 수행

시스템 관리자, 네트워크 관리자, 데이터베이스 관리자 등 운영 담당자는 시스템 로그를 지속적으로 검토하여 수백만 개의 알림 중에서 패턴을 파악한다. 운영 담당자는 시간이 지남에 따라 어떤 유형의 알림은 4만 건, 다른 유형의 알림은 3만 건, 또 다른 유형의 알림은 5,000건이 정상인 경우와 비정상적인 알림이 심각한 경보의 원인이 되는 경우를 학습한다. 실제로는 1,000개와 2,000개가 진짜 문제를 알리는 경고이다. 이런 분석에 도움을 줄 수 있는 제품이 있지만, 결국 전화를 거는 것은 사람이고, 전화를 계속 걸어야 하는 것도 사람이다.

생성형 AI가 이런 운영 인력의 직접 개입을 완전히 대신할 수는 없지만, 보다 효율적이고 자신감 있게 경보를 분석하는 데 도움을 줄 수 있다. 실제로 시스템, 네트워크, 데이터베이스 관리자는 알림을 조사할 때 무엇을 할까? 조사를 하면서 스스로 교육한다. 보통은 구글 검색을 많이 이용한다. 이들은 알림의 정의를 찾아본 다음 특정 인프라나 환경의 맥락에서 그 의미를 종합적으로 파악해야 한다. 언어 모델을 훈련하는 방법과 비슷하게 들릴 것이다. 바로 그렇다.

로그 항목이 좋은지, 나쁜지, 무의미한지 판단하는 것은 항상 일종의 예술적인 작업이다. 예를 들어 새벽 2시에 정전이 발생한 후 서비스를 복구할 때 사람이 100%의 신뢰 구간을 갖는다는 것은 불가능하다. 우리는 서비스가 다시 작동한다고 '생각'하고, 로그를 확인하고, 한눈에 살펴본 다음, 완벽하지는 않지만 다시 작동하고 '정상 상태'로 복구됐다고 선언한다. 그러고는 다시 잠자리에 든다!

"오류 메시지"에 대한 로그를 분석할 때도 마찬가지이다. 인간 프로그래머가 영문 오류 메시지를 작성하면 인간 관리자가 로그 어딘가에서 오류 메시지를 분석한다. 이 두 당사자 간의 커뮤니케이션은 아무리 해도 불완전하다. 이런 불완전한 커뮤니케이션은 오탐을 발생시키고 관리자의 업무 수행 속도를 저하시킬 수 있다. 관리자는 확신할 수 없고 언어 모델도 확신할 수 없지만 언어 모델은 사람이 의심스러운 알림에 대해 올바른 판단을 내릴 가능성을 높일 수 있다. 이는 인간에게 생체 공학적 역량이 될 것이며, 근무 시간은 물론, 새벽 2시에 서비스 중단 사고가 발생했을 때도 더 나은 삶을 살 수 있도록 해 준다.
 

환경 구성 파일 생성하기

아무것도 없는 상태에서 환경 구성 파일을 생성하는 것을 좋아하는 관리자는 없다. 형식의 복잡성, 구식 구문, 소프트웨어 버전 간의 구문 차이, 환경별 요구 사항, 유효성 검사, 보안 문제, 통합 문제 등등 해결해야 할 과제가 끝도 없다. 또한 한 대의 서버(Bind, Apache, Nginx, Redis 등)가 프로덕션 환경에서 필요한 모든 작업을 수행하려면 총 5개, 10개 또는 20개의 서로 다른 환경 구성 파일을 조합해야 할 수도 있다. 관리자는 네트워크 인터페이스, DNS, NTP, 웹 서버 등이 모두 완벽하게 구성되어 있는지 확인해야 한다.

이런 모든 이유로 생성형 AI를 사용해 환경 구성 파일을 생성하면 시간을 크게 절약할 수 있으며, 수백 명의 작업 시간을 단 몇 시간으로 줄일 수 있다. 하지만 생성형 AI에 환경 구성 파일 생성을 전적으로 맡기는 것은 위험하다. 예를 들어, 조직에 특화된 요인을 해결하거나 업계 표준 및 규제 의무를 준수하는지 확인하기 위해 사람이 파일을 검토하고 검증해야 한다. 또한 향후 번역 시 문제가 발생하지 않도록 환경 구성 파일이 문서화되어 있는지 확인해야 한다. 

깃허브 코파일럿이나 앤서블 라이트스피드(Ansible Lightspeed)를 보면 생성형 AI가 이미 파이써이나 루비, Node.js 등의 공식 언어 구문을 생성하고 있다. 이미 변화가 시작된 것이다. 이를 환경 구성 파일과 같은 훨씬 더 제한된 구문으로 확장하는 데는 그리 긴 시간이 걸리지 않을 것이다. 더 좋은 점은 앤서블 라이트스피드가 어떤 소스 코드를 기반으로 학습했는지 보여주는 작업까지 인용한다는 점인데, 이는 모든 구문 생성 코드에 필요한 기능일 것이다.
 

환경 구성 파일 번역

환경 구성 파일을 생성하는 것도 힘들지만, 이를 번역하는 것도 힘들다. 서버나 소프트웨어를 업그레이드할 때 환경 구성 파일 형식이 조금만 변경된다고 가정해 보자. 기존 환경 구성 파일을 최신 형식으로 번역해야 서비스(Apache, Redis, Nginx 등)가 제대로 시작되고 실행될 수 있다. 수년 전에 누군가가 직접 작성한 환경 구성 파일의 기능적 무결성을 유지하면서 변경해야 할 사항을 정확하게 번역해야 한다.

시스템 관리자로 일하던 시절, 필자는 고통스러운 환경 구성 파일을 해킹하면서 많은 시간을 좌절감에 빠져 보냈다. 그리고 사람들은 왜 "애플리케이션이 업데이트되었는지 확인"이 가장 쉽게 따를 수 있는 보안 베스트 프랙티스가 아닌지 궁금해한다. 생성형 AI는 이런 작업에 어떤 도움을 줄 수 있을까? 다시 말하지만, 100% 신뢰도는 아니지만 머신러닝 모델은 어떤 환경 구성 옵션이 더 이상 사용되지 않고 어떤 새로운 옵션이 있는지 쉽게 알려줄 수 있다. 무엇이 궁극적으로 괜찮은지에 대한 최종 필터링은 시스템 관리자가 해야 하지만, 머신러닝 모델이 그 과정에서 도움을 줄 수 있다.

또한 LLM을 사용하면서 발견한 베스트 프랙티스가 하나 있다. 생성 또는 번역 중인 아티팩트와 함께 프롬프트 텍스트를 저장하는 것이 좋다. 프레젠테이션용으로 생성하는 이미지의 경우 '프롬프트 텍스트'를 발표자 노트에 넣지만, 환경 구성 파일의 경우 파일에 주석으로 저장한다. 이렇게 하면 미래의 시스템 관리자는 현재의 시스템 관리자가 어떤 생각을 하고 무엇을 달성하려고 했는지 이해할 수 있다. 베테랑 시스템 관리자라면 코드를 보고 작성자를 저주하다가 나중에야 작성자가 자신이라는 것을 알게 된 적이 있을 것이다.
 

'동료'의 관점 제공

가장 좋은 조언은 직접 경험해 본 사람들에게서 얻을 수 있지만, 특정 환경의 소프트웨어 업그레이드는 모두 미지의 영역이다. 기업이 사용하는 표준 운영 환경에 대한 미묘한 뉘앙스와 세부 사항이 항상 존재하며, 특정 워크로드가 잘 실행되도록 하기 위해 해당 표준 운영 환경을 잠깐 변경해야 하는 경우(예: SELinux 비활성화) 더 심할 수 있다.

물론 레딧이나 링크드인 및 기타 관리자들이 모이는 곳을 샅샅이 뒤져볼 수도 있다. 솔루션 업체가 제공하는 매우 긍정적인 사용례의 행간을 읽어볼 수도 있다. 솔루션 업체가 최선을 다한다고 해도 특정 환경에서 사용하는 소프트웨어와 환경 구성의 정확한 조합을 테스트할 수는 없다.

특정 환경에 대해 알아야 할 모든 정보를 종합하는 것은 아무리 말해도 어려운 일이다. 이때 생성형 AI가 도움이 될 수 있다. 자체 회사 데이터를 포기하지 않고도 챗GPT, 바드, 퍼플렉시티(Perplexity), 그래나이트(Granite), 미스트랄(Mistral) 같은 로컬 모델을 사용하면, 예를 들어 특정 퍼블릭 클라우드에서 특정 하드웨어 공급업체의 온프레미스를 사용하는 하이브리드 모델로 또는 소프트웨어 플랫폼의 한 버전에서 다른 버전으로 이동할 때 기업이 어떤 경험을 했는지 물어볼 수 있다.

LLM은 실제로 레딧이나 스택 오버플로우, 블로그 등을 통계적으로 스크랩해 내러티브를 만들고 테마를 찾아내는 데 매우 능숙하기 때문에 AI가 생성한 이런 종류의 ‘스토리’는 꽤 강력하며, 조사 작업의 시간을 절약할 수 있다. 필자는 일반적인 문제와 베스트 프랙티스를 모범 사례를 발견하고 생각할 거리를 풍부하게 제공하는 데 LLM을 성공적으로 활용하고 있다. 그렇지만 생성형 AI가 만든 내러티브는 반드시 확인해야 한다. 물론 신뢰하되 검증해야 한다. 이렇게 신중한 방식으로 LLM을 사용함으로써 어려운 아키텍처 결정을 내릴 때 자신감을 가질 수 있다.
 

셸 강화하기

생성형 AI가 셸과 CLI에 통합되는 사례가 등장하고 있다. 셸 명령어는 30~40년 동안 유기적으로 개발되어 왔기 때문에 LLM을 사용하기에 매우 적합한 곳이다. 명령 자체는 이해하기 어려운 간결한 구문을 가지고 있으며, 매뉴얼 페이지도 일반적으로 큰 도움이 되지 않는다. 이런 명령어와 매뉴얼 페이지는 한 사람이 명령어의 사용법을 기억하기 위해 작성한 경우가 많으며, 그런 작성자 모두가 다른 사용자를 배려하는 친절한 사람은 아니다. 우리의 목표가 사람들을 끌어들이고 더 많은 사람들이 리눅스를 사용할 수 있도록 하는 것이라면 LLM 지원 셸은 사람들이 더 편안하게 느낄 수 있는 완벽한 방법이다.

LLM 지원 셸은 신규 사용자가 새로운 환경에 쉽게 적응할 수 있도록 지원하는 것은 물론, 오랜 사용자에게도 도움이 된다. 특히 명령에 복잡한 옵션이 필요한 경우나 한동안 해보지 않은 작업을 수행하려면, 정확한 구문을 잊어버려 헤맨 적인 몇 번인지 셀 수 없을 정도이다. LLM 지원 셸은 사용자가 자연어를 사용해 컴퓨터와 상호 작용할 수 있도록 함으로써 이런 문제를 해결한다. 예를 들어, 사용자는 "이 디렉터리에서 가장 오래된 파일은 무엇인가?" 또는 "237MB보다 큰 파일 모두 찾기" 또는 "이 디렉터리에 있는 모든 파일 이름에서 숫자 제거"라고 질문할 수 있다. 이런 종류의 명령은 대부분 사용자가 오랫동안 잊어버린 암호 구문을 사용해 새로 구성하기에는 매우 복잡할 수 있다.

예전에는 자신의 awk 기업이 얼마나 뛰어난지 사람들에게 보여주기 위한 '플렉스'였지만, 오늘날의 클라우드 운영자와 관리자는 너무 많은 기술을 지원해야 하기 때문에 한 가지 기술에 대해 깊이 있는 전문가가 될 수 없다. LLM 지원 셸, 플러그인 및 래퍼를 활용하는 것이 점점 더 많은 기술을 지원하는 데 있어 핵심이 될 것이다.
 

강화되는 솔루션 업체 소프트웨어 

챗GPT와 같은 공개적으로 사용 가능한 도구와 내부 언어 모델 사용 외에도 IT 솔루션 업체는 자사 제품에 생성형 AI 기능을 적용하기 시작했다. AIOps와 MLOps의 정의는 인프라와 관련된 "LLM을 지원하는 모든 것"을 의미하는 것으로 빠르게 진화하고 있는 것 같다.

그렇지만 몇 가지 흥미로운 사용례가 등장할 것으로 보인다. LLM 지원 도구가 운영체제, 엔터프라이즈 데이터베이스, CRM 소프트웨어 및 기타 대규모 시스템과 같은 복잡한 소프트웨어에 대한 표준 운영 환경을 생성하는 데 도움이 될 것이라고 쉽게 생각할 수 있다.

대규모 엔터프라이즈 워크로드를 배포하려면 요구사항과 베스트 프랙티스를 파악하기 위해 수많은 문서를 읽어야 하는 경우가 많다. 그런 다음 여러 아키텍트(엔터프라이즈, 스토리지, 네트워크, 데이터베이스)가 함께 협력해 문서에서 얻은 지식을 특정 보안 표준, 규정 준수 규칙, 네트워크 구성, 스토리지 구성 및 아키텍처 표준과 종합해야 한다.

이것은 결코 작은 작업이 아니다.

SAP, 오라클 넷스위트, 마이크로소프트 SQL 서버, 레드햇 엔터프라이즈 리눅스에 대한 참조 아키텍처와 수많은 문서를 읽고 직접 조각을 조합하는 방법 대신, 이런 업체 중 한 곳에서 제공하는 LLM 지원 도구를 사용해 보안 표준, 규정 준수 요구 사항, 네트워크 및 스토리지 요구 사항에 따라 조직 내에서 워크로드를 실행하는 데 필요한 구성을 생성하는 미래가 올 것이다. 얼마나 걸릴지 단정할 수는 없지만, 계속 지켜봐야 할 기술이다.
 

관리자와 아키텍트를 위한 언어 모델

시스템 관리자가 LLM과 생성형 AI를 어떻게 사용하든 정확성, 성능, 자원 관리, 데이터 프라이버시 등 여러 가지 요소를 고려하는 것이 중요하다. 또한 더 작고 특수 목적에 맞게 구축된 언어 모델로의 전환이 증가함에 따라 시스템 관리자는 여러 모델을 함께 사용할 수 있는 방법에 대해 고민해야 한다. 또한 이런 모델은 업그레이드, 테스트, 교체 등 애플리케이션에 필요한 것과 동일한 수명 주기 작업이 필요하다.

LLM은 자연어와 잘 작동하기 때문에 관리자와 아키텍트에게 매우 흥미로운 기술이다. LLM은 스토리를 기반으로 작동하며, 우리가 인식하든 인식하지 못하든 스토리는 우리 업무의 모든 곳에 존재한다. 프로그래머가 애플리케이션에 삽입하고 나중에 로그 파일에 덤프하는 모든 오류 메시지는 본질적으로 개발자가 관리자에게 전달하는 이야기이다. 이런 메시지는 어떤 규칙의 제약을 받지 않으며 항상 정확한 것은 아니다. 제대로 이해하기 위해서는 해석과 종합이 필요하다. 이는 로그 파일뿐만 아니라 문서, 참조 아키텍처 등에도 해당된다. 이런 정보 소스 중 어느 것도 100% 정확한 정보를 제공하지는 않는다.

하지만 여기서 제안하는 사항과 앞으로 생겨날 새로운 사용례에서 가장 중요한 공통분모는 운영 담당자, 그리고 그 외 모든 사람이 생성형 AI와 LLM에 자신의 권한과 책임을 떠넘겨서는 안 된다는 것이다. 이는 AI가 자신의 일자리를 빼앗는 것을 원하지 않기 때문이 아니라, AI가 자신의 일자리를 대체할 수 없기 때문이다. 오히려 인프라 및 운영 전문가는 AI를 활용해 자신의 업무를 더 잘 수행할 수 있는 방법을 찾아야 한다.

관리자와 아키텍트는 항상 핵심이었으며, 앞으로도 핵심이 될 것이다.

*Scott McCarty는 레드햇의 RHEL 서버 담당 수석 대표 제품 관리자이다.
editor@itworld.co.kr