이 화면은 정본 마크다운 스펙에서 다시 만들 수 있는 보기 화면입니다. 정본은 2026-08-16_인터널_2.1.1_스펙.md.
D401 재승인 완료 — 코덱스 반대 검토(스펙 평의회)로 바뀐 범위·시간(L3 재분류·클린룸 패키지 전수 스캔·16~20h·2트랙 파이프라인)까지 포함해 원우님이 다시 승인하셨습니다. 5건 전부 확정 상태입니다.
추가 반영(같은 날) — 개발 운영방식 정본 R8(원우 결정)에 따라, 내부 채널의 봉인(F83) 감사를 배포 관문에서 빼고 배포 뒤 비동기로 옮겼습니다. §5·§8에 반영돼 있습니다.
v1.2에서 바뀐 것 (코덱스 반대 검토 반영)
· 규모 재분류: L2 → L3 — DMG·이관·설치/롤백을 포함한 버전은 정본상 L3다. 설치·덮어설치·롤백에 데이터 보호 계약(무엇을 지키는지·어떻게 확인하는지·실패하면 어떻게 되돌리는지)을 문서로 남긴다
· 클린룸 범위 확장: 알려진 8건 + 패키지 전수 스캔(설치 파일 안까지 원우님 개인정보 흔적 검사) + 직원 두 계정 교차 확인(서로 안 섞이는지)
· 검증 환경 문구 통일: 이 맥의 새 macOS 계정에서 실제로(시뮬레이션 아님)
· 안전장치 보강: 페이블 검토는 이제 "괜찮음/보류"를 명시적으로 남겨야 하고(말 없으면 진행 아니라 대기), 코덱스가 대기하는 시간에 실제 12시간 제한을 걸었고, 준비 단계가 실패하면 착수 안 함 신호(NO-GO)를 명확히 만들었습니다
· 예상 시간: 13~16h → 16~20h(2.1에서 실제로 겪은 재작업 여유분 반영), 벽시계 기준 하루반~이틀
왜 만드는가 — 2.1(v2.1.0-internal.1)은 원우님이 매일 쓰는 리뷰 빌드로 이미 배포됐고, 그 뒤 빠른 확인·수정 왕복(고속 루프)까지 한 차례 더 돌았습니다. 2.1.1은 그 다음 단계 — 직원 4~5명에게 실제로 나눠줄 수 있는 배포 패키지를 만드는 일입니다.
사용자의 무엇이 달라지는가 — ① 직원용 신규 그리드 첫 화면에 원우님 개인 정보(클라이언트명·개인 위젯 등)가 하나도 안 보이는지 최종 확인(클린룸) ② 직원이 실제로 앱을 다운로드해 설치할 수 있는 DMG 파일 + 암호로 보호된 다운로드 링크 ③ 새로 그리드를 만들 때 온보딩이 처음부터 끝까지 실제로 되는지 확인.
예상 시간 — 파트별 합계 약 16~20시간(v1.2 재산정 — 2트랙 파이프라인 P1→P3 / P2→P4), 벽시계 기준 하루반~이틀 목표(§2) · 진행 방식 — 코덱스가 지휘하고 페이블이 파트 경계마다 확인(§5) · 결정 상태 — 5건 중 4건 확정, D401 1건만 재승인 필요
| 파트 | 내용 | 시간(v1.2) | 담당(실편성) |
|---|---|---|---|
| ⓪ | 고속 루프 마무리 + 전체 관문 + internal.3 배포 | ~1.5h | 페이블 단독 |
| P1 | DMG 패키징 | 3~4h | 코덱스 Terra 구현 → 클로드 Sonnet 검증 |
| P2 | 클린룸 검증(8건 + 패키지 전수 스캔) | 4~5h | 코덱스 자동 전수 + 클로드 워크스루 2인 |
| P3 | 설치 시나리오 3종 + 데이터 보호 계약 문서화 | 3h | 코덱스 Terra → 클로드 검증 |
| P4 | 온보딩 검증 + 배포 허브 페이지 + 직원 A/B 교차오염 검증 | 4~5h | 클로드+코덱스 독립 2진 + 클로드 가이드 집필 |
| P5 | 고속 루프 필수 4건 배치(잔여 7건은 시간 될 때) | 1~2h | 클로드 구현 → 코덱스 검증 |
합계 약 16~20시간(파트 합산 그대로 — 2.1에서 실제로 반복됐던 검증 라운드·재작업 여유분이 P2·P3·P4에 반영돼 있습니다). 2트랙 파이프라인으로 진행합니다 — 트랙 A(P1→P3, DMG→설치검증)·트랙 B(P2→P4, 클린룸→온보딩+배포허브)가 서로 겹치고, 트랙 안에서는 순서대로 갑니다("전부 병렬"이 아니라는 걸 v1.2에서 분명히 했습니다). 벽시계 기준 하루반~이틀이 목표입니다. ⓪은 페이블이 먼저 끝내는 선행 작업이고, 코덱스는 그 신호(GO 파일)를 받은 뒤에만 P1부터 시작합니다.
동시성 계약(v1.2) — 코덱스 동시 작업 상한 2(헤드 포함 3 프로세스 이하), 클로드 워커 동시 상한 2. 이 상한을 넘는 편성은 진행하지 않습니다.
이번 버전에 들어가는 것
들어가지 않는 것 — 이미 끝났거나(2.1) 다른 시점 몫
D401~D405 전부 원우님이 승인하셨습니다(카드가 잠겨 있음 — 참고용 기록).
결정 카드의 data-decision-id는 정본 스펙 결정 테이블의 D401~D405와 1:1로 대응합니다.
이 편성은 새로 만든 규칙이 아니라, GRID.OS 개발 운영방식 정본(§04 조직·모델 편성)이 원래 정해둔 방식을 이번 스트림에 그대로 적용한 것입니다.
지휘 — 빌드 대장은 코덱스(Sol high~xhigh). 정본이 "전수조사·증거 결속·이관·패키징처럼 기계 정밀함이 중심인 스트림은 코덱스가 지휘"라고 이미 정해둔 조건과 이번 작업(DMG 패키징·클린룸 전수 검사·설치 검증)이 그대로 맞습니다. 페이블은 감리 — 지휘가 아니라 검문입니다. 두 헤드가 동시에 실행을 판단하는 구조가 아닙니다(정본이 "지휘 이원화 금지"를 명시).
| 파트 | 만드는 쪽(writer) | 검사하는 쪽(verifier) |
|---|---|---|
| ⓪ 선행 작업 | Claude 페이블(헤드 직접) | — (현행 유지) |
| P1 DMG 설치판 | Codex Terra | Claude Sonnet |
| P2 클린룸(8건+패키지 전수 스캔) | 자동 검사 전수 = Codex | 사람 확인 1회 = Claude 2인 분리(기능+화면) |
| P3 설치 시나리오 + 데이터 보호 계약 | Codex Terra | Claude Sonnet |
| P4 온보딩 검증 + 직원 A/B 교차오염 | Claude 1 + Codex 1 독립 2진 | 서로 다른 결과 비교 |
| P4 배포 허브 페이지(다운로드+소개+가이드) | Claude(쉬운 말 강점) | — |
| P5 피드백 배치 | Claude Sonnet/Opus | Codex 읽기 전용 |
| 역할 | 담당 | 구체 임무 |
|---|---|---|
| 제품 통제부 | 코덱스 헤드 겸직(경량) | 진행 중 들어오는 원우님 피드백을 접수해 4갈래(지금 빌드 막을 문제 / 이번 빌드에 교환 가능 / 다음 버전 / 조사 필요)로 나눕니다. 결정은 하지 않습니다 — 채택 여부는 코덱스 헤드가 정합니다. |
| 통합 관제 | 헤드 직속(코덱스 주도) | P1~P5 산출물을 합치고, 소유 파일·계약 위반이 없는지 기계적으로 대조합니다. |
| 개발 학습부대 | 경량 겸직(코덱스+클로드) | 이번 스트림 진행 데이터를 실시간 기록합니다 — 파트별 실제 걸린 시간, 검증에서 되돌아온 횟수, 막힌 사건. 스트림이 끝난 뒤 회고의 재료가 됩니다(2.1 회고와 같은 방식). |
| 페이블 감리 | Fable 단독 | 파트 경계마다 체크포인트를 가볍게 확인하고, 관문(빌드 확정·배포) 승인 파일을 발급합니다. 봉인(F83) 감사는 관문이 아닙니다 — 배포 뒤 비동기로 따로 돕니다(아래 R8 안내). |
스펙 평의회 — 이종 반대 검토: 완료, 반영됨
정본은 "스펙 확정 전 헤드와 다른 회사 모델의 독립 검토 1회가 필수"라고 정해 두었습니다. 이 스펙은 클로드가 작성해서 코덱스 반대 검토가 필요했고, 결과(HIGH 15건·MED 3건, 총 18건)가 나와 헤드가 선별해 이번 v1.2에 반영했습니다.
절차 교훈 — 이 검토는 원래 승인 전에 끝났어야 하는데, 이번엔 승인 후에 도착해 D401 재승인이 필요해졌습니다. 다음 스트림부터는 순서를 고칩니다(브리핑 발송 전 필수 관문으로).
⏱️ 한도 게이트(배치 시작마다 필수 확인)
· 코덱스 — 주간 사용량 80%부터 효율 모드, 90%부터 정지선
· 클로드 — 남은 한도 80% 소진 시 체크포인트 우선 모드
· 동시성 상한(v1.2) — 코덱스 동시 2(헤드 포함 3 프로세스 이하)·클로드 워커 동시 2. 이 확인을 통과하지 못하면 분대를 늘리지 않습니다
· 지금 상황 — 페이블·클로드 쪽 한도가 빠듯해서, 페이블은 선행 작업과 감리에만 관여하고 실제 작업은 여유 있는 코덱스가 맡습니다. 규모는 v1.2에서 L2 → L3로 재분류됐지만(설치·롤백에 데이터 보호 계약 추가), 상설 역할은 여전히 겸직으로 충분합니다 — L3가 요구하는 건 writer 분대 다중 편성이지 통제부·학습부대 같은 상설 모자를 늘리라는 뜻이 아닙니다.
이번 스트림은 코덱스가 실제 작업을 주도합니다. 대신 안전판 두 겹을 둡니다 — ① 각 파트가 끝날 때마다 페이블이 가볍게 한 번씩 확인(문제 없으면 그냥 넘어감) ② 되돌리기 어려운 일(실제 빌드 확정·실제 배포)은 페이블이 "승인 파일"을 직접 만들어주기 전엔 코덱스가 손대지 못합니다.
R8 반영 — 봉인(보안) 감사는 배포 뒤로 옮겼습니다(2026-08-16 원우 결정)
오늘 ⓪ 실측에서 보안 봉인 정산이 배포 전 검증 과정에서 4시간 넘게 걸린다는 게 확인됐습니다. 원우님 혼자 쓰는 내부용 빌드에는 이 정도 대기가 위험도에 비해 과하다고 판단해, 봉인 감사를 배포를 막는 관문에서 뺐습니다. 대신 배포가 끝난 바로 다음 순서로 코덱스가 자동으로 감사를 돌리고, 발견되는 보강 사항은 사람이 따로 정리하지 않아도 차기 백로그 파일에 자동으로 쌓입니다 — 다음 버전을 시작할 때 그 목록을 보고 반영 여부를 정하시면 됩니다. 원우님 개인정보가 새는지 확인하는 클린룸 검사는 이 변경과 상관없이 그대로 배포 전에 확인합니다.
원우: 시동 프롬프트 실행 → 퇴근
│
▼
[코덱스] GO/NO-GO 대기 (최대 12시간, 아직 시작 안 함)
│
├─ NO-GO 감지 ──▶ 착수하지 않고 종료(⓪ 실패)
├─ 12h 경과 ──▶ BLOCKED 기록 후 종료
│
▼ (페이블: 고속루프 마무리 → 전체 관문 → internal.3 배포)
GO 파일 생성
│
▼
[코덱스] P1 실행(자유 — 아직 관문 없음) ──▶ 체크포인트 기록
│ │
│ [페이블 검토] ──▶ PASS 또는 HOLD 파일 필수(무응답=대기)
▼ │
PASS 확인 → 그 DMG를 출시 후보로 확정(빌드 관문 승인) → P2 실행 ──▶ 체크포인트
│ │
│ [페이블 검토] ──▶ PASS/HOLD
▼
… P3(확정된 DMG 사용) → P4 → P5(같은 패턴 반복) …
│
▼
배포 관문 ──▶ 페이블 승인 파일 없으면 대기(페이블 확인 후 승인)
│
▼
[코덱스] 배포 실행 → 완료 보고
│
▼ (비동기, 배포를 막지 않음 — R8)
[코덱스] 후단 감사 실행 → 발견 항목 차기 백로그에 자동 등재
│
▼
페이블 최종 확인 → 종료
v1.2에서 바뀐 점: 페이블 검토는 이제 "말 없으면 통과"가 아니라 PASS/HOLD를 명시해야 합니다. "빌드" 관문은 P1 자체를 막지 않고, P1이 만든 결과물을 출시 후보로 확정하는 시점에만 걸립니다(자체 검증에서 발견된 순환 대기 문제를 이렇게 풀었습니다). 봉인(보안) 감사는 배포 뒤로 옮겨져 더 이상 관문이 아닙니다(R8).
위 §4에서 D401만 다시 골라 주세요. 재승인되면 코덱스 세션에 §8(이 화면 하단)의 시동 프롬프트를 붙여넣고 실행한 뒤 퇴근하시면 됩니다 — 실제 작업은 페이블이 선행 작업(⓪)을 끝낸 뒤 자동으로 시작됩니다.
문제가 생길 수 있는 지점 — 버전 번호를 새로 매길 때 4곳(앱 버전 라벨·lock 파일·테스트 DMG 스크립트·빌드 라벨) 중 하나를 놓치면 배포 직전에 실패가 뜰 수 있음(2.1에서 실제로 1곳을 놓쳤던 적이 있어 이번엔 체크리스트로 미리 막습니다). 관문(빌드 확정·배포, 조건부로 봉인) 앞에서 페이블 승인 파일이 없으면 코덱스가 거기서 멈춥니다 — 오작동이 아니라 설계된 안전 정지입니다. v1.2 보강 — 페이블이 "괜찮다"는 말을 깜빡해도 예전엔 조용히 통과됐는데(자체 코덱스 검증이 지적한 허점), 이제는 명시적으로 PASS/HOLD를 남겨야만 다음 파트로 넘어갑니다.
사용자 데이터 보호 — 원우님 그리드 데이터·업무 정본은 이번 스펙에서 전혀 건드리지 않습니다. 직원용 신규 그리드만 대상입니다. v1.2 보강 — 설치·덮어설치·롤백 전 과정에서 무엇을 지키는지(그리드 markdown·앱 설정·스냅샷)와 실패 시 되돌리는 절차를 문서로 남기는 걸 이번 스트림의 정식 산출물로 넣었습니다(규모 L3 재분류에 따른 요구사항).
되돌리는 방법 — DMG는 이전 버전 DMG를 재설치하는 방식으로 되돌립니다(그리드 데이터·설정이 실제로 보존되는지까지 실기로 확인). 원우님 기기는 기존과 같은 방식(canonical 재승격)으로 되돌립니다. 준비 단계(⓪)가 실패하면 코덱스는 아예 착수하지 않고 조용히 종료합니다(NO-GO 신호, v1.2 신설) — 어중간하게 시작했다가 막히는 상황을 원천 차단합니다.
정본 — 2026-08-16_인터널_2.1.1_스펙.md. 시동 프롬프트 전문은 이 화면 §8에도 그대로 있습니다(복사 버튼 포함).
있는 것(재사용) — 오프라인 격리 빌드 스크립트, 테스트 DMG 생성기(만들 수 있다의 증거는 이미 있음, 배포용 UX만 추가), 부팅 스모크 게이트, 신규 그리드 표준 시드, 온보딩 최소 강제 계층(F1~F8) — 전부 이미 구현돼 있습니다.
새로 만드는 것 — 실제 배포용 DMG(Applications 드래그 설치 UX), 신규설치·덮어설치·롤백 3종 실기 하네스, 온보딩 실행 가능한 회귀 게이트(또는 수동 체크리스트), 암호 보호 다운로드 페이지, 버전 범프 4곳 동시 확인 절차.
체크포인트·관문 파일 경로 — .gridos/GO-2.1.1.md(착수 신호), .gridos/GO-2.1.1-checkpoints/CHECKPOINT-P<N>.md·REVIEW-P<N>.md·APPROVE-SEAL.md·APPROVE-BUILD.md·APPROVE-DEPLOY.md.
아래 전문을 그대로 코덱스 앱 세션(워크스페이스 = 그리드 루트, 승인 모드로 실행 가능한 수준)에 붙여넣으세요. 코덱스는 받는 즉시 GO 파일 대기 루프만 시작하고, 실제 착수는 페이블이 선행 작업을 끝낸 뒤 자동으로 이어집니다.
너는 지금부터 GRID.OS 인터널 2.1.1 스펙 실행 헤드다(Sol, high~xhigh 추론 강도).
이번 스트림은 "코덱스 지휘 + 페이블 감리" 구조다 — 네가 실행을 주도하되,
파트 경계마다 페이블이 검토하고 관문급 행위는 페이블 승인 없이는 절대
넘어가지 않는다. 아래 순서를 정확히 그대로 따른다 — 순서를 건너뛰거나
미리 착수하지 마라.
1. 대기(필수, 먼저 이것부터): 아래 스크립트를 bash 도구로 직접 실행해라.
GO 파일·NO-GO 파일 둘 다 감시하고, 최대 12시간 뒤에는 스스로 종료한다
(문서상의 타임아웃이 아니라 실제로 도는 코드다).
GRID="/Users/oneu.choi/grids/CHOI-WONWOO"
GO_FILE="$GRID/.gridos/GO-2.1.1.md"
NOGO_FILE="$GRID/.gridos/NO-GO-2.1.1.md"
CKPT_DIR="$GRID/.gridos/GO-2.1.1-checkpoints"
DEADLINE=$(( $(date +%s) + 12*3600 ))
mkdir -p "$CKPT_DIR"
while true; do
if [ -f "$NOGO_FILE" ]; then
echo "NO-GO 감지 — 착수하지 않고 종료합니다"
cat "$NOGO_FILE"
exit 0
fi
if [ -f "$GO_FILE" ]; then
echo "GO 파일 감지 — 착수 시작"
break
fi
if [ "$(date +%s)" -ge "$DEADLINE" ]; then
echo "BLOCKED_BY_TIMEOUT — 12시간 동안 GO/NO-GO 파일이 생기지 않았습니다" \
> "$CKPT_DIR/BLOCKED-TIMEOUT.md"
echo "12h 타임아웃 — 종료합니다"
exit 1
fi
sleep 30
done
매 폴링마다 NO-GO를 GO보다 먼저 확인해라(안전 방향 우선 — 매뉴얼
§6-⑤). 이 파일들이 생기기 전에는 스펙을 읽지도, 착수 판단을 하지도
마라 — Fable이 아직 고속 루프 마무리·전체 관문·internal.3 배포를
끝내지 않았을 수 있다. NO-GO가 뜨면 ⓪이 실패했다는 뜻이니 재시도하지
말고 그대로 종료해라. 12h 타임아웃으로 종료했다면 BLOCKED-TIMEOUT.md를
남긴 채로 끝내고, 재실행은 원우가 이 프롬프트를 다시 붙여넣을 때만
한다.
2. GO 파일이 생기면 그 파일을 Read해서 스펙 경로·착수 지시·태스크 노트
경로를 확인한다.
3. 스펙 정본(기본 경로: "03. AI 사업/02_상품개발/GRID.OS/01_기획·명세/
03_인터널에디션/2026-08-16_인터널_2.1.1_스펙.md")을 Read하고
D401~D405 확정 내용을 그대로 따른다. D401이 브리핑에서 조건부
승인으로 바뀌어 있으면 그 조건도 반드시 반영한다.
4. §1 파트·시간표대로 진행한다 — ⓪(선행 루프 마무리·관문·internal.3)은
Fable이 이미 끝낸 상태이니 P1부터 시작한다. P1(DMG 패키징) 자체는
아직 아무 승인도 필요 없다 — 자유롭게 반복 빌드·조정해라(6번 참고,
관문은 "확정" 시점에만 걸린다).
5. 체크포인트·검토 규약(스펙 §6-④, 매 파트 필수 — N=1~5):
a. 파트를 끝낼 때마다 ① 태스크 노트 "## 진행 기록"과
② ".gridos/GO-2.1.1-checkpoints/CHECKPOINT-P<N>.md" 두 곳에
체크포인트를 남긴다. 무엇을 했는지·무엇을 확인했는지·다음 파트로
넘어가도 되는 이유를 구체적으로 쓴다(Fable이 그대로 이어받을 수
있을 만큼).
b. 다음 파트를 시작하기 **전에** 반드시 아래 둘 중 하나가 있는지
확인한다 — ".gridos/GO-2.1.1-checkpoints/REVIEW-P<N>-PASS.md"
(통과, 진행해도 됨) 또는 "...-HOLD.md"(교정 필요). **둘 다 없으면
대기해라 — v1.1의 "부재=이견없음"은 폐기됐다.** PASS면 그대로
진행, HOLD면 지시를 반영한 뒤 재체크포인트 → 재검토를 받는다.
c. **절대 스스로 건너뛰지 마라**: PASS 파일 확인 없이 다음 파트로
넘어가는 것은 이 규약 위반이다. 오래 응답이 없으면 태스크 노트에
"🔴 Fable 소환 필요 — REVIEW-P<N> 무응답"을 남기고 계속 대기한다
(임의로 진행하지 않는다).
6. 관문 잠금 — 2종, 부재 = 대기(예외 없음). **봉인(F83/action-manifest
감사)은 여기 없다 — v1.2에서 관문에서 빠졌다(9번 앞 새 규칙 참고).**
a. **빌드 확정** (".gridos/GO-2.1.1-checkpoints/APPROVE-BUILD.md") —
P1 자체는 이 승인이 필요 없다. 이 승인이 막는 것은 "P1이 만든
특정 DMG를 이번 스트림의 출시 후보로 확정해서 P3 설치 검증과
최종 배포가 그걸 쓰게 하는 것"이다. P1 완료 → CHECKPOINT-P1 →
REVIEW-P1-PASS.md 확인 후에만 그 DMG에 대해 APPROVE-BUILD.md를
기다린다. 이 파일이 생기기 전에는 P3에서 그 DMG를 "확정본"으로
쓰지 마라(P1 안에서 계속 빌드해보는 것 자체는 막지 않는다).
b. **배포** ("APPROVE-DEPLOY.md") — R2 업로드·Worker 게시·DMG
실배포 전환. P4·P5 완료 + §5 검증 계획 통과 후에만 요청한다.
c. 위 두 파일이 없으면 그 행위 앞에서 멈추고 태스크 노트에
"🔒 관문 대기 — <관문명> 승인 파일 없음"을 남긴 뒤 대기한다.
7. 원우 승인이 새로 필요한 판단(스펙에 없는 새로운 결정)이나 막히는
문제가 생기면 진행을 멈추고 태스크 노트에 "🔴 Fable 소환 필요"와
사유를 남긴 뒤 대기한다 — 임의로 계속 진행하지 마라.
8. 이종 교차 검증(R7)은 클로드 검증단이 맡는다. 네가 만든 코드를 네가
검증해서 끝내지 마라 — 검증이 필요한 지점에서 명확히 "클로드 검증
대기" 상태로 표시하고 넘어간다.
9. **배포 직후, 후단 감사(P0) — 개발 운영방식 정본 R8, 원우 결정
2026-08-16 새벽 반영.** APPROVE-DEPLOY 실행 직후, 다음 무엇도
기다리지 말고 곧바로 실행해라: F83/action-manifest 봉인 정산 감사를
오늘 ⓪에서 만든 재봉인 스크립트를 도구화해 돌린다(경로는
검증 게이트 보강안 "A. 재봉인 자동화 도구" 참조 — 태스크 노트에서
찾아라). 이 감사는 **배포를 막지 않았고, 지금도 아무것도 막지
않는다** — 그냥 도는 것이다. 발견된 보강 항목은 네가 직접 고치지
말고, 사람이 분류하지 않도록 자동으로 ".../03_인터널에디션/
차기-백로그.md"에 그 파일이 정한 형식대로 append해라. 감사 결과
요약(정상 또는 발견 N건)을 태스크 노트에 한 줄 남긴다.
10. 완료 조건: §5 검증 계획 1~6 전부 통과 + P1부~P5부 전부 체크포인트
기록 완료 + PASS 파일 전부 확보 + 관문 2종(빌드확정·배포) 전부
APPROVE 파일 확보 + 후단 감사(P0) 실행·차기-백로그 반영 완료.
다 끝나면 태스크 노트에 최종 요약을 남기고 Fable을 소환한다.