이 화면은 정본 마크다운 스펙에서 다시 만들 수 있는 보기 화면입니다. 정본: 2026-08-27_GRID.OS_3.1_스펙_초안_v0.1.md. 여기서 받은 결정은 즉시 정본에 되씁니다.
3.1이 뭔가 — 3.0을 8/25에 완주한 뒤, 개발 방식을 "선반영 모드"로 바꿨습니다. 정식 빌드를 기다리지 않고 원우님 앱에 바로 반영 → 며칠 써보고 → 괜찮으면 정식 확정(승격)하는 방식입니다. 그래서 3.1의 절반(뇌 개편, 보안 수리 일부)은 이미 원우님 앱에 들어가 있습니다. 이 브리핑은 나머지 절반 — "무엇을 더 넣고, 무엇을 미룰지" — 를 확정하는 자리입니다.
원우님이 체감할 변화 — ① 오케스트레이션 돌릴 때 오르카 앱이 자꾸 다시 뜨는 문제 등 실사용 불편 16건 해소 ② 보안 구멍 2개 봉합 ③ 앱 업데이트 때마다 맥이 권한을 다시 묻는 문제 해소 ④ 뇌(주제별 기억 카드)의 정식 확정.
주요 위험 — 보안 수리가 배포 체계와 얽혀 있어, 잘못 건드리면 배포가 통째로 막힙니다(실제로 한 번 그랬습니다). 그래서 일반 작업과 분리한 전담 배치로 진행하자는 게 핵심 제안입니다.
결정 현황 — 1차 6건(C1~C6)은 08-27 컨펌 완료·정본 반영됨. 원우님 지적으로 누락이 확인된 지침(핵심구조) 시스템 포함 여부(C7) 1건만 추가로 결정해 주시면 됩니다.
| 지금 (internal.19) | 3.1 정식 확정 후 | |
|---|---|---|
| 뇌(기억) | 주제별 요약 카드 생성·주입까지 라이브 — 단, "임시 반영" 상태 | 원우님 "됐다" 확인 + 검증 게이트 통과 → 정식 기능으로 확정 |
| 실사용 불편 | 오르카 반복 실행, 대시보드 숫자 잘림, 창분할 폭 고정 등 16건 잔존 | 16건 순차 해소 (개별 크기가 작아 배치 단위로 빠르게 처리) |
| 보안 | 구멍 2개 파악됨 (아래 4절 C3·C6) — 당장 악용 위험은 낮으나 열려 있음 | 전담 배치로 봉합 + 앱 업데이트 때 권한 재요청 문제도 함께 해소 |
| 그대로 유지 | 일간노트·업무보드·대시보드 사용 방식, 권한 설정(bypass/explicit), 데이터(markdown 정본) — 전부 그대로입니다 | |
3.1에 들어가는 것 (8개 그룹, 약 35건)
3.2로 미루는 것 (약 30건 — 카드 C4에서 동의 여부 결정)
별도 트랙 (3.1과 독립 진행)
C1~C6은 1차 컨펌(08-27)이 그대로 반영돼 있습니다 — 바꾸실 게 없으면 그대로 두세요(다시 누르면 변경됩니다). 새로 결정할 것은 맨 아래 C7 하나입니다. 결정 후 맨 아래 컨펌 버튼으로 전달해 주세요.
뇌 개편(주제별 기억 카드 생성 + AI 대화에 자동 주입 + 뇌 화면)은 이미 원우님 앱에 라이브입니다. 3.1은 이걸 새로 만드는 게 아니라, 며칠 써보시고 "됐다" 하시면 검증 게이트를 통과시켜 정식 버전으로 확정하는 작업부터 시작합니다.
대표 항목: 오르카 앱 반복 기동("가장 큰 문제"로 접수) · 대시보드 화면 좁으면 숫자 잘림 · AI탭 화면분할 폭 조정 불가 · 업무종료(퇴근마감) 버튼 없음 · "명령 실행중" 카드 무한 누적 · 설정에서 기본 AI 모델 지정 불가 등. 각각 크기가 작아 배치 단위로 빠르게 처리됩니다.
구멍 ① 권한 자가승격 — 비유하면, 출입증 검사를 정문에서만 하고 금고문 앞에서는 출입증을 안 봅니다. 권한 표시(마커)를 바꿔치기하면 AI가 사람 승인 없이 전권 모드로 올라설 수 있는 경로가 있습니다. 개발자 도구 수준의 접근이 필요해 당장 위험은 낮지만, 구조적으로 막아야 합니다.
구멍 ② 앱 실행 서명 불안정 — 배포 때마다 앱의 "신분증"이 바뀌어서 맥이 권한(화면 기록 등)을 매번 다시 묻습니다. 원우님이 겪으신 그 반복 팝업이 이것입니다.
왜 전담 배치인가 — 서명 쪽을 지난주에 고치려다 외부 검증(코덱스)에서 3라운드 연속 문제가 나와 배포 라인에서 분리해 둔 상태입니다. "2줄 수정"으로 보였던 게 실제로는 배포 증명 체계 전체와 얽혀 있었습니다. 일반 작업과 섞으면 배포가 통째로 막힐 수 있어, 따로 설계부터 다시 합니다.
지금 3.1의 목표는 원우님 혼자 쓰는 인터널 앱을 빠르게 도는 것입니다. 다른 회사에 파는 판(대행사 에디션)의 설치·온보딩 화면 다수와, 팀원별 로그인 같은 계정 체계까지 넓히면 속도가 다시 느려집니다. 3.0에서 겪었던 템포 저하의 재발 방지이기도 합니다.
뇌 개편의 핵심 목표였습니다: 대화 원문을 그대로 쌓지 않고, 주제 단위로 정리해 저장한다. 지금 카드 20장이 만들어져 있습니다 (아래 5절 시안 A에 현재 모습). 이게 맞는지는 코드로 판단할 수 없고 원우님 사용감이 곧 검증입니다. 앱 뇌 패널에서 확인하실 수 있습니다.
C3가 "따로 뺀다"는 결정이라면, C6은 "어떻게 고칠지"입니다. 임시 잠금(nonce)을 만들어 봤지만 근본 봉합이 아니라는 게 확인돼, 2축으로 다시 설계합니다:
원우님 지적이 맞았습니다. 8/25에 결정 8건을 전건 승인하신 핵심구조 기획(그리드·지침·뇌)에서 지침 트랙은 «설계 → 구현»까지 가기로 확정돼 있었는데, 이 스펙 초안이 "설계 문서 완료" 한 줄만 남기고 구현 범위 분류에서 통째로 빠뜨렸습니다. 바로잡아 다시 올립니다. 빠졌던 본체는:
아래는 판단을 돕는 개념 시안입니다. 실물 UI 시안은 각 배치 착수 때 시안 게이트에서 별도로 컨펌받습니다 (기존 규칙 유지).
이전 방식 대화 원문 나열
원문이 그대로 쌓여 길어질수록 찾기 어렵고, AI 주입 효율도 낮음
지금 (internal.19 라이브) 주제별 요약 카드
주제 단위로 접혀 있어 훑기 쉽고, 다음 대화에 요약만 주입됨
소독 후에도 이렇게 보입니다
| 캠페인 | 지출 | ROAS |
|---|---|---|
| 이미지타입7 | 142,000 | 3.2 |
| 리더 신규 | 98,000 | 2.1 |
표·굵게·목록 등 일반 서식은 전부 유지 — 체감 변화 없음
제거되는 것 (원래 화면에 보이지도 않던 것)
응답 안에 실행 코드가 섞여 들어와도 화면에 그리기 전에 걸러냅니다. 이게 구멍 ①(자가승격)을 막는 두 축 중 하나입니다.
지금 회의록과 녹음이 따로 흩어짐
3.1 제안 회의 폴더에 함께 결속
문제가 생길 수 있는 지점 — ① 보안 수리가 배포 체계와 얽혀 배포가 막히는 경우 (이미 한 번 발생 → 서명 작업을 배포 라인에서 분리해 둔 상태) ② 선반영 특성상 원우님 앱에 바로 반영되므로, 배치 하나가 잘못되면 실사용에 영향.
데이터·환경 보호 — 데이터 정본은 전부 markdown 파일이라 앱 문제와 무관하게 안전합니다. 배포마다 직전 상태 백업이 남고, 원우님 권한 설정(bypass/explicit)이 변하지 않았는지를 매 배포의 필수 확인 항목으로 검사합니다 (internal.19에서 무변 확인 완료).
되돌리는 방법 — 각 배포에 롤백 경로가 준비돼 있습니다 (internal.19 기준 int-deploy-int31-dogfood-c/). 문제가 보이면 말씀만 하시면 직전 버전으로 되돌립니다.
승격 게이트 — 정식 3.1 확정 전에 미뤄둔 무거운 검증(안전 하네스 25종·이중 리뷰·코덱스 교차·시뮬레이션 82종)을 한 번에 정산합니다. 검증을 생략하는 게 아니라 시점을 모아서 하는 것입니다.
동결 기준 — 선반영 브랜치 fable/int31-dogfood HEAD 9ceafe7, 라이브 = 설치앱 3.0.0-internal.19. nonce 커밋은 심층 방어로 브랜치에만 유지, «P0 수리» 명목 배포 금지(internal.20 보류).
스코프 그룹(정본 스펙 §3) — 3.1 포함: V31-D1(실사용 소품)·D2(보안 전담)·D3(게이트 선행 처리)·D4(재확인)·D5(학습부대 문서화)·D6(UI 후속, 시안 게이트 조건부 — 뇌 그래프 뷰 개선 C1 코멘트 등재 포함)·D7(회의록 폴더)·D13(H5 판단, C5 승인으로 닫힘)·D14(지침 시스템 본체 — C7 결정 대기: E-10 승격 큐·E-11 감시 검사 5종·E-15 AI.md 정본·미러·승계 행렬. 온보딩 결속분 E-3·5·6·9는 C4 결정대로 인터널 상품화 트랙 분리). 3.2 이후: D7-def(대행사 온보딩)·D8(UI·정책 세부)·D9(뇌 확장). 별도 트랙: D10(데이터 안전 실측)·D11(계정 체계 설계)·D12(성능·구조부채).
보안 재설계 2축(카드 C6) — 축 ①: 권한 소비자(터미널·오케스트레이터·컴퓨터유즈)가 bypass 실행 직전 origin=explicit 재확인 (마커는 생산자단 표시일 뿐이라는 원칙). 축 ②: AI 응답 HTML 렌더에 허용목록 기반 sanitize 도입. 설계 단계부터 코덱스 교차 (§0-10). 서명은 attestation 통합설계 v0.1 기반 별도 구현 배치.
승격 게이트 체크리스트(정본 스펙 §4-2) — 실패 테스트 13건 + dash-widget-loader-packaging-contract + settings-runtime(.c-center) 판정/수리, 뇌 게이트 17/17 재확인, perm 설정 무변 재확인, C5(H5) 원우 확인, 보안 배치 완료 여부 판정.
검증 절차 — 안전 하네스 25/25(3전제: detached 체크아웃·owner token·node_modules 없음), F71 sim-harness 82종(매 빌드 코드 강제), build-app.sh boot-smoke, deployment.js root inode 보존, 정확 경로 open. 이중 리뷰 + 코덱스 이종 교차는 누적 diff 전체 대상 1회.
결정 기록 계약 — 이 화면의 카드 ID(C1~C6)는 정본 스펙 md «결정 기록» 테이블과 tools/check-spec-approval.js로 자동 대조됩니다. 컨펌 결과는 즉시 정본에 되쓴 뒤에만 개발 시작으로 간주합니다.