플러그인 생태계 사이트

플러그인 디렉터리는 신뢰를 얻거나 잃는 장소입니다. 방문자는 수식어가 아니라 사실을 원합니다. 플러그인이 무엇을 하는지, 누가 유지보수하는지, 프로덕션 준비가 되었는지, 어떻게 설치하는지, 실제 EmDash 스택에서 어떻게 동작하는지를 알고 싶어합니다. 구조화된 공개 사이트는 흩어진 README 조각 대신 일관된 페이지로 이런 질문에 답하게 해줍니다.

각 플러그인 페이지가 증명해야 할 것

먼저 결과를 제시하세요: 해결하는 문제, 지원 환경, 운영 발자국(Workers, D1, 외부 API). 이어서 호환성, 버전 관리, 라이선스를 명시합니다. 소스 코드, 다운로드, 심화 문서 링크도 눈에 띄게 배치하세요. 베타 상태라면 명확히 표시하고, 데이터와 가용성 측면에서 베타가 의미하는 바를 설명해야 합니다.

구체적인 적용 단계

1. 단일 페이지 템플릿을 정의하세요. 표준 필드는 상태, 카테고리, 버전, 가격 모델, 호환성, 저장소 링크, 변경 이력을 포함할 수 있습니다. 일관성은 사용자의 빠른 비교를 돕습니다.

2. 현실과 맞는 설치 가이드를 공개하세요. 현재 저장소 구조에서 실제로 동작하는 명령과 설정 스니펫을 우선합니다. 예를 들어 EmDash 모노레포에서 packages/plugins/<name>가 기준이라면 그 기준으로 안내합니다.

3. 의미 있는 변경마다 릴리스 노트를 발행하세요. 짧은 불릿 목록이라도 무기록보다 낫습니다. 가능하면 GitHub 비교 보기나 태그 릴리스를 링크합니다.

4. 신뢰 신호를 추가하세요. 유지보수자 이름, 지원 채널, 보안 기대치는 채팅이 아니라 페이지에 있어야 합니다. 서드파티 API를 호출하는 플러그인은 필요한 시크릿과 레이트 리밋도 문서화하세요.

5. 사용 사례를 교차 연결하세요. 플러그인이 여는 시나리오와 연결합니다: Forms는 리드 수집, Webhook Notifier는 자동화, Audit Log는 다중 편집자 팀 운영.

예시: 신규 플러그인 등재 전 점검

페이지를 공개하기 전에 다음 체크리스트를 확인하세요: 한 줄 설명이 실제 코드 내보내기와 일치하는가? 스크린샷/다이어그램이 정확한가? 라이선스가 맞는가? 신규 사용자가 내부 지식 없이 설치할 수 있는가? 하나라도 “아니오”라면, 홍보 전에 그 격차를 먼저 수정하세요.

운영 주기

매월: 열린 이슈를 검토하고 상태 필드를 갱신합니다. 분기별: 방치된 항목을 폐기하거나 “unmaintained”로 표시하고 마이그레이션 메모를 남깁니다. EmDash 주요 릴리스 후: 상위 플러그인을 재검증하고 호환성 문자열을 업데이트합니다.

결과

빌더는 플러그인을 더 빠르게 발견하고, 예상치 못한 문제를 줄인 채 도입하며, 생태계를 브로셔가 아닌 진지한 인프라로 인식하게 됩니다.