- Published on
프롬프트로 3D CAD를 만든다는 것 — 메시와 B-rep, 그리고 제약 조건이라는 병목
- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 들어가며 — Show GN에 올라온 CAID, 그리고 "제조에 쓰지 말라"는 자백
- 메시와 B-rep은 다른 물건이다
- 파라메트릭이라는 말의 진짜 의미 — 피처 트리와 제약 solver
- 현재 도구들이 실제로 하는 일
- 벤치마크가 말하는 한계
- 오늘 실제로 쓸모 있는 자리
- 엔지니어가 여전히 필요한 자리 — 공차, DFM, 가공성
- 마치며 — 메시를 만드는 일과 부품을 만드는 일 사이의 거리
들어가며 — Show GN에 올라온 CAID, 그리고 "제조에 쓰지 말라"는 자백
GeekNews Show GN에 프롬프트로 3D CAD 모델을 생성하는 툴 CAID가 올라왔습니다. 만든 사람의 문제의식은 명확합니다 — 머릿속에 있는 형상과 메커니즘을 표현하려면 CAD 툴의 기능을 익히고 수백 번 클릭해야 하는 것이 하드웨어 설계의 병목이라는 것.
동작 방식도 간명합니다. 자연어로 원하는 형상을 입력하면 LLM이 코드를 생성하고, 3D 모델이 렌더링되며, 파라미터를 조정할 수 있습니다. STEP과 STL로 내보냅니다. 플랜지, L-브래킷, 히트싱크 세 종류는 미리 검증된 템플릿이라 LLM을 거치지 않고, 자유 프롬프트만 AI 경로를 탑니다.
흥미로운 것은 만든 사람이 스스로 밝힌 한계입니다. 치수를 자동으로 검증하지 못하고, 제조 가능성 — 공차, DFM 제약, CNC와 밀링 관점의 가공성 — 을 판단하지 못하며, 검증된 프로토타입일 뿐 출력물을 제조에 바로 쓰면 안 된다는 것입니다.
이 자백이 이 분야 전체의 상태를 정확하게 요약합니다. 그리고 왜 그런지는 CAD가 어떤 자료구조인지를 보면 바로 드러납니다.
메시와 B-rep은 다른 물건이다
"3D 모델을 생성했다"는 문장은 두 개의 전혀 다른 결과를 가리킬 수 있습니다.
메시는 삼각형의 목록입니다. 꼭짓점 좌표와 삼각형의 인덱스, 그게 전부입니다. 곡면은 존재하지 않고 다각형으로 근사됩니다. 지름 20밀리미터 원통은 실제로는 서른두 개쯤의 평면이고, 진짜 원통이 아닙니다. 텍스트에서 메시를 생성하는 것은 지금 잘 됩니다 — 확산 모델과 3D 생성 모델이 몇십 초 만에 만들어 냅니다.
B-rep은 위상 그래프입니다. 면이 있고, 면은 해석적 곡면(평면, 원기둥, 원환, NURBS)에 놓여 있으며, 면끼리 모서리로 만나고, 모서리는 꼭짓점에서 만납니다. 지름 20밀리미터 원통은 반지름 10이라는 파라미터를 가진 원기둥면 하나입니다. STEP 파일이 담는 것이 이것이고, 기계 CAD가 다루는 것도 이것입니다.
차이가 실무에서 어떻게 나타나는지 보겠습니다.
# 같은 브래킷을 두 방식으로 표현했을 때
메시(STL):
vertex 12.000 0.000 5.000
vertex 11.951 1.111 5.000
... (구멍 하나가 삼각형 64개로 근사됨)
-> "이 구멍의 지름은?" 대답 불가. 점 집합에서 역추정해야 함.
-> "지름을 8에서 10으로" 전체 재생성 필요.
-> 드릴 가공 지시 생성 불가. 구멍이라는 개념 자체가 없음.
B-rep(STEP):
CYLINDRICAL_SURFACE('', axis_placement, 4.0)
-> "이 구멍의 지름은?" 8.0 밀리미터.
-> CAM 소프트웨어가 원통면을 인식해 드릴 사이클을 생성.
-> 다만 STEP은 결과 형상만 담는다. 어떻게 만들었는지는 없다.
마지막 줄이 중요합니다. STEP은 B-rep을 담지만 피처 트리는 담지 않습니다. 그래서 "STEP으로 내보내니 어떤 CAD에서도 편집할 수 있다"는 말은 절반만 참입니다. 면을 밀고 당기는 직접 편집은 됩니다. 하지만 "이 브래킷의 두께 파라미터를 5에서 8로 바꾸고 나머지를 자동으로 맞춰라"는 안 됩니다. 그 관계가 파일에 없기 때문입니다.
파라메트릭이라는 말의 진짜 의미 — 피처 트리와 제약 solver
기계 CAD가 파라메트릭이라고 할 때 뜻하는 것은 두 층입니다.
첫째 층은 스케치 안의 제약입니다. 2D 스케치에 선과 원을 그리고 나서 평행, 수직, 접함, 동심, 대칭 같은 기하 조건과 치수를 겁니다. 이 조건들은 연립방정식이 되고, 기하 제약 solver가 이를 풉니다. 사용자가 치수 하나를 바꾸면 solver가 다시 돌아 나머지 요소의 위치를 재계산합니다.
둘째 층은 피처 트리입니다. 스케치를 돌출하고, 그 결과에 구멍을 뚫고, 모서리에 필렛을 넣는 순서가 기록됩니다. 파라미터가 바뀌면 이 순서를 처음부터 재생(replay)합니다.
여기서 LLM 기반 생성이 부딪히는 벽이 세 가지입니다.
제약 solver는 만족 가능성 문제입니다. 조건을 너무 적게 걸면 형상이 자유도를 남긴 채 떠 있고(under-constrained), 너무 많이 걸면 서로 모순되어 풀리지 않습니다(over-constrained). 사람도 여기서 자주 막힙니다. 모델이 자연어에서 이 균형을 맞춘 제약 집합을 뽑아내는 것은 형상을 그리는 것과는 완전히 다른 종류의 작업입니다. 그리고 실패가 조용합니다 — solver가 풀리기는 하는데 의도와 다른 해를 고르는 경우가 흔합니다.
피처 재생은 깨지기 쉽습니다. 필렛은 특정 모서리를 참조하는데, 앞 단계의 파라미터가 바뀌어 그 모서리가 사라지거나 갈라지면 필렛이 실패합니다. CAD 업계에서 오래된 문제이고 고유 이름까지 있습니다. LLM이 생성한 트리는 이 취약성을 고려하지 않으므로, 파라미터를 조금만 바꿔도 재생이 무너지는 모델이 나오기 쉽습니다.
공간 추론이 약합니다. Hacker News에 올라온 Text-to-CAD 논의에서 이 지적이 반복됩니다. 어떤 사람은 L-브래킷 벤치마크에서 보강 리브가 구멍을 덮어 버리는 것을 지적하며 위치 계산이 제대로 되는지 의심합니다. 다른 사람은 정확히 원하는 형상을 서술하는 데 드는 노력이 손으로 CAD를 그리는 것과 맞먹어서 효율 논거가 무너진다고 지적합니다. 그리고 파라메트릭 피처 트리 안의 제약 풀이 복잡성은 사실상 손대지 못한 채 남아 있다는 것이 그 스레드의 공통된 결론입니다.
현재 도구들이 실제로 하는 일
지금 이 공간에 있는 접근법을 정리하면 이렇습니다.
| 도구·접근 | 입력 | 출력 | 편집 가능성 | 공개된 한계 |
|---|---|---|---|---|
| CAID (Show GN) | 자연어 프롬프트 | STEP, STL. LLM이 코드를 생성하고 렌더링 | 파라미터 조정 가능 | 치수 자동 검증 없음. 공차·DFM·가공성 판단 불가. 제조 직접 사용 금지 |
| text-to-cad (오픈소스 하네스) | 코딩 에이전트의 프롬프트 | build123d 코드에서 STEP, STL | 코드가 곧 피처 정의라 버전 관리 가능 | 공간 추론 오류(리브가 구멍과 겹침). 복잡한 어셈블리에서 토큰 비용 과다 |
| Zoo Text-to-CAD | 자연어 프롬프트 | B-rep 곡면, STEP 등 다수 포맷 | STEP을 임포트해 기존 CAD에서 편집 | 명사가 아니라 피처 트리를 서술해야 결과가 좋다고 안내 |
| SGS-1 (Spectral Labs) | 이미지 또는 메시 | 편집 가능한 B-rep STEP | 파라메트릭 편집 지향 | 복잡 곡면, 유기적 구조, 매우 얇은 형상, 완전한 어셈블리 생성에 취약 |
| 메시 생성 모델 일반 | 텍스트 또는 이미지 | 삼각형 메시 | 사실상 불가 | 기계 CAD 용도로는 부적합. 시각화와 3D 프린팅 초안용 |
몇 가지 짚을 대목이 있습니다.
코드를 중간 표현으로 쓰는 접근이 현재로선 가장 견고합니다. text-to-cad 하네스는 build123d를 쓰고, 그 아래는 OpenCascade 커널입니다. LLM이 형상을 직접 생성하는 대신 파라메트릭 모델을 만드는 파이썬 코드를 씁니다. 이 구조의 장점은 명확합니다 — 코드가 곧 피처 트리이고, git으로 버전 관리되며, 파라미터가 변수이고, 실패하면 스택 트레이스가 나옵니다. 관측 가능성이 확보됩니다.
# 코드로서의 CAD가 견고한 이유: 의도가 텍스트로 남는다
from build123d import *
THICKNESS = 5.0
HOLE_D = 8.0
EDGE_MARGIN = HOLE_D * 0.75 # 구멍 가장자리 최소 살두께를 관계식으로 고정
with BuildPart() as bracket:
with BuildSketch() as base:
Rectangle(60, 40)
extrude(amount=THICKNESS)
with Locations((20, 0)):
Hole(radius=HOLE_D / 2)
fillet(bracket.edges().filter_by(Axis.Z), radius=3)
# 여기서 HOLE_D를 12로 바꾸면 EDGE_MARGIN이 따라 움직인다.
# 이 관계가 STEP 파일에는 남지 않는다. 코드에만 남는다.
이 예제가 동시에 문제도 보여 줍니다. fillet이 참조하는 모서리 집합은 필터로 선택되는데, 앞 단계 형상이 바뀌어 해당 모서리가 사라지면 조용히 다른 모서리에 적용되거나 실패합니다. 코드로 써도 피처 재생의 취약성은 그대로 남습니다.
SGS-1은 방향이 다릅니다. Spectral Labs가 2025년 9월에 공개한 이 모델은 구조화된 CAD(B-rep) 생성을 목표로 하는 첫 생성 모델을 표방합니다. 이미지나 메시를 입력받아 편집 가능한 STEP을 내놓으므로, 리버스 엔지니어링 자동화와 어셈블리 문맥 안의 신규 부품 생성이 주 용도입니다. 75장의 복잡한 CAD 이미지로 GPT-5와 HoLa BRep 대비 성공 비율에서 우위를 보였다고 밝혔습니다. 개발팀이 인정한 한계는 복잡 곡면, 유기적 구조, 매우 얇은 형상, 완전한 어셈블리입니다. Hacker News 반응에는 상당한 회의가 있었습니다 — 실제로 써 본 CAD 사용자들이 치수 오류, 실패한 구멍, 어긋난 피처를 보고하며 "쉽게 편집 가능"이라는 표현에 의문을 제기했습니다.
벤치마크가 말하는 한계
2026년 5월에 공개된 Text2CAD-Bench가 이 상태를 수치로 정리합니다. 600개의 큐레이션된 예제를 네 단계 복잡도(L1에서 L4)로 나누고, 각 예제에 두 스타일의 프롬프트를 붙였습니다 — 비전문가가 서술하듯 쓴 것과 전문가가 절차적으로 쓴 것. 이 이중 프롬프트 설계가 좋습니다. 사용자의 CAD 숙련도가 결과에 얼마나 영향을 주는지를 분리해서 볼 수 있으니까요.
결론은 예상 가능하되 유용합니다. 범용 LLM과 도메인 특화 모델 모두 기본 형상에서는 합리적으로 동작하지만 복잡한 위상과 고급 피처에서 성능이 급격히 떨어집니다. 즉 성능 곡선이 완만하게 내려가는 게 아니라 어느 지점에서 무너집니다.
이건 직관과도 맞습니다. 상자에 구멍을 뚫는 것은 프롬프트에서 파라미터 몇 개를 뽑는 문제입니다. 하지만 여러 피처가 서로를 참조하고, 곡면이 접선 연속으로 만나고, 얇은 벽이 붕괴하지 않아야 하는 형상은 제약 만족 문제이고, 그건 언어 모델링과 다른 종류의 계산입니다.
오늘 실제로 쓸모 있는 자리
비관적으로만 읽을 이유는 없습니다. 지금 확실히 값을 내는 용도가 있습니다.
첫 초안. 빈 화면에서 시작하는 대신 그럴듯한 형상 하나를 받아 놓고 고치는 것은 실제로 시간을 아낍니다. 특히 표준적인 부품 — 플랜지, 브래킷, 히트싱크, 하우징 — 은 형태의 변주 범위가 좁아서 생성 품질이 좋습니다. CAID가 이 세 종류를 미리 검증된 템플릿으로 둔 것도 같은 판단으로 보입니다.
부품 라이브러리 검색. "M8 볼트 4개가 들어가는 90도 각 브래킷"을 자연어로 넣어 기존 라이브러리에서 찾는 것은 생성보다 훨씬 쉽고 안전합니다. 검증된 부품을 재사용하니까요. 생성 모델의 진짜 값은 형상을 만드는 것보다 형상을 인덱싱하고 검색하는 데 있을 수 있습니다.
코드로서의 CAD와 에이전트 워크플로. 코딩 에이전트가 파라메트릭 CAD 코드를 쓰고, 렌더링된 이미지를 보고 스스로 고치는 루프가 실제로 작동합니다. text-to-cad 스레드의 사용자들이 단순 형상에서 이 반복 개선이 잘 된다고 보고합니다. 흥미로운 구현 세부가 하나 있는데, 이 하네스는 STEP 파일에 위상 사이드카를 만들어 모델이 파일 전체를 로드하지 않고도 B-rep 정보를 읽을 수 있게 합니다. 컨텍스트 예산 안에서 형상을 다루려는 시도입니다.
리버스 엔지니어링. 메시나 스캔 데이터를 B-rep으로 변환하는 작업은 원래도 반자동이었고 지루했습니다. SGS-1이 겨냥하는 자리입니다. 결과를 사람이 검수한다는 전제 아래, 백지에서 만드는 것보다 검증 부담이 작습니다.
공통점이 보입니다. 검증 비용이 낮거나, 사람이 즉시 눈으로 확인할 수 있거나, 실패해도 되돌리기 쉬운 자리에서 값이 납니다.
엔지니어가 여전히 필요한 자리 — 공차, DFM, 가공성
CAID 개발자가 정직하게 열거한 세 가지가 정확히 자동화되지 않은 영역입니다.
공차와 끼워맞춤. 구멍 지름 8밀리미터라는 숫자는 그 자체로는 아무 의미가 없습니다. 8H7인지 8H11인지, 축과 헐거운 끼워맞춤인지 억지 끼워맞춤인지에 따라 부품이 조립되거나 안 됩니다. 그리고 공차는 형상에서 도출되지 않습니다 — 기능적 의도에서 나옵니다. 이 축이 회전해야 하는지, 고정돼야 하는지, 열팽창을 흡수해야 하는지를 모델은 프롬프트에 없으면 알 수 없습니다. 여러 부품에 걸친 공차 누적 해석은 더 말할 것도 없습니다.
DFM. 사출 성형이면 빼기 구배와 균일한 살두께가 필요하고, 3축 밀링이면 공구가 닿지 않는 내부 코너와 언더컷이 문제가 되며, 판금이면 굽힘 반경과 최소 플랜지 길이가 제약입니다. 같은 형상이 공정에 따라 제조 가능하기도 하고 불가능하기도 합니다. 프롬프트에 공정이 명시돼도, 모델이 그 제약을 형상 생성 중에 만족시킨다는 보장이 없습니다.
가공성 검증. 공구 접근성, 셋업 횟수, 고정 방법 — 이건 형상만 보고는 판단할 수 없고 공장의 장비 목록을 알아야 합니다.
그리고 하나 더, 덜 언급되지만 중요한 것이 있습니다. 의도의 기록입니다. 잘 만들어진 CAD 모델은 형상만이 아니라 왜 그 형상인지를 담습니다. 어느 치수가 기능적으로 중요하고(그래서 공차가 빡빡하고), 어느 것이 임의로 정한 것인지. 이 정보가 있어야 6개월 뒤 다른 사람이 안전하게 수정할 수 있습니다. 생성된 모델은 모든 치수가 똑같이 임의적으로 보인다는 특성이 있고, 이건 유지보수 비용으로 돌아옵니다.
마치며 — 메시를 만드는 일과 부품을 만드는 일 사이의 거리
이 분야를 볼 때 가장 유용한 질문 하나만 남기자면 이것입니다. 이 도구의 출력이 편집 가능한 피처를 가지고 있는가, 아니면 결과 형상뿐인가.
- 메시만 나온다면 시각화와 프린팅 초안용입니다. 기계 설계 파이프라인에 들어갈 수 없습니다.
- B-rep(STEP)이 나온다면 CAD로 가져가 직접 편집은 됩니다. 하지만 피처 트리가 없으므로 파라미터 한 개를 바꿔 재생성하는 일은 못 합니다.
- 파라메트릭 코드가 나온다면 진짜 파라메트릭입니다. 대신 코드가 깨지기 쉬운 참조를 포함할 수 있고, 그 취약성은 사람이 봐야 합니다.
그리고 그 어느 것도 공차, DFM, 가공성을 대신하지 않습니다. Show GN에 올라온 툴의 개발자가 "제조에 바로 쓰지 말라"고 적은 것은 겸손이 아니라 정확한 기술적 서술입니다. 형상을 만드는 일과 부품을 만드는 일 사이의 거리는, 지금까지 이 분야가 좁힌 것보다 아직 훨씬 멉니다.