에이전트도 늙는다 — 68일 묵은 메모리를 전달하는 에이전트 비서

감시를 여러 겹 쌓아놓고도 못 보던 것 — "살아 있나"와 "맞게 가나"는 다른 질문이었습니다

고장 난 에이전트를 찾는 건 쉽습니다. 에러가 나니까요.

이날 하루에 같은 병을 세 번 찾았는데, 셋 다 에러를 하나도 내지 않았습니다. 제일 오래된 건 68일 묵어 있었습니다. 그리고 그걸 고치려고 만든 감시 장치가, 가동 10분 만에 진짜 사고를 잡았습니다.

1. 감시는 여러 겹인데, 전부 같은 질문이었다

주말에 스터디장님이 학습 자료를 하나 공유해 주셨습니다. AI 에이전트의 작업을 실행하고 기록하고 평가하고 고치는 "루프"를 직접 만들어 보는 실습 자료였는데요.

훑어보다가 좀 머쓱해졌습니다. 이름은 처음 듣는데 전부 제 시스템에 이미 있는 것들이었거든요. 비싸게 깨져 가며 하나씩 만든 부품들이 교과서에는 처음부터 정리되어 있었습니다.

"그럼 적용 할 게 없나" 하고 덮으려는데, 딱 하나 대응물이 없는 개념이 있었습니다.

자료 속 부록 하나가 에이전트의 작업 상태를 다섯 가지로 나눕니다. 계획대로 / 애매함 / 벗어나는 중 / 모순됨 / 막힘. 포인트는 판정 근거였습니다. 코드가 잘 돌아가느냐가 아니라, 정해둔 원본과 어긋나지 않았느냐를 봅니다.

제 시스템에는 감시가 꽤 많습니다. 야간 작업이 죽으면 되살리는 감독 프로그램, 일요일마다 리포트가 왔는지 확인하는 루프, 실패하면 알림을 보내는 잡.

그런데 목록을 놓고 보니 전부 한 가지만 묻고 있었습니다 — "살아 있나?"

"맞게 가고 있나?"를 묻는 감시는 하나도 없었습니다.

2. 그날 하루, 같은 병을 세 번 봤다

하나 — 작업은 완주했는데, 장부는 3일 전

대본을 분석 기준으로 다시 써 보며 기준 자체를 검증하는 야간 작업이 있습니다. "어떤 작품이 어디까지 됐나"는 장부 문서 하나에 적어 두고, 모든 판단이 이 문서를 믿습니다.

폴더를 직접 세어서 장부와 맞춰봤더니:

• 작업은 완벽하게 살아 있었습니다. 밤새 성실하게 돌았고 알림도 정상이었습니다.

• 그런데 장부는 3일 전이었습니다. 작품 하나가 15회차를 완주했고 다음 작품이 이미 시작됐는데, 장부만 그걸 몰랐습니다.

세는 과정도 문제였습니다. 결과 파일을 "그냥 전부" 세면 282개, 문서에 적힌 산문 규칙을 옮겨 적용하면 176개, 진짜 정답 규칙으로 세면 124개. 세 번 다 달랐습니다. "세지 말 것" 폴더의 이름이 9가지로 제각각이라, 정답 규칙이 코드가 아니라 문서 머리말 산문으로만 있었기 때문입니다.

살아 있나를 묻는 감시는 여기서 아무 경보도 울리지 않습니다. 죽은 게 없으니까요.

둘 — 검사기를 고치면 기존 검사가 조용히 깨진다

양식을 검증하려고 성격이 다른 파이프라인 하나에도 같은 표를 채워 봤습니다. 매일 아침 자료를 골라 배달하는 작은 자동화였는데, "이건 작아서 채점도 관문도 없을 것"이라던 제 추정과 달리 검사기도 완료 기준도 다 있었습니다.

근데 빈칸은 딴 데 있었습니다. 검사기를 고칠 때 과거의 함정이 계속 잡히는지 확인할 세트가 없다는 것. 여기서도 병은 같습니다 — 검사기는 매번 돌고 있고, 어제와 다른 걸 보고 있는지는 아무도 안 묻습니다.

셋 — 68일간 자기소개를 고쳐 쓰지 않은 비서

비서 에이전트가 하나 있습니다. 세션을 시작할 때마다 자기 기억 파일의 "활성 프로젝트" 칸을 읽고 전달하게 해뒀습니다. 매번 맥락을 다시 잡으라고 만든 규칙이고, 성실하게 잘 지킵니다.

어느 날 그 전달을 유심히 봤습니다. 5월 26일 이후 68일간 한 번도 갱신되지 않은 내용이었습니다. "활성 프로젝트" 칸에는 이미 끝나서 보관함에 들어간 실험이 그대로 살아 있었고, 비서는 그걸 매 세션 성실하게 복창하고 있었습니다.

에이전트는 고장 나지 않았습니다. 시키는 대로 정확히 했습니다. 장부가 늙은 겁니다.

3. 이 병에는 이름이 있었다

찾아보니 시스템 설계 쪽에서 말하는 2층 구조였습니다.

핵심은 한 줄입니다. 낡은 파생 층은 멀쩡해 보입니다. 에러도 로그도 없이 그럴듯한 답을 계속 냅니다.

복창 규칙이 없었으면 낡은 장부는 그냥 방치된 파일이었을 텐데, 매 세션 복창하게 해둔 덕분에 낡은 정보가 매번 대화의 맥락으로 주입되고 있었습니다.

4. 처방 세 층

동기화를 "더 자주 하자"로 풀지 않았습니다. 파생 층은 어차피 또 낡습니다. 대신 낡아도 사고가 안 나는 구조로 바꿨습니다.

① 현황 질문에는 기억 말고 실측. "지금 어디까지 됐나" 에이전트의 질문이 오면 기억을 읽는 게 아니라 정본을 세는 명령을 실행해서 답하게 규칙을 박았습니다. 폴더를 훑어 "작품 × 회차 × 결과" 표를 뱉는 스크립트를 만들어, 저장해 두지 않고 물어볼 때마다 다시 세게 했습니다. 저장본은 반드시 낡기 때문입니다.

② 브리핑은 정본에서 자동 생성. 사람이 손으로 갱신하는 "활성 프로젝트" 칸을 없애는 방향입니다. 정본에서 뽑은 현황을 자동으로 밀어 넣으면, 낡는 속도가 사람 손이 아니라 스케줄에 묶입니다.

③ 워든 — 낡음 자체를 감시. 파생 층 파일들의 갱신 시각을 정기적으로 보고, 기준보다 오래 묵으면 경보를 내게 했습니다. 파이프라인마다 두 칸짜리 명세도 한 장씩 붙였습니다. 위 칸은 표준 어휘 매핑, 아래 칸은 정렬 감시 — 정본이 뭔지, 다섯 상태를 각각 어떤 명령으로 판정하는지(산문 금지), 상태별 다음 행동이 뭔지 적습니다.

5. 그 워든이, 가동 10분 만에 진짜 사고를 잡았다

배선하고 검증 런을 돌리는데 런이 끝나지 않았습니다.

파보니 파일 하나를 여는 시스템 호출에서 무한 대기에 걸려 있었습니다. 추적해 보니 저장소 쪽 고장의 재발이었습니다. 예전에 한 번 크게 앓았던 병입니다.

이때 워든이 남긴 판정은 막힘이었습니다. 사유는 "문서 폴더 접근 실패, 저장소 고장 의심", 다음 행동은 "진단 절차로". 다섯 상태에 막힘을 넣어둔 게 이날 처음 일했습니다.

그날 낮에 비서 에이전트가 한동안 무응답이었는데 원인을 못 찾고 넘어갔었거든요. 같은 저장소 고장의 동반 증상이었을 가능성이 높다는 게 이 추적에서 나왔습니다.

배운 점

하나. 감시는 두 축이다.

"살아 있나"(생사)와 "맞게 가나"(정렬)는 다른 질문입니다. 병원에 비유하면 심장이 뛰는지 보는 것과, 진료 기록이 실제 환자 상태와 맞는지 보는 것의 차이입니다. 저는 앞의 축만 여러 겹 쌓아두고 뒤의 축은 이번에 처음 세웠습니다.

둘. 낡은 기억은 죽은 시스템보다 찾기 어렵다.

죽은 건 침묵하니까 언젠가 들통납니다. 낡은 건 매번 자신 있게 답합니다. 그래서 "살아 있나" 감시로는 영영 안 잡히고, "언제 갱신됐나"를 따로 물어야 합니다.

그리고 얄궂게도 성실할수록 위험합니다. 복창 규칙이 없었으면 낡은 파일은 그냥 방치돼 있었을 텐데, 잘 지킨 덕분에 매 세션 확성기를 탄 셈이 됐습니다.

셋. "막혔다"를 제3의 상태로 만들어두면, 첫 시험은 실전이 대신 쳐준다.

워든이 10분 만에 잡은 건 운입니다. 하지만 막힘이라는 상태를 미리 정의해 둔 건 운이 아닙니다. 정상도 고장도 아닌 칸을 만들어두지 않았다면, 그 무한 대기는 그냥 "느리네"로 넘어갔을 겁니다.

현황을 묻거든 기억에서 꺼내지 말고, 그 자리에서 세게 하십시오.