OSS/CSS 과립화 — 왜 내가 foundry/를 두 개로 나누었나?

Table des matières

일어나기를 기다리던 사고
- 진짜 질문
해결책 : OSS/ 및 CSS/
왜 "OSS"와 "CSS"이며 "Public"과 "Private"가 아닌가
- 완전한 나무 — 네 구역, 세 구역이 아님
특별한 경우: cheroliv.com
- bakery-gradle 신경 쓰지 않는다
거버넌스 에이전트에 미치는 영향
우리가 얻는 것 (그리고 우리가 잃는 것)
결론 : 물리적 신호가 소프트웨어 신호를 이긴다
참조

읽는 시간: 10 minutes

foundry/— 내 워크스페이스 코드를 호스팅하는 기능 영역 — 18개의 프로젝트를 포함하고 있습니다. 여덟 개는 Apache 2.0 라이선스 하에 오픈 소스입니다. 단 하나만 closed source — SaaS Edster. 몇 달 동안, 이 아홉 개의 프로젝트가 공존했습니다. 같은 폴더에 있으며, 아무것도 없이 단순히… 구분되어 있습니다. 공개/비공개 상태 그건 내 머리 속의 정보였지, 파일 시스템의 정보가 아니었어.

그리고 나서 RAG를 연결하고 싶었어요. 그러자 모든 것이 무너졌습니다.

일어나기를 기다리던 사고

2026년 4월에, 저는 slider-gradle를 위해 RAG pgvector 구현을 시작했습니다. 원칙 : 모든 저장소를 색인하는`foundry/, 생산하다 embeddings, 이를 LLM의 컨텍스트에 주입하여 그것이 하나의 perception" 파일에 대한 인식`foundry/.

파이프라인은 간단했습니다 :

val repos = fileTree(rootDir) {
    include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml")
}
val chunks = repos.map { chunk(it) }
val embeddings = chunks.map { embed(it) }
pgvector.insert(embeddings)

간단함. 효과적. 그리고위험한.

왜냐하면 이것이`fileTree`사이에 차이를 두지 않다`plantuml-gradle/` (Apache 2.0, public) 그리고`edster/`(closed source, private).그는 tudo를 다 삼킨다. 그리고 언젠가 내가 이 임베딩을 게시한다면 — 대시보드에서, 응답에서 LLM, 훈련 데이터셋에서 — Edster의 독점 코드가 유출됩니다.

문제는 LLM이 닫힌 소스 코드를 읽는 것이 아니다. 문제는, 이 코드가 공개된 벡터 임베딩에 들어가게 되는 것이다 — 되돌릴 수 없는, 삭제할 수 없는, 감사할 수 없는.

진짜 질문

이건 "LLM이 코드를 누출하는 것을 어떻게 막을 수 있나요?"가 아닙니다. 이건 "어떻게"입니다 도주를 구조적으로 불가능하게 만들 수 있나요 ?

답변은 프롬프트가 아닙니다. 답변은 폴더를 두 조각으로 자르는 것입니다.

해결책 : OSS/ 및 CSS/

foundry/
├── plantuml-gradle/       ← public
├── bakery-gradle/         ← public
├── magic-stick/           ← public
├── edster/                ← PRIVÉ
├── slider-gradle/         ← public
└── ...                    ← mélange invisible

foundry/
├── OSS/                   ← tout est Apache 2.0
│   ├── plantuml-gradle/
│   ├── bakery-gradle/
│   ├── magic-stick/
│   ├── slider-gradle/
│   └── ...
└── CSS/                   ← tout est closed source / private
    └── edster/

Le `fileTree`된다:

val ossRepos = fileTree(File(rootDir, "OSS")) {
    include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml")
}
val cssRepos = fileTree(File(rootDir, "CSS")) {
    include("**/*.adoc", "**/*.kts", "**/*.kt", "**/*.json", "**/*.yml")
}

// Embeddings publics — OSS seulement
pgvectorPublic.insert(ossRepos.map { chunk(it) }.map { embed(it) })

// Dataset fine-tuning privé — CSS seulement
fineTuningDataset.insert(cssRepos.map { chunk(it) })  // jamais publié

공개된 RAG은 결코 보지 않는다.CSS/. 폐쇄 소스 코드가 데이터셋을 공급한다 파인튜닝 없이 — 내 집에서 절대 나가지 않는 내부 모델. 그 분리는 기계적이며 선언적이지 않습니다.

왜 "OSS"와 "CSS"이며 "Public"과 "Private"가 아닌가

OSS(Open Source Software)와 CSS(Closed Source Software)라는 약어 선택 의논된 :

Public"/"Private"는가시성(GitHub이 보는 것)
OSS"/"CSS" 는 설명하는자연코드 (LLM이 알아야 할 것)

GitHub 가시성은 원격 저장소의 메타데이터입니다. 코드의 성격은 내용의 속성. LLM은 GitHub API에 접근할 수 없지만 — 그러나 접근할 수 있습니다. 파일 시스템에.CSS/`그는 그에게 "주의, 이 코드는 라이선스가 없습니다"라고 말했다. 자유" 를 읽을 필요 없이`LICENSE`또는 하나를 파싱하는`package.json.

폴더 이름은 당신이 줄 수 있는 가장 강력한 메타데이터입니다 한 LLM. 잘못 파싱될 수 없고, 무시될 수도 없고, 잘못 해석될 수도 없습니다. 이 LLM 본다`CSS/edster/`파일 경로에서 — 그는 알고 있다.

완전한 나무 — 네 구역, 세 구역이 아님

OSS/CSS 세분화는 3영역 온톨로지를 완성한다. 영역 `foundry/`기능적 하위 구역이 1에서 2로 변경됩니다 :

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260

title foundry 조직 — OSS/CSS 세분화
package "주조소/" {

  package "원 0 — 근원" #FFCCCC {
    rectangle "PICTURE_ME_ROLLIN_*.adoc" as STIM
    rectangle "WORKSPACE_*.adoc" as VISION_DOC
    note right of STIM
      Brain dump libre
      Jamais versionné
      [LLM : interdit d'indexer]
    end note
  }

  package "원 1 — 설정/" #FFD9CC {
    rectangle "비밀, 토큰" as SECRETS
    rectangle "Spring Cloud Config" as SCC
    note right of SECRETS
      Privé-CVS, solo access
      [LLM : INTERDIT]
    end note
  }

  package "원 2 — 사무실/" #FFFFCC {
    rectangle "기사, 구도" as DATA
    rectangle "훈련, SPG/SPD" as FORM
    note right of DATA
      Privé-CVS
      [LLM : filtré Vision/Opinion]
    end note
  }

  package "원 3 — 주조/" #CCE5FF {
    package "OSS/ — 아파치 2.0" #CCFFCC {
      rectangle "그레이들 플러그인" as PLUGINS
      rectangle "엔진" as ENGINE
    }
    package "CSS/ — 폐쇄 소스" #CCDDFF {
      rectangle "edster/" as EDSTER
    }
  }
}

@enduml

| 구역 | 개인정보 보호 규정 | 공개 RAG 인덱싱 | 데이터셋 파인튜닝 | | 뿌리 | 수준 0 — 친밀한 | ✗ | ✗ | | configuration/| 레벨 1 — 제한됨 | ✗ | ✗ | | office/| 레벨 2 — 협업적 | ✓ 필터된 | ✓ 필터된 | | foundry/private/| 레벨 3 — 조건부 개방 | ✗ | ✓ 비공개 | | foundry/public/| 레벨 4 — 원어민 | ✓ 무료 | ✓ 공개 |

특별한 경우: cheroliv.com

거기 있을 때, 나는 또 다른 불일치를 수정했다. 내 사이트 cheroliv.com`살고 있던`foundry/`소프트웨어 프로젝트처럼 완전한 — 자체 Gradle 빌드, 자체 CI, 자체 거버넌스.agents/`.

하지만 블로그 글은 코드가 아닙니다. 데이터입니다 사설들** 의 Cercle 2 — 같은 기준으로 프레이밍 의`office/pilotage/` 또는 형성의`office/formations/`.

AVANT                            APRÈS
foundry/                office/
  cheroliv.com/                    sites/
    site/jbake/content/blog/         cheroliv.com/
      2026/0117_....adoc               2026/0117_....adoc

변경되는 것:

물건들은 안에 있습니다.office/→ Cercle 2의 기밀성
작업`publishSite`의 하나의 능력이 된다`engine`

통해`bakery-gradle`— 플러그인이 하나를 받는다`FileTree`, 그는 모른다 기사들이 오는`office/`

한 개의 CI, 한 개의 거버넌스 — 중복 없음
Vision/Opinion 분류기(규칙 2bis)는 자동으로 적용됩니다:

기사들 안에`office/`출판 전에 필터링됩니다

bakery-gradle 신경 쓰지 않는다

그리고それが 아름다워요. 플러그인`bakery-gradle`수정되지 않았습니다. 그는 AsciiDoc 콘텐츠 디렉터리를 받고, HTML을 생성하고, 푸시한다. GitHub Pages에서. 이 디렉터리가`site/jbake/content/` ou office/sites/cheroliv/— 플러그인은 신경 쓰지 않는다.

// engine/build.gradle.kts
task("publishBlog") {
    doLast {
        val articles = fileTree("../../office/sites/cheroliv/2026/")
        bakery.generate(articles)  // ← bakery ne sait pas d'où ça vient
    }
}

인터페이스 계약은 Gradle 작업입니다. REST API가 아닙니다. 웹훅이 아닙니다. 한 작업 — 타입이 지정된, 테스트 가능한, 로컬 및 CI에서 실행 가능한.

거버넌스 에이전트에 미치는 영향

OSS/CSS 세분화는 세 가지 측면에서 에이전트 거버넌스를 변경합니다:

RAG public : 색인 범위가 이동됩니다`foundry/**`

à foundry/public/+office/Vision/. 폐쇄 소스 코드 작업 구성에 의해 인덱스에서 제외되며, 프롬프트에 의해 제외되지 않습니다.

Knowledge Graph : graphify-gradle 두 개의 그래프를 생성합니다 :

*office/graph.json(public) — OSS 아티팩트와 office/Vision 사이의 관계 *configuration/graph_private.json(gitignored, 비공개의) — 관계 사이 CSS 아티팩트, 절대 게시되지 않음

데이터셋 파인튜닝 :`codebase-gradle`이제 두 개의 출처가 있습니다:

*OSS/→ 공개 데이터세트 (커뮤니티 모델, 벤치마크) *CSS/→ 개인 데이터 세트 (내부 모델, 독점적 파인튜닝)

우리가 얻는 것 (그리고 우리가 잃는 것)

이전 (평면 폴더)

다음에 (OSS/CSS + office/sites)

ls foundry/→ 공공/사적 혼합

ls foundry/public/→ 모든 것이 게시 가능합니다

RAG는 차별 없이 모든 것을 인덱싱합니다.

RAG은 인덱싱합니다`OSS/`+`office/Vision`오직

프로젝트가 오픈 소스인지 알 수 없습니다.

길`OSS/` ou `CSS/`위에서 언급한

cheroliv.com은 자체 CI, 자체 거버넌스를 가지고

CI와 거버넌스는 engine 내에서 공유됩니다.

블로그 글은 "code" 저장소에 있습니다.

블로그 게시물은`office/sites/`— 데이터, 코드가 아님

공개 임베딩에서의 폐쇄 소스 코드 유출 위험

구조적으로 불가능 —`CSS/`범위를 벗어난 RAG

유일한 비용 : 하나`git mv`전 세계 17개 OSS 저장소에 대한 + 리팩터링된 build.gradle.kts de engine. 이것은 콜드 마이그레이션 — 비행 중인 데이터도 없고, 영향을 받은 사용자도 없습니다.

결론 : 물리적 신호가 소프트웨어 신호를 이긴다

오늘 오후에 내가 한 일은 보이지 않는 관행을 대체한 것이었다. 구역 안에서 보이는 분리로`foundry/.이전에는, 당신은 해야 했습니다. 알다 고`edster/`폐쇄 소스였습니다. 이제 당신이 그것을 봅니다 — 폴더 이름은`CSS/.

이것은 Unix 권한, 네트워크 VLAN, 또는 그것과 동일한 원리입니다. 데이터베이스의 방화 구획. 보안은 해서는 안 된다 당신이 기억해야 할 정보여야 합니다. 그것은 속성이어야 합니다. 물리학시스템의.

OSS/CSS 세분화는 이 분야에서의 이 원칙의 번역이다. LLM 거버넌스. LLM은 Edster가 무엇인지 알 필요가 없습니다. 기밀. 그는 그것을 색인할 수 없어야 한다.

그리고 그것은 정확히`CSS/`보장한다

일어나기를 기다리던 사고

진짜 질문

해결책 : OSS/ 및 CSS/

왜 "OSS"와 "CSS"이며 "Public"과 "Private"가 아닌가

완전한 나무 — 네 구역, 세 구역이 아님

특별한 경우: cheroliv.com

bakery-gradle 신경 쓰지 않는다

거버넌스 에이전트에 미치는 영향

우리가 얻는 것 (그리고 우리가 잃는 것)

결론 : 물리적 신호가 소프트웨어 신호를 이긴다

참조

관련 기사