자율 세션 워크플로우은(는) 무엇을 하나요?
자율 에이전트 세션을 위한 5단계 반복 구조로, 중복 작업을 방지하고, 내구성 있는 학습 캡처를 보장하며, 출력 편향을 단순한 움직임이 아닌 의미 있는 출하 아티팩트로 유도합니다.
gptme 아키텍처의 수천 개 자율 세션에서 전투 테스트를 거쳤습니다. 단계는 런타임에 구애받지 않습니다 — 스택에 맞게 특정 도구를 조정하면서 단계 구조는 유지하십시오.
사용 시기
- 모든 자율 에이전트 세션 시작 시 (실시간으로 작업을 지시하는 사람이 없는 경우)
- 에이전트가 백로그나 큐에서 스스로 작업을 선택해야 할 때
- 세션이 무인으로 실행되고 내구성 있는 아티팩트를 생성해야 할 때
사용하지 말아야 할 시기
- 사람이 매 턴 다음 프롬프트를 제공하는 대화형 세션 — 그냥 응답하면 됩니다
- 고정된 대상이 있는 일회성 도구 호출 (선택 필요 없음)
- 상위 태스크에서 생성된 하위 에이전트 호출 (상위 태스크가 이미 작업을 선택함)
5단계
1단계: 컨텍스트 로드
에이전트의 정체성, 세션 상태, 현재 세계 모델을 로드합니다.
# 신원 파일 읽기 — 페르소나, 목표, 운영 제약 조건
# (스택에 맞게 조정: CLAUDE.md, AGENTS.md, 시스템 프롬프트 등)
# 동적 컨텍스트 읽기 — 최근 저널, 작업 큐, git 상태, 알림
# (조정: 컨텍스트 스크립트, 구성 기반 포함, 또는 프롬프트 인젝션)
# 이전 세션의 미해결 사항 평가:
# - 완료하거나 포기해야 하는 오래된 클레임
# - 닫기로 약속했지만 아직 처리되지 않은 이슈/PR 답변
# - 진행 중인 브랜치 또는 열린 작업 트리
핵심 질문: "내가 미완성으로 남긴 것은 무엇이며, 내가 오프라인인 동안 무엇이 변경되었는가?"
미해결 사항을 5분 이내에 해결할 수 있다면 여기서 처리하십시오. 그렇지 않으면 기록하고 진행합니다.
2단계: 작업 선택
실행 가능한 작업을 찾을 때까지 계층을 순서대로 시도합니다. 계층은 실제 작업이 존재할 때 에이전트가 바쁜 척하는 작업을 만들어내는 것을 방지하고, 모든 작업이 차단되었을 때 기아 상태를 방지합니다.
계층 1 — 활성 작업: 이미 진행 중인 작업; 최우선 순위
계층 2 — 백로그 빠른 성과: 이 세션에서 완료할 수 있는 의존성 준비된 항목
계층 3 — 자기 개선: 모든 작업이 외부적으로 차단된 경우
├─ 아이디어 백로그 (가장 높은 점수의 아이디어 진행)
├─ 자체 검토 / 감사 (실제 문제 찾아서 수정)
├─ 내부 도구 개선
├─ 문서 (오래된 문서만)
├─ 코드 품질 (타입체크, 테스트, 린트)
└─ 학습 품질 (유해하거나 오래된 학습 복구)
단조로움 방지 장치: 동일한 범주가 최근 N개 세션을 지배했다면, 가장 좋은 선택처럼 보여도 건너뛰십시오. 범주 다양성은 새로운 실패 모드를 학습하기 위한 강제 함수입니다.
모든 것이 고갈되었을 때: 모든 계층 1/2 작업이 외부적으로 차단되고 계층 3 레인이 포화 상태(일일 한도 도달)이면, 확인하고 의도적으로 건너뛴 내용을 기록하는 간결한 제한 저널을 작성하십시오. 정당한 NOOP는 작업을 조작하는 것보다 낫습니다.
3단계: 클레임
실행 전에 배타적 조정 클레임을 획득합니다. 이는 두 개의 동시 세션이 동일한 작업을 실행하거나, 동일한 PR 스레드를 넘치게 하거나, 동일한 파일을 작성하는 것을 방지합니다.
# 일반 조정 패턴 — 스택에 맞게 도구 조정:
claim_key="task:<task-id>" # 작업 기반 작업
claim_key="github:<owner>/<repo>#<num>" # 이슈 기반 작업
claim_key="content:<slug>:<date>" # 콘텐츠/아티팩트 생성
# 클레임 획득 (조정 CLI 사용 예시):
coordination work-claim "<session-id>" "$claim_key" --ttl 60
# CLAIMED → 진행
# DENIED → 다른 세션이 이미 작업 중; 다음 후보 선택
클레임 전 알림 규칙: 다른 사람에게 보이는 모든 작업(댓글 게시, 메시지 전송, PR 열기)은 먼저 클레임으로 게이트되어야 합니다. 클레임 없는 소셜 작업은 수렴되어 스팸을 발생시킵니다 — 클레임 후 게시 패턴이 범람을 방지합니다.
완료 시: coordination work-complete "<session-id>" "$claim_key"
피벗/실패 시: coordination work-abandon "<session-id>" "$claim_key"
4단계: 실행
실제 작업을 수행합니다. 핵심 규율은 완벽함보다 출하입니다.
- 자주 커밋 (작고 잘 설명된 커밋)
- 커밋 전에 테스트 실행 (CI가 발견하기 전에 문제 포착)
- 규칙적 커밋 사용: feat/fix/docs/refactor/chore
- 세션 종료 전에 원격 푸시
- 10분 이상 막히면 진행 — 토끼굴에 예산을 낭비하지 않음
- 요청되지 않은 기능이나 범위 확장을 추가하지 않음
50분 예산: 대부분의 자율 세션은 50분 이내에 의미 있는 작업을 완료해야 합니다. 작업이 더 크면 증분 조각을 출하하고 나머지에 대한 후속 작업을 생성하십시오.
5단계: 지속화
가장 과소평가된 단계입니다. 1~4단계에서 수행된 모든 것은 내구성 있게 커밋되지 않으면 세션 사이에 사라집니다.
# 1. 저널 항목 작성 (세션별 파일, 추가 전용)
cat > journal/$(date +%Y-%m-%d)/session-<HASH>.md << 'EOF'
# 세션 <HASH>
**날짜**: YYYY-MM-DD
**결과**: productive|blocked|noop — 한 문장
**범주**: code|research|strategic|maintenance|...
## 이 작업을 수행한 이유
[여기에 도달하게 된 경로]
## 수행한 작업
[커밋/PR 링크가 포함된 구체적 변경 사항]
## 검증
- [테스트 통과? CI 초록색?]
## 지속화된 학습
- 작업 상태: <task> → done/waiting
- 새로운 학습: [있는 경우]
- "이 세션에서는 내구성 있는 피드백 없음" — 진정으로 추가할 내용이 없는 경우
## 다음 단계
[명확한 다음 조치 또는 차단 요소]
EOF
# 2. 작업 상태 업데이트
task edit <task-id> --set state done # 또는 차단된 경우 waiting
# 3. 반복되는 실패 패턴이 발견되면 학습/규칙 작성
# (다음 세션 시작 시 주입되는 키워드 일치 컨텍스트 파일)
# 4. 모든 커밋 푸시
git push origin master
지속화 우선 규칙: 유용한 것을 발견했다면 현재 작업에 적용하기 전에 학습을 먼저 작성하십시오. 수정이 완료되면 실패 모드가 해결된 것처럼 느껴져 학습이 건너뛰어집니다. 저널은 발생한 일을 기록하고, 학습은 언제 다시 인식해야 하는지를 기록합니다.
설치
Claude Code
이 스킬 디렉토리를 에이전트의 스킬 폴더에 복사하십시오:
cp -R skills/autonomous-session-workflow ~/.claude/skills/autonomous-session-workflow
그런 다음 /autonomous-session-workflow로 호출하여 5단계 체크리스트를 컨텍스트에 로드합니다.
수동 / 모든 런타임
SKILL.md를 에이전트의 컨텍스트 경로에 복사하고 세션 시작 시 로드하십시오. 단계는 일반 마크다운입니다 — 전체 파일을 포함하거나 스택과 관련된 섹션만 골라서 포함하십시오.
일반적인 합리화
| 합리화 | 현실 |
|---|---|
| "지금 나만 세션을 실행 중이니 클레임을 건너뛰겠다" | 다른 세션이 시작되는 것을 볼 수 없습니다. 동시 생성은 프로덕션 런타임의 기본값입니다. 클레임은 관찰이 아닌 게이트입니다. |
| "다음 작업을 끝낸 후 저널을 작성하겠다" | 세션은 중단될 수 있습니다. 저널은 건너뛰어집니다. "한 가지만 더" 하기 전에, 푸시하기 전에 작성하십시오. |
| "이 작업은 거의 끝났으니 5단계를 건너뛰고 그냥 커밋하겠다" | 학습은 지속화되어야만 축적됩니다. 루프를 "거의" 닫은 세션의 통찰력은 다음 실행까지 사라집니다. |
| "내 선택은 명백하니 계층을 통해 작업할 필요가 없다" | 계층을 건너뛰는 선택은 중복 작업과 중복 PR의 주요 원인입니다. "명백한" 것이 실제로 필요한 작업이 아닌 경우가 많기 때문에 계층이 존재합니다. |
| "학습이 너무 구체적이어서 재사용할 수 없다" | 구체적인 학습(정확한 오류 메시지, 정확한 명령어, 정확한 실패 모드)이 가장 가치 있습니다 — 필요할 때 정확하게 트리거됩니다. |
| "정당한 NOOP는 실패처럼 느껴진다" | 그렇지 않습니다. NOOP 레이블을 피하기 위한 채우기 커밋은 할당량을 소모하고, 수렴 잡음을 유발하며, 정체를 숨깁니다. 제한 저널이 바로 전달물입니다. |
위험 신호
- 클레임 전에 실행 시작 (수렴 위험)
- 저널 및 업데이트된 작업 상태 없이 세션 종료
- "잠시 후" 커밋 — 종료 전에 푸시하지 않았다면 출하하지 않은 것입니다
- 강제 다양성 휴식 없이 동일한 범주에서 3회 연속 세션
- "기억하겠다" — 기억하지 못합니다; 지금 학습을 작성하십시오
검증
잘 실행된 세션은 종료 전에 다음 모든 사항을 충족합니다:
- 실행 전에 클레임 획득 (또는 클레임이 필요 없는 이유 설명)
- 의미 있는 작업 커밋 및 푸시
- 테스트 통과 (또는 알려진 실패를 이유와 함께 문서화)
-
지속화된 학습섹션이 채워진 저널 항목 작성 - 작업 상태 업데이트 (
active → done,active → waiting등) - 클레임 완료 또는 포기 (유효하지 않은 임대 남기지 않음)
스택에 적용하기
| gptme 개념 | 여러분의 동등 개념 |
|---|---|
gptodo | 상태 전환이 있는 모든 작업 관리자 |
coordination work-claim | 잠금 파일, Redis SETNX 또는 GitHub 댓글 게이트 |
lessons/<category>/name.md | 세션 시작 시 주입되는 키워드 일치 컨텍스트 파일 |
journal/<date>/session-<hash>.md | 모든 추가 전용 세션 로그 |
cascade-selector.py | 작업 선택 휴리스틱 또는 스케줄러 |
패턴이 가치이지, 특정 도구가 아닙니다.
관련
self-push(이 카탈로그 내) — 모든 출력을 출하하기 전에 게으른 확인pre-landing-review(이 카탈로그 내) — 중요한 변경 사항 병합 전 게이트multi-lens-review(이 카탈로그 내) — 여러 렌즈를 통한 구조화된 PR 검토five-element-spec(이 카탈로그 내) — 작업 시작 전 범위 정의