Aislo/docs/raw/plans/2026-09-08_plan_B05_B06_완료분.md

B05·B06 완료분 (0장 공통 기반 · 3장 B06 횡단설계)

이관 2026-09-08 — docs/raw/PLAN.md 에서 옮김 (원문 그대로). 절 셋은 통째로, 나머지는 완료된 조사·사고 기록만 덜어 옮겼다. 살아있는 미결과 지금도 기준으로 쓰는 표(0-7 확정 규칙 · 3-9 폼 기본값 · 0-5 계산·저장 지도)는 계획서에 남겼다.

0-7. 노선이 바뀌면 세 벌은 어떻게 되나 — 규칙 확정 (2026-09-06 사용자 확정)

데이터 세 벌(①초기값 ②작업본 ③캐시) 규칙은 노선이 그대로일 때만 서 있었음. 노선이 바뀔 때의 규칙이 없어 사용자가 지적(2026-09-06)했고, 같은 날 아래 규칙으로 확정함. 실제 작업은 0-2 에서 하고 이 절은 규칙과 현황만 적음.

당시 현황 조사(「노선을 바꾸는 길 넷」·「지적된 구멍과 답」·「지금 있는 것/없는 것」)는 아카이브로 옮겼음 — docs/raw/plans/2026-09-07_plan_completed_items_3.md. 그 표들은 0-2·0-10·0-12 가 끝나기 전 상태라 지금과 다름. 아래 「확정 규칙」이 지금 기준임.

확정 규칙 (2026-09-06 사용자 확정)

노선을 두 벌로 둔다. 원본과 수정본이며, 수정본은 원본과 같은 값으로 시작한다.

이름	무엇	누가 만드나	바뀌나
예상노선(원본)	파일 업로드 자동 체인이 낸 노선	서버(체인)	안 바뀜
계획노선(수정본)	예상노선을 복사해 시작, 사용자가 고쳐 쓰는 노선	복사 → 사용자 편집	바뀜

1. 노선 변경 = 계획노선만. 예상노선은 어떤 경로로도 안 고침.
2. 전처리 들어가기 전에 두 벌을 확보한다 — 자동 체인이 예상노선을 내면 그 자리에서 계획노선으로 한 벌 복사. 그 뒤 모든 계산은 계획노선 기준이며, 나머지 흐름은 지금과 같다.
3. 화면에는 둘 다 보인다 — 계획노선을 고치는 동안 예상노선이 같이 보여야 어디를 얼마나 옮겼는지 읽힘(0-2 모달).
4. [초기화] = 예상노선을 계획노선으로 다시 복사. 재계산이 아니라 복사다. ②작업본 전체의 초기화(initial_snapshot 복원)와 같은 문법 — 원본을 수정본 자리에 덮는다.
5. 노선이 바뀌면 배수유역부터 전처리를 다시 돈다. 노선 형상이 달라지면 유역·관·횡단이 전부 그 위에 서 있기 때문.
6. 둘로 갈라 다룬다 (2026-09-06 사용자 확정).
   • 횡단배수 지점(관 지점 정본 pipe_points.json — 배수관·세월교·물넘이·BOX) — 노선 자리에 따라 생기고 없어지는 것이라 옛 값을 물려받지 않고 새로 계산한 값을 씀. 지금 있는 좌표 투영 이월(load_pipe_points_file → project_pipe_points)은 쓰지 않음.
   • 그 밖의 구조물(structures.json — 기슭막이·옹벽 등) — 옛 측점값(누가거리)을 그대로 이어받음. 그래야 사용자가 고쳐 둔 값이 살아남음. 자동 재배치·삭제 없음.
7. 계산은 모달 [확인]을 눌렀을 때만 시작한다. 얽힌 계산이 많아 편집 중에 돌면 안 됨. 모달을 닫기 전까지는 아무 계산도 나가지 않음.
8. 화면 표기 — 예상노선은 점선, 계획노선은 실선.
9. 재계산은 초기 파일 업로드 체인의 로직을 재사용한다 (2026-09-06 사용자 제안, 코드 확인함). 이미 「재확정 체인」(run_redesign_chain)이 그 뼈대임 — 배수유역 다시 분석(refresh=True) → 기본 관 저장 → 관 정착 계획선 재산출 → 종횡단 재생성 → 옛 측점 설계를 누가거리로 이월 → B05·B06 확정까지 이미 한 줄로 돎. 노선 편집이 쓰려면 한 곳만 손보면 됨: 지금은 노선을 자동탐색으로 다시 푸는데, 사용자가 고친 계획노선을 그대로 받아 쓰는 입구를 하나 내면 나머지 단계는 그대로 재사용됨.

• 투영 이월 코드가 아직 살아 있음 (2026-09-07 위 대조에서 드러남, 작은 건) — common_util_drainage_pipes.py:163·223 project_pipe_points. 0-2 경로에서는 파일을 먼저 지워 안 탐. 그러나 load_pipe_points_file 이 B05_Profile_Engine_Sections.py:137 에서도 불리므로 다른 경로(지표면 바꿔 재확정 등)에서는 여전히 탐. 규칙 6 이 「투영 이월은 쓰지 않음」이라 했으니 그 경로도 정리 대상인지 정할 것. 고치면 호출 한 곳에서 vertices 를 안 넘겨 버리는 쪽으로 감.
  • ⛔ 조사 결과(2026-09-07 보조 창) — 빼면 관이 사라짐. 배분 창·사용자 판단 대기.

    • ⓐ 언제 도나 — 드문 경로가 아니라 B05 종횡단을 만들 때마다 늘 탐 (build_sections → _load_pipe_points). 자동설계 체인도 여기를 지남.

    • ⓑ 관 자리를 옛 노선으로 옮겨 붙이나 — 아님. 저장분 3개로 실측: 8879c53b 관 48건 · 5601e828 11건 · b269ea34 10건, 이동량 최대 0.01m (0.05m 넘는 관 0건). 「이월」이 아니라 같은 선을 두 정점열로 다시 매기는 것임.

    • 왜 지문이 늘 어긋나나 — 두 쪽이 서로 다른 파일을 읽기 때문. 저장된 지문이 planned_route.csv 지문과 글자까지 같음(5601e828 169-bea8d2a6e9fcd08e, b269ea34 115-1b8c4294d9e2c9b8). B05 는 route_main.geojson 을 읽어 다른 지문이 남 (169-59cc… · 115-51e9…). 정점 수는 같고 DB route_points 와 파일 좌표는 0.000000m 차이라 같은 노선이 맞음. 즉 「지문 일치」 가지는 사실상 죽은 길이고 투영이 정상 경로임.

    • ⓒ 빼면 무엇이 서나 — 아무것도 안 섬. vertices 를 안 넘기면 지문 불일치 → load_pipe_points_file 이 None → _load_pipe_points 가 [] → 관 0건 · 구조물 측점 0건. 2026-08-30 사용자가 지적한 그 결함으로 되돌아감. 기능 제거이므로 손대지 않았음.

    • 규칙 6 위반이 아님 — 규칙 6 은 노선이 바뀔 때 이야기인데 이 경로는 노선이 안 바뀌었고 한 노선을 두 파일에서 읽는 것임. project_pipe_points 라는 이름과 「이월」이라는 말이 위반처럼 보이게 했을 뿐임.

    • 정리하려면 방향이 다름 — 「호출부에서 vertices 빼기」는 아님. 조사 스크립트는 tmp/tests/probe_pipe_projection.py · probe_route_vertex_delta.py · probe_route_signature_source.py · probe_signature_method_vs_geometry.py 로 남겨 둠.

    • ✅ 왜 지문이 다른가 — 답 나옴. 기하가 아니라 「소수 자릿수」임(2026-09-07, 배분 창 지적으로 한 걸음 더 감). 앞서 잰 「0.000000m」는 DB vs geojson 이었고, 지문을 실제로 만드는 두 입력은 planned_route.csv(B04) vs route_main.geojson(B05) 이었음. 그 둘을 직접 대니 — · planned_route.csv 는 소수 4자리(208403.2001, 367920.7514), route_main.geojson 은 소수 3자리(208403.2, 367920.751) — geojson 이 mm 로 반올림한 사본임. · 좌표 차 최대 0.0005m(0.5mm) · 평균 0.0003m — 같은 노선이 맞음. · 그런데 지문은 f"{x:.2f}" 로 0.01m 자리에서 끊음. 그 0.5mm 가 .xx5 경계를 넘는 정점에서 글자가 바뀜 — 169개 중 16개가 그럼(보기: 367838.8947→.89 vs 367838.8950→.90). 그래서 같은 노선인데 해시가 늘 달랐음. · 지문 함수는 한 벌(route_signature)이고 같은 좌표를 넣으면 같은 지문이 나옴 — 방법이 갈린 게 아니라 입력 정밀도가 갈린 것임(배분 창 가설이 맞았음, 다만 「직렬화 방법」이 아니라 「저장 자릿수」).

    • → 고칠 자리는 「정본 파일 선택」이 아님. 셋 중 하나면 됨 — ① geojson 을 CSV 와 같은 자릿수로 쓰기 ② 지문 입력을 한 쪽으로 맞추기 ③ 지문 비교를 해시 일치 대신 기하 허용오차 (정점 수 같고 최대 좌표차 1mm 미만)로 바꾸기. ③ 이 경계 문제를 아예 없앰. ⚠ 어느 쪽이든 지문이 실제로 맞은 뒤에 투영 가지를 지울 것 — 순서가 뒤집히면 관이 사라짐.

    • ✅ ③ 구현 끝냄(2026-09-07, 커밋 e2d329d3).

      • 명세를 한 군데 바꿨음 — 「정점 수 같고 좌표차 1mm 미만」은 못 씀. 저장 파일에는 옛 노선 좌표가 없고 지문 문자열 하나뿐이라 정점을 댈 대상이 없음. 대신 파일이 실제로 들고 있는 것(관의 x·y)으로 같은 판정을 함 — 저장된 관을 지금 노선에 투영해 재 보기만 하고(max_projection_shift, 값은 안 고침) 최대 어긋남이 한계 안이면 같은 노선으로 봄. 이러면 이미 저장된 파일에도 그대로 듣는다는 이점이 있음(다시 저장할 필요 없음).

      • 허용오차 0.05m — 1mm 는 못 씀. 0.5mm 좌표 차가 누가거리에서는 누적돼 최대 5.3mm 로 나타나기 때문(아래 실측). 0.05m 는 그 열 배 여유이고, 사람이 노드를 끌면 관은 m 단위로 밀리므로 그것을 「같다」로 볼 위험은 없음.

      • 투영 가지는 안 지웠음. 대신 그 가지가 실제로 돌면 WARNING 을 찍게 함 (배수유역: 투영 이월 실행 —). 한동안 0 인 것을 본 뒤에 지울 것.

      • 시험 3건(tmp/tests/test_pipe_route_tolerance.py) — mm 반올림 사본은 같은 노선으로 판정되고 누가거리가 한 값도 안 움직임 / 중간을 3m 민 노선은 안 걸림(그물 확인) / 허용오차 값 범위. 기존 test_pipe_point_projection.py 2건도 그대로 통과 (±0.7m 잔물결 노선은 여전히 투영으로 감). 전체 514 passed · 18 skipped.

      • 저장된 실제 3개 프로젝트 전후 대조(tmp/tests/probe_tolerance_before_after.py) — 셋 다 판정이 「다름 → 투영 이월」에서 「같음 → 저장분 그대로」로 바뀜.

        프로젝트	관	최대 어긋남	화면 값 변화(투영본 → 저장본)
        8879c53b	48건	0.0053m	최대 0.0053m · 평균 0.0023m
        5601e828	11건	0.0009m	최대 0.0009m · 평균 0.0004m
        b269ea34	10건	0.0005m	최대 0.0005m · 평균 0.0002m

        즉 ③ 뒤로 화면 값이 바뀌는 폭은 최대 5.3mm — 도면·수량에 보이지 않는 크기임.

    • 판단(2026-09-07 배분 창) — 지금 고치지 않음. 다만 답 안 난 질문 하나부터 풀 것. · 정점 수가 같고 좌표가 0.000000m 차이인데 왜 지문이 다른가? 기하가 같으면 지문도 같아야 함. 그런데도 다르다면 원인은 기하가 아니라 지문을 만드는 방법(자릿수·직렬화 순서·포함 항목)일 수 있음. 그렇다면 고침은 「정본 파일 갈아치우기」가 아니라 양쪽이 같은 방식으로 지문을 내게 하는 것 — 훨씬 작고 위험도 낮음. · 그 답이 「방법 차이」면 그쪽으로 감. 「진짜 다른 기하」면 그때 어느 파일을 정본으로 삼을지를 정해야 하고, 그건 사용자 판단으로 올림. · ⚠ 어느 쪽이든 투영 가지를 먼저 지우지 말 것. 지문이 실제로 맞게 된 뒤에 지워야 관이 사라지지 않음. 순서가 뒤집히면 2026-08-30 결함으로 되돌아감.

    • 답 나옴 — 기하가 아니라 「저장 자릿수」임 (2026-09-07 보조 창). · 앞서 낸 「0.000000m」는 DB vs geojson 을 잰 값이었고, 지문을 실제로 만드는 두 입력 (planned_route.csv(B04) vs route_main.geojson(B05))은 안 대 봤던 것이었음. · planned_route.csv = 소수 4자리(208403.2001, 367920.7514) · route_main.geojson = 소수 3자리(208403.2, 367920.751, mm 반올림 사본). 좌표 차 최대 0.0005m · 평균 0.0003m — 같은 노선이 맞음. · 그런데 지문은 f"{x:.2f}" 로 0.01m 자리에서 끊음. 그 0.5mm 가 .xx5 경계를 넘는 정점에서 글자가 바뀜 — 169개 중 16개. 보기: 367838.8947→.89 vs 367838.8950→.90. · 지문 함수는 한 벌(route_signature)이고 같은 좌표를 넣으면 같은 지문이 나옴 (시험 통과). 갈린 것은 방법이 아니라 입력 정밀도임. · ⇒ 정본 파일 선택 문제가 아님.

    • 결정(2026-09-07 배분 창) — ③ 허용오차 비교로 감. · 후보 셋 — ① geojson 을 CSV 와 같은 자릿수로 쓰기 ② 지문 입력을 한 쪽으로 맞추기 ③ 지문 비교를 해시 일치 대신 기하 허용오차(정점 수 같고 최대 좌표차 1mm 미만)로. · ③ 인 이유 — ①② 는 이미 저장된 파일이 여전히 어긋난 채라 투영 가지를 계속 태워야 함. ③ 은 경계 문제를 원천에서 없애고 저장 자릿수가 앞으로 또 바뀌어도 안 흔들림. · [x] ③ 구현 완료(2026-09-07 커밋 e2d329d3). 다만 명세 두 곳이 바뀌었고 근거가 있음.

      • 「정점 수 같고 좌표차」로는 못 잼 — 저장 파일에 옛 노선 좌표가 없음(들어 있는 건 지문 문자열 하나뿐). 그래서 파일이 실제로 들고 있는 것(관의 x·y)으로 같은 판정을 함 — 저장된 관을 지금 노선에 투영해 재 보기만 하고(값은 안 고침) 최대 어긋남이 한계 안이면 같은 노선으로 봄. 덤으로 이미 저장된 파일에도 그대로 들음(다시 저장할 필요 없음).
      • 허용오차는 1mm 가 아니라 0.05m — 1mm 면 지금 프로젝트가 전부 탈락함. 좌표 차는 0.5mm 지만 누가거리에서는 선을 따라 누적돼 최대 5.3mm 로 나타남. 0.05m 는 그 열 배 여유이고, 사람이 노드를 끌면 관은 m 단위로 밀리므로 「같다」로 볼 위험이 없음. · [x] 시험 — mm 반올림 사본이 같은 노선으로 판정되고 누가거리가 한 값도 안 움직임 · 중간을 3m 민 노선은 안 걸림(투영으로 감) · 허용오차 값 범위. 기존 test_pipe_point_projection.py 2건도 통과(±0.7m 잔물결 노선은 여전히 투영). 전체 514 passed · 18 skipped. · [x] 저장된 실제 3개 전후 대조 — 셋 다 「다름 → 같음」으로 뒤집힘.

      프로젝트	관	최대 어긋남	화면 값 변화(투영본 → 저장본)
      8879c53b	48건	0.0053m	최대 0.0053m · 평균 0.0023m
      5601e828	11건	0.0009m	최대 0.0009m · 평균 0.0004m
      b269ea34	10건	0.0005m	최대 0.0005m · 평균 0.0002m

      ⇒ ③ 뒤로 화면 값이 바뀌는 폭은 최대 5.3mm — 도면·수량에 안 보이는 크기임. (앞서 「최대 0.01m」라 한 것은 정렬 목록끼리 뺀 값이라 조금 컸음.) · [x] 투영 가지는 안 지웠고 로그만 달았음 — 실제로 돌면 WARNING (배수유역: 투영 이월 실행 — 노선이 바뀌어 관 지점 N건을 좌표로 옮깁니다 (최대 어긋남 X)), 허용오차로 통과하면 INFO(지문은 다르나 같은 노선입니다 — 관 N건 그대로 씁니다). · [ ] 한동안 WARNING 이 0 인지 본 뒤 투영 가지를 지울 것. 지금 지우지 말 것 — 순서가 뒤집히면 2026-08-30 결함(관 0건)으로 되돌아감. · 1차 집계(2026-09-07) — 아직 지우지 않음. 근거는 모였으나 「한동안」이 안 됨.

      • 로그 — 서버 로그 전부(tmp/server*.log)에서 투영 WARNING 0건. 옛 형식 (좌표로 이월합니다, INFO) 1건이 남아 있는데 그건 e2d329d3 이전 것임.
      • 저장 자료 6개 실측(tmp/tests/probe_pipe_branch_today.py, 읽기만) — 5개가 허용오차 안(같은 노선): 최대 어긋남 0.0004 · 0.0009 · 0.0017 · 0.0053 · 0.0005m, 전부 0.05m 아래. 투영 가지로 가는 프로젝트 0개.
      • 나머지 1개(325f57d9)는 자료가 깨져 있어 판정 자체가 안 됨 — route_main.geojson 의 정점 135개가 전부 같은 점(선 길이 0)이고 관 좌표는 30km 떨어진 곳임. 옛 시험 프로젝트로 보임. 이 경우는 투영 가지도 안 타고 관이 None 이 됨.
      • ⇒ 지우는 이득이 작고 위험이 큼. 지워서 얻는 것은 코드 몇 줄이고, 잃는 것은 「노선이 진짜 바뀐 경우」의 안전망임(대체 경로인 관 재배치가 아직 없음). 꺼낼 조건을 분명히 함 — ① 노선 재확정을 몇 번 더 돌린 뒤에도 WARNING 0 이고 ② 노선이 실제로 바뀌었을 때 관을 다시 놓는 경로가 서 있을 것. 둘 다일 때만 지움.

이 절의 완료분은 아카이브로 옮겼음 — 2026-09-07_plan_completed_items_2.md · …_3.md(docs/raw/plans/).

0-8. 속도 개선 — 한 묶음 기록 (2026-09-06 완료, 두 창 공동)

본문(목표·결과·고친 것 ⓐ~ⓕ·안 하기로 한 것·재발 방지)은 아카이브로 옮겼음 — docs/raw/plans/2026-09-07_plan_completed_items_3.md. 여기에는 남은 것만 둠.

남은 것

• 호출량 — 막지 말고 「왜 이렇게 잦은지」부터 볼 것 (2026-09-07 사용자 지시 「일단은 막지말고 이건 어떤 부분에 영향을 미치는지 왜 이렇게 자주 요청하는지 확인해줘」). 지금은 넘어도 막지 않고 기록만 함(API_CALL_HOURLY_LIMIT 기본 20000/시간).

  • 답 — 지금은 잦지 않음. 상한에 닿은 적도 없음 (2026-09-07 조사, 막는 것은 안 함).

  • 상한이 하는 일 = 기록뿐 — main.py:397~403 미들웨어가 /api/ 로 시작하는 요청만 세고, note_api_call(common_util_audit.py:105~125)이 세션별·시간대별 메모리 카운터를 올림. 20,000 을 넘으면 그 시간대에 딱 한 번 감사기록 RATE_ANOMALY 한 줄 + 경고 로그 한 줄. 막지도 늦추지도 거절하지도 않음. 넘어도 사용자에게 변화 없음. 요청당 비용도 없음(메모리).

  • 실측 (공용 브라우저, 용화 5601e828 · B06) —

    무엇	/api/ 호출
    페이지 한 번 여는 데	11건 (sections/{n} 2 · …/detail 2 · auth/session 1 · workflow-state 1 · dashboard/me 1 · sections/company-standards 1 · projects/structure-types 1 · route/structures 1 · drainage/pipe-points 1)
    화면 이동 B06 → B05	1건 (auth/session)
    화면 이동 B05 → B06	1건
    가만히 둘 때 60초	0건

  • 되풀이·폴링 없음 — 유휴에서 한 건도 안 나감. 0-1 에 「이동 한 번에 B05→B06 12건 · B06→B05 20건」으로 적힌 것이 지금 1건임(캐시·중복 제거가 실제로 서 있고 다시 늘어난 자리 없음). 20,000/시간에 닿으려면 초당 5.5건을 한 시간 내내 내야 함 — 이 프로필로는 불가능. 옳은 표(system_audit_logs)에서 RATE_ANOMALY 0건.

  • 곁가지 — 지도 타일이 왜 안 세이나: 경로가 /api/ 밖이라서(2026-09-07 확인). 감시는 main.py:399 의 path.startswith("/api/") 한 줄이고, 타일은 @tiles_router.get("/tiles/{project_id}/{layer}/{z}/{x}/{y}.pbf") (B04_PreProcess_Router_GIS.py:187, prefix 없음)이라 그 그물에 안 걸림.

    • 켤 수는 있음 — 한 줄(startswith(("/api/", "/tiles/"))). 다만 지도를 끌면 타일이 수십 건씩 나가므로 상한 경고가 늘 울릴 것임. 상한을 타일용으로 따로 잡지 않으면 경고가 소음이 되어 오히려 감시가 무뎌짐.
    • ⇒ 지금은 안 켬(권고). 켤 조건 = 타일 남용을 실제로 걱정할 때 + 타일용 상한을 따로 정할 때.

  • 곁가지 — 빈 표 audit_logs 지움(2026-09-07 사용자 지시). db_management/019_drop_legacy_audit_logs.sql — 공용 DB 에 적용 완료.

    • 지우기 전 확인 — audit_logs 0행 · 정본 system_audit_logs 81행 · 이 표를 참조하는 외래키 0건 · 코드는 쓰기(common_util_audit.py:61)·읽기 (B01_Dashboard_Repository.py:455·460)·정리(purge_expired_audit_logs) 전부 정본만 씀.
    • 최초 스키마(001_create_schema.sql)는 안 고침 — 지나간 이력은 다시 쓰지 않음.
    • 공용 DB 라 적용 전 두 창에 알리고 25 의 「막을 것 없음」을 받은 뒤 돌림. 서버 재시작 없음.

이 절의 완료분은 아카이브로 옮겼음 — 2026-09-07_plan_completed_items_2.md · …_3.md(docs/raw/plans/).

3-6. B06 구조물 추가 — 남은 확인 (2026-09-05 조사)

이미 가능하다. B06 좌측 「구조물 배치」는 B05와 같은 폼·목록 부품을 쓴다(B06_Section_UI_Page_Structures_Panel.ts → 공용 A00_Common/b_structures_section). B~G군 구조물의 추가·수정·삭제가 세션에 쌓였다가 [저장]·[확정]에서 정본에 들어간다. 다만 계곡 통과 시설(A군 — 배수관·세월교·BOX암거)은 표시·선택만 되고 "추가·삭제는 B05에서 하세요" 안내만 뜬다. 배수유역을 다시 나눠야 하기 때문이다.

• 구조물 전체를 B06 에서 넣게 함 (2026-09-07 사용자 확정 「a군 구조물 뿐만아니라 구조물 전체를 넣을 수 있어야 함」, 보조 창 커밋 a811286e) — 전제가 달랐음: B06 이 A군만 받은 게 아니라, B군(종단배수 6종)·F군(생태 2종)이 레지스트리에서 enabled:false 였고 그래서 B05 도 똑같이 여섯 군만 보였음. fetchStructureTypes(includeDisabled) 갈래를 둬 B06 만 전체를 부름(B05 는 종전대로). 실화면 — B06 목록 8군(A·B·C·D·E·F·G·기타), B05 6군 그대로.
  • ⚠ 답: 안 흐름 (2026-09-07 보조 창 ⑧ 코드 추적) — 넣고 저장은 되나 도면·면적· 수량 어디에도 안 잡힘. 끊기는 자리 셋:
    • ① 측점을 안 심음 — B05_Profile_Structures_Schema.py:85 가 A군 전부 + D군 구간형만 심음. B·F군 제외 → 그 자리에 횡단도 자체가 안 생김.
    • ② 횡단 제원(벽)으로 안 얹힘 — 짝 두 곳이 C군 구간형만 봄 (B06_Section_Section_Store.ts:58 · B06_Section_Engine_Structures_Wall.py:49). 도면·설계선 트림·폐회로 면적·유토곡선·3D 가 전부 이 경로라 B·F군은 그림에도 물량에도 없음.
    • ③ 수량 별도 경로 없음 — B08_Quantity_Router.py 는 구조물 정본을 안 읽음. structures.json 을 읽는 파이썬은 두 곳뿐(B05_Profile_Engine_Sections.py:193, 목록 API).
  • 사용자 결정 (2026-09-07): B군(측구·맹암거) 먼저.
  • 🔴 B군(종단배수 6종)을 수량에 태우기 — 닫힘 (2026-09-08 두 창 대조). 측구는 횡단 설계가 ditch_area_m2 까지 파이썬·TS 짝으로 셈하므로 구조물로 또 세면 이중 계상임. 레지스트리 design_owner: 횡단 설계 가 붙은 것은 ditch_side 하나이고, B08 원단위 전개가 그것을 건너뛰는 것 확인(B08_Quantity_Router_Material.py:61, 건너뛴 사유를 응답에 적음). 연장 산출(common_util_structure_lengths.py)도 같은 규칙. 나머지 다섯(산마루측구·소단측구·도수로·절토사면 배수로·맹암거)은 연장(m) 으로만 나가고 랩탑 창이 실화면에서 산마루측구 1개소 40.0m 확인함. 그 줄들이 인계에 오면 B08 이 그대로 실음.
  • 옛 조사 기록 — 착수 전 설계 조사(2026-09-07 보조 창). 보고서 https://claude.ai/code/artifact/48396d2f-3478-40af-856a-932e81bae306
    • ⚠ 「도랑이라 새 단면 기하가 필요하다」는 전제가 대부분 틀렸음.
    • ① 측구(옆도랑)는 이미 다 되어 있음 — 횡단 설계에 내장돼 있고(카드의 측구 켬/끔 · 일반형/L형), ditch_area_m2(측구 터파기 단면적)를 파이썬·TS 짝으로 이미 셈함 (B06_Section_Engine_Design.py:627 · common_util_cross_design.ts:349). 구조물로 또 넣으면 이중 계상임.
    • ② 나머지 다섯은 횡단도에 그릴 법정 의무가 없음 — 별표2 「횡단면도 각 측점 기입 물량」은 지반고·계획고·절토고·성토고·단면적·지장목 제거·측구터파기 단면적·사면보호공뿐. 산마루측구·도수로·맹암거는 없음. 자리도 횡단도 밖임 — 산마루측구는 사면 정상 바깥, 도수로·산비탈수로는 사면을 따라 내려가는 시설, 맹암거는 땅속.
    • ③ 진짜 비어 있는 길은 수량 하나뿐이고 그게 제일 쉬움 — 수량 단위가 전부 m(연장) (맹암거 12-10 · L형 측구 12-9-1 · 산마루측구 12-9-2 · 소단측구 12-9-3). 단면 기하 불필요. ⇒ 「③ 이 가장 어렵다」가 아니라 **「③ 만 필요하다」**임.
    • 끊긴 자리 셋 재평가 — ① 측점 심기 필요 없음(현행 유지가 맞음) ② 횡단 제원은 도면에 그리기로 정할 때만 ③ 수량 이것만.
    • 지식DB — 치수 기준 없음. 측구만 법정(너비 0.5~1m · 깊이 30㎝ 내외). 나머지는 교본 8장 4절까지 봐도 배치·재료·단면형(반달꼴·U·사다리꼴)만 있고 폭·깊이 수치가 없음. 소단측구는 항목 자체가 없음. 크기 산정법(Manning + 통수단면 2.0배)은 있으나 표준 규격 미정 ⇒ 그리기로 하면 사용자 확정 필요, 안 그리면 이 문제가 사라짐.
    • 곁가지 — 소단측구는 놓을 자리가 없음. 우리 「2단 비탈」은 소단(berm)이 아니라 2단계 절토 경사(암 경계 위아래 경사 차)임. 소단 기하가 코드에 없음(소단·berm 0건). 소단을 만드는 것은 절토 비탈면 설계를 건드리는 별개 작업임.
    • 권고 범위 — 1단계 「구조물 정본 → 시설별 연장(m)」 함수 하나(반나절) · 2단계 종단·평면에 B군 구간을 띠로 표시(반나절). B08 연결은 재작업 때. 횡단도 그리기는 보류. (③ 을 뒤로 두는 이유가 「버려질까 봐」가 아니라 **「양식에 안 묶이는 조각만 먼저 떼면 되기 때문」**으로 바뀌었음.)
    • 사용자 결정 셋 (2026-09-07)
      • ㉮ 측구(옆도랑) — 목록에 두되 「횡단에서 관리」 표시만. 수량은 안 잡히게 함 (사용자: 「두되 표시만해줘. 다음에 내가 구조물 메뉴 정리할 때 정리할게」).
      • ㉯ 나머지 다섯 — 수량만. 횡단도 그리기는 나중에 검토(사용자: 「일단 수량만」). ⇒ 치수 확정 문제가 이번에는 안 걸림.
      • ㉰ 소단측구 — 소단(berm)부터 만들기(사용자). 아래 3-9 로 절을 냄.
    • ㉮ 구조물 목록의 측구에 「횡단에서 관리」 표시를 붙이고 수량 계통에서 제외 (이중 계상 방지). 끝냄 (2026-09-07, 커밋 7769db36)
      • 레지스트리에 design_owner 를 새로 두고 측구에 「횡단 설계」를 적음. managed_by 는 저장까지 막아 못 씀 — 사용자는 「두되」라 했으므로 배치는 계속 가능해야 함.
      • 표시 자리는 구조물 배치 폼(목록 항목은 「[측점][이름]만」이 2026-08-18 사용자 지시). 문구 — 「횡단 설계에서 관리 — 여기서 넣어도 제원·수량은 그쪽 값을 씁니다.」
      • 실화면 확인 — B06 좌측 폼에서 구조물군 B → 종류 측구(옆도랑) 를 고르면 안내가 254×44px 로 뜸. API 도 design_owner: "횡단 설계" 를 내려 줌. 리셋으로 폼 되돌림.
      • ⚠ @lru_cache 함정에 한 번 걸렸음 — 레지스트리는 프로세스 수명 동안 1회 로드라 JSON 을 고쳐도 서버를 다시 안 띄우면 옛 값이 나감. /api/health 의 stale: true (b8 의 7-2 표시)가 그것을 바로 잡아 줬음 — 첫 실전 사용 사례임.
    • ② B군 수량 1단계 — 「구조물 정본 → 시설별 연장(m)」 함수 하나. 단위가 전부 m 이라 단면 기하 불필요. 소단측구는 빈 칸으로 둠(3-9 뒤에 채움). 끝냄 (2026-09-07, 같은 커밋) — common_util/common_util_structure_lengths.py
      • 빼는 것 셋 — 관 정본 소관(managed_by) · 횡단 소관(design_owner) · 소단측구(PENDING_TYPE_IDS).
      • 겹친 구간은 합쳐서 셈함 — 같은 시설을 겹치게 두 번 넣으면 단순 합이 그 구간을 두 번 셈. 원래 합(raw_length_m)도 함께 내보내 겹침이 숨지 않게 함.
      • 수량서 양식에 안 묶임 — 종류별 연장·개소만 내므로 B08 을 실무 xlsx 로 다시 짜도 그대로 씀.
      • 자체검증 — 새 시험 7건(종류별 합산 / 겹침 제거 80m vs 단순 합 110m / 측구 제외 / 소단측구 제외 / 배관 제외 / 구간 없는 항목은 스키마가 막음 / 빈 프로젝트). 전체 521 passed · 18 skipped.
    • ✏️ 앞 보고 정정 하나 — 「B군은 옵션 항목이 하나도 없다」가 틀렸음(레지스트리 키 이름을 잘못 읽었음). 실제로는 있음 — 측구 형식·깊이 30cm, 산마루측구·절토사면 배수로 재료, 도수로 재료·단면형, 맹암거 규격(자유 입력). 소단측구만 비어 있음. 수량 단가에 필요한 재료·형식은 이미 담기고, 없는 것은 폭·깊이 치수뿐이라 ㉯(수량만) 결론은 그대로 서고 오히려 더 단단해짐.
    • ③ 종단에 B군 구간을 띠로 표시 — 끝(2026-09-07 커밋 76fa78c5). 부품은 새로 안 만들었음 — buildStructureLane 이 이미 모든 군을 받고 있었고(군 필터 없음), 빠져 있던 것은 「구간 띠를 고른 동안만 폈다」는 조건 하나뿐이었음. 그 조건만 걷음. · 구간형이면 늘 띠(고른 것 4px·0.55, 나머지 3px·0.45). 레인 높이 42px 그대로 (2-5b 에서 줄인 것 안 부풀림). · 실측 — 띠 0 → 7개(이 프로젝트 구간형 7건) · 띠 두께 3px · 레인 42px · 알약 18개(그대로). · ⚠ 확대 크롭은 못 잡았음(레인이 가로 5,799px 스크롤 안이라 좌표를 못 맞춤). 수치로는 확인됨.
    • 파다가 나온 것 — B05 가 레지스트리를 「켜진 것만」 받고 있었음(같은 커밋). B군은 레지스트리에서 꺼져 있어(a811286e 는 B06 만 전체를 부르게 했음), B06 에서 넣은 B군이 종단에 이름·색 없이 「?」 회색 알약으로 떴을 자리였음. · 고침 — 레지스트리를 쓰는 자리에 따라 나눔: 추가 메뉴는 켜진 것만(B05 는 종전대로 여섯 군), 알약 레인·군 판정은 전부. 요청 수는 그대로 1건. · 확인 — 타입 응답 36종에 B군 6종 포함. B군 6종은 전부 interval 이라 확인된 C군 7건과 같은 경로를 탐. · ✅ 실제로 넣어 봄 — 끝냄(2026-09-07 사용자 지시, 실화면 · 용화 5601e828). 좌측 [구조물 배치] 에서 B 종단배수 → 산마루측구, 시작 2+0 · 종료 4+0 으로 [추가] → 종단 띠 7 → 8개 → [저장] → 수량 함수가 ditch_ridge · B군 · 1개소 · 40.0m 한 줄을 냄(common_util_structure_lengths). 지우고 저장하니 띠 7개·수량에서 사라짐. ⇒ 넣는 것부터 수량까지 실제로 도는 것이 확인됨. · ⚠ 곁가지로 드러난 위험 — [삭제] 에 확인 절차가 없음. 목록에서 무엇이 골라져 있는지 헷갈린 상태로 누르면 다른 구조물이 조용히 지워짐(2026-09-07 실제로 겪음 — 돌쌓기(찰) 한 건이 지워져 같은 자리·같은 값으로 되살림). 사람이 쓸 때도 같은 사고가 남. 확인 창을 넣을지 사용자 판단 대기.
    • 평면(지도)에 구간형 구조물 띠 — 넣음(2026-09-07 사용자 지시, 커밋 f659aec8).
      • ⚠ 「부품이 없어 새로 짜야 함」은 사실이 아니었음 — 계획선 표본(strengthSamples)이 1m 간격이라 배열 인덱스가 곧 누가거리임(resampleRoute). 구간 → 화면 선은 그 토막을 잘라 굵게 긋기만 하면 됨. 새 파일 하나(88줄)로 끝남(B05_Profile_UI_Drainage_Spans.ts).
      • 그리는 자리 — 계획선 바로 위, 강도 색칠·마커 아래(굵기 7px·투명도 0.45). 색은 레지스트리 표시색 그대로. 이름은 안 적음(종단에 있고, 지도 글자는 눈금·유역 번호와 겹침).
      • 자료는 종단 레인과 같은 것(구조물 정본 + 타입 레지스트리) — routeSpansFromStructures. 구조물을 넣거나 빼면 띠도 따라옴(setStructures·setStructureTypes).
      • 시험 5건 — 부품 존재 · 범위 밖 구간 안전(저장분이 노선보다 길어도 잘라 그림) · 쌓는 순서(계획선 → 띠 → 강도 색칠) · 같은 자료에서 뽑는지 · 목록 변화 추종.
      • 실화면 확인(2026-09-08 00:47, 용화 5601e828 · B05 배수유역도) — 색으로는 계획선과 못 가름(계획선이 #f97316 주황이라 띠 색과 같은 계열임). 그래서 두께로 판정했음: 캔버스 세로 방향 따뜻한색 연속길이 분포 1~3px 216줄(계획선 2.4px) vs 5~8px 70줄 · 9px+ 32줄 — 7px 띠 무리가 뚜렷함. 관 마커는 11개뿐이라 이 수를 못 만듦. ⚠ 한계 — 띠를 끈 대조군을 못 만들어(끄는 스위치가 없음) 분포로만 판정했음.
    • B08 연결은 B08 재작업 때. 지금 프로토 위에 얹지 말 것.
  • F군(녹화·이동통로)은 뒤로 — 단면 기하가 없어 면적이 아니라 수량 항목으로 세는 것이 맞아 보임. B군이 선 뒤에 판단.

이 절의 완료분은 아카이브로 옮겼음 — 2026-09-07_plan_completed_items_2.md · …_3.md(docs/raw/plans/).

3-9. 소단(berm) 신설 — 절토 비탈면에 평평한 턱 넣기 (2026-09-07 사용자 지시)

🔴 사고 기록 — 소단을 놓으면 화면이 멈추던 것 (2026-09-07, 고침 80db17d4)

증상 — 공용 브라우저에서 구조물로 소단을 한 건 놓자 그 순간부터 25분 넘게 계산이 안 끝남. 렌더러가 1.4코어를 계속 태움. 같은 측점을 서버(파이썬)로 돌리면 0.01초에 끝나 서버는 멀쩡해 보였음 — 그래서 「화면만 느리다」로 오진하기 쉬운 자리였음.

원인 — cut_profile_points 의 무릎(암 경계 교차) 가지에서 제자리 뒤집기. 암 경계선의 기울기가 암 경사와 토사 경사 사이에 있으면 · 토사로 바꾸면 다음 걸음이 경계 아래 → 「다시 암」 · 암으로 바꾸면 다음 걸음이 경계 위 → 「다시 토사」 가 되고, 이때 share = -diff_now/span 이 0 이라 knee_dist == dist — 거리가 한 걸음도 안 나감. while dist < limit 이 영원히 안 끝남. multi_knee 가 참일 때만 나는데, 소단이 있으면 항상 참이라 소단이 곧 지뢰였음.

고침 — ① 무릎은 앞으로 나아갈 때만 인정(직전 무릎 자리를 기억, 같은 자리면 안 뒤집고 한 걸음 진행) ② 걸음 상한 40,000(정상 최대 4,000의 10배) + 넘으면 경고 로그 (조용히 자르지 않음) ③ 파이썬·TS 같은 규칙·같은 상수.

왜 종전 값이 안 바뀌나 — 단일 무릎 경로는 첫 뒤집기 뒤 (multi_knee or not in_soil) 가 거짓이 되어 가지 자체가 닫히므로 새 규칙에 닿지 않음. 소단 없는 272개 측점이 값 동일.

시험 — 배분 창의 tmp/tests/test_berm_knee_progress.py 5건(8초 타임아웃 재현·꼭짓점이 뒤로 안 감·소단 없는 경로 불변·짝 규칙 대조·TS 를 node 로 실제 실행). 이쪽 거울 시험 test_cross_berm_mirror.py 에도 그 기하를 케이스 둘로 넣었음(소단 있음/없음) — 12 → 14건.

배운 것 — 「걸어가며 그때그때 경사를 고르는」 루프는 한 걸음도 못 나아가는 상태를 반드시 막아야 함. 되풀이 상한은 마지막 방패이지 첫 방패가 아님.

사용자 지시 — 소단측구를 다루기 전에 소단부터 만들 것.

지금 없음 — 코드에 소단·berm 이 0건. 지금 「2단 비탈」은 소단이 아니라 2단계 절토 경사(암 경계 위아래의 경사 차)임. 평평한 턱이 아니라 경사가 두 번 꺾이는 것뿐임.

닿는 범위가 넓음 — 소단이 서면 횡단 설계선이 바뀌고, 그러면 면적 → 유토곡선 → 수량 → 3D 코리도 → 횡단도·종단도가 전부 따라 움직임. 오늘 고친 계통(사용자 값이 재계산에서 살아남기)도 같이 걸림.

폼 기본값 확정 (2026-09-07) — 폭 0.5m · 간격(사면길이) 3.0m · 기울기 안쪽 2°

• 근거 — 별표2 범위(사면길이 23m 마다 · 폭 50100㎝) 안에서 가장 적게 파는 조합 (폭 하한 + 간격 상한). 기본값은 되돌리기 쉬운 쪽이어야 함 — 더 넣는 것은 폼에서 한 번이지만 이미 판 것을 되돌리면 전 측점 재계산임.

• 소단은 비탈을 완만하게 만듦 — 경사 1:1 절토면 기준 실효 경사:

  폭 · 간격	실효 경사
  0.5m · 3m (확정)	1 : 1.24
  1.0m · 3m	1 : 1.47
  1.0m · 2m	1 : 1.71

  폭 1.0·간격 2 를 기본으로 잡으면 설계 경사 1:1 이 실제로는 1:1.7 로 서서 다른 비탈이 됨.

• 소단측구를 나중에 올리려면 폭이 모자람(측구 너비 0.5~1m) — 그때 사용자가 폼에서 1.0m 로 올리면 됨. 기본값을 미리 1.0 으로 잡아 모든 소단을 넓게 파는 것보다 나음.

• 기울기 2° 는 사용자 확정값. 코드 주석 근거 표기 「2026-09-07 사용자 확정 — 법령·교본 근거 없음」.

성토면 소단 vs 벽 — 「벽이 선 측점은 소단을 안 놓음」 (2026-09-07 확정)

• 성토측에 기슭막이가 서면 성토 설계선을 벽 상단에서 끊고 노견→벽 성토선을 대신 그림 (designTrim). 그 측점의 성토면은 이미 벽이 대신 그리고 있어 소단이 끼어들 사면이 없음. 다단 벽은 단 사이 성토부선이 이미 소단 노릇을 함 — 또 놓으면 단이 두 겹이 됨.
• 판정 단위는 측점 — 구간 전체를 막지 않음. 사용자가 넣은 소단 구간이 벽 있는 측점을 지나가면 그 측점만 건너뛰고 카드에 표시. (구간째 거부하면 배수관 유출 기슭막이가 있는 측점 때문에 못 쓰게 됨 — 시험 프로젝트에서 48곳.)
• 나중에 다시 볼 여지 — 벽이 낮고 그 위 사면이 길면 벽 위쪽에 소단이 필요할 수 있음. 그런 측점이 실제로 나오면 그때 벽 위 구간만 놓는 것으로 넓힐 것.

━━━ ⑦ 사용자 정정 (2026-09-07, 실무자 확인 완료) — 소단·소단측구를 「구조물」로 옮김 ━━━

수량을 어떻게 셀지 물었더니 자리 자체가 바뀌었음. 둘 다 구조물 배치 컨테이너 안으로 들어가므로, 연장은 놓은 구간 길이로 다른 구조물과 같은 길에서 나옴 — 「개수 × 길이」 문제가 사라짐.

사용자 원문

1. 소단

• 소단은 구조물배치 컨테이너의 내부로 이동되어야함.
• 구조물군은 사면안정, 종류는 소단으로 추가
• 기본 양식은 다른 옹벽이나 기슭막이처럼 기준측점 입력 2개, 상세옵션으로 기준측점 전과 후 각 1개 그리고 폭, 간격, 안쪽 기울기를 넣어주면 됨. (안쪽 기울기 기본값 2도 > 0도 변경)

2. 소단 측구

• 구조물 배치 컨테이너의 종단배수에 항목있음.
• 기본 입력 값은 기준측점 입력 2개
• 세부 옵션 기준측점 전, 후 입력, 폭, 안쪽 기울기, 간격이 있을것같음.
• 소단과 거의 동일하나 안쪽 기울기의 경우 사면쪽으로 기울여져야함. (소단과 반대.)

• 소단측구를 「그릴」지는 뒤로 — 사용자 확정 ㉯(「일단 수량만, 그림은 나중에 검토」) 그대로. 지금은 값만 받고 안 그림이라 「사면 쪽 기울기」는 기록만 되고 화면에 안 보임. 그리기로 하면 그때 소단 위에 얹고 부호를 화면에서 확인할 것(시험으로는 안 걸리는 자리).

3-11. 소단이 화면을 멈추던 사고 — 실화면 재확인 (2026-09-08)

80db17d4 로 고친 뒤 같은 조작을 그대로 다시 해 확인함(용화 5601e828 · route 169 · 측점 48+0 에 소단, 폭 0.5·간격 3·기울기 0).

	고치기 전	고친 뒤
소단 추가 → 재계산	25분 넘게 안 끝남(렌더러 1.4코어 계속)	17초에 끝남
그 측점 절토	(못 잼)	9.93 → 6.38㎡ (계단이 서서 값이 바뀜)

· 서버(파이썬)는 그때도 0.01초에 끝났음 — 화면만 물리는 사고라 「그냥 느리다」로 오진하기 쉬운 자리였음(25 가 계획서 3-9 에 그 문장으로 남김). · 시험용 소단은 지웠고 값도 9.93㎡ 로 되돌아왔음. [저장] 안 했으므로 정본은 안 건드림.

3-13. 실화면 검증이 남의 창 수치를 바꾼다 — 통로 셋 (2026-09-08)

하루에 두 번, 데스크탑 창이 「값이 저절로 움직였다」로 추적하다 이쪽 검증이 원인으로 밝혀짐. 탓할 일이 아니라 구조를 몰랐던 것이며, 오늘 처음 실물로 드러남. DB 는 원격 한 대 (dsm.chemifactory.com)를 4환경이 같이 씀.

통로 셋 — 셋째가 제일 안 보였음.

1. [확정]이 전 측점을 다시 계산해 정본에 씀.
2. [저장]도 다시 계산해 씀 — 「저장은 그대로 담는 것」이 아님.
3. ⚠ 그 사이 서버 코드가 바뀜. 같은 자료를 다른 코드로 두 번 계산하면 값이 달라짐. 실측: 앞 기준선(코드 09-07 17:46) ↔ 다음 저장(코드 09-08 00:41) 사이에 성토 −16.8%, 측구터파기가 기계 −19.1 / 브레카 +16.7 로 서로 반대(토사↔암이 옮겨간 모양). 그 사이 들어온 것 — 사면 구간 재료를 그린 경사비로 가름(4e7a4bf7), 성토면 소단 + 옹벽 의무 판정 재정의(db4f17fb·c7770b75).

⇒ 저장된 「정본」은 코드 버전에 매여 있음. 되받기 뒤 아무 창이나 [저장] 한 번이면 수치가 통째로 갱신됨. 대조할 때 자료 시각과 코드 시각을 함께 볼 것(GET /api/health 의 code_mtime).

• 검증용 프로젝트 나눔 — 사용자 승인(2026-09-08). 이쪽 몫은 5601e828(용화 확폭검증, 단면 664·설계 105측점) 그대로 둠. 데스크탑 두 창이 각자 몫(b269ea34·2f940d8a)으로 옮겨 갔으므로 더 옮길 까닭이 없음.
  • 빈 프로젝트(fae94c66·89449bf5·325f57d9)는 단면 0 이라 B06 검증에 쓰려면 자동설계 체인을 처음부터 돌려야 함(90초+ · 원자료 필요). 이득 없이 비용만 큼.
  • ⚠ 사용자 활성 5cff3920 은 아무도 손대지 말 것.
  • 추적 칸(updated_at·updated_by)은 안 넣기로 사용자 확정 — 프로젝트를 나눴으므로 「누가 언제 바꿨나」를 물을 일이 없어짐. 마이그레이션 020~ 계획 취소.
  • [확정]·[저장]·노선 [확인] 전에 알리기(장부 규칙 6)는 그대로 유효함 — 추적 칸이 없어진 지금은 그 통보가 유일한 안전장치임.
• 찌꺼기 확인 끝 — route 169 정본에 소단 0건, 절토각 사용자값은 측점 0.0·20.0 에 0 뿐. ⚠ 그 **0 은 「표준값을 씀」**이라는 되돌림 표식임(0도로 깎는다는 뜻이 아님).