코딩하는 건축가 : 2일
Revit API를 논하다
오늘은 Revit이라는 프로그램을 통해 좀 더 깊게 해결해야 할 문제가 있었다. 그와 관련된 이야기를 조금 해보려 한다.
Revit : 건축 BIM 도구의 사실상 표준
BIM = ifc = Revit이라는 기형적인 세상
Revit이 뭔지 모르는 독자들을 위해 잠깐 이야기하자면 Revit은 건축 분야에서 쓰이는 3D 모델링 도구 중 하나이다. 나는 Revit이라는 프로그램을 그렇게 좋아하지 않고, 내 기술철학 아래에서 Revit은 그렇게 좋은 프로그램이라고 생각하진 않는다. 그럼에도 Revit이 업계의 사실상 표준이 된 것은 Autodesk라는 회사의 파워가 워낙 세기 때문이라고 생각한다. 그리고 모델링 방법이 비교적 단순하기 때문에 사람들이 많이 쓰고 있다고 생각한다. 그럼에도 나는 어깃장을 놓는 것은 1) 실제 제작도를 만들 수준의 모델링을 하기 힘든 도구고 2) 그 위에서 개발을 하기에 그렇게 합리적인 도구도 아닌 것으로 보기 때문이며 3) 건축의 복잡한 문제를 풀기에는 프로그램의 유연성이 너무 떨어진다. 건축에서는 제약이 창의성을 만든다는 말을 많이 하긴 한다. 그게 맞는 말이긴 한데, 여기에 들이는 노력일 다른 곳에 들이면 더 행복하지 않을까라는 생각은 자주 한다.
개발경험은 참 좋지 못하다
어느 세부 터 개발경험이라는 단어를 쓰게 된다. 개발경험을 뭐라고 표현해야 할까. 개발하는 동안 쾌적도를 나타내는 말이라고 할 수 있을 것 같다. 그런 면에서 Rhino 개발에 비해 Revit개발 경험은 그리 좋지 못하다. 체계적인 것과 경직된 것은 깻잎 한 장 차이 일 텐데, Revit API는 경직된 느낌이 더 강했다.
프로젝트에 불러오기 된 Family 정보를 읽는 방법을 예로 들어보면 다음과 같다. 내 기준에서 직관적인 API 구성은 다음과 같아야 한다고 생각한다. 현재 revit문서를 doc이라 한다면 doc.loadedfamilies()로 호출한다면 원하는 Family들을 불러올 수 있어야 한다고 생각한다. 근데 실제로 해보면 doc.EditFamily(family)와 같은 식으로 해당 정보를 찾아야 한다. 그래서 이와 관련된 문서를 찾는데만 꽤나 오랜 시간이 걸렸다.
나는 PyRevit을 이용해 개발을 한다. 그래서 compiile문제로부터 자유롭다. 그러나 다른 분들은 C#을 이용해 개발하는데, 개발 경험은 정말 고통스러워 보였다. 단순히 C#이라서 문제가 아니라, 해당 결과를 로드하는 방식이 매우 불합리적이었다. 컴파일하고 로드하려면 Revit을 다시 켜야 하는 것으로 보였다. 즉 매 세이브마다 몇 분씩 기다려야 하는 경우가 꽤나 보였다. 내가 예전에 Grasshopper plugin 개발 깔짝거려 봤을 때는 그 정도는 분명 아니었다.
AI 시대와 Revit API
그래도 대학원에서 깔짝 AI를 해봤다는 관점에서 논해보면 이렇다. Revit은 AI시대에 맞지 않는 도구로 보인다. 왜냐하면 내가 다른 웨비나를 봤을 때, Revit을 통해 데이터를 뽑을 수 없어서 Rhino로 돌려 데이터를 뽑았다는 부분이 있었다. Revit은 건설 데이터를 통합하는 도구일 텐데 이와 같은 작업이 잘 안 된다면 문제가 있어 보인다. 또한 여러 문서를 찾아봤을 때 유사한 연산을 Rhino와 비교 시 매우 느린 것을 볼 수 있었다.
그래서 결론은
무엇을 얻고 싶으냐 따라서 다르겠지만, 나는 Revit API 개발이라는 분야에 되도록 사람들이 발을 들이지 않았으면 좋겠다. 끝이 분명하고, 다른 스킬 셋으로 갈아타기에 상당히 애매한 부분이기 때문이다. 즉, 웹을 배우면 다른 분야로 뻗어나갈 수 있지만 Revit API는 거기서 끝이라고 본다. 그리고 해당 프로그램을 통해 노릴 수 있는 시장은 유관 시장인데 그게 확장성 한계도 명확해 보인다. 아무튼 업무상 어쩔 수 없이 해야겠지만 세상을 넓게 보고 무언갈 꾸려 나가고 싶다면 너무 깊게는 안 팠으면 좋겠다.
