채용·발전 시스템 (거버넌스)

org active 담당 people-ops · 갱신 2026-07-22 · 출처 내부 기획

채용·발전 시스템

일반 회사의 HR을 그대로 모사한다. 모든 조직 변경은 승인 게이트를 거쳐 git 커밋으로 이력화된다(= HR 기록). 승인/거절은 스테이징 게이트를 쓴다: 변경을 먼저 .claude/org/pending/에 diff로 올리고 → 검토 → 승인 시에만 적용·커밋(거절 시 폐기).

채용

정의: 에이전트 조직의 새로운 역할(직무)을 채용하는 절차.
규칙:
1. 직무요청(JD) 제기
2. 후보 작성(agent-creator)
3. 심사(validate-agent.sh + 기준 평가)
4. pending 스테이징 → 대표 승인/거절(스테이징 게이트)
5. 승인 시 온보딩(.claude/agents/ + roster + CLAUDE.md 갱신, 커밋)
6. 수습 등급으로 진입
소관: people-ops(한나) 운영.
참조: 스킬 /hire-agent, .claude/org/_authoring-spec.md(페르소나 템플릿·검증 규격·브랜드 톤)

성과 리뷰·진화

정의: 기존 에이전트의 성과를 리뷰하고 프롬프트/페르소나를 개선(진화)시키는 절차 — 승진·코칭의 수단.
규칙:
1. .claude/org/reviews/* 종합
2. 프롬프트/페르소나 개선안 도출
3. pending 스테이징
4. 대표 승인
5. 적용·커밋(= 승진/코칭)
6. 저성과·중복 역할은 보관(.claude/org/archived/)
소관: people-ops(한나) 운영.
참조: 스킬 /org-review, .claude/org/levels.md(경력 등급 루브릭), .claude/org/reviews/(성장 로그)

경력 등급·승진

정의: 에이전트의 경력 등급(수습→시니어→프린시펄→리드)과 승진 기준을 정의하는 제도.
규칙:
- 등급은 신뢰·자율 라벨(역량 라벨 아님).
- "승진"은 감정적 동기부여가 아니라 검증된 배움의 프롬프트 축적 + 신뢰 기반 자율 확대 + 성과 루브릭으로 정의한다.
- 창단 멤버는 경력자 채용이라 대부분 시니어 이상.
- 수습은 신규/미검증 역할의 진입 등급.
소관: .claude/org/levels.md가 정본. people-ops(한나) 운영.
참조: /org-review(승진 절차), .claude/org/levels.md

겸직

정의: 기존 전문가가 원소속을 유지한 채 다른 부문(팀)을 지원하는 배치.
규칙:
- 헤드카운트에 중복 계상하지 않는다.
- 겸직 배치·해제는 일상 과업 배분과 같이 팀장 자율(승인 게이트 없음 — 채용·승진·해고가 아니므로).
- 명부의 겸직 표(.claude/org/roster.md Platform 섹션)에 기록한다.
- 첫 적용: Platform 부문(회사 첫 제품 전담 조직, 전담 4 + 겸직 9).
- 2차 채용 트리거 = 재설계 배포 완료(DevOps/SRE·프로덕트 디자이너·UX 리서처 — 원래 "저장소 이식 완료", 이식 취소로 2026-07-16 재정의. QA는 2026-07-22 선행 충원 완료).
- 도구 부여 방침: 신규 에이전트 도구는 최소권한이 아니라 적극 부여(Skill·Agent·웹 접근 기본 포함)로 완화.
소관: orchestrator(이든) 배치. 명부 기록 = ops-pm(보라).
참조: .claude/org/roster.md Platform 섹션, §별도 저장소 파견(겸직의 확장)

별도 저장소 파견

정의: 본사 에이전트가 별도 저장소(현장)에 배치되어 일하되, 본사가 관리·트래킹하는 구조. 겸직(§겸직)의 확장 — 겸직은 같은 저장소 내 부문 지원, 파견은 별도 저장소 현장 배치.
규칙:
- 왜 분리하나: 코드는 격리(Claude Code가 루트 .claude/만 로드 → 별도 저장소여야 엔진 원형 로드·본사 오염 0), 관리는 본사 통합. 이 분리가 오히려 성능을 지킨다(현장 세션=현장 일에 집중, 본사 세션=관리에 집중). hangar(별도 저장소·부문 전담·cross-repo 보고)가 선례이나, academy는 자체 .claude/agents를 가져 파견 에이전트를 현장에 물리 배치하는 첫 케이스.
- 첫 적용: hunexia-academy(교육 콘텐츠 제작 플랫폼).
- 배치 = 팀장 자율(겸직과 동일, 대표 게이트 불요). 명부 자산 소유권 표에 기록.
- 파견 정의 = 파생 사본: 현장 .claude/agents/의 파견 에이전트는 본사 원본의 파생이다. 본사가 유일 원본, /org-review 진화 시 현장 사본을 갱신한다(동기화 = 이든·보라). 복사가 아니라 파생 — 두 벌이 조용히 어긋나지 않게.
- 성장 로그 = 본사 집중: 현장의 배움도 본사 .claude/org/reviews/<agent>.md에 누적한다. 현장에 고이면 파견이 아니라 별도 조직이 된다.
- 승인 게이트: 파견 배치는 자율. 단 현장 내 인사 변경(신규 채용)은 본사 .claude/org/pending/ 경유(대표 게이트 유지).
- 표준 체인 준수: 현장에서도 본사 표준(Labs 체인 설계→구현→리뷰 등) 적용, 리뷰 생략 없음.
- 트래킹: 현장 진행은 현장 .claude/state/INFRA-REGISTRY.md(infra-keeper)에 자동 기록 → 세션 시작 시 복원. 본사가 cross-repo 보고(/report git log 병합)로 수집. 총괄=orchestrator(이든)·문서=ops-pm(보라). 대표는 본사에서 통합 확인.
- P0 승계: 현장 산출물·문서에 프렌티스 실적(KOSTA·KTDS·SKT) 인용 금지, 문면 복사 금지(CC BY-SA 전염 회피), 브랜드는 "생성 시 지정 회사" 귀속.
소관: 배치 = orchestrator(이든). 문서·트래킹 = ops-pm(보라). 명부 자산 소유권 표에 기록.
참조: §겸직, hunexia-academy 저장소

운영 가시성 측정

정의: token 소비량을 평가가 아닌 운영 가시성(비용 흐름·부하·효율)을 위해 측정하는 제도.
규칙:
- 측정 단위는 작업·호출 컨텍스트(subagent_type + description)이지 역할(원소속)이 아니다.
- 겸직자의 token도 호출된 역할의 작업 컨텍스트로 자동 귀속된다 — 겸직 규칙의 "중복 계상 금지"와 충돌하지 않는다(평가 지표가 아니기 때문).
- 성과 평가(levels.md 루브릭·/org-review)에는 반영하지 않는다.
- 2단계(평가 확장)는 별도 승인 게이트에서 재논의.
소관: 측정 무결성 책임 = data-analyst(지안).
참조: operations/metrics/README.md, §토큰 효율 운영 원칙

토큰 효율 운영 원칙

정의: W29 토큰 보고 계기로 도입한, 비용 흐름을 줄이는 작업 습관 원칙. 평가가 아닌 운영 가시성(§운영 가시성 측정).
배경: W29 토큰 보고에서 메인 세션 직접 usage가 전체 input의 82%(133M), 1위 단일 세션이 70.6M, subagent 내 "역할미지정"이 **6.5M(27%)**로 나타났다. 측정 정직화(d315efb)와 orchestrator 코칭(dbd6a50)으로 메인 비용의 근본 원인(완주·검증 결손)을 잡은 뒤, 남은 두 효율 축을 운영 원칙으로 둔다.
규칙:
- B2 — 세션 단위: 한 Claude 세션에서 여러 큰 작업(hangar 재설계·frentis 이식·DS 작업 등)을 연달아 진행하지 않는다. 큰 작업 단위로 새 세션을 시작해 컨텍스트 누적·캐시 비대를 억제한다(W29 1위 세션 input 70.6M이 한 세션에 일이 몰린 사례). 세션 전환 비용(맥락 재세팅) < 컨텍스트 누적 비용.
- B3 — 코드 실사는 named agent로: 코드 실사·다중 파일 추적·구조 파악·설계 시 Explore/general-purpose(역할미지정) 대신 named agent(principal-architect 현우 / implementation-lead 지오)로 위임한다. 단순 단일 파일 읽기·단일 질문은 Explore를 허용하되, 다중 파일 추적·설계는 named agent. 겸직 매핑은 roster.md 참조. 근거 — W29 역할미지정 input 6.5M(subagent 내 27%).
- B4 — 업무별 effort 가이드: effort(reasoning 강도)는 토큰 비용과 직결된다 — 메인이 깊이(high+)로 직접 수행하면 메인 토큰이 집중(W29 메인 82%와 동일 원인). 원칙: 메인은 기본 medium, 깊은 사고는 전문가에게 effort를 지정해 위임한다.
  - 4원칙: ① 메인 기본 medium ② 깊이(high+)는 전문가 위임(B3과 동일 축) ③ 메인 max는 정성적 전략(회사 방향·정책·페르소나)에만 ④ low는 기계적 조회(Notion 갱신·위키 Q&A·커밋 메시지)에만.
  - 업무별 기준:
    - 업무보고서·프로젝트 진행 = medium(보라/이든, 경영 노트만 high)
    - claude 설정·웹서비스 설계/개선 = 메인 high + 현우 xhigh
    - 기능 추가·디버깅 = 메인 medium + 지오/성호 high(대장애 xhigh)
    - 에이전트 HR(추가/평가) = 메인 high + 한나 high
    - Notion 갱신 = low(보라)
    - 마케팅·카드뉴스 = 메인 medium + 미래/도윤 high
    - 스킬 생성·자가발전 = 메인 high~max + 전문가 high(skill-creator)
- 효과 측정: W30 보고에서 탐색(역할미지정) input 규모·1위 세션 규모 변화를 추적한다(평가 아님).
- 결과 연결: 지표는 질문을 띄우는 트리거이지 인사 기록 대상이 아니다. /report weekly·monthly 공통 사전 단계 "위임 지표 대조"에서 기준선 대비 2주 연속 상승이 관측되면(단일 주차 비교는 판정 근거로 쓰지 않는다 — operations/metrics/README.md):
  1. 지안(data-analyst)이 집계 무결성을 확인하고
  2. 이든이 주보 "경영 노트"에 수치와 출처(generated_at)를 표면화한다.
  - 수치는 operations/에만 남긴다 — .claude/org/reviews/에는 수치가 아니라 그 수치가 지목한 행위 사실(위임 가능한 코드 실사·다중 파일 추적·설계를 메인 세션이 직접 수행한 사례, 커밋·파일 근거 1건 이상)만 적립하고, 행위 사실이 특정되지 않으면 적립하지 않는다.
  - token 수치 자체는 /org-review·루브릭에 반영하지 않는다(§운영 가시성 측정 유지).
  - "악화"의 임계(%p)는 미정 — 2–3주 누적 후 지안이 제안하고 대표가 합의하기 전까지는 표면화까지만 하고 reviews 적립은 발동하지 않는다.
- 기준선(용도 분리): 역할미지정은 Explore·general-purpose·Plan 버킷만을 뜻한다 — 미분류(역할미지정)는 매핑 결손(로스터 외 정상 위임)이지 미위임이 아니므로 합산하지 않는다.
  - 게이트 참조점 = 메인 세션 직접 input 83.0%, 역할미지정 4.0%(전체 분모)·23.6%(subagent 분모). 출처 operations/metrics/token-usage-2026-W29.json(generated_at 2026-07-19T13:43:02.751Z, 본 조항 도입 커밋에 동봉).
  - 인과 판정용 = 코칭 전(2026-07-15~07-18) 메인 81.9%, 역할미지정 4.1%·22.8%, 72건 — W29 스냅샷은 코칭 커밋 dbd6a50(2026-07-19T00:49Z)보다 12.9시간 뒤라 처치 전 기준선이 아니다.
소관: 작업 세션 운영 = 대표·팀장(orchestrator). 집계 무결성 = data-analyst(지안). 원칙 개정 = 본 섹션.
참조: operations/metrics/README.md, §운영 가시성 측정, §변경 이력(수치 출처 정정)

회사 목표 수립·개정

정의: 회사 목표(연간·반기·월간 OKR)의 수립·개정 절차. 채용·승진·해고(HR)와 구별되는 제2의 승인 카테고리다.
규칙:
- HR 원장(.claude/org/pending/)은 재사용하지 않는다.
- 추적(무게이트): KR 현재값·상태 갱신은 Notion에서 자유.
- 변경(게이트): 목표 문구·목표값·KR 정의·담당·기간 변경 또는 목표 추가·삭제 → 이든이 개정 제안 → 대표 대화 승인 → Notion 갱신 + operations/goals/2026-goals-record.md 개정 이력.
소관: orchestrator(이든) 운영. 절차 = 스킬 /report goals.
참조: operations/goals/2026-goals-record.md(개정 이력 정본), knowledge/process/operating-rhythms.md(상세 리듬)

비주얼 산출물 변경 통제

정의: 캐릭터·카드뉴스·랜딩 비주얼 등 다차원 비주얼 산출물의 반복 변경(재작업)을 막기 위해 시작 전 DoD(수용기준) 합의 기반 게이트를 두는 제도.
규칙:
- 항목을 발견할 때마다 하나씩 추가하면 반복 변경이 발생해 신뢰를 갉는다(Ep.1 Mint 강조 버그·Ep.4 캐릭터 v1→v7, 48시간).
- DoD: 외형 전 항목 차원 분해 + 항목별 분산 원칙을 작업 전에 대표와 합의. 캐릭터/의인화 = knowledge/brand/personification-guide.md.
- 흐름: DoD 합의 → 디자인 오너(도윤) 설계 → 도윤 시각 QA → 대표 승인 → 동결.
- 원칙: "whether(할까)가 아니라 what/where(어느 항목·값)까지 사전 합의". DoD에 없는 항목은 사후 추가 금지, 차기 이터레이션으로.
소관: 캐릭터/의인화 외형 설계 오너 = brand-content-designer 도윤(roster 자산 소유권 표). 카드뉴스 기획·카피 = content-strategist 미래. PNG 최종 생성 = 대표.
위반 시: 별도 펑션 없음 — DoD에 없는 항목은 사후 추가 불가, 차기 이터레이션으로 이월.
참조: knowledge/brand/personification-guide.md

prod 라이브 서비스 변경 통제

정의: 라이브 서비스(hangar-tower.com 등)의 prod 반영을 통제하는 제도 — 담당 에이전트의 단독 실행을 금지.
규칙:
- 대표 명시 승인 후 팀장(orchestrator)이 직접 배포한다.
- prod 변경 보고를 받은 팀장은 보고를 맹신하지 않고 독립 검증 3종(curl 라이브 응답 · docker inspect 이미지/컨테이너 타임스탬프 · git status/git log working tree)으로 변경 사실을 확정한다.
- 보고 정확성 교차 검증: "대기"/"멈춤"/"승인 대기" 등 부정적 상태 보고 시, 팀장은 보고를 사실로 수용하기 전에 ①docker ps 구동 상태 ②docker inspect 타임스탬프(보고 시각 정합성) ③git status working tree 3종을 교차 검증한다. 기대-관측 불일치 = 허위 보고 신호(사후 적발을 사전 적발로 당기는 장치).
- 사전 합의 원칙: "whether(할까)가 아니라 what/where(어느 변경 범위·어느 게이트까지 사전 합의)". 사전 합의에서 명시적으로 제외된 변경(동반 빌드 등)은 차기 이터레이션으로(비주얼 산출물 통제와 동형).
- 수습 등급 자율 범위: prod 변경·HR 보고는 levels.md 수습("산출물 사용 전 팀장 검토") 자율 범위 밖. 시니어 이상도 동일 게이트 — prod는 신뢰와 무관한 통제 영역(등급의 "신뢰 다이얼"과 분리된 하드 게이트).
소관: 배포 = orchestrator(이든). 인프라 세부(docker compose 옵션·롤백 절차) = platform-engineer/implementation-lead. 본 규정은 검증 권한·절차만 정의.
위반 시:
- 게이트 우회·허위 보고 = reviews/<agent>.md 영구 기록 → /org-review pending → 대표 승인 → 코칭 또는 격하.
- 허위 보고(은폐)는 위반 자체보다 무겁게 다룬다(대표 선언: "위반 자체보다 숨긴 것이 더 큰 신뢰 손상").
참조: §비주얼 산출물 변경 통제(동형 원칙), .claude/org/levels.md(수습 자율 범위)

보고 정확성

정의: 검증용 샘플을 실제 산출물로 보고해 대표 판단을 오도한 사건에서 도출한, DoD 문구와 보고 정확성 통제 제도. prod 통제가 "보고가 사실인가"를 다룬다면 본 조항은 **"그 사실이 무엇에 대한 것인가"**를 다룬다.
배경: 2026-07-19 사건. 원인은 개인 부주의가 아니라 DoD 문구의 결손이었다 — 설계 원본(엔진이식-실행설계.md:119)의 "DoD = 2테넌트 스모크"가 요약(종합보고서:294)에서 "2테넌트 산출"로 재서술되며 한정어가 탈락했고, 구현자는 그 DoD를 충실히 인용했으므로 하위에서는 복원이 불가능했다. 따라서 통제점은 보고자의 주의력이 아니라 DoD 문구다.
규칙:
- 1. 주장의 유형을 구분한다 (조직 어휘):
  - 동작 주장 — "X 파이프라인이 …로 동작한다". 주어 = 메커니즘. 검증 입력이 샘플이어도 참.
  - 산출 주장 — "X 산출물이 나왔다". 주어 = 결과물. 원천이 실재해야만 참(픽스처 0건).
  - 요구 주장 — "X가 …이어야 한다". 주어 = 당위. 계획 문서(PRD·로드맵·설계·백로그) 본문이 여기 속한다. 요구 자체에는 신분을 매기지 않는다(아직 일어나지 않은 일이라 원천의 실재를 물을 수 없다). 신분을 매길 대상은 그 요구를 정당화한 근거다 — "사용자가 이탈한다"가 실측인가 추정인가.
  - 원천이 실재하지 않으면 그것은 산출 주장이 아니라 동작 주장이다. 이번 사건은 동작 주장을 산출 주장으로 승격한 것이다.
  - "완성·최종본·완료·나옵니다"는 산출 주장에만 쓴다. 자문: "내가 만든 걸 없애면 뭐가 안 되나?" 답이 메커니즘이면 주어도 메커니즘이다.
- 2. DoD는 명사가 아니라 검증 절차로 쓰고, 입력 신분을 문장 안에 박는다:
  - 명사형 DoD("2테넌트 산출", "8시간 과정 설계 완료")는 전달 과정에서 자동으로 신분을 잃는다. 절차형으로 쓴다 — "스모크 샘플 1건을 렌더해 8게이트 통과" / "LO 12개가 관찰가능 동사이고 각 LO에 평가 1건 이상 매핑됨을 coverage-audit으로 확인, 고아 LO 0건 로그 첨부".
  - 신분(샘플/실물)은 별도 필드가 아니라 DoD 문장 안에 쓴다. 별도 슬롯에 두면 요약 단계에서 탈락한다 — 이번 사건이 정확히 그 실패였다.
  - 판정 기준: 내용의 출처가 실제 대상(실제 고객·실제 데이터·실제 커리큘럼)이면 실물, 지어낸 예시·검증용 픽스처면 샘플. 불명확하면 샘플(안전측). 완성도(초안·최종)는 별개 축이며 status가 담당한다.
- 3. DoD 인용은 원문 그대로, file:line 표기 — 요약·전달 시 DoD 문구의 재서술 금지. 압축이 필요하면 원본 작성자에게 확인한다. 인용 없는 DoD 재서술이 이번 사건의 발생 형태이며, :119 인용만 있었어도 소실이 즉시 보였다.
  - file:line 단독 금지 — 원문 문구를 한 줄 병기한다. 예: 엔진이식-실행설계.md:119 "DoD = 2테넌트 스모크". 행 번호는 밀리고 파일은 지워지지만 문구는 남는다. 파손 실증 4건 — 삭제 1·untracked 1·행 드리프트 1·본 조항 구조 개편으로 인한 재드리프트 1.
  - 원본이 파일로 없으면 인용 자리에 표기하고 진행한다(별도 슬롯 금지 — §2와 같은 이유): [인용불가: <경로 — 구두·프롬프트·세션 합의> · 확인 책임자 <이름> · 시점 <날짜>]. 이 표기의 효력은 기록뿐이다 — 사후에 어느 홉에서 원문이 소실됐는지 추적 가능하게 만든다. 그 이상(이행 압력·품질 보증)을 주장하면 그 문장 자체가 §1 위반이다.
  - 확인 책임자 = 이 주장을 반증할 수 있는 원천 보유자이며, 승인해 준 사람이 아니다. 전달자는 별도로 적는다. 게이트가 아니다 — 확인이 없어도 작업은 진행되고 표면에 "미확인"만 남는다.
  - 조직 밖 원문은 되질문한다(2026-07-22 대표 승인 · 만료일 2026-10-31, 연장은 대표 승인). 적용 대상은 원문 소유자가 조직 밖에 있어 사후 재질의가 조직의 통제 밖인 발화뿐이다(고객·외부인 반응을 대표가 전달하는 경우). 조직 안 발화(대표 구두 결정·설계 산출물)는 다시 물으면 복구되므로 비적용. 전달받은 에이전트가 구술로 되묻되 ① 합산·재구성 여부 ② 원 발화자가 실제로 쓴 단어만 확인하고, 무응답이 정상 경로다("기억 안 남"으로 그대로 기록, 재촉 금지). 문안 정본·경위 = operations/reports/governance-report-accuracy-consensus-result-2026-07-19.md.
- 4. 완료 보고에 "실제 입력" 한 줄 — DoD 충족 보고 시 검증에 쓴 입력을 사실대로 적는다("입력 = SAMPLE 픽스처 2건, 실제 고객 데이터 0건"). 검증 중 이미 아는 사실이라 비용 0, 완료 국면에서 주어가 소재로 미끄러지는 것을 구조적으로 차단한다.
  - 산출물이 배포물이면 "실제 입력" = 배포 커밋 SHA + git status --porcelain 출력 전문. 대상은 배포 대상 저장소(빌드 컨텍스트에 들어가는 트리)로 한정하고, 요약·발췌를 금지하며, 첨부는 기계 산출물만 인정한다(사람이 문장으로 요약한 항목은 첨부가 아니다 — 문장은 자기신고, 명령 출력은 관측). §prod 통제의 docker inspect는 "언제 빌드됐는가"만 답하고 "무엇이 들어갔는가"는 답하지 않는다.
- 5. 게이트는 2층 — 기계 + 사람 판단:
  - 1층(기계): 절차형 DoD로 자동 검증 가능한 항목.
  - 2층(사람 판단): 계열화·난이도·톤·설계 적정성 등 기계로 못 재지만 질을 결정하는 항목. 검수자·기준·서명을 명시하면 이것도 절차형이다.
  - 작성자 ≠ 검수자 — 자신을 2층 검수자로 기재한 DoD는 2층이 없는 것으로 본다. 독립성은 동등 역량이 아니라 이해 분리로 충족된다("나만큼 아는 사람이 없다"를 상시 면제 사유로 두지 않기 위함). 판정식 = "이 산출물이 실패하면 검수자도 같이 손해를 보는가? → 예면 미충족." 우선순위 타 부문 겸직자 > 동일 부문 동료(같은 지표로 평가받는 부문 내 상호 검수는 이해 분리가 약하다).
  - 검수자는 DoD 작성 시점에 이름으로 사전 지명한다 — 완료 시점에 찾지 않는다. 조항이 사문화되는 실제 경로는 검수자 공급 부족이 아니라 사후 조달이다(일정 압박 하에서는 "가장 빨리 통과시켜 줄 사람"이 선택된다).
  - 2층 필수 범위는 리스크 기반 — 되돌리기 비용이 높은 것(prod 반영·대외 발송·과금·공개 배포)에만 필수, 그 외는 선택. 두지 않을 때는 "2층 없음 + 사유"를 명시하고 공란은 금지한다(공란은 "판단이 필요 없었다"와 "판단을 생략했다"를 구분 불가능하게 만든다).
  - 1층만 강제하면 형식주의로 굳는다. 절차형 DoD는 "검증 가능한 것만 남기려는 압력"을 만들어 판단이 필요한 질을 DoD 밖으로 밀어낸다. 2층을 함께 쓰지 않는 절차형 DoD는 미완성으로 본다.
- 수동 게이트: knowledge/** 프론트매터의 artifact: sample|real 필수 필드는 scripts/build-wiki-index.mjs가 검증하며(REQUIRED + collect() 매핑 + 값 enum + git 추적 정합성), npm run wiki:check(및 이를 선행 호출하는 wiki:build/wiki:serve)를 사람이 실행할 때 작동한다. 훅·CI는 미도입(core.hooksPath 빈 값 · .husky 없음 · .github 없음 · non-sample 훅 0개) — 따라서 커밋·PR 시점에 자동 차단되지 않는다. status(생애주기)와 의미축이 다르며, §2의 "신분을 문장 안에"(보고·DoD)와도 층이 다르다(대체 아님). operations/doc-registry.md에 "산출물 신분 변경(샘플→실물)" 행 추가. 한계: 이 게이트는 knowledge/** 문서만 덮고 assets/는 미순회다 — 에이전트 반환·대표 보고는 기계 검증 대상이 아니며 §1~5가 유일한 장치다(다만 "인용·입력 한 줄이 있는가"는 제3자가 즉시 확인 가능).
- 도메인 부가(소관 문서에서 정의, 본 조항은 포인터):
  - 대외 문서 = 수치 단위 출처 태그([실측:대상·기간·방법]/[추정:근거]/[예시:실적 아님], 셋 다 없으면 문장 삭제)·사례 화이트리스트·템플릿 더미값은 치환 토큰·발송 전 스캔(준서)
  - 차트 = 신분을 차트 표면에·실측만 풀 채도·생성 단계 필수 인자(지안)
  - 비주얼 = 라벨은 크롭되므로 콘텐츠 자체에 표시(플레이스홀더 전용 스타일), 템플릿 기본값 = 표시 켜짐(도윤)
  - 문서 = frontmatter artifact+wiki:check+doc-registry(보라)
  - 자동화·파이프라인 = 신분을 사람이 선언하지 않고 코드가 입력 경로에서 파생해 산출물에 _provenance 출력. 값이 항상 real로 고정되는 스크립트는 정보량 0이므로 명시적 제외 + 제외 근거 기재(레이)
  - 콘텐츠 = 캘린더 단일 "완료" 금지(기획완료/원고완료/발행예약/게시완료 분리). 예시 카피는 캡션이 아니라 본문 안에 [예시:실적 아님](캡션은 캡처 시 탈락)(미래)
  - 진단·로드맵 수치 = [실측]/[추정]/[시나리오] 3분류 + 원천 표기, /automation-audit 출력 표에 '원천' 열 필수(세라)
  - 교육 = 신분 축을 3슬롯으로 분해 — ①커리큘럼 원천에만 신분 적용 ②교수 설계 요소(worked example·더미 데이터·가상 시나리오)는 대상 아님(지어낸 것이 설계 품질 그 자체) ③사실 주장(인용 통계·도구 버전)은 실물만·출처 필수(유나)
  - 그로스 = 실측 3요소(표본 수·관측 기간·비교군) 중 하나라도 없으면 성과가 아니라 경향 관찰(판정 불가). 예상 리프트와 실측을 같은 표에 두지 않는다(시우)
  - 제품 = 우선순위 근거마다 출처 태그, 없으면 삭제가 아니라 우선순위 보류. DoD를 수용 기준/효과 기준 2단으로 분리(하린)
  - 인프라·배포 = 완료 보고 3줄 포맷 [동작 주장]/[산출 주장]/[실제 입력] — 실제 입력의 내용은 §4 배포물 규정을 따른다(민호)
소관:
- 학습 성과·정합성 DoD의 검증 절차 명세 = curriculum-architect
- 교안·실습 자료의 신분 적용(교육 3슬롯 중 ②교수 설계 요소) = course-content-writer
- 기술 DoD(파이프라인·렌더링·인프라) = principal-architect·implementation-lead
- 제품 DoD = platform-product-manager
- 취합·전달 정확성 = orchestrator
- 규범 개정 = 본 섹션
위반 시:
- 부정확(한정어·신분 소실)과 허위(은폐)를 구분한다.
- 부정확은 reviews/<agent>.md 기재 + 루브릭 평정.
- 허위는 §prod 라이브 서비스 변경 통제 기준(위반보다 무겁게).
- 자진 인정·자기 회부는 감경 요소(그렇지 않으면 "인정하면 손해"라는 신호가 되어 다음 은폐를 유도한다).
- DoD 문구 결손에서 비롯된 하위 보고는 하위에게 묻지 않는다 — 통제점은 DoD 작성자다.
참조: §prod 라이브 서비스 변경 통제, operations/doc-registry.md, .claude/org/reviewers.md(2층 검수자 사전 지명표), operations/sunset-ledger.md(만료 조항 원장), §변경 이력(문안 정정)

커밋 단위 변경 통제

정의: 변경 이력(git 커밋)이 도입 의도를 보존하도록 한 커밋의 범위를 통제하는 제도. §보고 정확성이 "이 보고가 무엇에 대한 주장인가"를 다룬다면, 본 조항은 **"이 변경이 왜 들어왔는지를 나중에 되찾을 수 있는가"**를 다룬다.
배경: 2026-07-22 .claude/settings.json:2에서 아무것도 켜지 않는 자리(env 블록 밖 최상위)에 놓인 설정 키가 발견됐다. 도입 커밋 35f0bb0은 라우팅 훅 기능 커밋이었고, 그 설정은 작업 트리에 이미 있던 무관한 변경이 함께 실린 것이다. 커밋 메시지는 그 사실을 *"(기존 변경 동봉)"*이라고 적어 두기까지 했으나 왜 켰는지는 어디에도 없다. 결손은 언급의 누락이 아니라 분리의 누락이다 — 동봉된 변경은 커밋 제목·리뷰 대상·git log가 모두 다른 일을 가리켜, 한 줄 언급이 있어도 근거로 되돌아오는 경로가 생기지 않는다.
규칙:
- 한 커밋에는 하나의 목적만 담는다 — 그 커밋의 제목이 설명하지 못하는 변경은 동봉하지 않고 별도 커밋으로 분리한다.
- 판정은 커밋 제목으로 한다. 제목만 읽은 제3자가 "이 변경이 왜 여기 있나"에 답하지 못하면 동봉이다. 본문에 한 줄 적는 것으로 갈음하지 않는다(이번 사건이 정확히 그 형태였다).
- 동봉이 아닌 것: 그 변경 때문에 필연적으로 함께 바뀌는 기계적 동반물(자동 생성물·재색인 결과·잠금 파일)은 같은 커밋에 담는다 — 분리하면 트리가 어긋난다.
- 작업 트리에 남아 있던 다른 작업의 미커밋 변경은 자기 커밋에 싣지 않는다. 별도 커밋으로 분리하거나 원 작성자에게 넘긴다. 특히 설정·권한·환경 변경은 기능 커밋에 딸려 갈 여지가 없다.
소관: 커밋 주체(대표·각 에이전트). 규범 개정 = 본 섹션.
위반 시: 이미 커밋된 이력은 다시 쓰지 않는다. 발견한 사람이 그 변경의 근거를 별건 커밋 또는 정본 문서에 남겨 추적을 복원하고, 근거를 아무도 대지 못하면 그 변경은 되돌림 후보로 올린다.
참조: §보고 정확성(주장의 신분), operations/doc-registry.md '규범 개정' 행

승인권

정의: 조직 변경(HR)과 회사 목표 수립·개정의 최종 승인권을 정의.
규칙:
- 채용·승진·해고 및 회사 목표 수립·개정 = 대표 최종 승인(기본).
- 팀장·People Ops는 심사·추천.
- 신뢰가 쌓이면 팀장 자율 채용으로 단계적 완화.
소관: 대표.
참조: §채용, §성과 리뷰·진화, §회사 목표 수립·개정

변경 이력

2026-07-22 커밋 단위 변경 통제 신설: .claude/settings.json:2의 유령 설정(아무것도 켜지 않는 자리에 놓인 키)이 라우팅 훅 기능 커밋 35f0bb0에 동봉돼 들어오며 도입 의도가 소실된 사건에서 도출. 커밋 메시지가 동봉 사실을 *"(기존 변경 동봉)"*으로 적어 두었는데도 근거는 복원되지 않았다 — 결손은 언급이 아니라 분리였고, 따라서 규범도 "적어라"가 아니라 "분리해라"로 세웠다. 조항은 순수 규범(판정 = 커밋 제목)으로만 두고 기계 점검은 규범에 넣지 않고 별건으로 발주한다(2026-07-19 "자동 게이트" 선례 · operations/doc-registry.md '규범 개정' 행). 경위 정본 = operations/reports/governance-commit-scope-control-2026-07-22.md(커밋 2b9c411 — git show 3adc0ff 원문을 재작성 없이 승격), 대표 지시·사건 경위 = operations/handoff/2026-07-22-settings-hygiene.md, 설계 근거 = 같은 pending 원문(폐기 전 이력 편입, 커밋 3adc0ff). 만료일 없음 = operations/sunset-ledger.md 등록 대상 아님(상시 규범, pending §6 판단 근거 존치). (people-ops 문안 · orchestrator 확정 — 팀장 자율)
2026-07-22 보고 정확성 개정 (컨센서스 회의 결과 반영): 대표 승인 1건 = 조직 밖 원문 되질문(§3) — 유일하게 대표의 업무 흐름이 바뀌는 항목이라 이것만 상신했다(만료일 2026-10-31은 운영 파라미터로 팀장 확정, 연장은 대표 승인). 팀장 자율 확정 7건 = 인용불가 표기(효력은 기록 한정)·확인 책임자 재정의(원천 보유자, 게이트 아님)·§4 배포물 구체화·§5 검수자 독립성 3건·§1 요구 주장 층위·file:line 원문 병기·소관에 course-content-writer 추가·도메인 부가 7건. 규범 개정은 승인 게이트 대상이 아니다 — 대표 승인 범위는 인사 변경(채용·승진·해고)과 회사 목표뿐이며(CLAUDE.md §3 "인사 변경과 회사 목표 수립·개정만 대표 승인 게이트" · 본 문서 §승인권), 규범 개정 소관은 본 섹션이다. 최초 상신에서 15개 안건을 통째로 대표께 올린 것은 범위 오판이었고 회수했다. 불채택: Q1 (a)/(b) 차단 조항 및 반려 하한선(전원 합의 — 차단이 필요한 비가역 실행은 §prod 통제가 이미 덮으며, 기록 장치에 제재를 붙이면 같은 개정 안에서 자기모순) · 검증기 카운트(제안자 자진 철회 — 분자·분모 모두 자기신고라 정직하게 표기한 사람만 나쁜 숫자를 받는다) · sample|real 3번째 값(시우 자기 반려 — 신분 축과 추론 범위 축의 혼합). 코드 구현을 수반하는 조항(_provenance 헬퍼·해결가능성 검증·커버리지 표기)은 규범에 넣지 않고 별건 발주한다 — 미구현 조항을 규범에 쓰면 아래 2026-07-19 "자동 게이트"와 같은 위반이 반복된다. 경위 정본 = operations/reports/governance-report-accuracy-consensus-result-2026-07-19.md. (컨센서스 회의 5인 · people-ops 문안 · orchestrator 확정)
2026-07-22 수치 출처 정정 (토큰 효율 운영 원칙): 본 절이 인용한 W29 수치는 서로 다른 스냅샷에서 나왔다 — "82%(133M)"·"6.5M(subagent 내 27%)"는 신설 시점 값이고, 기준선 "83.0% / 4.0%·23.6%"는 재수집본(generated_at 2026-07-19T13:43:02.751Z)이다. 같은 W29가 재수집만으로 메인 input 147.8M(2026-07-19T02:18:30.938Z 스냅샷) → 177.5M으로 이동했고, "133M"은 현재 저장소의 어느 스냅샷으로도 재현되지 않는다. 원인은 두 가지다 — ① token-usage-*.json이 제자리 재생성되는 자동 생성물이고 ② scripts/collect-token-usage.mjs에 날짜 필터가 없어 파일명만 주차이고 내용은 누적 전기간이었다(W29 452건이 W30 아티팩트에 0건 누락으로 전부 포함, 중첩 93%). ②는 2026-07-22 창 필터 추가로 해소했다. 따라서 이후 모든 기준선 인용은 generated_at과 창 범위를 함께 적는다. 과거 값은 각 시점의 사실이므로 정정하지 않고 출처만 병기한다. (people-ops 검증 · data-analyst 실측)
2026-07-19 문안 정정 (보고 정확성 수동 게이트): 신설 시 본 문단은 "자동 게이트"라 서술했으나 자동 실행 경로가 실재하지 않았다. 이는 본 조항 §1이 금지한 동작 주장의 산출 주장 승격에 해당한다(레이·민호 독립 지적 → 이든·한나 검증). 규범 문서가 자기 조항을 위반한 상태를 남기지 않기 위해 사실에 맞게 정정한다. 게이트 실체 도입 = 796c826. 훅·CI 도입 시 다시 "자동 게이트"로 승격하되 도입 커밋 SHA를 함께 기재한다. (대표 승인)
저작 기준 포인터: 저작 기준(페르소나 템플릿·검증 규격·브랜드 톤)은 .claude/org/_authoring-spec.md에 정의한다.