코드로 3D 모델을 정의하는 방식은 AI 에이전트가 사람 없이 부품을 설계하도록 맡기기에 자연스러운 선택지다. 플랫폼 전반에서 OpenSCAD 코드를 생성해 온 ModelRift가, 코드 기반 CAD의 가장 유력한 대안인 CadQuery와 통제된 비교를 진행했다. CadQuery는 OpenCascade의 B-rep 커널 위에 올라간 파이썬 라이브러리다. 질문은 좁고 분명했다. 손으로 짜기에 어느 쪽이 더 편한가가 아니라, 아무도 지켜보지 않는 상태에서 에이전트가 정확하고 출력 가능하며 기능하는 부품까지 끌고 갈 수 있는 쪽은 어디인가였다.
실험은 6개의 에이전트에게 동일한 세 가지 부품 과제를 던지고, 세 개는 CadQuery로 세 개는 OpenSCAD로 만들게 하는 방식이었다. 모든 실행은 Claude Code를 통한 Claude Opus 5(1M 컨텍스트)가 담당했고, 각 셀은 상호 간섭 없는 별도의 서브에이전트로 돌아갔다. 도구 버전은 CadQuery 2.8.0(Python 3.14)과 OpenSCAD 2026.06.12였다. 에이전트는 최대 12개 버전까지만 반복할 수 있었고, 성공을 조작하지 말 것과 모든 실패를 원문 오류 메시지 그대로 보고할 것을 요구받았다. 핵심은 결과물을 도구의 자기 보고에 맡기지 않았다는 점이다. 최종 STL은 삼각형 수, 경계 상자, 부피, 수밀성, 비다양체·경계 에지, 뒤집힌 면, 연결 요소 수를 파일에서 직접 읽어내는 독립 파서로 재검증됐다.
능력은 지루한 결론이었다
결과부터 말하면 여섯 부품 모두 출력 가능한 상태로 나왔다. 반복 횟수도 양쪽 모두 11개 버전으로 동일했다. 능력 자체는 승부처가 아니었다는 뜻이다. 두 도구가 갈라진 지점은 '어떻게 실패하는가'였다.
가장 단순한 T1 벽걸이 L자 브래킷에서 이 차이가 선명하게 드러났다. OpenSCAD는 2D 프로파일을 둥글린 뒤 압출하는 방식이라 첫 시도에 올바른 형상을 컴파일하고 두 버전 만에 끝냈다. 반면 CadQuery는 네 모서리를 먼저 지정해야 했고, .fillet(3.0)이 에지도 반지름도 지목하지 않는 'BRep_API: command not done' 오류로 실패해 전체 실행의 3분의 1을 여기에 소진했다. 원인은 결국 산술 문제였다. 4mm 벽에 R3 필렛 두 개가 물리적으로 들어가지 않았던 것이다.
T2 스냅핏 케이스에서는 반대로 CadQuery의 강점이 나왔다. 모든 치수가 별도로 입력되지 않고 서로 파생되는 파라미터 체인 덕분에 립 깊이 하나를 바꾸면 림·플레이트·슬롯·홈이 함께 움직였다. 더 중요한 것은 검증 방식이었다. OpenSCAD는 사람이 읽어야 의미가 생기는 숫자를 출력하는 반면, CadQuery는 assert로 조건이 어긋나면 빌드 자체를 멈춘다. 지켜보는 사람이 없는 자동 생성 환경에서 이 격차가 사실상 승부의 대부분을 갈랐다.
조용한 성공이 더 비싼 실패다
가장 어려운 T3 나사 호스 어댑터에서 예상 밖의 반전이 나왔다. OpenSCAD는 라이브러리 없이, 스윕 연산이 없는 상태에서 나선을 정점·면 산술로 직접 계산해 단일 폴리헤드론으로 뽑아냈고 첫 컴파일에 43ms 만에 완성했다. 반면 CadQuery는 여섯 줄의 깔끔한 코드로 같은 형상을 표현했지만, 마지막 union()이 나사 뿌리가 코어 반지름에 정확히 접하면서 코어 실린더를 소리 없이 삭제했다. 겉보기엔 완벽했고 에이전트는 네 장의 렌더를 이상 없이 넘겼다. 이를 잡아낸 것은 부피 측정이었다. 기대치 10323㎣ 대신 7065㎣가 나온 것이다. 더 심각하게도 깨진 부품은 valid=True, solids=1로 보고됐고, 허용 오차를 1e-3으로 올리자 부피가 음수인 solid가 나오면서도 여전히 valid=True를 반환했다.
OpenSCAD도 결백하지 않았다. T2에서 Manifold 백엔드는 비다양체 에지 4개와 면적 0 삼각형 60개를 담은 STL을 두고 오류 없음을 인증했다. 어느 도구의 자기 보고도 최종 판단이 될 수 없다는 것, 그래서 모든 메시를 직접 파싱해야 했다는 결론이 여기서 나온다.
실무에 남는 것
이번 비교의 실질적 교훈은 표현력이 아니라 검증 가능성에 있다. CadQuery는 커널에 '방금 만든 것'을 되물을 수 있고 그 답에 assert를 걸 수 있다. 에이전트 루프에서는 이 능력이 편리한 문법보다 값지다. CadQuery는 시끄럽게 일찍 실패한다. 메시지는 빈약해도 예외가 실행을 멈추므로 잘못된 모델이 우연히 출고될 수 없다. OpenSCAD는 조용히 늦게 실패한다. 약 45번의 호출 동안 오류도 경고도 없이 삭제된 포스트와 어긋난 슬롯, 방금 정상으로 인증한 손상된 출력물을 만들어냈다. 반대로 OpenSCAD 진영은 기하 질의 수단이 없어 두 에이전트 모두 모델 코드에 맞먹는 분량의 바이너리 STL 파서를 직접 작성해 결과를 측정해야 했다.
다만 결과를 일반화하기 전에 짚을 한계가 있다. 셀당 에이전트가 하나뿐이라 편차의 일부는 도구 차이가 아니라 에이전트 변동일 수 있다. BOSL2 같은 라이브러리는 의도적으로 배제됐는데, 라이브러리를 쓴 OpenSCAD 실행이라면 T2와 T3 결과가 상당히 달라졌을 가능성이 있다. 또한 모든 실행은 윤곽선 렌더러 개선 이전에 이뤄져 시각 채널 조건이 균일하지 않았다. 그럼에도 실무자가 가져갈 원칙은 분명하다. 생성 파이프라인이 스크린샷에 의존한다면 이번에 아무것도 잡지 못한 채널에 기대는 셈이다. 벽 두께, 클리어런스, 간섭 부피, 오버행 각도 같은 수치 단언을 강제하고, 프리뷰와 출력용 메시는 별개라는 전제 아래 내보낸 메시를 반드시 독립적으로 재검사해야 한다.