Rhino.Inside.Revit로 연결하는 Grasshopper 파라메트릭 BIM 워크플로

Grasshopper의 알고리즘 설계 능력과 Revit의 BIM 데이터 관리 능력은 오랫동안 별개의 세계였다. 복잡한 형상은 Rhino/Grasshopper에서 만들고, 이를 다시 Revit으로 옮겨 벽·바닥·패밀리로 재작업하는 과정에서 형상 왜곡과 데이터 손실, 중복 모델링이 반복됐다. Rhino.Inside.Revit는 이 단절을 없앤다. Rhino와 Grasshopper를 Revit 프로세스 내부에서 직접 구동해, Grasshopper 캔버스에서 정의한 파라메트릭 지오메트리를 Revit 네이티브 요소로 실시간 생성·갱신하는 것이 핵심이다. 이 글은 개념부터 설치, 컴포넌트를 이용한 요소 생성, 실무 워크플로까지 프로그래밍 관점에서 정리한다.

■ Rhino.Inside.Revit란 무엇인가

Rhino.Inside는 McNeel이 공개한 오픈소스 기술로, Rhino 엔진(RhinoCommon)을 다른 64비트 호스트 애플리케이션의 프로세스 안에 로드해 구동한다. Rhino.Inside.Revit는 그 호스트가 Revit인 버전으로, Revit 리본에 별도 탭을 추가하고 그 안에서 Rhino 창과 Grasshopper 캔버스를 띄운다. 두 프로그램이 같은 메모리 공간에서 돌기 때문에 파일 내보내기·가져오기 없이 Grasshopper의 지오메트리를 Revit API로 직접 넘겨 요소를 만들 수 있다. 즉 Grasshopper가 Revit을 스크립팅하는 시각적 프로그래밍 프런트엔드가 되는 셈이다.

핵심 개념은 세 가지다. 첫째, 변환(Conversion) — Rhino의 Brep·Mesh·Curve가 Revit의 DirectShape, 벽, 바닥, 매스, 로더블 패밀리로 인코딩된다. 둘째, 참조(Reference) — Revit에 이미 있는 요소를 Grasshopper로 쿼리해 파라미터·형상을 읽어온다. 셋째, 트랜잭션(Transaction) — Grasshopper 컴포넌트가 실행될 때마다 Revit 문서에 대한 트랜잭션이 열리고 커밋되어 되돌리기(Undo) 히스토리에 기록된다.

■ 설치와 실행 요건

Rhino.Inside.Revit는 정식 라이선스가 있는 Rhino와 Revit이 같은 PC에 설치돼 있어야 동작한다. 버전 호환은 아래와 같다.

항목	요건
Rhino	Rhino 7 / 8 (정식 라이선스 필요, 데모 불가)
Revit	Revit 2018 ~ 2027
배포 방식	Food4Rhino 또는 Rhino 패키지 매니저(Yak)에서 RhinoInside 설치
최초 로드	Revit이 “미검증 애드인” 경고 → “Always Load(항상 로드)” 선택
실행	Revit 리본의 Rhino.Inside 탭 → Grasshopper 버튼

설치 후 Revit 리본에 Rhino.Inside 탭이 생기고, 여기서 Grasshopper를 열면 Revit 전용 컴포넌트 그룹(Revit 탭)이 팔레트에 추가돼 있다. 32비트 환경이나 데모 라이선스로는 로드되지 않으므로, 실무 도입 전 라이선스와 버전 조합을 먼저 확인한다.

■ 컴포넌트로 Revit 요소 생성·조회하기

Grasshopper의 Revit 팔레트는 크게 Build(생성), Elements(조회), Query(필터), Parameter(파라미터) 그룹으로 나뉜다. 실무에서 가장 자주 쓰는 흐름은 “Grasshopper에서 형상 정의 → Revit 요소로 굽기(bake)”다. 개념 코드로 표현하면 다음과 같은 데이터 흐름이 된다.

목적	대표 컴포넌트	입력 → 출력
벽 생성	Add Wall (Curve)	커브 + 레벨 + 벽 타입 → Revit 벽
바닥 생성	Add Floor	닫힌 커브 + 바닥 타입 → Revit 바닥
자유형상 배치	Add DirectShape (Geometry)	Brep/Mesh + 카테고리 → DirectShape
매스/패밀리	Add Component Family	지오메트리 → 로더블 패밀리 인스턴스
요소 조회	Query Elements / Element Geometry	카테고리·필터 → 기존 요소·형상
파라미터 읽기/쓰기	Element Parameter Get/Set	요소 + 파라미터명 → 값

의사코드로 나타내면 파라메트릭 벽 생성 로직은 다음과 같다.

# Grasshopper 데이터 흐름(의사코드)
base_curve = Interpolate(control_points)      # Rhino에서 형상 정의
level      = QueryLevels("1F")                 # Revit 레벨 참조
wall_type  = QueryWallTypes("기본 벽 200mm")   # Revit 벽 타입 참조
walls      = AddWall(base_curve, level, wall_type)  # Revit 트랜잭션으로 벽 생성
SetParameter(walls, "주석", "GH 자동생성")     # 파라미터 기록

control_points 슬라이더를 움직이면 커브가 갱신되고, 그 즉시 Revit 모델의 벽이 다시 그려진다. 요소는 DirectShape로 굽는 경우와 네이티브 시스템 패밀리(벽·바닥)로 굽는 경우가 있는데, 스케줄·태그·물량 산출이 필요하면 네이티브 요소로, 순수 조형만 필요하면 DirectShape로 처리하는 것이 원칙이다.

■ 파라메트릭 폼에서 Revit 매스·패밀리로

복잡한 파사드나 지붕 셸처럼 반복 패널로 이뤄진 형상은 Rhino.Inside.Revit의 대표 시나리오다. 전형적 흐름은 (1) Grasshopper에서 서피스를 UV로 분할해 패널 격자를 만들고, (2) 각 패널에 두께·프레임을 부여한 뒤, (3) 이를 Adaptive Component(적응형 패밀리) 또는 DirectShape로 Revit에 인스턴싱하는 것이다. 패널마다 면적·각도를 파라미터로 기록해두면 Revit 스케줄에서 그대로 물량과 제작 정보를 뽑을 수 있다.

이때 성능 관리가 중요하다. 수천 개 패널을 매 슬라이더 조작마다 다시 굽으면 Revit 트랜잭션이 과부하된다. 실무에서는 Grasshopper의 데이터 트리를 확정한 뒤 Add 컴포넌트를 활성화(굽기)하고, 조정 단계에서는 프리뷰만 켠 채 작업하는 방식으로 트랜잭션 횟수를 줄인다.

■ 대안 경로: Geometry Gym·IFC

Rhino.Inside.Revit가 실시간 라이브 링크라면, Geometry Gym(ggRhino) 계열 플러그인은 IFC 스키마를 매개로 Rhino/Grasshopper 모델을 IFC 요소로 인코딩해 Revit으로 임포트하는 별도 경로를 제공한다. 실시간성은 떨어지지만 구조 해석 도구나 다른 BIM 저작도구와의 상호운용이 필요할 때 유용하다. Dynamo를 병행해 Revit 내부의 파라미터 배치 자동화를 함께 쓰는 하이브리드 구성도 흔하다. 프로젝트 요구에 따라 라이브 링크(Rhino.Inside)와 스키마 교환(IFC)을 구분해 선택한다.

■ 눈여겨볼 것

Rhino.Inside.Revit의 진짜 가치는 “형상 변환기”가 아니라 “설계 의도의 파라미터화”에 있다. 파사드 분할 규칙, 층별 셋백 로직, 구조 격자 간격을 Grasshopper 정의로 잡아두면, 대안 검토가 파일 재작업이 아니라 슬라이더 조정으로 끝난다. 다만 라이브 링크로 만든 요소는 Grasshopper 정의에 종속되므로, 정의 파일(.gh)과 Revit 모델을 한 세트로 형상관리하고 굽는 시점·범위를 팀 규칙으로 정해두어야 협업에서 혼선이 없다.

■ 이런 분께 도움이 됩니다

Rhino/Grasshopper로 조형은 하지만 Revit 재작업에 시간을 뺏기는 설계자
파사드·비정형 지붕처럼 반복 패널·비정형 형상을 다루는 BIM 매니저
Dynamo만으로는 한계가 있는 복잡 지오메트리 자동화를 검토하는 개발자

■ 참고

버전 조합(Rhino 7·8 / Revit 2018~2027)과 정식 라이선스 여부를 먼저 확인한다. 대규모 요소를 다룰 때는 트랜잭션 부하와 파일 형상관리 규칙을 사전에 합의하고, 스케줄·물량이 필요한 요소는 DirectShape가 아닌 네이티브 패밀리로 생성하는 원칙을 지킨다.