코어 무수정 확장 API 확정 필요

[jiwonpapa]

수고 많으십니다.

업로더, 썸네일 서버를 작성해서 배포해 보려니 코어 수정은 아니더라도 템플릿, 다른 모듈에 손대야할 부분이 생겨서 이러면 안되겠다 싶어 보류 했습니다.
기본 제공 모듈끼리 서로 강하게 연결된 부분도 문제가 있습니다. 게시판만 따로 배포되는게 있는데 교체 한다면 다른 기본 모듈도 수정해야 됩니다.

소스보면 마켓플레이스를 운영할듯 한데 워드프레스처럼 바로 설치가 되어야 합니다.

초기 SIR 컨텐츠 몰에서 수백건 판매 했지만 가장 많은 요청이 설치입니다.
모듈, 플러그인 api 가 확정되고 코어나 의존성 모듈들을 수정 없이도 교체가 가능하도록 요청합니다.

뭔가 만들어 배포하려니 많이 걸립니다. 그누7이 빠른 확산을 위해 성능튜닝 및 모듈,플러그인 api 확정이 시급하다 하겠습니다.

아래는 역시나 코덱스로 분석해서 간단하게 정리해봤습니다. 첨삭하지 않은 코덱스 의견?입니다.

[P0][아키텍처] 마켓플레이스 전 코어 무수정 확장 API 확정 필요

결론
그누보드7이 모듈·플러그인 마켓플레이스를 운영하려면, 제3자 개발자가 코어·기본 모듈·템플릿을 수정하지 않고 제품을 설치·배포할 수 있어야 합니다. 현재는 패키지를 분리해 설치하는 기반은 있지만, 게시판·쇼핑몰·템플릿이 서로의 구체 구현과 URL·DB 구조를 직접 아는 부분이 남아 있습니다. 특히 업로더·썸네일·이미지 최적화처럼 사이트 전체에 적용돼야 하는 플러그인은 설치만으로 모든 화면과 모듈을 바꿀 수 없습니다. 마켓 화면보다 장기 호환되는 코어 확장 API와 성능 기준을 먼저 확정해야 합니다.

항목	판정
우선순위	P0 — 마켓 개발 전 최우선
현재 상태	독립 모듈 개발은 가능하지만 기존 기능의 설치형 교체는 미준비
핵심 위험	제3자 개발자가 모듈·템플릿별 패치를 떠안아야 함
제품 영향	플러그인 공급 부족, 업데이트 호환성 저하, 마켓 신뢰 하락
감사 기준	fcaacad8d16d47a8b5bcee65990869992de0a0d8 · 정적 코드 검토

관리자 모듈·플러그인·템플릿 화면에 비활성화된 marketplace_button이 존재하므로, 본 이슈는 제3자 마켓플레이스 도입 계획을 전제로 합니다. admin_plugin_list.json:260-263

이 판단이 맞는가

대체로 맞습니다. 마켓플레이스는 판매 화면이 아니라 개발자 공급망입니다. 개발자가 하나의 공개 API만 구현해 여러 사이트에 배포할 수 있어야 상품이 쌓입니다. 반대로 게시판·쇼핑몰·템플릿마다 별도 수정이 필요하면 개발·테스트·고객지원 비용이 반복되고, 코어 업데이트마다 호환성 위험이 커집니다. 이 구조에서는 무료 플러그인도 유지하기 어렵고 상용 플러그인은 더 만들기 어렵습니다.

다만 세 가지는 구분해야 합니다.

• 자체 API·UI를 모두 가진 독립 모듈의 수동 배포는 현재도 가능합니다. 이 이슈가 P0라는 판정은 미디어·에디터·결제처럼 기존 기능을 설치만으로 확장·교체하는 마켓을 목표로 할 때 적용됩니다.
• API 확정은 영구 동결이 아니라 공개 범위, 버전 규칙, 호환 기간, 폐기 절차와 자동 호환성 테스트를 확정한다는 뜻입니다.
• 전면 성능 튜닝 전체를 최고 P0로 볼 근거는 아직 부족합니다. 대신 성능 기준선·허용 예산·회귀 차단은 P0로 즉시 만들고, 확장 API 설계·기본 모듈 전환과 병행해 측정된 병목만 최적화해야 합니다. 곧 교체할 구체 구현을 먼저 튜닝하면 재작업이 발생합니다.

따라서 권장 순서는 다음과 같습니다.

1. 코어 확장 API와 모듈 경계를 확정합니다.
2. 설치·활성화·비활성화·업데이트와 패키지 신뢰 기준을 확정합니다.
3. 게시판·쇼핑몰·기본 템플릿도 그 API만 사용하도록 전환합니다.
4. 같은 서버·데이터·부하 조건의 성능 기준과 허용 퇴행 범위를 CI에 고정합니다.
5. 실제 외부 플러그인으로 코어 무수정 전체 흐름을 검증합니다.
6. 그 뒤 마켓 카탈로그·구매·배포 기능을 엽니다.

현재 가장 심각한 문제

1. 분리된 패키지와 교체 가능한 모듈은 다르다

모듈·플러그인 디렉터리가 분리돼 있다는 사실만으로 추상화가 끝난 것은 아닙니다. 기본 사용자 템플릿은 sirsoft-board, sirsoft-ecommerce, sirsoft-page를 필수 모듈로 직접 지정합니다.

• sirsoft-basic/template.json:25-34

이커머스 모듈은 manifest에 다른 모듈 의존성을 선언하지 않았지만, 상품문의 Listener는 sirsoft-board.post.after_delete 훅을 직접 구독합니다. 이는 모듈 간 숨은 의존입니다. module.json:12-17, ProductInquiryBoardListener.php:36-47

결제 플러그인도 공통 주문·결제 API 대신 이커머스 주문·결제 테이블을 직접 조회합니다.

• sirsoft-pay_kginicis/AdminTransactionController.php:48-54

따라서 별도 쇼핑몰 모듈을 만들어도 기본 템플릿과 기존 결제 플러그인이 자동으로 새 쇼핑몰을 사용하지 않습니다. 모듈 파일은 분리돼 있지만 생태계 차원의 교체 API는 부족합니다.

특정 쇼핑몰 전용 결제 플러그인이 해당 쇼핑몰의 공개 API에 의존하는 것은 정상입니다. 심각한 문제는 내부 Model·DB 테이블·고정 URL을 직접 사용하거나, 기본 템플릿이 여러 모듈의 구체 식별자를 필수로 요구하는 것입니다.

2. 실제 업로더·썸네일 서버가 설치만으로 전체 적용되지 않는다

외부 업로더·썸네일 서버를 플러그인으로 만들어도 게시판, 페이지, 상품, 카테고리, 리뷰가 서로 다른 업로드 서비스와 훅을 사용합니다.

• 코어 첨부: AttachmentService.php:47-68
• 게시판 첨부: sirsoft-board/AttachmentService.php:51-76
• 상품 이미지: ProductImageService.php:54-86
• 상품 리뷰 이미지: ProductReviewImageService.php:48-75

화면도 게시판·쇼핑몰 업로드 URL을 직접 지정합니다.

• 게시판 작성 화면: _post_form.json:660-682
• 상품 이미지 화면: _partial_image_upload.json:80-103

이 때문에 코어 파일을 수정하지 않더라도 기본 템플릿과 게시판·쇼핑몰 모듈을 수정하거나, 각 내부 구조에 맞춘 별도 패치를 계속 유지해야 합니다. 마켓에서 기대하는 “설치 → Provider 선택 → 사이트 전체 적용”이 아닙니다.

3. 기본 모듈이 공개 API를 우회하면 추상화는 작동하지 않는다

코어에 Provider 인터페이스만 추가해서는 부족합니다. 게시판·쇼핑몰·페이지·기본 템플릿이 파일 저장, 이미지 URL, 주문, 결제를 직접 처리하면 플러그인은 다시 각 구현을 따라가야 합니다.

문제는 훅의 개수가 아니라, 코어·모듈·템플릿이 동일한 공개 API를 반드시 사용하도록 보장되어 있지 않다는 점입니다.

필요한 구조는 다음과 같습니다.

제3자 플러그인 → 코어 공개 확장 API → 게시판·페이지·쇼핑몰·모든 템플릿

코어와 모든 기본 모듈이 같은 API를 의무적으로 사용하고, 이를 우회하는 직접 참조를 CI에서 차단해야 합니다.

WordPress 유명 플러그인을 G7에 적용한다면

대표 사례	WordPress	현재 G7 판정
Smush 이미지 최적화	공통 이미지 처리 Filter와 Attachment API를 통해 게시물·테마·WooCommerce에 적용	하나의 MediaProvider만으로 게시판·페이지·상품·리뷰·템플릿 전체 교체 불가
WPBakery 페이지 빌더	플러그인 설치로 편집·출력 기능 확장	html_editor 교체점은 있으나 직접 HtmlEditor/HtmlContent를 쓰는 화면까지 강제하지 못해 부분 가능
Stripe for WooCommerce	WooCommerce 주문·결제 흐름에 플러그인으로 연결	번들 쇼핑몰 안의 결제수단 추가는 가능하지만, 기존 PG가 이커머스 구현·테이블에 직접 의존해 대체 쇼핑몰에서는 재사용 어려움
Bookly 예약	예약 기능을 독립 플러그인으로 설치하고 결제·알림과 연동	독립 예약 모듈은 만들 수 있으나 공통 예약·결제·콘텐츠 API가 없어 통합마다 별도 연결 필요
Yoast SEO	공통 메타·사이트맵 훅으로 사이트 전체 확장	G7은 SeoRendererInterface, SitemapContributorInterface가 있어 상대적으로 준비된 영역

WordPress의 핵심은 플러그인 수가 아니라 코어와 WooCommerce·테마가 같은 공통 API를 사용한다는 점입니다. G7도 기본 모듈부터 이 원칙을 지켜야 제3자 플러그인이 설치만으로 작동합니다.

위 비교는 각 제품의 공식 설치 흐름 기준입니다. 개별 테마나 다른 플러그인의 비표준 구현까지 항상 호환된다는 뜻은 아닙니다.

왜 P0이며 ROI가 높은가

• 하나의 공통 API가 미디어, 에디터, 예약, 결제, SEO, 자동화 등 여러 상품 카테고리를 동시에 엽니다.
• 지금 경계를 확정하면 기본 모듈 수가 늘기 전에 직접 결합을 제거할 수 있습니다. 늦을수록 이전 비용과 호환성 부채가 커집니다.
• 개발자 한 명이 여러 고객에게 같은 패키지를 판매할 수 있어야 공급자가 붙습니다.
• 사용자는 코어 업데이트와 플러그인 업데이트를 독립적으로 할 수 있어야 유료 상품을 신뢰합니다.
• 마켓 UI를 먼저 만들어도 설치 후 충돌하거나 소스 수정이 필요하면 상품 공급과 재구매가 생기지 않습니다.

이 작업은 단일 기능 추가가 아니라 외부 개발자 수와 제품 출시 속도를 함께 늘리는 기반 투자입니다. 마켓플레이스 계획이 있다면 가장 높은 ROI의 선행 과제 중 하나로 보는 것이 타당합니다.

P0에서 확정할 최소 범위

1. 확장 API 정책

   • 공개 API 범위, 버전 규칙, 호환 기간, 폐기 절차
   • 확장이 제공·요구하는 기능과 기본 Provider 선택 방식
   • 확장 개발 문서에서 코어·기본 모듈·템플릿 직접 수정을 요구하지 않는 원칙

2. 우선 공개 API

   • 미디어: 업로드, 변환, 썸네일, URL, 기존 이미지 재생성, 업로더 UI
   • 콘텐츠: 게시판 읽기·쓰기·렌더링
   • 쇼핑몰: 상품, 주문, 결제, 환불
   • 편집기·폼·블록 등록
   • 예약 실행·예약 게시·작업 재시도

3. 기본 모듈 전환

   • 게시판·쇼핑몰·페이지·기본 템플릿도 위 API만 사용
   • 다른 모듈의 내부 Model·Service·테이블·URL 직접 참조 금지
   • 꼭 필요한 결합은 별도 연결 플러그인으로 분리

4. 안전한 설치 수명주기

   • 설치·활성화·비활성화·삭제·업데이트 상태를 모든 Route·Hook·Job에 동일 적용
   • 패키지 서명, 의존 버전, 업데이트 실패 복구

5. 호환성과 성능 자동 검증

   • 과거 버전 플러그인 호환성 테스트
   • 모듈 조합별 설치·활성화·비활성화 테스트
   • 같은 서버·데이터·부하 조건의 응답시간·메모리 기준
   • 확장 API 도입 전후 성능 퇴행 차단

완료 기준

다음 시험을 통과하기 전에는 범용 마켓 준비 완료로 판정하지 않습니다.

• 외부 MediaProvider 하나를 설치하고 관리자에서 한 번 선택하면 코어·게시판·페이지·상품·리뷰의 업로드와 목록·상세 이미지가 모두 바뀝니다.
• 위 시험에서 코어·모듈·템플릿 수정이 0건입니다.
• 대체 게시판 모듈을 설치해도 기본 템플릿이 구체 모듈 ID 변경 없이 작동합니다.
• 대체 쇼핑몰 모듈에서도 기존 결제 플러그인이 공개 주문·결제 API만으로 작동합니다.
• 코어 업데이트 시 지원 중인 기존 플러그인의 호환성 테스트가 통과합니다.
• 비활성화된 플러그인의 Route·Hook·Job이 실행되지 않고, 의존 버전이 맞지 않는 패키지는 설치되지 않습니다.
• 확장 API를 거치는 주요 요청이 정한 성능 기준을 넘지 않습니다.
• CI가 다른 모듈의 내부 클래스·테이블·URL 직접 참조를 차단합니다.

최종 제안

코어 확장 API 확정, 기본 모듈의 직접 결합 제거, 안전한 설치 수명주기를 마켓플레이스 선행 P0로 지정해야 합니다. 성능은 전면 튜닝이 아니라 같은 P0 트랙에서 기준선·예산·회귀 차단을 먼저 만들고, 확인된 병목만 병행 개선해야 합니다. 이후 실제 업로더·썸네일 Provider를 기준 플러그인으로 만들어 코어·게시판·쇼핑몰·템플릿 수정 0건을 증명한 뒤 마켓 기능 개발로 넘어가는 순서가 적절합니다.

[HeuJung]

@jiwonpapa

안녕하세요. 상세한 분석과 제안 감사드립니다. 지적해주신 내용을 항목별로 답변드립니다.

1. 기본 사용자 템플릿이 게시판/커머스/페이지 모듈에 의존하는 문제
현재 기본 사용자 템플릿은 번들 모듈 3종과 플러그인 1종을 의존으로 선언하고 있어, 유저가 별도 개발한 게시판 모듈로 교체하려면 템플릿 수정이 필요합니다.

현재 그누보드7에 포함된 사용자 템플릿이 1종뿐이라 도메인/디자인별로 다양한 선택지를 제공해드리지 못한 점은 저희도 미흡하다고 생각합니다. (SIR 커뮤니티에서도 이 점에 대해 많은 분들이 지적해주셨습니다) 다만, 한정된 인력과 일정 안에서 안정성과 완성도를 끌어올리는 것을 최우선순위로 두다 보니 근시일 내 대응은 어려운 점 양해 부탁드립니다.

이 부분은 로드맵에 포함해 진행하겠습니다.

2. 업로드 서비스가 코어와 모듈별로 분리되어 있는 점
게시판과 쇼핑몰은 성격이 다른 비즈니스 도메인이라 첨부 처리도 설계를 분리한 것으로, 이는 설계 당시에 의도한 부분입니다.

다만 말씀해주신 것처럼 첨부파일 처리는 코어의 공통 계층을 바라보는 편이 확장성에 유리한 측면이 있습니다. 특히 업로더/썸네일처럼 사이트 전역에 적용되어야 하는 영역을 공통 API로 끌어올리는 방향을 검토하여 개선 여부를 결정하겠습니다.
(현재 본인인증/알림 인프라는 코어에서 공통 로직을 제공하고, 플러그인/모듈이 확장할 수 있는 구조로 되어 있는데, 유사한 설계를 반영하는 형태로 고려해 보겠습니다)

3. 결제 플러그인이 커머스 모듈에 의존하는 점
번들 결제 플러그인들은 기본 제공 커머스 모듈 전용으로 설계되어 있습니다. 그누보드7 코어는 인증 등 공통 기반만 제공하고, 각 도메인 모듈 위에 플러그인이 붙는 구조입니다. 특정 쇼핑몰 전용 결제 플러그인이 그 모듈에 의존하는 것 자체는 설계 의도에 해당되는 부분입니다.

다만 말씀하신 대로, 플러그인이 모듈의 공개 API가 아니라 내부 테이블을 직접 조회하는 부분은 별개 이슈입니다. 확인 결과 관리자 거래조회 기능이 ecommerce_order_payments / ecommerce_orders 테이블을 직접 join하고 있습니다. 이 부분은 커머스 모듈이 결제 조회용 공통 인터페이스를 노출하고 플러그인이 공통 인터페이스만 의존하도록 정리하는 것이 맞다고 생각됩니다.

커머스 모듈이 게시판 훅을 구독하면서 module.json에 의존을 선언하지 않은 부분도 함께 확인했습니다. 이 부분도 함께 바로잡도록 하겠습니다.

4. 마켓플레이스
말씀해주신 대로 그누보드7은 마켓플레이스 운영을 염두에 두고 설계하였습니다. 그누보드7이 GitHub 링크를 통해 사용자 파일 업로드 없이 설치/업데이트를 지원하는 것도 이를 위한 사전 설계입니다. 다만 마켓플레이스 오픈은 상당한 공수가 필요한 작업이라 시간이 걸립니다. 향후 로드맵에 포함해 진행하겠습니다.

다만 현 단계에서는 안정화가 최우선이라 제안해주신 범위를 한 번에 반영하기는 어려운 점 양해 부탁드립니다. 상세한 로드맵은 늦지 않은 시기에 SIR 커뮤니티를 통해 공유드리겠습니다.

좋은 의견 감사합니다.

[glitter-gim]

@jiwonpapa

안녕하세요.

업로더와 썸네일 서버를 만들어 배포하려 하셨다면,
우선 현재 제공되는 모듈과 플러그인 구조를 이용해서
실제 제품을 하나 구현하고 배포하는 과정에서 확인되는 한계를 바탕으로 논의하는 것이 더 설득력이 있다고 생각합니다.

먼저 구분해야 할 것은 범용 확장 개발과 개별 사이트 커스터마이징은 서로 다른 영역이라는 점입니다.

범용으로 배포할 플러그인이라면 지원 대상을 명확히 정하고,
해당 모듈이 제공하는 공개 구조와 확장 지점을 이용하여 구현하는 것이 맞습니다.
반대로 특정 사이트에 맞춘 통합 기능이라면 번들 모듈이나 템플릿을 필요한 형태로 커스터마이징하는 것도 자연스러운 개발 방식입니다.

이 두 경우는 요구사항과 목표가 다르므로 같은 기준으로 판단하기는 어렵습니다.

게시판 첨부파일, 상품 이미지, 리뷰 이미지 등은 각각 목적과 처리 방식이 다릅니다.
따라서 사이트 전체의 업로드와 썸네일 방식을 하나의 플러그인으로 교체하려면 각 기능과 연결 작업이 필요한 것도 자연스러운 일입니다.
이것만으로 현재 구조가 잘못되었다고 보기는 어렵습니다.

그런데 실제 구현과 배포를 통해 확인된 구체적인 한계가 제시되기 전에, 제품 전체의 아키텍처 개선을 P0 과제로 일반화하기에는 아직은 근거가 더 필요해 보입니다.

먼저 실제 제품을 만들어 보면서 현재 구조로 해결 가능한 부분과 정말 공개 API가 부족해서 해결할 수 없는 부분을 구분하는 과정이 필요합니다.
실제 구현과 배포를 거친 뒤에도 특정 기능이 반드시 코어나 다른 모듈의 내부 구현을 수정해야만 가능하다면,
그 지점을 근거로 필요한 API를 제안하는 것이 더 적절한 접근이라고 생각합니다.

이러한 검증 과정을 거치기 전에,
WordPress 수준의 공통 미디어 API와 제품 전반의 확장 구조를 P0 과제로 함께 제안하는 것은 다소 범위를 넓게 해석한 접근으로 보입니다.

확장 API는 처음부터 모든 가능성을 고려해 한 번에 완성하는 것이 아니라,
실제 모듈과 플러그인을 개발하고 배포하는 과정에서 반복적으로 확인되는 한계를 공통 API로 보완해 가는 방식이 더 현실적이고 안정적이라고 생각합니다.

[jiwonpapa]

의견 감사합니다. 다만 이 이슈는 개별 사이트 커스터마이징 사례를 전체 아키텍처 문제로 일반화한 것이 아닙니다.
업로더·썸네일 서버는 이미 범용 배포를 목적으로 구현했습니다. 그러나 그누보드7 공식 구성인 코어·게시판·쇼핑몰·기본 템플릿에 적용하려면 각 모듈의 업로드 경로와 템플릿을 별도로 수정해야 했습니다. 배포하지 않은 이유가 바로 이것입니다. 따라서 “먼저 배포해서 검증해 보라”는 제안은, 배포를 막는 구조적 한계를 배포 후 다시 증명하라는 순환 논리가 됩니다.
지원 대상도 불명확하지 않습니다.
그누보드7 코어 + 공식 번들 게시판 + 공식 번들 쇼핑몰 + 기본 템플릿

이 공식 구성에서조차 플러그인 설치와 Provider 선택만으로 전체 업로드·썸네일 경로를 교체할 수 없다면, 마켓에서 판매할 범용 플러그인이라고 보기 어렵습니다.
게시판 첨부, 상품 이미지, 리뷰 이미지의 처리 방식이 서로 달라야 한다는 점에는 동의합니다. 그러나 이것은 공통 API가 불필요하다는 근거가 아닙니다. 공통 Media API가 사용 위치와 정책을 전달하고, 각 기능이 서로 다른 설정을 적용하도록 설계하면 됩니다.
핵심은 “연결 작업이 있느냐”가 아닙니다.
플러그인이 공개 API를 통해 연결하는 것은 정상입니다.
공식 모듈·템플릿 소스를 직접 수정해야 하는 것은 마켓용 플러그인 구조가 아닙니다.
모듈은 어떤 플러그인이 설치됐는지 몰라야 하며, 선택된 공통 Provider만 사용해야 합니다.
플러그인도 게시판·쇼핑몰의 내부 클래스, DB 테이블, 고정 URL을 몰라야 합니다.
현재는 게시판·페이지·상품·리뷰의 업로드 경로가 분산돼 있고, 기본 템플릿은 구체 모듈과 업로드 URL을 직접 사용합니다. 이커머스와 게시판 사이에는 manifest에 선언되지 않은 훅 의존도 있으며, 결제 플러그인은 이커머스 내부 테이블까지 직접 조회합니다. 이미 구체적인 코드 근거와 실제 구현 경험이 모두 제시된 상태입니다.
P0 제안도 “WordPress의 모든 API를 한 번에 구현하자”는 뜻이 아닙니다. 마켓을 열기 전에 최소한 다음 원칙을 확정하자는 것입니다.
코어·공식 모듈·기본 템플릿은 동일한 공개 확장 API를 사용합니다.
제3자 확장에 코어·모듈·템플릿 수정을 요구하지 않습니다.
공개 API는 버전·호환 기간·폐기 절차를 보장합니다.
실제 MediaProvider 하나로 설치형 교체가 가능한지 먼저 증명합니다.
확장 API를 실제 요구에 따라 발전시키는 것은 맞습니다. 그러나 최소 기준조차 없는 상태에서 제3자 개발자에게 먼저 제품을 배포하라고 할 수는 없습니다. 마켓 출시 후 API를 정리하면 초기 개발자들이 그 비용과 호환성 위험을 떠안게 됩니다.
그누보드7이 그누보드5와 달라지려면 사용자가 소스를 고쳐 쓰는 구조가 아니라, 설치와 설정만으로 기능을 추가할 수 있어야 합니다. 혼자 사용하는 사이트라면 커스터마이징으로 해결할 수 있지만, 지금 논의하는 대상은 제3자 개발자와 일반 사용자가 참여하는 마켓 생태계입니다.
따라서 먼저 아래 기준 플러그인으로 검증하면 됩니다.
외부 업로더·썸네일 Provider 설치
→ 관리자에서 한 번 선택
→ 게시판·페이지·상품·리뷰의 업로드와 목록·상세 이미지가 모두 교체
→ 코어·모듈·템플릿 수정 0건

이 시험이 현재 공개 API만으로 통과된다면 P0 범위를 줄일 수 있습니다. 통과하지 못한다면 그것이 바로 보완해야 할 API가 구체적으로 확인된 것입니다.

[glitter-gim]

@jiwonpapa

추가 설명을 요청드린 것은 아닙니다.
제가 제기한 핵심은 원 이슈의 결론과 P0 판단을 뒷받침할 근거가 충분히 제시되지 않았다는 점입니다.

"범용 배포를 목적으로 구현했지만 공식 구성에 적용하지 못해 보류했다"는 설명만으로는 그 근거가 보완되었다고 보기 어렵습니다.
실제 구현 과정에서 어떤 수정이 불가피했는지 검증 가능한 자료, 기존 공개 API로 해결할 수 없었던 지점, 공식 모듈·템플릿에 필요했던 수정 내역 등 객관적으로 확인 가능한 자료가 함께 제시되어야 한다고 생각합니다.

현재 제시된 설명만으로는 기존 주장에 새로운 검증 근거가 추가되었다고 보기는 어렵습니다.
먼저 해당 구현과 실패 지점을 검증할 수 있는 구체적인 근거를 제시한 뒤, 그 근거를 바탕으로 제품 전체의 확장 API를 P0 우선순위로 다루어야 하는지 논의하는 것이 적절하다고 생각합니다.

짧은 소견에 귀 기울여 주셔서 감사합니다.