---
title: 조경 BIM을 위한 IFC 4.3
subtitle: 수목 한 그루에서 시작하는 정보모델과 교환 실무
date: 2026-09-23
edition: 1.0
schema: IFC4X3_ADD2 (4.3.2.0)
---

# 01. 조경에서 IFC를 읽는 방법

공원 모델에서 나무 한 그루를 선택했다고 생각해 보자. 화면에는 줄기와 수관이 보인다. 관리 담당자가 필요한 것은 여기에 더해 수종, 관리번호, 식재 위치, 검사 기록이다. IFC는 이러한 정보를 여러 프로그램 사이에서 주고받을 때 사용하는 공통 데이터 구조다. 보기 좋은 형상에 필요한 의미와 근거를 연결하는 일이 조경 BIM의 출발점이다.

이 설명서는 조경을 공부하는 학생, 모델 작성자, 설계·시공·유지관리 담당자를 위한 자료다. 먼저 조경 대상을 IFC 객체로 표현하는 방법을 익히고, 그 객체를 공간·속성·좌표·검사 기록과 연결한다. 기준 판본은 **IFC 4.3 ADD2, 4.3.2.0, 스키마 식별자 `IFC4X3_ADD2`**다. 자료 확인일은 2026년 9월 23일이다.

## 형상과 함께 전달해야 할 것

| 질문 | 수목 한 그루의 예 | IFC에서 살펴볼 정보 |
|---|---|---|
| 무엇인가 | 관리 대상 느티나무 | 엔티티, 사전 정의 유형, 분류 |
| 어느 개체인가 | 수목 T01 | GlobalId, 관리번호 |
| 어디에 있는가 | 북측 식재 구역 | 공간 포함관계, 배치, 지리참조 |
| 어떤 사양인가 | 설계 규격과 준공 실측값 | 유형, 속성, 단위, 측정 시점 |
| 무엇을 근거로 확인했는가 | 준공 측량과 검사표 | 문서 참조, 검사 기록 |

IFC의 **엔티티(entity)**는 정보를 담는 대상의 종류다. `IfcGeographicElement`가 그 예다. **객체(instance)**는 그 종류로 실제 생성한 개별 데이터다. 같은 종류로 만든 수목 T01과 T02도 서로 다른 객체다. 이름을 ‘느티나무’라고 붙인 것과 식생 객체로 분류한 것은 별개다.

## 파일, 스키마, 프로그램을 구분한다

스키마는 사용할 수 있는 객체와 관계의 규칙이고, `.ifc` 파일은 그 규칙에 따라 작성한 데이터를 담는다. 통상적인 IFC 파일은 STEP 텍스트 문법을 사용한다. 작성 프로그램의 원본 파일과 IFC 파일은 역할이 다르므로 원본도 보관한다. IFC를 가져왔을 때 원래 프로그램의 편집 기능이 모두 복원된다고 기대해서는 안 된다.

IFC 4.3이라는 표시는 표현 가능한 범위를 알려 준다. 특정 파일에 필요한 정보가 실제로 들어 있다는 뜻은 아니다. 내보내기 설정, 사용하는 교환 뷰, 받는 프로그램의 구현 범위까지 확인해야 한다.

## 이 자료에서 예시를 읽는 기준

공식 엔티티와 속성의 의미는 buildingSMART 공개 명세를 따른다. 공원 구역 나누기, 사용자 속성 이름, 납품 항목은 이해를 돕기 위해 작성한 **교육용 적용안**이다. 이를 발주 기준이나 현장 검증 결과로 간주하지 않는다. 실제 프로젝트에서는 목적·계약·분류체계와 프로그램 시험 결과를 반영해 확정한다.

**공식 근거:** [IFC 4.3 고정 판본](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/) · [ISO 16739-1:2024 개요](https://www.iso.org/standard/84123.html)

# 02. 버전의 흐름과 선택 기준

IFC는 서로 다른 소프트웨어가 건설 정보를 공유하기 위한 공통 언어로 발전해 왔다. 조경에서 버전 차이를 살펴보는 이유는 새 버전이라는 이름 때문이 아니다. 식생·지형·포장·배수시설을 얼마나 정확하게 표현하고 상대방이 읽을 수 있는지 판단하기 위해서다.

## 건축 중심의 교환에서 인프라로

| 시기·판본 | 흐름 | 조경에서 읽을 점 |
|---|---|---|
| 1990년대 후반, IFC 1.x | 건설 분야 공통 정보교환의 초기 단계 | 형상과 업무 정보를 함께 교환하려는 출발 |
| 2000년대, IFC 2x 계열 | 객체·관계·속성 체계와 건축 교환의 축적 | 기존 도구와 납품 관행에서 자주 접하는 기반 |
| IFC 2x3 / TC1 | 건축 중심의 널리 쓰이는 교환 기반 | 4.x의 조경·인프라 객체를 그대로 담을 수 없음 |
| IFC 4, 2013 이후 개정 | 형상, 지리참조, 속성 표현의 확장 | IfcGeographicElement와 IfcMapConversion은 이때 이미 존재 |
| IFC 4.1·4.2 | 선형·인프라 확장의 중간 단계 | 4.3 ADD2와 같은 판본으로 취급하지 않음 |
| IFC 4.3 ADD2, 2024 | 교량·도로·철도·수로·항만을 포함하는 범위 | 포장·경계석·시설 구조·선형 정보를 함께 검토 |

IFC 4.3 ADD2는 ISO 16739-1:2024와 대응한다. ISO의 발행 시점은 2024년 3월, buildingSMART 판본 목록의 표기는 2024년 4월이다. 이는 서로 다른 등록·발행 기준의 날짜이며, 버전이 다르다는 뜻이 아니다.

## 식생 객체와 식생 구분은 도입 시점이 다르다

`IfcGeographicElement`는 IFC 4에 도입됐다. IFC 4.3 ADD2의 열거값에는 식생을 뜻하는 `VEGETATION`이 있으며, 그 범위에는 교목뿐 아니라 관목·초본·잔디 등도 포함된다. 따라서 ‘IFC 4.3에서 처음으로 나무를 표현할 수 있게 됐다’는 설명은 정확하지 않다. 이전 판본의 객체와 열거값을 구분해서 살펴봐야 한다.

## 판본을 결정할 때 기록할 것

1. 교환 목적과 대상: 예를 들어 준공 수목 인계, 포장 수량 검토, GIS 중첩 중 무엇인가.
2. 스키마와 뷰: IFC4X3_ADD2인지, 어떤 MVD와 내보내기 설정을 쓰는가.
3. 작성·수신 프로그램: 제품명과 정확한 버전, 가져오기·내보내기 기능을 기록한다.
4. 작은 시험의 결과: 객체, 좌표, 속성, 수량, 문서 연결이 남는지 비교한다.

기존 업무에서 IFC 2x3 또는 IFC 4가 요구되면 필요한 정보를 해당 판본으로 옮길 수 있는지 먼저 시험한다. 파일 헤더의 버전 문자열만 고쳐서 변환하지 않는다. 다른 엔티티로 바꾸거나 일부 정보를 포기해야 한다면 대응표와 손실 내용을 남긴다.

## RELEASE와 DEV를 구분해 읽는다

이 자료는 고정된 RELEASE 문서를 기준으로 삼는다. 개발·보완 중인 DEV 문서는 추가 설명을 찾는 데 도움이 되지만, 계약에서 지정한 판본과 같은 문서라고 가정하지 않는다. 링크를 열었을 때 주소와 문서 상단의 판본 표시를 함께 확인한다.

**공식 근거:** [판본 목록](https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/) · [ISO 개요](https://www.iso.org/standard/84123.html) · [지리 요소](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcGeographicElement.htm) · [식생 열거값과 변경 이력](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcGeographicElementTypeEnum.htm)

# 03. 조경 대상을 IFC 객체로 표현하기

먼저 무엇을 하나의 관리 대상으로 볼지 정한다. 개별 수목의 이력 관리가 목적이라면 수목별 객체가 필요하다. 잔디 교체 면적이 목적이라면 관리 구획별 면적 객체가 더 적합할 수 있다. 화면을 그리기 편한 단위와 정보를 인계하기 좋은 단위가 항상 같지는 않다.

## 객체 선택의 순서

대상의 기능과 의미에 맞는 구체 엔티티를 먼저 찾는다. 이어 `PredefinedType`의 허용값과 표준 속성의 적용 범위를 확인한다. 프로젝트 분류가 더 필요하면 분류 코드나 사용자 속성을 보완한다. 적합한 구조가 없을 때 일반 엔티티나 Proxy를 검토하고, 그 선택 이유를 기록한다.

## 조경 객체의 매핑 후보

다음 표는 공식 엔티티의 의미에 근거한 **적용 후보**다. 모든 프로젝트에 강제되는 분류표는 아니다.

| 조경 대상 | 검토할 IFC 표현 | 추가로 결정할 내용 |
|---|---|---|
| 현황·계획 지형 | IfcGeographicElement / TERRAIN | 조사 시점, 표면 표현, 원자료, 정밀도 |
| 개별 수목 | IfcGeographicElement / VEGETATION | 관리번호, 수종, 개체별 실측값 |
| 관목군·초지 | IfcGeographicElement / VEGETATION | 군식 범위, 면적, 개수·밀도의 산출 기준 |
| 보행 포장 | IfcPavement | 전체 포장과 층의 구분, 구간 분할 |
| 경계석 | IfcKerb | 길이 산정 기준, 곡선부와 세그먼트 |
| 벤치 | IfcFurniture | 제품 사양, 고정 방식, 기초와의 관계 |
| 안내판의 표지판 | IfcSign | 판면과 지주를 분리할지, 문안·방향 |
| 배수관 구간 | IfcPipeSegment | 관경, 구배, 흐름, 연결 구조 |
| 집수정·맨홀 | IfcDistributionChamberElement | 기능에 맞는 유형, 표고, 유지관리 접근 |

벤치는 고정됐다는 이유만으로 가구에서 제외하지 않는다. `IfcFurniture`의 정의에는 영구 부착 여부와 무관한 가구가 포함된다. 다만 벤치 본체, 기초, 지붕 등을 묶은 복합 시설이라면 부품과 조립체의 범위를 별도로 정한다.

## 이름만으로 의미를 대신하지 않는다

객체 이름이 ‘북측 수목 T01’이어도 엔티티가 일반 Proxy라면 식생만 고르는 검사에서 누락될 수 있다. 반대로 `VEGETATION`만으로는 교목과 잔디를 구별할 수 없다. 이 자료의 예시에서는 사용자 속성 `Landscape_ObjectClass`의 `Category`를 사용해 `TREE`, `SHRUB_GROUP`, `LAWN`을 구분한다. 이 값들은 교육용 합의안이며 IFC 표준 열거값이 아니다.

분류체계를 연결할 때는 체계 이름·판본·코드·정의를 함께 정한다. 이름이 비슷한 두 분류 코드가 같은 뜻인지 확인하지 않은 채 합치지 않는다. 객체 수량을 집계할 때는 개체와 군식 구획이 섞이지 않도록 한다.

**공식 근거:** [지리 요소](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcGeographicElement.htm) · [포장](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcPavement.htm) · [경계석](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcKerb.htm) · [가구](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcFurniture.htm) · [표지판](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcSign.htm) · [배수관](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcPipeSegment.htm) · [챔버](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcDistributionChamberElement.htm)

# 04. 공간과 관계의 구조

같은 수목이라도 ‘식재 구역에 속한다’, ‘느티나무 유형을 따른다’, ‘식재 작업의 대상이다’는 서로 다른 관계다. 이 차이를 이해하면 모델 트리와 속성 창에 보이는 정보를 더 정확하게 읽을 수 있다.

## 먼저 단순한 공간구조를 만든다

가상의 작은 공원에서는 프로젝트 아래에 대지를 두고, 대지 아래에 외부 공간을 나누는 구성을 사용할 수 있다. 아래는 교육용 구조도다. `IfcSpace`는 실제 또는 가상의 경계로 정의되는 공간이며, 외부 공간은 대지와 연결할 수 있다.

```
IfcProject  공원 조성 프로젝트
  IfcSite   가상 대상지
    IfcSpace  진입 구역
    IfcSpace  식재 구역
    IfcSpace  휴게 구역
```

이 공간 분해에는 `IfcRelAggregates`를 사용한다. 식재 구역에 수목을 포함시키는 관계는 `IfcRelContainedInSpatialStructure`다. 수목은 공간의 구성 단계가 아니라 그 공간에 속한 제품 객체다. 외부 공간 여부는 `Pset_SpaceCommon.IsExternal`로 표현하는 방식을 확인한다. `IfcSpace`의 과거 `EXTERNAL` 열거값에만 의존하지 않는다.

| 표현하려는 뜻 | 대표 관계 | 조경 예 |
|---|---|---|
| 전체와 부분 | IfcRelAggregates | 대상지와 외부 공간의 구조 |
| 공간에 속한 객체 | IfcRelContainedInSpatialStructure | 식재 구역에 포함된 수목 |
| 공유 사양을 따르는 개체 | IfcRelDefinesByType | 같은 조달 유형을 따르는 여러 수목 |
| 객체에 붙인 속성 | IfcRelDefinesByProperties | 수목별 관리 속성 |
| 객체와 수행 작업 | IfcRelAssignsToProcess | 수목과 식재 작업의 연결 |

## 공간 소속과 좌표 기준은 별개다

수목의 공간 소속이 식재 구역이라고 해서 좌표가 반드시 그 공간의 원점을 기준으로 계산되는 것은 아니다. 좌표의 상대 기준은 배치 정보에서 따로 읽어야 한다. 공간 트리가 맞아도 배치가 잘못될 수 있고, 화면상 위치가 맞아도 공간 소속이 빠질 수 있다.

제품의 주 공간 포함관계는 하나의 공간을 가리키는 계층 구조다. 여러 관리구역에 걸치는 객체를 표현하려고 동일 객체를 여러 공간에 중복 포함시키지 않는다. 추가 공간 참조나 그룹 등 목적에 맞는 관계를 검토한다.

## 시설 구조를 더할 때

여러 시설을 함께 인계하는 사업에서는 `IfcFacility`와 시설 부분을 포함하는 구조가 필요할 수 있다. 작은 공원에서도 이를 사용할 수 있지만 모든 단계가 필수는 아니다. 특히 `IfcFacilityPartCommon`을 이름이 ‘Common’이라는 이유로 일반 공원 구역에 일괄 적용하지 않는다. 정의와 교환 목적을 확인한 뒤 구조를 늘린다.

**공식 근거:** [공간](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcSpace.htm) · [공간 유형](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcSpaceTypeEnum.htm) · [전체와 부분](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcRelAggregates.htm) · [공간 포함](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcRelContainedInSpatialStructure.htm) · [유형 연결](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcRelDefinesByType.htm)

# 05. 수목의 속성을 설계하는 방법

수목 T01과 T02는 같은 조달 규격을 따르더라도 설치 위치와 준공 실측값이 다르다. **유형(type)**은 공통 사양을 묶는 역할을 하고, **개별 객체(occurrence)**는 현장에 놓이는 각 대상을 식별한다. 공통 정보와 개별 정보를 구분하면 수정과 검토가 쉬워진다.

## 표준 속성부터 확인한다

`Pset_VegetationCommon`에는 학명인 `BotanicalName`과 지역에서 사용하는 이름인 `LocalName`이 정의돼 있다. 이 세트는 `IfcGeographicElement / VEGETATION`에 적용하며, **개별 객체에 부착하는 세트**다. 수종이 같다는 이유만으로 세트를 유형 객체에 옮기지 않는다.

객체의 `PredefinedType`을 유형 객체에서 제공하는 경우도 있다. 개별 객체의 필드만 읽고 식생 구분이 없다고 판정하면 오류가 생길 수 있다. 유형 연결을 포함해 유효한 값을 읽는지 수신 프로그램과 검사기를 확인한다.

## 예시: 교목 인계를 위한 최소 정보

아래 이름 중 `Landscape_`로 시작하는 세트는 이 자료의 교육용 제안이다. 실제 적용 전에 다른 표준 속성의 적합성, 사내 사전, 발주 요구와 중복되는지 확인한다.

| 위치·세트 | 항목 | 예시·기록 기준 |
|---|---|---|
| 객체 기본 정보 | GlobalId / Tag | IFC 식별자 / 현장 관리번호 T01 |
| Pset_VegetationCommon | BotanicalName / LocalName | 학명 / 현장 사용 수종명 |
| Landscape_ObjectClass | Category | TREE: 이 예시의 교목 구분 |
| Landscape_TreeHandover | SurveyHeight | 수고의 준공 실측값, 길이 자료형 |
| Landscape_TreeHandover | SurveyDate | 측정일, 날짜 자료형 |
| Landscape_TreeHandover | RecordStatus | DESIGN 또는 AS_BUILT |
| 문서 참조 | 검사표·사진 식별자 | 관련 파일의 위치와 접근 방법 |

`SurveyHeight`를 문자열 ‘4.2m’로 기록하면 수치 비교가 어려워질 수 있다. 길이 값을 담는 적절한 자료형과 단위를 사용하고, 프로그램이 다른 단위로 내보내도 같은 물리량인지 확인한다. 흉고직경·근원직경·수관폭은 서로 다른 측정값이므로 모호한 ‘규격’ 한 칸에 섞지 않는다.

## 사용자 속성 이름과 갱신 책임

IFC 명세에 없는 사용자 속성 세트에 표준 접두사 `Pset_`를 붙이지 않는다. 이 자료에서 `Landscape_TreeHandover`처럼 구분한 이유다. 속성 사전에는 이름, 정의, 자료형, 단위, 허용값, 작성자와 갱신 시점을 함께 적는다.

설계 요구값을 준공 실측값으로 덮어쓰면 변경 내용을 추적하기 어렵다. 예를 들어 `DesignHeight`와 `SurveyHeight`를 구분하거나 설계·준공 판본을 별도로 보존한다. 동일 대상을 갱신했는지 식별할 수 있도록 GlobalId 유지 정책도 정한다. 객체의 관리번호와 IFC 식별자는 용도가 다르므로 서로 대체한다고 가정하지 않는다.

**공식 근거:** [식생 표준 속성](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/Pset_VegetationCommon.htm) · [속성 세트와 명명 규칙](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcPropertySet.htm) · [유형과 개체의 속성](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcRelDefinesByType.htm)

# 06. 지형과 좌표를 맞추는 방법

조경 모델은 측량, 건축, 토목, GIS 자료와 함께 쓰인다. 지형과 수목이 같은 화면에 보인다는 사실만으로 같은 좌표 기준을 사용한다고 판단할 수 없다. 파일을 교환하기 전에 로컬 원점, 실제 좌표계, 높이 기준, 단위를 문서로 맞춘다.

## 로컬 모델과 실제 위치의 연결

`IfcProjectedCRS`는 목표 좌표 참조체계를 기록하는 데 쓰이고, `IfcMapConversion`은 로컬 모델 좌표와 그 좌표체계를 연결한다. 대표적으로 동·북 좌표와 높이의 이동량, 수평 회전, 축척을 다룬다. 지도 투영 자체를 수행하는 만능 좌표변환 함수로 이해하지 않는다.

`IfcSite`의 위도·경도만으로 정밀한 지리참조가 완성되지는 않는다. 좌표계의 식별, 수평·수직 기준, 단위와 변환 관계가 함께 있어야 다른 자료와 일치 여부를 판단할 수 있다.

## 이해를 위한 간단한 계산

회전이 없고 축척이 1이며 양쪽 단위가 m라고 가정하자. 로컬 원점이 지도 좌표 E=200,000, N=500,000, H=50에 대응하면 로컬 위치 (10, 20, 2)는 지도 위치 (200,010, 500,020, 52)가 된다. **이 값들은 계산 설명용 가상 좌표이며 실제 대상지나 지정 좌표계가 아니다.**

실제 교환에서는 회전·축척·축 방향·단위가 다를 수 있다. 좌표계 코드만 같다고 판단을 끝내지 않는다. 서로 떨어진 여러 기준점과 높이를 비교해 평행이동, 회전, 축척 또는 높이 기준의 오류를 찾는다. 허용오차는 업무 목적과 측량·계약 기준에 따라 정한다.

| 확인 항목 | 기록하거나 비교할 내용 |
|---|---|
| 수평 기준 | 좌표계 이름·식별자, 축 방향, 단위 |
| 수직 기준 | 기준면, 표고 자료원, 단위 |
| 모델 기준 | 로컬 원점, 배치 계층, 진북과 도북의 관계 |
| 변환 정보 | 동·북·높이 오프셋, 회전, 축척 |
| 검증 근거 | 기준점 좌표, 계산 결과, 차이와 허용값 |

## 지형은 표면과 조사 근거를 함께 보낸다

`IfcGeographicElement / TERRAIN`은 지형을 표현할 때 검토할 수 있다. 현황 지형과 계획 지형은 목적과 기준 시점이 다르다. 원자료, 조사일, 해상도 또는 정밀도, 가공 방법을 남겨 구분한다. TIN과 같은 삼각망 형상은 프로그램별 지원 범위를 시험한다.

토공량을 계산할 때는 비교한 두 표면, 경계, 단위, 절·성토 산정 방법을 함께 기록한다. 모델의 체적값이 내역 산출 기준과 같다고 가정하지 않는다. 지중시설의 미확인 위치도 확정된 실측값처럼 표현하지 않는다.

**공식 근거:** [좌표 변환](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcMapConversion.htm) · [투영 좌표체계](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcProjectedCRS.htm) · [대지](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcSite.htm)

# 07. 포장·시설물·배수를 연결하기

같은 포장이라도 설계자는 마감과 구배를, 시공자는 단면과 작업 구간을, 관리자는 교체 범위를 읽는다. 객체를 나누는 기준과 전달할 정보는 이러한 사용 목적에서 정한다.

## 포장 전체와 구성층

`IfcPavement`는 포장 구조를 다룰 때 검토하는 엔티티다. 구성층을 독립 객체로 관리해야 한다면 `IfcCourse` 등을 검토하고, 재료층 정보만으로 목적을 달성할 수 있다면 해당 객체의 재료 표현을 확인한다. 두 방식을 함께 사용할 때는 전체와 부분의 관계를 명확히 하고 수량을 중복 합산하지 않는다.

가상 보행로에서 표층 60 mm, 기층 100 mm라는 값을 정했다고 하자. 이는 설명을 위한 값이며 시방 권장 두께가 아니다. 모델에는 각 두께의 단위와 어느 설계 판본의 값인지 남긴다. 두께만 입력하고 재료·다짐·배수 성능이 검증됐다고 해석하지 않는다.

## 수량에는 산출 기준이 필요하다

`IfcElementQuantity`는 길이·면적·체적 같은 수량 묶음을 담는다. `MethodOfMeasurement` 등으로 산출 방법을 명시할 수 있다. 표준 수량 세트를 사용할 때도 대상 엔티티와 정의를 확인한다.

| 수량 | 먼저 정할 질문 |
|---|---|
| 포장 면적 | 수평 투영면적인가, 경사면의 실제 면적인가? |
| 포장 체적 | 층별 순체적인가, 전체 체적인가? 공제 기준은 무엇인가? |
| 경계석 길이 | 중심선·한쪽 면·제품 길이 중 어느 기준인가? |
| 식재 수량 | 개별 수목 수인가, 군식 면적에 밀도를 적용한 추정값인가? |

## 시설의 본체와 구성품

안내판의 판면은 `IfcSign`을 검토할 수 있다. 지주와 기초까지 하나의 표지판으로 취급할지, 구성품을 나눌지는 제작·관리 목적에 따라 정한다. 벤치 역시 제품 전체, 기초, 교체 가능한 부품의 경계를 먼저 정한다. 작은 부품까지 모두 모델링하기보다 필요한 정보와 교환 성능을 비교한다.

## 배수는 연결과 높이를 함께 읽는다

배수관은 `IfcPipeSegment`, 집수정과 맨홀은 `IfcDistributionChamberElement`를 후보로 검토한다. 관경과 재료뿐 아니라 유입·유출 위치, 연결 구조, 바닥 표고, 흐름 방향을 확인한다. 화면에서 관이 집수정에 닿는 것과 데이터상 연결된 것은 다를 수 있다. IFC 객체의 존재만으로 배수 성능이 입증되지는 않는다.

**공식 근거:** [포장](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcPavement.htm) · [구성층](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcCourse.htm) · [수량](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcElementQuantity.htm) · [배수관](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcPipeSegment.htm) · [챔버](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcDistributionChamberElement.htm)

# 08. 현황에서 준공 인계까지

모델의 정보는 한 번 입력하고 끝나지 않는다. 조사 자료를 근거로 설계를 만들고, 설계 객체를 시공 작업과 연결한 뒤 실제 설치 상태를 확인해야 한다. 각 단계에서 무엇이 확정됐고 무엇이 아직 확인되지 않았는지 구분한다.

| 단계 | 남길 정보 | 다음 단계에서 쓰는 판단 |
|---|---|---|
| 현황 조사 | 자료원, 조사일, 좌표 기준, 기존 수목·시설의 상태 | 설계의 기준과 불확실성 |
| 설계 | 대상·유형, 재료, 설계값, 수량 기준, 판본 | 조달과 시공에 필요한 사양 |
| 시공 | 작업 구간, 대상 객체, 승인 문서, 변경 기록 | 작업 지시와 검사 대상 |
| 준공 검토 | 실측 위치·규격, 검사 결과, 미해결 사항 | 설치 상태와 인계 가능 범위 |
| 유지관리 | 관리번호, 담당자, 점검·교체 이력, 문서 | 점검과 보수의 대상 및 시점 |

## 객체와 작업을 연결한다

`IfcTask`는 식별 가능한 작업을 표현한다. 식재 작업, 지주 설치, 포장 시공 같은 단위를 구분하고 `IfcRelAssignsToProcess`로 대상 객체와 연결할 수 있다. 선후 관계는 `IfcRelSequence`를 검토한다. 모든 현장 시스템이 이러한 IFC 공정 정보를 읽는 것은 아니므로, 일정의 원본을 관리하는 시스템과 교환할 범위를 정한다.

수목 T01의 식재 위치를 바꾸는 경우에는 설계 객체, 작업 지시, 준공 실측값과 승인 기록이 함께 갱신돼야 한다. 어느 하나만 고치면 같은 관리번호에 서로 다른 위치가 남는다. 변경 사유, 승인 주체, 적용 판본을 기록한다.

## 긴 보행축과 선형 정보

`IfcAlignment`는 선형 시설의 기준을 표현한다. 길게 이어지는 도로변 식재나 시설물 위치를 측점 기준으로 관리할 때 검토할 수 있다. 수평·종단 구성과 해당 업무에 필요한 정보를 확인한다. 작은 공원의 모든 보행로에 선형 객체를 넣을 필요는 없다. 선형 기준이 실제 설계·시공 위치를 정하는 경우에 적용한다.

## 문서를 연결한 뒤 실제 접근을 확인한다

`IfcDocumentReference`와 관련 관계를 통해 시방서, 제품자료, 검사표 등을 연결할 수 있다. 연결은 파일 자체를 IFC 안에 내장했다는 뜻이 아니다. 수신자가 문서를 열 수 있는 위치와 권한을 갖는지 확인하고, 판본과 식별자를 유지한다. 개인 PC의 경로만 남기면 인계 후 접근할 수 없다.

현장 사진이나 검사 기록에 개인정보·비공개 위치정보가 포함돼 있으면 공개 교육 자료와 분리한다. 이 설명서의 공원과 수치는 모두 가상이며 현장 자료를 공개하지 않는다.

**공식 근거:** [작업](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcTask.htm) · [작업 대상 연결](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcRelAssignsToProcess.htm) · [선형](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcAlignment.htm) · [문서 참조](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcDocumentReference.htm)

# 09. 가상 공원으로 따라가기

40 m × 30 m의 가상 공원을 생각해 보자. 진입부, 보행로, 휴게 공간, 식재 구역과 빗물 정원이 있다. 이 예시는 **준공 수목의 위치와 관리 정보를 인계하는 방법**을 설명한다. 실제 공원의 조사·설계·시공 성과가 아니며, 실행 가능한 IFC 모델이나 인증된 납품 규칙을 제공하는 예시도 아니다.

## 1단계: 인계 목적을 좁힌다

수신자는 공원 관리 담당자다. 필요한 판단은 ‘관리할 교목이 빠짐없이 들어 있는가’, ‘현장에서 해당 나무를 찾을 수 있는가’, ‘수종·설치 상태·검사 근거를 확인할 수 있는가’다. 이 판단에 필요하지 않은 속성을 관행적으로 늘리지 않는다.

## 2단계: 공간과 객체를 정한다

대상지는 `IfcSite`, 식재 구역은 외부 `IfcSpace`로 표현하는 단순한 안을 사용한다. 교목 T01·T02·T03은 각각 독립된 `IfcGeographicElement`로 두고 `VEGETATION`으로 구분한다. 동일한 조달 사양을 공유하면 `IfcGeographicElementType`과 연결한다. 교목을 골라내는 사용자 구분값은 `Landscape_ObjectClass.Category = TREE`로 합의한다.

## 3단계: 값의 의미와 시점을 정한다

다음은 현장 결과가 아닌 합성 학습 데이터다. x·y·z는 설명용 로컬 m 좌표이며 정밀한 실제 위치를 뜻하지 않는다.

| 관리번호 | 로컬 x, y, z (m) | 수종명 | 준공 수고 (m) | 기록 상태 |
|---|---|---|---|---|
| T01 | 8, 22, 0 | 느티나무 | 4.2 | AS_BUILT |
| T02 | 16, 22, 0 | 느티나무 | 4.0 | AS_BUILT |
| T03 | 28, 20, 0 | 느티나무 | 미확인 | REVIEW_REQUIRED |

T03은 빈칸을 임의의 값으로 채우지 않는다. 측정 누락으로 남기고 담당자와 확인 절차를 정한다. `REVIEW_REQUIRED`는 이 예시의 상태값이며 IFC가 정한 품질 등급이 아니다. 실제 IFC로 작성할 때는 배치, 지리참조, 식별자와 관계까지 완성해야 한다.

## 4단계: 정보 확인과 현장 확인을 나눈다

교목 구분, 관리번호, 수종명, 측정일과 수고값은 규칙으로 확인할 수 있다. 반면 그 값이 실제 나무와 일치하는지는 측량과 검사 기록을 대조해야 한다. 모델이 모든 항목을 갖췄더라도 T03의 실측 근거가 없다면 인계 완료로 처리하지 않는다.

## 5단계: 작은 교환 결과를 기록한다

작성 프로그램에서 내보낸 파일을 수신 프로그램으로 가져온다. 세 수목의 식별자, 공간 소속, 유형, 속성, 좌표가 유지됐는지 비교한다. 재내보내기가 업무에 포함된다면 그 결과도 다시 비교한다. 보기 방식이 달라졌는지와 정보가 사라졌는지를 구분해서 기록한다.

사이트에서 제공하는 ‘요구사항 작성표’와 ‘교환 점검표’는 이 과정을 기록하기 위한 CSV 서식이다. 작성 예시이며 실행 가능한 IDS 파일이나 검사 결과를 대신하지 않는다.

**관련 근거:** 객체와 공간은 3~5장의 공식 정의를 따른다. 대상지, 배치, 속성 합의안과 수치는 이 설명서에서 구성했다.

# 10. 납품 요구와 검증

납품 요구는 ‘속성을 많이 넣는다’는 지시보다 구체적이어야 한다. 누가 어떤 시점에 어떤 판단을 할지 정하고, 그 판단에 필요한 대상·정보·단위·증거를 적는다. 요구한 값이 존재하는지와 요구 자체가 적절한지는 별도로 검토한다.

## IFC·MVD·IDS의 역할

| 이름 | 하는 일 | 조경 업무에서의 예 |
|---|---|---|
| IFC 스키마 | 표현 가능한 객체와 관계를 정의 | 수목·포장·배치·속성을 구성 |
| MVD | 특정 교환을 위한 구현 범위를 정함 | 사용할 뷰와 수신 도구의 지원 확인 |
| IDS | 필요한 정보의 조건을 기계가 읽도록 표현 | 교목에 수종·관리번호 등이 있는지 검사 |
| bSDD | 용어·분류·속성 정의를 참조하는 사전 | 같은 속성이 같은 뜻인지 확인 |
| BCF | 모델 객체와 시점을 연결해 이슈를 전달 | 위치 오류와 수정 요청을 공유 |

IDS는 규정한 정보 조건의 검토에 쓰인다. 수목의 활착, 현장 측량의 정확도, 배수 성능을 자동으로 보증하지 않는다. 이 자료의 요구사항 표는 IDS로 작성할 내용을 정리하는 출발점이며, 실행 가능한 IDS 자체는 아니다.

## 검사를 여섯 층으로 나눈다

1. **파일과 문법:** 파일이 열리고 선언한 스키마에 맞는지 확인한다.
2. **스키마·교환 범위:** 엔티티, 관계, 적용 뷰와 지원 기능을 확인한다.
3. **정보요구:** 필수 속성, 자료형, 허용값, 단위와 적용 대상을 검사한다.
4. **형상과 좌표:** 배치, 표고, 간섭, 수량과 허용오차를 검토한다.
5. **업무 의미:** 객체 구분과 정보가 인계 목적에 충분한지 판단한다.
6. **현장 근거:** 측량·사진·검사 기록과 실제 설치 상태를 대조한다.

## 교목 인계 요구를 작성하는 예

| 요구 | 확인 방법 | 추가로 남는 확인 |
|---|---|---|
| 관리 대상 교목을 구분할 수 있다 | 엔티티·유효 유형·합의된 분류값 확인 | 대상 교목을 빠뜨리지 않았는가 |
| 관리번호가 있고 중복되지 않는다 | 속성 존재 검사와 목록의 고유성 검사 | 현장 표찰과 같은 번호인가 |
| 수종·실측값·측정일이 있다 | 값과 자료형 검사 | 실제 수종·측정 기록과 일치하는가 |
| 위치를 재현할 수 있다 | 배치·좌표 변환과 기준점 비교 | 허용오차가 목적에 적합한가 |
| 검사표에 접근할 수 있다 | 문서 연결과 수신 권한 확인 | 문서가 해당 개체·판본의 근거인가 |

번호의 전체 목록 고유성, 좌표 편차, 문서 접근성처럼 별도 로직이 필요한 항목을 모두 IDS 한 파일에서 해결한다고 가정하지 않는다. 검사 도구가 실제로 지원하는 규칙과 결과 보고 범위를 확인한다.

## 납품 전 작은 시험에서 확인할 것

객체 수와 GlobalId, 공간 포함, 유형, 속성과 단위, 재료, 좌표, 수량, 문서 참조를 원본과 비교한다. 결과는 ‘합격’ 한 칸으로 끝내지 말고 도구 버전·검사 대상·판정 기준·차이·미해결 사항을 남긴다. IFC 4.3 지원이라는 제품 설명을 실제 프로젝트의 교환 성공으로 대신하지 않는다.

**공식 근거:** [IDS](https://www.buildingsmart.org/standards/bsi-standards/information-delivery-specification-ids/) · [MVD](https://technical.buildingsmart.org/standards/ifc/mvd/) · [bSDD](https://www.buildingsmart.org/users/services/buildingsmart-data-dictionary/) · [BCF](https://technical.buildingsmart.org/standards/bcf/)

# 11. 용어와 자주 묻는 질문

## 읽다가 막힐 때 찾는 용어

| 용어 | 이 자료에서의 뜻 |
|---|---|
| 엔티티 | IFC가 정의한 데이터 대상의 종류 |
| 객체·인스턴스 | 엔티티에 따라 실제로 생성한 개별 데이터 |
| occurrence | 현장에 놓이는 개별 대상의 객체 |
| type | 여러 개체가 공유하는 사양을 담는 유형 객체 |
| GlobalId | IFC에서 객체를 식별하는 전역 식별자 |
| PredefinedType | 엔티티를 더 구체화하는 표준 열거값 |
| ObjectType | 해당 엔티티 규칙에 따라 쓰는 추가 유형 설명 |
| Pset | 이름과 정의를 가진 속성의 묶음 |
| 수량 세트 | 길이·면적·체적 등 수량을 담는 묶음 |
| 배치 | 객체 좌표계와 다른 좌표계의 위치 관계 |
| 지리참조 | 모델 위치와 실세계 좌표체계의 연결 |
| Proxy | 더 적절한 의미 구조를 쓰기 어려울 때 검토하는 일반 표현 |

## IFC 4.3이면 모든 조경 정보가 표준화됐나?

식생·지형·인프라를 표현할 구조가 있어도 조경 업무의 모든 정보 항목과 납품 방식이 정해진 것은 아니다. 관리 단위, 지역 분류, 규격 측정 방식과 승인 절차는 프로젝트에 맞게 정해야 한다.

## 속성은 유형에 모으면 관리하기 편하지 않나?

공통 사양을 유형으로 묶으면 반복을 줄일 수 있다. 그러나 모든 표준 속성 세트를 유형에 둘 수 있는 것은 아니다. 세트의 적용 범위를 먼저 확인한다. 특히 `Pset_VegetationCommon`은 개별 객체에 부착하는 세트다.

## 화면에서 위치와 모양이 맞으면 교환에 성공한 것인가?

시각 확인은 필요하지만 충분하지 않다. 공간 소속, 유형, 속성, 단위, 수량과 문서가 유실될 수 있다. 반대로 정보는 남았지만 형상이 잘못 보일 수도 있다. 시각과 데이터 검토를 함께 수행한다.

## IFC를 내보내면 원본 프로그램에서 그대로 편집할 수 있나?

교환한 형상과 정보를 읽는 것과 원래의 설계 기능을 복원하는 것은 다르다. 필요한 편집 작업이 가능한지 시험하고 원본 모델, 교환 설정과 IFC 파일을 함께 보관한다.

## 납품 전에 가장 먼저 할 작은 일은 무엇인가?

수목 몇 그루와 포장·시설물 일부를 포함한 시험 파일을 정한다. 작성자와 수신자가 객체·속성·좌표를 비교하고, 실패한 항목을 해결한 뒤 범위를 넓힌다. 전체 모델을 만든 뒤에 처음 교환해 보는 일을 피할 수 있다.

## 공식 엔티티 페이지는 어디부터 읽나?

먼저 `Semantic definition`으로 의미를 읽는다. 이어 상속, 속성, `Formal propositions`의 조건, 표준 속성 세트의 적용 범위를 확인한다. `OPTIONAL`은 스키마에서 생략할 수 있다는 뜻이다. 해당 프로젝트의 인계 요구까지 선택사항이라는 뜻은 아니다.

**관련 근거:** 앞선 각 장의 공식 엔티티 링크와 12장의 출처 안내를 참조한다.

# 12. 출처와 자료의 범위

이 자료는 제공된 「IFC 4.3 체계 상세 해설 보고서 - 역사·버전 비교 확장판」(2026-09-22)을 조경 학습과 실무 참조에 맞게 재구성하고, 아래 공식 자료와 대조해 작성했다. 원문의 기계적인 문장과 반복을 줄이고, 조경 객체에서 시작하는 설명 순서로 바꿨다. 원본 PDF 자체는 이 사이트에서 재배포하지 않는다.

## 기준 문서

| 출처 | 이 자료에서 확인한 범위 |
|---|---|
| buildingSMART, IFC 4.3.2.0 고정 판본 | 엔티티·관계·속성·수량·좌표 구조 |
| buildingSMART, IFC Schema Specifications | 판본과 ISO 대응, 공식·개발 상태 |
| ISO 16739-1:2024 공개 개요 | 발행 시점과 건축·인프라 적용 범위 |
| buildingSMART IDS·MVD·bSDD·BCF 안내 | 정보요구, 교환 범위, 사전, 이슈 교환의 역할 |

- [IFC 4.3.2.0 고정 명세](https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/)
- [IFC 판본 목록](https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/)
- [ISO 16739-1:2024 공개 개요](https://www.iso.org/standard/84123.html)
- [IDS 공식 안내](https://www.buildingsmart.org/standards/bsi-standards/information-delivery-specification-ids/)
- [MVD 공식 안내](https://technical.buildingsmart.org/standards/ifc/mvd/)
- [bSDD 공식 안내](https://www.buildingsmart.org/users/services/buildingsmart-data-dictionary/)
- [BCF 공식 안내](https://technical.buildingsmart.org/standards/bcf/)

엔티티별 상세 근거는 각 장 끝에서 바로 연결한다. 고정 판본을 읽으려면 주소에 `RELEASE/IFC4_3`가 있는지 확인한다. 일반 문서 주소가 DEV 문서로 이동할 수 있으므로 문서 상단의 판본도 확인한다.

## 공식 정의와 이 자료의 적용안을 구분한다

IFC 엔티티·열거값·표준 속성의 의미는 명세에서 확인했다. 공원 공간구조, `Landscape_` 사용자 속성, 세 수목의 수치, 요구사항·점검표는 교육용 제안이다. 실제 소프트웨어의 IFC 내보내기·가져오기나 현장 성능을 검증한 결과로 제시하지 않는다.

이 설명서는 buildingSMART 또는 ISO의 공식 번역이나 인증 문서가 아니다. 외부 명세와 상표의 권리는 각 권리자에게 있다. 원문을 복제하기보다 핵심 개념을 풀어 쓰고, 확인할 공식 페이지를 연결했다.

## 판본과 수정 기록

- **1.0 / 2026-09-23:** 조경 중심의 12개 장으로 재구성. 고정형 벤치의 분류 설명, 식생 객체와 열거값의 도입 시점, 외부 공간의 표기, 개체·유형 속성의 구분을 정리했다.
- **기준 스키마:** IFC4X3_ADD2, 버전 4.3.2.0.
- **제공 자료:** 웹 설명, PDF 설명서, 수정 가능한 Markdown 원고, 요구사항 및 교환 점검 CSV 서식.

## 사이트를 이용하는 방법

처음 읽는다면 1~3장에서 개념과 객체 대응을 익힌다. 모델을 작성하는 중이라면 4~7장에서 공간·속성·좌표·수량을 찾는다. 인계를 준비한다면 9~10장의 가상 예시와 서식을 함께 읽는다. 각 장의 아래쪽에서 이전·다음 장으로 이동할 수 있다. PDF는 인쇄하거나 오프라인에서 읽을 때, Markdown은 원고를 수정할 때 사용한다.

서식에 값을 채웠다는 사실은 검사가 끝났다는 뜻이 아니다. 실제 업무에서 사용한 도구·판본·근거 파일과 담당자를 기록하고, 확인되지 않은 항목은 미확인 상태로 남긴다.