Aislo/docs/raw/plans/2026-09-04_plan_snapshot_before_cleanup.md

상시 계획서 — 2026-09-04 정리 전 원문 스냅샷

운영 원칙

• 진행 중: 현재 구현·검증 대상으로 선택된 작업만 둔다.
• 진행 예정: 아직 착수하지 않은 작업을 기능군별로 둔다.
• 참고: 코드 작업 중 필요한 기준표·확정사항만 둔다.
• 완료 항목은 사용자 검증 또는 교차검증 후 docs/raw/plans/와 docs/raw/verification/으로 이관한다.
• 담당은 적지 않는다 — 어느 창·폴더가 맡을지는 그때그때 정한다.
• 작성방법 — 짧고 이해하기 쉽게, 문단의 종료 시점 전까지 줄바꿈금지.

---

진행 중

2026-09-04 현재 — 미완료 체크 11건. 완료 구현과 자체검증 기록은 docs/raw/plans/로 이관했다(이번 이관: 2026-09-04_plan_user_verified_completed_items.md). 이 문서에는 진행 중·진행 예정·판단 대기 항목만 유지한다.

B05↔B06 이동 지연 — 원인 확정과 개선 (2026-09-04 조사 · 2026-09-05 작업 예정)

사용자 지시(2026-09-04) — 「B05·B06을 세션·캐시로 한 페이지처럼 만들어 빠르게 하려 했는데 생각보다 느림. 원인을 파악할 것」. 조사만 끝냈고 구현은 하지 않음(내일 작업).

1. 실측 (공용 브라우저 5174 · 프로젝트 용화_LAS · 2026-09-04)

이동	화면 틀	서버 요청	마지막 응답	메인스레드 멈춤
B05 → B06	0.61초	11건	0.93초	합 1.02초 (최대 0.28초)
B06 → B05	즉시	21건	4.87초	합 2.62초 (최대 0.89초)

느린 쪽은 B05 재진입 한 방향뿐임. 개별 요청은 60~500ms 로 느리지 않고, 줄을 서느라 4.9초가 됨.

B06→B05 요청 순서 실측(시작ms +소요ms):

   13 +484  surface/status          ← 이동 문지기
  498 +366  surface/confirmed       ← 이동 문지기
  927 +67/134/104/71  auth/session ×4
 1141 +61   vworld-meta
 1144 +113  workflow-state (24KB)
 1303 +101  workflow-state (24KB, 중복)
 1305 +161  route/latest (67KB)
 1305 +116  sections/context
 1305 + 59  sections/road-widths
 1469 +153  surface/models
 1485 + 62  geojson(도엽_하천) 304
 1582 + 67  geojson(도엽_등고선) 304
 2173 +386  drainage/pipe-points (139KB)
 2317 + 93  route/structures/migrate
 2318 + 87  route/structures
 2594 +167  surface/confirmed (중복)
 2928 + 76  surface/models/418/preview 304
 4112 +759  surface/models/418/contour 304

2. 원인 4가지 (코드 위치 포함)

• (가) 요청이 줄줄이 앞을 기다림 — 가장 큰 몫 ① 이동 문지기 A00_Common/b_workflow_nav.ts routeAfterPreloadCheck 가 화면을 띄우기 전에 surface/status → surface/confirmed 를 차례로 물어 0.9초를 먼저 씀. ② B05 진입 B05_Profile/B05_Profile_UI_Page.ts:599~ 이 워크플로우 상태 → Promise.all(노선·설정·도로폭) → 지표면 목록 → 종·횡단 → 구조물 순으로 다섯 덩이를 차례로 기다림. 이 중 워크플로우 상태·지표면 목록·구조물은 서로 필요 없음(참 의존은 「노선 → 종·횡단」뿐).
• (나) 같은 것을 여러 번 물어봄 — 로그인 확인 4번(A00_Common/router.ts 문지기 2번 + A00_Common/app_shell.ts 상단바 2번, 게다가 상단바는 두 번을 차례로 부름), 워크플로우 상태 2번(24KB×2 — 두 번째 호출자는 내일 확정), 확정 지표면 2번(문지기 + B05 3D 단계), 구조물 목록 2번(migrate 포함).
• (다) 세션 캐시가 큰 자료를 담지 않음 — 담아 두는 것은 준비 표식(frd_preloaded_signature)·계획선 초안·노선 latest 정도임. 노선 최신값은 진입 때 일부러 DB를 다시 읽고(loadLatest(true)), 배수관(139KB)·구조물·지표면 목록은 매번 새로 받음. B06에서 방금 쓰고 온 자료도 다시 받음.
• (라) 받은 뒤 그리느라 2.6초 멈춤 — 3D 메쉬와 등고선 12.7MB(contour_csf_dtm_smooth_1.0m.json)를 다시 읽어 그림. 서버는 304(본문 0바이트)만 주지만 브라우저가 그 12.7MB를 다시 해석함. 이 멈춤이 뒤따르는 요청까지 밀어냄(마지막 contour 요청이 759ms로 잡힌 것도 이 영향).

3. 내일 작업 (효과 큰 순서, 앞에서부터)

• (1) 중복 호출 제거 — 로그인 확인 4 → 1, 워크플로우 상태 2 → 1, 확정 지표면 2 → 1, 구조물 2 → 1. 화면 한 번 그리는 동안 같은 요청은 한 번만 나가게 공용 캐시를 둠(같은 URL 진행 중이면 그 약속을 함께 씀). 먼저 두 번째 워크플로우 상태 호출자를 확정할 것. 기대: 요청 21 → 15건, 앞머리 0.3~0.6초 단축.
• (2) B05 진입을 병렬로 — 워크플로우 상태·노선·설정·도로폭·지표면 목록·구조물을 한 번에 보내고, 「노선 → 종·횡단」 의존만 남김. 화면 틀은 워크플로우 상태가 오는 대로 세움. 기대: 1.4초 → 0.5초 안팎.
• (3) 이동 문지기를 화면과 겹치게 — routeAfterPreloadCheck 의 surface/status·surface/confirmed 확인을 이동을 막지 않게 바꿈(먼저 넘어가고 뒤에서 확인, 다르면 그때 준비 화면으로). 기대: 앞머리 0.9초 제거.
• (4) 화면을 오가도 자료를 들고 있기 — B05·B06이 함께 쓰는 자료(노선 latest·배수관·구조물·지표면 목록)를 프로젝트+갱신표식 기준 메모리 캐시에 두고, 저장·확정으로 값이 바뀔 때만 버림. 「진입 때 무조건 DB 재조회」는 그 표식 비교로 대체. 기대: 재진입 요청 15 → 6건 안팎.
• (5) 등고선·3D 다시 그리지 않기 — 한 번 해석한 등고선·메쉬를 화면을 나갈 때 버리지 말고 들고 있다가 되돌아오면 그대로 얹음. 기대: 메인스레드 멈춤 2.6초 → 1초 미만.
• (6) 자체검증 — 아래 「측정 방법」으로 전·후 수치를 재고 PLAN 에 남김. 목표: B06→B05 마지막 응답 1.5초 이하, 요청 10건 이하, 메인스레드 멈춤 1초 이하.

4. 측정 방법 (전·후 비교에 그대로 씀)

공용 브라우저 명령 파일(tmp/browser/cmd/NN_*.py)에서:

1. B05 에 들어가 안정된 뒤 performance.clearResourceTimings() + PerformanceObserver({entryTypes:['longtask']}) 를 걺.
2. 진행단계의 「횡단설계」/「종단설계」를 눌러 이동.
3. performance.getEntriesByType('resource') 에서 /api/ 만 골라 시작·소요·전송크기를, 롱태스크에서 멈춤 합·최대를 뽑음.
4. 위 표와 같은 형식으로 기록. 이번 측정값이 기준선임.

5. 앞으로 이런 문제를 만들지 않기 위한 규칙 (사용자 지시 2026-09-04)

새 화면·기능을 붙일 때마다 같은 지연이 다시 쌓임. 아래를 개발 중 지킬 규칙으로 삼음.

• ① 진입은 「틀 먼저, 자료는 한꺼번에」 — 화면 진입 코드에서 await 를 세로로 쌓지 말 것. 서로 값을 쓰지 않는 요청은 Promise.all 로 묶고, 진짜 의존(앞 응답의 id 를 쓰는 경우)만 줄을 세움. 새 자료가 필요해지면 기존 묶음에 넣는 것이 기본이고, 새 단계를 만드는 것은 예외임.
• ② 같은 요청은 화면당 한 번 — 로그인·워크플로우 상태처럼 여러 곳이 쓰는 값은 공용 캐시를 거쳐 받음. 모듈마다 자기 몫을 따로 부르지 말 것.
• ③ 화면 이동을 막는 요청을 새로 만들지 말 것 — 이동 전에 확인이 필요하면 먼저 넘어가고 뒤에서 확인해 어긋날 때만 되돌림.
• ④ 화면을 나갈 때 비싼 것을 버리지 말 것 — 3D 메쉬·등고선처럼 해석에 수백 ms 드는 자료는 프로젝트가 바뀔 때만 버림.
• ⑤ 무엇이 바뀌었을 때 버릴지 먼저 정할 것 — 캐시를 둘 때는 「무엇을 담나」보다 **「언제 버리나」**를 먼저 적음(저장·확정·재계산·프로젝트 변경). 이 규칙이 없으면 옛 값이 남아 더 큰 문제가 됨.
• ⑥ 화면마다 성능 한도를 둠 — 진입 시 API 10건 이하 · 대기 사슬 3단계 이하 · 메인스레드 멈춤 1초 이하 · 한 응답 100KB 이하. 넘기면 그 자리에서 줄이거나, 못 줄이면 PLAN 에 사유와 함께 남김.
• ⑦ 화면 작업을 끝낼 때 진입 수치를 한 번 잼 — 위 「측정 방법」을 그대로 돌려 요청 수·마지막 응답·멈춤을 검증 기록에 적음. 눈으로 「빠른 것 같다」는 판정 금지.
• ⑧ 응답 크기도 봄 — 목록 응답이 수십 KB 로 커지면 화면이 실제로 쓰는 필드만 내려보내게 서버를 고침(지금 워크플로우 상태 24KB·배수관 139KB 가 그 후보).

B03 계획노선 미리보기 색·점선 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — 「계획노선 도형이 왜 붉은색인가. 점선 없애고 실선은 녹색으로」.

• 붉은색은 경고였음 — 노선이 지형 자료 범위를 벗어나면 선과 상자를 붉게 칠함. 그때 지형이 검증용 가짜 라이다라 범위가 어긋나 있었음. 실제 라이다를 올리니 경고가 풀림.

• 점선 상자는 「자료가 덮는 땅 범위」 — 노선은 선 자체가 범위를 보여 주므로 상자가 겹침.

• 노선 카드의 점선 상자 제거 — 그릴 선이 있는 자료(계획노선)에는 범위 상자를 그리지 않음. 점구름·래스터는 그대로.

• 노선 실선 녹색 — 선 색을 녹색으로. 범위를 벗어나면 붉은 경고색으로 덮어쓰는 규칙은 그대로 둠.

• 자체검증(2026-09-04, 검증 대기) — 공용 브라우저 5174, 프로젝트 카드미리보기_검증_sub. 실측: 노선 미리보기의 범위 상자 없음, 선 색 rgb(63,187,111)(녹색), 경고 표시 없음(실제 라이다 기준 범위 안). npm run typecheck 통과.

  • 계획 대비 차이 — 없음.

B03 파일 교체 후 다시 돌리기 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — 「검증용 프로젝트를 지우지 말고 그걸로 전처리 시험을 하려 함. 파일 교체해서 [파일 업로드] 버튼으로 실행할 수 있게 할 것」.

막고 있던 것 두 가지를 찾음.

• 끝난 카드에 [파일 선택]이 없었음 — CSS 가 완료 카드의 선택 단추를 감추고 있어 파일을 갈아 끼울 방법이 없었음. 규칙 자체는 이미 교체를 허용함(필수 칸은 서버에 올라간 파일로 충족).

• 한 번 「자동 확정 보류」가 나면 그 프로젝트는 영영 새 자료를 못 받았음 — 전처리 1단계가 IN_PROGRESS 로 남고 서버 업로드 관문이 그것을 「분석 중」으로 읽음. 보류는 계산이 끝나고 사용자의 확정을 기다리는 상태라 분석 중이 아님. 검증용 프로젝트만의 문제가 아니라 실사용에서도 같은 자리에서 막힘.

• 끝난 카드에도 [파일 선택] — 올리는 중에만 감추게 바꿈. 누르면 기존대로 「기존 파일 교체 확인」 모달이 뜨고, [교체하고 계속] 뒤 [파일 업로드]가 열림.

• 「확정 대기」는 업로드를 막지 않음 — 업로드 관문이 1단계 상태만 보던 것을 고쳐, 전처리 진행 파일이 awaiting_confirmation·completed·failed 로 끝나 있으면 새 자료를 받음. 실제로 도는 중(analyzing)이면 그대로 막음.

• 자체검증(2026-09-04, 검증 대기) — 공용 브라우저 5174, 프로젝트 카드미리보기_검증_sub. 백엔드 재시작 후 실측.

  • ① 끝난 카드 9개 전부 [파일 선택] 보임(display: block). 합격
  • ② 포인트클라우드를 다른 파일로 교체 → 교체 확인 모달 → [파일 업로드] 활성. 고치기 전에는 서버가 409 「이 프로젝트는 지금 분석 중입니다」로 거절했음. 합격
  • ③ 업로드 뒤 카드가 「완료 / verify_mini2.las 1.14 MB」로 바뀌고, 전처리가 새 파일로 다시 돎 — 입력 파일 22:40:33 저장, B04 산출물 structured.npz 22:40:35 재생성. 합격
  • ④ 회귀 — pytest tmp/tests/ 185 통과·1 건너뜀, npm run typecheck 통과.
  • 남은 것 — 이 프로젝트는 가짜 라이다라 자동 확정이 계속 보류됨(「기본값과 일치하는 지표면 모델 없음: filter=csf, method=dtm」). 전처리 시험은 B04 에서 모델을 직접 골라 확정하면 됨.
  • 계획 대비 차이 — 없음. 계획에 없던 서버 관문 수정이 붙음(그것이 진짜 원인이었음).

B03 파일입력 카드 — 부속 파일 값 표시 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — 「지금 그림은 3개(노선·점구름·래스터)뿐이고 나머지는 글자임. shx·dbf·cpg·prj 파일 내용 중 중요한 정보를 몇 개 뽑아 넣을 것」 + 「지형 래스터는 왜 다른 그림처럼 점선 박스에 안 들어가 있나」.

• 개수만 보이던 것이 문제 — 「도형 1개」·「레코드 1개」로는 그 파일에 무엇이 들었는지 안 보임.

• 재료는 파일 머리글에 이미 있음 — 머리글만 읽으므로 업로드가 느려지지 않음(사용자 제약 「오래 걸리면 안 됨」). .cpg 견본만 같은 세트 .dbf 앞부분을 함께 읽음.

• 래스터에 점선이 없던 이유 — 다른 미리보기는 「자료가 덮는 땅 범위」를 점선 사각형으로 그리는데, 래스터는 그 범위를 썸네일이 그대로 채워 그리는 코드가 썸네일에서 끝났음.

• .shx — 도형 종류·범위 — 머리글에서 도형 종류 코드와 bbox 를 읽어 「폴리라인 · 도형 1개 / 범위 1,234×435 m」로 보임.

• .dbf — 속성 이름 — 머리글 서술자에서 속성 이름을 읽어 앞 4개를 보임(넘으면 …).

• .cpg — 글자 견본 — 같은 세트 .dbf 의 첫 글자 속성을 그 인코딩으로 읽어 「견본 「…」」으로 보임. 인코딩이 틀리면 글자가 깨져 눈에 바로 보임.

• .prj — 원점·단위 — 투영 매개변수에서 중앙자오선을, 축 정보에서 길이 단위를 읽음. proj 문자열 변환을 쓰지 않아 정보 손실 경고가 사라짐.

• 표시 줄 수·단위 표기 — 카드 값을 2줄 → 3줄로 늘리고 길이 단위는 metre·METER 를 모두 m 으로 통일.

• 래스터 썸네일 점선 테두리 — 썸네일에 다른 미리보기와 같은 점선 테두리를 둘러 셋이 같은 모양이 되게 함.

• 자체검증(2026-09-04, 검증 대기) — 기존 프로젝트를 건드리지 않으려고 **새 프로젝트 「카드미리보기_검증_sub」**를 만들어 실제 업로드 경로로 확인함(공용 브라우저 5174). 백엔드는 재시작 후 확인.

  • ① 업로드 후 카드 실측 — .shx 「폴리라인 · 도형 1개 / 범위 1,234×435 m」, .dbf 「레코드 1개 · 속성 2개 / 대상지, 길이」, .cpg 「인코딩 949 / 견본 「일월.용화.2.2」」, .prj 「Korean 1985 / Modified East Belt (EPSG:5176) / 중앙자오선 129.0029°E · 단위 m」. 합격
  • ② 단위 표기 — 노선 .prj 는 사용자 정의 WKT 라 METER 로 나오던 것을 고쳐 두 카드 모두 「단위 m」으로 나옴. 합격
  • ③ 래스터 썸네일 — 용화_LAS 의 지형 래스터 카드에서 테두리 실측 dashed · 1px · rgb(50,42,69) — 다른 미리보기 점선과 같은 색. 합격
  • ④ 회귀 — pytest tmp/tests/ 185 통과·1 건너뜀, npm run typecheck 통과.
  • 뒷정리 필요 — 검증용 프로젝트 「카드미리보기_검증_sub」가 대시보드에 남아 있음(자동설계는 돌지 않음). 필요 없으면 지울 것.
  • 계획 대비 차이 — 없음.

B07 화면 손질 5건 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — ① 횡단면도 배치에서 박스와 박스 사이 간격 제거 ② 마지막 1장으로 구성된 횡단면도에 도각 없음 ③ 도면 위 마우스 스크롤을 줌인아웃으로(도면 영역 안에서만) ④ CAD 리본 메뉴의 세로 스크롤 안 나오게 ⑤ 좌측 패널 하위 버튼이 이름이 길어 우측으로 튀어나감 — 누가거리 대신 그 장의 시작 측점으로 표기, 넘치면 ….

착수 전 공용 브라우저(5174, 시행정 테스트)와 코드로 확인한 현황임.

• ②·③ 은 확인 결과 손댈 것 없음 — 사용자 확정(2026-09-04) 「도각 / 마우스 휠 괜찮음」. ② 도각은 4개 프로젝트의 마지막 장·단면 1개짜리 장까지 전부 A1 도각이 들어 있음(도면 범위 840×594mm = A1 실치수, 내용만이면 739×499mm 이내). ③ 캔버스 위 휠은 이미 확대/축소이고 페이지 스크롤이 아님 — 사용자가 겪은 상하 팬은 트랙패드 두 손가락 이동이 설계상 팬으로 잡히는 것임(isMouseWheel) — 그대로 두기로 확정.

• ① 간격은 상수 하나가 정함 — 장 배치가 칸 크기를 「블록 + 간격 8mm」로 잡고 테두리를 그 칸 안쪽에 그림(_BLOCK_GAP_MM).

• ④ 리본이 4px 모자람 — 실측: 리본 줄의 내용 높이 85px, 보이는 높이 81px. 리본 칸 높이가 116px 로 고정돼 있어 4px 이 남고, 한 축만 잘리면 브라우저가 나머지 축도 스크롤로 바꿔 세로 스크롤바가 생김. 잘라 숨기지 않고 리본 높이를 조금 늘려 없앰(사용자 지시 2026-09-04). 높이는 토큰 한 곳(--cad-ribbon-height)이 정하고 캔버스 위치·높이가 그 값을 따라감.

• ⑤ 튀어나감은 실측으로 재현 — 2열 격자의 오른쪽 열 단추가 패널 오른쪽 끝(303px)을 14px 넘어 317px 까지 나감. 격자 칸의 기본 최소폭이 글자 길이라 칸이 컨테이너를 밀어냄. 라벨도 「16장 (1060~1070m)」처럼 누가거리 범위라 긺.

• ① 박스 사이 간격 없애기 — 칸 여백 상수를 0 으로 두어 테두리끼리 맞닿게 함(_BLOCK_GAP_MM). 척도(1/100)·칸 통일 규칙은 그대로.

• ④ 리본 높이 늘리기 — 리본 칸 높이를 116px → 122px 로 올려 세로 스크롤바가 안 생기게 함(모자란 4px + 여유 2px). 가로 스크롤은 그대로 둠.

• ⑤ 라벨을 시작 측점으로 — 「N장 (시작~끝m)」 → 「N장 (No.n)」. 측점 표기는 납품 도면과 같은 규칙(station_no_label)을 씀.

• ⑤ 단추가 패널을 넘지 않게 — 격자 칸의 최소폭을 풀어(min-width: 0) 이름이 길면 … 로 잘리게 함.

• 자체검증(2026-09-04, 검증 대기) — 공용 브라우저(5174, 프로젝트 용화_LAS) + 생성 도면 실측. CAD 앱은 다시 빌드하고 캐시를 비운 뒤, 백엔드는 재시작하고 확인함.

  • ① 한 장(9칸, 칸 168.0×164.43mm)의 칸 테두리 9개를 재니 가로·세로 이웃 간격 모두 0.0mm(옛 8mm). 테두리 크기 = 칸 크기와 같음. 화면에서도 이웃 박스가 세로선 한 줄을 함께 씀. 합격
  • ④ 리본 줄의 내용 높이 87px = 보이는 높이 87px(옛 85 > 81) — 세로 스크롤 가능 높이 0. 리본 칸 122px, 캔버스 상단이 158 → 164px 로 내려감. 합격
  • ⑤ 단추 33개 중 패널 오른쪽 끝(303px)을 넘는 것 0개(옛 8개가 317px 까지 나감), 횡단 격자의 내용 폭 277px ≤ 칸 폭 279px. 라벨은 「1장 (No.0)」…「20장 (No.53+10.4)」 형식이고, 가장 긴 「20장 (No.53+10.4)」만 … 로 잘림. 합격
  • ⑥ 회귀 — pytest tmp/tests/ 185 통과·1 건너뜀(다른 창 커밋 2건을 되받은 뒤 실행).
  • 계획 대비 차이 — 없음.

B05 종단·유토곡선 조작감 3건 (2026-09-04 지시)

사용자 지시 3건 — ① 휠 스크롤이 늦게 따라옴, 리소스가 크지 않으면 부드럽게 ② 유토곡선 「다시 계산 중」 문구가 창을 밀어냄 — 그래프 안 우측 상단 오버레이로 ③ 코리도 초기값 — 지금 로딩이 늦음.

착수 전 측정 (공용 브라우저 5173, 실측)

• 휠 이동 자체는 즉시. 마지막 휠 508ms → 그래프 재구성 706ms — 멈춘 뒤 약 0.2초에 세로 눈금·곡선이 다시 섬(디바운스 160ms + 재구성). 재구성은 longtask 0건(50ms 미만)이라 가벼움.

• 이동이 한 칸 120px 점프라 부드럽지 않음 — scrollLeft += deltaY 직접 대입이 브라우저 기본 휠 관성을 대신함.

• 같은 휠 처리가 종단(B05_Profile_UI_Profile_Panel.ts)·유토곡선(_MassHaul.ts)· 테이블(_TableOverlay.ts) 세 곳에 복사돼 있음.

• 「다시 계산 중…」 칩이 요약 막대(flex-wrap: wrap)에 붙어 줄바꿈 → 막대가 높아지며 곡선이 밀림.

• 코리도 저장본 17.6MB, 전송만 328ms(압축 없음) + 파싱. [초기화]는 새 route id를 만들어 (restore_initial_snapshot) 저장본 파일명이 어긋남 → 초기화 뒤 첫 진입은 항상 재빌드.

• 휠 가로 이동 부드럽게 — 세 곳의 휠 처리를 B05_Profile_UI_Profile_Wheel.ts 한 벌로 모음. 이동은 rAF 로 목표를 쌓아 프레임마다 좁히는 방식.

  • 계획 대비 차이 — 브라우저 기본 scrollTo({ behavior: "smooth" }) 로 갔다가 되돌림. 휠이 들어올 때마다 애니메이션이 처음부터 다시 시작해 느린 구간만 반복함: 실측 1.6초 동안 1,200px 중 17px만 이동. 자체 애니메이션으로 교체함.

• 따라오는 시간 단축 — 세로 자동 맞춤 디바운스 160 → 80ms. 「멈춘 뒤 한 번」 규칙 유지.

• 「다시 계산 중」 오버레이화 — 칩을 요약 막대에서 떼어 곡선 영역 우측 상단에 절대배치(범례 아래 4px, pointer-events: none). 레이아웃 차지 0.

• 자체검증 (2026-09-04, 검증 대기) — 방법: npm run typecheck 통과, 공용 브라우저 5173 임시 탭에서 실제 휠 조작·수치 판독(사용자가 쓰던 B07 탭은 건드리지 않음). 결과: ① 휠 10칸(1,200px) 중 1,199px 이동, 궤적이 40ms 간격으로 연속(점프 없음), 마지막 휠 500ms → 그래프 재구성 813ms ② 칩 표시/숨김에서 요약 막대 높이 53px·곡선 자리 (top 1078 · height 226) 완전 동일 — 창밀림 0, 칩은 곡선 영역 안 우측(범례와 겹치지 않음). 계획 대비 차이 — 재구성 시점이 고침 전 706ms → 813ms 로 약 0.1초 늦어짐(이동 애니메이션 시간만큼). 이동 자체가 이어져 보이므로 그대로 둠. 커밋 c2f681f9.

• 코리도를 서버가 미리 만들어 저장 (2026-09-04 사용자 확정 — 「같은 TS 코드를 서버에서 1회 실행」). 다른 데이터와 같은 흐름으로 맞춤: 전처리 체인 마지막에 계산·영구저장 → 진입 시 로딩만 → 조작은 캐시 → [저장]·[확정] 때 저장. 계산 재구현 없음 — 브라우저 빌더 8,209줄을 그대로 씀.

  • 저장 형식 공용화 — B05_Profile_UI_Corridor_Envelope.ts 신설. 버전 해시·직렬화를 _UI_Corridor.ts 에서 내용 그대로 떼어 브라우저·서버가 한 벌을 씀.
  • 서버 진입점 + 번들 — B05_Profile_Corridor_Node.ts(47줄) → npm run build:corridor 로 335kB 번들. npm run build 에 물림. 번들 산출물은 git 제외(.gitignore).
  • 낡은 번들 방지 — B05_Profile_Corridor_Prebuild.py 가 번들과 TS 원본 시각을 대조해 낡았으면 스스로 다시 만듦. 계획서가 「유일한 위험」으로 적었던 항목을 코드로 막음.
  • 체인 마지막 단계 — 스냅샷 직전에 호출. 실패는 비치명적(브라우저 폴백 유지).
  • 초기값 편입 — 스냅샷이 코리도를 initial_corridor.json 으로 함께 뜨고, [초기화] 복원 때 새 route id 이름으로 되돌림.
  • 프론트는 무변경 — 저장본 해시가 맞으면 ensureCorridor 가 그대로 로드함. 확인용 디버그 훅 window.__corridorSource 만 추가.
  • 자체검증 (2026-09-04, 검증 대기) — 방법: 전체 시험 + 실제 프로젝트 실행 + 공용 브라우저 임시 탭 판독. 결과: ① 전체 시험 381 통과 · 17 건너뜀 ② 용화 프로젝트 (route 139)로 서버 사전 생성 성공(16MB) ③ 그 저장본을 브라우저가 source: "stored", 해시 377c2a84 로 그대로 채택 — 재빌드 0회, 전송 278ms ④ 스냅샷 복원 3건 (tmp/tests/test_b05_corridor_prebuild.py) 통과. 계획 대비 차이 — 착수 전 확인 항목이던 「체인 시점 기본설계·구조물 정본」은 상세 조회 (get_section_detail)를 그대로 부르므로 따로 손댈 것이 없었음. 옛 테스트 2건은 이름·경로 변경에 맞춰 갱신(_corridor_path → corridor_path, 배수유역 스냅샷 자리). 미검증 — 새 프로젝트 업로드로 체인이 처음부터 도는 실경로와 [초기화] 뒤 복원은 아직 못 돌림(둘 다 사용자 프로젝트를 갈아엎는 조작이라 지시 필요). 커밋 c322f538.

• 코리도 응답 압축(일단 동의로 종료처리) — 백로그 (2026-09-04 사용자 판단). 압축은 전송량만 줄고 회전·이동 같은 조작 속도와는 무관함(그건 GPU·메쉬 몫). 18MB 는 견딜 만하므로 미룸.

B05 종단 세로 맞춤 — 다시 그리기에서 변환으로 (2026-09-04 지시)

사용자 지시 — 「지금은 화면을 리프레시하는 느낌. 가장 강한 지연은 멈춘 뒤 끊김. 실시간처럼 동작하려면 근본적으로 표현을 바꿔야 하지 않나」. 확정: 변환 방식.

착수 전 측정 — 스크롤을 멈추면 그래프를 통째로 새로 만듦. SVG 요소 457개 (선 311·글자 76)를 버리고 다시 그려 한 번에 34ms(60Hz 두 프레임 통째 누락). 스크롤 중 프레임 자체는 중앙값 16.6ms(60fps)라 그리기 성능 문제가 아님 — 세로 위치가 선 하나하나의 좌표에 박혀 있어, 세로 창이 바뀌면 좌표를 전부 다시 만들 수밖에 없는 구조임.

방식 — 세로 창을 좌표가 아니라 한 줄 변환(translate+scale)으로 표현. 창이 바뀌어도 좌표 재계산 없이 변환값만 갈아 끼움. 두 창의 대응은 1차식이라 정확히 겹침 (a = 기존폭/새폭, b는 중심 이동분). 스크롤하는 내내 매 프레임 적용해도 1ms 미만.

• 그래프 구조 손질(B06_Section_UI_Longitudinal.ts) — 세로에 딸린 것(눈금선· 절성토 음영·지반선·계획선)을 b06-chart__ywindow 한 겹으로 묶음. 자를 영역은 변환 밖, 글자도 변환 밖에서 자리만 옮김. 선 굵기는 vector-effect: non-scaling-stroke (변환이 걸렸을 때만 적용해 B06 은 예전 그대로).

• 기준값 각인 — 그릴 때 쓴 창(중심·표고1m당 px·기준 y·플롯 상단·높이)을 SVG 속성으로 남김. 그리는 함수의 인자를 늘리지 않음.

• 적용 모듈 신설 — common_util_chart_ywindow.ts(B05·B06 공용으로 옮김). 변환 계산 + 눈금 글자· 좌측 고정 축 이동. 배율이 0.8~1.25 밖으로 나가면 눈금층만 다시 만듦(요소 20개 안팎).

• 눈금 계산 공용화 — yWindowTickValues 로 빼 그리는 쪽과 갱신 쪽이 같은 눈금을 씀.

• 스크롤 연결(_UI_Profile_Panel.ts) — 스크롤마다 변환 갱신만. 전체 재구성은 눈금 갱신으로도 못 살릴 때만 남김.

• B06 영향 없음 확인 — 변환 겹 3개 모두 변환값 없음(항등).

• 자체검증 (2026-09-04, 검증 대기) — 방법: 공용 브라우저 임시 탭에서 휠 20칸 (4,800px) 실제 조작 후 수치 판독(사용자가 쓰던 탭은 건드리지 않음). 결과: ① 그래프 전체 재구성 0회(고침 전 다회) ② 최대 프레임 59.9 → 20.0ms, 20ms 초과 0건 ③ 눈금 글자와 눈금선 어긋남 6.4 → 0.5px ④ 지반선의 한 점을 변환이 놓은 자리와 눈금이 말하는 자리가 0.000px 일치(배율 2.715 상태) ⑤ B06 종단 화면 불변 ⑥ 전체 시험 381 통과 · 17 건너뜀. 계획 대비 차이 — 「눈금 값이 낡으면 눈금층만 다시 만든다」를 계획대로 넣되, 글자 내림 4px 을 변환 뒤에 더해야 함을 실측으로 발견해 고침(그전에는 배율만큼 벌어짐). 커밋 8dca4bbf.

• 유토곡선·B06 페이지 확대 적용 (2026-09-04 사용자 지적 — 「유토곡선도 반영해야지. B06 페이지도 있잖아. 같은 로직일 텐데 왜 반영이 안 된 거야」).

  • 원인 — 그리는 쪽(종단 렌더러)은 공용이라 이미 바뀌어 있었고, 스크롤을 받아 창을 옮기는 쪽이 화면마다 따로 있어 B05 만 연결돼 있었음.

  • 세로 창 모듈을 common_util_chart_ywindow.ts 로 옮겨 B05·B06 공용. 좌측 고정 축은 표식이 붙은 것만 옮김(B06 은 한 컨테이너에 종단·유토곡선 축이 함께 삶).

  • 세로 과장(B06 조절값)을 각인·반영 — 예전에는 과장 1일 때만 대상이었음.

  • 유토곡선은 변환이 아니라 곡선만 다시 그림. 곡선 위 말풍선·EP 표·측점 점이 세로로 늘어나면 안 되는 것이라, 그것만 따로 옮기는 값이 다시 그리는 값보다 큼 (유토 SVG 234개 = 종단의 1/3).

  • B06 상단 패널 통째 재구성 제거 — 종단은 변환, 유토곡선은 제자리 교체.

  • 700줄 정리 — 종단 조립을 _View_Chart.ts(116줄), 유토곡선 조립기를 _View_MassHaul.ts 로 분리(_Section_View.ts 727 → 718줄).

  • 자체검증 (2026-09-04, 검증 대기) — ① B05 유토곡선 눈금이 스크롤을 따라 4.3㎥ → −1,348.8㎥ 이동(예전에는 안 따라옴) ② B06 종단 830/840/850m → 824/826/828m, 유토곡선 68.2㎥ → −3,375.1㎥ 동시 이동 ③ B06 최대 프레임 35.9 → 23.5ms, 33ms 초과 1 → 0건 ④ B05 최대 프레임 27.4ms, 33ms 초과 0건 ⑤ 전체 시험 381 통과. 커밋 685d44ac.

• 유토곡선 세로창이 확 튀는 것 (2026-09-04 사용자 보고·확정 「버티기 + 부드럽게」).

  • 원인 측정 — 한 칸마다 세로 폭 240·234·228 → 1,019㎥(4.5배). 누가토량 곡선이 표고와 달리 가팔라, 급한 구간이 창에 들어오면 배율이 한 번에 몇 배로 바뀜. 종단은 같은 방식인데 폭이 20m로 계속 같음 — 방식이 아니라 데이터가 가파른 것이 원인.

  • 버티기 — 곡선이 지금 창 안에 들고 55% 넘게 채우면 창을 안 건드림.

  • 부드럽게 — 바꿀 때도 남은 만큼 20%씩 좁혀 약 0.15초에 걸쳐 미끄러짐.

  • 여유 5% → 20%(종단과 같은 값) — 곡선이 위아래 끝에 딱 붙지 않음.

  • 곡선 계산을 입력 객체 단위로 아낌 — 스크롤 중 다시 계산해 프레임을 먹던 것.

  • 자체검증 — ① 8칸 중 4칸은 폭 변화 0(버티기) ② 바뀌는 순간 궤적 257 → 711(42ms) → 882(80ms) → 1,030(151ms) — 계단이 아니라 미끄러짐 ③ 휠 20칸 기준 최대 프레임 27.4 → 24.0ms, 33ms 초과 0건 ④ B06 21.2ms·0건 ⑤ 전체 시험 381 통과. 커밋 2b1fe118.

• 되돌림 — 곡선 계산 캐시 제거 (2026-09-04 사용자 보고 「종단 곡선 조절에 따라 횡단 기준 유토곡선 변경 안 됨」). 같은 날 프레임을 아끼려고 넣은 캐시가 원인 — 횡단 설계는 refreshCrossDesigns 가 같은 객체를 제자리에서 고치므로 「입력 객체가 같으면 안 바뀐 것」 판정이 성립하지 않음. B06 은 detail 동일성으로 캐시해 한 번 계산한 뒤로는 영원히 낡은 곡선을 보였음. 두 곳 모두 걷어내고 그릴 때마다 계산하게 되돌림. 커밋 79dc0cc8.

  • 자체검증 — ① B06 지반 종류 변경 시 절토 4,500.3 → 4,500.7㎥·곡선 경로 변화 확인 (고치기 전에는 완전 동일) ② B05 계획고 6칸 조절 시 계획선·유토곡선 둘 다 변화 (성토 14,729 → 17,513㎥) ③ 휠 20칸 최대 프레임 27.0ms·33ms 초과 0건 ④ 전체 시험 381 통과.

• 유토곡선이 그래프 칸 밖으로 새던 것 (2026-09-04 사용자 보고 — 「0선이 위로 넘어가고 채움색이 눈금 상한을 넘어 표현됨」). 유토곡선에 자르는 영역(clip)이 없었음 — 종단은 진작 자르고 있었는데 빠져 있었음. 겹 둘(면 뒤 / 곡선 앞)로 자르고, 0선은 창 안에 있을 때만 그리도록 함(사용자 확정: 0선은 나가도 됨). 커밋 331be116.

  • 자체검증 — 확대 4칸 + 휠 25칸으로 0을 밖으로 보낸 상태에서 자르는 겹 2개, 0선·0눈금 사라짐, 눈금 5개 전부 음수, 영역 캡처로 채움색이 위 경계에서 멈춤 확인.

• 700줄 초과 건은 아래 「700줄 제한 초과 — 한 번에 정리」로 모았음(2026-09-04 사용자 지시).

구조물 측점 누가거리 정본 일원화 (2026-09-04 사용자 보고)

증상 — 배수관 2 자리에서 계획선이 수직으로 꺾이고 최대 기울기 155,791 %.

원인(측정으로 특정) — 「가까운 점이 겹친 것」이 아니라 한 구조물이 층마다 다른 누가거리를 든 것: 횡단 측점 264.054626 · 종단 정본 변화점 264.055 · 배수 정본 파일 264.06 (cm 반올림, common_util_drainage_pipes.py). 사이드 목록이 든 값으로 계획고를 편집하면 정본 옆 5mm 자리에 변화점이 하나 더 서고, 둘 사이 종단곡선이 mm 로 쭈그러들어 기울기가 거리 0 에 가까운 값으로 나뉨. 2026-09-03 에 같은 증상(11,858%)을 ▲▼ 버튼 경로만 막아 뒀고, 측점 테이블·도구 경로가 남아 다시 터짐.

• 저장 쪽 — 누가거리를 좌표와 같은 밀리미터 기준으로 남김(cm 반올림 제거).
• 화면 쪽 — 구조물 측점 목록이 들어오는 한 자리에서 종단 정본 측점(0.1m 안)으로 누가거리를 갈아 끼움. 모든 편집 경로가 함께 막히고, 이미 cm 로 저장된 옛 프로젝트도 안전.
• 자체검증 (2026-09-04, 검증 대기) — ① 264 부근 그래프 측점이 264.055 하나로 모임 ② 그 측점 계획고를 8칸 올려도 수직 꺾임 0건, 계획선 점 수 1,208 불변, 최대 기울기 66.0 → 183.5%(정상값) ③ 전체 시험 381 통과. 커밋 5446f0cf.
• 겹치면 구조물 측점만 남김 (2026-09-04 사용자 확정 — 「규칙 측점에 구조물 측점이 위치하면 그때는 구조물 측점 하나만 기준으로 종단선을 그리면 된다」). 지금은 정본 맞춤으로 둘이 같은 자리에 모이면 측점선이 두 벌 그려짐(예: 980m — 배수관 11 이 규칙 측점 980 과 겹침). 겹쳐 보여 눈에 띄지는 않으나 같은 자리에 선이 둘인 것은 맞지 않음.
  • 그래프 측점 목록을 만들 때, 구조물 측점과 같은 자리(0.1m 안)의 규칙 측점을 뺀다 (_UI_Profile_Render.ts 의 regular + injected 합치는 자리).
  • 측점 번호 라벨은 그대로 읽혀야 함 — 구조물 측점이 같은 누가거리를 들고 있어 라벨 계산(offsetStationLabel)은 같은 값이 나옴. 실화면으로 확인.
  • 선택 동기화 확인 — 규칙 측점을 빼면 그 측점의 station_id 가 사라짐. 그래프·3D· 사이드바가 같은 측점을 고르는 경로(selectStation)와 측점 테이블 열이 구조물 측점 id 로 이어지는지 확인할 것. 여기가 이 작업의 유일한 위험.
  • 같은 규칙을 B06 종단에도 적용할지 확인(같은 렌더러를 씀).

700줄 제한 초과 — 한 번에 정리 (2026-09-04 지시)

사용자 지시 — 「700줄 리밋 리팩토링은 한번에 하자」. 그때그때 쪼개지 않고 여기에 모아 두고 한 번에 처리함. 착수 지시 대기.

전수 조사(.py·.ts·.css, node_modules·venv·0_old·tmp·storage·resources 제외) — 초과 5개, 임박(620~700줄) 39개.

줄수	파일	나눌 결
944	B07_DesignDetail/openwebcad/src/App.css	화면 영역별(툴바·캔버스·패널·대화상자)로 나눔. 이 폴더는 상류 저장소 없는우리 코드라 규칙 대상임
851	common_util/common_util_mass_haul_view.ts	세로창 규칙(버티기·부드럽게·범위 계산)을common_util_mass_haul_window.ts 로, 말풍선·EP·선택 강조를 별도로
730	B05_Profile/B05_Profile_UI_Profile_Panel.ts	높이 캐스케이드·리사이저 몫과 스크롤·세로창 갱신 몫을 각각 분리
718	B06_Section/B06_Section_UI_Section_View.ts	스크롤·패널 높이 처리 분리(종단 조립·유토곡선 조립은 2026-09-04 에 이미 뺌)
714	B03_FileInput/B03_FileInput_UI_Style.css	업로드 칸·카드·미리보기 영역별로 나눔

• 위 5개 분리 — 기능 이동 없이 잘라 옮기기만 함(내용 불변). 옮긴 뒤 npm run typecheck · ruff format · 전체 시험으로 같은 동작임을 확인.
• 임박 39개는 손대지 않음 — 620~700줄 구간(가장 큰 것 B05_Profile_UI_Page.ts 700줄). 넘길 때 그 작업에서 함께 나눔.

B05 초기화 범위 확대 — 전체 결과 보존 (2026-09-04 지시)

사용자 확정(2026-09-04) — 「초기값 = 파일 입력 직후 내부 기본값 결과 전부. 배수유역· 유토곡선·횡단도·횡단 구조물·3D 전체 포함, 불변」.

• 지금 되돌리는 것 — 노선 폴더 · 종단 · 횡단 · 관 편집분, DB 5개 표.

• 빠진 것 — 배수유역 분석 산출물(01~04), 3D 코리도(지우고 재계산), B07·B08 산출물.

• 스냅샷 범위 확대(배수유역) — 촬영 대상이 B04_PreProcess/drainage/edits 에서 B04_PreProcess/drainage 폴더 통째로 넓어짐. 이제 00_watershed_response · 01_primary_region · 02_flow_direction · 03_road_routing · 04_detailed_basins 가 함께 들어감. 용량 실측(용화_LAS): 배수유역 폴더 8.6MB, 스냅샷 전체 3.9MB → 약 12MB. 감당할 수준.

• 옛 스냅샷 호환 — 범위를 넓히기 전에 찍힌 프로젝트는 edits/ 만 갖고 있음. 그 경우 예전처럼 관 지점 편집분만 되돌림(안 하면 초기화 뒤에도 편집분이 남음).

• 3D 코리도 — 해결됨(2026-09-04). 「체인 시점에 코리도가 없다」는 전제 자체가 사라짐 — 전처리 체인 마지막에 서버가 같은 TS 빌더로 코리도를 만들어 저장하게 바꿨으므로, 스냅샷이 그것을 그대로 뜨고 [초기화] 는 새 route id 이름으로 되돌림. 읽기 전용 규칙도 안 건드림. 구현·검증은 위 「B05 종단·유토곡선 조작감 3건」의 코리도 항목(커밋 c322f538).

• 자체검증(단위) — tmp/tests/test_initial_snapshot_scope.py 3건 통과. ① 촬영 목록에 배수유역 폴더가 있음 ② 관을 옮겨 세부유역이 바뀐 뒤 복원하면 04_detailed_basins 와 관 지점이 초기 내용으로 되돌아감 ③ 옛 스냅샷도 관 지점 편집분이 되돌아감. 전체 시험 185 통과 · 1 건너뜀.

• 자체검증(실경로) 남음 — 용화_LAS 의 스냅샷은 범위를 넓히기 전에 찍힌 것이라 새 범위를 실화면으로 확인할 수 없음. 파일입력부터 자동설계 체인이 새로 도는 프로젝트가 필요함(또는 기존 프로젝트의 초기값을 버리고 다시 촬영 — 초기값 삭제라 사용자 지시 필요).

B05/B06 구조물 UI 통합 후속(2026-09-04 예정)

완료한 UI 결함 수정은 docs/raw/plans/2026-08-30_plan_B05_B06_ui_fixes.md로 이동했다.

도각·표제란 후속

완료 구현은 docs/raw/plans/2026-09-02_plan_user_verified_completed_items.md와 docs/wiki/pages/B08_DesignDetail/B08_CAD_title_block.md로 이관했다.

• 도각 외부 파일 불러오기와 개인용 도각은 다음 판 범위로 유지한다.

B05/B06 700줄 제한 위반 정리 — 남은 확인 (2026-09-04)(분리시 유사 기능끼리 모아서 제한 리밋과 갭을 만들것.)

두 창이 15개를 나눠 정리해 초과 파일 0건. 분리 목록·자체검증 기록은 docs/raw/plans/2026-09-04_plan_700line_split.md 로 이관함.

• B04 배수유역 라우터 — 쓰기 경로 확인. 분리 검증에서 읽기 경로(/drainage/rainfall·/drainage/primary-region 200)와 텍스트 대조까지만 했고 분석 재실행은 돌리지 않음(30초 재계산이 작업본 산출물을 덮어씀). 다음에 그 프로젝트를 재분석할 일이 생기면 그때 결과가 분리 전과 같은지 확인.

초기값 보전 후속

완료 구현은 docs/raw/plans/2026-08-29_plan_initial_design_lock.md로 이동했다.

• 새 프로젝트 업로드 때 initial_design.lock 동안 B05 진입이 B11 준비 화면으로 이동하고 체인 종료 후 자동으로 넘어가는지 실측한다.
• 노선 경로 변경을 전체 재계산으로 분리하고 별도 모달·진행 표시· route_signature 게이트를 설계한다.

진행 예정

B06 횡단·수량 후속

• 3D 코리도 스윕과 저장·확정·새로고침에서 extra_spans 단별 구간값을 확인한다.

• 자동 자리에서 좌우 이동이 적용되지 않는 측점의 지형·배치 한계를 분리한다.

• 불규칙 측점 생성 시점 정본화.

  • 파일 업로드 직후 자동연산은 저장, 사용자 직접 추가는 캐시에 두고 임시저장·확정 때 정본화.

라이다 다중 파일 입력·대용량 처리

• 드론 라이다 프로그램의 병합 가능 여부 확인 후 용량 대책을 합의하고 별도 계획 수립.
  • 평상시 2장 30GB 미만, 최대 3장 50GB 미만.
  • 노선 버퍼 클리핑 없이 병합 전체 범위를 전처리한다는 현재 방침 유지.

구조물 절·성토 면적 반영 — 분리 보류 (2026-09-02 사용자 확정)

현재 방식을 그대로 둔다. 착수 시점은 나중에 따로 정하며, 그때까지 2D 면적·유토곡선은 지금처럼 트림 전 표준횡단 기준으로 산출한다. B05·B06 다른 작업에서 이 산식을 건드리지 말 것 — 손대면 이 항목의 판이 흐트러진다.

• 구조물이 차지하는 절·성토 면적과 수량 반영 (보류 — 착수 지시 대기).
  • 원인 확인(2026-08-30): compute_cross_design이 구조물 인자를 아예 받지 않는다 (samples, design_elevation_m, ground_type, section_mode, ditch_*, paved, standard, rock_boundary_offset_m, two_stage_slope). 정본 design_line·cut/fill_area_m2는 트림 전 표준횡단이고, 구조물이 깎는 designTrim은 화면·3D가 그릴 때만 만든다.
  • 그 결과 3D(트림 반영)와 2D 면적·유토곡선(미반영)이 서로 다른 단면을 본다. common_util_mass_haul.ts가 design.fill_area_m2를 그대로 쓴다.
  • 크기(구조물 단면적 상한 — 겹침·근입 포함, 신발끈 적분): 84.3m 15.83㎡ / 149.73m 11.89㎡ / 200.92m 14.74㎡ / 275.71m 16.12㎡ 대 같은 측점 저장 성토면적 8.84 / 18.46 / 19.86 / 17.77㎡ — 성토량의 절반 규모다.
  • 착수 시 결정할 것: 트림 산식을 서버로 포팅할지, 확정 시점에 프론트가 잰 면적을 함께 저장할지. B08 수량산출(현재 37줄 셸)의 선행 조건이다.

참고

구조물 구현 기준

• 상세 타입·옵션 정본: B05_Profile/B05_Profile_Structure_Types.json.
• 배수관 정본: pipe_points.json; 일반 구조물 정본: structures.json.
• B05·B06은 같은 프론트 캐시와 백엔드 데이터를 사용한다.
• 점형=측점 1개, 구간형=시점~종점, 부지형=위치+면적.
• 자동=프로그램 산출, 후보=제안 후 사용자 확정, 수동=직접 추가.
• A8 집수정은 A1 배수관 유입부 옵션이며 단독 구조물이 아니다.
• 교량(A5)과 생태연못(F2)은 임도에서 사용하지 않는다.
• B·F·G군은 B05 선택지에서 제외하고 필요한 항목만 B06에서 사용한다.
• 기술 근거·수치는 resources/knowledge/technical_info/01_임도/를 우선한다.

계곡 통과 시설 선정

조건	시설
소계류, 횡단경사 30% 이하, 종단 3~5% 조정 가능	물넘이 또는 세월교 우선 검토
계곡 횡단경사 30% 초과	배수관 Ø800 이상; 800→1000→1200→1500 순 검토
수리계산 Ø1,500 초과, 협곡, 횡단경사 40% 이하	BOX암거 검토
배수관 2련 이상 필요	물넘이 재검토
하천 또는 3차수 이상 계곡	세월교 검토

설계유량은 Qd = 2.0 × Q와 Manning 통수능으로 판단한다. 관경은 유량으로, 집수정·기슭막이 등 부속은 지형과 배치 위치로 정한다.