Public / Private Boundary

한눈에 보기

KeystoneHub는 내부 운영 원천과 공개 설명 계층을 분리합니다. 이 문서는 무엇을 공개해도 되는지, 무엇은 내부에 남겨야 하는지, 그리고 공개 사이트가 어떤 역할을 맡는지 정리합니다.

• 핵심 질문: 내부 운영 지식 중 어디까지 공개 문서로 바꿀 수 있는가?
• 읽는 대상: 공개 포트폴리오의 범위와 보안 경계를 확인하려는 사람
• 연결 문서: System Architecture, Evidence Dashboard, Result Portfolio

이 문서에서 확인할 것

• private/public 저장소의 책임 경계
• 공개 가능한 설명과 공개하지 않는 데이터의 기준
• 내부 원천을 공개 문서로 바꾸는 게시 흐름

결론

Keystone의 공개 웹사이트는 keystone-portfolio 하나로 수렴합니다. 내부 운영 원천은 별도로 유지하고, 공개 사이트에는 공개 가능한 정제본만 게시합니다.

저장소 역할

저장소	공개 범위	책임
ai-rules	private	에이전트 행동 규칙, 커맨드, 스킬, 문서화 정책의 원천
pkb-wiki	private	Memory Bank 이후 선별한 결정, 실패 학습, 운영 노하우
keystone-hub	private	훅, settings, 로컬/회사/머신별 배포 자산
ai-rules-public	public	배포 가능한 ai-rules 패키지, 공개 예제, OSS 문서
keystone-portfolio	public	공개 가능한 운영 철학, 아키텍처, 사례, 포트폴리오

왜 하나의 공개 사이트인가

별도 ai-rules-astro 사이트를 유지하면 공개 문서 작성 위치가 둘로 갈라집니다. Keystone Portfolio가 이미 Astro 기반 문서 사이트이므로, 공개 해설과 포트폴리오 콘텐츠는 이곳으로 모읍니다. 대신 내부 정책 원천은 공개 저장소로 옮기지 않습니다.

검토한 대안

이 경계는 2026-05-23 내부 결정에서 아래 대안들을 비교해 확정했습니다.

대안	장점	단점	판단
별도 공개 문서 사이트를 하나 더 유지	도구 전용 브랜딩 가능	공개 사이트가 2개가 되어 문서 작성 위치가 갈라짐	기각 — 관리 포인트와 중복 증가
모든 문서를 공개 사이트로 통합	공개/비공개 구분이 단순해짐	내부 규칙, 훅, 경로, 운영 정책이 공개 계층으로 새어 나갈 위험	기각 — 비공개 원천까지 합치면 위험
비공개 원천 유지 + 공개 사이트만 하나로 수렴	원천은 유지하면서 공개 접점만 단순화	공개용 요약/정제 절차가 필요	채택 — 가장 낮은 관리 비용과 안전한 공개 경계

게시 흐름

flowchart TD
  A["Private work<br/>ai-rules / pkb-wiki / keystone-hub"]
  B["Curation<br/>remove secrets, local paths, client names, raw logs"]
  C["Public package<br/>keystone-portfolio"]
  D["OSS source<br/>ai-rules-public when reusable as a product"]

  A --> B --> C
  B --> D

공개 가능한 것

• 운영 철학과 의사결정 방식
• 추상화된 agent rules
• Memory Bank와 PKB의 역할 분리 원칙
• 실패를 규칙과 자동화로 승격하는 사례
• 공개 가능한 시스템 다이어그램
• OSS로 배포 가능한 템플릿과 예제

공개하지 않는 것

• 로컬 경로와 개인 머신 정보
• 토큰, 계정, webhook, 외부 통합 세부값
• 회사/고객명과 내부 프로젝트명
• raw session transcript
• 보안 우회 절차와 내부 스케줄러 상세
• 아직 검증되지 않은 내부 아이디어

운영 원칙

공개 사이트는 원천이 아니라 전시 계층입니다. 운영 정책은 먼저 내부 원천에서 확정하고, 공개할 가치가 있는 내용만 짧게 다시 씁니다.

• 공개 문서는 blacklist가 아니라 whitelist 방식으로 고릅니다. 기본값은 비공개이고, 공개 근거가 확인된 문서만 게시합니다.
• 공개 문서는 내부 원천의 복사본이 아니라 정제본입니다.
• 공개 사이트에는 새로운 운영 정책을 원천으로 작성하지 않습니다. 정책 변경은 먼저 내부 원천에 반영합니다.

재검토 트리거

아래 신호가 보이면 이 경계 모델을 다시 검토합니다.

• 공개 사이트가 제품 코드와 문서 사이트 역할을 분리해야 할 만큼 커진다.
• 공개 OSS 패키지에 별도 문서 사이트가 반드시 필요한 배포 요구가 생긴다.
• 공개 문서가 내부 정책 원천처럼 수정되기 시작한다.
• 공개/비공개 문서 sanitization 자동화가 필요해진다.