Project Space Contract

프로젝트 공간: 기존 폴더와 구분할 최소 계약

작성일: 2026-09-20. 연결: #290, #289, Discussion #287. 기준 main: 558714a818ae8f0dcffc8436d8e7e30a66c93442. 상태: 코드 조사와 범위 제안. 고객 수요·시제품·구현 검증은 미완료다.

판단

여러 제품의 자료를 묶는 일은 현재 폴더로도 가능하다. 프로젝트를 추가하는 이유는 이것만으로 충분하지 않다. 같은 원본을 여러 업무에서 재사용하고, 문서를 지우지 않은 채 업무 묶음을 보관해야 하는지 먼저 확인한다.

추천은 기존 폴더를 비교 기준으로 삼고, 프로젝트의 추가 가치를 검증하는 것이다. 당장 전체 업무 관리 기능을 만드는 결론은 아니다. #290의 ‘간단한 단계 정보’는 첫 범위에서 진행/보관 상태로 제한하는 안을 제안한다. 검토·승인·담당자·기한이 필요한지는 실제 업무에서 확인한다. 아직 채택 결정은 없다.

기존 기능과 새 개념의 차이

개념	현재 사실 또는 제안	문서 본문·주소에 미치는 영향
폴더	현재 문서별 문자열 1개. 전체 제품 목록을 같은 값으로 거른다. 폴더 목록은 문서에서 계산한다.	폴더 변경은 문서 ID를 바꾸지 않는다.
문서 참조	현재 문서 A가 문서 B의 ID를 연결한다. 복사나 양방향 소속 관계가 아니다.	원본을 연다. 연결 해제는 본문 삭제가 아니다.
독립 사본	현재 새 문서 ID를 만든다.	별도 본문이며 원본 변경을 자동 반영하지 않는다.
프로젝트	제안: 안정된 ID·이름·진행/보관 상태를 가진 업무 묶음. 문서 하나가 여러 프로젝트에 소속될 수 있다. 빈 프로젝트도 유지한다.	소속은 문서 이동·복사·권한 부여가 아니다.
로컬 workspace	현재 한 origin의 통합 자료함과 catalog 맥락이다. 제품 저장소는 제품별로 유지한다.	프로젝트를 추가해도 저장 위치가 서버로 바뀌지 않는다.
서버 tenant/workspace	기존 플랫폼 설계의 회사 보안 경계와 회사 내 작업 공간이다. 현재 로컬 기능과 구분한다.	향후 서버가 membership과 문서 권한을 확인한다. 프로젝트 ID만으로 접근을 허용하지 않는다.

근거: metadata와 목록, 폴더 필터·목록, 참조, 로컬 계약, 서버 경계.

추가 가치를 확인할 세 질문

1. 최근 실제 업무에서 같은 원본이 서로 다른 두 업무에 쓰였는가? 원본을 복사했는지, 링크했는지, 어떤 문제가 있었는지 관찰한다.
2. 업무가 끝나면 관련 자료를 어떻게 정리하는가? 원본까지 삭제되거나 다른 업무에서 못 찾게 된 경험이 있는가?
3. 제품에서 돌아왔을 때 같은 업무의 자료를 다시 찾는 데 문제가 있는가? 폴더·검색으로 충분히 해결하는지도 본다.

UX-05는 다른 역할이 네 제품에서 전체 자료함으로 돌아가는 정상 경로를 실행한 기록이다. 기능은 동작했으며 신규 결함을 보고하지 않았다. 실제 고객의 발견성이나 프로젝트 필요성을 입증한 결과는 아니다. 해당 기록의 빌드 범위와 미검증 조건을 그대로 따른다. 이번 회차는 화면을 다시 실행하지 않았다.

채택할 경우의 최소 모델

프로젝트에는 고유 ID, 이름, 보관 상태와 수정 revision을 둔다. 소속은 프로젝트 ID와 문서 주소의 관계로 표현한다. 같은 관계의 중복을 막는다. 이름·폴더·본문을 소속 정보에 복제하지 않는다. 목록은 원본의 현재 이름과 사용 가능 상태를 읽는다.

작은 로컬 시제품은 프로젝트별 문서 주소 집합을 별도 프로젝트 저장 레코드에 두는 안부터 검토한다. 기존 catalog는 문서 메타데이터를 읽는 구조이므로 프로젝트 레코드를 무조건 섞지 않는다. 저장 위치의 상세 설계는 구현 전에 정한다. 동시에 두 탭이 소속을 바꾸면 조건부 저장으로 충돌을 알리거나 안전하게 다시 적용한다. 오래된 집합으로 덮어써서 다른 탭의 추가를 잃지 않아야 한다.

폴더는 자동으로 프로젝트가 되지 않는다. 기존 문서도 자동 배정하지 않는다. 사용자가 필요한 문서를 명시적으로 추가한다. 프로젝트 간 원본 공유는 같은 ID를 가리키며, 한쪽에서 본문을 바꾸면 다른 쪽에서도 같은 원본이 열린다는 점을 표시한다.

사용자 동작 계약

동작	기대 결과
기존 자료 추가	원본 ID 유지. 이미 소속된 자료는 중복 추가하지 않음. 휴지통 자료는 새로 추가하지 않음.
프로젝트에서 새 자료 만들기	문서 저장과 소속 저장이 모두 끝나야 완료 표시. 소속 저장만 실패하면 저장된 문서 위치와 다시 연결하는 동작 제공.
자료 열기·돌아오기	제품의 기존 저장 후 이동 계약 재사용. 프로젝트 맥락으로 돌아올 경로 제공. 전체 자료함 경로도 유지.
원본 이름·폴더 변경	모든 프로젝트에서 현재 원본을 표시. 소속 유지.
프로젝트에서 빼기	해당 소속만 해제. 원본과 다른 프로젝트의 소속 유지.
원본 휴지통 이동	해당 원본을 쓰는 모든 프로젝트에 사용 불가 표시. 소속은 유지하여 복원 후 다시 연결됨.
원본 영구 부재	누락 항목을 명시. 사용자가 소속을 해제할 수 있음. 다른 문서로 조용히 대체하지 않음.
프로젝트 보관·복원	진행 목록에서 이동. 문서 삭제·휴지통 이동·편집 권한 변경 없음. 보관은 승인 완료를 뜻하지 않음.

프로젝트 문맥은 선택적인 탐색 정보다. 문서의 파일 ID를 바꾸거나 프로젝트마다 별도 문서 URL 정체성을 만들지 않는다. 같은 원본을 서로 다른 프로젝트의 두 탭에서 열면 각 탭의 복귀 맥락을 유지한다. 프로젝트가 없거나 보관된 경우도 문서 자체를 ‘없는 파일’로 처리하지 않는다. URL의 프로젝트 값은 로컬 유효성 확인에 쓰며 서버 권한으로 간주하지 않는다.

현재 공통 이동은 ProductNavigation에서 입력 저장 후 이동한다. 이를 제품별로 다시 만들지 않는다. 이동에 실패하면 현재 편집 화면과 입력을 유지해야 한다.

백업과 실패 처리

현재 전체 백업 형식은 version 1이고 문서와 메타데이터를 담는다. 복원은 새 문서 ID를 만들며 여러 제품 DB를 한 번에 원자적으로 저장하지 않는다.

프로젝트를 채택하면 새 앱은 기존 version 1 백업을 프로젝트 없이 읽어야 한다. 프로젝트와 소속을 포함한 새 백업은 형식 버전을 명시한다. 구형 앱이 프로젝트를 조용히 누락한 복원을 성공으로 표시하지 않도록 version 1에 필드만 추가하는 안보다 새 버전 도입을 우선 검토한다. 현재 구형 reader는 version 1 외 입력을 거절한다.

새 형식은 문서·프로젝트·소속을 모두 검증한 뒤 쓴다. 복원 시 프로젝트도 새 ID를 만들고 같은 이름이라는 이유로 기존 프로젝트에 합치지 않는다. 함께 백업한 문서는 새 문서 ID로 매핑한다. 두 프로젝트가 원본 하나를 공유했다면 복원 후에도 새 사본 하나를 함께 가리킨다. 일부 저장 실패는 문서 수만으로 ‘전체 성공’ 처리하지 않고 프로젝트와 소속의 미완료 상태를 구분한다. 재시도 중복 방지 범위도 설계한다.

첫 범위는 전체 백업의 확장이다. 프로젝트별 선택 내보내기, 회사 간 이관, 외부 원본 권한 이전은 포함하지 않는다. 프로젝트 밖 문서 참조와 출처는 자동으로 접근 가능해진다고 약속하지 않는다. #291의 출처·복원 계약과 함께 검토한다.

검증 순서와 인수 기준 보완

1. 필요성 확인: 기존 폴더로 관련 문서를 찾는 과제와 실제 업무의 원본 재사용 사례를 관찰한다. 기존 #289의 재열기 단계 및 UX-05 문항과 중복 측정하지 않는다.
2. 개념 비교: 기능이 없으면 정적 화면으로 ‘추가·빼기·보관’의 의미만 확인한다. 정적 화면으로 저장 성공이나 시간 절감을 주장하지 않는다. 같은 원본을 두 업무에 추가한 뒤 한 업무에서 빼는 상황은 별도 확장 과제이며, 기존 실험에 몰래 합치지 않는다.
3. 채택 후 기능 인수: 네 제품 연결·생성·재열기, 마지막 입력 저장 실패, 중복 연결, 두 탭 소속 충돌, 원본 휴지통·복원, 프로젝트 보관, version 1 입력, 새 백업의 다대다 관계 복원을 검사한다. 전체 자료함·폴더·즐겨찾기·참조의 기존 회귀 검사를 유지한다.

보류 조건: 관찰한 업무가 폴더 하나와 원본 참조로 충분하고 별도 소속·보관의 필요가 나오지 않으면 #290의 구현을 보류한다. 자료를 못 찾는 원인이 이름이나 복귀 경로라면 그 문제를 먼저 다룬다. 프로젝트 기능을 성공시키기 위해 과제를 억지로 복잡하게 만들지 않는다.

진행 조건: 실제 반복 업무에서 폴더만으로 처리하기 어려운 원본 재사용·업무 보관 문제가 확인되고, 사용자가 추가·해제·보관을 원본 삭제와 구분한다. 표본 수와 합격 기준은 실험 전에 #289와 함께 정한다. 현재는 참여자와 측정값이 없어 어느 조건도 충족했다고 판단하지 않는다.

후속 결정

Discussion #287에서 A: 폴더를 기준으로 먼저 관찰 / B: 프로젝트 시제품을 바로 추가를 비교한다. 추천은 A다. 기존 기능을 활용할 수 있고 추가 복잡성의 필요를 아직 확인하지 못했기 때문이다. 반대 근거는 빈 업무의 유지·여러 업무에서 같은 원본 재사용·업무 단위 보관을 현재 폴더가 직접 표현하지 못한다는 점이다. 해당 요구가 실제 업무에서 먼저 확인되면 B로 재검토한다.

#290은 열린 제안으로 유지한다. 이 문서는 코드 실행 결과나 최종 설계 승인이 아니다. 팀 권한·서버 저장·일정·채팅·태스크 관리·승인 엔진·모바일 화면 설계는 포함하지 않는다.