GRID.OS 전 에디션 커스텀 × 업데이트 운영·판매 전략

• 9/3 — "기업 고객은 앱 속을 못 건드리게 한다"는 원칙과 "그리다 팀은 커스텀 내역을 공유해야 한다"는 원칙을 먼저 정했습니다.
• 9/7 — 그리다·엔터프라이즈·퍼스널 3종 상품 구분을 확정했습니다.
• 9/10 — 팀원(김승일님)이 앱 코드 파일 9개를 직접 고쳐 쓰고 있다는 사실이 드러났습니다. 지금 겪는 "충돌 화면"이 여기서 시작됐습니다.
• 9/11~13 — "위젯·스킬은 부품처럼, 본체 수정은 별도 관리"라는 아이디어를 처음 설계했습니다. 다만 그때는 검증 전 계획이었습니다.
• 9/21~26 — 원우님 앱을 새 버전으로 옮기는 작업 8번 중 5번이 충돌했습니다. 9/26엔 "이미 반영됐겠지"라는 추측으로 코드 56줄을 잃을 뻔했습니다.
• 9/26 밤 — 실명이 담긴 주석이 다른 제품 라인으로 새어 들어가다 마지막 검사에서 겨우 걸러졌습니다. 맥에서 앱 안 자동 업데이트가 8개 버전 내내 고장 나 있었다는 사실도 이날 확정됐습니다.
• 9/27 00시 — 원우님 지시: "그리다뿐 아니라 퍼스널도 커스텀이 있으니, 전 에디션 업데이트 운영 방식을 다시 짜서 보고하라."

방치하면 — 그리다는 팀이 늘수록 원우님 시간이 기하급수로 듭니다. 엔터프라이즈는 고객이 직접 고치기 시작하면 같은 문제가 고객 쪽에서 재현됩니다. 퍼스널은 사용자가 늘면 "업데이트 후 깨짐"을 사람이 감당하지 못합니다.

커스텀의 정체 — 사실은 "복사본"입니다

팀원들이 하는 "커스텀"은 앱을 통째로 복사해서 따로 고치는 방식입니다(전문용어로 포크). 앱은 원본 대신 이 복사본을 계속 씁니다.

충돌이 잦은 진짜 원인 — 합치기 도구의 크기 한계

두 판을 자동으로 맞춰주는 도구(3-way 병합)가 1,000줄 넘는 파일은 아예 비교를 포기하고 "전체가 겹쳤다"고 처리해 버립니다. 팀원들이 자주 고치는 핵심 파일이 전부 이 크기를 넘습니다.

이 상한선만 손보면 효과가 실측으로 확인됐습니다 — 세 판을 줄 단위로 맞춰 겹치는 곳만 남기는 표준 방법(diff3)으로 다시 합쳐 보니, 송한영님 파일 7개가 원래는 통째 충돌이었는데 각각 1~7줄짜리 충돌로 줄었습니다.

공식 통로는 하나뿐, 나머지는 비공식

공식적으로 코드를 앱에 붙이는 통로는 대시보드에 위젯 파일 하나 끼워 넣는 것뿐이고, 나머지는 전부 비공식 직접 수정입니다. 그 위젯조차 앱 화면과 같은 공간에서 돌아가 완전히 격리돼 있지는 않습니다.

사고에서 배운 것 5가지

• "이미 반영됐겠지"라는 추측이 실제로 코드를 지운 적이 있습니다.
• 업데이트를 적용하면 이전 백업이 사라지는 구조였습니다.
• 실명이 코드 주석에 섞여 다른 제품 라인으로 샌 적이 있습니다.
• 테스트는 8개 버전 내내 통과했는데, 실제 앱에서는 업데이트 프로그램이 고장나 있었습니다(테스트 환경과 실제 앱이 다르게 반응).
• 원우님이 직접 고친 부분도 제품에 반영이 빠진 적이 있습니다.

옵시디언 가설 재확인

절반만 맞음 안전한 진짜 이유는 "플러그인만 허용해서"가 아니라 "공식 규격이 대부분의 요청을 이미 받아주고 있어서"입니다. 규격이 부족한 자리에서는 옵시디언 개발자들도 몰래 속을 건드리다 업데이트 때 깨집니다(실제 사례 다수 확인).

기획을 쓴 AI(헤드)가 초안을 만든 뒤, 별도의 AI(코덱스 아스트라)에게 "이 기획의 약점·빠진 선택지·틀린 사실을 전부 찾아내라"고 독립적으로 시켰습니다. 코덱스는 코드와 문서를 직접 읽고 8분 동안 검토했습니다.

결과: 조건부 인정 — 지적 30건 중 26건을 그대로 받아들였고 3건은 일부만 반영했습니다. 완전히 틀렸다고 반박된 지적은 0건입니다.

이 과정에서 처음 생각을 바꾼 것 6가지

1. 충돌의 진짜 원인 — "파일이 커서"가 아니라 "합치기 도구가 1,000줄 넘는 파일을 통째로 포기"하는 게 원인이었습니다. 고치는 방법도 훨씬 간단해졌습니다.
2. 병합이 실패했을 때 — "일단 예전 방식으로라도 설치"가 아니라 "실패하면 원래 있던 상태 그대로 두기"가 더 안전하다는 쪽으로 바꿨습니다.
3. 커스텀 정리 기준 — "두 번 지나면 자동 삭제"는 숫자만 채우기 쉬워 "30일마다 사람이 다시 검토"로 바꿨습니다.
4. 부품(위젯 등)의 안전성 — "부품 형태면 무조건 안전하다"는 전제를 버렸습니다. 실제로는 검증한 범위 안에서만 안전합니다.
5. 이번 주 작업 순서 — 원래 순서가 앞뒤가 바뀌어 있어 다시 배열했습니다(송한영님 적용보다 도구 수리·검증이 먼저입니다).
6. 커스텀 허용 기준 — "이 사람은 개발자형, 저 사람은 제보형"이 아니라 "실제로 얼마나 크게 고쳤는지"로 바꿨습니다. 송한영님이 실제로는 큰 수정(14개 파일)을 하고 있었다는 사실이 드러났기 때문입니다.

권고 이유 — 선례들이 전부 "공식 방법 먼저, 직접 수정은 예외, 사람 승인은 마지막 안전판" 구조였고, D안이 이걸 에디션별로 나눈 것뿐입니다. 퍼스널·엔터프라이즈는 이미 "본체 수정 금지"가 확정돼 있어 새 결정이 아니라 기존 결정의 재확인입니다. 그리다에서만 "허용하되 주기적으로 다시 점검"하는 방식이 "AI가 내 앱을 고쳐준다"는 장점과 "업데이트 안전"을 동시에 지킵니다.

에디션별 허용 범위

그리다 "②(본체 수정)" 4가지 규칙

1. 이름 붙은 묶음 — 누가·왜 고쳤는지, 언제 다시 볼지 기록합니다.
2. 30일마다 재검토 — 제품에 반영 / 부품으로 전환 / 유지 / 폐기 중 하나를 정합니다. 자동으로 지우지는 않습니다(업무 방해 방지).
3. 같은 요청이 2번 쌓이면 "이거 아예 공식 기능으로 만들까?"를 심사합니다.
4. 코드가 넘어가는 두 지점(공유 전, 제품 반영 전) 모두에서 실명·비밀번호를 자동 검사합니다.

엔터프라이즈 — "본체는 우리 것, 확장은 계약이 정한 것"

위타민 대표님이 직접 고치고 싶어하시는 부분은 화면 항목·정렬·문구·지침까지만 가능합니다. 새 화면이나 새 데이터 연결은 저희가 만들어 드립니다.

퍼스널 — "무지원 자동 업데이트"가 성립하는 5가지 조건

1. 업데이트해도 사용자의 그리드·설정은 건드리지 않고, 형식이 바뀌면 자동으로 옮겨줍니다.
2. 부품마다 "검증한 앱 범위"를 표시하고, 범위 밖이면 자동으로 꺼지며 알림과 복구 수단을 줍니다.
3. 언제든 되돌릴 수 있는 지점(앱 판+설정+데이터)을 남깁니다.
4. 새 버전은 소수에게 먼저 배포한 뒤 전체로 넓힙니다.
5. 업데이트 프로그램 자체를 실제 패키징된 앱으로 끝까지 시험한 뒤에만 내놓습니다.

1. 앱이 스스로 "내가 뭘 고쳤는지" 압니다 — 사람이 쓰는 보고서에만 의존하지 않습니다.
2. 설치 전에 충돌 여부를 미리 보여줍니다 — "설치"와 "실제 반영(병합)"은 별개 단계입니다.
3. 겹치지 않는 수정은 자동으로 합치고, 겹치는 부분은 AI가 제안한 뒤 사람이 최종 승인합니다.
4. 되돌리기는 도구가 기본으로 제공합니다 — 앱만이 아니라 설정·데이터까지 통째로.
5. 업데이트 프로그램 자체도 실제 앱으로 끝까지 검증한 뒤에만 배포합니다.
6. 채널·버전 표시는 한 곳에서만 관리합니다 — 여러 파일에 흩어지면 서로 어긋납니다.
7. 코드가 넘어가는 모든 관문에서 보안 검사(실명·비밀번호)를 합니다.

월요일 30분 커스텀 검토

이번 주는 아직 전용 도구가 없어서 "접수·분류·보류"까지만 합니다. 팀원 유형은 이름이 아니라 실제 수정 규모로 판단합니다 — 송한영님을 "제보형"으로 분류했던 예전 판단이 틀렸다는 게 이번에 드러났기 때문입니다.

원우님 본인의 수정도 같은 규칙

원우님 dev-source에 쌓인 약 220줄(업무 로직·새 기능·UI 수리 3묶음)도 같은 규칙을 적용합니다. 목표는 "행선지 없는 수정 0건"입니다.

송한영님 건 — 권고 절차

1. 송한영님 앱 안 AI가 로컬 인벤토리(어느 파일을 얼마나 고쳤는지)와 날짜 붙은 백업을 만듭니다.
2. .62 후보를 완성하고 실제 앱으로 끝까지 검증합니다.
3. 원우님이 안내를 보냅니다 — "파일과 설정은 유지되고, 새 판 개선은 병합 뒤에 적용됩니다"라고 정확히 씁니다.
4. 송한영님이 설치 파일로 1회 덮어 설치합니다(이 단계까지는 옛 화면 그대로 유지되며 안전합니다).
5. 앱 안 AI가 자동으로 합치기를 시도하고, 겹치는 부분만 AI가 해결한 뒤 사람이 최종 확인합니다.

실패하면 — 백업을 복원해 원래 상태(.60)를 유지합니다. 원인을 고친 뒤 다시 시도합니다. 급하지 않다면 조건이 갖춰질 때까지 .60을 그대로 써도 손해가 없습니다.

엔터프라이즈 견적 틀 — 기존 "A/B/C"(납품 범위)에 "D 유지보수"를 더해 팀입니다. 요율·SLA 숫자는 아직 자리표시일 뿐 원가 산정 뒤 확정합니다. 위타민 요구사항부터 첫 적용합니다.

이번 주 (9/28 월 ~ 10/2)

1. 기기별 커스텀 실측·백업 1~2시간
2. .62 후보 완성 2~4시간
3. 이전·복구 검증 2~3시간
4. 원우님 앱 새 판 적용 5~10분
5. 송한영님 적용 1~3 통과 후
6. 합치기 도구 수리 — 큰 파일도 부분만 충돌로 반나절+1~2일
7. 실명 검사 강화 2~3시간

6번(도구 수리)은 유력한 즉시 개선이라 5번(송한영님 적용)보다 먼저 하는 것을 권고합니다.

2~4주 (10/5 ~ 10/23)

부품 1종을 "설치→업데이트→복구"까지 전체 검증(3~4일), 패치 묶음 기록 체계 완성(2~3일), 합치기 도구 완성(2~3일). 이 구간 합계가 평일 15일에 여유가 크지 않아, 굵은 항목만 필수로 두고 나머지는 다음 구간으로 미룰 수 있습니다.

1~2개월 (10월 말 ~ 11월)

판매 시작 조건을 날짜보다 먼저 고정합니다 — 퍼스널은 부품 검증 1종 + 자동 업데이트(서명 절차) + 복구 실증, 엔터프라이즈는 견적 틀 + 안정 채널 규칙 확정입니다.

이미 확정된 것 (이 기획이 그대로 전제하는 것)

• 기업 고객은 앱 본체만 봉인 · 에디션 3종 고정 · 그리다 "커스텀 내역 공유"는 끌 수 없음(2026-09-03)
• 위젯·스킬은 검사 통과 후 자동 공개, 본체를 바꾸는 기능은 관리자 확인 후 공개(2026-09-11, D174)
• 팀원 커스텀은 "결함만 채택, 신규 기능은 별도 협의" · 퍼스널 윈도우는 "구성 적용" 완성 전 출시 안 함(2026-09-26)

열린 결정 5개

• "차별점이 줄었다"는 오해 — 팀원이 재검토를 "내 수정을 못 쓰게 한다"로 받아들일 수 있습니다. 대비: 재검토는 재결정일 뿐 자동 삭제가 아니라는 점을 명확히 알립니다. 첫 달은 알림만 하고 보류는 걸지 않습니다.
• 합치기 도구를 안 고치면 — 큰 파일을 고친 사람은 매 판마다 AI 충돌 해결이 고정비가 됩니다. 대비: 이번 주 안에 도구부터 수리합니다.
• 전용 도구가 늦어지면 — 패치 기록·자동 재검토 표시가 늦어질수록 규칙만 남고 실행이 안 됩니다. 대비: 도구 전에는 "접수·분류·백업·보류"까지만 약속합니다.
• .62 재검증에서 새 결함 — 대비: 게시 전 두 채널을 다시 검증하고, 실패하면 팀 안내는 "설치 파일 1회"로 유지한 채 게시만 보류합니다.
• 퍼스널 맥 자동 업데이트 공백 — 서명 절차 전까지는 "알림 + 수동 설치"뿐입니다. 대비: 판매 화면에 현재 방식을 정확히 표시합니다.
• 약속과 실증이 어긋나면 — "그대로 유지됩니다" 같은 문구를 실증 전에 쓰면 송한영님 건이 고객 규모로 재현될 수 있습니다. 대비: 실증 통과 기록이 있을 때만 그 문구를 씁니다.
• 원우님 시간 병목 — 검토·승인이 원우님 한 사람에게 몰립니다. 대비: 30분 상한, AI가 먼저 분류 초안을 만들어 둡니다.
• 확인 안 된 항목들 — 윈도우 커스텀 여부, 김승일님 기기 보류 사유, 박윈도님 기기의 본체 수정 여부. 대비: 이번 주 1번(기기 실측)에서 확인하고, 확인 전까지는 "추정"으로만 표시합니다.

확정 후 다음 절차 (원우님 결정 이후 AI가 할 일)

1. 결정을 받으면 정본 문서를 "확정판"으로 표시하고 이 페이지를 갱신합니다.
2. 결정 1·3·4는 상품 체계·공통 개발 규칙 문서에 "커스텀 등급·채널" 절로 반영합니다.
3. 결정 2는 송한영님 안내문을 확정하고, 이번 주 1~3단계 통과 뒤 발송합니다.
4. 결정 5는 계약서·기술명세서 틀에 견적 틀과 지원 범위를 추가하고, 위타민 요구사항 회신 초안을 만듭니다.
5. 역이식 백로그에 "확장점 심사 후보"와 "병합기 한계 수리" 항목을 새로 올립니다.
6. 이번 기획에서 얻은 원칙 3가지를 AI 메모리에 등록합니다.