PlayGround: 컴포넌트의 피팅룸
UI 기능을 페이지에 직접 작성하면 한 곳을 고치면 모든 곳이 영향을 받고, 버튼 하나를 조정하려면 전체 페이지를 실행해야 합니다. 해결책은 독립적인 컴포넌트 PlayGround를 먼저 만드는 것입니다: 각 UI 요소마다 별도의 demo가 있고, 완성된 후 정식 페이지에 통합합니다.
아래는 최소한의 PlayGround입니다: 왼쪽은 컴포넌트 실시간 미리보기, 오른쪽은 파라미터 컨트롤입니다. 마음껏 조정해 보세요 — 여기서 어떤 변경을 해도 페이지의 다른 것에는 영향을 주지 않습니다. 이것이 "격리 디버깅"입니다.
PlayGround에서 조정하기
방금 한 모든 조정은 이 하나의 demo에만 영향을 미쳤습니다. 스타일과 비즈니스 로직이 서로 간섭하지 않으며, 완성된 파라미터를 정식 컴포넌트에 그대로 적용하면 통합 시 이미 완성품입니다.
페이지에 직접 작성하면 어떻게 될까요
같은 버튼을 조정하려면: 먼저 전체 페이지를 실행하고, 로그인하고, 데이터를 불러오고, 목표 상태로 이동해야 한 번 볼 수 있습니다. 스타일과 비즈니스 로직이 뒤엉켜 있어, 모서리 반경을 크게 하면 옆 레이아웃이 틀어질 수 있습니다. 실 하나 당기면 전체가 풀립니다.
같은 아이디어, 다른 비용. Storybook은 업계 표준이지만 설정이 너무 무거워 AI 지원 빠른 프로토타이핑 프로젝트에는 과도합니다. PlayGround는 그 아이디어를 빌려옵니다: 하나의 정적 페이지에 모든 컴포넌트 demo를 나열하고, 컴포넌트를 변경해도 비즈니스 로직에 영향을 주지 않으며, 비즈니스 로직을 조정해도 컴포넌트 스타일이 흐트러지지 않습니다. 비용은 거의 없습니다.
애니메이션은 반드시 먼저 만들어야 합니다
페이지 애니메이션이 포함될 때는 반드시 먼저 정적 페이지 PlayGround를 만들어 컴포넌트를 자유롭게 조정하고 테스트한 후, 그다음에 정식 페이지에 작성해야 합니다.
요구사항이 바뀌면 demo도 따라 바뀝니다
요구사항이 변경된 후에는 반드시 PlayGround를 동기화 업데이트해야 합니다. demo가 항상 컴포넌트의 최신 형태를 반영하도록 유지하고, 낡은 장식이 되지 않도록 하세요.
취소된 요구사항의 demo도 보존합니다
demo 컴포넌트는 추가하거나 수정만 할 수 있고 삭제할 수 없습니다. 기능 요구사항이 취소되어도 해당 demo는 보관합니다. 설계 과정의 역사적 기록이며, 나중에 요구사항이 부활할 때 바로 재사용할 수 있습니다.
세 가지 실제 시나리오입니다. 올바르다고 생각하는 방법을 선택하고 판정과 이유를 확인하세요.
대화 테스트 페이지가 필수입니다
프로젝트에 AI 대화 기능이 포함될 때, PlayGround에 간단한 대화 테스트 페이지를 반드시 구현해야 합니다. 전체 비즈니스 플로우 없이도 단독으로 한 라운드의 대화를 테스트할 수 있어야 합니다.
모든 Prompt를 나열하세요
페이지에 프로젝트에서 사용하는 모든 Prompt를 나열해야 합니다. Prompt는 AI 제품의 핵심 자산입니다. 코드 문자열 안에 숨어 있으면 디버깅할 수 없고, 페이지에 펼쳐야 빠르게 비교하고 조정할 수 있습니다.
컴포넌트는 피팅룸에서 먼저 완성하고, 그다음 무대에 올립니다. PlayGround는 하나의 정적 페이지 비용으로 컴포넌트와 비즈니스 로직 간의 양방향 격리를 얻습니다.
출처: rule-opensource.mdc 3장 "PlayGround 컴포넌트 페이지 규범", 저장소 itshen/xs_vibe_rules.