eomsangdon/Aislo
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
Files
8856008bf690e758a61ba16da170c4f329085c8c
Aislo/docs/raw/verification/2026-09-13_축C_명세.md
T

47 KiB
Raw Blame History

축 C 명세 — 두 축과 그것을 잇는 표

작성 2026-09-13 · 브레인(데스크탑 메인) · 코드 창 둘이 따를 계약

왜 이 문서가 있나 — 랩탑 메인(1장 축)과 랩탑 서브(3장 구조물도)가 서로 안 만나면서도 나중에 맞물리게 하려면 계약이 먼저 있어야 함. PLAN.md 는 「무엇을 할 것인가」이고 이 문서는 「그것이 어떤 모양이어야 하는가」임.

00. 브레인 인수인계

브레인 지침과 작업 기억은 이 문서가 아니라 .claude/ 에 있음 (2026-09-13 사용자 확정).

파일 무엇
.claude/BRAIN.md 브레인일 때 추가로 지킬 것 — 컨텍스트 규율·판정 방식·창 조율
.claude/BRAIN_MEM.md 지금 상태 — 창 배정·다음 차례·확인해 둔 것·아픈 자리

⚠ 둘 다 git 밖(시놀로지·정션으로 공유)이라 이력이 없음. 계약·판정처럼 잃으면 안 되는 것은 이 명세와 PLAN.md 에 둘 것.

새 브레인이 읽는 차례 — .claude/BRAIN.md → .claude/BRAIN_MEM.md → 이 명세 → PLAN.md 0장·판정 절.

0. 한 줄 요약

공종 축(수량이 붙는 자리)과 자원 축(돈이 붙는 자리)을 따로 두고, 일위대가가 둘을 잇는 표로 선다.

공종 축  FP-09-03-01 돌쌓기(찰)        ← B08 이 수량을 붙임
             │
             └── 일위대가 = 잇는 표     ← 라이브러리가 저장하는 것
                    ├─ 자원 M-야면석    0.88 ton/㎡
                    ├─ 자원 L-조경공    0.21 인
                    └─ 자원 L-보통인부  0.15 인
                                         ← B09 가 돈을 붙임

1. ⚠ 실측 — 지금 무엇이 서 있나 (2026-09-13 브레인 확인)

「자원 축 뒤 패스를 만든다」는 틀린 말임. 이미 있고 이미 돌았음.

무엇 자리 상태
공종 축 마스터 resources/data_work_item_master/work_item_master_2026-01-01.json ✅ 섬 (477공종·456표)
뒤 패스 코드 B09_Estimation/B09_Estimation_ResourceAxis*.py (6파일) ✅ 섬 — 매번 메모리에서 새로 돎
data_cost_resource_axis/*.json 418줄·못맞춤 497 ⛔ 옛 산출물. 정본 아님

⚠⚠ 2026-09-13 정정 — 앞서 적은 418/497 은 죽은 파일이었음

브레인이 틀렸음. write_resource_axis 는 정의만 있고 부르는 곳이 한 군데도 없음(확인 완료). 그 JSON 둘은 옛 마스터로 한 번 돌려 남긴 자취이고, B09 는 실행할 때마다 메모리에서 새로 맞춤.

살아 있는 실측 (랩탑 메인 조사, 지금 코드로 돌린 값)

맞춘 줄 575   노임 532 · 기계 43 · 자재 0        ⚠ 자재 축이 통째로 안 섬
못 맞춤 508
건너뛴 표     참조 63 · 미판정 73 · 계수 19

⇒ 못 맞춘 508 은 한 덩어리가 아니라 둘임.

갈래 수 무엇이 필요한가
카탈로그에 없는 이름 271 STmate 목록 894개로 풀릴 후보 (11장)
뭉친 줄 이름 못 풂 등 약 230 표 읽기 문제 — 목록이 와도 안 풀림

일감을 둘로 갈라 잡을 것. 「목록이 오면 다 풀린다」는 틀림.

⭐ 제일 큰 구멍은 자재 0 — 자재 축이 아예 안 서고 있음. 여기부터 볼 것.

산출물 파일의 자리 — 정본은 메모리 실행임. write_resource_axis 는 시험·조사용 덤프로만 두고 정본으로 읽지 말 것. 옛 JSON 둘은 지우지 말고 그대로 두되 근거로 쓰지 말 것.

2. 공종 축

코드 모양 — 이미 도는 규약을 그대로 씀

FP-<절>-<절>-<절>        예) FP-04-02-02 (벌목, 5m 미만)
  • 정본은 품셈 절 번호. 표의 행은 그 절의 조건별 변형(variant 칸)임
  • 이름은 표시용, 잇기는 코드로. 이름으로 맞추는 코드가 남아 있으면 그것이 곧 결함임

⭐ 어느 품셈 판인가 — 2026-09-14 확인 (조문 근거 있음)

FP- 는 산림사업 표준품셈 한 판임. 건설공사 표준품셈은 공종 축이 아니라 기계 층에만 들어옴.

공종 축 477/477  FP-  ·  원천 pum_forest_2026.json (산림청고시 2025-82호, 2026-01-01)
기계 층          pum_const_2026.json · mach_base_2026.json (건설품셈 제8장 — 취득가·손료계수·연료·운전원)
빌려 온 몇 곳    「교차 참조」 딱지를 붙임 (예: 뿌리뽑기 밑수 3-9-2)

근거 — 같은 고시 총칙 7: 「본 품셈에 명시되지 않은 품은 타 부문(토목, 건축, 전기, 기계 등)의 표준품셈에 명시된 부분의 품을 적용하고, 타 부문과 유사한 공종의 품은 본 품셈을 우선하여 적용한다.」

⇒ 지금 얼개가 이 조문 그대로임. 건설품셈 절번호로 선 공종 줄은 0 건(소스에 「8-2-8」 참조 0건). ⚠ 자료를 찾을 때 건설품셈만 보면 「값이 없다」고 잘못 결론 내기 쉬움 — 덤프 운반이 그랬음 (건설 8-2-8 에는 단위중량·적재용량 표가 없으나 산림 10-12 [주]에 토사 1.9 · 암 2.4 ton/㎥ · 덤프 15 ton 이 있었음). 막히면 산림품셈 쪽을 먼저 볼 것.

  • 부모·잎이 있음. ⚠ 「부모에 수량 금지」는 반쪽만 맞았음 — 2026-09-13 정정. 부모가 두 모양이고 규칙이 다름(랩탑 메인 실측).

    모양 보기 규칙
    갈래 고르기형 FP-10-12(덤프·사토·표토 운반) · FP-09-15(표토제거) · FP-05-24 · FP-09-13 부모에 붙이지 말 것. 잎 하나를 골라야 함. 못 고르면 오류로 세울 것 — 조용히 부모에 붙이면 금액 0 이 됨
    단계 합산형 FP-09-04(파쇄+집토) · FP-09-05(절취10%+깍기90%+집토) · FP-12-38(유로폼) 내역 한 줄이 곧 부모임. 부모에 수량을 붙이되 일위대가는 잎들의 합으로 조립 — 부모가 곧 조합 일위대가

    ⚠ 가름은 자동 판정하지 말 것. 마스터에 parent_mode 칸을 두고 기본 choose_one, 합산형만 사람이 명시. 표 모양으로 짐작하면 조용히 틀림. ⇒ 지금 FP-09-04·FP-10-12·FP-09-15 는 일위대가 제목이 아예 없어 금액 0 임(실측).

⭐ 코드 체계 — 브레인 확정 (2026-09-13, 사용자 지시)

새로 만들지 않았음. 이미 도는 규약에 한 칸을 더한 것임.

① 층 글자 — 이미 코드에 살아 있음. 바꾸지 말 것

S-<기계코드>              중기 취득가(천원)
X-<기계코드>              시간당 중기사용료      · X-<코드>#조합 = 기계 조합
B-<공종코드>[#<갈래>]      일위대가               예) B-FP-12-01-01#철근구조물
D-<공종코드>              단가산출               B- 를 D- 로 갈아 끼움
W-<…>                    일식·견적

② 공종 축 코드 — 층 글자 뒤에 오는 자리

FP-<절>-<절>-…           품셈 절번호 (정본, 두 자리 zfill)   예) FP-04-02-02
AX-<갈래>-<8자리 16진>    우리가 더한 공종

   갈래 ST   구조물 일위대가 — 라이브러리가 낳는 것
   갈래 WK   품셈에 없는 공종 — 첫 사례 지장목제거

예) B-AX-ST-3f9a2b17 = 어느 구조물 양식이 낳은 일위대가 한 벌

③ 자원 축 코드

<숫자>                   카탈로그 코드 (정본)    예) 1037 보통인부
AR-<종류>-<8자리 16진>    카탈로그에 없는 자원

   종류 M 자재 · L 노임 · X 중기   ← PriceKind 글자 그대로. 새 낱말 안 만듦

지금 못 맞춘 497줄(보통휘발유(주연료) 등)이 여기로 들어감. ⚠ 단가는 없어도 됨 — 이름·코드만 서면 축은 이어짐.

④ 지킬 것 다섯

  1. 관급은 코드가 아님 — 자재 줄의 칸임 (material_supply = owner_supplied·contractor_supplied·unknown, 관급 줄엔 install_by 가 더 붙음). ⇒ 관급용 접두는 만들지 않음
  2. 번호는 난수 8자리 소문자 16진. 발급자를 두지 않음 — 3단 라이브러리(프로그램·회사·개인)와 창끼리 공유에서도 안 부딪힘. 만들 때 자기 범위 안 중복만 볼 것
  3. 코드는 동등 비교만. 사전순 정렬·계층 해석 금지 — AX·AR 에는 부모·잎이 없음(FP 만 있음). 표시 차례는 공종 계층에서 옴
  4. 층 글자는 맨 앞에만 — B-AX-ST-3f9a2b17 ⭕ · AX-B-ST-… ❌
  5. #갈래 는 기존 규약 그대로. 새 구분자를 만들지 말 것

⑤ 왜 이 모양인가

  • FP 는 CODE_PREFIX = "FP" 로 이미 박혀 있고 B-FP-12-01-01#철근구조물 이 실제로 돎. 거기에 AX 한 칸만 나란히 세우면 층 글자 로직을 한 줄도 안 고쳐도 됨
  • 난수를 쓰는 까닭 — 회사·개인 라이브러리가 서로 모르는 채 항목을 만들고 공유까지 함. 일련번호를 쓰면 공유하는 순간 부딪힘
  • 읽기는 이름 칸이 맡음. 코드는 식별자일 뿐임

3. 자원 축

한 줄의 모양 — 실물 그대로 (고치지 말 것)

{
  "work_item_code": "FP-04-02-02",
  "resource_kind":  "labor",
  "resource_code":  "1037",
  "resource_name":  "벌목부",
  "resource_spec":  "",
  "amount":         "2.14",
  "amount_unit":    "",
  "variant":        "5m 미만",
  "pum_form":       "requirement",
  "pum_table_id":   "F0087",
  "raw_row_index":  1
}

지켜야 할 것 다섯 — 이미 코드 머리에 적혀 있음

  1. pum_form 을 먼저 볼 것. productivity = 1 ÷ 값 · requirement = 값 ÷ 밑수. ⚠ 뒤집으면 20배 틀림
  2. coefficient·reference 는 공종이 아님 — 일위대가 항목으로 세우지 말 것. undetermined 는 값을 쓰지 말 것
  3. 규격(resource_spec)이 없으면 매칭 성공이 아님. 「굴착기」와 「굴착기 0.7㎥」는 단가가 다름
  4. 못 맞춘 것은 빈칸이 아니라 unmatched 목록으로
  5. 자재는 할증 전 값. 할증은 자재총괄 한 곳뿐

자원 종류와 단가 층은 다른 것

헷갈리면 값이 두 배가 되거나 사라짐.

축 값 무엇인가
자원 종류 (resource_kind) labor · material · machine 품셈 줄이 무엇을 부르나
단가 층 (PriceKind) M·L·S·X·B·D·W 단가가 어느 겹에 사나

⚠⚠ 층 차례 — 2026-09-13 정정. 화살표 방향이 모호했음

조립(참조) 차례는 아래가 맞음. 앞서 적은 … → B → D 는 거꾸로 읽힐 수 있었음.

L 노임 · M 자재   (카탈로그 — 상세 없이 값이 바로 있음)
   ↓
S 중기취득가(천원)  →  X 시간당 중기사용료
   ↓
D 단가산출 (Q 식으로 시간당 단가 ÷ Q)
   ↓
B 일위대가 (D 와 카탈로그를 물어 조립)

⇒ D 가 먼저 서고 B 가 D 를 참조함. 우리 코드는 지금 D 가 B 를 참조해 뒤집혀 있음(랩탑 서브 실측). ⚠ 차례가 뒤집히면 위상순서·재귀·이중계상 판정이 다 영향받음 — 값 정밀도 고치기와 따로 뗄 것.

D 는 Q 를 쓰는 자리에만 섬 (2026-09-13 실측)

D 가 서는 자리   Q 식으로 시간당 단가를 나누는 기계 공종
                 (굴착기 · 도자 · 직접 작업량/다짐 · 암 잎)
D 가 없는 자리   사람 품만 있는 공종 · 자원축 표 시간(Q 아님) → B 가 X·카탈로그를 바로 물음
  • D-<공종>[#갈래] · D→X 수량 1/Q × 몫 · B→D 수량 1
  • STmate 한 D 에 Q 가 여럿일 수 있음(기계조합 호표)
  • ⚠ 「단산 N」 번호는 실제 D 가 든 줄에만. 단가산출이 없는 줄에 번호를 붙이면 없는 근거를 가리킴
  • ⚠ 내역이 부르는 코드 축은 B 하나로 둠. STmate 는 순수 기계 공종에서 내역이 D 를 바로 부르나 (봉화 「토사절취 … 산근 19호표」), 금액은 같고(B→D 수량 1) 축이 하나여야 인계·골든셋·이중계상이 단순함. ⇒ 골든셋 대조에서 STmate 의 D 줄과 우리 B 줄을 짝으로 알아보게 해 둘 것

4. 일위대가 — 잇는 표

  • 한 줄 = 공종 코드 하나 + 그에 딸린 자원 줄 여럿
  • 금액은 어느 층이든 재료·노무·경비 3분할이고 합계 = 재료 + 노무 + 경비
  • 재귀 — 구조물 일위대가(AX-ST-*)가 다른 공종의 하위 일위대가로 들어감. ⚠ 순환 참조 막이 필요 · 깊이 한도는 사용자 답 대기

5. 별칭표

한 파일에만 둘 것. 지금 B08_Quantity_Engine_Handoff_Mapping.py 등 여러 곳에 흩어져 있음.

우리 이름  →  코드  ←  남의 이름
리핑암     →  FP-…  ←  파쇄암          (실재 · 코드에 주석으로 있음)
노면다짐   →  FP-…  ←  노면고르기       (답 대기)
  • 방향은 양쪽 다 — 우리 이름으로도, 실무·품셈 이름으로도 코드를 찾을 수 있어야 함
  • 한 이름이 두 코드에 걸리면 오류로 세울 것. 조용히 첫째를 고르면 안 됨

⚠⚠ 2026-09-13 정정 — 별칭에 범위 칸이 있어야 함

전역 양방향 사전은 틀림. 별칭은 표 범위에서만 참임.

리핑암 = 파쇄암 은 산림품셈 10-11 f 표 안에서만 성립함 — 우리 「리핑암」은 지반유형 (캘 수 있는가)이고 품셈 「파쇄암」은 운반할 때의 상태(부서졌는가)라 발파암도 캐고 나면 파쇄암임. 그 표가 토사·파쇄암·발파암을 따로 두었고 10-12 [주]③ 의 토량환산계수가 파쇄암 1/1.35 = 암절취(리핑) 이라 그 표 안에서만 이어짐 (근거는 B09_Estimation_UnitPrice.py:464~477 주석).

별칭 한 줄 = { from , to , scope }
   scope = 이 별칭이 참인 코드 범위   예) "FP-10-11"
   ⛔ scope 없는 별칭은 오류로 세울 것

⚠ 별칭과 대체는 다른 것 — 섞지 말 것 (2026-09-13)

무엇 어떻게
별칭 같은 것을 다르게 부름 — 단가가 같음 별칭표에 scope 와 함께
대체 대응하는 것이 아예 없어 다른 것으로 갈음 — 단가가 다를 수 있음 ⛔ 별칭표에 넣지 말 것. 설계가 고르게 드러낼 것

가르는 법 — 카탈로그에 원래 이름이 있나 보면 됨. 보기) 노임 카탈로그에 화약취급공 은 있고 화약공 은 없음 ⇒ 표기 차이(별칭 후보). 소운반인부 는 카탈로그에 아예 없음 ⇒ 보통인부로 붙이는 것은 대체이지 별칭이 아님. 대체는 도메인 판단이라 사용자 확인 자리임.

⭐ 후보 넷 판정 (2026-09-13 브레인, 사용자 위임)

랩탑 메인이 「범위 별칭 후보」로 올린 넷을 갈랐음. 별칭은 하나뿐임.

후보 판정 까닭
화약공 → 화약취급공 ✅ 별칭 · scope FP-09-05 계열 「화약취급공」이 건설업 노임 표준 직종명이고 품셈이 표 안에서 줄여 적은 것. 같은 사람이라 단가가 갈릴 이유 없음
소운반인부 → 보통인부 ⛔ 별칭 아님 — 「표 읽기」로 옮김 품셈 원본에 0건이고 어느 사전에도 없음. 표준품셈에서 소운반은 직종이 아니라 작업 성격이고 품은 보통인부로 계상함. FP-12-10·FP-12-15 에서 나온 것으로 보아 표의 한 칸을 자원 이름으로 읽었을 가능성이 큼
소형브레이커 → (공압식) ⛔ 별칭 아님 — 「규격 미정 · 후보 2」 공압식·전기식은 다른 장비이고 단가가 다름. 품셈이 형식을 안 정했다는 뜻
공기압축기(3.5㎥/min) → (이동식) ⛔ 별칭 아님 — 「규격 미정 · 후보 N」 품셈은 용량으로, 카탈로그는 형식으로 부름 — 축이 다름. ⚠ 이동식 목록에 3.5㎥/min 이 있으면 규격으로 바로 걸림(별칭 불필요) — 그것부터 볼 것

⇒ 별칭 1 · 표 읽기 1 · 규격 고르기 2. ⚠ 「이름이 안 맞는다」를 전부 별칭으로 풀려 하면 근거 없이 단가가 붙음. 먼저 표를 잘못 읽은 것인지, 다음 규격이 안 정해진 것인지, 마지막이 별칭임.

흩어진 세 벌(Handoff_Mapping 의 파쇄암·암절취 · B09 의 파쇄암만 · B08 인계본 ground_class_aliases — B09 가 안 읽음)을 한 벌로 모으되 범위를 붙여 옮길 것. 범위 없이 합치면 발파암이 리핑암으로 조용히 섞임.

6. 이중계상 경계 — 축으로 판정

지금은 주석 경고뿐임. 코드가 잡게 세울 것.

규칙 판정 자리
구조물 터파기·되메우기는 토공집계로만 공종 축 — 같은 물량이 두 공종 코드에 붙으면 오류
콘크리트 배합 성분(시멘트·모래·자갈)은 일위대가만 쪼갬 자원 축 — 자재총괄에 배합 성분이 뜨면 오류
자재 할증은 자재총괄 한 곳 material_amounts_are_before_surcharge=true 정책 이미 있음

원문 규칙은 docs/raw/plans/2026-09-13b_plan_구컨셉_전문_재편전.md 8-7절. 세우기 전에 반드시 대조할 것.

7. 반올림 — 자리마다 다름 (STmate 실증, 17·18번)

⚠ 한 가지로 통일하면 틀림. 자리마다 다른 것이 실측 결과임.

자리 규칙 근거
호표 안 성분 소계 절사 중기사용료 398건 100% · 일위대가 345건 94.2%
집계표 행 금액 ROUND 자원 셋(재료비·노무비·경비) 279/279
중기시간금액집계표 성분마다 반올림한 뒤 합 131/144. ⚠ 합계를 한 번에 반올림하면 107/144 로 떨어짐
내역에 실릴 때 정수 절사 착공내역서 178건 100%
단가산출 성분단가 소수 1자리 절사 211건 중 137건 설명
내부 계산 은행가(최근접-짝수) STmate 내부. ⚠ 뽑은 엑셀은 사사오입이라 20개 경계 중 10개가 갈림

⭐⭐ 2026-09-14 — 위 실측이 고시 조문과 그대로 맞았음

산림청고시 제2025-82호 「산림사업 표준품셈」 1-2-2 「2. 금액의 단위표준」:

종목 단위 지위 비고 우리 실측과
설계서의 총액 원 1,000 미만버림 ⚠ 우리는 안 버리고 있었음 — 실무 6건은 여섯 다 000, 우리는 373·695·578·654·341·639. 기본을 켜는 것으로 판정(2026-09-14)
설계서의 소계 원 1 미만버림 ✅
설계서의 금액란 원 1 미만버림 ✅ 「내역에 실릴 때 정수 절사」와 같음
일위대가표의 계금 원 1 미만버림 ✅ 「호표 안 성분 소계 절사」와 같음
일위대가표의 금액란 원 0.1 미만버림 ✅ 「단가산출 성분단가 소수 1자리 절사」와 같음

⇒ STmate 를 재서 얻은 규칙이 법 조문이었음. 경쟁사를 베낀 것이 아니라 둘 다 같은 고시를 따른 것임.

⚠ 총액 줄만 우리가 안 따르고 있었음 (2026-09-14 데스크탑 서브 실측). 기본값이 꺼져 있어(cut_basis="") 실무 6건의 총공사비 끝 세 자리가 우리 엔진에서만 남음. 기본을 켜되 화면에 근거를 보일 것 — 2026-09-08 「조용히 깎지 않음」 합의는 근거가 없을 때 정한 것이고, 지금은 고시가 근거임. 곁에 버그 하나 — 절사 자동보정이 둘째 걸음부터 ÷1.1 을 안 해 경계를 지나쳐 진동함 (울진 신설 654→999→900→910→909…). 다섯 건은 첫 걸음에 앉아 안 드러났음.

⚠ 「설계서의 소계 1원 미만버림」과 우리 「집계표 행 금액 ROUND(279/279)」는 다른 자리로 봄 — 집계표는 설계서 소계가 아님. 같은 자리로 읽을 근거가 나오면 다시 잴 것.

같은 고시 1-2-2 「1. 수량의 단위표준」 [주]:

① 설계서 수량의 단위와 소수자리 표시는 본 표에 따르며, 반올림하여 적용
② 품목이 제시한 소숫자리가 본 표와 다르면 항목 쪽을 우선
③ 본 표에 없는 품은 유사품의 규격·단위수량을 참고, C.G.S 단위 원칙

⇒ 아래 「규정이 없는 자리 = 소수 2자리」는 이 표에도 없는 자리에만 적용할 것. 표에 실린 품목(관류 길이 m 소수 2 · 수로연장 m 소수 1 · 옹벽 ㎡ 소수 1 …)은 표가 규정임.

⭐ 규정이 없는 자리 — 소수점 2자리가 기본값 (2026-09-13 사용자 확정)

단수처리에 법적 근거가 없음이 확인됐음 — 기재부 예정가격작성기준 전 조문에 원단위 절사·관급 올림 조문이 없고, 국고금관리법 §47 과 발주청 지침 영역임(안티그래비티 조사).

규정이 있는 자리   그 규정을 따름 (품셈·발주청 지침·STmate 실증)
규정이 없는 자리   소수점 2자리 · 반올림       ← 기본값. 사용자가 칸으로 바꿈

⇒ STmate 관행(절사·은행가)을 따라도 되는 근거가 생겼음. 발주청 지침이 오면 그것으로 덮음. ⚠ 붙박이로 박지 말 것 — 사용자가 바꿀 칸으로 둘 것.

식을 접지 말 것 둘

  • 노임 시간당 환산 — 식 문자열을 좌→우 순차 평가. 계수로 미리 곱하면 267,360 × 0.20833… = 55,699.99… → 55,699 로 1원 틀림. 좌→우는 모든 단계가 정수라 55,700.

    ⚠⚠ 2026-09-13 정정 — 「18/18 원 단위」는 틀렸음(랩탑 서브 실측).

    다섯 건        원 미만 절사
2025 울진소광   0.1 원 미만 절사   (57,077.2 · 49,479.1 · 35,608.3)

    ⇒ 자릿수가 프로젝트마다 다름. 실무 설정값임. 프로젝트 설정 칸으로 둘 것 · 기본 0(원 단위). 붙박이로 박지 말 것

  • 단가산출 Q 식 — Q = 3600 × q × K × f × E / Cm. ⚠ Q 를 소수 2자리로 먼저 확정한 뒤 나눌 것(55,700/15.708 = 3,545.96 ≠ 55,700/15.71 = 3,545.5)

중기 시간당 사용료 조립 — 손료(경비) · 운전원(노무) · 주연료(재료) · 잡품(재료). ⚠ 잡품은 수량 × 단가가 아니라 연료비 × 비율의 가산 행임.

8. 검산 계약 — 무엇이 「끝났다」인가

STmate 골든셋 재현이 초록이면 끝.

⚠⚠ 2026-09-14 보강 — 초록이 늘 증거인 것은 아님

판정 기준을 받으면, 그 기준이 이 변경을 실제로 잴 수 있는지부터 볼 것. 못 재면 그 자리에서 말하고 잴 수 있는 것을 새로 만들 것. 브레인이 준 기준도 마찬가지임.

드러난 자리 — 인계 수량 자리 맞춤(1-2-2 [주]① 반올림) 때 브레인이 「골든셋 전수 초록」을 판정 기준으로 줬으나, 골든 금액 시험은 STmate 원본 수량을 bill_line 에 바로 넣어 새 길을 안 거침. 초록이어도 증거가 아니었음. 랩탑 메인이 이를 알아채고 원본 내역 수량 321줄을 자리 규칙에 통과시키는 대조를 따로 만들어 4줄 빨강을 뽑아냄 (영월·울진 철근·철근운반 Ton 0.264·0.008 을 기본 2자리가 자름 → 철근 kg 정수 = ton 소수 3자리 환산 + 단위 대소문자 흡수로 321/321). 그 대조를 test_b09_quantity_digits_golden.py 로 남김.

재지 못한 것을 잰 척하지 않을 것 — 같은 보고에 「원본 수량 대부분이 정수라 자리 규칙 전체를 입증하진 못함」이라고 한계를 그대로 적었음. 그것이 옳은 모양임.

  • 기준점 — 실무 6건 · 내역 1,515행을 원 단위로 재현한 실증본 (…/STmate 분석/20_분석/16_골든셋_회귀_결과.md)
  • 시험 자리 — resources/tester/ (git 추적 대상)
  • 시험 코드는 코드 창이 짜고 판정은 브레인이 함

⭐ 어느 창에서든 돎 (2026-09-13 확인) — 골든셋 스크립트는 로컬 원본 C:\경영정보(주) 를 안 씀. 저장소 안 resources/knowledge/original/실무문서/ 의 STC·XLSX 만 봄. 절대경로가 박혀 있던 것을 24개 스크립트 전부 저장소 뿌리 자동탐색(_repo_root())으로 고쳤고 고친 뒤 6건 초록 유지를 확인했음. ⇒ 랩탑에서 그대로 돌릴 수 있음.

쓸 것 무엇을 하나
40_스크립트/golden_regression.py 이것 하나면 됨 — 프로젝트 짝짓기부터 직접비·간접비 대조까지
40_스크립트/golden_bonghwa_full.py 봉화 한 건을 총공사비까지 훑음
40_스크립트/revision_direct_cost.py 변경설계

⚠ 로컬 원본이 필요한 스크립트 25개는 설치폴더(PE·폼·JB) 분석용이라 검산과 무관함.

⚠ 골든셋은 계산 엔진을 재는 것이지 기준자료를 재는 것이 아님. 기초단가 원천(자재 57,580 · 노임 460 · 중기 833 · 표준시장단가 4,921건)은 전부 암호화라 영영 못 가져옴 — 그 자리는 사용자 수동입력 + 빨간 테두리로 둠.

9. 아직 안 정한 것

  • 일위대가 재귀 깊이 한도 — 사용자 답 대기
  • 옆도랑파기 갈래 수(우리 둘 ↔ 실무 셋) · 노면고르기 ↔ 노면다짐 — 사용자 답 대기
  • undetermined 75표 판정 — 사람이 봐야 함. 값을 쓰면 뒤집힌 채 들어감
  • 못 맞춘 497줄 잇기 — ⭐ 재료가 생겼음(2026-09-13). 아래 §11 참고. 남은 것은 「품셈 이름 ↔ STmate 자재명」 맞추기이지 목록 구하기가 아님

11. ⭐ 이름·코드 목록 — 확보됨 (2026-09-13)

STC 의 COSTN.DBF 가 암호화가 아니라 코드·명칭·규격·단위가 평문으로 읽힘. 실무 7건을 합쳐 서로 다른 코드 894개.

resources/knowledge/original/경쟁사 프로그램/STmate 분석/30_원자료/stmate_code_name_list.csv
열 : code , name , size , unit          ← size 가 곧 우리 resource_spec

D 단가산출 273 · M 재료 228 · B 일위대가 158 · X 중기 96
S 경비 92 · L 노임 37 · W 일식·견적 10

곁들여 노임 직종 사전 106종이 평문으로 있음 (ST_U_Convert.CPM · 28번 §3.1).

⚠ 그대로 우리 코드로 쓰지 말 것

STmate 코드는 B00001·M00042 꼴로 층 글자 + 다섯 자리이고 대시가 없음. 우리 규약(B-<공종코드>)과 모양이 비슷해 헷갈리기 딱 좋음.

  • 우리 자원 코드는 AR-<M|L|X>-<8자리 16진> 그대로 감
  • STmate 코드는 별칭표(5장)에 한 줄로 실을 것 — 양방향 조회용·교차 확인용
  • 까닭 — 894개는 그 7개 프로젝트가 실제로 쓴 것만임. 배포 전체 카탈로그 (JDCODE_M.BSC 자재 57,580건 등)는 여전히 암호화라 못 읽음. 남의 내부 번호를 정본으로 삼으면 나중에 빈 자리를 못 메움

⚠⚠ 규격은 선택이 아니라 조인 키임 — 수치 근거 (29번)

암호화 기준자료도 스키마는 평문이라 뼈대를 잴 수 있었음. 잰 결과:

자재 사전 JDCODE_M.BSC   코드 57,580건  ↔  명칭 1,761종
                         같은 이름이 규격만 달리해 평균 33건씩 갈림
                         규격 칸 110자 · 단위 사전 59종(자재)·130종(통합) · 분류 4~5단

⇒ 이름만으로는 원리적으로 못 맞춤. 「이름으로 맞추고 규격으로 확인」이 아니라 (이름 + 규격) 한 쌍이 키임. 못 맞춘 497줄의 뿌리가 이 수치로 설명됨.

쓰는 법

  1. size 칸을 반드시 같이 볼 것 — 3장 ③ 「규격이 없으면 매칭 성공이 아님」이 여기서 걸림
  2. 출력 XLSX 목록표 시트 6종에서 317개가 따로 읽힘 — 교차 확인용
  3. 임도에서 실제 쓰는 자재·기계라면 못 맞춘 497줄 중 상당수가 894개 안에 있을 것으로 봄. 맞춰 보고 남는 것만 새로 AR- 코드를 낼 것

12. 납품 규격 — 조달청 공사원가호환규정 (근거, 범위 밖)

System\Valid_Xml.vsl 이 조달청 공사원가통합관리시스템 공개 규격 V1.0.5 전문이었음 (1,429줄). STmate 고유가 아니라 국가 표준 납품 규격이라 우리가 그대로 따르면 됨. 사본 — …/STmate 분석/30_원자료/조달청_공사원가호환규정.xsd · 해설 20_분석/30_조달청_호환규정_XSD.md

⭐ 우리 계약 둘을 국가 규격이 뒷받침함

우리가 정한 것 규격이 요구하는 것
산출식을 데이터로 저장(3장 구조물도) 제경비항목에 적용산식·적용산식설명을 실어 보낼 것
제외 구역을 따로 셈 직접공사비정보 에 제요율적용제외공종_금액 이 박혀 있음

⇒ 「식을 칸에 담는다」는 우리 취향이 아니라 납품 요구사항임. 랩탑 서브에게 이 근거를 줄 것.

⚠ 손료가 네 갈래인데 우리는 하나뿐

규격   E0-주간 · E1-야간 · E2-주야간2교대 · E3-주야간3교대
우리   E0 만 (17번 §4 손료율 25개 장비)

⇒ 야간·교대 손료는 품셈에서 가져와야 함. 6장 일감으로 세웠음.

(기계경비 산출 구간 H0-일반 · H1-터널 · H2-장대터널 · H3~H5 준설선 은 우리가 UI 에서 캔 RX1NM~RX4NM 과 하나도 안 틀리고 같음 — 검증 통과로 봄.)

⚠ XSD 납품 기능 자체는 지금 판의 범위 밖임. 여기는 근거로만 둠.

13. ⭐ 식 칸 계약 — 구조물도(3장)와 라이브러리 양식형(4장) 공용

한 계약임. 구조물도 한 줄이 들고 가는 모양이 곧 라이브러리 양식형 항목의 모양임. 따로 만들면 라이브러리가 구조물도를 못 낳음.

한 줄이 들고 갈 칸

{
  "seq":          3,
  "name":         "고임돌",
  "spec":         "",
  "formula":      "AREA * LOOKUP(뒷길이표, L3, '고임돌')",
  "formula_text": "돌쌓기면적 × 고임돌 원단위",
  "refs":         { "AREA": 1 },
  "vars":         { "L3": 45 },
  "amount":       "0.18",
  "unit":         "㎥",
  "rounding":     { "mode": "floor", "digits": 2 },
  "source":       "library"
}
칸 무엇
formula 기계가 푸는 식. 여기가 정본
formula_text 사람이 읽는 산출 기초. 조달청 규격의 적용산식설명 자리
refs 앞 줄 결과를 이름으로 받음 (AREA → 1번 줄)
vars 제원 칸 (집계표·라이브러리에서 옴)
rounding 줄마다 다름 — 아래
source auto · user · library — 줄마다 출처 표시
when ⭐ 줄이 서느냐 — 거짓이면 그 줄은 아예 안 남(0 이 아님)
destination ⭐ 갈 곳 — earthwork·material·unit_price·reference·haul_deduction

⭐ 칸 셋 보강 — 2026-09-13 판정 (랩탑 서브 제안, 셋 다 채택)

Ⓐ when — 「0」과 「없음」은 다름

지금 전개도 버림·채집석·고임돌을 줄 자체를 안 세우는 방식임(실무 표도 찰쌓기 11줄 ↔ 메쌓기 8줄로 갈림).

when 이 거짓  →  그 줄은 산출물에 나가지 않음. 0 으로도 나가지 않음
  • ⛔ 안 선 줄을 refs 로 가리키면 오류로 세울 것. 조용히 0 으로 치면 뒷줄이 통째로 틀어짐
  • 화면에는 「안 섬」과 까닭을 보일 것 — 빈칸으로 두면 빠뜨린 것과 구별이 안 됨

Ⓑ destination — 이중계상 경계를 줄 단위로 적는 칸

6장의 규칙이 지금까지 주석 경고였는데, 이 칸이 그것을 데이터로 만듦.

값 어디로 6장 규칙
earthwork 토공집계 구조물 터파기·되메우기는 여기만
material 자재총괄 ⚠ 배합 성분은 오면 안 됨
unit_price 일위대가 콘크리트 배합은 여기만 쪼갬
reference 보여주기만 어디에도 안 실림
haul_deduction 운반 공제

⛔⛔ destination 이 빠진 줄은 오류로 세울 것. 기본값을 주지 말 것. 까닭 — 이미 그 결함이 실재함. 자재총괄에서 유로폼·면목·이형철근·떼가 축 이름 누락으로 기본값에 빨려 통째로 빠져 있었음(랩탑 메인 조사). 기본값은 빠진 것을 조용하게 만듦.

Ⓒ 이름은 고정, 종류는 spec 으로

돌 줄 이름이 돌 종류(야면석·호박돌·깬잡석…)를 따라 바뀌는 자리 — name 은 「돌」로 고정하고 spec 에 종류를 담음. name_formula 는 쓰지 않음.

  • 까닭 — 11장에서 (이름 + 규격)이 조인 키라고 못 박았음. 이름이 식으로 바뀌면 조인 키가 흔들리고 별칭표(5장)도 못 걸림
  • 종류를 안 고른 경우는 spec 이 빔 ⇒ 3장 ③ 대로 매칭 성공이 아님 ⇒ 「규격 미정 — 후보 N」 으로 드러낼 것(성공으로 세지 말 것)

식 언어 — 확정 (2026-09-13 보강, 소광리 53탭 전수 실측 반영)

연산  + - * / ^  ( )
비교  =  <>  <  <=  >  >=            ← IF 조건에 씀
함수  SQRT · MIN · MAX · SUM · IF(조건, 참, 거짓)
      LOOKUP(표이름, 키, 열이름)        근사 일치 (기본)
      LOOKUP_EXACT(표이름, 키, 열이름)  정확 일치
참조  refs 의 이름(앞 줄) · vars 의 이름(제원)

실측 근거 — ROUND 105 · INT×100/100 36 · ROUNDDOWN 25 · ROUNDUP 9 · IF 36(비교식 11) · VLOOKUP 13(전부 근사) · SUM 47. ⇒ SUM 과 비교 연산이 빠져 있었음. 넣음.

LOOKUP 은 근사 일치가 기본 — 실무 13건이 전부 근사이고 뒷길이표가 35/45/55/60 구간 표라 그것이 맞음. ⚠ 표는 키 오름차순으로 저장할 것 — 근사 일치는 정렬을 전제로 함. 정확 일치가 필요하면 LOOKUP_EXACT 를 쓸 것.

⚠ LOOKUP 은 반드시 있어야 함 — 실무 표가 뒷길이별 원단위표를 VLOOKUP 으로 참조함 (35/45/55/60 → 채움콘크리트·고임돌·돌중량). 표는 양식과 한 벌로 저장할 것.

지킬 것 넷

  1. 상수 폴딩 금지 · 적힌 차례대로 풀 것. 중간값을 미리 접으면 1원이 틀어짐 (STmate 실증 — 267,360 × 0.20833… = 55,699 ✗ / 좌→우 = 55,700 ✅. 18건 중 14건만 맞았음)

  2. 앞 줄만 참조. refs 는 자기보다 작은 seq 만 가리킴 ⇒ 순환이 원리적으로 불가

  3. 반올림은 줄마다 칸으로. 한 가지로 통일하면 실무 값과 원 단위에서 갈림

    mode : floor · trunc · round · ceil_away · ceil · none · round_half_even
실무 한 표 안에 INT(x*100)/100 · ROUND(,2) · ROUNDUP(,2) · 없음이 섞여 있었음

    ⚠ 엑셀 함수 ↔ 모드 대응표 — 2026-09-13 보강 (브레인 검산에서 틈 둘 발견)

    모드 이름만 보고 옮기면 음수에서 조용히 갈림. 실무 식을 옮길 때 이 표를 볼 것.

    실무 엑셀 뜻 우리 모드 보기 (-2.5)
    INT 아래로 (음의 무한쪽) floor -3
    ROUNDDOWN 0 쪽으로 버림 trunc ⭐신설 -2
    ROUNDUP 0 에서 먼 쪽 올림 ceil_away ⭐신설 -3
    ROUND 사사오입(0 에서 먼 쪽) round -3
    (없음) 위로 (양의 무한쪽) ceil -2
    (없음) 은행가 round_half_even -2

    ⚠ ROUNDDOWN 을 floor 로, ROUNDUP 을 ceil 로 옮기면 안 됨 — 양수에서는 같고 음수에서만 갈리므로 시험을 빠져나감. 실무 실측에 ROUNDDOWN 25건 · ROUNDUP 9건이 있고, 사용자가 식을 고치면 음수가 나올 수 있음 (잔토정리 = 터파기 − 되메우기 같은 뺄셈 줄).

    ⭐ round = 사사오입(HALF_UP) 으로 못 박음 — 구조물도는 실무 엑셀을 본뜨는 표이고 엑셀 ROUND 가 사사오입임. ⚠ B09 내부 계산의 은행가 반올림과 헷갈리지 말 것 — 자리가 다름(7장). 은행가가 필요하면 round_half_even 을 따로 쓸 것

  4. 식을 버리지 말 것. 값만 저장하면 납품 규격(적용산식·적용산식설명)을 못 맞추고, 라이브러리 양식형도 못 만듦 (12장)

양식형 ↔ 고정형

양식형 고정형
formula 있음 — 제원을 바꾸면 amount 가 다시 남 없음(또는 빈칸)
amount 식이 낳은 값 박힌 값 (STmate 내역서에서 뽑음)
vars 제원 칸 안 씀

칸은 같고 formula 유무로만 갈림. 표를 두 벌 만들지 말 것.

14. #갈래 는 무엇인가 — 2026-09-13 판정

랩탑 메인 지적이 맞음. 일위대가 제목 446 중 202 가 B-<코드>#<한글이름> 이고, 지금 B09 는 그 한글을 정규화해 맞추고 있음(normalize_variant_key). 2장 「이름으로 맞추면 결함」과 부딪혀 보임.

가름 — 둘은 다른 자리임.

무엇 이름으로 맞춰도 되나
공종 축 ↔ 자원 축 서로 다른 표를 잇는 것 ⛔ 안 됨. 코드로만
#갈래 한 공종 안의 조건 딱지(토질·암종·규격) ⚠ 지금은 이름으로 맞추고 있어 약함

⚠⚠ 2026-09-13 정정 — 위 판정이 틀렸음

variant_key 를 정본으로 못 씀. 브레인이 「456표에 다 있다」만 보고 「쓸 수 있다」로 넘겼으나, 그 값은 「표 첫 열 값 24개까지」(Build_WorkItemMaster.variant_axis)임.

단가표 갈래 제목 294개 중 그 목록에 있는 것  86개  (약 1/3)
나머지 208 — 머리행에 갈래가 있는 표(벌목 「5m이상~8m미만」)
             두 단 머리(「굴착기(무한궤도)0.2·밀」)
             구간 이름 어긋남(표 「0.3~0.7m이하」 ↔ 목록 「0.3m미만」)
             첫 열이 자원 이름인 표

⇒ 지금 정본으로 읽으면 3분의 2가 폴백으로 떨어짐.

고쳐 세운 판정 둘

  1. 지금은 B09 단가표 제목을 정본으로 둘 것(모양별 읽기가 이미 만든 것). find_variant_code 의 느슨한 맞춤(수의 짝·구간 고르기)이 쓰일 때 로그로 남길 것 — 조용히 다른 갈래에 붙는 자리가 바로 거기임
  2. 마스터 생성기가 표 모양(첫 열 / 머리행 / 두 단)대로 variant_key 를 다시 뽑게 할 것 — 1장 마스터 일감. 그것이 서면 그때 정본을 옮김

(지난 판정) 마스터의 variant_key 를 정본으로 삼을 것 — ⛔ 위 정정으로 뒤집힘

  • 마스터 456표 전부에 variant_key 가 이미 있음(브레인 확인). 그런데 B09 가 안 읽고 변형 문자열에서 매번 다시 만들어 씀
  • B09 가 variant_key 를 읽게 고칠 것. 문자열 재파생은 폴백으로만 남김
  • 폴백이 실제로 쓰이면 로그로 남길 것 — 조용히 다른 갈래에 붙는 것을 잡으려는 것임

15. 판정 — 층이 갈리는 자리

✅ 콘크리트 축 — 닫음 (2026-09-13, 기술정보DB 근거)

충돌이 아니었음. 층이 둘이라 둘 다 맞음.

공종  콘크리트 타설 (레미콘/기계비빔/인력비빔)   FP-12-01 · ㎥ · 품   → unit_price
자재  레미콘 (25-18-120 등)                      mat_remicon · 원/㎥  → material
근거 어디
「콘크리트 타설(레미콘/기계비빔/인력비빔) · 12-1 · ㎥」 = 공종 04_수량분석정보/구조물_수량.md:61
mat_remicon 레미콘 = 자재, B3-1 타설 에 붙음 05_원가정보/원가_입력변수_사전.md:77
「단가산출서·일위대가: 수량 × 자재단가 = 재료비(GC)」 05_원가정보/자재단가_적용.md:85
레미콘은 사급 조달가 채택 품목 자재단가_적용.md:33
레미콘 타설 할증 무근 2 % · 철근 1 % — 자재 할증 자리 04_수량분석정보/수량산출_일반.md:65

규칙

  1. 타설은 공종 → unit_price. 레미콘은 자재 → material. 같은 물량의 두 얼굴이지 두 번 세는 것이 아님
  2. ⛔ 배합 성분(시멘트·모래·자갈)을 쪼개는 것은 일위대가만. 자재총괄에 배합 성분이 뜨면 그때가 이중계상임(6장)
  3. 할증은 자재총괄 한 곳 — 레미콘 무근 2 % · 철근 1 %. 일위대가 재료비는 할증 전 값을 씀
  4. ⇒ 두 벌을 하나로 합치지 말 것. 전개식이 material 로 보내는 줄과 관측 원단위가 unit_price 로 보내는 줄이 같은 층인지만 확인할 것 — 같은 층에 같은 이름이 둘이면 그것만 하나로

(지난 기록) 콘크리트가 어느 축으로 가나 (랩탑 메인 ⓔ)

  • 전개식은 material 로 보내고, 관측 원단위 JSON 은 unit_price 로 되어 있어 두 벌임
  • 브레인이 근거를 찾지 못함 — 지목된 「확정 3차 ⑥」은 백업 원문에서 막자갈 식 건이라 이 건이 아님
  • 한편 코드 주석은 「콘크리트는 unit_price 로 감 — B09 가 배합을 분해」, 「배합 성분은 산출물에 나타나면 안 됨」이라 unit_price 쪽으로 기울어 보임
  • ⛔ 임의로 고르지 않음. 틀리면 시멘트·모래·자갈이 두 번 세어지거나 통째로 빠짐
  • ⇒ 사용자 확인 대기. 그때까지 양쪽을 그대로 두고 기록만 할 것

16. ⭐ 일위대가 레시피 사전 350개 — 확보 (2026-09-13)

표준일위대가 배포본은 암호화라 못 읽지만 실무에서 실제 쓴 조합은 출력 엑셀에 평문으로 남음.

resources/knowledge/original/경쟁사 프로그램/STmate 분석/30_원자료/일위대가_레시피.json
350개 = 일위대가 132 · 단가산출 136 · 중기 82   ·   구성행 1,729 (조합당 평균 4.9)
한 항목 = { 종류 · 명칭 · 규격 · 단위 · Q식 · 품셈근거 · 구성[{명칭·규격·단위·수량}] }
누락 감사 — 호표 526개 전수, **설명되지 않는 누락 0건**

우리 설계에 바로 걸리는 것 셋

  1. 150/350 이 다른 호표를 참조(2단 이상) — 명세 4장 「하위 일위대가 재귀」가 실데이터로 확인됨. 예) 기슭막이 H=2.0m → 깬잡석찰쌓기 → 석공 0.08인 + 보통인부 0.04인 + 굴삭기 0.3시간. ⇒ 위상순서 계산이 반드시 필요함. 취향이 아니라 자료가 그럼
  2. ⭐ 규격이 바뀌면 구성 목록은 같고 수량만 비례함 (기슭막이 H=2.0 ↔ 2.5 → 2.09/2.61 · 0.31/0.39). ⇒ 「한 조합 + 규격별 수량표」로 접힘. 4장 라이브러리 양식형 자료구조가 이 모양이어야 함 — 규격마다 항목을 새로 만들면 350개가 수천 개로 불어남
  3. 품셈 근거문구를 가진 것은 82개뿐(브레인 실측 — 그중 「건설표준품셈」을 대는 것 69). ⇒ 나머지 268개는 근거가 없음. 현행값으로 임의 확정 금지(지침 「미결 임의 확정 금지」). 그 268개가 곧 수동 확인 대기 목록임

⚠⚠ 읽을 때 함정 둘 — 브레인 실측, 원문 문서에 없음

① 종류에 따라 구성.수량의 뜻이 다름

일위대가 · 중기   수량 = 진짜 수량   (0.4 · 9.95 · 0.2085 · 5.0)
단가산출          수량 = ⚠ 금액      ("274,978" = 형틀목공 노임)

구성행 1,729 중 511(29%)이 1,000 을 넘음 — 대부분 단가산출 줄임. ⛔ 일률적으로 수량으로 읽으면 29% 가 금액인 채 들어감. 종류로 먼저 가를 것.

② 중기 손료 줄은 단위가 「천원」인데 값은 율임

{ "명칭": "굴삭기(0.2m3)", "규격": "무한궤도", "단위": "천원", "수량": 0.2085 }
                                                        ↑ 취득가가 아니라 시간당 손료율

⇒ 손료 = 취득가(천원) × 0.2085 임(7장 중기 조립과 같은 자리). 단위 칸만 보고 금액으로 읽으면 취득가 자리에 율이 들어감.

⚠ 조합은 가져오되 값은 가져오지 말 것

수량은 그 시점 품셈값임. 「조합 = STmate 에서, 값 = 현행 표준품셈에서」 (사용자 확정 방향). 레시피는 뼈대를 베끼는 자료이지 값을 베끼는 자료가 아님.

세 자료가 한 벌임

자료 무엇 명세
stmate_code_name_list.csv 자원 코드·명칭·규격 894개 11장
일위대가_레시피.json 조합 350개 16장
조달청_공사원가호환규정.xsd 납품 규격 12장

17. ⚠⚠ 공종 코드는 품셈 판에 묶임 — 2026-09-13 판정

축 C 의 뿌리에 걸리는 것이라 여기 박음.

FP-* 는 품셈 절 번호를 그대로 싣는 코드임. 그런데 절 번호는 판이 바뀌면 바뀜 — 과거 임도품셈의 절 번호가 현행 산림사업 표준품셈(산림청고시 2025-82호, 2026-01-01 시행)에서 크게 달라졌음이 확인됐음(코덱스 32번).

지금 마스터는 effective_date = 2026-01-01 · dataset = pum_forest 한 판임.

규칙 넷

  1. FP-* 는 그 판 안에서만 유일함. 판을 넘어 같은 코드가 같은 공종이라고 보장되지 않음
  2. ⛔ 번호만 보고 판을 잇지 말 것. 판이 바뀌면 절 대응표(과거판 ↔ 현행판)로 이어야 함. 대응표를 만드는 것이 새 일감임
  3. 라이브러리 항목은 자기가 본 판을 적을 것 — AX-ST-* 는 난수라 판에 안 묶이지만 그 안의 공종 참조(FP-*)는 판에 묶임. 항목마다 pum_edition 칸을 둘 것. 안 적으면 품셈이 갱신되는 날 어느 항목이 흔들리는지 모름
  4. 판이 바뀐 뒤 대응이 안 잡힌 참조는 「확인 대기」로 세우고 값을 쓰지 말 것. 조용히 이웃 절에 붙으면 품이 통째로 달라짐

⚠ 「숫자가 다르다」 = 「품이 바뀌었다」가 아님

코덱스가 레시피 350개를 현행 품셈과 전수 대조했는데 확정은 2개뿐임 (단끊기(절취없음) ↔ 5-16-1 · 제근(밀림) ↔ 9-21). 나머지를 「변경」으로 찍지 않은 판정이 옳음 — 같은 숫자가 없다는 것만으로는 규격·토질·장비·일작업량 조건이 달라진 것인지 품이 개정된 것인지 못 가름.

현행 원문까지 확인   2
절은 찾음·수동대조   11     ← 손댈 순서는 여기부터
후보 절만 찾음       161
근거문구만 있음       69
근거 미기재          107

우리도 같은 태도로 갈 것 — 대조가 안 닫힌 것은 값을 바꾸지 말고 「확인 대기」로 세울 것.

10. 고칠 때

이 문서는 브레인이 관리함. 코드 창이 계약을 바꿔야 하면 고치지 말고 브레인에게 알릴 것 — 두 창이 각자 고치면 계약이 두 벌이 됨.

Reference in New Issue View Git Blame Copy Permalink