text-to-cad: AI 에이전트에 파라메트릭 CAD 능력을 부여하다

배경 및 문제 정의

기계 설계는 여전히 그래픽 인터페이스에 의존한다. 엔지니어는 CAD 프로그램을 열고, 스케치를 그리고, 구속 조건을 주고, 돌출을 적용한 뒤, STEP 파일을 가공 현장에 넘긴다. 언어 모델은 Python을 작성하고 사양서를 읽을 수 있지만, 이 GUI 작업 순서를 그대로 따라 하기는 어렵다. 실질적인 질문은 분명하다. 에이전트가 자연어 요구나 부품 사진을 다른 사람이 검토하고, 수정하고, 제조할 수 있는 3차원 모델로 바꿀 수 있는가.

text-to-cad는 명확한 설계 선택으로 이 질문에 답한다. 모델 자체가 소스 코드다. 부품은 build123d로 작성한 Python 파일이며, build123d는 OpenCascade 커널 위에서 동작하는 Python CAD 라이브러리다. 파일을 실행하면 결과물이 만들어진다. 주된 출력은 STEP 파일이고, 소스는 설계 의도를 기록한다. 덕분에 형상도 차이를 비교하고, 리뷰하고, 다시 생성할 수 있는 대상이 된다.

어려운 부분은 생성이 아니라 검증이다. 모델은 뷰어에서 맞아 보여도 구멍의 위치가 틀릴 수 있다. 그래서 이 저장소는 측정, 스냅샷 리뷰, 검증을 부가 기능이 아닌 독립된 스킬로 다룬다.

핵심 아키텍처와 기술 원리

text-to-cad는 단일 프로그램이 아니라 에이전트용 스킬 라이브러리다. CAD, step.parts, 공학 도면, DXF, URDF, SRDF, SDF, SendCutSend, DfAM 검사, DFM, G-code, Bambu Labs까지 12개 스킬을 담고 있다. 중심은 CAD 스킬이며, 다른 스킬 대부분은 그 출력을 사용하거나 같은 부품을 다른 도구용으로 기술한다. 버전 고정이 명시적이다. 스킬의 requirements.txt는 cadgen[snapshot]을 0.7.11로 고정한다. README 배지는 build123d 0.11, Open CASCADE 7.9, Python 3.11 이상, Node.js 20 이상을 보여 준다. 따라서 에이전트는 특정 커널과 실행 환경에 의존한다. 고정은 팀이 과거 릴리스를 재현할 수 있게 해 주지만, 업그레이드는 수작업이 된다는 대가가 있다.

기술 스택은 세 계층으로 보면 이해하기 쉽다. 맨 위에서는 에이전트가 SKILL.md를 읽고, 작업 유형에 따라 짧은 참조 문서로 이동한다. 가운데에서는 cadgen 명령줄 도구와 MCP 서버가 실행을 맡는다. MCP 서버는 uvx로 시작하므로 첫 실행 때 런타임을 내려받는다. 가장 아래에서는 OCP 바인딩이 OpenCascade를 Python에 노출하며, 형상 연산과 STEP 읽기·쓰기를 수행한다. 설계 원칙은 소스 파일이 진실이라는 것이다. SKILL.md는 내보낸 파일을 고치는 대신 모델 소스를 편집하고 python으로 다시 실행하라고 안내한다. 따라서 변경은 Python 파일의 차이로 나타나고, 메시나 STEP은 파생된 결과물이 된다. 이는 코드를 리뷰 가능하게 만드는 원리와 같으며, 버전 관리와도 잘 맞는다. 배포도 같은 논리를 따른다. Codex, Claude Code, Cursor, Grok Build용 플러그인이 있고, 스킬은 npx skills add로 설치한다. 호스트마다 모델을 보여 주는 방식은 다르지만, 모두 같은 cadgen 패키지를 호출한다.

실용성 및 검증 결과

나는 이 도구를 설치하지 않았고, 이것으로 모델을 생성해 보지도 않았다. 이 절의 내용은 저장소의 문서, 설정, 코드 구조에서 읽어 낸 것이다. 따라서 여기서 다루는 것은 출력에 대한 측정이 아니라 설계에 대한 해석이다. CAD 스킬은 네 가지 기능을 명시한다. 장식된 Python 모델로 부품과 조립체를 만들고 편집한다. 메시 데코레이터나 일회성 build 명령으로 STL, 3MF, GLB를 내보낸다. read_scene과 scene.resolve로 저장된 STEP 문서의 이름 붙은 참조를 찾는다. Chromium을 사용해 외관과 움직임을 검토하는 스냅샷을 그린다. 실무에서는 네 기능을 모두 쓰는 흐름이 합리적이다. 모델 생성, 내보내기, build123d 네이티브 스크립트로 치수 확인, 출시 전 스냅샷 점검 순서다.

문서에는 실서비스에서 중요한 경고가 두 가지 있다. 첫째, 버전 마이그레이션이 필요한 모델을 마이그레이션하지 않으면 운동학, 재질, 애니메이션 정보가 조용히 사라진다. 충돌보다 조용한 실패가 더 위험하므로, 팀은 마이그레이션을 파이프라인의 명시적 단계로 만들어야 한다. 둘째, 스마트 앱 컨트롤이 켜진 Windows 11에서는 서명되지 않은 OCP 휠이 차단되어 DLL 오류로 가져오기가 실패한다. 저장소의 답은 이 기능을 끄거나 WSL에서 실행하는 것이다. Windows 전용 워크스테이션을 쓰는 팀은 배포 전에 반드시 시험해야 한다. 도입 시 고려할 실무 사항이 두 가지 더 있다. 분석 기능은 사용자가 허용하기 전까지 꺼져 있고, DO_NOT_TRACK 변수로도 끌 수 있다. 플러그인 설치는 첫 실행 때 uv를 통해 로컬 런타임을 내려받는다. 둘 다 결함은 아니지만 조직의 설치 체크리스트에 포함해야 한다. 현실적인 도입 계획은 다섯 부분으로 구성된다. 생성된 Python을 git으로 관리한다. cadgen 버전을 고정하고 기록한다. cadgen doctor를 환경 점검으로 실행한다. 핵심 치수마다 단언문 스크립트를 하나씩 작성한다. 스냅샷은 적합성 증명이 아니라 검토 보조 도구로 취급한다.

업계 영향과 전망

이 프로젝트는 완성된 제품이라기보다 방향을 보여 준다. CAD는 코드, 테스트, 버전 관리로 제약할 수 있는 공학 자산이 되고 있다. 이미 Python을 쓰는 소규모 하드웨어 팀, 로봇 그룹, 메이커에게는 파라메트릭 설계의 진입 장벽이 낮아진다. 책임의 위치도 바뀐다. 모델 생성기가 그럴듯한 치수를 내놓으면, 위험은 부품을 그린 사람에서 그것을 검사하는 절차로 옮겨 간다. 이 방식을 채택하는 팀은 제조 전에 측정 관문을 두어야 한다. DFM, DfAM 검사, SendCutSend 스킬은 형상을 믿기보다 제조 규칙에 비추어 검사한다는 방향을 보여 준다.

로봇 기술 스킬은 두 번째 질문을 낳는다. 형식 간 일관성이다. URDF, SRDF, SDF는 서로 다른 소비자를 위해 같은 로봇을 기술한다. CAD 형상, 관절 한계, 시뮬레이터 모델을 계속 일치시키는 일은 아직 풀리지 않은 공학 과제다. 하나의 스킬 라이브러리로 묶은 구조는 옳지만, 일관성 확인은 여전히 사용자의 몫이다. 이번 스냅샷 기준 스타 16,697개는 높은 관심을 보여 준다. 그러나 관심은 검증이 아니다. 유용한 근거는 실제 프로젝트의 재작업률, 검사 통과율, 납기 실측치다. 이 분석에는 그런 데이터가 없다. 독자는 이 프로젝트를 검증이 필요한 유망한 인터페이스로 보는 것이 맞다. CAD 워크스테이션을 대체할 만큼 입증된 수단이라는 근거는 아직 없다.