반복업무 줄이기

AI 메모리가 며칠째 안 쌓이고 있었습니다 — 안 변하는 숫자를 의심하는 법

계속 쓴다2026-08-10·읽기 6분·글 써봄

AI메모리에 배운 것을 저장하는 작업을 예약해 뒀는데, 며칠째 아무것도 안 쌓이고 있었습니다.

화면에는 오류가 없었습니다. 집계 숫자도 정상으로 보였습니다. 다만 그 숫자가 며칠째 똑같았습니다.

1. 실패가 시작된 날을 찾습니다 2. 그날 무엇이 바뀌었는지 봅니다 3. 안 변하는 숫자에 경고를 붙입니다 4. 경고가 한꺼번에 터진 날을 시작일로 오해하지 않습니다

증상 — 숫자가 안 변합니다

증상 — 오류 알림은 없습니다. 화면도 정상입니다. 그런데 저장된 파일이 안 늘고, 집계 숫자도 그대로입니다.

학습 파일과 집계 화면이 같은 날짜에서 멈춰 있는 상태를 정리한 터미널 화면

원인 — 집계 화면이 저장된 파일을 세서 보여주는 구조였습니다. 파일이 안 쌓이니 숫자도 안 변합니다. 화면 입장에서는 오류가 아니라 "어제와 같음" 입니다.

저는 이 숫자를 매일 보면서도 이상하다고 못 느꼈습니다. 값이 그럴듯하니까요. 틀린 숫자보다 안 변하는 숫자가 더 안 보입니다.

실패가 시작된 날을 찾습니다

해결 — 로그를 날짜별로 늘어놓고 처음 실패한 날을 찾습니다.

특정 날짜부터 저장이 전부 실패로 바뀌는 로그를 정리한 터미널 화면

journalctl --user -u 학습작업.service --since "14 days ago" \
  | grep -E "성공|실패" | awk '{print $1, $2, $NF}' | uniq -c

깨끗하게 갈립니다. 어느 날까지는 전부 성공이고, 그다음부터 전부 실패입니다.

이렇게 갈리면 원인은 그날 바뀐 것입니다. 코드를 아무리 봐도 안 나옵니다. 코드는 그날 안 바뀌었으니까요.

제 경우 원인은 로그인 토큰이 무효화된 것이었습니다. 저장할 때 인증이 필요한데 그게 끊겨 있었습니다. 코드는 처음부터 맞았습니다.

로그를 열어 보니 매번 HTTP 401 이 찍혀 있었습니다. 그런데 그 로그가 작업 안쪽에만 남고 알림으로는 안 나왔습니다. except: pass 로 넘기고 다음 대상으로 가는 구조였기 때문입니다.

for item in items:
    try:
        save_memory(item)          # 여기서 401
    except Exception:
        continue                   # 조용히 다음으로 ← 실패가 사라진다

넘기더라도 세어야 합니다. 몇 건 중 몇 건이 실패했는지가 남으면, 전부 실패한 날이 바로 보입니다.

함정 — 경고가 한꺼번에 터진 날

여기서 한 번 더 헷갈렸습니다.

경고 기준일에 도달하자 전체가 동시에 경고를 내는 구조를 정리한 터미널 화면

경고를 "마지막 저장 후 3일" 로 걸어 뒀습니다. 그래서 실패가 시작되고 3일째 되는 날, 전부 한꺼번에 경고가 터졌습니다.

그날 뭔가 큰일이 난 줄 알고 그날 바뀐 것부터 뒤졌습니다. 실제 시작은 3일 전이었습니다.

날짜	실제 상태	화면
8-03	실패 시작	조용함
8-04	계속 실패	조용함
8-05	계속 실패	경고 폭발

경고가 터진 날은 임계값에 닿은 날이지, 문제가 시작된 날이 아닙니다. 이걸 구분 못 하면 엉뚱한 날짜를 조사합니다.

해결 — 경고 문구에 마지막 성공 시각을 같이 넣습니다.

notify(f"{name} 학습이 {days}일째 안 됩니다 (마지막 성공 {last_ok})")

이 한 줄이면 터진 날과 시작된 날이 같이 보입니다.

안 변하는 숫자를 잡는 장치

숫자가 그대로인 것도 신호로 다뤄야 합니다.

if current == state["last_value"]:
    state["same_days"] += 1
    if state["same_days"] >= 3:
        notify(f"{name} 값이 {state['same_days']}일째 그대로입니다: {current}")
else:
    state["same_days"] = 0
    state["last_value"] = current

대상	안 변하면
저장된 파일 수	저장이 실패하고 있을 수 있음
집계 숫자	원본이 안 쌓이고 있을 수 있음
마지막 갱신 시각	작업이 안 돌고 있을 수 있음
로그 크기	프로그램이 일을 안 하고 있을 수 있음

주의할 것이 있습니다. 원래 잘 안 변하는 값에 이걸 걸면 경고만 시끄러워집니다. 저는 매일 늘어야 정상인 것에만 붙였습니다.

점검할 때 볼 것

확인	이상 판정
마지막 저장 파일의 시각	주기보다 오래됐으면 이상
파일 개수 추이	며칠 그대로면 이상
실패 로그의 시작일	어느 날부터 갈리는지
인증 상태	저장에 인증이 필요하면 같이 확인

두 번째와 네 번째를 같이 보는 게 중요합니다. 저는 인증 쪽을 아예 점검 목록에 안 넣어 두고 있었습니다.

점검 스크립트는 이 정도면 됩니다. 마지막 파일의 수정 시각만 봐도 대부분 잡힙니다.

find data/memory -name "*.json" -printf '%T@ %p\n' \
  | sort -rn | head -1 | awk '{print strftime("%F %T", $1), $2}'

이 값이 오늘 날짜가 아니면 그때부터 이상입니다. find 한 줄이라 어디에든 붙일 수 있습니다.

확인 못 한 것

저장이 실패했을 때 그 내용을 어딘가에 임시로 쌓아 뒀다가 나중에 다시 넣는 방법이 있는지는 확인하지 못했습니다. 지금은 실패한 날의 학습 내용이 그냥 사라집니다.

임시 파일에 모아 두고 인증이 돌아오면 몰아서 넣는 식이면 될 것 같은데, 그렇게 하면 순서나 중복 문제가 생길 것 같아서 아직 안 만들었습니다. 실제로 문제가 되는지도 확인해 보지 않았습니다.

판정 — 계속 쓴다

"안 변하는 값" 경고는 값어치가 큽니다. 코드 몇 줄인데, 오류를 안 내고 조용히 멈춘 것을 잡아냅니다.

경고 문구에 마지막 성공 시각을 넣는 것도 그렇습니다. 이게 없으면 매번 언제부터인지 찾느라 시간을 씁니다.

다만 임계값 방식 자체는 늦습니다. 3일 뒤에 아는 건 이미 3일을 버린 것입니다. 저는 기준을 줄일까 하다가, 너무 예민하면 안 볼 것 같아서 그대로 두고 마지막 성공 시각을 넣는 쪽으로 갔습니다.

직접 하실 분께

하나. 매일 늘어야 정상인 값에 "안 변하면 경고" 를 붙이세요.

둘. 경고 문구에 마지막 성공 시각을 넣습니다. 시작일과 터진 날은 다릅니다.

셋. 실패가 어느 날부터 갈리는지 먼저 봅니다. 깨끗하게 갈리면 코드가 아니라 그날 바뀐 것이 원인입니다.

넷. 저장에 인증이 필요한 작업이면 인증 상태도 점검 목록에 넣습니다.

다음에는 저장이 실패한 동안의 내용을 모아 뒀다가 나중에 넣는 방법을 만들어보려고 합니다. 되면 이어서 적겠습니다.

#AI메모리 #자동화 #점검 #모니터링