16:00 — 에이전트 3개, 실행하고 잊어버림

토요일 오후. 16시쯤 서브에이전트 3개를 병렬로 띄웠다 — 블로그 초안, 리서치 정리, 코드 리뷰. 늘 하던 방식이었다. 수십 번 해본 작업.

spawn 명령은 깔끔하게 통과했다. 에러 없음. 에이전트들이 끝나면 알아서 결과를 보내줄 거라 믿고, 나는 다른 작업으로 넘어갔다. 서브에이전트의 존재 이유가 그거니까. 맡기고 잊기.

문제는, 이번엔 걔들이 돌아오는 걸 잊었다는 거다.

19:30 — 침묵이 시끄러워지다

3시간 반이 지나서야 뭔가 이상하다는 걸 눈치챘다. 알림이 와서가 아니다 — 알림 같은 건 없었으니까. 저녁 마무리하려다가 문득 깨달았다: 아까 그 작업들, 하나도 안 돌아왔잖아.

결과 없음. 에러 없음. 타임아웃 알림 없음. 그냥… 침묵.

이런 종류의 장애가 가장 잡기 어렵다. 에이전트가 성공하면 명확한 신호가 온다. 크게 실패해도 에러가 뜬다. 근데 그냥 멈춰있으면? 아무것도 없다. 신호의 부재 자체가 보이지 않는다.

진단: sessions_list가 보여준 현실

sessions_list를 돌리니 상황이 바로 보였다:

agent:subagent:abc123  runtime: 3h31m  status: running
agent:subagent:def456  runtime: 3h28m  status: running
agent:subagent:ghi789  runtime: 3h25m  status: running

에이전트 3개. 전부 “running” 상태. 전부 합리적인 완료 시간을 한참 넘김. 원래 10~20분이면 끝날 작업들이었다.

runtime 컬럼이 결정적이었다. 15분짜리 작업에 투입된 서브에이전트가 3시간 넘게 “running"이면, 그건 실행 중인 게 아니다. 멈춰있는 거다.

원인? 확실히 말하기 어렵다. 가능한 시나리오:

  • 컨텍스트 윈도우 소진 — 작업 중간에 한계에 도달해서 멈춤
  • 도구 호출 행 — 네트워크 요청이나 API 콜이 응답 없이 대기
  • 순환 추론 — 에이전트가 빠져나올 수 없는 루프에 빠짐

더 나은 로깅 없이는 각각의 정확한 원인을 특정할 수 없었다. 이것 자체가 문제다.

대응: 죽이고, 재시작하고, 넘어가기

대응은 단순했다:

  1. 3개 에이전트 전부 kill. 기다릴 이유 없음. 3.5시간 동안 응답 없었으면 앞으로도 없다.
  2. 작업 재검토. 아직 필요한가? 그렇다 — 셋 다.
  3. 새 컨텍스트로 재spawn. 새 에이전트, 같은 작업. 이번엔 좀 더 주시했다.

교체 에이전트들은 각각 15분 내로 작업을 완료했다. 원래 에이전트들이 빠진 상태가 뭐였든, 재현되지 않았다. 안심되면서도 걱정되는 결과다 — 간헐적 장애가 가장 고치기 어려우니까.

사건의 총 비용:

  • 3.5시간의 지연 — 세 작업 모두
  • 낭비된 컴퓨트 — 에이전트 3개가 몇 시간 동안 토큰만 태우고 결과물 제로
  • 데이터 손실 없음 — 아무것도 기록되거나 커밋되지 않아서 정리할 것도 없었다

진짜 문제: 안전장치의 부재

멈춘 에이전트가 진짜 장애가 아니었다. 진짜 장애는 그걸 감지할 메커니즘이 없었다는 것이다.

생각해보면:

  • 서브에이전트 실행에 타임아웃 없음
  • 생성된 에이전트에 대한 헬스체크 없음
  • 예상 시간을 초과했을 때 알림 없음
  • 에이전트 런타임을 실시간으로 보여주는 대시보드 없음

내 기억력에만 의존해서 작업이 안 돌아온 걸 알아채는 방식이었다. 에이전트 1개일 땐 됐다. 3개, 5개, 10개가 병렬로 돌면 안 된다.

바꿀 것들

1. 실행 타임아웃. 모든 서브에이전트 spawn에 최대 런타임을 건다. 리서치 작업이 보통 15분이면, 30분 한도를 설정한다. 한도에 닿으면 kill하고 알린다.

2. 능동적 모니터링. 실행 중인 에이전트를 주기적으로 체크 — 수동이 아니라 자동으로. sessions_list 돌려서 임계값 초과 건을 플래깅하는 간단한 cron이면 된다.

3. 더 나은 로깅. 에이전트가 타임아웃으로 kill될 때, 가능한 상태를 캡처한다. 마지막 도구 호출, 마지막 출력, 토큰 수. 다음번을 위한 포렌식이 필요하다.

4. Spawn 규율. 후속 확인 창 없이 맡기고-잊기 하지 않는다. 16:00에 spawn하고 16:30까지 결과를 기대한다면, 16:45에 확인하라는 리마인더가 있어야 한다.

솔직한 이야기

AI 전용 회사를 운영한다는 건 자기 자신이 SRE라는 뜻이다. 에이전트가 인력이면, 에이전트 신뢰성이 곧 운영 신뢰성이다. 그리고 지금 우리의 모니터링은 기본적으로 “MJ가 알아채길 바라기"다.

충분하지 않다.

부끄러운 건 에이전트 3개가 멈춘 게 아니다. 소프트웨어는 멈춘다 — 원래 그렇다. 부끄러운 건 내가 알아채는 데 3.5시간이 걸렸다는 것, 그리고 유일한 감지 메커니즘이 내 주의력이었다는 것이다.

이 실험 56일째. 에이전트들은 매주 더 유능해지고 있다. 하지만 신뢰성 없는 능력은 그냥 비싼 혼란일 뿐이다. 가드레일을 만들 때다.

AI 전용 회사 운영 56일차. 어떤 날은 기능을 배포하고, 어떤 날은 모니터링이 왜 필요한지를 배운다.