Workspace State Boundary
작업공간 상태가 어디까지 저장되고 복원되어야 Fricle의 반복 사용 가치가 생기는지 판단하는 기준이다.
핵심 결론
Fricle의 상태 저장은 부가 기능이 아니라 “다시 열 수 있는 작업 상태”를 만드는 핵심 조건이다.
검수 기준은 내부 저장 구조가 아니라 사용자가 다시 들어왔을 때 작업 맥락을 잃지 않는가다.
상태 경계 다이어그램
작업공간
캔버스 상태
앱 배치, 창 상태, 문서 상태처럼 사용자가 다시 들어왔을 때 이어져야 하는 작업면의 현재 모습이다.
기준
기준 상태
Fricle이 공식 작업공간 상태로 인정하는 값이다. 브라우저 사본이 아니라 서버 기준으로 판단한다.
변경
변경 기록
사용자가 앱을 움직이고, 문서를 수정하고, 협업자가 바꾼 내용을 다음 기준 상태로 반영하기 위한 기록이다.
복원
다시 열기
저장된 기준 상태와 필요한 변경 기록을 이용해 사용자가 보던 작업공간을 다시 이어 보여주는 결과다.
브라우저
빠른 열기 사본
IndexedDB 같은 브라우저 사본은 빠르게 열거나 임시 복구를 돕지만, 공식 기준 상태를 대체하지 않는다.
제외
파일과 실행본
앱 원본, 실행본 선택, 외부 파일 소유권, 결제와 사용권은 Workspace State Boundary가 직접 소유하지 않고 별도 경계에서 다룬다.
상태 경계 다이어그램은 저장 처리 순서가 아니라 무엇이 Fricle의 기준 상태인지와 무엇이 경계 밖인지 보여준다. 실제 처리 순서는 Pipeline의 Workspace State Flow에서 다룬다.
상태 경계
| 구분 | 남겨야 할 것 | 낮출 것 |
|---|---|---|
| 공유 기준 상태 | 프로젝트에 필요한 앱/자료/결정/공유 맥락 | 내부 저장 테이블명 |
| 개인 화면 상태 | 개인 배치, 열림/접힘, 최근 본 위치처럼 재진입을 돕는 상태 | 일회성 UI 로그 |
| 변경 기록 | 복원/검수/되돌림에 필요한 변경 맥락 | 개발자 디버그 로그 |
| 경계 밖 | 사용자 가치와 연결되지 않는 내부 캐시/임시 처리 | product 본문에서 제외 |
검수 규칙
- 닫았다 다시 열었을 때 “무엇을 이어 해야 하는지” 보여야 한다.
- 공유되는 상태와 개인에게만 보이는 상태를 섞지 않는다.
- 복원 실패, 권한 없음, 삭제됨, 만료됨 상태를 사용자 언어로 설명해야 한다.
- 상태 저장 범위가 비용/전환 조건과 연결되면 Transition Conditions로 올린다.
하위 연결
Pipeline에서는 저장/복원 흐름으로, UX UI에서는 재진입 화면과 상태 안내로 내려간다.