프로덕션 환경에서의 AI 에이전트 모니터링

전통적인 모니터링은 한 가지 질문을 던집니다: 서버가 작동 중인가? 만약 엔드포인트(Endpoint)가 200을 반환한다면 모든 것이 정상입니다. 하지만 AI 에이전트는 이러한 가정을 깨뜨립니다. 서버는 완벽하게 건강한 상태일 수 있지만, 에이전트는 단 하나의 알림(Alert)도 발생시키지 않은 채 조용히 잘못된 출력을 생성하거나, 단계를 건너뛰거나, 예산을 초과하거나, 혹은 완전히 작동을 멈출 수 있습니다.

자율 에이전트(Autonomous agents)를 모니터링하려면 다른 사고 모델(Mental model)이 필요합니다. 실제로 무엇이 고장 나는지, 그리고 이를 어떻게 포착할 수 있는지 알아보겠습니다.

전통적인 모니터링이 놓치는 것들

업타임 모니터링(Uptime monitoring)은 엔드포인트가 응답했다는 사실만을 알려줍니다. 그 응답 내부에서 에이전트가 무엇을 했는지는 말해주지 않습니다. 50ms 만에 {"status": "ok"}를 반환하는 에이전트 엔드포인트는 컨텍스트 길이 제한(Context length limit), 모델 API의 속도 제한(Rate limit), 또는 조용히 실패한 잘못된 도구 호출(Malformed tool call)로 인해 전체 작업을 건너뛰었을 수도 있습니다.

프로덕션 환경의 AI 에이전트에서 발생하는 특유의 실패 모드(Failure modes)는 다음과 같습니다:

조용한 도구 실패 (Silent tool failures). 도구 호출이 에러를 반환하지만, 모델이 이를 무시하고 작업을 계속함으로써 발생합니다. 작업은 "완료"되지만 데이터가 누락됩니다.
컨텍스트 창 고갈 (Context window exhaustion). 장시간 실행되는 에이전트가 작업 도중 토큰 제한(Token limits)에 걸려 작업을 잘라버립니다. HTTP 응답은 여전히 200입니다.
모델 API 성능 저하 (Model API degradation). 기반이 되는 모델 API가 느려지거나 저하된 출력을 반환합니다. 엔드포인트는 살아있지만, 작업 결과는 잘못되었습니다.
시간 경과에 따른 드리프트 (Drift over time). 지난주에는 잘 작동하던 에이전트가 모델 업데이트에 따라 미묘하게 다른 출력을 생성하기 시작합니다. 알림은 울리지 않으며, 출력값만 조용히 변합니다.
예약된 실행 건너뛰기 (Scheduled run skips). 에이전트가 06:00에 실행되었어야 했으나 실행되지 않았습니다. 서버가 다운된 것이 아니기 때문에 기존 모니터링 체계에서는 이를 잡아낼 수 없습니다.

에이전트 모니터링의 세 가지 계층

계층 1: 업타임 모니터링 (Uptime monitoring)

여전히 필요하지만, 그것만으로는 충분하지 않습니다. 에이전트의 HTTP 엔드포인트는 가용성(Availability)과 응답 시간(Response time) 측면에서 모니터링되어야 합니다. 저하된 모델 API는 종종 실패를 일으키기 전, 지연 시간(Latency) 증가로 먼저 나타나곤 합니다.

에이전트가 노출하는 엔드포인트(Endpoint)에 업타임 모니터(Uptime monitor)를 설정하세요. 30초 간격의 체크는 대부분의 장애를 사용자가 인지하기 전에 포착할 수 있습니다. 타임아웃 알림(Timeout alerts)을 구성하십시오. 만약 에이전트가 평소에는 10초 미만으로 응답하다가 90초가 걸리기 시작한다면, 비록 여전히 200 상태 코드를 반환하더라도 무언가 잘못된 것입니다.

curl -X POST https://api.tickstem.dev/v1/monitors \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -H "Content-Type: application/json" \
...

레이어 2: 하트비트 모니터링 (Heartbeat monitoring)

업타임(Uptime)은 서버가 살아있는지를 알려줍니다. 하트비트(Heartbeat)는 에이전트가 실제로 작업을 수행했는지를 알려줍니다.

하트비트 모니터는 데드맨 스위치(Dead man's switch)처럼 작동합니다. 에이전트가 각 작업을 성공적으로 완료한 후 핑(Ping)을 보냅니다. 예상된 시간 범위 내에 핑이 도착하지 않으면 알림을 받게 됩니다. 서버가 가동 중인지 여부는 중요하지 않습니다. 작업이 중단되었다면 하트비트가 이를 포착합니다.

# 하트비트 생성 — 토큰 저장
curl -X POST https://api.tickstem.dev/v1/heartbeats \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
...

핑은 에이전트가 자신의 출력을 검증한 후, 성공했을 때만 발생합니다. HTTP 응답이 무엇을 말하든 간에, 침묵은 곧 실패를 의미합니다.

레이어 3: 실행 이력 (Execution history)

가장 활용도가 낮은 레이어입니다. 예약된 모든 에이전트 실행은 실행 시간, 소요 시간, 성공 여부, 그리고 반환값 등을 포함한 로그 기록을 생성해야 합니다.

이것이 없다면, 장애 발생 시 디버깅(Debugging)을 위해 흩어진 로그로부터 무슨 일이 일어났는지 재구성해야 합니다. 실행 이력이 있다면, 실행 이력을 열어 즉시 확인할 수 있습니다. 예를 들어, 06:03에 실행된 작업이 평소 45초가 아닌 4분이 걸렸고, 500 에러를 반환했으며, 응답 본문(Response body)에 모델 API의 속도 제한(Rate limit) 에러가 포함되어 있다는 사실을 바로 알 수 있습니다.

에이전트에 HTTP 기반 스케줄링 (HTTP-based scheduling)을 사용하고 있다면, 실행 이력은 무료로 제공됩니다. 모든 실행은 전체 요청(Request) 및 응답(Response)과 함께 로그로 기록됩니다.

실질적인 규칙: 정해진 일정에 따라 실행되며 다른 시스템이 의존하는 출력을 생성하는 모든 에이전트 작업은 세 가지 레이어(layer)가 모두 필요합니다. 가동 시간(Uptime)만으로는 모니터링이라고 할 수 없습니다. 그것은 단지 맥박을 확인하는 것(pulse check)에 불과합니다.

MCP를 통한 연결

Claude Code 또는 이와 유사한 MCP 호환 에이전트로 빌드하고 있다면, 에디터 내부에서 전체 모니터링 스택(monitoring stack)을 설정할 수 있습니다. Tickstem MCP 서버는 create_monitor, create_heartbeat, list_executions를 네이티브 도구(native tools)로 제공합니다.

훌륭한 에이전트 모니터링이란

목표는 로그를 일일이 뒤져보지 않고도 어느 시점에서든 다음 세 가지 질문에 답하는 것입니다:

에이전트 엔드포인트(endpoint)에 접속 가능하며 정상적으로 응답하고 있는가? (가동 시간 (uptime))
에이전트가 마지막으로 예정된 작업을 완료했는가? (하트비트 (heartbeat))
마지막 N번의 실행에서 어떤 일이 일어났는가? (실행 이력 (execution history))

이 세 가지가 모두 갖춰지면, 디버깅(debugging) 방식은 "뭔가 잘못된 것 같으니 전부 확인해 봐야겠다"에서 "정확히 언제 어떤 일이 일어났다"로 전환됩니다.

Tickstem은 하나의 API 키로 가동 시간 모니터링, 하트비트 체크, cron 스케줄링 및 이메일 검증을 제공합니다. app.tickstem.dev에서 무료 티어 이용 가능 — 신용카드 등록이 필요하지 않습니다.