근거: CONSTITUTION.cst.md 제8조(정확한 배치와 파이프라인 정립)
소관: 13_하드웨어운용법.law.md 제8조의2에서 정의한 역할형 4종(수집형·운영형·
연산형·개발형)이 실제로 데이터를 주고받으며 어떻게 연결되는지, 전체
파이프라인의 순서와 각 단계의 책임 경계를 정한다.
데이터·서비스는 조사 단계부터 고객 응대까지 다음 순서로 흐른다 — 단계를 건너뛰거나 역순으로 흐르지 않는다.
0. 조사(발굴처 조사) ── 개발형-프로그래머
↓ 어떤 소스를 어떻게 발굴할지 판단·설계(예: 09_발굴처차단대응법 대응 포함)
1. raking(raker 개발) ── 개발형-프로그래머
↓ 조사 결과를 바탕으로 실제 수집 도구(raker)를 만든다
2. 발굴·수집(raker 실행) ── 수집형(수집기)
↓ raker를 돌려 raw 데이터를 실제로 발굴·수집한다
3. 연산(범용 전처리) ── 연산형(연산 서버)
↓ 정제·정규화·형식변환 등 ML과 무관한 범용 가공
4. 청킹(chunking) ── 연산형(연산 서버) 🔴(2026-09-13 정정, 구 운영형-마이닝)
↓ 정제된 데이터를 검색·임베딩 단위로 분할
5. 임베딩(embedding) ── 연산형(GPU임베딩 서버) 🔴(2026-09-13 정정, 구 운영형-마이닝)
↓ 청크를 벡터로 변환
(+ 색인화(indexing) → 양자화(quantization, 선택) — `01_데이터구조법.law.md`
제6조의 AI 파이프라인 표준 순서를 그대로 이어서 따른다. 이 둘도 연산형.)
6. 고객 응대(서빙) ── 운영형-트래픽(웹서버/데이터서버/양자서버)
→ 실제 고객에게 응답하고, 그 과정에서 문제점을 찾아낸다
개발형(개발 프로그래머·개발 테스트 서버)은 0~1단계를 직접 맡을 뿐 아니라, 2~6단계 전체에 걸쳐 신규 로직을 실전 투입 전 검증하는 역할도 겸한다 — 파이프라인의 한 고정 지점이 아니라 전 단계에 개입 가능한 횡단 역할이다.
① 조사(0단계)와 raking(1단계)의 차이: 조사는 "무엇을·어디서·어떻게
발굴할지" 판단하는 리서치 단계이고, raking은 그 판단을 실제 코드(raker
스크립트)로 구현하는 단계다. 조사 없이 raking을 시작하지 않는다 —
09_발굴처차단대응법.law.md의 발굴처 유형 판정이 조사 단계의 산출물이다.
② 🔴 연산형과 운영형의 경계(2026-09-13 정정): 3~5단계(범용 전처리· 청킹·임베딩·색인화·양자화)는 전부 연산형이다. "운영형-마이닝"이라는 구분은 폐기한다 — 운영형은 6단계(고객 응대·서빙) 하나뿐이며, 실제 고객 요청에 응답하면서 그 과정에서 문제점을 찾아내는 역할만 운영형으로 분류한다.
| 구분 | 연산형(3~5단계) | 운영형(6단계) |
|---|---|---|
| 처리 대상 | 수집형에서 갓 들어온 원본 → 서빙 직전 결과물까지 전부 | 연산형이 완성한 서빙 가능 결과물 |
| 처리 성격 | 범용 전처리 + ML 특화 가공(청킹·임베딩·색인화·양자화) 전 과정 | 실제 고객 응대 + 응대 중 문제점 발견 |
| 산출물 | 서빙 가능한 벡터/색인/양자화 결과물 | 고객 응답 |
| 소속 | 독립 역할형(가공의 처음부터 끝까지 담당) | 독립 역할형(트래픽 전담) |
즉 연산형이 원본부터 서빙 직전 결과물까지 전 가공을 담당하고, 운영형은 그 결과물을 고객에게 내보내는 마지막 한 단계만 담당하는 구조로 정리한다 — "운영형-마이닝"이라는 중간 하위유형은 더 이상 쓰지 않는다.
같은 "양자(화)"라는 단어가 파이프라인의 서로 다른 두 지점에서 쓰이므로 반드시 구분한다:
문서·대화에서 이 둘을 지칭할 때는 반드시 "양자화(생산)"/"양자(서빙)"처럼 괄호로 구분해 명시한다.
① 각 단계는 앞 단계의 산출물만 입력으로 받는다 — 뒷단계가 앞단계를 건너뛰어 원본에 직접 접근하지 않는다(예: 트래픽 서버가 수집형 raw 데이터를 직접 읽지 않음).
② 단계 간 전달은 01_데이터구조법.law.md의 그릇/음식 원칙 및
05_정거장모니터링법.law.md의 정거장 회수 원칙을 그대로 따른다 — 단계
사이에 데이터가 정거장 없이 직접 밀어넣어지지 않는다.
개발형은 0~6 어느 단계든 신규 로직을 검증할 수 있으나, 검증 완료 전까지는 실제 파이프라인(운영형-트래픽)에 절대 연결되지 않는다 — 개발 테스트 서버의 산출물이 실서비스로 흘러들어가는 경로는 없다.
이 조는 12_그룹웨어법.law.md 제5조의5(목표-실행-문제점-개선점 4항목
기록 원칙 — 전 업무 공통)를 수집(2단계)에 적용한 구체 사례다. 전 업무
공통 원칙은 그룹웨어법 5조의5를 따르고, 여기서는 수집 특유의 항목만
규정한다.
① 2단계(발굴·수집, raker 실행)에 들어가기 전에는 항상 목표를 먼저
설정한다 — 12_그룹웨어법.law.md 제5조의3⑦⑧(발·클 단위 목표 수치화·
업무 단위 산정)에 따라, 수집량·소요 발/클 등을 착수 전에 못박는다.
② 수행 완료 후에는 다음 4항목을 반드시 기록한다 — 목표만 세우고 결과를 복기하지 않으면 다음 수집에 같은 실수가 반복된다.
| 항목 | 내용 |
|---|---|
| 목표 | 착수 전 정한 수집량·소요 발/클 목표 |
| 실행 | 실제 수집량·소요 발/클(실적) |
| 문제점 | 목표보다 늦어졌다면 구체적으로 무엇 때문인지(예: 차단·재시도·네트워크 지연) |
| 개선점 | 목표보다 빨라졌다면 무엇 덕분인지, 또는 늦어졌다면 다음엔 무엇을 바꿀지 |
③ 이 기록은 해당 세션의 _gw/{세션명}.md 기록지 또는 대시보드에 남기고,
매 바이클 종합 요약(12_그룹웨어법.law.md 제5조의4③)에 집계·반영한다.
④ 목표보다 늦어진 원인이 09_발굴처차단대응법에 해당하는 차단·제한이면 그쪽 법령의 대응 절차도 함께 따른다 — 이 조는 기록 의무를, 09법은 대응 절차를 각각 규정한다.
2026-09-13 신설. 제1조의 6단계(0~6)는 거시 흐름이다. 실제로는 2단계
(수집)부터 6단계(서빙) 사이에 도구(role) 단위로 25개 세부 단계가
있다 — 단일 출처는 _knowhow/_cowork/_naming_registry.tech.py
(자동생성 문서: _NAMING_ABBREVIATIONS.md)이며, 이 조는 그 레지스트리를
법률 차원에서 인용·고정한다.
0단계: raker(수집) — 제1조 2단계와 동일, 세부 25단계의 출발점.
전처리 15단계(수집 이후 ~ 청킹 이전, 제1조 3단계에 해당): ocrer → cleaner → deduper → normalizer → tagger → validator → translator → txter/mder/csver/jsoner(포맷 변환, 4종 중 산출물에 맞게 선택) → resizer → cropper → thumbnailer → inpainter
AI 파이프라인 4단계(제1조 4~5단계에 해당, 순서 고정): chunker → embedder → indexer → quantizer(선택)
서빙 5단계(제1조 6단계에 해당): searcher → reranker → responder → cacher → evaluator
합계: 1(raker) + 15(전처리) + 4(AI파이프라인) + 5(서빙) = 25단계.
①-1 실제 데이터 처리 시 15개 전처리 도구를 전부 거치는 게 아니라 데이터 특성에 맞는 것만 선택 적용한다(예: 순수 텍스트 데이터는 ocrer·resizer·cropper·thumbnailer·inpainter 불필요). 25는 "가능한 도구 전체 목록"이지 "매번 25단계를 다 거친다"는 뜻이 아니다.
2026-09-13 신설. 제7조의 25단계는 데이터 종류를 가리지 않는 범용
도구 목록이다. 실제로는 데이터 특성(영상/전자책/오디오북/전자상거래
등)에 따라 이 도구들을 특정 순서로 조합한 "named process"가 별도로
존재한다 — 이것도 _naming_registry.tech.py가 단일 출처다.
| named process | 표준 순서(핵심 도구만) | 비고 |
|---|---|---|
| text_processor(기존) | raker → cleaner/normalizer 등 전처리 → mder | 가장 기본형 |
| image_processor(기존) | raker → resizer/cropper/inpainter → thumbnailer | - |
| table_processor(기존) | raker → validator → csver | - |
| api_processor(기존) | raker → validator → jsoner | - |
| video_processor(youtube/shorts 2종) | raker → transcriber → scener → clipper → editor → captioner → thumbnailer → tagger → publisher | 긴 영상=youtube_processor, 짧은 영상=shorts_processor(도구 동일, 강도만 다름) |
| ebook_processor | text_processor 산출물 → composer → coverer → binder → publisher | Solfit 전자책 아이디어의 기술화 |
| audiobook_processor | text_processor → composer → narrator → mixer → binder → publisher | ebook과 앞뒤 공유, 가운데만 다름 |
| ec_processor | raker → table_processor → image_processor → lister → pricer → tagger → publisher | PRODFIT류 사업 |
| mcp_processor | indexer → quantizer → exposer → publisher | KBrain9/knowledgeai_mcp |
| baikal_history_processor | (사건/대화) → chronicler → validator → tagger → archiver → publisher | 사관 — 조선왕조실록류 직필 원칙 |
| cms_processor | (고객요청) → profiler → customizer → mcp_processor → responder/supporter → evaluator | 고객맞춤·AS |
| pr_processor | (사업부 특징) → storyteller → copywriter → image/video_processor → promoter → evaluator | 홍보 |
| strategy_processor | (전 사업부 실적) → monitor → strategist → improver → chronicler | 경영전략 |
| board_processor 🔴최상위 | strategy_processor + 전 processor 현황 → director(전원 교차심의) → resolver → reporter → archiver | 이사회, 12_그룹웨어법.law.md와 연동, chronicler·counselor 상시 필참 |
①-2 이 표의 각 named process는 제7조 25단계 도구를 재사용한다 —
video_processor의 thumbnailer·tagger·publisher는 image_processor·
서빙 단계에서 이미 정의된 그 도구와 동일 개체다. 새 데이터 특성이
추가될 때마다 처음부터 새 도구를 만들지 않고, 기존 25단계 도구를
먼저 재사용할 수 있는지 확인한다(_naming_registry.tech.py 등록
절차 준수).
이 법의 원칙이 실제로 적용된 사례:
| 날짜 | 사례 | 요약 | 자료 위치 |
|---|---|---|---|
| 2026-08-28 | 0~2단계(조사→raking→수집) — HistoAI raker 함대 | 발굴처 조사 → raker 코드화 → 실제 실행까지 파이프라인 순서를 그대로 밟아 raker 17개로 약 4,200건·23GB의 검증된 자산을 실제로 확보 | 00_handoff_to_content_director_20260828.md |
아직 사례 없음: 3~6단계(연산형의 범용 전처리·청킹·임베딩·색인화·양자화, 운영형의
고객 응대)는 이 법의 원칙이 실제로 적용되어 결과가 나온 실행 사례가 아직 기록되지
않았다 — CaloryFit_임베딩파이프라인_RTX3060_소요시간_추정.md(_knowhow/_dator/) 등은
스펙 기반 사전 추정치일 뿐 실측·실행 결과가 아니라고 문서 자체에 명시돼 있어 이
표에 포함하지 않았다. 제6조(수집 목표-실행-문제점-개선점 4항목 기록 의무) 역시
2026-09-13 신설 조항이라 아직 실제 적용 사례가 없다.