근거: CONSTITUTION.cst.md 제6조
소관: 도구·기밀정보의 공개서버 유출 방지
공용 서비스 서버(프로덕션, 고객 대면)로 나가는 모든 배포 작업 전, 배포 목록에서
다음을 검사한다.
1. _로 시작하는 모든 경로 — 발견 시 배포 목록에서 제외
2. secret이 포함된 모든 경로 — 발견 시 배포 목록에서 제외
3. .git 이력에 위 항목이 과거 커밋된 적 있는지 여부
대표 본인이 직접 조사·수집한 원본, 또는 우리만의 판단 모델은 bm/a 동기화 트리
바깥(예: 각 기기 로컬 ~/_local_only/)에 보관한다. bm/a 안에 두면 함대 전체로
자동 전파되어 기밀성이 깨진다(reference_market_research_lead_delegation.md 참조).
① 이름에 "secret"이 포함된 모든 파일·폴더는 예외 없이 이사급 이상 세션과
시스템관장자 세션(11_시스템관장자법.md)만 열람할 수 있다.
② 기술적으로는 OS 파일권한을 소유자 전용(600)으로 최대한 제한한다. 다만 이 기기들은 세션별 OS 계정이 분리되어 있지 않으므로, 600만으로는 세션 간 접근을 완전히 막을 수 없다 — 따라서 이 조는 기술적 강제가 아니라 행동 규범(모든 세션이 지켜야 할 규칙)으로 시행한다.
③ 이사급 미만 세션(팀장·실장급 등)은 secret 파일을 열람할 권한이 없다.
① 팀장·실장급 세션이 작업 중 .env 등에 API 키·비밀번호 등 크리덴셜을 넣어야
하는 상황이 생기면, 직접 secret 파일을 열지 않고 보고서로 필요 사항을
올린다.
② 보고를 받은 이사급 이상 세션이 직접 .env 파일을 생성·기입해준다 —
크리덴셜 원본이 담긴 secret 파일 자체는 절대 하위 세션에게 전달·복사되지
않는다. 필요한 값만 담긴 .env만 전달된다.
① _secret이 포함된 폴더·파일의 존재 허용 기준은 기기를 3분류한 물리적
성격이다(2026-09-10 최종 정정, 수집기 여부와 무관). _secret에 담기는
내용은 각종 AI API 키 등 크리덴셜뿐 아니라 회사의 암호(비밀번호)와
핵심 코드(재작성 시 경쟁력 손실이 큰 주요 로직)까지 망라한다
(2026-09-10 범위 명확화).
| 분류 | 정의 | secret 허용 |
|---|---|---|
| 거점형 | 우리 조직의 상시가동 거점(2026-09-10 확정: mm1, win1) | ✅ 오직 거점형만 허용 |
| 고정형 | 각종 서버들(linux1, linux2, del1, lin1, lin2 등 물리 고정 서버 전반) | 🔴 금지(2026-09-10 강화 — 개별승인 조항 폐지) |
| 이동형 | 휴대 가능해 분실 위험이 있는 기기(예: 맥북) | 🔴 절대 제외 |
① -1 🔴 거점형 전용 원칙(2026-09-10 최종 확정): _secret은 거점형에만
보관한다 — 기존에 고정형(서버)도 개별 승인 하에 허용했던 조항은
폐지한다. 서버 대수가 많아질수록 노출면이 커지므로, secret 보관처는
거점형(현재 mm1, win1) 2곳으로 고정한다.
②-2 🔴 참여 권한 = 각 기기의 최고 이사진만(2026-09-10): _secret에
접근·참여할 수 있는 것은 각 기기(사업라인)를 담당하는 최고 이사진
뿐이다 — 제2조의2의 "이사급 이상"을 이 기준으로 더 좁혀 적용한다.
담당 라인이 아닌 이사급 세션은 다른 라인의 _secret에 접근할 근거가
없다.
② 2026-09-10 기준 허용: 맥미니(mm1, 거점형), win1(거점형). 새 기기 추가 시 위 표로 즉시 분류해 판정한다.
②-1 🔴 이동형 폴더 생성 자체 금지(2026-09-10 강화): 이동형 기기에는
_secret 파일을 두는 것뿐 아니라, _secret/ 폴더 자체를 생성하는
것도 금지한다 — "폴더는 만들되 내용만 비워둔다"는 우회도 허용하지
않는다. 이동형에서 _secret 경로가 조금이라도 존재하는 순간 그 자체가
위반이다.
③ 공용 서버·서비스용 프로덕션 서버(고객 대면)에는 이동형/고정형과 무관하게 항상 절대 금지다 — 이건 별도 원칙(헌법 제6조)으로 예외 없음.
④ 함대 동기화(03_함대동기화법.law.md) 작업 시 _secret 경로는 ①~③ 판정 후에만
포함 여부를 결정하며, 판정 전에는 항상 제외한다.
⑤ 🔴 거점형 = 본부/부본부 명칭 통일(2026-09-13 확정): 13_하드웨어운용법.law.md가
쓰는 "본부"(m1/맥미니)·"부본부"(w1/win1) 명칭은 이 조의 "거점형" 두 곳과
동일 대상을 가리킨다 — 앞으로 이 법에서도 "본부/부본부"로 부를 수 있다.
본부는 본부 역할과 개발기(무기개발기) 역할을 겸하고, 부본부는 개발을
겸하지 않고 본부 장애 대비 백업 전담이다(2026-09-13 명확화).
⑥ 🔴 secret 파일 개별 암호화 의무(2026-09-13 신설): 거점형(본부/부본부)에
보관이 허용된 _secret 파일이라도, 위치 제한만으로 충분하지 않다 —
각 파일 자체를 비밀번호(대칭키 암호화, 예: gpg --symmetric)로 잠가야
열람 가능하게 한다. 평문 상태로 거점형에 두는 것만으로는 이 조 준수로
인정하지 않는다. 실증 사례: 2026-09-13, mb1(이동형)에 _master_env.md
평문 사본이 존재하는 게 발견됨 — 본부(m1)에 이미 있던 정본과 별개로
생긴 위반 사본이었다. 즉시 mb1에서 삭제 완료(시정). 본부 정본의 gpg
암호화 적용은 실제 출시(제품 런칭) 시점에 재검토하기로 보류
(2026-09-13 대표 지시) — 그 전까지는 위치 제한(⑤)만으로 준수 상태를
유지한다.
②-3 🔴 접근 로그 의무(2026-09-10): _secret을 읽거나 쓰는 모든 행위는
별도 로그로 남긴다 — 일시, 수행 세션(직책), 대상 경로, 읽기/쓰기 구분을
최소한 기록한다. 로그 자체는 _secret 내용을 포함하지 않는 별도
파일(예: _secret_access.log)에 남겨, 로그 파일 자체가 또 다른 유출
경로가 되지 않게 한다.
③ 다른 기기에서 _secret 경로가 발견되면(허용 안 되는 위치에 있는 경우) 위반
여부를 확인하고 삭제를 진행한다. 🔴 단, _secret 삭제는 예외 없이
대표(시조·창조자)의 사전 승인을 받은 뒤에만 실행한다(2026-09-10 신설)
— 위반 상황이라도 세션이 임의로 먼저 지우지 않는다. secret 데이터는
한번 삭제되면 복구가 불가능할 수 있어, 삭제 자체가 또 다른 돌이킬 수
없는 손실이 될 수 있기 때문이다. 승인 전까지는 접근을 차단하고 대기한다.
시장조사 등 조사성 산출물은 다음 기준으로 이원화한다.
- 일반: 공개 소스 기반 재정리 → bm/a 안, 고객 제공·상품화 후보
- 특급: 직접 조사 원본·판단모델 → bm/a 바깥, 절대 비공개
경계가 애매하면 항상 특급(비공개) 쪽으로 보수적으로 분류한다.
이 법의 원칙이 실제로 적용된 사례:
| 날짜 | 사례 | 요약 | 자료 위치 |
|---|---|---|---|
| 2026-09-10 | 시장조사 발굴팀장 일반/특급 이원화 | 제2조·제3조(일반/특급 이원화) 실제 적용 — _kbox/_it(bm/a 안, 일반·공개소스 재정리)와 형제 폴더 _itdata(특급데이터, 절대비공개)를 명시적으로 분리 선언. 실제로 _itdata는 bm/a 워크스페이스 안에 생성되지 않고 대신 각 기기 로컬 ~/_local_only/_it_secret에 별도 보관되어, "특급은 동기화 트리 바깥"이라는 제2조 원칙이 그대로 지켜지고 있음을 확인 |
README.md |
| 2026-09-12 | 크리덴셜 원본 미기록 원칙 적용 | 제2조의2·제2조의3 정신의 실제 적용 — linux2 IPMI 원격 전원 조작 시도 기록에서, 실제 사용된 PIN·sudo 비밀번호 값 자체는 일반 인수인계 문서에 남기지 않고 "_secrets/_master_env.md 갱신 여부를 별도로 검토한다"고만 기록, 크리덴셜 원본과 일반 작업 기록을 분리 |
linux2 서버 원격으로 켜고 끄는 법.md |
아직 이 법의 제1조(배포 전 점검 의무)·제2조의2/2조의4(secret 열람권한·위치제한)가 실제 배포 작업이나 위반 대응으로 이어진 구체 사례는 기록되지 않았다 — 공용 서비스 서버 배포 자체가 아직 본격화되지 않은 단계라 해당 조항은 아직 원칙만 존재하고 실행 사례는 없다.