Fricle Product
Fricle 제품 판단의 최상위 기준 문서다. 여기서는 무엇을 만들지, 어떤 문제를 어떤 기준으로 풀지 정한다.
서비스 콘셉트와 타겟
여기서 만든다는 것은 화면을 꾸미는 것이 아니라, 프로젝트에 필요한 작업 요소를 한 공간에 배치하고 연결해 실제 작업 흐름으로 굴리는 것을 뜻한다. AI는 필요한 작업을 맡기거나 필요한 앱/도구를 더 쉽게 채우기 위한 보조 수단이며, 도구 제작 자체가 Fricle의 본질은 아니다. 공유/협업은 이 작업공간을 다른 사람에게 전달하고 함께 운영하기 위한 기본 축이다.
| 구분 | 제품 기준 | 헷갈리면 안 되는 것 |
|---|---|---|
| 서비스 콘셉트 | 프로젝트별 작업환경을 만들고, 실제 작업 흐름으로 운영하며, 다시 들어와 이어 가는 라이브 작업공간이다. | 단순 문서 정리 도구나 앱 바로가기 모음이 아니다. |
| 핵심 타겟 | 여러 앱과 파일과 대화를 오가며 작업 맥락을 잃는 개인 작업자와 팀이다. | 메모 하나만 쓰는 사용자나 단일 기능 도구만 목표로 삼지 않는다. |
| 확장 타겟 | 필요한 도구를 작업공간에 연결하고 운영해야 하는 프로젝트 운영자 또는 확장 단계의 파트너/도구 공급자다. | 도구 제작 플랫폼이 아니라, 작업공간을 채우는 보조 장치로 다룬다. |
| 운영 타겟 | 권한, 라이선스, 설치, 실행 상태, 게시 기준을 함께 관리해야 하는 작업공간 운영자다. | 요금제나 관리자 콘솔만 따로 붙은 부가 기능으로 보지 않는다. |
업무 범위 판정
직접 구현하지 않는 내용도 사용자 가치, 전환 조건, 운영 리스크, 외부 작업물 검수에 조금이라도 필요하면 남긴다. 다만 내부 구현 세부나 운영 실무는 현재 정본처럼 보이지 않게 참고/후속으로 낮춘다.
| 판정 | 남기는 내용 | 처리 방식 |
|---|---|---|
| 직접 판단 | 사용 이유, 반복 가치, Alpha 검증, 전환 조건, 메시지, 우선순위 | Product, Business Basis, Alpha GTM, Transition Conditions의 현재 기준으로 둔다. |
| 검수 기준 | 권한, 라이선스, 상태 복원, 마켓 설치, 앱 실행, UX 화면처럼 외부/개발 작업물 평가에 필요한 기준 | Architecture, Pipeline, UX UI에 남기되 사용자 경험과 제품 리스크 언어로 번역한다. |
| 참고/후속 | 저장소 한도, 요금제 후보, 환불, 정산, 공급자 운영, 프로토타입, App UI 이후 화면 초안 | reference, legacy, 후속 정책, 재검토 초안으로 낮추고 현재 정책처럼 쓰지 않는다. |
| 제외/보관 | 내부 API, DB, 컨트롤러, 결제 인프라, SDK, 구현 로그처럼 사용자가 보는 판단과 직접 연결되지 않는 내용 | 현재 본문에서 빼고 archive나 개발/운영 문서로만 둔다. |
사업 기준
초기 검증 대상은 실제 프로젝트나 핵심 작업 흐름을 Fricle로 옮겨볼 수 있는 프로젝트 작업자 / 작은 팀이고, 1차 반복 가치는 프로젝트 작업환경 지속성과 작업 흐름 재개다.
왜 사용하나
앱, 파일, 대화, 작업 상태가 흩어져 다음 작업으로 이어지지 않는 문제를 줄인다.
왜 계속 쓰나
프로젝트별 작업환경이 계속 보존되고, 재진입/권한/저장소 운영이 후속 전환 가치로 연결된다. 공유/협업은 작업환경을 함께 운영하기 위한 기본 축으로 본다.
전환 조건 기준
사용권, 권한, 저장소, 사용량, 복원, 지원 조건은 반복 가치와 사용자 흐름을 연결한다. Alpha에서는 이 조건으로 돈을 받는 것이 아니라, 어떤 조건이 계속 사용을 가능하게 하거나 막는지 관찰한다.
무엇을 판단하나
사용자가 지금 무엇을 쓸 수 있고, 왜 막혔고, 계속 쓰려면 어떤 조건이 필요한지 판단한다.
어디에 연결되나
Business Basis, User Flow, License & Seat, Workspace State, 전환 조건 UX 초안을 연결한다.
Alpha GTM
초기 Alpha는 큰 공개 런칭이나 긴 영업 루프가 아니라, 메시지 신호와 게이트를 통과한 Alpha 검증 참여자의 실제 프로젝트나 핵심 작업 흐름을 직접 온보딩해 “이어지는 프로젝트 작업공간”이 실제 사용 이유가 되는지 확인하는 단계다. 여기서 나온 데이터는 Business Basis, User Flow, UX UI, Marketplace, License/Seat, BM 기준을 수정하는 입력값으로 쓴다.
신호 방식
48~72시간 메시지 테스트로 구체적인 프로젝트 사례가 나오는지 먼저 보고, 게이트 통과 후보에게만 문제 인터뷰와 수동 온보딩을 붙인다.
검증 방식
정해진 검증 기간 안에 실제 프로젝트 이전, D+1/D+7 재진입, 필요 시 내부 공유, 이후 계속 사용 조건을 기준으로 본다.
제품 기준
모든 하위 문서는 작업 환경이 흩어지고, 상태가 사라지고, 작업 맥락과 도구 접근이 끊기는 문제를 Fricle 안에서 어떻게 줄이는지 설명해야 한다.
| 사용자 불편 | 제품 답변 | 해결 기준 |
|---|---|---|
| 작업 환경이 흩어진다 | 캔버스, 작업 공간, 앱 창, 파일, 문서를 하나의 작업 배치로 다룬다. | UX UI: Overview UX UI: Workspace 예정 Architecture: Workspace State Boundary Pipeline: Overview Pipeline: Workspace State Flow |
| 상태가 쉽게 사라진다 | 앱 배치, 세션, 문서 상태, 동기화 상태를 저장하고 복원 가능한 흐름으로 만든다. | Architecture: Workspace State Boundary Pipeline: Overview Pipeline: Workspace State Flow |
| 필요한 도구를 바로 쓰기 어렵다 | 마켓플레이스, 앱 게시, 외부 앱, 필요 도구 보강 흐름을 연결한다. | UX UI: Overview UX UI: Marketplace 화면 예정 Architecture: Marketplace Policy Architecture: App Capability Policy Architecture: AI Policy Architecture: Tool Support Policy Architecture: Runtime Boundary Pipeline: Tool Support Flow Pipeline: App Publish Flow Pipeline: AI Usage Flow |
| 사용권과 전환 조건이 제품 흐름에서 끊긴다 | 라이선스 소유자, 사용권 배정, 실행 권한, 후속 전환 조건을 같은 제품 모델 안에서 판단한다. | Architecture: License & Seat Architecture: Access Model Pipeline: Marketplace Install Flow Pipeline: App Runtime Flow |