[AI 에이전트를 30일간 방치] 실제로 고장 난 건 이것.

출처: Dev.to

항상 켜져 있는 AI 에이전트라는 약속은 놀라울 정도로 단순합니다: 작업을 설명하고, 잠을 자면, 일이 끝난다는 것이죠. “다시 확인할게요”, 휴가, 월요일에 시작하는 일은 없습니다. 혼자 일하는 사람에게는 생산성 해킹이라기보다 비즈니스를 운영하는 것과 비즈니스에 휘둘리는 것의 차이입니다.

저는 그 약속을 샀습니다. 그리고 30일 동안 실제로 살아보았습니다: 하나의 OpenClaw 에이전트를 백오피스—받은 편지함 정리, 리드 조사, 후속 초안 작성, 몇 가지 정기 보고서—에 연결했습니다. 여러 대가 아니라 하나, 한 명의 운영자, 실제 돈이 달린 실제 작업이었습니다.

작동했습니다. 대체로. 하지만 작동하지 않은 방식이 벤치마크보다 에이전트를 실제 운영에 투입할 때 더 많은 교훈을 주었습니다. 랜딩 페이지에 적히지 않는 부분: 실패는 모델이 멍청해서가 아니라 운영 문제였다는 점입니다. 트렌치 코트를 입은 문제였죠. 실제로 저를 괴롭힌 세 가지와 각각에 대해 어떻게 해야 할지 알려드리겠습니다.

첫 주는 마법 같았습니다. 둘째 주가 되자 에이전트가 자신감 있게 잘못된 판단을 내리기 시작했어요—이전에 내린 결정을 무시하고 스레드에 답변하고, 이미 검증한 리드를 다시 조사하고, 아침에 내린 지시와 조용히 모순되는 행동을 했습니다.

이 현상은 이제 “컨텍스트 부패(context rot)”라고 부릅니다. 세션이 오래 지속될수록 컨텍스트 창이 자체 히스토리로 가득 차고, 에이전트가 그 안의 정보를 찾아 행동하는 능력이 떨어집니다—정보는 여전히 존재하지만 말이죠. 일관성은 대략 20~30턴 정도에서 눈에 띄게 감소합니다. 에이전트가 잊어버린 것이 아니라, 무엇이 중요한지 판단하지 못하게 된 겁니다. 2025년 배포 분석에 따르면 기업 에이전트 실패의 약 2/3가 컨텍스트 드리프트와 메모리 손실 때문이라고 합니다. 제 경험과 정확히 일치했죠.

해결책은 더 똑똑한 모델이 아니라 위생입니다:

• 세션을 작업 단위로 제한하고, 하루 단위로 묶지 마세요. 워크플로우마다 새로운 컨텍스트를 시작하는 것이 마라톤형 하나의 스레드보다 낫습니다.
• 중요한 내용—결정, 제약, “하지 말아야 할” 규칙—을 영구 메모리에 체크포인트로 저장하세요. 다음 세션이 의도를 재구성하는 대신 바로 불러올 수 있습니다(9,000 토큰을 스크롤백할 필요 없이).
• 컨텍스트 창이 무거워지기 전에 요약하고 압축하세요, 드리프트가 나타난 뒤가 아니라.

지루하나요? 네. 하지만 제가 바꾼 것 중 가장 레버리지가 큰 부분이었습니다.

9일 차 밤, 프로세스가 죽었습니다. 스택 트레이스가 뜨는 크래시가 아니라, 그냥 멈춘 것이죠. OOM, 불안정한 업스트림 API, 누가 알겠어요. 아침 8시에 알게 되었는데, 아침 브리프가 도착하지 않았고, “어제 업무 종료까지”라고 약속한 고객 팔로업이 아직 초안에 남아 있었거든요.

여기 함정이 있습니다: 저는 에이전트를 일정에 맞춰 자동화했다고 부렸지만, 크론 잡은 감독자가 아닙니다. 스케줄링은 프로세스가 언제 시작할지 알려줄 뿐, 살아있게 유지하거나, 교착 상태를 감지하거나, 복구하는 역할은 하지 않죠. 항상 켜져 있는 에이전트는 장기 실행 서비스이며, 다른 프로덕션 서비스와 마찬가지로 다음이 필요합니다:

• 헬스 하트비트: 에이전트가 실제로 응답하고 있는지 확인하는 체크가 필요합니다. 단순히 실행 중이라는 표시만으로는 부족합니다.
• 자동 재시작(백오프 포함): 일시적인 오류가 스스로 치유되도록 하고, 하루 전체가 놓치지 않게 합니다.
• 인간에게 알림: 스스로 회복하지 못할 때 경고를 보내야 합니다—무음 실패가 가장 치명적이니까요.

에이전트가 새벽 3시에 더 똑똑해질 필요는 없었습니다. 대신 저가 아닌 베이비시터가 필요했죠.

가장 가슴이 철렁한 순간은 에이전트가 실시간 시스템에 되돌릴 수 없는 행동을 했을 때였습니다. 복구는 가능했지만, 제가 우연히 잡아냈기 때문이죠. 자율 에이전트는 실제 세계에서 행동합니다—그게 목적이니까요—즉 자신감 있게 잘못된 움직임을 하면 단순히 문장을 다시 쓰는 것이 아니라, 이미 전송된 이메일, 변경된 레코드, 일어난 사건이 됩니다.

처음부터 가지고 있었으면 좋았을 것들:

• 관측성: 에이전트가 무엇을, 왜 했는지 보여주는 실제 읽을 수 있는 트레이스. 최종 답변만 보는 것이 아니라, “뭐가 생각됐는가”를 알 수 있어야 합니다.
• 스냅샷 및 롤백: 알려진 좋은 상태를 고정하고 언제든지 되돌릴 수 있는 기능. 복구 가능성은 심장마비를 어깨 턱으로 만들죠.
• 돌이킬 수 없는 행동에 대한 가드레일: 금전, 고객, 프로덕션 데이터에 영향을 주는 모든 작업에 확인 단계나 드라이런을 두세요.

여기서 “비결정적 출력” 문제가 학문적 논의에서 벗어납니다. 설문조사에 따르면 예측 불가능성이 에이전트를 프로덕션에 도입하는 가장 큰 장벽이라고 합니다. 예측 불가능성을 없애려는 시도가 아니라, 감당할 수 있는 파급 범위를 설계하는 것이 답입니다.

한 걸음 물러서 보면 세 가지 실패는 리듬을 이룹니다: 메모리 관리, 감독, 복구성—이들은 지능 문제가 아니라, 영리한 데모를 실제 신뢰할 수 있는 인박스로 바꾸는 비광채적인 운영 골격입니다.

업계 수치는 이를 뒷받침합니다. 약 88%의 에이전트 프로젝트가 프로덕션에 도달하지 못하고, 실패의 약 79%는 능력이 아니라 사양·조정 부족에서 비롯됩니다. 반면 프로덕션에 성공한 팀들은 공통적으로 운영 소유권을 갖고 있습니다: 담당자를 지정하고, 모든 변경에 자동 평가를 두며, 모니터링을 기본으로 합니다. 모델 자체가 어려운 부분이 아니라, 모델을 운영하는 것이 어려운 것이죠.

솔직히 말하면 선택지는 이렇습니다. 직접 만들 수 있습니다: 재시작 로직이 있는 감독자, 메모리 체크포인트 전략, 스냅샷/롤백 시스템, 실제 백업, 관측 파이프라인, 그리고 온콜 로테이션—축하합니다, 온콜 로테이션은 바로 여러분입니다. 일부에게는 이것이 올바른 선택일 수 있으며, 관리형과 자체 호스팅을 라인별로 비교해 보시길 권합니다.

하지만 대부분의 솔로 운영자에게는 수학적으로 맞지 않습니다. AI 에이전트의 목적은 차별화되지 않은 작업을 없애는 것이었는데, 이제 여러분이 직접 어시스턴트를 위한 SRE가 된다면 그 목적이 사라집니다. 직접 호스팅 비용을 시간당 인건비까지 포함해 계산해 보면 “무료”가 전혀 무료가 아니라는 걸 알게 됩니다.

바로 이 점이 OpenClaw를 관리형 인프라에서 운영하는 이유입니다: 다른 사람이 신뢰성 레이어—감독 프로세스, 일일 백업, 스냅샷, 모니터링—를 담당하므로, 여러분은 에이전트가 계속 작동하는지 신경 쓸 필요가 없습니다. 직접 구축하고 싶지 않다면, RapidClaw의 관리형 플랜이 감독자, 스냅샷, 백업을 번들로 제공하며 월 $29부터 시작합니다.

30일이 지난 지금, 제 에이전트는 여전히 실행 중입니다. 첫 주와 현재의 차이는 더 좋은 모델이 아니라, 지루한 부분들을 마무리했기 때문입니다—그리고 저는 다시 잠들 수 있게 되었습니다.

— 티조 가우처, RapidClaw