Antigravity Agent
9148c358d0
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
3.1 KiB
3.1 KiB
id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases
| id | title | category | status | source_trust_level | verification_status | created_at | updated_at | tags | tech_stack | applied_in | aliases | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| rn-ota-updates-codepush | RN OTA — Expo Updates / CodePush 후속 | Coding | draft | B | conceptual | 2026-05-09 | 2026-05-09 |
|
|
|
RN OTA Updates
JS 번들만 변경하면 store review 없이 즉시 사용자에게 배포. Expo Updates (CodePush 종료 후 표준) + 채널 + rollback. 단 native code 변경은 OTA 불가.
📖 핵심 개념
- OTA: JS bundle + assets만 교체. native 코드, infoplist, AndroidManifest 변경은 store 빌드.
- 채널: production / staging / canary.
- Rollback: 새 버전 문제 시 이전 만료 / 강제.
💻 코드 패턴
Expo Updates 셋업
npm install expo-updates
npx expo install expo-updates
// app.json
{
"expo": {
"runtimeVersion": "1.0.0",
"updates": {
"url": "https://u.expo.dev/<project-id>",
"fallbackToCacheTimeout": 0,
"checkAutomatically": "ON_LOAD"
}
}
}
EAS Update publish
eas update --branch production --message "v1.0.1: bug fix"
클라이언트 — manual check
import * as Updates from 'expo-updates';
async function checkForUpdate() {
try {
const update = await Updates.checkForUpdateAsync();
if (update.isAvailable) {
await Updates.fetchUpdateAsync();
// 사용자에게 안내 후 reload
await Updates.reloadAsync();
}
} catch (e) { /* ignore */ }
}
Runtime version 호환성
- runtimeVersion 같으면 OTA OK.
- native 변경 시 runtimeVersion bump → 새 store 빌드 필수, 옛 OTA 받지 않음.
채널 / 환경 분리
eas update --branch staging
# staging 빌드만 staging 채널 받음
const channel = Updates.channel; // 'production' / 'staging'
🤔 의사결정 기준
| 변경 | OTA |
|---|---|
| JS 비즈니스 로직 / UI | ✅ |
| 새 npm package (JS only) | ✅ |
| Native module 추가 | ❌ store 필요 |
| Asset (이미지) | ✅ |
| app icon / splash | ❌ |
| Push 인증서 / 권한 | ❌ |
| 큰 변경 (UX 전면 개편) | OTA 가능하지만 staged rollout 권장 |
❌ 안티패턴
- runtimeVersion bump 안 하고 native 변경: 옛 binary 가 새 JS 받음 → crash.
- production 채널 직접 publish: 검증 없음. staging → production 단계.
- rollback 절차 없음: 사고 시 모두 영향.
- 거대 update (수 MB): 사용자 모바일 데이터 부담. 변경 부분만.
- store 빌드와 OTA 버전 mismatch 모니터링 X: 어떤 사용자 어떤 버전 모름.
- OTA 로 보안 패치만 의존: 사용자가 OTA 받기 전 노출. 진짜 보안 = store 빌드.
🤖 LLM 활용 힌트
- "JS only 변경 = OTA, native 변경 = runtimeVersion bump + store" 명시.
- 채널 분리 (production / staging).