슬랙에 AI 에이전트를 직원처럼 앉혀놓고, 서버 문제 알림을 대신 읽게 했습니다

소개

저는 AI 에이전트를 24시간 대신 켜주는 서비스를 만들고 있습니다. 스터디에서 헤르메스를 노트북에 설치해 보셨다면, 그걸 노트북 대신 클라우드에서 계속 돌려주는 것이라고 보시면 됩니다.

24시간 돌아가니까 문제도 24시간 생깁니다. 새벽 3시에도 슬랙으로 "이거 실패했어요" 알림이 옵니다. 아침에 몰아서 보면 이미 늦고, 그냥 놓치는 알림도 많았습니다.

그래서 사람이 읽는 걸 포기했습니다. 슬랙에 헤르메스 에이전트를 dev1이라는 이름으로 초대했습니다. 프로필 사진도 있고 멘션도 되는, 사실상 직원 한 명입니다. 얘가 알림을 대신 읽습니다.

진행 방법

쓴 도구

1. dev1을 슬랙에 앉혔습니다

슬랙 앱을 하나 새로 만들었습니다. 슬랙 개발자 페이지에서 앱을 만들고 봇 권한을 준 다음 토큰을 받습니다. 그 토큰을 dev1 설정에 넣으면, dev1이 그 앱 이름으로 슬랙에 로그인합니다. 텔레그램 봇 만들어서 헤르메스에 붙이는 것과 순서가 같습니다.

그다음은 사람 초대하는 거랑 똑같습니다. 서버 문제 알림이 오는 채널에 dev1을 초대했습니다. 이제 그 채널에 뜨는 알림을 dev1이 전부 봅니다.

2. dev1에게 준 지시문

길게 쓰지 않았습니다. 핵심은 "확인한 것과 추측한 것을 나눠서 쓰라"입니다.

너는 이 채널의 문제 담당이다. 새 알림이 뜨면 내가 부르지 않아도 아래 순서로 처리해라.

1. 알림에 적힌 걸 전부 읽는다. 요약본 말고 원문을 읽는다.

2. 첨부된 링크를 실제로 열어서 코드와 기록을 확인한다. 추측으로 채우지 않는다.

3. 답할 때 아래 네 가지를 나눠서 쓴다.
   - 증상: 눈에 보인 것만
   - 확인한 사실: 한 줄마다 어디서 봤는지 근거를 단다. 근거를 못 대면 여기 쓰지 않는다
   - 내 추측: 반드시 "추측"이라고 표시한다
   - 아직 모르는 것: 확인 못 한 걸 빠뜨리지 말고 적는다. 여기가 비면 내가 의심한다

4. 우리 구조를 먼저 확인하고 답해라. "일반적으로 이런 경우엔" 으로 시작하지 마라.
   우리는 고객 한 명당 컴퓨터 한 대를 쓴다. 흔한 구조가 아니다.

5. "AI가 하는 일의 양을 줄이자"는 제안은 하지 마라. 그건 우리가 파는 가치다.

6. 코드를 고쳐야 하면 먼저 물어보고 승인받은 다음에 고친다.
   원인을 못 찾았으면 못 찾았다고 써라. 그럴듯한 얘기로 채우지 마라.

결과와 배운 점

dev1은 그동안 코드를 49번 고쳤습니다. 알림을 읽고 시작한 것도 있고 그냥 슬랙에서 시킨 일도 있는데, 어느 쪽이든 "이거 고쳐줘" 한마디면 코드를 고치고 스스로 검사한 뒤 승인 요청까지 올립니다.

그런데 배운 건 실패한 쪽입니다.

시행착오 1 — 알림을 요약해서 주면 AI는 아무것도 못 합니다

앉혀놓고 처음엔 알림이 이렇게 왔습니다.

🔴 이미지 전송 실패
사용자에게 이미지가 배달되지 않았습니다.

사람은 읽을 수 있습니다. 그런데 AI한테는 줄 게 없는 알림입니다. 누가, 왜, 어디서 잘못됐는지가 없으니 "로그를 확인해 보세요" 말고는 할 말이 없습니다.

친구한테 "나 아파"라고 하면 "병원 가봐" 밖에 못 듣습니다. "어제부터 오른쪽 아랫배가 쑤시고 열이 38도야"라고 해야 대답이 나옵니다. AI도 같습니다.

그래서 알림에 에러 메시지 원문 그대로, 누구·언제, 그리고 문제가 있을 코드로 바로 가는 링크를 전부 담게 바꿨습니다.

이거 하나 바꾸고 몇 주 묵은 버그가 잡혔습니다. 카카오톡으로 이미지가 계속 안 가고 있었는데, 거절 사유 원문을 담게 하니 답이 나왔습니다.

A201 — 이미지 제목이 너무 김

AI가 만든 이미지 파일 이름이 58글자였는데, 카카오톡 발송 대행사가 받아주는 길이를 넘겼던 겁니다. 용량도 형식도 아니고 파일 이름 길이였습니다.

시행착오 2 — AI가 쓴 원인 분석의 절반이 틀렸습니다

어느 날 dev1이 사는 컴퓨터가 4시간 반 동안 먹통이 됐습니다. 아주 무거운 일을 하나 시켰더니 생각에 빠져서 아예 대답을 못 하는 상태가 됐고, 그게 계속 반복됐습니다.

복구한 뒤 dev1 본인에게 "네가 왜 죽었는지 분석해봐"라고 시켰습니다. 술술 읽히는 리포트가 나왔습니다. 그런데 4개 주장을 하나씩 확인해 보니 2개만 사실이었습니다.

dev1은 세상에 흔한 구조로 답했습니다. 보통은 큰 서버 하나에 고객 여럿을 태웁니다. 그래서 "한 명이 사고 치면 다 같이 죽는다"가 상식이죠. 그런데 우리는 반대입니다. AI가 우리 구조를 확인하지 않고, 자기가 아는 평균적인 구조로 답한 겁니다.

dev1이 제일 먼저 하라고 한 조치도 그래서 위험했습니다. "AI가 한 번에 처리하는 일의 양을 강제로 줄이세요." 말은 맞습니다. 그러면 안 죽습니다. 그런데 저희가 파는 게 무거운 일을 시켜도 해내는 AI입니다. 그대로 했으면 고장 대신 일 못 하는 AI를 얻을 뻔했습니다.

지시문 4번과 5번은 이 일을 겪고 나서 넣은 줄입니다.

시행착오 3 — 자기가 쓰러지면 자기가 119를 못 부릅니다

AI에게 자기 자신을 고치게 시켰더니, 정작 AI가 멈췄을 때 아무도 못 고쳤습니다.

그래서 AI 바깥에 아주 단순한 감시자를 하나 뒀습니다. 하는 일은 이게 전부입니다.

1. 1분마다 "살아있니?" 물어본다

2. 5번 연속 대답이 없으면 껐다 켠다

3. 슬랙에 알린다

AI일 필요가 전혀 없습니다. 오히려 단순할수록 안 죽어서 좋습니다. 덕분에 지금은 같은 고장이 나도 10분 안에 저절로 복구됩니다. 예전엔 4시간 반이었습니다.

도움 받은 글

• NousResearch/hermes-agent — 헤르메스 원본

• 지피터스 23기 「AI 입문자도 오픈클로·헤르메스로 나만의 반려 에이전트 직접 만들기」 스터디