Cloudflare Think 업데이트 뒤 파일이 안 보인다면
Cloudflare Think를 업데이트했더니 에이전트가 빈 작업 공간만 본다. 예전 파일은 지워진 걸까, 어디로 옮겨 놓아야 다시 보일까?

- Think의 작업 공간이
@cloudflare/shell에서@cloudflare/computer로 바뀌면서 기존 파일을 읽는 테이블도 달라졌다. - 이전 데이터는 원래 테이블에 남지만 자동 복사는 없으며, Think의 새 파일 경로는
/workspace아래다. - 공식 복사 예시는 한 번 실행하도록 기록해야 하며, 기존 파일의 생성·수정 시각과 MIME 정보는 보존하지 않는다.
새 작업 공간이 비어 있어도 원본 테이블은 남아 있다
기존 Think 앱을 새 작업 공간 구현으로 바꾼 직후 파일 목록이 비었다면, 먼저 파일 저장 형식의 변경을 확인해야 한다. Cloudflare의 10월 20일 발표는 파일을 자동 이전하지 않으며, 복사하지 않으면 빈 작업 공간에서 시작한다고 명시한다. 이때 원래 데이터는 기존 테이블에 남는다.
이전 Think의 기본 파일 테이블은 cf_workspace_default다. 새 Computer는 vfs_·_vfs_로 시작하는 테이블을 사용한다. 같은 Durable Object에 두 형식이 함께 있을 수 있어, 패키지를 바꿨다는 사실만으로 기존 파일이 새 도구에 나타나지는 않는다.
따라서 이 변경에 해당하는 앱은 작업 공간을 초기화하기보다 원본 테이블과 복사 여부부터 확인하는 편이 맞다. 파일이 보이지 않는 원인이 저장 위치 변경이라면, 새 위치로 데이터를 옮기는 것이 다음 작업이다.
Think 파일은 /workspace 아래로 복사한다
공식 마이그레이션 안내는 같은 저장소에 두 Workspace를 연결하고, 이전 파일을 읽어 새 workspace.fs API로 쓰는 예시를 제공한다. 새 테이블에 SQL 행을 직접 넣는 방식은 피해야 한다. 파일 조각의 해시와 변경 기록을 함께 맞춰야 하기 때문이다.
Think의 도구가 사용하는 작업 루트는 /workspace다. 예를 들어 예전 /notes.md는 /workspace/notes.md로 복사한다. 파일을 옮겼더라도 앱이 예전 절대 경로를 계속 참조하면 읽을 위치가 맞지 않을 수 있다.
| 기존 저장 방식 | 이전 전에 확인할 조건 |
|---|---|
| 기본 Think 파일 | cf_workspace_default의 파일을 새 작업 루트로 복사한다. |
| 큰 파일을 R2에 저장한 Shell | 원래 r2와 name 또는 r2Prefix 설정이 있어야 파일 내용을 읽을 수 있다. |
| 여러 namespace를 쓰던 Shell | 새 Computer는 한 Durable Object 저장소에 작업 공간 하나를 둔다. 기존 분리 방식이 그대로 옮겨지지 않는다. |
특히 R2를 사용했다면 저장 위치가 계속 같을 것이라고 가정하면 안 된다. 대용량 파일의 R2 분리 저장은 아직 기능 요청 상태이며, 현재 새 파일 내용은 SQLite에 저장된다. namespace 지원도 별도 요청으로 남아 있다.
복사는 한 번 수행하고, 파일 내용과 경로를 확인한다
공식 예시는 onStart에서 복사를 마친 뒤 shellMigrated를 기록해 다음 시작 때 반복하지 않게 한다. 이미 새 공간에서 수정한 파일이 있다면 원본을 다시 복사할 때 무엇을 남길지 먼저 결정해야 한다. 복사 함수를 시작할 때마다 무조건 실행하도록 붙이는 방식은 적절하지 않다.
복사 결과가 이전 파일의 모든 속성을 보존하는 것도 아니다. 생성·수정 시각은 복사 시점으로 바뀌고 파일별 MIME 정보는 유지되지 않는다. 시간순 정렬이나 MIME 분류를 앱에서 사용했다면, 파일 내용이 같다는 확인만으로 이전을 끝내기 어렵다.
운영 전환 전에는 대표 파일의 내용, 링크 대상, 앱이 참조하는 경로를 대조하는 순서를 권할 만하다. 원본 정리는 그 다음이다. 공식 안내도 복사한 파일 확인을 먼저 요구하며, R2를 정리할 때는 공유할 수 있는 접두사 전체가 아니라 대상 파일의 정확한 키를 구분하도록 한다.
파일을 옮겨도 예전 bash 도구가 돌아오지는 않는다
새 Think 도구 구성에는 읽기·쓰기 등 파일 작업이 기본으로 들어간다. 목록 도구는 list에서 ls로 바뀌었고, 기본 작업 공간에는 실행 backend가 없어 exec도 없다.
JavaScript 실행을 쓰려면 WorkerJavaScriptBackend와 Worker Loader 바인딩을 연결해야 한다. 파일은 보이는데 코드 실행만 되지 않는다면, 데이터 복사를 반복할 것이 아니라 이 도구 구성을 확인해야 한다. 이전 완료의 기준은 파일 목록 복원에 더해 실제 앱이 쓰는 경로와 도구가 새 구성에 맞는지까지다.