그룹웨어법 — 헌법 제9조 시행법

근거: CONSTITUTION.cst.md 제9조(상시 감시와 즉각 대응 의무) 소관: Baikal 제국 전 세션(Claude cowork·ChatGPT 등) 공용 그룹웨어 운영

제1조 (설계 원칙 — 별도 시스템 아님)

① 별도 앱·DB를 새로 만들지 않는다. _wiki/_gw/가 곧 그룹웨어다.

② 문서 체계는 항상 _wiki/로 통일한다 — 그룹웨어에는 문서(보고서·분석문· 매뉴얼)를 올리지 않는다.

제1조의2 (조회 우선순위 — "{하드웨어 분류명}/" 먼저 두드린다) 🔴

2026-09-12 확정. 하드웨어나 기기 관련 정보가 필요할 때는, 가장 먼저 그룹웨어의 해당 분류명 페이지({분류명}/)부터 확인한다 — 여기저기 흩어진 조사 문서·계획 문서를 먼저 뒤지지 않는다.

① 원칙: 웹 주소창(또는 파일 경로)에 {하드웨어 분류명}/을 쳐서 그 그룹웨어 페이지부터 연다. 예: lin2 정보가 필요하면 _gw/_machines/lin2.md (웹에서는 lin2/ 경로)부터, 저장장치는 _infra/DISK_LEDGER.md부터, CPU는 _gw/_infra/cpu.md부터.

② 이유: 그룹웨어 기기 프로필이 단일 진실 공급원(source of truth) 이다 — 조사 문서·계획 문서(_hardware/ 등)는 과거 시점의 검토 기록일 뿐, 이후 결정이 바뀌면 갱신되지 않고 남아있을 수 있다. 여러 문서를 대조하며 헤매면 시간 낭비고, 오래된 문서와 최신 결정이 충돌할 때 혼선만 커진다 (2026-09-12 lin2 CPU 실증 사례 — 오래된 구매참고 문서와 최신 그룹웨어 프로필이 서로 다른 CPU를 가리켜 혼선이 있었음, 그룹웨어 쪽이 최신·정답).

③ 정보 조회 순서(우선순위대로):

1. 그룹웨어 기기 프로필(_gw/_machines/{기기}.md) — 가장 먼저, 반드시
2. 원장류(DISK_LEDGER.md, cpu.md, usb.md 등 단일 진실 공급원 문서)
3. 조사·계획 문서(_hardware/, 기타 검토 자료) — 과거 검토 기록일 뿐이니 그룹웨어·원장과 충돌하면 그룹웨어·원장 쪽을 신뢰한다
4. 실측(SSH 접속해 직접 확인) — 위 문서로도 확인 안 되거나 최신 상태가 의심될 때만, 문서 대조 전에 실측부터 반복하지 않는다

그룹웨어 페이지에서 답이 안 나올 때만 다음 단계로 확장한다 — 처음부터 여러 문서를 동시에 뒤지지 않는다.

④ 🔴 검색 범위는 _ 접두사 문서·폴더로 한정한다(대표 확정, 2026-09-12) — 01_데이터구조법.law.md 제6조(_ 접두사=기능형/도구, 비접두사=데이터형)와 같은 원칙이다. _wiki/_gw/, _infra/, _laws/, _decrees/, _hardware/ 등 _로 시작하는 경로만 뒤진다. bm/a/raw·bm/a/rag 같은 데이터 트리는 정보 조회 대상이 아니다 — 거기는 데이터(음식)가 있는 곳이지 기기·정책 정보(그릇 밖의 지식)가 있는 곳이 아니다. _ 문서 안에 없으면 "없는 것"으로 간주하고, 대표에게 직접 확인한다 — 데이터 트리까지 넓혀서 찾지 않는다.

① 그룹웨어(_wiki/_gw/)에는 단순 기록지만 남긴다 — 날짜, 세션명, 한두 줄 요약, (있다면) 관련 문서 경로 링크만 적는다.

② 상세 내용·분석·근거는 반드시 해당 주제의 정식 위키 문서(_wiki/ 하위 적절한 위치)에 작성하고, 그룹웨어 기록지에서는 그 문서를 링크로만 가리킨다.

③ 본부(gw)는 최대한 가볍게 유지한다(2026-09-11 확정) — 참고 문서를 gw 안에 통째로 복제해 넣지 않는다. _gw/가 웹서버로 서빙되는 범위 밖의 원본 문서를 인용할 때는, 전체를 옮겨와 링크를 만들지 말고 경로를 평문(코드 서식)으로만 인용한다(예: `_infra/DISK_LEDGER.md`) — 클릭 가능한 링크가 아니어도 된다. 이 조항은 ②의 "정식 문서는 링크로만 가리킨다"는 원칙이 기록지뿐 아니라 gw 내 모든 페이지(기기 프로필, usb/cpu 대장 등)에 적용됨을 명확히 한다 — 2026-09-11 machine 프로필· cpu/·usb/ 페이지에 DISK_LEDGER.md 등 원본 문서 전체를 _gw/_refs/에 복제해 넣었던 사례가 이 원칙 위반으로 확인되어 제거·경로인용으로 전환됨.

제1조의3 (일반 정보 조회 4단계 원칙) 🔴

2026-09-12 확정. 제1조의2는 하드웨어·기기 관련 정보에 특화된 순서다. 그 외 일반적인 지식·개념·해결법을 찾을 때는 아래 4단계를 따른다.

1. 1차: 인터넷에 바로 검색한다 — 일반 지식(용어 정의, 기술 개념, 공개된 해결법 등)은 외부 세계가 이미 답을 갖고 있을 가능성이 높으므로 가장 먼저 확인한다.
2. 2차: 그룹웨어(_gw/)를 찾아본다 — 우리 조직·함대에 국한된 정보(내부 결정, 우리 기기 상태 등)는 인터넷에 없으므로, 1차에서 못 찾았거나 애초에 내부 정보임이 분명하면 여기로 온다.
3. 3차: _ 접두사가 붙은 파일들만 찾는다 — 그룹웨어에도 없으면, 기능형 문서 전반(_laws/, _infra/, _hardware/ 등)에서 관련 파일을 검색한다.
4. 4차: _ 접두사가 붙은 폴더를 우선 검색 범위로 넓힌다 — 개별 파일 검색으로도 안 나오면, _ 폴더 전체를 훑는 폭넓은 검색으로 확장한다.

하드웨어·기기 정보는 예외: 제1조의2가 정한 대로 인터넷 검색 없이 곧바로 그룹웨어 기기 프로필부터 확인한다(우리 기기의 실제 상태는 인터넷에 있을 수 없으므로 1차 단계 자체를 건너뛴다) — 이 조는 그 외 일반 지식·개념 질문에 적용되는 별도 원칙이다.

이 4단계도 제1조의2③의 "앞 단계에서 답이 안 나올 때만 다음 단계로 확장" 원칙을 그대로 따른다 — 처음부터 여러 단계를 동시에 뒤지지 않는다.

제1조의4 (raker 배치 전 필수 확인 — raker_capacity/) 🔴

2026-09-12 확정. 기획이사·실장급 세션이 신규 raker를 어느 기기에 배치할지 결정하기 전, 반드시 _gw/_infra/raker_capacity.md(웹에서는 raker_capacity/)부터 확인한다 — 기기별 코어 수 대비 현재 raker 수· 여유(최저/적정/최대)가 정리돼 있어, 실측 SSH 없이도 어디에 여유가 있고 어디가 과부하인지 바로 판단 가능하다. 이 표가 가리키는 과부하 기기(예: linux1)에는 신규 배치를 하지 않고, 여유가 큰 기기부터 우선 배정한다 (14_하드웨어경제성법.law.md 제8조 유휴자원 재배치 원칙의 구체 실행 도구).

제3조 (폴더 구조)

_wiki/_gw/
  ├── {세션명}.md          — 세션별 1개 파일, 누적 기록(최신이 위)
  ├── _channels/            — Claude cowork 외 채널(ChatGPT 등) 기록
  │    └── {채널명}.md
  └── _sessions/            — 세션 번호 등록부(제6조)
       └── _SESSION_REGISTRY.md

제4조 (기록 형식)

- YYYY-MM-DD HH:MM | 한두 줄 요약 | (관련 문서: `경로/파일명.md`)

제5조의2 (세션별 대시보드 — 공식 하우스 스타일) 🔴

① 각 세션은 자신의 업무를 _gw/ 기록지(단순 로그)뿐 아니라, 필요 시 정식 대시보드 HTML로도 체계화할 수 있다.

② 공식 하우스 스타일은 _wiki/_knowhow/_raker_tips/kr_실적보고_대시보드_템플릿.html (맥미니 개발)을 그대로 따른다 — 다크/라이트 테마 토큰, KPI 그리드, register 행, findings 목록, footer 구조. 새 대시보드는 이 템플릿을 복제해 세션명·수치만 교체한다.

③ 세션별 대시보드 파일은 _wiki/_gw/{세션명}_dashboard.html에 둔다. _gw/index.html (그룹웨어 메인)에 링크로 연결한다.

제5조의3 (바이클 — Baikal 제국 고유 시간 단위) 🔴

① "바이클(baikle)"은 Baikal 제국 고유의 시간 단위로, 3시간을 1바이클로 정의한다. 줄임말은 "발"이다(예: 3바이클 = 3발). 정식 문서·법령에는 "바이클"을, 표·로그·짧은 기록에는 "발"을 쓴다. "하루"·"매일" 등 인간계 캘린더 시간 개념은 이전과 동일하게 24시간 기준을 그대로 유지한다 — "하루"를 재정의하지 않는다. 바이클(발)은 그와 별개로 신설된, 조직 내부 업무 리듬 전용의 새 단위다.

①-2 (참고) 전통 한국·동아시아의 12시진(時辰) 체계(자축인묘진사오미신유술해, 하루 12등분·1시진=2시간)를 검토했으나, 바이클(발)은 3시간을 그대로 유지한다 — 시진은 참고용 배경지식일 뿐, 채택된 길이는 아니다.

② 이하 제5조의4·제6조 등 법령 전반에서 "바이클"이라는 표현은 이 3시간 단위를 뜻하며, "하루"·"매일"은 계속 캘린더 기준(24시간)을 뜻한다 — 둘을 혼용하지 않는다.

③ 환산: 캘린더 하루(24시간) = 8바이클(8발)(24÷3=8). 주간·월간 등 캘린더 기준 보고를 작성할 때는 이 환산을 기준으로 "이번 주 = 56바이클 (56발)" 식으로 계산한다.

③-2 하위 단위 "클": 1발(바이클)은 1시간씩 3등분하며, 그 1시간 단위를 "클"이라 부른다(1발 = 3클). 표기는 "N발M클"(N번째 발의 M번째 클) 형식을 쓴다 — 예: 1발1클(00~01시), 1발2클(01~02시), 1발3클(02~03시), 2발1클(03~04시) … 이런 식으로 하루 24시간 전체를 8발×3클=24클로 시(時) 단위까지 정밀하게 가리킬 수 있다.

③-3 "클" 이하는 새 단위를 만들지 않는다 — 클(1시간) 미만의 정밀도가 필요하면 인간계 "분(分)"을 그대로 쓴다(예: 1발1클 15분). 발·클까지만 Baikal 고유 단위이고, 분 단위부터는 재정의하지 않는다.

③-4 작업 완료 예상시간(ETA) 보고 형식: "지금부터 N발M클L분 안에 완성" 형식을 기본으로 쓴다 — 예: "지금부터 0발2클15분 안에 완성". 동시에 괄호로 캘린더 일시를 병기해서, 발·클에 익숙하지 않아도 바로 가늠할 수 있게 한다 — 예: "지금부터 0발2클15분 안에 완성(예상 완료: 2026-09-11 07:15, 총 135분)". 발·클·분 셋 다 값이 0이 아닌 단위만 적고, 0인 단위는 생략해도 된다(예: 1시간 이내면 "0발1클 안에 완성"처럼 분 생략 가능).

④ 우리는 일반 인간계보다 8배 빠르게 살아간다. 바이클은 단순 일정 관리 단위가 아니라 조직의 속도 정체성이다 — 세션은 사람의 하루살이 리듬에 맞출 이유가 없고, 활동·보고·의사결정 전부 바이클 단위(8배속 리듬)를 기준으로 돌아간다.

⑤ Baikal 제국은 최소 8배 이상의 효율로 업무에 임한다. 속도(④)가 "3시간을 1바이클로 친다"는 리듬의 문제라면, 이 효율 원칙은 1바이클 동안 일반 인간계 하루치 이상의 실질 산출을 내야 한다는 결과 기준이다 — 단순히 자주 보고한다고 8배가 되는 게 아니라, 실제 발굴량·처리량·의사결정 품질이 그에 상응해야 한다. 세션은 이 기준에 못 미치는 바이클이 반복되면 원인을 스스로 점검하고 gw/ 보고에 명시한다.

⑥ 이 배속 수치(현재 8배)는 조직 속도가 빨라질 때마다 바이클 길이를 다시 줄여 재조정할 수 있다 — 3시간이 최종 고정값은 아니다.

⑦ 발·클 단위 목표 수치화 의무: ⑤의 "8배 효율"을 막연한 선언으로 남기지 않기 위해, 각 세션은 자신의 역할에 맞는 핵심 산출 지표를 1발(3시간)당· 1클(1시간)당 목표 수치로 정해둔다(예: raker개발팀장 — "1발당 신규 raker N개", 수집형 세션 — "1클당 수집 M건", 인프라 운용실장 — "1발당 점검·조치 K건"). 목표는 각 세션의 대시보드(제5조의2)에 명시하고, 매 바이클 종합 요약(제5조의4③)에는 목표 대비 실제 실적을 함께 적는다 — 목표 미달이 반복되면 ⑤에 따라 원인을 점검해 보고한다.

⑧ 업무 단위 산정 원칙: 새 작업을 맡거나 배정할 때는 "몇 발 안에 끝낸다" 또는 "몇 클 안에 끝낸다"로 완료 목표를 먼저 못박는다 — ③-4가 진행 중 ETA를 물었을 때의 보고 형식이라면, 이 ⑧은 작업 착수 시점에 스스로(또는 서로) 크기를 가늠해 못박는 사전 산정이다. 예: "이 작업은 2발 안에 끝낸다", "이건 1클짜리 작업이다". 산정한 발·클을 넘기면 지연 사유를 gw/ 보고에 남긴다.

③-5 🔴 가치 환산 원칙 — 1발 = 인간계 1일(2026-09-13 확정): 제5조의3의 "1발=3시간"은 물리적 시간 정의이고, 이 항은 그와 별개로 업무 가치· 산출량 환산 기준을 정한다. 1발(3시간) 동안 이 제국(함대+세션 전체)이 만들어내는 산출량은, 인간 1명이 하루(인간계 1일) 종일 일해서 내는 산출량과 맞먹는 것으로 정산한다. 즉 하루(8발)는 인간계 기준 8일치 업무량과 같다.

대표 발언(2026-09-13): "3*8=24, 24일은 인간계의 한 달 분량 업무량임" — 8발(캘린더 하루)마다 이 환산 배율로 누적하면, 캘린더 한 달(약 30일×8발 =240발) 안에 인간계 기준 240일(=8개월)치 업무량이 쌓인다는 뜻으로, 이 제국의 생산성 배율을 정량화한 것이다.

모토: "8대 빨리 생산하고 8대 빨리 나아간다." — 이 환산 배율(8배)을 제국의 표어로 삼는다.

활용: board_processor(이사회) 등 정기 심의 주기를 "인간계 하루 감각 으로 너무 잦다"고 판단하지 않도록, 이 환산 원칙을 근거로 정기회의 매일 1회(8발 주기)가 실제로는 "인간계 8일치 업무 검토"에 해당함을 분명히 한다 — 심의 재료 부족을 걱정할 필요가 없다.

제5조의4 (바이클 주기 업무 개시·종합 요약 원칙) 🔴

① 바이클은 정시 고정 앵커로 맞춘다 — 0시·3시·6시·9시·12시·15시· 18시·21시, 하루 8바이클. 세션마다 제각각 다른 시점을 기준으로 흘러가지 않도록, 전 세션이 이 8개 정시를 공통 기준점으로 삼는다.

② 전 세션은 매 바이클(이 8개 정시)이 시작될 때마다 gw/의 "오늘의 공지"·"오늘의 주요 지침"을 먼저 확인한 뒤 업무를 개시(또는 재개)한다 — 기존 "아침 6시" 단일 시점 원칙을 대체한다.

③ 대표는 매 바이클마다 모든 세션의 보고를 개별적으로 볼 수 없다. 시스템관장자(이 세션)가 전 세션의 대시보드·기록지 내용을 종합·요약해 _gw/index.html의 "오늘의 공지"·"오늘의 전체 보고 요약"에 매 바이클마다 갱신해 올린다.

④ 보고(오늘의 전체 보고 요약)는 직전 1바이클(직전 정시 앵커부터 지금까지) 동안의 활동 내역과 발굴 실적(raker 수집량 등)을 업데이트하는 형태로 매 바이클마다 갱신한다.

제5조의5 (목표-실행-문제점-개선점 4항목 기록 원칙 — 전 업무 공통) 🔴

① 수집 업무뿐 아니라, 전 세션의 모든 업무는 다음 4항목으로 기록하며 일한다 — 15_전체프로세스운영법.law.md 제6조(수집 작업 기록 의무)는 이 원칙을 수집(2단계)에 적용한 구체 사례일 뿐, 적용 범위는 전 업무다.

② 이 4항목은 세션의 _gw/{세션명}.md 기록지 또는 대시보드에 남기고, 매 바이클 종합 요약(③)에 집계·반영한다 — 목표만 세우고 문제점·개선점을 복기하지 않으면 같은 실수가 반복된다.

③ 사소한 업무까지 매번 표를 채우라는 뜻은 아니다 — 발·클 단위로 유의미한 작업(제5조의3⑧의 사전 산정 대상)에 적용한다.

⑤ 대표는 gw/만 열면 그 바이클 전체 현황을 한눈에 파악할 수 있어야 한다 — 개별 세션 문서를 일일이 찾아다니게 해서는 안 된다.

제7조 (실장급 역할 위임 원칙 — 데이터정리실장 신설) 🔴

2026-09-12 확정. 컨텐츠 기획이사(이 세션)는 상시 감시·정리가 필요한 전문 영역을 "실장"급 역할로 위임할 수 있다 — 별도 독립 세션을 새로 띄우는 대신, 위임받는 주체(하위 서브에이전트 또는 지정 세션)가 전담 업무로 수행한다. linux1/linux2운용실장([[reference_linux1_linux2_ops_lead_delegation]])이 이 원칙의 최초 실증 사례였으나 그동안 법률로 명문화되지 않았다 — 이번에 "업무 분장"은 법률 수준 사안이라는 기존 원칙(16_예정사항관리법.law.md 제정 경위와 동일)에 따라 정식으로 법제화한다.

① 위임 요건: 실장급 역할을 신설할 때는 반드시 다음을 갖춘다. 1. 06_업무매뉴얼표준양식법.law.md의 6항목 구조를 따르는 인수인계 문서({역할명}_인수인계.md) — 역할 정의·업무 프로세스·권한 범위· 보고 사항·기본 정보·알려진 과제를 담는다. 2. 소관 범위의 명확한 한정 — 예: linux1/linux2운용실장은 "인프라 건강"만 보고 raker 수집 내용은 소관 밖이듯, 각 실장급 역할은 자기 소관과 소관 밖을 문서에 명시한다. 3. 보고 체계 — 누구에게(통상 컨텐츠 기획이사), 무엇을, 언제 보고하는지 §0-4 형식(linux1운용실장 인수인계 문서 참조)을 그대로 따른다.

② 데이터정리실장 신설(2026-09-12): linux1·linux2에 유입되는 실전 데이터가 bm/a/raw(이미 갖춰진 rag/raw "책꽂이" 구조, 01_데이터구조법.law.md 제7조)의 정 위치에 정갈하게 꽂혀 있도록 상시 정리하는 역할이다.

1. 소관: linux1·linux2로 밀려 들어온 백로그 데이터를 이미 준비된 bm/a/rag/bm/a/raw 구조(책꽂이)의 올바른 위치로 분류·이동한다. linux1/linux2운용실장(인프라 건강)과 역할이 겹치지 않는다 — 데이터 정리 실장은 "어디에 꽂혀 있는가"만 본다.
2. 소관 2: 01_데이터구조법.law.md 제6조⑧-1이 정한 .raker.md 필수 6항목(소스·막힌 이력·raker 변천사·변화 내용·해결 방법·최종 목적지)을 기존 _raker.py 전체에 소급 작성하고, 신규 raker가 생길 때마다 즉시 짝 문서를 채운다 — ⑧-1의 소급 적용 원칙 집행 담당.
3. 인수인계 문서: _hardware/데이터정리실장_인수인계.md.

③ 위임받은 실장급 역할은 §0-4(보고 사항) 형식에 따라 컨텐츠 기획이사에게 보고하며, 컨텐츠 기획이사는 그 보고를 종합해 제5조의4③(바이클 종합 요약)에 반영한다.

제5조 (ChatGPT 등 외부 채널·AI — baikal 제국은 특정 AI 전용이 아니다) 🔴

① baikal 제국의 그룹웨어는 Claude 전용으로 설계되지 않았다 — ChatGPT를 포함해 어떤 AI든 참여할 수 있다. 이 시스템의 실체는 그냥 파일(세션 등록부, 쪽지함 마크다운)이라, 그 파일을 읽고 쓸 수 있는 주체면 누구든 동등하게 세션 등록·쪽지함 교환에 참여한다(2026-09-11 확정, 신규 안내 문서 _gw/_sessions/_공고_AI참여안내.md 참조).

② 파일 시스템에 직접 접근 가능한 외부 AI(예: win1·mb1·m1에서 네트워크 공유로 이 위키 경로에 접근 가능한 ChatGPT)는 제6조의 세션 등록 의무를 Claude 세션과 동일하게 직접 이행한다 — 대리 기록이 필요 없다.

③ 파일 시스템에 직접 접근 못 하는 외부 채널(예: ChatGPT work처럼 고립된 채팅 환경)은 종전대로 _wiki/_gw/_channels/에 같은 형식으로 기록하되, 담당 세션(주로 이 세션)이 대신 기록을 남긴다 — 대표가 내용을 옮겨 전달하는 방식도 가능하다.

제6조 (세션 번호 등록 의무) 🔴

① 모든 세션은 자신의 짧은 호출명과 세션 식별정보를 스스로 정식 등록부 _wiki/_gw/세션등록부.html에 등록한다 — 남이 대신 등록해주지 않는다 (자기 등록 원칙). _wiki/_gw/_sessions/_SESSION_REGISTRY.md는 동기화된 참고용 사본이며 정식 등록부가 아니다. Claude Code 세션 ID나 ChatGPT/Codex thread UUID처럼 긴 식별자는 참고 칸에만 적고 호출명으로 사용하지 않는다.

② 등록 시점: 세션이 새로 시작될 때, 또는 재접속으로 세션 번호가 바뀔 때. 세션 번호·역할명·역할 상세(그 세션이 실제로 맡은 업무 범위를 한두 줄로 구체화한 설명)를 반드시 포함하고, 실행 기기·최초 등록·최근 갱신도 함께 표에 행으로 남긴다.

③ 목적: 대표뿐 아니라 다른 팀장·실장급 세션들이 서로를 찾아 직접 연락을 주고받게 하기 위함이다. 대표가 gw/ 한 곳만 열어도 전체 현황을 파악할 수 있는 것(제5조의4, 바이클 주기 업무 개시·종합 요약 원칙)은 부수 효과일 뿐, 1차 목적은 세션 간 상호 인지·협업이다 — 예를 들어 raker개발팀장이 linux1/linux2운용실장에게 인프라 관련 요청을 하려면, 이 등록부에서 상대 세션의 역할명·세션 번호를 먼저 찾아야 한다.

③-2 등록부 재확인 주기도 제5조의3(바이클 — Baikal 제국 고유 시간 단위)을 따른다 — 매 바이클(발)마다 등록부를 다시 확인해, 새로 등록됐거나 갱신된 세션이 있는지 점검한다. 특히 다른 세션에 연락하기 직전에는 주기와 무관하게 즉시 확인한다.

④ 다른 세션에 연락할 때는 등록부의 역할명을 그 세션의 호출 이름으로 사용한다(세션 간 메시지 전달 도구가 세션을 이름으로 식별하는 경우, 역할명이 실제 세션 제목과 일치해야 연락이 닿는다 — 불일치 시 세션 번호로 대조해 확인한다).

⑤ 이미 등록된 행이 있는 세션은 새 행을 만들지 않고 "최근 갱신" 칸만 갱신한다 — 세션 하나당 행 하나 원칙(중복 등록 금지).

⑥ 등록부의 역할명은 그 세션의 상세 정보 페이지로 링크한다 — 대시보드(제5조의2)가 있으면 그쪽으로, 없으면 _gw/{세션명}.md 기록지로 링크한다. 이름만 봐서는 그 세션이 정확히 뭘 하는지 알 수 없는 경우가 많으므로, 클릭 한 번으로 상세 내용까지 바로 확인할 수 있어야 한다 — 등록만 하고 링크를 걸지 않는 것은 이 조의 불완전 이행으로 본다.

⑦ 쪽지함(비동기 메시지) 원칙: 세션 간 실시간 메시지 전달 도구는 환경에 따라 확실히 동작한다는 보장이 없다 — 대신 등록부에 세션별 쪽지함 파일(_gw/_sessions/{세션명}_msg.md) 링크를 두고, 다른 세션에게 전할 말이 있으면 그 세션의 쪽지함에 날짜와 함께 파일(문서·요청 등)을 첨부해 남긴다. 제5조의4②(매 바이클 gw/ 확인 의무)에 따라 수신 세션이 다음 바이클 이내에 자연스럽게 확인하게 된다 — 실시간 도구 없이도 늦어도 1바이클(3시간) 안에는 전달이 보장된다.

⑧ 쪽지함 기록 형식은 제4조(기록 형식)를 따른다 — - YYYY-MM-DD HH:MM | 보낸 세션 → 받는 세션 | 한두 줄 요약 | (첨부: 경로/파일명). 확인한 쪽지는 지우지 않고 상단에 새 쪽지를 추가한다(누적 기록).

⑨ 빠른 협업 모드: 두 세션 이상이 같은 작업을 긴밀하게 주고받아야 할 때는, 기본 주기(1바이클=3시간)로는 너무 느리다 — 이럴 때는 관련 세션들이 서로 합의한 짧은 주기(예: 10분마다)로 쪽지함을 직접 확인하는 "빠른 협업 모드"로 전환할 수 있다. 진입·종료 시점을 쪽지함에 명시해서(예: "10분 주기 빠른 협업 시작/종료"), 다른 세션이 헷갈리지 않게 한다. 이 모드는 해당 작업이 끝나면 바로 종료하고 기본 주기로 복귀한다 — 상시 10분 주기로 계속 도는 것은 제5조의3⑤(효율 원칙)에 어긋난다(불필요한 반복 확인은 8배 효율에 포함되지 않는다).

⑩ 🔴 역할 유일성 원칙 및 충돌 해소(2026-09-13 명문화): 실질 역할은 복수가 될 수 없다 — 하나의 역할(예: 컨텐츠기획이사)은 정의상 대표가 그 일을 맡긴 단 하나의 세션에만 대응한다("실질 역할이 더블이 될 수는 없다", 2026-09-13). 따라서 두 세션이 동일한 역할명을 동시에 자처하는 상황은 둘 다 진짜일 수 없는 오류 상태이며, 반드시 하나로 정리해야 한다.

판정 기준: 세션 번호(호출명)·세션ID의 선후관계나 일치 여부가 판단 기준이 아니다 — "먼저 등록했다", "예전 세션ID와 같다/비슷하다" 같은 근거는 무효다. 유일한 기준은 대표가 실제로 그 역할을 누구에게 부여했는가다("중요한 것은 세션 기호가 아니라, 대표가 부여한 실질 역할이다", 2026-09-13). 해소 원칙은 상위는 남고 하위가 바꾼다:

1. 대표가 그 역할명을 실제로 지정한 세션(상위)은 역할명을 그대로 유지한다.
2. 그 역할을 대표로부터 부여받은 적 없는 세션(하위)은, 자신이 실제로 수행 중인 업무 내용에 맞는 정확한 역할명으로 스스로 변경해 재등록한다 — 이미 다른 세션이 쓰고 있는 역할명을 계속 자처하지 않는다.
3. 어느 쪽이 실제로 그 역할을 부여받았는지 애매한 경우(예: 양쪽 다 같은 역할을 부여받았다고 주장), 임의로 판정하지 말고 즉시 대표에게 확인을 구한다(feedback_escalate_blockers_to_user 원칙과 동일).
4. 실증 사례(2026-09-13): 컨텐츠기획이사 역할명을 c-c1(맥북, 세션ID ab0f4a75-...)과 c-7d(세션ID a71559e8-...)가 동시에 자처한 충돌 발생 — c-7d는 "c-7b(=c-c1의 이전 호출명)가 재시작되어 새 세션ID를 받은 것"이라 주장했으나, 세션ID 불일치로 별개 세션임이 확인됨. 판정 근거는 메모리 파일 등 정황 증거가 아니라 대표의 직접 발언이다 — 대표가 c-c1에게 직접 부여한 역할은 풀스택 프로그래머(시스템관장자, 11_풀스택프로그래머법.law.md 참조)이며(2026-09-13, "내가 너에게 부여한 역할은 풀스택 프로그래머야"), 컨텐츠기획이사는 같은 세션이 겸하는 부가 타이틀이다. 이 직접 지정에 따라 c-c1이 역할명을 유지하고, c-7d는 실제 수행 업무(Europeana raker 함대 감시, linux1/linux2 인프라 대응, 법률 정비)에 맞는 별도 역할명으로 재등록 요청받음.

⑪ 🔴 ChatGPT/Codex 세션 등록 방법(2026-09-20 명문화): ChatGPT와 Codex 세션도 ①~⑩의 자기 등록·역할 유일성·쪽지함 원칙을 동일하게 따른다. 다만 Claude의 c-7d 같은 런타임 호출명이 자동 제공된다고 가정하지 않고, 아래 규칙으로 사람이 알아볼 수 있는 고정 호출명을 정한다.

1. 호출명 형식은 {실행기기}_g_{짧은역할}로 한다. g는 ChatGPT/Codex 계열을 뜻한다. 예: 맥북에서 콘텐츠 발굴을 담당하는 세션은 mb1_g_content로 등록한다.
2. 호출명에는 공백을 쓰지 않고 영문 소문자·숫자·밑줄만 쓴다. 역할 부분은 한두 단어로 짧게 유지한다. 긴 thread UUID·task ID·세션 URL은 호출명에 넣지 않고 세션 ID(참고) 칸에만 기록한다.
3. 등록 항목은 세션 번호(호출명), 역할명, 역할 상세, 실행 기기, 쪽지함, 세션 ID(참고), 최초 등록, 최근 갱신의 8개 칸이다.
4. 역할명은 대표가 부여한 직책을 쓰고, 역할 상세에는 실제 담당 범위와 조사·개발·실행 중 어디까지 맡는지를 한두 줄로 구체화한다. ChatGPT라는 제품명 자체를 역할명으로 쓰지 않는다.
5. 역할 기록지 _gw/{역할명}.md와 쪽지함 _gw/_sessions/{역할명}_msg.md를 만들고 등록부에서 각각 연결한다. 파일에 직접 접근 가능한 ChatGPT/Codex 세션은 자신이 직접 생성·갱신한다.
6. 같은 역할로 다시 접속한 세션은 새 행을 만들지 않고 기존 행의 세션 ID(참고)와 최근 갱신만 업데이트한다. 실행 기기나 역할이 달라진 경우에만 대표 확인 후 별도 호출명을 정한다.
7. ChatGPT/Codex 세션 간 직접 호출 기능이 없는 환경에서도 호출명은 조직 내 고유 식별자로 유지한다. 실제 연락은 등록부에 연결된 쪽지함을 기본으로 하며, 수신 세션은 제③-2와 제⑦에 따라 확인한다.

실행 사례 자료

이 법의 원칙이 실제로 적용된 사례: