데이터구조법 — 헌법 제1장·제2장 시행법

근거: CONSTITUTION.cst.md 제1조~제5조 소관: raw/rag 구조 관리, 이전(migration) 실무

제1조 (구조 동일성 검증 절차)

새 카테고리를 추가하거나 구조 변경을 할 때는 다음 순서를 따른다.

1. raw/에 새 폴더를 만들기 전, FOLDER_NAMING.md의 예약어 표를 linux1 정본 기준으로 재확인한다.
2. raw/에 폴더를 만들면 같은 턴 안에 rag/에도 동일 경로의 빈 폴더를 만든다 (헌법 제1조① 이행).
3. 생성 직후 find raw -type d와 find rag -type d를 비교해 구조 일치를 확인한다.

제2조 (증분이전 실무 절차)

1. 이전 대상 경로 X와 rag/의 대응 경로를 du -sh로 각각 측정한다.
2. 두 값이 다르면(즉 raw 쪽에 실데이터가 쌓여 있으면) 그 차이분만 대상으로 삼는다.
3. _ 접두사 경로는 1~2단계 전부 건너뛴다(헌법 제5조).

제3조 (기능형/데이터형 판정 기준)

폴더뿐 아니라 개별 파일(문서)에도 동일하게 적용한다. 폴더 또는 파일이 다음 중 하나에 해당하면 기능형으로 판정하고 이름 앞에 _를 붙인다. - 스크립트·코드(자체 실행 파일 포함) - 문서·노하우·매뉴얼(운영·설계·SOP 문서) - 키·크리덴셜·인증정보 - 색인·매니페스트·로그

그 외 실제 수집 콘텐츠(이미지, 문서, 스크랩 데이터)나 사업 산출물 보고서(사업계획서· 시장조사서 등 "총알"에 해당하는 결과물)가 담기는 폴더·파일은 데이터형으로 판정하고 접두사를 붙이지 않는다. 판정 기준은 깊이(depth)나 위치와 무관하며, 오직 유형 (type)만으로 판단한다(헌법 제5조④).

제4조 (폴더 구조화 원칙 — 계층 깊이)

① raw/(및 이를 그대로 미러링하는 rag/) 하위 구조는 대분류 → 중분류 → 소분류 → 리프(개별 항목) 순서로 계층화한다.

② 대분류(raw/ 바로 아래 1글자 도메인 루트: b, c, f, g, h, m, n, p, r, s, w 등)는 linux1 정본 구조를 기준으로 하며, 임의로 새 대분류를 신설하지 않는다 — 신설이 필요하면 시스템관장자(이 세션) 승인을 받는다.

③ 중분류·소분류는 팀장급 재량으로 신설 가능하나, 신설 직전 반드시 제6조의 예약어 확인 절차를 거친다.

④ 리프 폴더(개별 수집 항목 단위)는 분류 체계(대/중/소분류 신설 절차, 예약어 확인 등)의 적용 대상이 아니며, 실무 편의에 따라 자유롭게 세분화한다. 다만 _ 접두사 판정(제3조)은 분류 체계와 별개로 깊이에 상관없이 항상 적용된다 — 리프 위치라도 그 안의 폴더·파일이 기능형(스크립트·매뉴얼·키·로그 등)이면 _를 붙인다. 리프의 데이터형 개별 항목(실제 수집 콘텐츠 자체)에만 접두사를 붙이지 않는다.

제5조 (폴더 네이밍 규칙)

① 폴더명은 영문 소문자를 원칙으로 한다. 공백은 쓰지 않고, 구분이 필요하면 _(기능형 접두사와 혼동되지 않도록 단어 중간에만) 또는 소문자 붙여쓰기를 쓴다.

② 국가 단위 중분류는 ISO 3166-1 alpha-2 소문자 코드(kr, us, jp, de 등)를 쓴다.

③ 날짜를 이름에 포함할 때는 YYYYMMDD 형식을 접미사로 붙인다(예: 보고서 파일명 관례와 동일, 헌법·법률 문서 네이밍 관례를 폴더명에도 준용).

④ 한글 폴더명은 원칙적으로 쓰지 않는다 — 수집 데이터 트리(raw/, rag/) 및 기능형 폴더는 전부 영문으로 통일한다. 단, _makefund/ 하위 사업부 개별 보고서 파일명 등 사람이 직접 작성하는 문서는 한글 사용을 허용한다([feedback_business_docs_under_makefund] 관례).

⑤ 축약어를 쓸 때는 기존에 이미 쓰이고 있는 축약 관례(예: nutri=nutrition, exer=exercise)를 우선 따르고, 새 축약을 만들 때는 제6조 예약어 표에 등록해 전사가 같은 의미로 재사용할 수 있게 한다.

제6조 (_ 접두사 적용 범위 및 예약어)

① _ 접두사(기능형 표시, 제3조)는 폴더 계층의 깊이와 무관하게, 기능형으로 판정되는 모든 폴더와 모든 파일(문서)에 예외 없이 적용한다. 대분류·중분류· 소분류·리프를 가리지 않는다 — 적용 여부를 가르는 것은 오직 유형(type) 판정 (제3조)이며, 위치나 깊이는 고려하지 않는다.

② 새 카테고리(대/중/소분류)를 만들기 전, 다음 3종을 예약어로 취급하여 이름이 겹치지 않게 한다. 1. 이미 존재하는 대/중/소분류 카테고리 폴더명 전부 — 신규 카테고리가 기존 이름을 다른 의미로 재사용하면 안 된다. 2. _가 붙은 기능형 폴더명 전부(_wiki, _raker, _knowhow, _format, _infra, _cowork, _manifest, _off_keys, _conductor, _neuron, _tech, _global 등) — 접두사 없는 데이터 카테고리명으로 재사용 금지. 3. 회사 고유명사(사업명·내부 시스템명 등, 예: caloryfit, histoai, rulemap, stage) — 상세 표는 _wiki/_knowhow/_cowork/FOLDER_NAMING.md에서 상시 관리한다(라이브 데이터라 이 법률 문서에는 스냅샷을 옮기지 않는다).

③ 예약어와 충돌하면 그 이름을 그대로 쓰지 말고 같은 뜻의 유의어로 변형한다 (예: biz 충돌 시 busi/bizinfo/corp 등).

④ 신규 대/중/소분류를 만들기 전에는 항상 linux1 정본에서 현재 전체 목록을 직접 확인한다(ssh [email protected] "ls raw/ raw/*/ ...", 경로: /l1h1/bm/a/raw/) — 로컬 미러나 기억에 의존하지 않는다.

⑤ 새로 확정된 예약어(고유명사·축약어)는 발견 즉시 FOLDER_NAMING.md 표에 등록한다 — 등록하지 않고 넘어가면 시행령 제1조의 경미한 위반으로 처리한다.

⑥ (기능형 파일 확장자 표준) _ 접두사와 결합했을 때 검색이 정확해지도록, 기능형 파일은 종류별로 확장자를 표준화한다.

⑦ (역할별 2차 확장자 — 모든 .py에 예외 없이 의무화) 파이썬 스크립트에 국한하지 않고, 기능형 파일 일반에 _<이름>.<역할>.<기본확장자> 형태로 역할을 2차 확장자로 병기한다. 특히 모든 .py 파일은 예외 없이 역할을 나타내는 2차 확장자를 이름 안에 반드시 넣는다 — 단순 _name.py로 끝내는 것을 금지한다. .raker.py(raker 스크립트)뿐 아니라 .raker.md(그 raker의 개별 노하우·설정 문서), .updater.py(updater 봇), .updater.md처럼 기본확장자(.py/.md/.sh/.json 등)는 그대로 두고 역할만 그 앞에 끼워 넣는다. 역할명은 이미 통용되는 어휘(raker, updater, dator, tech 등, 헌법 제5조① 예시 및 [project_updater_bot_convention] 관례와 동일)를 우선 쓰고, 해당하는 기존 역할명이 없으면 새 역할명을 만들어 제6조② 예약어 절차를 거쳐 FOLDER_NAMING.md에 등록한 뒤 쓴다.

목적: 파일명만 보고도 그 .py가 어떤 성격(무슨 역할)의 코드인지 누구나 바로 알 수 있게 하는 것이다. find -name "*.raker.*"처럼 확장자와 무관하게 역할 단위로도 정확히 필터링할 수 있는 것은 그 부수 효과다.

⑧ (역할 스크립트–문서 쌍 원칙) 실행 파일 _<이름>.<역할>.py(또는 .sh 등)를 만들면, 같은 이름·역할의 _<이름>.<역할>.md를 반드시 쌍으로 둔다. 제7조가 모든 .py에 역할 2차 확장자를 의무화했으므로, 이 쌍 원칙도 .py 전부에 예외 없이 적용된다 — "역할이 아직 정해지지 않은 .py"라는 예외는 없다. 코드와 설명을 절대 한 파일에 섞지 않는다. - .py/.sh 등 실행 확장자 = 실행 로직 그 자체만 — 코드는 최대한 간결하게 유지한다. - .md = 그 실행 파일의 운용 설명서 — 무엇을 하는 스크립트인지, 실행 방법(커맨드·인자), 전제 조건(정거장 경로·필요 크리덴셜 등), 자주 겪는 실패와 대처(노하우), 마지막 갱신·검증 일자를 상세히 기록한다. 06_업무매뉴얼표준양식법.law.md 제4조(상시 보강 의무)를 그대로 준용해, 실패를 겪을 때마다 이 md에 즉시 반영한다. - 검색 시 *.raker.py만 걸러내면 실행 가능한 파일만 정확히 얻고, 로직에 대한 자세한 운용 방법은 옆의 *.raker.md에 들어가면 전부 파악할 수 있다 — 실행 코드와 운용 지식을 파일 단위로 짝지어 분리 보관하는 것이 이 조항의 목적이다. - 예외 없음: .raker.py(및 그 외 모든 역할별 실행 파일)는 .raker.md 짝 없이 존재할 수 없다. 짝 없이 만들어진 실행 파일을 발견하면 발견 즉시 .md를 만들어 채운다 — 신규 작성뿐 아니라 기존에 이미 있는 역할별 실행 파일에도 소급 적용한다. - 목적: 코드만 봐서는 파악하기 어려운 실행 방법·전제조건·노하우를 md에 분리 기록해 두면, 이제 막 투입된 신규 팀장·실장도 코드를 처음부터 읽어 해석할 필요 없이 .md 한 장만 읽고 바로 정확하게 운용할 수 있다 — 즉 이 쌍 원칙 자체가 프로그램 활용성과 신규 인력의 업무 정확도·성과를 끌어 올리는 장치다. 짝을 만들지 않고 넘어가는 것은 단순 누락이 아니라 이 목적을 무력화하는 위반으로 본다(시행령 제1조 경미한 위반 대상).

⑧-1 (raker 역할 .md 전용 필수 항목, 2026-09-12 확정) .raker.py의 짝 .raker.md는 ⑧의 일반 항목(실행방법·전제조건·노하우) 위에 다음을 반드시 추가로 담는다 — raker는 "무엇을 수집하는가" 자체가 운용지식의 핵심이라 일반 스크립트보다 더 상세한 명세가 필요하다: 1. 발굴된 데이터의 소스 — 어느 기관/사이트/API에서 수집하는지, 라이선스· 재수집 가능성(재수집 쉬움 vs 어려움, [[feedback_recollectible_single_copy_policy]] 참조)까지 2. 막힌 이력 — 레이트리밋·차단·API 변경 등으로 멈췄던 사고와 그 시점 3. raker 변천사 — 이 raker가 처음 어떻게 만들어졌고, 이후 어떤 버전/방식 변화를 겪었는지 시간순 기록 4. 변화 내용 — 각 변천 단계에서 구체적으로 무엇이 바뀌었는지(로직·인자· 출력경로 등) 5. 해결 방법 — 막혔던 문제를 어떻게 풀었는지(우회·재시도·소스 전환 등) 6. 최종 목적지 — 이 raker가 실제로 데이터를 쌓는 최종 경로(호스트· ZFS풀·raw/rag 슬롯까지 구체적으로) 기존에 이미 있는 .raker.py도 이 항목 기준으로 소급 보강한다(⑧의 소급 적용 원칙과 동일).

⑨ (기능형 문서 탐색 원칙) _ 접두사를 전면 적용하는 실질 목적은 은폐가 아니라 탐색 속도다(헌법 제5조⑤). 새 세션·팀장은 기능형 문서만 빠르게 훑어볼 때 접두사와 확장자(및 2차 확장자)를 조합해 필터링한다.

find <경로> -name "_*"            # 기능형 폴더·파일 전체
find <경로> -name "_*.md"         # 기능형 문서·매뉴얼만
find <경로> -name "_*.py" -o -name "_*.sh"   # 기능형 스크립트만
find <경로> -name "*.raker.py"    # raker 역할 실행 파일만 (⑧의 코드 쪽)
find <경로> -name "*.raker.md"    # raker 역할 운용 설명서만 (⑧의 문서 쪽)
find <경로> -name "*.raker.*"     # raker 역할 파일 전부(확장자 무관, .py+.md 등)

데이터형 항목은 애초에 _가 붙지 않으므로 위 검색에서 자동으로 제외된다 — 전체를 다 읽지 않고도 "무엇이 도구/매뉴얼인가, 그중에서도 어떤 역할인가"를 즉시 골라낼 수 있는 것이 이 조항의 존재 이유다.

제7조 (함대 전 기기 배치 원칙 — 프로그래밍/정거장 슬롯) 🔴

목적: 임시정거장 → 또 다른 임시정거장 → 실전 서비스 데이터(본 데이터)까지 전부 동일한 bm/a/raw 구조를 갖고 있어야, 전송·이전 작업이 항상 "같은 상대경로에서 같은 상대경로로" 이동하는 것으로 통일된다 — 목적지마다 구조가 다르면 매번 경로를 다시 매핑해야 하는데, 구조가 똑같으면 rsync 경로/ → 경로/처럼 기계적으로 반복 가능해진다(2026-09-12 대표 설명).

비유: "이사를 하는데 아파트처럼 동일한 아파트 방구조를 셋팅해두고 이사짐을 똑같은 형태로 정리하는 것"과 같다 — 새 집(정거장)의 방 배치(폴더 구조)가 이전 집과 똑같으면, 이삿짐(데이터)을 어느 방에서 어느 방으로 옮길지 고민할 필요 없이 "안방→안방, 주방→주방" 그대로 옮기면 된다.

① 모든 수집기(대형·소형 불문)의 프로그래밍 슬롯(p)에는 bm/a/rag· bm/a/raw의 폴더 구조(그릇)와, 각 폴더에 흩어진 _raker 실행 파일 전체를 보유한다(2026-09-12 확정). 폴더 구조는 빈 껍데기만, _raker는 실제 스크립트까지 채운다 — 그 외 _wiki·_neuron·_tech·_updater·_dator 같은 다른 도구 폴더는 소형 수집기에 넣지 않는다(대표 지적: "이런 소형 수집기에는 들어갈 일이 전혀 없음").

② 모든 수집기의 임시정거장 슬롯(s)에는 bm/a/raw의 폴더 구조(그릇)만 전부 셋팅한다(rag는 정거장에 불필요, 프로그래밍 슬롯에만 있으면 됨).

③ linux1의 l1s2/stage/ 처럼 하나의 볼륨이 기기별로 하위 폴더로 나뉘어 있는 경우, 그 하위 폴더 각각에도 개별적으로 raw 구조를 따로 셋팅한다 — 공용 상위 폴더 하나에만 두는 게 아니라 기기별 폴더 각각이 독립적으로 완전한 구조를 갖는다.

④ 맥미니(m1)를 이 구조의 본부(소스)로 지정하고, 주기적 자동 전파로 전 기기 구조를 동기화한다 — 실행 스크립트는 m1:~/bm/a/s/_fleet_sync/push_rag_raw_skeleton.sh(cron, 매시간), 원칙은 "구조(그릇)만 전파, 데이터는 절대 안 건드림"(제1조와 동일 원칙의 자동화 버전). 대상 기기 추가 시 이 스크립트의 TARGETS에 등록한다.

⑤ 기기 호칭은 m1으로 통일한다 — mm1 등 구 별칭은 전부 폐기 (2026-09-12).

⑥ 🔴 _raker 실제 파일(스크립트)은 반드시 프로그래밍 존(p 슬롯)에만 존재한다 — 데이터 존(s 슬롯, 정거장, 실전 서비스 데이터 경로)에 실제 _raker 코드가 존재하는 즉시 중대한 위반으로 취급한다(대표 확정, 2026-09-12: "_raker 파일들은 반드시 프로그래밍 존에만 존재해야 함. 데이터 존에 존재하는 즉시 벌을 내리겠음"). 01_위반처리시행령.dec.md 적용 대상 — 경미한 위반이 아니라 핵심자산 보호 원칙(제6조, "무기창고") 정면 위반으로 다룬다.

• 데이터 존에 _raker라는 이름의 빈 폴더(스켈레톤)가 존재하는 것 자체는 위반이 아니다 — bm/a/raw 전체 구조를 그대로 미러링하는 과정에서 카테고리마다 있는 _raker 플레이스홀더 폴더가 자연히 따라오기 때문. 위반은 그 폴더 안에 실제 스크립트 파일이 들어있을 때만 성립한다.
• 배치·동기화 작업 시 반드시 확인: find <데이터존 경로> -path "*/_raker/*" -type f 결과가 0이어야 한다.

제8조 (데이터 사본 수 — 수집 난이도 기준) 🔴

목적: 모든 raw 데이터를 일괄 다본(예: 3사본)으로 유지하는 건 수익화 이전 시점의 저장공간·연산자원 한계상 비현실적이다 — 판정 기준은 소스의 종류나 "공개 API 생존 여부"가 아니라, 실제로 그 데이터를 다시 모으는 데 걸리는 속도·난이도다(2026-09-12 확정).

① 1본만 유지: 언제든 다시 가져오기 쉬운 데이터 — 공식 대량 덤프·API로 빠르게 통째 재수집 가능한 소스(예: 위키(Wikipedia/Wikisource) 계열). 소스가 "살아있음"만으로는 충분하지 않다 — 재수집에 실제로 얼마나 걸리는지가 기준.

② 이중화(2본): 저속·고난도로 힘들게 모아야 하는 데이터 — 소스 API 자체는 살아있어도 레이트리밋·기관별 개별 수집 등으로 재수집에 오랜 시간이 걸리는 소스(예: Europeana — 대형 기관 하나(limit 수십만 건)를 레이트리밋 때문에 며칠씩 걸려 수집한 실측 사례, 2026-09-11~12). "소스 생존"과 "재수집 용이성"은 별개 축임을 보여주는 근거 사례로 삼는다.

③ 새 수집 소스를 편입할 때마다 위 두 예시로 유추 판정하지 말고, 그 소스 자체의 실측 수집 속도/난이도로 1본/2본을 새로 판정한다 — 판정 근거(실측 소요시간, 레이트리밋 유무 등)를 해당 raker의 .raker.md(제6조⑧-1)에 기록한다.

④ 수익화 이후에는 이 조항 자체를 재검토해 필요한 소스부터 순차적으로 사본 수를 늘린다 — 이 조항은 수익화 이전 임시 조치이지 영구 정책이 아니다. [[feedback_recollectible_single_copy_policy]] 참조(상세 이력·근거).

제9조 (코드번호 체계)

① raw/·rag/의 모든 폴더는 코드번호를 받는다. 코드는 한번 부여하면 바뀌지 않는다. ② 새 폴더를 만든 같은 턴에 코드를 등록하고, 수집 전에 목록·위치 코드·수집계획서를 먼저 확정한다. ③ 맥북 bm/a가 정본이며, 구조는 m1에 자동으로 추가 반영된다.

상세 문서 위치 (기준 /Users/baikal/bm/a/) - 코드 규칙·수집 전 절차·코드표: _README_코드번호_list.md - 코드 원본(전체 폴더): _wiki/_manifest/_code_registry.tsv - 등록 도구 운용법: _wiki/_manifest/_code_registry.gen.md - m1 자동 동기화 운용법: _wiki/_manifest/_structure_sync.sync.md

제10조 (폴더는 저장, 분류는 코드·태그)

① 폴더는 저장 위치(원천·형식)만 나타내고, 주제·시대·종류·권리는 코드와 목록표 태그로 기록한다. ② 한 대상이 여러 분류에 걸리면 폴더는 한 곳에 두고 나머지는 태그로 표시한다. ③ 시대 구분 폴더는 로컬 규칙이며, 목록표 날짜가 정본이다(원본 경로로 쓸지 파생 뷰로 쓸지는 미결).

상세 문서 위치 - 원칙의 출처(축·코드 규약): rag/s/ai/raker/docs/00_MASTER.md - 목록표 열 정의·생성 도구: _wiki/_manifest/_catalog_list.schema.md, _wiki/_manifest/_catalog_list.build.md - 근거 조사(ChatGPT): /Users/baikal/dev/c/_codex_research/media_classification_standards_library_museum_20261005.md, /Users/baikal/dev/c/_codex_research/software_classification_standards_20261004.md

제11조 (c/culture 미디어 형식·대상 폴더)

① c/culture/ 아래에 형식 폴더(영상·소리·이미지)와 대상 폴더(monu)를 둔다. ② 폴더는 원천(제공기관) 기준으로 나누고, 시대·주제는 태그로 한다.

상세 문서 위치 (raw/c/culture/_wiki/에도 같은 사본) - 영상(film·movie·video)·소리(sound·voice·call): rag/c/culture/_wiki/영화_film_movie_분류규칙.md - 음악·가사: rag/c/culture/_wiki/음악_가사_연도분류규칙.md - 이미지(image/…): rag/c/culture/_wiki/이미지_분류규칙.md - 기념물(monu/…): rag/c/culture/_wiki/기념물_분류규칙.md

제12조 (이름 길이·약어 등록)

① 국가가 아닌 종류 폴더 이름은 3글자 이상을 원칙으로 한다(기존 예외: cs, ds, go 등). 국가코드(ISO 2글자)와 같은 층에서는 2글자 이름을 쓰지 않는다. ② 줄여 쓴 이름은 FOLDER_NAMING.md에 의미와 함께 등록하고, 새 이름은 기존 이름과 겹치는지 먼저 검색한다. ③ 위반이 확인되면 데이터가 들어오기 전에 개명한다. ④ 뜻과 축이 달라 대표가 허용한 예외는 FOLDER_NAMING.md에 사유와 함께 등록한다. ⑤ 한 대상에 이름이 둘 이상이면 더 대중적인 이름을 실제 폴더로 쓰고 나머지는 별칭(심볼릭 링크)으로 연결한다.

상세 문서 위치 - 예약어·약어 등록표, 별칭 규칙·별칭표: _wiki/_knowhow/_cowork/FOLDER_NAMING.md - 코드 규약 원문: rag/s/ai/raker/docs/00_MASTER.md

부속 (구조도·제정 이유)

• 전체 구조도·raw/rag 차이: _wiki/_doc/_list/_폴더구조도.md (전체 트리: 같은 폴더의 _폴더구조도_raw_전체.txt, _폴더구조도_rag_전체.txt)
• 이렇게 정한 이유: _wiki/_doc/_list/_폴더구조_제정이유.md
• 구조도 생성 도구: _wiki/_manifest/_folder_tree.gen.md

실행 사례 자료

이 법의 원칙이 실제로 적용된 사례: