잠자는 동안에도 일하는 개발 조직 — Gucci Harness
발표자 테디노트 · 프로젝트 Gucci Harness · 분량 슬라이드 50쪽 / 6개 파트 출처 패스트캠퍼스 (2026년 05월) 발표 — 2026-06-01-teddynote-gucci-harness-presentation 원본 캡처
한눈에 보는 요약
이 발표의 한 줄은 “도구가 아니라, 일하는 방식을 바꾼다” 입니다. 사람이 프롬프트를 하나하나 치는 동기형(Interactive) 코딩에서, 트리거·스케줄로 사람 없이 굴러가는 비동기형(Background) 자율 시스템으로의 전환을 다룹니다.
핵심 구조는 세 가지로 압축됩니다. 첫째, 자율 에이전트 프레임워크 hermes-agent는 “엔진”이자 디스패처일 뿐이고, 추론·구현 알고리즘은 여전히 에이전트 harness에 있습니다. 둘째, 사람의 결정이 필요한 순간은 GitHub의 ADR / Human Review로 표면화해 보정된 자율성(Calibrated Autonomy) 을 만듭니다. 셋째, 발표자가 만든 Gucci Harness는 그 위에서 GitHub 운영을 자율화하는, PM 오케스트레이터 + 6개 워커 + SoT(Source-of-Truth) 계약 시스템입니다.
Part 1 · 왜 지금 자율형 에이전트인가
코딩 도구의 진화, 세 단계
“옆에서 돕는 도구”에서 “스스로 일하는 작업자”로의 전환이 핵심입니다. ① 자동완성(Copilot — 코드 라인 단위 보조) → ② 페어 프로그래밍(채팅·IDE — 대화로 문제 해결) → ③ 자율 에이전트 팀(목표만 주면 알아서).
2026년, 숫자로 보는 현실
| 지표 | 값 | 비고 |
|---|---|---|
| 기업 앱의 AI 에이전트 탑재 | 80% | 2024년 33% → 2026 Q1 |
| 엔터프라이즈 코딩 에이전트 시장 | $9.8–11B | 연환산, 2026년 4월 추정 |
| Zapier 전사 AI 도입률 | 97% | 2026년 1월 기준 |
출처: Anthropic 2026 Agentic Coding Trends Report, 시장 추정치(업계 보도 기준).
위임 격차 (Delegation Gap)
쓰긴 쓰는데, 맡기진 못합니다. 개발자는 업무의 약 60% 에 AI를 사용하지만, 완전히 위임 가능한 일은 0–20% 에 불과합니다. 이 격차의 정체는 능력이 아니라 신뢰·구조의 문제이며, 이를 메우는 것이 자율형 시스템의 과제이자 본 발표의 출발점입니다.
동기형에서 비동기형으로
| 구분 | 동기형 · Interactive | 비동기형 · Background |
|---|---|---|
| 방식 | 내가 앉아서 프롬프트 → 결과 확인 | 트리거·스케줄로 사람 없이 실행 |
| 사람 | 매 단계 호출·감독 | 결과만 받아본다 |
| 처리량 | 사람의 시간 | 시스템의 가동 |
| 대표 도구 | Claude Code | hermes-agent 류 |
“당신이 보지 않는 동안, 에이전트가 일한다.”
계층 구조 — 경쟁이 아니라 계층
자율형 에이전트(오케스트레이션 계층)와 에이전트 harness(실행 계층)는 경쟁 관계가 아니라 계층이 다릅니다. 오케스트레이터(Hermes)가 일감을 자율 분배하고, 하네스가 추론·코드를 구현하며, 그 아래 모델(LLM)이 원천 지능을 제공합니다. 자율형이 푸는 문제는 24/7 가동 · 병렬 처리 · 부재 내성(트리거·재시도·하트비트)입니다.
자율 SWE는 이미 현장에 있다
Devin · Cognition 은 Goldman Sachs “하이브리드 인력” 파일럿에서 PR 머지율을 34% → 67%로 끌어올렸습니다. Factory · Droids 는 $1.5B(Series C) 기업가치에 Terminal-Bench 상위권, MongoDB·EY·Morgan Stanley·Nvidia가 도입했습니다. 시사점은 — “자율 코딩”은 실험이 아니라 도입 경쟁 단계라는 것입니다.
Part 2 · Hermes Agent란 무엇인가
hermes-agent는 Nous Research가 만든 오픈소스 자율 에이전트 프레임워크입니다(MIT 라이선스 · 2026년 2월 출시). IDE에 묶인 코파일럿도, API 챗봇 래퍼도 아닙니다.
한 줄 정의 — 서버에 상주하며, 배운 것을 기억하고, 돌릴수록 더 유능해지는 에이전트.
출시 2개월 만에 GitHub 10만+ 스타(중순 약 14만), Codex 백엔드로 월 $20에 프런티어급 운용, agentskills.io 호환 개방 표준, 모델을 직접 만드는 연구소의 신뢰가 빠른 주목의 배경입니다.
7가지 핵심 기능
| # | 기능 | 요지 |
|---|---|---|
| ① | 닫힌 학습 루프 + 메모리 | 세션 시작 시 user.md/memory.md 로드, FTS5 교차 세션 회상 + LLM 요약. “빈 상태로 깨어나지 않는다.” |
| ② | Skills (절차적 기억) | 어려운 작업 후 SKILL.md 자동 생성. 기본 85개 + 커뮤니티 520여 개. 사용 중 스스로 개선 → “경쟁력은 스킬에 있다.” |
| ③ | Soul (개성·일관성) | soul.md로 세션을 넘나드는 일관된 페르소나·말투. “우리 팀처럼” 일하게. |
| ④ | Cron (스케줄 자동화) | 자연어 “매일 06시 X” → 격리 세션 실행 후 Telegram 보고. cron이 또 cron을 못 만든다(자기증식 방지). |
| ⑤ | 멀티플랫폼 게이트웨이 | Telegram·Discord·Slack·WhatsApp·Signal·Email·SMS 등 20+ 플랫폼. 주머니 속에서 지휘. |
| ⑥ | 어디서나 실행되는 런타임 | 6개 백엔드(local·Docker·SSH·Daytona·Singularity·Modal). 서버리스 유휴 시 거의 0원, hibernate. |
| ⑦ | 위임·병렬 + 멀티에이전트 Kanban | 격리 서브에이전트 spawn 병렬, execute_code, 내구성 Kanban, mcp로 외부 도구 확장. |
Hermes vs Claude Code vs OpenClaw
| 구분 | Claude Code | Hermes Agent | openclaw |
|---|---|---|---|
| 성격 | 책상 위 동기형 드라이버 | 자율 백그라운드 워커 | 커뮤니티형 백그라운드 |
| 실행 위치 | 내 터미널·IDE | VPS·서버리스·어디서든 | VPS·서버 |
| 스케줄 | 제한적(수동 호출) | 자연어 Cron 내장 | Cron 지원 |
| 메모리 | 프로젝트 범위 | 교차 세션 개인 메모리 | 세션 메모리 |
| 생태계 | Anthropic 공식 | 스타 14만+ · 빠른 성장 | 스타 35만+ · 최대 규모 |
| 안정성 | 안정적 | 가볍고 안정적 | 빠른 업데이트 · 변동성 |
결론 경쟁이 아니라 보완 — “책상엔 Claude Code, 백그라운드엔 Hermes”. 공유 GitHub 레포가 셋을 묶는다.
Part 3 · 우리가 정의한 자율형 코딩
우리의 정의
사람이 프롬프트를 하나하나 치는 단계가 완전히 빠진 시스템.
에이전트가 스스로 탐색(무엇을 해야 할지 백로그에서 찾기)하고 스스로 구현(찾은 일을 직접 수행·검증)합니다. 기존 방식의 한계는 사람이 루프 안의 병목이라는 점 — 손가락 속도, 근무 시간, 컨텍스트 전환 비용이 처리량을 묶습니다.
Before → After
- Before (사람이 모든 단계에 개입): 할 일 식별·프롬프트 작성·검토·다음 작업 모두 사람.
- After (사람은 목표·제약만): 목표·제약 정의만 사람, 탐색·구현·검토·비평·조치는 에이전트.
사람의 결정이 필요한 순간 — HITL
완전 자율 ≠ 무인 방치입니다. 되돌릴 수 없거나·위험하거나·모호한 결정은 사람에게 넘깁니다. 패턴은 보정된 자율성(Calibrated Autonomy) + 승인 게이트(Approval Gate) 입니다.
결정 지점은 GitHub의 ADR / Human Review 로 표면화합니다. 상태는 보존되고(state-managed interruption), 사람은 결정에만 개입합니다. GitHub에 두는 이유는 추적성(PR·Issue·Label), 책임 분리(Separation of duties), 공동 SoT(사람·에이전트가 같은 Source of Truth에서 협업)입니다.
핵심 통찰 — Hermes는 “디스패처”다
Hermes가 하는 일은 자율적으로 일감을 분배(dispatch) 하는 것입니다. 궁극의 추론·구현 알고리즘은 여전히 에이전트 harness(Claude Code · codex · OpenCode)에 있습니다. 따라서 우리의 경쟁력은 디스패처가 아닙니다.
“엔진은 공용(Hermes), 레이스카는 우리 것(스킬·SoT).” — 우리의 해자(moat)는 시스템 위에서 돌아가는 스킬·규약(SoT).
Part 4 · Gucci Harness 아키텍처
Gucci Harness 는 Hermes 위에서 GitHub 운영을 자율화하는 시스템입니다. 산출물은 Hermes용 GitHub 운영 스킬 세트 + 그 SoT 계약 + 정적 역할 스킬(install·update·project-setup·cronjob) + Jinja2 스킬 생성기 + 프로젝트 프로파일입니다.
단일 오케스트레이터 + 6개 독립 워커
cron 트리거가 project-manager(유일한 디스패처)를 깨우고, PM은 한 tick에 한 결정만 내려 최대 1개 워커를 디스패치합니다. 핵심 규칙은 워커는 서로를 호출하지 않고, PM만 선택한다는 것입니다.
| 역할 | 책임 |
|---|---|
| project-manager | 오케스트레이터 — 디스패치 결정 |
| issue-finder | 처리할 이슈를 탐색·선별 |
| issue-to-pr | 이슈를 받아 PR로 구현 |
| code-reviewer | 변경을 리뷰·승인 |
| code-critic | 비판적 점검·리스크 식별 |
| github-actioner | 머지·라벨·클로즈 등 조치 |
| document-writer | 문서·기록 작성 |
각 역할 = 하나의 책임 = 하나의 스킬(계약).
한 tick, 한 결정 + /background 논블로킹 디스패치
PM의 판단 흐름은 ① GitHub 스냅샷 수집 → ② dispatch_priority 규칙 평가 → ③ 최대 1개 워커 디스패치(or no-op)입니다. PM이 워커를 tool로 직접 호출하면 다음 cron tick을 막기 때문에, 리포트의 마지막 줄에 /background 한 줄만 출력해 Hermes가 격리 워커 세션을 spawn하게 합니다.
/background Run the gucci-harness:<worker> skill
for project=<slug> (target=<target>,
reason=<reason>) using the <worker_cli> worker CLI.
참고: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/yuanbao#background-tasks
상태 관리와 안전장치
| 파일 | 역할 |
|---|---|
pm-decisions.db | 프로젝트당 SQLite(WAL) 1개. tick마다 dispatch / no-dispatch 결정 기록. |
last-tick.json | 머지된 PR 커서 + 마지막 tick 시각 보존 → 중복 처리 방지. |
| rate limit 내성 | GitHub 429 발생 시 디스패치 없이 no-dispatch 기록 → 안전하게 다음 tick으로. |
GitHub 계약 · 생성기 · 운영
상태 라벨은 br:triage / br:in-progress / br:needs-adr / br:blocked, 우선순위는 P0–P3입니다. 코멘트는 사람이 읽는 한국어로 쓰고, 기계가 읽는 값은 footer의 br_label·reason만 둡니다. 스킬은 profile.yaml → Jinja2 generator(2단계 dry-run → apply, 해시·TTL 검증) → 레포별 Hermes 스킬(~/.hermes/)로 렌더되며, 모두 docs/sot/ 계약을 따릅니다(토큰은 redact_token_text로 스크럽). 운영은 설치 → gh 인증 → smoke check → 24/7 cron 순으로, 한 번 설치하면 반복 작업이 백그라운드 cron으로 상시 가동됩니다.
Part 5 · 의미와 가치
24 / 7 / 365 — 사람의 근무시간이 더 이상 처리량의 상한이 아니게 됩니다. 야간·주말에도 백로그가 줄어들고, 출근하면 PR이 와 있습니다.
경쟁력의 위치를 다시 못 박자면, 디스패칭(Hermes)은 누구나 설치해 쓰는 범용재이고, 해자는 스킬·SoT·역할 설계 — 우리 회사의 업무 지식이 코드화된 자산입니다.
벤치마크 잠재 효과(참고치)는 마이그레이션 시간 10x, 보안 수정 속도 20x, PR 머지율 2x(TELUS: 13,000 솔루션, 출시 30% 단축, 50만 시간 절감) — 다만 벤더·외부 보고 기준이므로 우리 환경에서는 자체 검증이 필요합니다.
| 리스크 | 완화 장치 |
|---|---|
| 환각 · 잘못된 도구 호출 | 승인 게이트로 부작용 전에 차단 |
| 비가역적 변경 | ADR · Human Review 필수 게이트 |
| 토큰 · 시크릿 노출 | 환경변수 only · redact_token_text 스크럽 |
| 워커 폭주 · 충돌 | 워커 격리 · 한 tick 한 결정 · 최소 권한 |
위임 격차(0–20%)를 넘으려면 자율성을 신뢰할 수 있는 구조가 먼저입니다. ADR·Human Review, 상태·우선순위 라벨, 결정 로그(DB)가 곧 “신뢰를 만드는 인프라”입니다.
Part 6 · 미래 업무 방식 & 레슨
단순 코딩·코드 검수·반복 운영 작업은 시스템으로 이동합니다. 사람에게 남는 것은 무엇을 만들지, 왜 만들지, 어떤 트레이드오프를 택할지 — 즉 의사결정입니다.
- 아키텍처 디시전 — 시스템의 경계·트레이드오프·장기 진화 방향. 되돌리기 비싼 선택, “무엇을 만들지 않을지”의 결정.
- UX / UI 기획 — 사용자 흐름·정보 구조 설계, 제품 감각이 필요한 판단.
- 비즈니스 로직 — 도메인 규칙·우선순위·가치 판단. 맥락을 아는 사람만 할 수 있는 일.
좋은 결정을 하려면 축적된 인사이트와 경험이 필요하다. 인재상은 실행자 → 판단자·설계자 로 전환된다.
핵심 요약 5
- 자율형은 동기형이 아니라 비동기 백그라운드다.
- Hermes는 디스패처, 알고리즘은 하네스(스킬)에 있다.
- 사람의 결정은 GitHub ADR / Human Review 로 표면화한다.
- Gucci Harness = PM 오케스트레이터 + 6개 워커 + SoT 계약.
- 사람에겐 의사결정이 남고, 그래서 인사이트가 자산이다.
“도구가 아니라, 일하는 방식을 바꾼다.” — 테디노트
실전 보충 — 라이브 데모 & Q&A
슬라이드 발표에 이어진 라이브 데모·질의응답에서 나온 실전 팁입니다. 슬라이드가 “무엇을·왜”라면, 이 절은 “실제로 어떻게 굴리는가”에 대한 보충입니다. (출처: 2026-06-01-teddynote-gucci-harness-live-qa)
보이스 코딩으로 SoT를 빠르게 “털어낸다”
SoT(Source of Truth) 문서를 만들 때 타이핑 대신 음성 입력을 씁니다. 단축키를 걸어 터미널에 바로 받아쓰기하면, 손가락 타이핑보다 훨씬 빠르게 많은 컨텍스트를 쏟아낼 수 있습니다. 발표자는 Whisper Notes / WhisperFlow 에 로컬 모델 Whisper Large V3 Turbo 를 얹어 사용합니다(무료로도 가능, 유료도 약 $7 평생 라이선스 · 맥 기준, 윈도우 미지원). “프로젝트 목적·아키텍처·DB 스키마·유저 시나리오·코딩 룰·API 스펙을 다 담아주고, hermes-agent로 구현할 거니까 API 뽑아줘”처럼 구두로 빠르게 지시해도 정확도가 높습니다.
SoT를 “깎는” 것이 진짜 일
크론 명령은 범위를 좁히는 방향으로 진화합니다. “결함을 찾아줘”는 범위가 너무 넓습니다. 대신 — “SOT 문서를 먼저 확인한 뒤, SOT에 어긋나거나·미구현이거나·잘못 구현된 내용을 찾아 5분마다 픽스하고 보고서를 남겨줘” 로 지시하면 범위가 급격히 좁아집니다. 내 의도와 방향성을 SoT에 모두 담았기 때문입니다.
그래서 실제 리팩토링 프로젝트에서는 한 달 중 25일을 마크다운(스펙) 깎기에 쓰고 손코딩은 거의 하지 않았다고 합니다. 실행(execution)은 금방 되니, 사람은 SoT를 계속 다듬습니다. 유저 시나리오는 절대 완벽하지 않으므로 — “내가 생각 못 한 엣지케이스(예: 동시 요청)를 노출해봐” → 좋은 것을 골라 업데이트 — 를 반복합니다. 지루하지만, 잘 깎아두면 실행은 자동으로 따라옵니다. 비개발자는 코드를 직접 못 고치니 문서(SoT)를 더 탄탄히 만드는 데 집중하는 것이 핵심입니다.
로그 vs ADR — 무엇을 남기나
런타임·디버그 로그는 문제가 해결되면 쓸모가 없어지므로 굳이 저장하지 않습니다(터미널 출력으로 충분). 대신 해결된 결정만 ADR(Architecture Decision Record) 로 마크다운에 남깁니다. 대략 “코드 변경 1건 + 문서 1건” 꼴입니다. 실제 운영 중인 DA-Agent(Bedo) 플랫폼에서는 문서가 112개에 이르고, 에이전트가 계속 갱신하며 “현재 반영 범위 / 최근 병합된 PR”을 정리합니다. 사람이 모든 히스토리를 추적할 수 없으므로 위키 형태로 쌓아 에이전트가 참조하게 만듭니다.
SoT ≠ 위키 (LLM Wiki / Karpathy)
이 둘은 반드시 구분해야 합니다.
| 구분 | SoT (Source of Truth) | 위키 (Wiki) |
|---|---|---|
| 성격 | 코어 · “진실” | 기록 · “메모리” |
| 내용 | DB 스키마, 스펙 시트, 방향성 | 작업 일지, 레슨, 변경 히스토리 |
| 질문 | 무엇이 맞는가(현재 상태) | 어떻게 여기까지 왔는가(이력) |
위키는 Andrej Karpathy의 LLM Wiki 패턴을 따릅니다(검색 추천). LLM이 자기가 한 일을 폴더 구조 + 마크다운으로 작성·저장하는 체계이며, 폴더 구조는 회사·개인마다 프롬프팅으로 정합니다. 공개본 기반의 오픈소스도 다수 존재합니다. 발표자는 위키 업데이트와 SoT 업데이트를 별개의 동작으로 구분해 운영합니다. (이 노트가 들어 있는 볼트 자체가 그 LLM Wiki 패턴의 예입니다.)
위키 업데이트 규칙 (스킬로 만든다)
무조건 기록하는 게 아니라 룰이 있는 스킬로 만듭니다. 버그픽스는 위키에 안 남깁니다(레슨이 아니라 내 실수일 뿐). 반면 방향성 변경은 남깁니다. 예를 들어 “소셜 로그인 없음”으로 정했다가 나중에 “소셜 로그인 추가”로 바꾸면, ① SoT 문서를 먼저 업데이트하고 ② 위키에 변경 히스토리를 기록합니다.
왜 이력을 남길까요? SoT는 현재 상태(“소셜 로그인 있음”)만 보여줄 뿐, “원래 없다가 생겼다”는 변화는 보여주지 않습니다. 위키에 “최근 소셜 로그인이 추가됨”이라는 히스토리가 있으면, 5분마다 도는 에이전트가 그 변경에서 발생할 수 있는 미반영·잔재 코드·오류를 찾아낼 수 있습니다. 즉 위키는 hermes-agent의 교차 세션 메모리처럼 작동합니다. 팀 공통 개발 문서로 쓸 때도 최신 버전뿐 아니라 버전 이력(어떤 경로로 왔는지)을 관리하는 것이 더 중요합니다.
GitHub 라벨 상태 머신 (핵심 기법)
이걸 아무리 해도 “마음처럼 동작하지 않는” 이유는 작업에 순서가 있기 때문입니다(이슈 찾기 → 코드 구현 → 리뷰 → 크리틱 → 클로즈/문서). 6개 워커를 5분마다 병렬로 돌리려면, 지금 무엇을 할 차례인지를 시스템이 알아야 합니다. 해법은 GitHub 라벨입니다. 각 워커는 자기 라벨이 달렸을 때만 발동하고, 끝나면 다음 워커용 라벨로 전환합니다. GitHub를 이슈·상태 관리 시스템으로 쓰는 셈입니다.
워커들은 코멘트로 서로 “대화”하며(코멘트가 매우 많음), 원스텝 프롬프트로 한 번에 끝내는 게 아니라 5분마다 코멘트 하나씩 누적하며 처리합니다. 이미 머지·해결된 이슈는 중복 처리를 자동으로 스킵합니다. 라벨 자동화 설정은 별도 코드 없이 — Hermes에게 “이슈 만들 때 라벨을 달고, 리뷰가 필요하면 need-review, 크리틱이 필요하면 need-critic을 달아줘”라고 영어로 일러주면 끝입니다.
숙제로 권하는 스킬 3개 (각각 ① 발동 라벨 조건 ② 설정할 라벨 ③ 하는 일을 프롬프트/스킬로 정의):
| 스킬 | 발동 조건 | 하는 일 | 다음 라벨 |
|---|---|---|---|
| issue-finder | 라벨 없음(신규) | SoT 기준 이슈 탐색 | need-execution |
| code-execution | need-execution | 이슈를 코드로 구현 | need-review |
| code-reviewer | need-review | 구현 코드 리뷰 | need-human (권장) |
Gucci Harness에서는 이 라벨 값들을 정리하고,
request(사람 요청)와ADR(사람 리뷰 필요) 라벨을 둡니다. 사람은 ADR에 의견만 남기고 라벨을need-review로 바꾸면 끝 — 이슈에 ADR이 쌓이면 사람이 결정해주고 다시 자동으로 돕니다.
worktree로 병렬 작업 (브랜치 금지)
같은 터미널에서 브랜치 전환은 위험합니다. 한 터미널에서 브랜치를 바꾸면 같은 레포로 병렬 실행 중인 다른 터미널의 메인 작업이 의도치 않게 휩쓸려 날아갈 수 있습니다. 대신 git worktree 를 쓰면 동시성 문제가 한 번에 해결됩니다(“워크트리로 병렬 작업해줘” 한 줄). 공통 코드 충돌은 git 컨플릭트 해결로 처리합니다. 참고로 hermes-agent의 코딩 세션은 누적이 아니라 매번 새로 켜지며(조절 가능), 작업 완료 시간은 1분~10분 등 작업마다 다릅니다.
모델·도구 선택
발표자는 codex에 OpenCode 를 물려 씁니다. 이유는 동적 멀티모델 — -m 옵션으로 간단한 태스크는 GLM 5.1, 복잡한 태스크는 GPT-5.5 에 위임할 수 있기 때문입니다(코덱스 단독은 GLM을 못 씀). oh-my-opencode/oh-my-agent를 쓰면 프롬프트 끝에 ULW(울트라싱크)를 붙여 자동 적용할 수 있습니다. Claude Code는 구독으로 더 못 쓰게 되어, 선택지는 사실상 OpenCode와 Codex입니다(openclaw도 대안). 모델은 상향 평준화되어 Claude 4.8 ≈ GPT-5.5이며, 좁고 빠른 구현은 코덱스, 긴 컨텍스트는 Claude 4.8이 유리합니다. 비용 효율로는 GLM 5.1·Qwen Coder 3.7도 괜찮습니다.
문서 포맷은 — MD→HTML 변환은 토큰 낭비이니 압축이 목적이면 XML로 바로 저장하는 편이 낫고, MD는 사람이 검사하기 편하라고 쓰는 것입니다. 모델 effort는 max보다 medium을 권장합니다(컨텍스트 비대화로 오히려 성능이 떨어진다는 리포트 존재).
운영 디테일 (Q&A 요약)
- “결함 없음”은 거의 안 나옵니다(소프트웨어엔 대부분 결함 존재). 정말 없다면 거의 완성 단계입니다.
- 팀 공통 규칙과 부서 규칙이 충돌하면 오너(회사)가 먼저 해결해서 넣어야지, 에이전트에게 떠넘기면 안 됩니다.
- 5분이 너무 짧으면 간격을 늘리면 됩니다.
- 메모리(
memory.md)는 200라인 안쪽으로 유지하고 오염되지 않게 합니다(항상 로드되므로).
철학 — 의도(Intent)와 실행(Execution)
마지막 메시지는 커리어와 닿아 있습니다. 노정석 채널에 출연한 해시드 대표의 말(2026-05-30-hashed-kim-seojun-ai-execution-intention)을 인용해 — 앞으로는 의도와 실행만 남고, 그중 실행은 완전 자동화 가능 영역이라 결국 의도만 남는다고 봅니다. 대기업은 실행이 대부분이고 의도는 위에서 결정되지만, 스타트업은 개인이 의도만으로 프로젝트를 끌 수 있습니다(실행 코스트 ≈ 0).
그래서 실행을 잘하던 사람(과거의 높은 연봉)은 이제 AI와 경쟁해야 해 어려워집니다. 개발자도 코딩만이 아니라 비즈니스 로직·아키텍처 디시전을 낼 수 있어야 하고, 취준생도 “Claude Code보다 코딩을 잘하나”가 아니라 Claude Code를 잘 써서 내 의도를 실현하는 쪽으로 가야 합니다. 한편 실행력은 개인의 AI 인프라(하드웨어·토큰 가용성)에 비례하므로, 미래엔 “주 52시간”보다 “주 N억 토큰” 같은 제약이 더 의미를 가질 수도 있다는 농담 섞인 전망도 나왔습니다(다만 토큰을 많이 태우는 것 자체가 자랑은 아니며, 방법론 연구를 위한 것). 이는 슬라이드 Part 6 “사람에겐 의사결정이 남는다”와 정확히 맞닿습니다.
참고자료 (Sources)
- Hermes Agent 공식 문서 · GitHub (NousResearch)
- Anthropic 2026 Agentic Coding Trends Report
- Hermes vs Claude Code vs OpenClaw (MindStudio)
- Devin 2025 Performance Review (Cognition)
- Factory(Droids) 사례 (ZenML LLMOps DB)
- awesome-hermes-agent · HITL Approval Gate 패턴
- Gucci Harness 내부 문서 (docs/sot, AGENTS.md): 03 PM Runtime Architecture · 04 GitHub Label Contract · 07 Skill Role Contracts · 09 Static Skill Contract
관련 노트
- hermes-agent — Hermes Agent 개요·스킬 관리
- harness — 에이전트 하네스 개념
- openclaw · codex — 비교 대상 도구
- mcp — 외부 도구 확장 프로토콜
- 2026-05-25-diana-hu-ai-native-company-os — 이 시스템이 구현하는 “AI 소프트웨어 팩토리 + 폐쇄 루프 회사”의 원형 비전 (Diana Hu, YC)
- 2026-05-30-hashed-kim-seojun-ai-execution-intention — Part 6·Q&A에서 인용한 ‘의도 vs 실행’ 명제의 원출처 (해시드 김서준)
- moc-ai-agents-harness — MOC: 하네스 & 자가개선