에이전트 자기개선 하네스 (7/12) — Heartbeat v2: 15 모드와 escalation

-

알림 시스템을 상태 머신으로 설계하는 기법

핵심 요약

이 글이 전달하는 것: - Heartbeat를 상태 머신으로 설계하는 법 — "살아 있음"을 15개 모드 × 상태 전이로 분해한다. - Escalation을 13개 명시적 이유로 잠그는 기법 — 모호한 알림을 막고 "알 수 없음"을 1급 시민으로 둔다. - False-positive를 줄이는 단일 파라미터 튜닝 — cold-start 타임아웃을 60s → 120s로 올리면 모델 로딩 타임아웃이 사라진다. - Proactive Preferences 피드백 루프 — 사용자의 반응/무반응을 지수이동평균(EMA)으로 escalation 임계에 반영한다.

v1의 한계와 v2의 설계 목표

v1 heartbeat은 이진 상태(alive / dead)로만 작동한다. 이 구조의 한계는 살아 있지만 비정상을 표현할 수 없다는 점이다. 결과적으로 "이상 징후는 감지되지만 원인이 불명확"한 알림이 축적된다.

v2의 설계 목표는 세 가지다: 1. 상태를 상태 × 컨텍스트의 곱집합으로 분해 2. 알림 조건을 명시적 enum으로 고정 3. 사용자 반응을 학습 신호로 편입

기법 1: 15 모드 상태 머신

v2의 모드는 {상태}.{컨텍스트} 네이밍 규칙을 따른다.

상태 클러스터 모드
idle idle.normal, idle.degraded, idle.silent
working working.normal, working.slow, working.stuck
recovering recovering.from-crash, recovering.from-quota, recovering.from-network
escalation escalating, escalated, cooling-down
maintenance maintenance.scheduled, maintenance.unplanned
fallback unknown

작동 원리

중요한 것은 모드 개수가 아니라 상태 전이 그래프다. 예: working.normal → working.slow → working.stuck → escalating. 알림은 임의 시점이 아니라 상태 전이 시점에만 발행된다. 이 제약이 "같은 상태에서의 반복 알림"을 구조적으로 차단한다.

기법 2: 13 Escalation 이유 enum

알림 발생 조건을 13개 명시적 이유로 제한한다:

  1. quota 80% 초과
  2. quota 100% 초과
  3. 동일 에러 3회 반복
  4. 응답 시간 p95 임계 초과
  5. cron job 2회 연속 실패
  6. memory 디렉터리 size 폭주
  7. embedding 서버 응답 없음
  8. external API 5xx 연속
  9. self-review 차단 패턴
  10. retain 태그 검증 실패율 급증
  11. 사용자 제로 응답 (장기간)
  12. 새 에이전트 자기진단 실패
  13. unknown 모드 진입

13번의 역할

13번은 설계상 가장 중요한 항목이다. 불확정 상태를 1급 시민으로 승격시키는 장치다. 분류 불가능한 상황에서 침묵하는 시스템은, 분류 가능한 실패보다 더 큰 잠재 리스크를 가진다. unknown 진입 자체를 escalation 사유로 지정하면 "모르는 것을 모른다고 보고"하는 경로가 확보된다.

기법 3: cold-start 타임아웃 튜닝

False-positive 알림의 지배적 원인은 복잡한 로직이 아니라 단일 타임아웃 값이었다.

  • 증상: 첫 heartbeat 호출이 타임아웃 → 응답 없음 분류 → escalation
  • 원인: 모델 cold-start 로딩 시간(초기 가중치 적재 + 워밍업)이 60초 기본 타임아웃을 초과
  • 조치: cold-start 전용 타임아웃을 60s → 120s로 분리
  • 효과: 해당 경로의 false-positive 제거

적용 가능 패턴

이 발견의 일반화 가능한 원리는: cold/warm 경로의 타임아웃은 별도 상수로 분리해야 한다. 단일 타임아웃 값으로 두 경로를 다루면, 한쪽을 최적화하면 다른 쪽이 손상된다. 운영 실패 60건 분석은 16편에서 다룬다.

기법 4: Proactive Preferences 피드백 루프

알림 임계를 정적으로 두지 않고, 사용자 반응을 신호로 삼아 동적으로 조정한다.

입력 신호

  • 무반응 / "조용히" 신호: 해당 모드의 escalation 임계 상향
  • "왜 안 알려줬어" 신호: 해당 모드의 escalation 임계 하향

학습 파라미터

  • 지수이동평균(EMA) + 14일 윈도우
  • 너무 빠른 학습률 → 알림 누락 (false-negative)
  • 너무 느린 학습률 → 사용자의 반복 수정 요구
  • 14일 윈도우가 수렴성과 반응성의 균형점

측정 결과

EMA 기반 수렴은 정적 임계값 대비 반복 튜닝 요청을 구조적으로 제거한다. 단, 학습 초기 2주 구간에서는 사용자 피드백이 많이 필요하다 — 이 초기 비용을 감수해야 이후가 조용해진다.

한계와 이식 방향

현재의 한계

  • 초기 2주 학습 구간에서 오작동 가능성
  • 13번 (unknown) 진입 빈도가 높으면 피로도 증가 — unknown 하위 분류 추가 필요
  • EMA 윈도우 길이(14일)는 경험적 상수, 도메인 따라 재튜닝 필요

Hermes 이식

  • Heartbeat 트리거: cron + on_turn_start hook
  • 상태 머신 / 13 이유 enum: 그대로 이식
  • Proactive 루프: MemoryProvider.on_memory_write가 사용자 응답 패턴을 메모리에 기록 → escalation 임계 계산이 이 메모리를 참조

적용 가능 범위와 열린 질문

이 설계가 유효한 범위

  • 알림 발생 빈도가 사용자 만족도에 직접 영향을 주는 시스템
  • 상태 분류가 가능한 운영 환경 (관측 가능성 확보)
  • 사용자 피드백이 수집되는 채널이 존재

열린 질문

  • unknown 모드 진입률을 어디까지 낮출 수 있는가
  • EMA 외에 더 나은 학습 곡선이 존재하는가 (칼만 필터 등)
  • 멀티 사용자 환경에서 개별 임계와 공통 임계를 어떻게 분리할 것인가

좋은 알림 시스템의 본질은 알리지 않을 조건을 명시할 수 있는가로 귀결된다. 15 모드와 13 이유는 그 명시화이고, cold-start 튜닝과 EMA 피드백은 그 명시를 오작동에서 보호하는 장치다.

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »