qwreey
790ebba78f
컴포넌트 함수를 감싸 에러 시 플레이스홀더를 그려주는 pcall/xpcall 래퍼 아이디어를 백로그로 문서화(research/component-fallback-plan.md), README/ question.md/CLAUDE.md 인덱스 반영. 후속 code-review로 발견된 결함(코드 스팬이 줄바꿈에 걸쳐 깨진 곳 4군데, 워크트리가 계획 문서 없이 시작되는 원인을 "git 미추적"으로 오진단했던 세션 로그 서술)도 같이 정정. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
80 lines
5.1 KiB
Markdown
80 lines
5.1 KiB
Markdown
# 2026-08-14 첫 번째 세션 — 컴포넌트 에러 격리 유틸 `Fallback` 백로그 신설
|
|
|
|
## 배경
|
|
|
|
사용자가 컴포넌트마다 개별적으로 `pcall`을 직접 감싸는 게 실용적이지
|
|
않다고 지적 — 매 컴포넌트 호출 자리마다 손으로 `pcall`을 반복해 쓰는
|
|
대신, 컴포넌트 함수 하나를 받아 에러 시 자동으로 플레이스홀더를 그려주는
|
|
버전으로 바꿔주는 아주 단순한 유틸을 요청. 사용자가 직접 제시한 모양:
|
|
|
|
```
|
|
Fallback((T...)→OriginalComp, (errorMessage)→ErrorComp) → (T…)→OriginalComp|ErrorComp
|
|
```
|
|
|
|
클린업 동작(언마운트/리소스 해제)이 목적이 아니라, 실제 에러가 났을 때
|
|
디버깅이나 프로덕션 유저 리포트를 편하게 만드는 게 유일한 목적이라고
|
|
명시. `ErrorComp`가 추가 상태/props가 필요하면 `Fallback`이 그걸 신경 쓸
|
|
필요 없이 `onError` 자체를 커링해서 만들면 된다는 점도 사용자가 직접
|
|
짚음. "이걸 백로그로 작성해봐, 워크트리에서 작업해"라고 요청.
|
|
|
|
## 확인한 것 — 기존 결론과의 관계
|
|
|
|
`research/additional-primitives-plan.md`를 확인한 결과, 이미 "Error
|
|
Boundary는 빈 자리 아님 — `pcall(MyComp, props)`만으로 React Error
|
|
Boundary와 같은 격리 효과를 프레임워크 지원 없이 얻는다"는 결론이 확정돼
|
|
있었음(2026-08-06~07 세션, 이 문서는 이후 "새로 열린 설계 질문 없음"으로
|
|
배경 자료화됨). 사용자의 `Fallback` 요청은 이 결론을 뒤집는 게 아니라
|
|
정확히 그 결론이 지목한 메커니즘(`pcall(MyComp, props)`)을 감싸는 얇은
|
|
편의 함수 — `Operator` 콤비네이터가 `:Compute`/`:Apply` 위에 얹힌 것과
|
|
같은 관계이므로, `additional-primitives-plan.md`를 다시 열지 않고 새
|
|
research 문서로 분리하는 게 맞다고 판단.
|
|
|
|
`research/debug-tooling-plan.md`가 이미 확인해둔 선례(Vide/Fusion 둘 다
|
|
`xpcall`+`debug.traceback`으로 에러 나는 순간에만 스택을 찍는 패턴)도
|
|
같이 참고해, 에러 트레이스 캡처 메커니즘을 새로 발명하지 않고 재사용하는
|
|
방향으로 스케치.
|
|
|
|
## 한 일
|
|
|
|
- `research/component-fallback-plan.md` 신설 — 동기, 제안 API(`Fallback(original, onError)`),
|
|
메커니즘 의사코드(`xpcall`+`debug.traceback`), 커링 관용구, 기존
|
|
"Error Boundary는 빈 자리 아님" 결론과 안 부딪히는 이유, 열린 질문
|
|
(pcall vs xpcall 트레이드오프, `xpcall` 에러 핸들러 배선 실측 필요,
|
|
패키지 배치, 이름, 프로덕션 동작) 정리. **설계 확정 아님 — 순수
|
|
백로그**, 사용자가 어떤 결정도 아직 내리지 않음.
|
|
- `.claude/README.md` research 표에 새 행 추가.
|
|
- `CLAUDE.md` "지금 할 일" 4번 백로그 목록에 `Fallback`을 형제 항목
|
|
(`quad-mock`/`quad-debug`/문서 사이트/`Operator`)과 나란히 추가, 상세
|
|
링크 목록에도 `component-fallback-plan.md` 추가.
|
|
|
|
## 반영 상태
|
|
|
|
새로 연 설계 질문 없음(전부 문서 신설 자체가 목적) — `question.md`에
|
|
낮은 우선순위 항목으로 포인터 추가는 이 세션 안에서 같이 처리.
|
|
`doc-check.py`는 워크트리에 `.claude/` 전체가 없어(아래 "워크트리 관련
|
|
메모" 참고) 메인 체크아웃에 결과 반영 후 그쪽에서 실행.
|
|
|
|
## 워크트리 관련 메모 (재발 방지용, 코드 리뷰로 정정됨)
|
|
|
|
**[정정, 같은 세션 후속 `/code-review`]** 최초 기록("`.claude/`와 루트
|
|
`CLAUDE.md`/`ROADMAP.md`/`HUMAN_TODO.md`가 git에 커밋돼 있지 않음")은
|
|
틀렸음 — `git ls-files`로 재확인한 결과 이 파일들 전부(`.claude/` 208개
|
|
포함) 로컬 `main` 브랜치엔 정상적으로 커밋돼 있음. 실제 원인은 따로
|
|
있었음: `EnterWorktree`가 기본값(`baseRef: "fresh"`)으로
|
|
**`origin/<기본브랜치>`**(이 레포는 `origin/master`)에서 새 브랜치를 침 —
|
|
그런데 `origin/master`는 `.claude/` 파일이 **0개**
|
|
(`git ls-tree -r origin/master -- .claude`로 확인, `CLAUDE.md`도 없음). 이 레포의 계획
|
|
문서(`.claude/`, 루트 `CLAUDE.md`/`ROADMAP.md`/`HUMAN_TODO.md`)는
|
|
`SAFETY.md`의 "GitHub 등 외부 git 호스팅에 이 레포를 push하지 말 것"
|
|
규칙에 따라 **로컬 `main`에만 있고 `origin`(GitHub)엔 의도적으로 한 번도
|
|
push된 적 없음** — 그래서 `origin/master`에서 갈라친 fresh 워크트리는
|
|
계획 문서가 원천적으로 빠진 채 시작되는 게 **의도된 안전장치**이지,
|
|
문서가 untracked라서가 아님.
|
|
|
|
**재발 방지 — 다음에 이 레포에서 "워크트리에서 작업해"라는 지시를 받으면**:
|
|
계획 문서를 편집해야 하는 작업이면 `EnterWorktree`에 `path`로 로컬
|
|
`main`에서 이미 갈라친 워크트리를 쓰거나, 필요한 파일만 메인 체크아웃
|
|
(로컬 `main`)에서 복사해 편집 후 다시 복사해 반영하는 이번 방식을 그대로
|
|
반복하면 됨 — 다만 "git에 안 올라가 있어서"가 아니라 "`origin/master`
|
|
브랜치엔 애초에 이 문서들이 없어서(의도된 것)"라는 정확한 이유로
|
|
이해하고 시작할 것.
|