# 도면에서 모델·보고서까지 — 전체 흐름과 ERD

현재 코드 확인 기준: 2026-09-11

**도면 입력 → 도면 정보 추출 → 객체·형상 생성 → 철근 배치 → 검사·보고서**

전체 그림과 아래 설명을 같은 **①~⑤ 순서**로 구성했습니다. 그림은 왼쪽에서 오른쪽으로, 각 단계 안에서는 위에서 아래로 읽습니다.

## 전체 그림

```mermaid
flowchart LR
    subgraph S1["① 도면 입력"]
        direction TB
        A1["DWG · DXF"]
        A2["원본 식별<br/>도면명 · SHA-256"]
        A1 --> A2
    end
    subgraph S2["② 도면 정보 추출"]
        direction TB
        B1["문자 · 선분 · 치수"]
        B2["평면 · 입면 · 단면<br/>상세 · 배근도 · 재료표"]
        B1 --> B2
    end
    subgraph S3["③ 객체·형상 생성"]
        direction TB
        C1["객체 구분<br/>블럭 · 부재 · 좌우"]
        C2["콘크리트 생성<br/>외곽 · 두께 · 표고"]
        C1 --> C2
    end
    subgraph S4["④ 철근 배치"]
        direction TB
        D1["한 본 형상 + 설치기준<br/>시작 · 끝 · 간격"]
        D2["객체에 귀속<br/>본별 3D 경로"]
        D1 --> D2
    end
    subgraph S5["⑤ 검사·보고서"]
        direction TB
        E1["전체 콘크리트<br/>합집합 이탈 검사"]
        E2["객체별 이미지<br/>위치 · 철근명"]
        E3["PDF · 작업 JSON"]
        E1 --> E2 --> E3
    end
    S1 --> S2 --> S3 --> S4 --> S5

    classDef input fill:#edf4fc,stroke:#6689af,color:#17324d;
    classDef evidence fill:#eef6f8,stroke:#679ba8,color:#173c46;
    classDef concrete fill:#eef5ef,stroke:#739b7b,color:#23412b;
    classDef rebar fill:#eef2ff,stroke:#7c8ac4,color:#2c3861;
    classDef report fill:#fff3eb,stroke:#c69c79,color:#634127;
    class A1,A2 input;
    class B1,B2 evidence;
    class C1,C2 concrete;
    class D1,D2 rebar;
    class E1,E2,E3 report;
```

| 순서 | 들어오는 정보 | 코드가 하는 일 | 다음 단계로 전달 |
|---|---|---|---|
| ① 입력 | DWG·DXF 원본 | 원본 식별, DWG 변환 경로 처리 | 읽을 수 있는 CAD 원본 |
| ② 추출 | CAD 원본 | 문자·벡터·치수·도면 뷰·재료표 판독 | 도면 근거 |
| ③ 형상 | 도면 근거 | 실제 객체 구분, 외곽·두께·표고 연결 | 콘크리트 객체 |
| ④ 철근 | 콘크리트 + 철근 근거 | 한 본 형상과 설치선 연결, 객체별 배치 | 실제 철근 경로 |
| ⑤ 보고서 | 콘크리트 + 철근 경로 | 구조물 이탈 검사, 객체별 이미지 구성 | 모델·보고서·저장 파일 |

작업의 기본 순서는 **도면 → 형상 확인 → 철근 → 결과 확인**입니다. 위 그림은 그 내부 처리를 다섯 단계로 펼친 것입니다.

## ① 도면 입력

DWG는 변환 경로를 거쳐 DXF로 읽습니다. 도면명·원본 내용 식별값은 원본 추적과 캐시 판단에 사용합니다.

| 정보 | 필드 예시 |
|---|---|
| 도면명 | `filename` |
| 원본 내용 식별 | `sha256` |
| 원본 접근 | `uploadId` |

**저장된 결과를 여는 것과 원본에서 다시 생성하는 것은 다른 동작**입니다.

## ② 도면 정보 추출

DXF 문자, BLOCK/INSERT, 벡터 좌표, 철근 표기와 재료표를 읽습니다. 초기 예비 치수와 최종 형상 근거를 구별합니다.

```mermaid
erDiagram
    direction LR
    DRAWING ||--o{ EVIDENCE : "도면 근거 추출"
```

| 구분 | 의미 | 주요 데이터 |
|---|---|---|
| DRAWING | 입력 도면 | 원본·도면명·내용 식별값 |
| EVIDENCE | 도면에서 읽은 근거 | 문자·치수·선분·뷰·재료표 |

도면 판독에는 로컬 CAD 추출·결정론적 연결 함수뿐 아니라 `call_model_plan`의 Codex 판독 경로도 존재합니다. 모든 정보를 순수 수식으로만 판독하는 구조는 아닙니다.

## ③ 객체 구분과 콘크리트 형상 생성

평면의 외곽·위치, 입면·종단의 높이·경사, 단면·상세의 두께를 실제 부재와 연결합니다. 같은 날개벽 이름이라도 블럭·좌우·시종점이 다르면 별도 객체입니다.

```mermaid
erDiagram
    direction LR
    EVIDENCE }o--o{ COMPONENT : "형상 근거 연결"
```

| 구분 | 의미 | 주요 데이터 |
|---|---|---|
| EVIDENCE | 여러 도면 뷰의 근거 | 외곽·치수·표고·접합 근거 |
| COMPONENT | 실제 콘크리트 부재 | `concrete_components[].id`, 종류, 외곽·표고 또는 메시 |

예: **날개벽 평면 + 입면 + 단면 → 블럭1 · 좌측 날개벽**

객체별로 생성하되 **접합부는 인접 객체와 함께** 확인합니다.

## ④ 객체별 철근 배치

콘크리트와 철근은 별도 데이터로 관리합니다. 철근 그룹에 상세·설치기준을 연결하고, 실제 철근 한 본마다 귀속 객체와 3D 경로를 저장합니다.

```mermaid
erDiagram
    direction LR
    COMPONENT }|--o{ REBAR_GROUP : "호스트 연결"
    REBAR_GROUP ||--o{ REBAR_INSTANCE : "본별 배치"
```

| 도면 정보 | 배치에 사용하는 내용 |
|---|---|
| 철근 상세 | 한 본의 절곡 형상·구간 치수 |
| 배근도·치수선 | 시작·끝·간격·설치선 배열 |
| 재료표 | 직경·본수·길이 대조 |

| 데이터 | 연결 필드 |
|---|---|
| 콘크리트 객체 | `concrete_components[].id` |
| 철근 그룹 | `mark`, `host_component_ids`, `rebar_assembly_id` |
| 한 본의 경로와 귀속 | `instance_paths_m[i]` ↔ `occurrence_instance_ids[i]` |
| 도면 설치기준 | `source_station_contract` |

`REBAR_INSTANCE`는 별도 테이블이 아니라 그룹 안의 두 배열을 같은 인덱스로 연결한 개념입니다. 정착·접합 철근은 도면 근거에 따라 복수 객체에 걸칠 수 있습니다.

**객체별 공통 구조**이지 모든 부재를 동일한 함수 하나로 생성한다는 뜻은 아닙니다. 부재 종류별 생성 함수와 공통 연결·검사 규칙이 함께 사용됩니다.

부분 처리의 기준은 **실패한 항목만 건너뛰고 독립적으로 생성 가능한 항목을 계속 처리하며, 기존 결과를 보존하는 것**입니다. 관련 예외 분리 수정과 회귀테스트는 진행했으나, 이 문서 작성 시 실행 중인 형상 작업을 보호하기 위해 8097 서버 재시작 적용은 대기 중입니다.

## ⑤ 검사·보고서·저장

보고서는 객체별로 정리하지만, 이탈 판정 범위는 **전체 콘크리트 합집합**입니다. 다른 부재 내부에 정착된 구간을 원래 호스트 밖이라는 이유만으로 이탈 처리하지 않습니다.

```mermaid
erDiagram
    direction LR
    REPORT ||--o{ REPORT_ROW : "객체별 결과"
    REPORT_ROW ||--o{ EXPOSURE_SEGMENT : "이탈 구간"
```

| 데이터 | 의미 | 표시·저장 내용 |
|---|---|---|
| REPORT | 현재 모델의 검사 스냅샷 | 입력 확인값·검사 버전·완료 여부 |
| REPORT_ROW | 객체·철근별 결과 | 위치·철근명·이미지 재구성 데이터 |
| EXPOSURE_SEGMENT | 검출된 구조물 밖 구간 | `airSegments` → 빨간 선·점 |

PDF는 이탈 항목을 **객체별 작은 이미지 + 위치·철근명**으로 구성합니다. 작업 JSON을 복원하면 저장된 모델·검사 좌표로 이미지를 다시 구성합니다.

### 작업 저장 구조

`JOB`은 전 단계의 도면·생성 결과를 묶는 작업 단위입니다. 작업 저장과 출력 흐름을 혼동하지 않도록 전체 그림의 교차 연결선에서는 생략했습니다.

| 저장 위치 | 담기는 내용 |
|---|---|
| `result` | 현재 생성 모델 |
| `partialResult` | 생성 중 누적된 부분 결과 |
| 작업 JSON의 `modelPlan` | 콘크리트·철근 모델 |
| 작업 JSON의 `modelReport` | 검사 결과·이탈 좌표·인쇄 구성 |

## 같은 순서로 보는 예시 — 블럭1 · 좌측 날개벽 WR2

| 순서 | 예시 |
|---|---|
| ① 입력 | 해당 날개벽이 있는 원본 도면 입력 |
| ② 추출 | 날개벽 평면·입면·단면 및 WR2 상세·배근도·재료표 판독 |
| ③ 형상 | 블럭1 · 좌측 날개벽 콘크리트 생성 |
| ④ 철근 | WR2 설치선과 한 본 형상을 해당 날개벽에 연결 |
| ⑤ 보고서 | 전체 콘크리트와 대조 → 이탈 선·점 → 객체별 이미지 출력 |

## 해석 범위와 한계

- 위 ERD는 실제 DB 테이블이 아니라 **현재 JSON·코드의 논리 관계**입니다.
- ERD에서 `||`는 하나, `o{`는 0개 이상, `}|`는 1개 이상입니다. 연결되지 않은 후보는 별도 보류 항목입니다.
- 객체별 공통 구조만으로 모델별 예외나 과거 보정 경로가 모두 제거됐다고 단정할 수 없습니다. 이 문서는 전체 하드코딩 감사 결과가 아닙니다.
- 파란색 표시는 승인 판정이 아닙니다. 사용자 확인 기록과 계산 결과는 분리합니다.
- `auditComplete`는 검사 계산 종료이지, 모든 철근의 도면 일치·시공 적합성 보증이 아닙니다.
- 현재 보고서는 원주 샘플 기반 검사이므로 미지원 형상과 샘플 사이 미세 노출의 한계가 있습니다.

## 코드 위치 — 위 순서와 동일

| 순서 | 코드 |
|---|---|
| ① 입력·변환 | `server.py` 업로드 처리, `dwg_conversion.py` |
| ② 문자·벡터·재료표 | `server.py`: `build_analysis`, `drawing_evidence_schema` |
| ③ 형상·단계 관리 | `server.py`: `call_model_plan`, `run_model_job` |
| ④ 객체별 누적 생성 | `progressive_rebar.py`: `stream_current_source` |
| ④ 그룹·본별 귀속 | `server.py`: `enforce_object_local_rebar_geometry_contract` |
| ④ 화면 표시 대상 | `rebar_review_visibility.js`: `isCurrentSourceDrawable` |
| ③·④ 화면 형상 | `model_kernel.js`, `app.js` |
| ⑤ 전체 합집합 검사 | `air_exposure.js`: `prepare`, `inspect`, `segment` |
| ⑤ 보고서·JSON | `model_report.js`, `app.js` |