GRID.OS 인터널 — 신규 유저 온보딩 기획

이 주제는 오늘 처음 나온 게 아닙니다. 2026-07-28~29에 "팀원이 기존 볼트를 들고 올 때 어떻게 할까"를 이미 설계했고, 그때 나온 F1~F8 최소 강제 계층(코어 지침 블록·업무보드 스켈레톤·스냅샷 안전망 등)은 실제로 구현돼 지금도 동작하고 있습니다.

그런데 그 설계 문서 자체가 이렇게 적어뒀습니다 — "시나리오 N은 기존 create-grid(personal) 경로 그대로 안내", 그리고 미룸 목록에 "원우 구조 '부분 이식' 선택 UI". 결정표에는 "K=최소 강제+불가침 / N=템플릿 풀 이식 (A/C 계열, B 배제)"라고 명시돼 있습니다 — "완전히 구조 없는 자료 더미"는 그때 의도적으로 범위 밖으로 뺐습니다.

이 문서는 그 "미룸" 항목을 정식으로 집어드는 후속 기획입니다.

판정 방식 — 이진, 스캔·제안 없음

server/index.js의 GRID_MARKERS·gridIsComplete()·looksLikeGrid()(약 308~320행)는 마커 존재 여부만 보는 이진 판정입니다. /api/setup/pick-grid·/api/setup/set-grid 둘 다 통과하면 연결, 실패하면 그 자리에서 거부합니다. 부분 일치 점수, "이렇게 보강하면 연결됩니다" 제안 화면 — 어느 것도 없습니다.

Type C — 유일하게 완전히 동작하는 경로

/api/setup/create-grid(6316~6424행) 전체를 확인했습니다. personal 모드는 승인 없이 누구나, 폴더 선택창조차 없이 os.homedir()에 바로 시작합니다. grid-seed-installer.js가 seed/core/**를 결정적 ZIP으로 심고 gridIsComplete()로 재검증합니다.

시드는 실제로 중립입니다 — seed/core/CLAUDE.md(19줄)를 직접 열어 확인했습니다. "마케팅 대행사" 같은 언급 0건, 영문 범용 문구뿐입니다. 대행사 페르소나가 하드코딩된 sample-grid-personal/CLAUDE.md는 현재 어떤 경로에서도 실제로 심어지지 않는 죽은 참조 자산입니다(연구 중 이 사실을 먼저 못 보고 "시드가 대행사 편향"이라 잘못 결론 내릴 뻔했습니다).

다만 개인화가 0%입니다 — 온보딩 질문 7개(onboarding-questions.js)의 답변은 .gridos/onboarding-answers.json에만 저장됩니다. 시드 설치 코드 전체를 grep했지만 이 답변을 읽는 지점이 없습니다 — 무엇을 답하든 심어지는 그리드 내용은 항상 똑같습니다.

Type A — 이진 거부, 중간 지대 없음

GRID.OS 마커를 우연히 갖고 있지 않은 일반 옵시디언 볼트(대부분의 실제 케이스)는 그 자리에서 거부되고 끝입니다. 무엇이 부족한지, 어떻게 하면 되는지 안내가 코드상 없습니다.

onboard-wizard.js:785~790을 직접 읽었습니다. adopt_mode 질문에 "표준 구조로 새로 시작"을 답해도, 코드 주석 그대로 "이번 범위에서는 안전한 기본값(keep)으로 설치"하고 "설정 › 그리드에서 직접 진행해 주세요" 안내만 띄웁니다. 의도를 묻는 질문은 있지만 그 답으로 실제로 뭔가 해주는 코드는 없습니다.

실증 사례 — 원우 자신의 2026-07-28 그리드 컷오버가 정확히 이 상황이었는데, 쓴 방법은 이 제품의 어떤 온보딩 기능도 아니라 AI 세션과 함께한 수동 작업이었습니다. 제품을 만드는 사람 본인이 제품이 지원하지 않는 방식으로 자기 마이그레이션을 했다는 것이 가장 직접적인 증거입니다.

Type B — 지원 경로 0건 (3중 확인)

세 가지 독립 근거로 확정했습니다.

1. 유일한 후보 기능이 온보딩 이전엔 도달 불가 — /api/import/pick+/api/import/copy+legacy-data-migration 스킬은 구조상 B가 필요로 하는 것과 거의 일치하지만, "이미 연결·시딩된 그리드 안의 채팅"에서 AI가 [[import]] 토큰을 출력해야만 나타나는 버튼입니다. 그리드가 아직 없으면 도달 방법이 없습니다.
2. 프레이밍이 전부 "클라이언트 이식" — 스킬 설명·버튼 라벨·분류 대상 폴더 전부 "이미 대행사 그리드를 쓰는 사람이 새 거래처 자료를 들여온다"는 전제입니다. "personal" 변형조차 문구를 그대로 물려받았습니다.
3. 설정 화면에 노출 0건 — settings-internal.js(1,154줄)를 grep했지만 관련 UI가 0건입니다. 채팅 중 AI가 알아서 토큰을 뱉어야만 발견되는 은닉 기능입니다.

결론 — Type B 유저가 오늘 처음 열면 create-grid(빈 그리드) 아니면 pick-grid(거부됨) 둘 중 하나만 만납니다. 자기 업무 폴더를 구조화해서 넣는 방법은 온보딩 어디에도 없습니다.

A — 기존 그리드 감지 → 검증 → 비파괴 연결

이진 판정 대신 부분 일치 점수를 매기고, 완전 불일치는 B 흐름으로, 부분 일치는 "구조 진단" 화면(있는 것/추가하면 되는 것)을 보여주고 승인받습니다. 승인 시 이미 구현된 F1~F8 core-block 설치 메커니즘을 그대로 재사용해 부족한 부분만 additive로 채웁니다.

신규: 부분 일치 점수화 · 구조 진단 화면 1개 · additive 설치 프리뷰(기존 로직 재사용). 난이도: 중 — 핵심 인프라가 이미 있어 주로 UI+판정 작업.

B — 업무 폴더 스캔 → 구조 제안 → 이식 마법사

create-grid에 personal/team 외 세 번째 선택지 "기존 자료로 시작"을 추가하고, legacy-data-migration 스킬 절차(스캔→분류계획→20개 이상이면 승인→이식→원본 보존)를 "클라이언트" 프레이밍을 뺀 일반형으로 다시 씁니다. 이미 있는 두 시스템(F84 시드 설치 + import 복사 엔진)을 온보딩이라는 새 진입점 하나로 이어 붙이는 작업이지, 밑바닥부터 새로 만드는 게 아닙니다.

신규: create-grid 3번째 모드 · 온보딩에서 도달 가능한 import 재배선 · 스킬의 범용 버전 · 분류 계획 승인 화면. 난이도: 가장 높음 — 세 시스템 통합, 전용 스펙 필요.

C — 시드 개인화 보강

온보딩 답변이 실제로 시드 내용에 반영되도록 resolvePackSelection(현재 ['core'] 고정)을 답변 기반으로 확장합니다. sample-grid-personal을 죽은 참조로 방치하지 않고, role=마케팅 대행 답변 시 제안하는 선택형 "대행사 팩"으로 재활용합니다.

신규: 답변→팩 매핑 · sample-grid-personal 재포장. 난이도: 낮음 — 다중 팩 선택 메커니즘이 이미 있어 값만 고정 해제하면 됩니다.

2.1.1의 P4부("온보딩 검증 + 배포 허브 페이지 + 직원 A/B 교차오염 검증")는 신규 직원이 그리드를 처음부터 끝까지 직접 만들어보는 실측입니다. 신규 입사자는 거의 항상 Type B(회사 자료는 있지만 그리드 구조는 없음) 아니면 Type C(완전 신규)입니다 — Type A는 드문 케이스입니다.

• P4의 실측 결과(어디서 막히는지·얼마나 걸리는지·무엇을 헷갈리는지)가 이 문서 §2의 서술을 실사용자 데이터로 검증·보강하는 입력이 됩니다.
• 이 문서 §3이 채택되면, 다음 P4류 검증이 개선 대상이자 재검증 대상이 됩니다 — 순환 관계입니다.
• 배포 허브 페이지는 지금 "설치→첫 실행→온보딩→첫 대화"만 안내합니다. 이식 마법사가 실제로 만들어지기 전까지는 "먼저 자료를 폴더 하나로 모아두면 다음 버전에서 더 쉬워진다" 정도의 임시 팁만 넣고, 기능이 붙으면 실제 화면 캡처로 교체합니다.