에이전트가 STEP 파일을 건넬 수 있다: text-to-cad와 코드를 형상으로 쓰는 요령

한 번도 텍스트였던 적이 없는 부분

코딩 에이전트가 소프트웨어를 쓰는 건 소프트웨어가 텍스트이기 때문이다. 이 한 가지 사실이 이들이 잘하는 거의 모든 것을 설명한다. 기계 쪽 일에서 계속 쓸모가 없었던 이유도 설명해 준다. 브래킷은 텍스트가 아니고, 벽 두께도 텍스트가 아니고, STEP 파일은 절대 텍스트가 아니다. 기술적으로는 텍스트지만.

text-to-cad는 earthtojake가 만든 MIT 라이선스 플러그인으로, 이번 달 내내 GitHub 트렌드에 18,600 stars 근처로 올라 있었다. 이 모순을 오래된 수법으로 푼다. 텍스트가 아니라면, 그 물건의 텍스트 표현을 만들면 된다. 여기서는 파라메트릭 Python 스크립트다.

에이전트의 일은 3D 모델을 상상하는 게 아니다. 지오메트리 커널이 실행할 수 있는 코드를 쓰는 것이다. 그 차이가 제품 전부다.

루프는 실제로 어떻게 도나

밑에 깔린 엔진은 cadgen이고, PyPI의 Python 패키지이며 build123d 위에 올라가고, build123d가 다시 Open CASCADE를 돌린다. 진짜 CAD 도구들이 쓰는 것과 같은 계열의 지오메트리 커널이다. 모델은 그냥 Python 스크립트다. step 정의 데코레이터가 붙고 shape를 반환하는 함수.

3mm 벽 두께에 M3 구멍 두 개가 있는 카메라 마운트를 원한다고 하자. 말로 설명한다. 에이전트가 벽 두께, 구멍 지름, 구멍 간격을 파라미터로 하는 스크립트를 쓴다. cadgen이 그걸 돌려 STEP을 쓰고, 요청하면 STL, 3MF, GLB도 쓴다. 구멍 위치를 바꾸고 싶으면 숫자 하나를 고치고 다시 돌린다. 모델 소스는 저장소에 남아 다른 코드 옆에 놓인다. 즉 다른 것들처럼 diff하고 리뷰하고 되돌릴 수 있다.

정확한 지오메트리와 그럴듯한 메시의 차이다. 메시 생성기는 브래킷처럼 보이는 표면을 만든다. 솔리드 모델러는 벽 두께가 알려진 브래킷을 만든다. 가공 업체는 STEP 파일은 받아 주지만, 삼각형 4,000개로 된 곡면 STL은 정중히 거절한다.

플러그인은 설계가 실제가 되는지를 결정하는 지루한 부분도 맡는다. 제조를 위한 설계와 적층 제조를 위한 설계 검사를 돌린다. 벽 두께, 오버행, 드래프트 각, 언더컷. 그리고 각 지적마다 그 뒤에 있는 규칙을 함께 내놓는다. 경고 한 줄만 던지지 않는다. 뷰, 숨은선, 구멍 콜아웃, 표제란이 있는 치수 기입 도면을 PDF로 만든다. 레이저 커팅용 DXF 프로파일을 쓰고, OrcaSlicer로 G-code를 슬라이스하고, Bambu Lab 기계로 프린트를 보내고, SendCutSend용 업로드 전 검사를 돌리고, 로봇 기술과 시뮬레이터 월드용 URDF, SRDF, SDF 파일을 쓴다.

로컬 뷰어도 있다. 지원하는 앱에서는 모델이 채팅 안 카드로 뜨고, 아니면 localhost 링크를 받는다.

왜 일반화되는가

CAD 유즈케이스는 구체적이지만 패턴은 구체적이지 않다. 두 가지 속성을 가진 영역은 코딩 에이전트에 맡길 수 있다. 산출물의 코드 표현, 그리고 그 산출물이 유효한지 말해 주는 검사기.

기계 부품은 둘 다 있다. 스크립트가 표현이고 제조성 검사가 검증기다. 웹 페이지도 둘 다 있다. HTML과 브라우저. 인프라도 둘 다 있다. 설정과 plan. 비디오는 얼마 전까지 둘 다 없었다. 적어도 에이전트가 실행할 수 있는 형태로는. HyperFrames 같은 프로젝트가 메우는 구멍이 정확히 그것이다.

검사기가 없는 영역에서 에이전트는 자신감 넘치는 쓰레기를 만든다. 'AI for 3D'가 프리뷰 단계에 머문 이유다. "의자처럼 보인다"와 "제조할 수 있다" 사이에 검증기가 없었다.

패턴의 나머지 절반은 로컬 실행이다. cadgen은 당신 기계에서 진짜 지오메트리 커널을 상대로 돈다. 지오메트리 단계에서 신경망이 근사하는 것은 없다. 에이전트가 파라메트릭 의도를 내고, 커널이 진실을 낸다.

도입 비용, 이건 진짜다

두 가지가 사람을 물 것이다. 둘 다 저장소에 적혀 있다. 아프게 겪고 나서 알게 되는 게 아니라. 저자들에게 점수를 줘야 할 부분이다.

Windows 11에는 전용 함정이 있다. CAD 커널의 Python 바인딩은 서명되지 않은 네이티브 모듈을 함께 배포하고, 새로 설치하면 기본으로 켜져 있는 Windows 11의 Smart App Control이 그걸 막는다. 그러면 모든 명령이 DLL 로드 오류로 실패한다. 앱별 예외는 없다. 선택지는 Smart App Control을 끄거나(일부 시스템에서는 Windows를 다시 설치해야만 되돌릴 수 있다), WSL 아래에서 CAD 스킬을 돌리는 것. 이 경우를 감지하는 doctor 명령이 있어서 적어도 빨리 알 수 있다.

텔레메트리는 기본으로 켜져 있다. README가 유난히 자세히 적어 두었고, 그 직감은 맞다. 보내는 것: 버전, 설치 경로, 운영체제, 어떤 에이전트 앱을 쓰는지, 그리고 각 도구가 몇 번 호출됐는지, 모델을 몇 개 만들었는지 같은 카운트, 실패 이유는 오류 텍스트가 아니라 고정 목록에서 고른 것. 크래시 리포트에는 오류 유형과 코드의 어디서 실패했는지가 들어간다. 모든 것에 무작위 설치 ID가 붙고 PostHog에 저장된다. 서버는 IP로 국가를 추론하고 주소는 보관하지 않는다. 절대 보내지 않는 것: 파일 이름, 경로, 파일 내용, 프롬프트. 명령 하나로 끌 수 있고, 이미 보낸 것도 삭제된다. CI나 개발용 설치에서는 아무것도 보내지 않는다.

둘 다 젊은 프로젝트에서는 흔한 일이고, 둘 다 도입을 갉아먹는다. 상용 CAD 벤더라면 둘 다 내놓지 않을 것이다.

이게 맞지 않는 곳

유기적 형상. 캐릭터, 피규어, 조각 같은 형태. 형상 자체가 목적이고 기능이 목적이 아닌 모든 것은 메시 생성 영역이고, 메시 기반 image-to-3D 모델이 더 나은 도구다. 용을 파라미터로 설명하려는 건 끔찍한 오후가 된다.

엔지니어링 사인오프를 대신하지도 않는다. DFM 스킬은 안내된 리뷰지 인증이 아니다. 사람 몸무게를 버텨야 하는 부품이라면 여전히 사람 엔지니어가 도면에 서명한다. 루프는 누군가 청구서를 지불하는 데서 끝나고, 사람이 있을 자리는 아마 거기다.

저장소 자체는 젊고 빠르다. 2026년 4월에 만들어졌고, 1,400 commits 이상, PyPI 패키지는 수십 개 릴리스, 10월 초에는 이틀 안에 세 버전이 나왔다. 이 속도는 새 스킬을 좋아하면 장점이고, 안정성이 필요하면 위험이다.

README에 있는, 중요한 그 문장

설명문에 그냥 지나치기 쉬운 주장이 박혀 있다. 이 플러그인은 당신의 에이전트에게 진짜 CAD 워크플로를 준다. 데모도, 프롬프트 래퍼도 아니고, 표현과 실행기와 검증기, 그리고 제작 업체로의 인계를 갖춘 워크플로.

이게 에이전트를 소프트웨어 밖에서 쓸모 있게 만드는 물건의 모양이다. 브래킷을 아는 모델이 아니라, 모델이 실행 가능한 무언가를 쓰고, 다른 무언가가 그것을 검사하고, 출력이 다른 시스템이 받아들이는 파일이 되는 루프. 에이전트가 CAD를 잘할 필요는 없다. 코드를 잘하면 되고, 그 영역에 컴파일러가 있으면 된다.

기계공학이 먼저 도착한 건 컴파일러가 오십 년 된 물건이고 검증기가 제조 규칙 묶음이었기 때문이다. 이 두 조각을 갖추는 다른 모든 영역은 1년 안에 이런 모습이 될 것이다.