과거 이야기 : 오토데스크 일본과 협업

D+20

Apr 18. 2024

건축을 하는데 오토데스크를 모른다. 그것은 간첩임에 틀림없다. 일본 프로젝트 중 오토데스크와 협업을 했던 이야기를 잠시나마 더듬어가며 이야기해보려 한다.

여기 어디쯤 있었다.

오토데스크는 누구인가?

그래도 모르는 분들이 있기에 오토데스크를 이야기해 본다. 오토데스크는 오토캐드로 뚝배기 구멍이 뚫릴 때까지 평생 먹고사는 회사다. 오토캐드라는 프로그램은 기계, 건축, 전기 분야에서 안 써본 사람은 없을 정도로 유명한 프로그램이다. 주로 2D 설계를 할 때 쓰이며, 3D 시대에도 여전히 잘 쓰이고 있다. 그 이유는 상대적으로 쓰기 쉽고 비교적 가볍기 때문이다.

기계분야에선 오토캐드 이상의 존재감은 크지 않은 것으로 보인다. 하지만 건축분야에서는 막강하다. Revit을 중심으로 ifc관련 시장은 거의 선점하고 있다(나는 BIM이라고 까진 안 하겠다). 아마 한국의 건축회사의 90% 이상은 오토데스크 제품군을 기반으로 프로젝트를 진행할 것이다. 그 정도로 엄청난 파워를 가진 회사다.

그리고 외국계회사란 대부분 홍콩, 싱가포르, 일본에 지사를 두고 한국엔 영업소 정도를 둔다. 참으로 슬픈 일이다. 그렇기 때문에 일본에 상대적으로 중요한 인물들이 더 많다고도 얘기할 수 있다.

오토데스크에서 그래스호퍼를 한다?

그런 면에서 내가 오토데스크에서 접촉한 사람은 다소 이례적인 부부이 있다. 왜냐하면 오토데스크의 제품군을 쓰지 않고 Rhino를 썼기 때문이다. 즉, 오토데스크 제품군을 홍보하는 자리였다면 Revit + Dynamo를 통해 문제를 해결했어야 하는 것이 맞다. 하지만 그는 메뚜기(Grasshopper)를 이용해 문제를 해결하고 있었다. 나의 확대해석을 덧붙이자면 역시 메뚜기만 한 게 없다.

아무튼 규칙은 명확하지만 그 반복이 너무 심해 스크립트 작성이 필수적인 프로젝트에 내가 뛰어들게 되었다. 내 업무는 해당 프로젝트의 스크립트를 보고 이해한 후 다시 다쏘시스템의 3 DExperience(이하 3Dx)로 재구성하는 내용이었다. 그때당시 xGenerative Design(이하 xGen)이라고 하는 3Dx에서 구동 가능한 프로그램이 나왔고, 대표는 이것을 좀 더 프로모션 하고 싶어 했기 때문이다.

건네받은 스크립트와 재해석 작업

업계에 있으며 다른 사람의 메뚜기 파일을 받을 일은 많지 않다. 왜냐면 다들 주기 싫어하기 때문이다. 하지만 그는 흔쾌히 내줬다. 코드를 보니 나와는 다른 패턴으로 짜는 부분이 있어 재밌었다. 내 업무는 해당 내용을 3Dx에 옮기는 것이었기에 하나하나 뜯어보기로 했다. 작업을 하며 패턴을 찾고 내용을 옮기기 시작했다.

옮기는 작업은 순탄치 않았다. 당시 3Dx의 xGen은 굉장히 불안정했다. 클라우드로 모든 것을 옮겼는데, 그게 화근이었다. 클라우드를 쓰려면 서버 지연율이 낮아야 하는데 당시 그렇지 못했다. 그때 얘기하기론 서버가 인도에 있다 그랬다. 그래서 뭐 하나 저장을 하면 저장이 안 되거나 내용물이 통째로 날아가거나 그런 일이 빈번했다. 그래서 로직과의 싸움이라기보다는 인터넷과의 싸움이었다.

그런 싸움을 계속하다 보니 결국엔 해내긴 했다. 해당 스크립트를 원 건축가에게 주고, 본인이 원하는 사이즈를 만들어보세요 까지 하는 것이 내 일이었다.

여기서 배운 것은?

그렇다면 여기서 내가 배운 것을 더듬더듬 다시 적어보면 이렇다.

1. 클라우드는 함부로 하는 것이 아니다.

오토데스크 협업에서 클라우드 얘기로 넘어왔지만 클라우드에 대해 이야기해보자. 클라우드의 이상적인 이야기는 모두가 하나의 데이터를 가지고 같은 내용을 중심으로 협업을 이뤄내는 것이다. 하지만 그 클라우드가 문제가 생기면 모든 프로젝트는 정말 어그러지고 만다.

당시 3Dx의 경우 클라우드로 전환한 것은 좋았지만 서버 지연율이 너무나 끔찍했기 때문에 정말 쓸 수가 없었다. 작년에 다시 써봤을 때 그 점은 개선돼서 다행이었다. 클라우드 기반 서비스를 한다면 오프라인 기능도 반드시 지원해줘야 한다.

2. 하나를 깊이 잘하는 것이 중요하다

그때의 나는 한우물을 파는 장인이었다. Rhino 메뚜기를 정말 깊이 하고 싶어서 플러그인 개발도 알아보고 python도 야매로 공부해 보고 온갖 발악을 다 하던 시기였다. 그래서 꽤나 깊은 수준까지 할 수 있었다. 그 경험을 토대로 데이터 구조에 대한 이해, 각 형상 간 연산이 어떻게 될지 예측할 수 있었다. 그리고 그렇기 때문에 같은 개념이지만 다른 플랫폼에 생긴 xGen에서도 같은 내용을 구현할 수 있었다.

이런 의견이 틀리지 않은 것이 내가 퇴사할 즈음엔 Dynamo로 짜인 예제 코드를 메뚜기로 변환하기도 했으니까. 아무튼 프로그램을 배울 땐 하나를 깊이 하는 게 옳다.

3. 침묵의 엔지니어는 한계가 있다

지원팀 엔지니어의 숙명은 전면에 거의 나설 일이 없다는 것이다. 그래서 내가 어떤 것을 해냈는지 나 자신도 피부로 느끼기 힘든 점이 있다. 그런 게 단절된 부분은 인간적인 성장면에서 아쉬운 부분이다. 그리고 기술보다는 껍데기가 중요한 원칙상 기술만 하는 엔지니어는 한계가 있다. 결국 그런 것들을 더 잘 포장하는 것이 설득력을 가지는 세상에서 아무리 잘해도 조용히 있는 것은 꽤나 손해 보는 장사다. 그러니 본인이 한 것을 잘 이야기하고 정리하는 것이 중요하다는 생각이 들었다.

왜냐하면 건축가에게 내용물을 전해줄 때 나는 건축가를 한 번도 만난 일이 없었고, 나를 어필할 수 없었기 때문이다. 잠재적으로 미래의 내 고객을 대면으로 만날 기회를 잃은 것이다. 사회성이 좋지 못해 잘 어울리진 못하지만 고객관계를 잘 관리하는 일도 중요하다

keyword

Brunch Book

코드아키택트 직업 개발자

BIM / Facade Consultant / Software Engineer in AEC 라는 직무를 수행하고 있습니다. 브런치에서 글을 쓰며 다양한 기회들을 만나고 있습니다

팔로워 115

이전 20화과거 이야기 : 일본의 태풍을 만나다과거 이야기 : 일본에서 후임을 받고 가르치다다음 22화