토목 엔지니어가 자바스크립트와 Three.js를 배워야 하는 이유

Three.js로 코딩한 강합성 거더교 3D 모델

우리는 왜 아직도 무거운 프로그램과 엑셀에 갇혀 있을까?

아침에 출근해서 가장 먼저 하는 일을 떠올려 보자. 메일을 확인하고, 어제 보던 모델을 열기 위해 Revit이나 Midas를 실행한다. 그리고 기다린다. 라이선스 서버가 응답하기를, 수백 메가바이트짜리 모델이 로딩되기를. 가끔은 "사용 가능한 라이선스가 없습니다"라는 메시지를 보고 옆자리 동료에게 언제 끄냐고 묻기도 한다.

설계 검토 회의는 더 답답하다. 발주처 담당자에게 3D 모델을 보여주고 싶지만 그쪽 PC에는 뷰어가 없다. 결국 캡처한 이미지 몇 장을 PPT에 붙여 보낸다. 현장에서 태블릿으로 거더 배치를 확인하고 싶다는 요청이 오면 할 말이 없다.

그리고 모델링이 끝나면 다시 엑셀로 돌아온다. 물량을 뽑고, 구조계산서 양식에 값을 옮겨 적고, 단면이 하나 바뀌면 이 과정을 처음부터 반복한다.

거더 몇 줄, 가로보 몇 개, 바닥판 한 장. 구조 자체는 단순한데 이걸 3D로 확인하려면 무거운 프로그램을 거쳐야 한다. 이쯤 되면 한 번쯤 이런 생각이 든다.

"설치 없이, URL 하나만 보내면 누구나 도면과 3D 모델을 볼 수는 없을까?"

이 질문에 대한 답이 바로 자바스크립트와 Three.js다.

---

파이썬이 아닌 자바스크립트인 이유

엔지니어가 코딩을 시작한다고 하면 대부분 파이썬을 먼저 권한다. 틀린 말은 아니다. 데이터 분석, 수치 계산, 엑셀 일괄 처리에는 파이썬만 한 도구가 없다.

문제는 "내가 만든 툴을 동료에게 줄 때" 생긴다.

파이썬 스크립트를 넘기려면 이런 대화가 오간다. "파이썬 설치되어 있어요? 버전이 몇이에요?", "pip install 먼저 해주세요", "아, 회사 보안 정책 때문에 설치가 안 된다고요?" 결국 그 툴은 내 PC에서만 돌아가는 '나만의 스크립트'로 남는다. 아무리 잘 만들어도 팀의 자산이 되지 못한다.

자바스크립트는 출발점이 다르다. 이미 모든 PC에 실행 환경이 깔려 있다. 크롬, 엣지, 사파리 — 브라우저 자체가 자바스크립트 엔진이기 때문이다.

파이썬과 자바스크립트의 툴 공유 방식 비교

정리하면 이렇다. 혼자 계산할 땐 파이썬, 함께 쓸 툴을 만들 땐 자바스크립트. 실무에서 우리가 원하는 건 대부분 후자다. 내가 만든 거더 검토 툴을 팀장님이 클릭 한 번으로 열어볼 수 있어야 그 툴이 의미를 가진다.

---

Three.js: 브라우저 위에서 가볍게 돌아가는 나만의 3D 뷰어

자바스크립트가 '공유'의 문제를 해결한다면, Three.js는 '시각화'의 문제를 해결한다.

Three.js는 브라우저에서 3D 그래픽을 그려주는 라이브러리다. 게임이나 화려한 웹사이트에 주로 쓰이지만, 구조 엔지니어 입장에서 보면 이건 "코드로 만드는 3D 모델러"다.

무거운 모델 대신, 가벼운 코드

상용 BIM 툴의 모델이 무거운 이유는 범용성 때문이다. 건축물이든 플랜트든 모든 것을 표현하려다 보니 객체 하나에도 수많은 속성이 붙는다.

하지만 우리가 실무에서 보고 싶은 건 생각보다 단순하다. 거더의 배치, 단면 형상, 가로보 위치, 철근의 간격. 이런 건 사실 몇 개의 숫자로 정의된다. 그 숫자로 형상을 직접 생성하면 모델은 수백 메가바이트가 아니라 수십 킬로바이트의 코드가 된다. 거더 하나를 그리는 데 필요한 코드는 이 정도다.

// 길이 30m, 높이 2.0m, 폭 0.6m 거더
const geometry = new THREE.BoxGeometry(30, 2.0, 0.6);
const material = new THREE.MeshStandardMaterial({ color: 0x8899aa });
const girder = new THREE.Mesh(geometry, material);
scene.add(girder);

여기에 반복문 하나만 씌우면 거더 여러 개가 간격에 맞춰 배치되고, 입력값을 바꾸면 모델이 즉시 다시 그려진다. 말로 설명하는 것보다 직접 보는 게 빠르다. 아래는 실제로 Three.js로 그린 강합성 거더교다. 슬라이더를 움직여 보고, 마우스로 드래그해서 돌려보자.

 

지간 (m)30

거더 수5

가로보 간격 (m)6

바닥판 표시

주거더 강재 중량
-

가로보 개수
-

바닥판 콘크리트
-

드래그해서 회전 · 물량은 데모용 개략 추정값

지간이 바뀌어도, 거더 개수가 바뀌어도 다시 모델링할 필요가 없다. 숫자 하나를 바꾸면 모델이 다시 그려지고, 아래 물량도 같이 바뀐다. 모델이 '파일'이 아니라 '파라미터의 결과'가 되는 것이다. 그리고 이 데모 전체가 설치 없이 지금 이 블로그 화면 안에서 돌아가고 있다는 점도 눈여겨보자.

내 입맛대로 만드는 기술적 자유도

상용 툴의 가장 큰 한계는 "그 툴이 허락하는 방식"으로만 작업해야 한다는 점이다. 우리 회사의 특수한 합성거더 형식, 독특한 철근 배근 패턴은 기본 패밀리로 표현이 안 되고, 플러그인을 사거나 복잡한 API를 공부해야 한다.

Three.js로 직접 만들면 이야기가 달라진다. SBarch 같은 특수 합성거더의 단면을 그대로 형상화할 수 있고, 철근 하나하나를 정확한 좌표에 배치해 겹침이음 구간을 색으로 구분할 수 있다. 간섭이 생기는 부위만 빨간색으로 강조하거나, 시공 단계별로 부재가 하나씩 나타나는 애니메이션도 만들 수 있다.

외부 플러그인의 업데이트를 기다릴 필요도, 라이선스 비용을 걱정할 필요도 없다. 내 실무에 필요한 기능을, 필요한 만큼만 만들면 된다.

---

단순 스크립트를 넘어, 'Web BIM 솔루션'으로의 진화

여기까지 오면 "그래서 3D로 예쁘게 보여주는 것 말고 뭐가 좋은데?"라는 질문이 남는다. 진짜 가치는 도구들을 연결했을 때 나온다.

• JavaScript — 입력, 계산 로직, 전체 흐름을 담당하는 뼈대
• Three.js — 계산 결과를 3D 형상으로 보여주는 눈
• ExcelJS — 결과를 실무 양식의 엑셀 파일로 내보내는 손

기존 실무 흐름은 계산서(엑셀) → 도면(CAD) → 모델링(BIM 툴) → 물량 산출(엑셀)로 각 단계가 따로 논다. 단면 하나가 바뀌면 네 군데를 모두 고쳐야 하고, 그 과정에서 반드시 불일치가 생긴다. 웹 기반으로 묶으면 흐름이 이렇게 바뀐다.

JavaScript Three.js ExcelJS 웹 BIM 파이프라인

모델과 계산서가 같은 데이터에서 나오기 때문에 불일치가 원천적으로 생기지 않는다. 위의 거더교 데모에서 슬라이더를 움직일 때 물량이 함께 바뀌었던 것, 그게 바로 이 파이프라인의 축소판이다. 여기에 ExcelJS 버튼 하나만 붙이면 그 물량이 실무 양식의 엑셀로 떨어진다.

3D 모델에서 특정 거더를 클릭하면 해당 부재의 단면 정보와 철근 물량이 팝업으로 뜨고, 그 자리에서 "이 부재 계산서 다운로드"를 누르는 장면을 상상해 보자. 이게 거창한 소프트웨어 회사의 제품이 아니라 엔지니어 한 명이 브라우저 위에 직접 만든 도구일 수 있다는 게 이 접근의 핵심이다. 제가 개발 중인 MacroBIM도 바로 이 방향을 지향하고 있다.

---

엔지니어링의 무기를 바꾸다

오해하지 말았으면 하는 게 있다. 이 글은 "토목 엔지니어도 개발자가 되어야 한다"는 이야기가 아니다.

우리는 여전히 구조 엔지니어다. 하중을 이해하고, 부재를 검토하고, 안전한 구조물을 설계하는 게 본업이다. 코딩은 그 본업을 대체하는 게 아니라 본업을 더 잘하게 해주는 무기일 뿐이다.

선배 엔지니어들이 계산자에서 계산기로, 계산기에서 엑셀로 무기를 바꿔왔듯, 지금은 엑셀에서 한 단계 더 나아갈 때다. 엑셀 매크로를 처음 배웠을 때를 떠올려 보자. 처음엔 어려웠지만, 반복 작업 하나를 자동화하고 나서 느꼈던 그 해방감이 있었을 것이다. 자바스크립트와 Three.js는 그 해방감을 3D와 공유의 영역까지 넓혀준다.

거창하게 시작할 필요 없다. 오늘은 거더 하나를 브라우저에 띄워보는 것, 그거면 충분하다.