knowledge(로직): PLAN 3-4 복사해서 만들기 설계 밑그림 — 별칭 규칙·전수 수치·로직부르기 갈래

찾기()·로직() 을 이름 하나로 보이는 규칙(겹치면 번호) · 로직 1,354개 전수 조사(찾기 7,500·
로직부르기 1,022 · 같은 표 다른 인자로 겹치는 행 507건은 예외가 아니라 흔한 경우) ·
로직 부르기 참조냐 복사냐 두 갈래 비교와 브레인 판정 제안(기본은 참조 유지) · 복사본은
원본이 나중에 바뀌어도 안 따라감(스냅숏) 및 까닭. 화면 코드는 안 만듦 — 설계 문서만.

resources/master_data/ref/_설계_식_복사.md

@@ -0,0 +1,55 @@
+# 「복사해서 만들기」(PLAN 3-4) 설계 밑그림 — 식과 데이터만
+
+대상: PLAN.md 3-4. 화면은 안 만듦 — 규칙과 수치 근거만 정리. 3-0 전제 그대로 따름: **정본 로직은 원문 그대로 · 화면에서 못 고침 · 개선은 복사한 새 컨테이너(자체 로직 `GX`)에서만.**
+
+수치는 새 `resources/master_data/scripts/analyze_식_복사.py`(읽기 전용 · 아무것도 안 씀)로 냄 — 로직 54개 파일 · 1,354줄 전수, 호표[].수량·호표[].요소·중간[].식·덧줄[].식 안의 `찾기(...)`·`로직(...)` 을 괄호 짝 맞춰 전부 뽑음.
+
+## ① 별칭 규칙 — 같은 표 찾기를 이름 하나로
+
+**보이는 자리**: 식 문자열 속 `찾기(QC001210, '시공높이(m)'=최소(시공높이m, 7.2), 벽두께=벽두께)` 처럼 표 키+인자로 된 부분만 통째로 별칭으로 바꿔 보임 — 뒤에 붙는 `.시공량`·`.조적공` 같은 값칸 이름은 그대로 둠(이미 그 값칸 이름 자체가 뜻을 담고 있어 안 건드림).
+
+**이름 짓기**:
+1. 기본 이름 = 그 표(`소요량_*.json`·`계수_*.json`)의 `이름` 칸, 로직 부르기는 그 로직(`로직_*.json`)의 `이름` 칸.
+2. 같은 행(줄) 안에서 **같은 표를 같은 인자로 두 번 이상** 쓰면 → 별칭 하나로 합쳐 보임(번호 안 붙임 — 완전히 같은 호출이라 겹치는 게 아니라 중복 제거 대상). 예: `GC000575`(벽돌 쌓기)의 중간 3줄이 전부 `찾기(QC001210, '시공높이(m)'=최소(시공높이m, 7.2), 벽두께=벽두께)` — 별칭 `벽돌 쌓기` 하나만 만들고 세 곳 다 그걸 씀.
+3. 같은 행 안에서 **같은 표를 다른 인자로** 쓰거나(아래 ② 507건 — 매우 흔함) **다른 표가 같은 표이름을 우연히 씀**(전체 3,030개 표 중 37개 이름이 92개 표에 겹침 — 예: `재료량` 이름이 표 6개에서 씀 · 행 안에서 실제로 부딪힌 경우는 이번 조사 0건이나 앞으로 생길 수 있음) → 처음 나온 순서대로 번호를 붙임: `벽돌 쌓기1`·`벽돌 쌓기2`… 순서는 그 로직 안에서 처음 등장하는 자리(호표 → 중간 → 덧줄 순) 기준으로 고정.
+4. 이름이 비거나(표에 `이름` 칸이 없음) 너무 길면(대략 12자 넘으면) 표 키를 그대로 보임 — 억지로 줄이지 않음.
+
+**되돌리는 법**: 별칭은 저장하지 않음 — 화면에 보일 때 식 문자열에서 그때그때 만들어 씌우는 겉치레(파생물)일 뿐, JSON에 저장되는 식 원문은 항상 `찾기(원래 키, 원래 인자)` 그대로. 그래서 "되돌리기"는 별도 동작이 필요 없음 — 별칭 보기를 끄면(또는 그 값칸을 표에서 다른 표로 바꾸면) 그냥 다시 원문을 그대로 보여주거나 새 인자로 새 별칭을 다시 만들면 끝.
+
+## ② 로직 1,354개 전수 — 찾기·로직 부르기 수
+
+| 항목 | 수 |
+|---|---|
+| 로직 전체 줄 | 1,354 |
+| `찾기()` 호출 | 7,500 |
+| `로직()` 호출(다른 로직 부르기) | 1,022 |
+| 호출이 하나라도 있는 줄 | 1,319 / 1,354 |
+| 한 자리(호표 수량 한 칸·중간 식 한 줄)에 호출이 2번 이상 겹친 자리 | 801 |
+| 같은 행 안에서 **완전히 같은** 호출(표+인자 동일)이 2번 이상 반복 | 843줄(62%) — ①의 규칙3 "번호 안 붙임" 대상 |
+| 같은 행 안에서 **같은 표를 다른 인자로** 2번 이상 | 507줄(37%) — ①의 규칙3 "번호 붙임" 대상, 흔한 경우로 봐야 함 |
+| 같은 행 안에서 **같은 로직을 다른 인자로** 2번 이상 | 129줄 |
+| 표이름이 겹쳐 번호가 필요한 행(다른 표 키가 같은 표이름) | 0건(이번 자료 기준 — 전체 3,030개 표 중 37개 이름이 92개 표에서 겹치나, 한 행 안에서 동시에 부딪힌 사례는 없음) |
+
+요지: 같은 표를 여러 번 부르는 건 예외가 아니라 절반 이상에서 일어나는 보통 경우(범위형 표를 여러 단·여러 회차에 걸쳐 부르는 산림토목 로직이 다수) — 번호 붙이는 규칙(①-3)은 장식이 아니라 필수 경로로 설계해야 함.
+
+## ③ 로직 부르기(`로직(...)`)를 복사할 때 — 그대로 부를지 같이 복사할지
+
+로직이 다른 로직을 부르는 중첩은 얕음 — 로직이 부르는 로직이 또 다른 로직을 부르는 경우는 전체에서 4건뿐(`GF000170`·`GF000171` → `GF000185` → `GC000268`, `GF000177`·`GF000178` → `GF000168` → `GC000267`). 트리가 깊어질 걱정은 크지 않음.
+
+**갈래 A — 그대로 부름(참조 유지)**
+- 좋은 점: 하나만 관리하면 됨 · 정본이 품셈 개정으로 갱신되면 복사본도 최신 계산을 따라감 · 로직이 로직을 부르는 자리(1,022건)를 전부 펼쳐 복사할 필요가 없어 복사량이 작음.
+- 나쁜 점: 복사본이 완전히 "내 것"은 아님 — 부른 로직 쪽 계산까지 내가 바꾸고 싶으면 결국 그 로직도 복사해야 함(갈래 B로 전환 필요).
+
+**갈래 B — 같이 복사(펼쳐서 자체 로직으로 통째로 복사)**
+- 좋은 점: 복사 시점 값을 완전히 고정 · 부르는 로직의 계산식까지 마음대로 고칠 수 있음.
+- 나쁜 점: 여러 로직이 같은 하위 로직(예: `GC000268` 굴삭기 계열 — 위 4건 포함 자주 불림)을 부르면 복사할 때마다 따로따로 자체 로직이 생겨 같은 계산이 여러 벌로 벌어짐 · 하위 로직에서 나중에 원문 오류가 고쳐져도 복사본은 못 따라가 옛 값을 계속 씀.
+
+**브레인 판정 제안**: 기본은 **갈래 A(그대로 부름)**. 까닭 — 3-0 전제상 정본 로직 자체는 「원문 그대로 · 안 바뀜」이 원칙이라 참조해도 계산이 몰래 바뀔 위험이 원래 없음(바뀌는 유일한 경우는 품셈 개정판 반영인데, 그때는 오히려 참조 전부가 최신 법령을 따라가는 쪽이 맞음). 다만 PLAN 3-4 문구대로 **부르는 자리마다 선택은 사용자에게 맡김** — 그 하위 로직 자체를 고치고 싶다는 뜻이 분명한 경우(예: 인자만 바꾸는 게 아니라 계산식을 바꾸려 할 때)만 그 호출 하나를 갈래 B로 펼침.
+
+## ④ 복사한 뒤 원본이 바뀌면 복사본은?
+
+**안 따라감이 맞음.** 까닭:
+
+- 「복사해서 만들기」를 쓰는 목적 자체가 정본을 안 건드리고 내 것을 만드는 것 — 복사 시점 값을 그대로 박아 넣는 스냅숏이어야 사용자가 그 뒤 손댄 내용과 원본 개정이 뒤섞여 충돌하지 않음.
+- 데이터 3층 원칙(§5)의 결과 같음 — 확정된 값은 그 뒤 원천이 바뀌어도 조용히 안 바뀜(초기값 스냅숏과 같은 결). 설계를 확정해 둔 뒤 원본이 나중에 바뀌었다고 계산 결과가 몰래 달라지면 이미 넘긴 견적이 어긋나는 사고로 이어짐.
+- ③의 갈래 A(그대로 부름)와는 층위가 다름 — ③은 "로직 안에서 하위 로직을 참조냐 복사냐"의 선택이고, ④는 "복사라는 행위 자체가 끝난 뒤 원본-복사본 관계"라 복사인 이상 독립이 자연스러움. ③에서 그대로 부르기를 고른 자리는 계속 정본을 참조하므로 정본이 갱신되면 그 자리만 같이 갱신됨 — 이건 ③의 선택이 그렇게 되도록 만든 것이지 ④가 뒤집는 게 아님.