24시간 인프라 지킴이 AI 봇을 만들었습니다

회사 Slack 채널에 이렇게 메시지를 남깁니다.

@Plaiddy 인프라 현황 점검

잠시 뒤 봇이 답합니다. 게이트웨이는 정상인지, 서버의 메모리와 디스크는 얼마나 사용 중인지, 추가로 살펴볼 항목은 무엇인지 정리해서 보여줍니다. 실제 점검 응답에서는 스왑 사용량이 높다는 항목을 따로 짚어주기도 했습니다.

출처: Plaid Labs 내부 Slack 대화, 작성자 제공.

이 봇의 이름은 Plaiddy입니다. Plaid Labs에서 OpenClaw를 기반으로 구성한 AI Agent로, Slack에서 요청을 받고 인프라를 확인하는 일을 맡습니다. Teleport의 봇 전용 계정으로 서버와 Kubernetes에 접근할 수 있어, 질문에 따라 실행 도구를 사용하고 그 결과를 대화로 돌려줍니다.

“24시간 지킴이”는 필요할 때 불러 일을 맡길 수 있도록 상시 실행한다는 의미입니다. 모든 장애를 자동으로 발견하고 복구한다는 약속은 아닙니다. 이 글에서는 Slack의 한 문장이 실제 인프라 조회로 이어지는 과정과, 그 연결을 운영하기 위해 정리한 것들을 소개합니다.

인프라 담당자가 저 혼자라는 문제

저는 Plaid Labs에서 인프라를 담당하고 있습니다. 그리고 현재 이 일을 맡는 사람은 저 한 명입니다. 제가 자리를 비우거나 바로 응답하기 어려울 때는 다른 팀원이 인프라 상태를 확인하고 필요한 조치를 하는 데 어려움이 있었습니다.

접속 권한만 전달한다고 해결되는 문제도 아닙니다. 어느 클러스터를 봐야 하는지, 이 에러가 지금 서비스에 영향을 주는지, 설정은 어디에서 바꿔야 하는지 같은 운영 맥락이 함께 필요합니다. 그 정보와 실행 경험이 한 사람에게 집중되어 있으면, 작은 확인 작업도 결국 그 사람을 기다리게 됩니다.

봇을 만든 배경은 여기에 있습니다. 제가 부재할 때도 팀원이 현재 상태를 확인하고 필요한 조치를 요청할 수 있는 통로를 만들고 싶었습니다. 평소 쓰는 Slack에서 봇에게 일을 맡기면, 봇이 운영 문서와 접근 도구를 이용해 확인하고 다음 행동으로 연결하는 방식입니다.

인프라 상태를 확인하려면 여러 맥락을 알아야 합니다. 어느 서버에 접속할지, 어떤 Kubernetes 클러스터를 볼지, 배포 설정은 어느 저장소가 관리하는지부터 판단해야 합니다. CPU나 메모리 수치 하나를 읽는 것보다, 질문에 맞는 대상을 찾아 필요한 정보를 모으는 과정이 더 번거로울 때가 있습니다.

Plaid Labs는 서버와 Kubernetes 접근을 Teleport로 관리하고 있습니다. 클라우드 자원은 OpenTofu/Terraform 코드로, Kubernetes 리소스는 Argo CD가 동기화하는 Git 저장소로 관리합니다. 봇에도 이 구조를 알려주고 기존 접근 경로를 연결했습니다.

팀원이 보는 입구는 평소 일하는 Slack입니다. 명령어를 찾아 복사하는 대신 확인하고 싶은 내용을 말하고, 봇은 인프라 문서와 실행 도구를 이용해 요청을 처리합니다. 요청과 결과가 채널에 함께 남으므로 다른 팀원도 어떤 점검이 있었는지 대화의 맥락에서 볼 수 있습니다.

OpenClaw와 Teleport는 각각 무엇을 할까?

OpenClaw는 내 컴퓨터나 서버에서 실행하면서, 메신저의 요청을 AI Agent의 작업으로 연결하는 소프트웨어입니다. Slack 같은 대화 채널, 요청을 처리하는 AI 모델, 파일을 읽거나 명령을 실행하는 도구를 연결합니다. 여기서 Agent는 요청을 이해한 뒤 필요한 도구를 사용하고, 결과를 보며 다음 행동을 정하는 실행 주체입니다. OpenClaw 공식 소개

예를 들어 “서버 상태를 확인해줘”라는 메시지를 받으면, 모델이 요청을 해석하고 연결된 실행 도구로 상태를 조회한 뒤 답하도록 구성할 수 있습니다. OpenClaw는 이 과정에서 메시지 수신, 대화의 맥락, Agent와 도구의 연결을 담당합니다. 저희는 여기에 인프라 운영 지식과 실행 환경을 붙여 Plaiddy를 만들었습니다.

출처: OpenClaw 공식 저장소. © OpenClaw Foundation, MIT.

Teleport는 서버와 Kubernetes 같은 인프라에 누가 접근할 수 있는지 관리하는 시스템입니다. 사용자의 신원을 확인하고, 부여된 역할에 따라 접근을 허용하며, 접속과 실행에 관한 감사 기록을 남깁니다. 사람뿐 아니라 자동화 프로그램에도 별도의 신원을 부여할 수 있습니다. Teleport 공식 소개

두 제품의 역할을 나눠 보면 쉽습니다. OpenClaw 쪽에서는 “요청을 처리하려면 무엇을 해야 하는가”를 정하고 도구를 실행합니다. Teleport는 그 접근을 “어떤 신원과 권한으로 허용할 것인가”를 관리합니다. 다만 권한이 있는 명령이라고 해서 지금 실행하는 것이 적절하다는 뜻은 아닙니다. 그 판단을 보완하는 장치가 뒤에서 다룰 안전 가드레일입니다.

우리 인프라에서는 이렇게 연결했습니다

현재 구성에는 Slack의 요청을 받는 Plaiddy와 인프라 작업용 Agent가 있습니다. Plaiddy는 인프라 Agent를 호출할 수 있고, 인프라 Agent에는 별도의 작업 공간과 운영 문서를 두었습니다. 모든 메시지가 곧바로 서버 명령 하나로 바뀌는 구조는 아닙니다. 먼저 요청을 해석하고, 필요한 작업과 실행 대상을 정합니다.

팀원에게 Slack은 인프라 작업을 요청하는 창구입니다. 서버의 접속 방법이나 클러스터 이름을 모두 외우지 않아도, 확인하고 싶은 상태와 필요한 조치를 대화로 전달할 수 있습니다. 요청과 응답이 같은 채널에 남으므로 관리자가 돌아왔을 때도 어떤 점검과 작업이 있었는지 이어서 볼 수 있습니다.

OpenClaw는 그 요청을 실제 작업으로 연결합니다. Plaiddy가 인프라 Agent를 호출하면, Agent는 운영 문서로 대상과 절차를 파악하고 tsh, kubectl 같은 도구를 사용합니다. 도구가 받은 결과는 다시 Agent를 거쳐 Slack 응답으로 돌아옵니다. 그림의 점선은 이 결과가 돌아오는 경로입니다.

Teleport는 서버와 Kubernetes로 들어가는 접근 경로를 관리합니다. 봇도 저희가 쓰던 접근 체계 안에서 별도의 신원으로 움직입니다. OpenClaw 실행 환경의 tbot이 봇 인증서를 발급받고 갱신하고, 실행 도구는 그 인증 정보를 사용합니다. Teleport는 봇에 부여된 역할을 기준으로 접근을 허용하고 감사 기록을 남깁니다.

인프라 관리자인 저는 운영 절차와 권한, 변경 판단을 맡습니다. 봇이 참고할 문서를 정비하고 어느 자원에 접근하게 할지 설정하며, 조치가 필요하면 Slack에서 작업을 지시할 수도 있습니다. 제가 잠시 자리를 비워도 첫 확인과 작업 요청은 이어갈 수 있고, 저는 위험한 변경의 검토와 운영 기준 정비에 더 집중할 수 있습니다. 다만 어떤 작업을 팀원에게 맡길지, 언제 별도 승인을 받을지는 실행 가드레일로 구체화해야 합니다.

Slack 연결에는 Socket Mode를 사용합니다. 앱이 Slack과 WebSocket 연결을 맺고 이벤트를 받는 방식으로, 이벤트 수신을 위해 공개 HTTP Request URL을 따로 노출할 필요가 없습니다. Slack App의 App-Level Token과 Bot Token은 각각 연결과 봇 API 사용에 필요한 인증을 담당합니다. Slack 공식 문서, OpenClaw Slack 연결 문서

현재 설정은 채널에서 멘션을 요구합니다. 팀의 일반 대화와 봇에게 일을 맡기는 요청을 구분하는 입구입니다. 다만 멘션 여부를 확인하는 설정만으로 인프라 작업의 권한까지 결정되는 것은 아닙니다. 실제 서버 접근에는 별도의 인증이 필요합니다.

봇에게도 자기 이름의 출입증을 준다

사람은 Teleport에 로그인한 뒤 서버나 클러스터에 접근합니다. 봇은 같은 일을 반복하면서 사람의 로그인 세션에 의존하지 않아야 합니다. 여기에는 Teleport Machine ID를 사용했습니다.

Machine ID의 tbot은 자동화 프로그램이 사용할 짧은 수명의 인증서를 발급받고 갱신하는 프로세스입니다. Agent는 이 인증 정보를 사용해 Teleport에 등록된 자원에 접근합니다. 인증서가 만료되기 전에 갱신하는 일과, 이번 요청에서 어떤 명령을 실행할지 판단하는 일을 서로 다른 구성 요소가 맡습니다. Teleport Machine & Workload Identity 문서

출처: Teleport 공식 Machine ID 구성도. © Gravitational, Inc., AGPL-3.0.

그림에서는 tbot이 인증 정보를 저장하고, 아래쪽의 애플리케이션이 이를 읽어 Teleport를 거쳐 인프라에 접근합니다. 저희 구성에서는 봇이 사용하는 실행 도구가 이 인증 정보를 이용합니다. 그림 왼쪽의 Kubernetes·CI/CD·클라우드 인증 방식은 여러 참여 방식의 예시이며, 저희가 모두 사용한다는 의미는 아닙니다.

글을 준비하며 실제 OpenClaw 실행 환경에서 봇의 인증으로 접근 가능한 서버와 Kubernetes 클러스터 목록을 조회했습니다. 두 클러스터 모두 시스템 네임스페이스를 읽는 요청에 정상 응답했습니다. 설정 파일에 접근 경로가 적혀 있는 수준을 넘어, 봇이 사용할 실행 환경에서 조회가 되는 것까지 확인한 셈입니다.

사람 계정과 봇 계정을 나누면 실행 주체도 구분할 수 있습니다. 기존 접근 검증 기록에는 SSH 명령 실행과 Kubernetes 요청이 봇 신원으로 기록되어 있습니다. Slack은 사람이 무엇을 요청했는지 보여주고, Teleport의 감사 기록은 인프라에 어떤 신원으로 접근했는지 확인하는 근거가 됩니다.

확인에서 조치까지, Slack 대화 안에서

봇의 장점은 상태를 읽어주는 데서 끝나지 않습니다. 점검 결과를 바탕으로 조치 후보를 제안하고, 사람이 선택한 작업을 실행하는 과정까지 같은 대화에서 이어갈 수 있습니다.

아래는 실제 Slack 대화입니다. 봇은 클러스터와 Argo CD 상태를 정리한 뒤, Error 상태로 남아 있는 Pod 정리와 동기화가 어긋난 애플리케이션 점검을 후속 작업으로 제안했습니다. 저는 그중 잔여 Pod 삭제를 지시했습니다.

출처: Plaid Labs 내부 Slack 대화, 작성자 제공.

봇은 삭제를 완료했다고 답하면서, 남아 있는 실행 중 Pod의 상태와 서비스 영향 여부도 함께 보고했습니다. 다른 동기화 문제에 대해서는 바로 실행하지 않고 Git과 실제 설정의 차이를 먼저 확인해야 한다고 설명했습니다. Kubernetes의 Pod는 애플리케이션 컨테이너가 실행되는 단위이고, Argo CD의 동기화는 Git에 적힌 설정과 클러스터 상태를 맞추는 과정입니다.

이 사례에서 중요한 것은 점검, 조치 선택, 실행, 결과 확인을 연결했다는 점입니다. 담당자가 직접 터미널을 열어 모든 명령을 입력하지 않아도 대화로 작업을 진행할 수 있습니다. 제가 부재할 때 팀원이 활용할 수 있는 운영 통로가 생긴다는 장점도 여기에서 나옵니다. 다만 이 화면은 담당자인 제가 지시한 사례이며, 비담당자에 의한 장애 복구나 모든 종류의 조치가 검증됐다는 의미는 아닙니다.

가장 큰 과제는 안전 가드레일

조치를 쉽게 요청할 수 있다는 편리함은 잘못된 조치도 쉽게 요청할 수 있다는 부담을 동반합니다. 대상 서버를 잘못 이해하거나, 이미 바뀐 상태를 기준으로 판단하거나, 영향 범위를 충분히 확인하지 않은 채 명령을 실행하면 운영 장애로 이어질 수 있습니다.

여기서 안전 가드레일은 봇이 할 수 있는 일의 범위를 정하고, 위험한 실행 앞에서 확인하거나 멈추게 만드는 장치입니다. 현재 봇에는 운영 변경이 가능한 관리자 역할이 부여되어 있습니다. Teleport의 전용 계정으로 실행 주체는 구분할 수 있지만, 그 자체가 모든 조치의 적절성을 보장하지는 않습니다.

앞의 대화에서는 봇이 조치를 제안하고 사람이 그중 하나를 지시했습니다. 이런 흐름을 일관되게 지키려면 대화상의 약속을 넘어, 실행 도구와 권한에도 제한이 필요합니다. 다음은 이 사례를 바탕으로 보강해야 할 기준입니다.

이 표는 현재 모두 강제되고 있는 기능 목록이 아니라, 운영 조치 범위를 넓힐 때 적용해야 할 기준입니다. 특히 유일한 담당자의 부재를 대비하려면, 매번 그 담당자에게만 승인을 요구하는 구조도 다시 생각해야 합니다. 팀원이 수행해도 되는 제한된 작업과, 별도 승인이 필요한 고위험 작업을 나누고 승인할 수 있는 사람을 정해야 합니다.

봇이 더 많은 일을 할 수 있게 만드는 만큼, 어디서 멈춰야 하는지도 구체적으로 정해야 합니다. 이것이 현재 구조의 가장 큰 과제입니다.

명령어보다 먼저 알려줘야 하는 것

서버에 접속할 수 있다고 해서 올바르게 운영할 수 있는 것은 아닙니다. 같은 설정을 바꾸더라도 어느 계층에서 바꿔야 하는지 알아야 합니다.

예를 들어 Argo CD가 Git의 설정을 기준으로 리소스를 동기화하고 있다면, 실행 중인 리소스만 직접 수정한 변경은 다시 되돌아갈 수 있습니다. 클라우드 자원과 Kubernetes 리소스의 소유 관계를 모르면, 한쪽에서 고친 내용을 다른 쪽이 덮어쓰는 상황도 생깁니다.

그래서 인프라 Agent의 작업 공간에 저장소 지도와 운영 규칙을 넣었습니다. 문서에는 클라우드 자원은 OpenTofu/Terraform이, Kubernetes 리소스는 Argo CD와 GitOps 저장소가 관리한다는 경계가 담겨 있습니다. 배포와 설정 변경은 해당 저장소의 PR을 통해 진행하도록 안내합니다.

여기서 문서는 Agent의 판단을 돕는 맥락입니다. 접근을 막는 권한 정책과 같은 장치는 아닙니다. 문서에 “승인을 받아라”라고 쓰는 것과, 승인 전에는 실행할 수 없도록 도구를 제한하는 것은 구분해야 합니다.

문서의 최신성도 중요합니다. 이번 확인에서도 Agent의 인프라 지도 일부가 현재 Teleport 저장소의 설명보다 오래된 상태였습니다. 문서는 어디를 살펴볼지 알려주는 출발점으로 쓰고, 실제 상태와 최신 설정을 다시 확인하는 과정이 필요합니다. 봇이 기억하는 인프라와 지금 운영 중인 인프라는 달라질 수 있습니다.

점검 결과도 다시 읽어야 한다

처음 소개한 Slack 응답에서 유용했던 부분은 정상 항목과 추가 관찰 항목을 나눠 보여준 점입니다. 여러 명령의 출력을 그대로 나열하지 않아도, 팀원은 무엇을 더 확인할지 빠르게 찾을 수 있습니다.

다만 그 해석까지 항상 맞는 것은 아닙니다. 예를 들어 load average를 CPU 코어 수로 나눈 비율을 CPU 사용률처럼 읽으면 의미가 달라집니다. 스왑 사용량이 높다는 사실만으로 현재 메모리 압박의 원인이나 심각도를 확정할 수도 없습니다. 추가 지표와 시간에 따른 변화를 함께 봐야 합니다. Linux load average 설명, Linux 메모리 압박 지표 문서

따라서 점검 응답에는 조회한 대상과 시점, 확인된 값, 추가 확인이 필요한 해석을 구분하는 방식이 필요합니다. 서버 한 대를 살펴본 결과를 인프라 전체의 정상 판정으로 확대하지 않는 것도 같은 이유입니다.

봇의 장점은 첫 확인에 필요한 정보를 모아 대화로 연결하는 데 있습니다. 원인 판정이나 운영 변경으로 넘어갈 때는 그 응답이 어떤 실행 결과에 근거했는지 다시 확인할 수 있어야 합니다.

24시간 운영하려면 봇의 연결도 살펴야 한다

상시 실행하는 Agent는 인증이 끊기면 인프라를 볼 수 없습니다. 현재는 tbot이 실행 중인지 확인하는 작업을 5분 간격으로 등록해 두었습니다. 이 작업은 프로세스가 살아 있으면 종료하고, 실행 중이 아니면 다시 시작하도록 작성되어 있습니다.

이것은 인증 프로세스의 실행 상태를 확인하는 작업입니다. 인프라 전체의 건강 상태나 인증서 갱신 성공을 매번 검사하는 작업은 아닙니다. 실제 자원에 접근 가능한지는 별도의 조회로 확인해야 합니다.

OpenClaw 게이트웨이, Slack 연결, 모델 응답, Teleport 인증, 대상 서버 중 어느 부분에서든 문제가 생기면 요청이 끝까지 처리되지 않을 수 있습니다. 따라서 봇의 운영에서도 “프로세스 실행 중”과 “실제 요청 처리 가능”을 나눠 보는 것이 중요합니다.

우리에게 생긴 새로운 운영 입구

저 혼자 알고 직접 수행하던 인프라 작업을 팀원이 Slack에서 요청할 수 있는 경로로 옮기고 있습니다. 팀원은 자연어로 요청하고, Agent는 운영 문서와 도구를 사용하며, Teleport는 봇의 신원으로 접근을 관리합니다. 점검에서 필요한 조치까지 연결할 수 있다는 점이 이 봇의 실질적인 장점입니다.

앞으로의 과제는 그 편리함을 유지하면서도, 요청자와 작업별 권한·승인·실행 검증을 더 단단하게 만드는 것입니다. 담당자 한 사람에게 집중된 운영 부담을 줄이려면, 실행할 수 있는 능력과 안전하게 맡길 수 있는 범위를 함께 넓혀가야 합니다.

다른 팀에서도 비슷한 봇을 만든다면, 먼저 범위가 분명한 조회 하나를 끝까지 연결해보는 것을 권합니다. 어느 자원을 어떤 신원으로 조회했는지, 결과가 Slack까지 돌아오는지 확인하고 나면 변경 권한과 승인 절차를 어디에 둘지도 더 구체적으로 판단할 수 있습니다.

이제 우리 팀의 인프라 점검은 이런 한 문장으로 시작할 수 있습니다.

@Plaiddy 인프라 현황 점검

Plaid Labs의 인프라 운영 배경이 궁금하다면 Kubernetes 하이브리드 클라우드 구축기도 함께 읽어보세요.