---
type: advisory
issue: HAN-62
date: 2026-05-20
author: raphael
status: final
---

# [자문] 자율 백그라운드 에이전트 시스템 설계

## TL;DR

완전 자율화보다 **스펙 승인 1회 체크포인트 + 나머지 자율** 구조가 ROI 극대화와 감사 공백 방지를 동시에 달성한다.

---

## 질문 / 결정 사항

사용자 입력 없이 백로그 스캔 → 티켓 생산 → 코드 구현 → PR 생성까지 자율화할 때:
1. 어떤 아키텍처로 파이프라인을 구성할 것인가
2. 어디에 사람이 개입해야 하는가 (승인 게이트)
3. 실패 모드와 상태 관리를 어떻게 다룰 것인가

---

## 자문 참여

- **구현자 관점 (Asurada-role)**: 실패 모드·인프라 전제 조건·상태 관리
- **제품 전략가 관점**: 자율화 함정·HITL 최소 지점·ROI vs 리스크
- **Gemini**: 503 불가 (고수요)

---

## 아키텍처 제안: 3-Layer 파이프라인

```
[Layer 1: Discovery]
  Notion 백로그 DB + Linear 미할당 이슈 → 스캔 에이전트(CronCreate, 1일 1회)
       ↓ 중복 체크 (소스ID → Linear ID 매핑)
  → Linear 티켓 자동 생성 (status: PENDING)

[Layer 2: Spec Gate] ← 유일한 HITL 지점
  PENDING 티켓 → Raphael이 Slack 브리핑 ("이 티켓을 이렇게 해석, 범위 이렇게 잡겠음")
  사용자 승인(이모지/버튼) → status: APPROVED
  미응답 48h → status: ON_HOLD (자동 보류)

[Layer 3: Execution]
  APPROVED 티켓 → Asurada-role 에이전트
    → worktree 생성 (agent/<HAN-XX>)
    → /spec → /implement → PR 생성
    → status: PR_CREATED
    → Slack 결과 보고
```

---

## 옵션 비교

### Option A: 완전 자율 (게이트 없음)

**장점**
- 사용자 개입 0 — 정말 백그라운드로 동작
- 빠른 처리량

**단점**
- Goal Proxy 문제: 에이전트는 "PR 머지"를 목표로 최적화, "사용자가 원한 것"이 아님
- 방향 오류가 누적되어 뒤늦게 발견 → 수정 비용 폭발
- 잘못된 티켓 자동 생성 → 백로그 오염

**트레이드오프**
- 속도 최대 vs 방향 신뢰도 최소

---

### Option B: 스펙 승인 1회 체크포인트 (권장)

**장점**
- 방향 오류의 90% 차단: 코드 작성 전 한 번만 확인
- PR 리뷰보다 훨씬 앞단 → 수정 비용 최소
- 나머지 단계는 완전 자율 → 실질적 레버리지 유지

**단점**
- 사용자가 Slack 알림에 응답해야 함 (1 티켓당 1 응답)
- 미응답 시 파이프라인 정체 가능

**트레이드오프**
- 약간의 개입 비용 vs 감사 공백 방지 + 방향 신뢰도

---

### Option C: 단계별 다중 게이트

**장점**
- 리스크 최소화

**단점**
- 자율화의 의미가 없어짐 — 현재와 큰 차이 없음
- 승인 피로 (approval fatigue) → 게이트가 형식화

**트레이드오프**
- 안전 최대 vs 레버리지 최소

---

## 권장안

**선택: Option B (스펙 승인 1회 체크포인트)**

근거:
- Layer 1(Discovery)·Layer 3(Execution)는 완전 자율화 가능한 영역
- 코드 작성 전 스펙 확인 한 번이 PR 리뷰 여러 번보다 비용 대비 효과 압도적
- 미응답 48h 자동 보류로 파이프라인 정체 방지 가능

---

## 인프라 전제 조건 (선행 필수)

1. **멱등성 저장소**: `소스ID → Linear ID` 매핑. 파일 또는 Notion DB. 없으면 중복 티켓 폭발
2. **격리된 git 환경**: worktree 루트 고정 (`~/Workspace/pantheon/worktrees/`), 브랜치 `agent/<HAN-XX>`, 클린업 훅
3. **MCP 쓰기 권한 범위 확정**: Linear/Notion/GitHub write scope 명시 + 범위 초과 방지 토큰 분리
4. **에러 알림 채널**: 파이프라인 실패 시 Slack 도달 보장 (루프가 죽으면 무소식이 독)

---

## 상태 기계 (Linear 티켓 기반)

```
PENDING → [Spec Gate 승인] → APPROVED → [에이전트 픽업] → IMPLEMENTING
        → [Spec Gate 48h 미응답] → ON_HOLD
IMPLEMENTING → [성공] → PR_CREATED → [머지] → DONE
            → [3회 실패] → FAILED (Slack 에스컬레이션)
```

Linear 티켓 status = source of truth. 별도 외부 DB 불필요.
실패 기록 → 티켓 댓글에 append (Slack은 요약만).

---

## 맹점 · 반증 가능성

1. **"백로그 소스 품질" 전제 위험**: Notion 백로그 항목이 "개선 필요" 수준이면 에이전트가 추측으로 채운다. Discovery Layer 실효성이 백로그 작성 습관에 의존. → 백로그 입력 컨벤션 강제가 선행되어야 함
2. **"스펙 승인이 빠르다"는 가정 위험**: 사용자가 바쁘거나 관심 없을 때 ON_HOLD 쌓임 → 파이프라인 가동률 0. 미응답이 "암묵적 거절"이라면 자율화 의미 퇴색. → 일배치 승인(아침 한 번에 몰아서 Y/N) 패턴 고려 필요

---

## 구현 순서 권장

1. `HAN-50` (MCP 직접 실행) 먼저 완료 — 실행 레이어 기반 필요
2. Layer 1 (Discovery) 단독 구현 및 검증 — 중복 체크 포함
3. Spec Gate (Slack 브리핑 + 응답 처리) 구현
4. Layer 3 (Execution) 연결

---

## 참고

- HAN-53: proactive advisor loop (완료)
- HAN-50: MCP 직접 실행 (선행 후보)
- [구현자 관점 자문]: 멱등성·워크트리·상태 기계 설계
- [제품 전략가 관점 자문]: Goal Proxy 문제, 감사 공백, HITL 최소화