에이전트가 스스로 행동하게 하기 전에 확인해야 할 일곱 가지 점검 사항

저는 작고 대부분 자동화된 출판 환경을 운영합니다. 예약 작업(scheduled job)이 공식 API를 통해 X에 글을 작성하고, 디지털 제품들은 Gumroad에 놓여 있으며, 몇 개의 야간 스크립트들이 이 모든 것을 유지합니다. 그 어떤 것도 크지 않습니다. 하지만 제가 잠들어 있는 동안에도 모두 저를 당황하게 하거나 돈을 잃게 할 수 있습니다.

이것은 어떠한 에이전트(agent), 봇(bot) 또는 예약 파이프라인이 제가 지켜보지 않고 행동하도록 허용하기 전에 제가 실행하는 목록입니다. 모든 항목은 실제로 발생했던 일 때문에 여기에 포함되었습니다. 가설이나 꾸며낸 사건은 없습니다.

1. 첫 번째 작성 전, 자신을 확인합니다

저는 같은 기기에 여러 계정을 로그인해 두었습니다. 그래서 게시 스크립트는 보낼 때마다 API에 “나는 누구인가?”라고 물어보고 그 답변을 하드코딩된 핸들(handle)과 비교합니다. 만약 다르면 멈춥니다. 경고하고 계속하지 않습니다.

이것은 매일 추가적인 API 읽기(read) 비용이 발생하지만 (저는 이를 캐싱합니다). 전체 시스템에서 가장 저렴한 보험입니다.

2. 오래된 파이프라인은 증명될 때까지 활성화된 것으로 간주됩니다

제가 환경을 재구축했을 때, 여전히 실제 게시를 하도록 설정된 오래된 파이프라인을 발견했습니다. 그것이 게시되지 않은 것은 품질 필터가 우연히 모든 것을 거부했기 때문일 뿐이었습니다. 그것은 운이었지 안전 설계는 아니었습니다.

이제 “비활성화(off)”한다는 것은 눈에 보이는 변화를 의미합니다: 제거된 플래그, 오래된 파일의 날짜가 찍힌 백업본, 그리고 무엇을 비활성화했고 언제 했는지 기록하는 원장(ledger)의 메모입니다.

3. 알 수 없는 결과는 다음 전송을 차단합니다

모든 작성은 외부로 나가기 전에 “시도(attempt)”를 기록하고, 나간 후에 결과를 기록합니다: 전송됨(sent), 실패함(failed), 또는 알 수 없음(unknown). 타임아웃(timeout)은 “알 수 없음”이며, 알 수 없는 상태는 사람이 확인할 때까지 큐(queue)를 차단합니다. 재시도는 자동으로 이루어지지 않는데, 왜냐하면 재시도된 게시물, 이메일 또는 결제는 중복이기 때문입니다.

이것은 제가 계속 반복하는 생각과 같은 아이디어입니다: 200을 확인으로(confirmation)가 아닌 주장(claim)으로 취급하십시오. 중요한 곳에서는 객체를 다시 읽어보십시오.

4. 지출 한도는 제공업체 측에 위치합니다

내 스크립트는 일일 5개 게시물 제한이 있고 모든 호출 비용을 기록합니다. 하지만 제가 실제로 신뢰하는 제한은 제공업체(provider) 콘솔에 설정된 것이기 때문입니다. 코드로 인한 제한은 코드가 잘못되었을 때 정확히 실패하기 때문입니다. 또한 이 스크립트는 남은 잔액을 추정하고, 소진되기 전에 일주일 전부터 경고해 줍니다.

5. 제가 직접 제품을 구매하여 파일을 열어봤습니다

이것은 쓰라렸습니다. 저는 제 자체 디지털 제품 중 하나를 테스트 구매했고, 구매자가 할 것처럼 ZIP 파일의 내용을 열어보았습니다. 그 내용 중 절반 정도는 저의 내부 자료였습니다. 출시 계획이나 고객 다운로드에 포함되어서는 안 되는 메모들이었습니다.

해결책은 오직 구매자에게 공개되는 파일만 담긴 클린 빌드(clean build)를 만드는 것이었고, 이후 또 다른 테스트 구매를 진행하여 실제로 도착하는 것을 확인했습니다. 이제 빌드는 재현 가능(reproducible)하며, 동일한 입력값은 항상 동일한 SHA-256 값을 제공하므로 구매자가 정확히 어떤 파일을 받았는지 말할 수 있습니다.

6. 실제 스케줄러에서 밤에 한 번 실행해봤습니다

자동으로 처리되는 작업(unattended job)이 하룻밤 사이에 UnicodeEncodeError로 인해 죽었습니다. Windows 콘솔 코드 페이지(cp932)가 로그 라인에 비-ASCII 문자(non-ASCII character)를 출력할 수 없었던 것입니다. 제가 직접 실행했을 때는 매번 작동했습니다.

어떤 작업은 프로덕션 환경에서 사용할 동일한 스케줄러, 사용자, 로케일(locale), 인코딩으로 실행되기 전까지는 테스트되지 않으며, 그 실패가 로그 파일이 아닌 사람에게 도달해야 합니다.

7. 자동화는 게시물 수를 늘렸을 뿐, 도달률은 아니었습니다

이전에 완전히 자동화된 X 설정은 33개의 게시물을 발행했습니다. 평균 노출(median impressions)은 약 5회였습니다. 자동화는 완벽하게 작동했지만, 아무도 그 결과물을 보지 못했습니다.

그 이후로 저는 답글을 게시물과 별도로 측정합니다. 현재 제 수치에 따르면, 관련 스레드에서의 짧은 답글이 제가 직접 예약한 게시물의 노출보다 몇 배 더 많습니다. 에이전트는 초안 작성 및 예약을 할 수 있습니다. 하지만 대화의 일부가 되는 것은 여전히 사람에게 달려있습니다.

경험칙(The rule of thumb)

만약 이 중 어느 하나라도

저는 이 전체 목록을 7가지 영역에 걸쳐 25개의 점검 사항이 포함된 한 페이지 체크리스트로 만들었습니다. 무료입니다: Agent Ops Pre-Flight Checklist.

저는 여기서 AI 에이전트와 자동화를 프로덕션 환경에서 운영하는 것에 대해 매주 글을 씁니다. 무엇이 고장났는지, 제가 지금 무엇을 점검하는지, 그리고 그것이 얼마나 비용이 들었는지에 대해서 말입니다. 재정적, 법률적 또는 보안 자문은 아닙니다. 모든 것을 자신의 시스템에 맞게 조정하십시오.

원래 NeuralAlpha에 게시되었습니다. 저는 AI 에이전트를 프로덕션 환경에서 운영하는 것에 대해 매주 글을 씁니다.