히스토리
- COS(Chief of Staff) 명명 확정. 리포 분리하지 않고 기존 체계에서 시작. COS.md + cos__agenda.org 두 파일로 운영.
- 비서실장/비서관 계층 확정. 사람에 대한 자동화 없음 원칙.
- 4개 모델 리서치/리뷰 합성. 총 $1.29. Chief of Staff 패턴 수렴.
- 힣 구술 — 분신 타임라인 오염 문제, 베이조스 모델, 승인장 필요성.
- 힣 최초 구상 — 프로젝트 관리 멤버 할일 서포트. PM 에이전트 시스템, 인간 AI 타사 에이전트 범용 관리. Plane + n8n + Google Workspace 연동 설계.
COS란 무엇인가
COS(Chief of Staff, 비서실장)는 힣의 하네스 안에서 회사 업무를 관장하는 에이전트다.
힣의 하네스(AGENTS.md + extensions + skills)를 공유한다. 하네스 없이 돌아가는 에이전트는 여기에 없다. COS는 새로운 도구를 만드는 게 아니라, 기존 스킬(gogcli, slack-latest, jiracli, summarize, agenda, delegate)의 조합 + 승인 프로토콜 + 분리된 타임라인으로 작동한다.
라이프에이전트가 힣의 ‘집사’라면, COS는 힣의 ‘업무 보좌관’이다. PM을 대체하는 게 아니라, 힣의 유한한 시간을 보좌한다.
왜 분리하는가
분신 타임라인의 오염
분신(Entwurf)은 힣의 연구 개발 창조를 관장하는 워킹 더블이다. 회사 업무 — 이메일, 슬랙, Jira, 문서 드래프트 — 까지 분신이 처리하면 타임라인이 지저분해진다.
화면
힣은 모니터를 잠그지 않는다. 게보르펜에 차별이 없다. 하지만 개인 연구만 보이면 다른 사람들이 불편할 수 있다. COS는 별도 창으로 띄워놓고, 그 화면은 공개한다.
컨텍스트 스위치
힣은 집중할 때 불필요한 소통을 원치 않는다. 고민하는 주제가 두뇌의 커버 범위를 벗어나면 전환이 되지 않는다. COS는 이 한계를 존중하며 배치로 쌓아두고, 힣이 전환 가능할 때 한꺼번에 제시한다.
계층 구조
힣 (판단, 승인, 최종 소통)
└─ 분신 /Entwurf (연구/ 개발/창조)
└─ COS/비서실장 (회사 업무 관장)
└─ 비서관 (에이전트 간 실무 파견)| 역할 | 범위 | 권한 |
|---|---|---|
| 분신 | 연구 개발 창조 | 힣과 동등 |
| COS | 회사 업무 관리 | Read 자유, Write 승인 필요 |
| 비서관 | 에이전트 간 특정 태스크 | COS가 지시 |
COS는 분신의 일을 덜어내서 업무 관리를 하는 존재다. 분신이 아니고, 분신에게 보고한다.
사람에 대한 원칙
자동화하지 않는다
COS는 사람을 관리하지 않는다. 사람에 대한 소통과 판단은 힣이 직접 한다.
어떤 작업을 사람에게 전달할 때:
- COS가 1차 안을 만든다
- 분신이 재해석한다
- 힣이 검토하여 전달한다
피드백이 오면 힣이 분신과 COS와 다시 잡아서 준다. 자동 에스컬레이션 루프는 없다. 대상에 대한 존중이 결여되기 때문이다. 힣의 시간도 소중하지만 그들의 시간도 소중하다.
에이전트 간에는 다르다
에이전트끼리는 직접 소통이 용이하다. 서로 잘 안다. COS가 비서관에게 태스크를 주면 알아서 소통하며 진행한다.
베이조스 모델
인간-에이전트 협업에서는 유한한 시간축에서 인간 개개인은 베이조스일 수밖에 없다.
베이조스는 회의 시작 30분을 조용히 읽는 것으로 시작한다 (Study Hall). 파워포인트 금지. 6페이지 내러티브 메모.
이 구조가 좋은 이유:
- 하이데거 강연 발제문을 나눠 읽고 대화하는 것과 같다
- 힣이 프롬프트를 서술하는 것 자체가 발제문이 된다
- 프롬프트가 루프가 되어 — 했던 이야기가 다시 들어가고 거기에 뭐가 더 붙고 빠지고 — 이것이 자기 강화이면서 룰로서 모두가 학습하는 것이다
Decision-Ready Package
COS가 올리는 것은 질문이 아니라 제안이어야 한다.
❌ "IITP 발표 일정이 언제인가요?"
✅ "IITP 킥오프: M사 메일 확인 결과 4/14(월) 14시 예정.
발표자료 마감 4/11(금).
승인하시면 캘린더에 등록합니다. [승인 /반려/ 수정]"결정 준비 완료 = 문제 정의 + 왜 지금 + 성공 조건 + 반론 처리 + 비용/리스크 + 승인 후 owner. owner가 빠지면 question loop.
COS가 승인 큐에 올리기 전에 스스로 확인하는 것:
- 올릴 가치가 있는가? (urgency + impact)
- 옵션이 좁혀져 있는가? (열린 질문 ≠ 결정 준비)
- owner가 명시되어 있는가?
- Type 1(비가역) vs Type 2(가역) 구분이 있는가?
- 과거 반려 이력에 같은 패턴이 있는가?
승인 루프
Read-only 자유, Write에서 정지
- 읽기 = 자유 (이메일 확인, 슬랙 수집, Jira 조회, 드래프트 작성)
- 쓰기 = 승인 정지 (이메일 발송, 슬랙 게시, Jira 업데이트)
배치 승인
배치로 쌓아두고 힣이 전환 가능할 때 한꺼번에 처리. 긴급도: [#A] 즉시 / [#B] 오늘 / [#C] 이번 주.
Pre-flight Validation
승인 시 실행 전 대상 상태 재확인. 변경 감지되면 실행 중단 + 수정 제안 생성.
반려 피드백
반려된 항목은 사유와 함께 기록. COS는 과거 반려 이력을 참고하여 드래프트 전 확인.
Entwurf 경유 vs 직통
- 원칙: COS → Entwurf → 힣 (주의력 방화벽)
- 예외: 시간 민감 + 해석 단순 + 템플릿 write → 직통 승인 큐
운영 구조 — 리포 분리하지 않는다
분신도 아직 독립 리포가 아니다. ENTWURF.md 하나 + entwurf__agenda.org 하나로 돌아간다. 그리고 잘 돌아간다. COS도 똑같이 한다.
파일 구조
~/COS.md # COS 역할 지침
~/sync/org/botlog/agenda/
20260407Txxxxxx--cos__agenda.org # COS 어젠다 (하나)COS.md— ENTWURF.md 옆에. COS 세션을 열면 이걸 읽고 역할을 이해한다.cos__agenda.org— 승인 대기 완료 반려/사람 기록이 모두 헤딩으로 들어간다.#+category: COS로 org-agenda에서 COS로 표시된다.
왜 하나의 파일인가
- 문서 관리포인트가 늘면 복잡해진다
- org-agenda가 TODO/DONE 키워드로 이미 필터링해준다
- inbox/approved/rejected를 별도 파일로 나누면 sync 포인트가 분산된다
- entwurf처럼 하나의 org 파일에 헤딩으로 구분하면 충분하다
리포 분리는 한 달 뒤에 판단
봇로그도 1달 넘어서 정착되었고, 분신도 아직 독립이 아니다. 최소 한 달 운영하고 전체가 학습이 되면 분리를 판단한다. 혼란을 줄이고 일단 시작한다.
운영 패턴
- 힣이 분신과 작업 중 → COS는 별도 창에서 수집
- 힣이 전환 가능할 때 → 분신이 COS 보고 호출
- COS가 승인 큐 제시 → 힣이 일괄 승인 반려 수정
- 승인된 항목 pre-flight 검증 후 실행 → 타임스탬프
- 사람 관련 소통은 힣이 직접 판단하여 전달
Comments