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

「복사해서 만들기」(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(그대로 부름)와는 층위가 다름 — ③은 "로직 안에서 하위 로직을 참조냐 복사냐"의 선택이고, ④는 "복사라는 행위 자체가 끝난 뒤 원본-복사본 관계"라 복사인 이상 독립이 자연스러움. ③에서 그대로 부르기를 고른 자리는 계속 정본을 참조하므로 정본이 갱신되면 그 자리만 같이 갱신됨 — 이건 ③의 선택이 그렇게 되도록 만든 것이지 ④가 뒤집는 게 아님.