요약
Antimony는 CAD가 Lisp 머신에서 진화했다면 어땠을지 상상해 만든 노드 그래프 방식의 CAD 도구입니다.
매트 키터가 MIT 비트·원자 센터(Center for Bits and Atoms)에서 개인 규모 제작 도구를 연구하며 만든 프로젝트입니다. 이 페이지는 앞선 도구 cad_ui와 kokopelli를 이은 2015년판 소개 글입니다. 저자는 안정적이지만 아직 베타 단계라 중요한 작업에는 권하지 않는다고 밝혔습니다.
왜 중요한가
- 선을 긋는 제도판 방식 대신 형상을 수식과 데이터 흐름으로 다루는 CAD의 다른 길을 보여 줍니다.
- Python 기초만 알면 누구나 새 노드를 만들어 도구 자체를 넓힐 수 있습니다.
- 저자가 이후 libfive, Fidget, Halfspace로 이어 간 암시적 곡면(수식으로 정의한 형상) 연구의 출발점입니다.
핵심 내용
- 각 노드는 Python 3 스크립트로 정의하며, 값이 바뀌면 연결을 따라 뒤쪽 노드에 자동으로 반영됩니다.
- 형상은 함수 표현(F-rep, 형상을 하나의 수식으로 나타내는 방식)으로 다뤄 합치기·빼기 같은 불리언 연산이 쉽습니다.
- 표준 라이브러리는 기본 도형과 회전·확대 외에 끌어당기기·휘기 같은 독특한 변형도 제공합니다.
- 3D 화면에서 도형의 꼭짓점을 끌면 그래프 속 노드 값도 함께 바뀝니다.
- 결과는 2.5D 가공용 높이맵이나 3D 제작용 STL 파일로 내보낼 수 있습니다.
HN 반응
- AutoCAD가 40년 넘게 Lisp 방언인 AutoLISP를 지원해 왔으니 Lisp 머신 설정은 아이러니하다는 지적이 나왔습니다.
- AI 바람에 코드 CAD 도구가 쏟아져 오래갈지 걱정이라는 의견에, STEP 파일로 주고받으면 된다는 반론과 STEP은 수정이 어렵다는 재반론이 맞섰습니다.
(2015) 표시를 붙여야 할 글이네요 :)
저는 2016년쯤부터 유지보수를 점점 줄여 왔고, 지금은 https://github.com/nsfm/stibium 에 더 활발히 관리되는 포크가 있어요. (2026년이니 LLM의 도움을 잔뜩 받긴 했지만요!)
결과는 장담 못 해요. 저도 써 보거나 변경 사항을 꼼꼼히 살펴보지는 않았어요. 다만 그 포크 작성자와 연락을 주고받았는데, 프로젝트를 성공시키려고 정말 열심히 하는 분 같았어요.
요즘은 어떤 작업을 하고 계세요?
여러 가지를 하고 있습니다. 암시적 곡면(implicit surface)의 가장 마음에 드는 점은 컴퓨터 과학 전체의 축소판 같다는 겁니다. 그래서 파고들 방향이 무척 많습니다.
libfive [1]는 그 뒤를 이은 커널로, C++로 작성했고 빠른 평가와 견고한 메시 생성에 힘을 많이 쏟았습니다. 이것도 지금은 유지보수 모드이지만, 상용 CAD 도구 몇 군데에 탑재되어 나갔습니다.
2020년에는 GPU에서 암시적 곡면을 렌더링하는 내용으로 SIGGRAPH 논문 [2]을 썼습니다. 정말 재미있고 짜릿한 경험이었습니다. 프런트엔드는 libfive로 하고, 연산이 많이 드는 렌더링 작업은 전부 GPU에서 처리했습니다.
그러다 C++을 다루는 데 지쳐서 전부 Rust로 다시 작성했고, 이후로는 계속 그것을 쓰고 있습니다. 새 커널이 Fidget [3]이고 새 IDE가 Halfspace [4]입니다. 지금 가장 열심히 작업하는 프로젝트로, Halfspace 블로그 글은 몇 주 전에 올라갔고, Fidget에는 GPU 렌더링 백엔드를 구현하고 개선하는 중입니다(써야 할 블로그 글도 몇 편 밀려 있습니다).
그 사이에는 여러 사람을 꼬드겨서(nerd-sniping) 각자 f-rep 평가 엔진을 만들게 했고 [5], '독립 연구'라는 주제로 강연도 했습니다 [6].
[1] https://libfive.com
[2] https://www.mattkeeter.com/projects/siggraph/
[3] https://www.mattkeeter.com/projects/fidget/
[4] https://www.mattkeeter.com/projects/halfspace/
[5] https://www.mattkeeter.com/projects/prospero/
[6] https://www.youtube.com/watch?v=UxGxsGnbyJ4
답변 감사합니다. 작업물의 열렬한 팬입니다. Halfspace와 Fidget은 별개의 프로젝트인 줄 알았습니다. libfive와 SIGGRAPH 논문을 직접 이어 가는 프로젝트라는 말씀이신가요? Rust로 다시 구현한 쪽은 얼마나 안정적이고, 실무에 쓸 만한 수준입니까?
모두 같은 큰 '연구 프로그램'에 속하고 비슷한 알고리즘을 구현하지만, libfive와 코드를 공유하지는 않습니다(언어가 바뀌었으니 공유하기도 어렵습니다).
Rust 코드는 저 말고도 몇 사람이 쓰고 있지만 아주 안정적이지는 않습니다. '맞는 API'를 찾는 것이 목표 중 하나라서, 더 나은 추상화를 찾으면 주저 없이 기존 구조를 깨뜨립니다. 메시 생성도 libfive만큼 다듬어지지는 않았습니다. 제 요구 사항을 모두 만족하는 알고리즘을 아직 찾지 못했고, 선택한 알고리즘(매니폴드 이중 윤곽 추출, manifold dual contouring)의 문제를 덮는 데 들인 시간도 더 적기 때문입니다.
그 훌륭한 유튜브 영상은 따로 게시물로 올릴 만합니다. 43분 만에 이렇게 많이 배울 수 있다니 놀랍네요.
저는 이 분야 전문가는 아니지만, 레이마칭(raymarching) 같은 기법은 어떻게 보시나요?
좋게 말씀해 주셔서 감사합니다!
레이마칭은 훌륭한 기법이고, 데모씬과 Inigo Quilez 같은 분들의 작업을 아주 좋아합니다! 제가 그 이야기를 자주 하지 않는 것은 제 라이브러리의 목표가 조금 다르기 때문입니다.
대부분의 레이마칭 전략은 함수에 제약을 겁니다. 예를 들어 광선을 따라 전진할 때 모델을 뚫고 지나가지 않도록 보장하려면 립시츠 연속성(Lipschitz continuity)이 필요합니다. 이 성질은 실수로 깨지기 쉬워서(모델의 크기만 바꿔도 보정 계수가 필요합니다) 바탕이 되는 수식을 구부리거나 비틀 때 조심해야 합니다. 데모 하나만 만들거나 검증된 도형 라이브러리가 있다면 그래도 괜찮지만, 그만큼 유연성은 떨어집니다.
제 인프라의 목표는 아무리 성질이 나쁜 수식이라도 사실상 어떤 수식이든 지원하는 겁니다(C0 연속성만은 꼭 있었으면 좋겠지만요). 그래서 구간 산술(interval arithmetic)이 주는 보장 [1]이 마음에 듭니다.
그렇다고 경계가 뚜렷한 것은 아닙니다. 한쪽에서는 점 표본 대신 구간 연산으로 레이트레이싱을 할 수 있습니다 [2]. 반대쪽에서는 제가 최근 만든 GPU 렌더링이 공간 영역을 Z 정렬해서 쓰는데, 여전히 3D 구간을 쓰되 카메라 뒤쪽에서부터 훑어 나갑니다(아직 블로그 글은 없습니다, 죄송합니다).
[1] Fidget은 사실 FPU의 반올림 모드를 바꾸지 않아서 절대적으로 보장되는 것은 아니지만, 음......
[2] https://arxiv.org/abs/2202.02444
세상에, 제가 이름을 정말 못 외워서 그 SIGGRAPH 논문과 Antimony가 같은 분 작품이라는 걸 몰랐어요! 둘 다 정말 멋져요. 훌륭한 작업을 하셨네요!
저는 딱 그 무렵에 당신의 작업을 처음 접했는데, 이런 게 어떻게 돌아가는지 전혀 몰랐던 터라 큰 충격을 받았습니다. 그 뒤로 잊고 지냈다가 어제 다시 찾았어요. 그때도 정말 반가운 발견이었고 제 생각을 많이 바꿔 놓았습니다. 감사합니다!
요즘 코드 CAD(Code CAD) 쪽이 AI 기반 신규 프로젝트들과 함께 아주 강하게 밀리고 있다는 점은 짚어 둘 만합니다.
최근에 진전이 있었던 프로젝트들을 정리해 보겠습니다.
OpenSCAD --- 오랫동안 기다려 온 업데이트의 (부디 마지막이길 바라는) 릴리스 후보가 나왔습니다: https://openscad.org/downloads.html#rc
PythonSCAD --- 값이 바뀌는 변수 같은 걸 쓰고 싶은 분들을 위한 것입니다: https://www.pythonscad.org/
CADquery --- https://cadquery.github.io/
Build123D --- https://github.com/gumyr/build123d
더 긴 목록과 논의는 여기 있습니다: https://github.com/Irev-Dev/curated-code-cad
또 Matt Keeter의 더 최근 프로젝트인 Halfspace도 얼마 전에 발표됐는데, 여기서는 별로 논의되지 않았습니다.
https://news.ycombinator.com/item?id=49881890
이런 프로그램들 때문에 시장이 얼마나 쪼개질까요? 다들 수십 가지 서로 다른 설계 도구로 갈라져 쓰게 되는 걸까요?
저는 바이브 코딩으로 만들어져서 오래 지원받지 못할 애플리케이션으로 파일을 만들고 싶지 않습니다. 그중 일부는 분명 그렇지 않겠지만, 최고의 소프트웨어를 찾고 그것이 계속 남아 있을지 검증하는 일은 그냥 Fusion이나 OnShape를 계속 쓰는 것보다 품이 더 들어 보입니다.
제가 틀렸을 수도 있지만, 새로운 드래프팅이나 설계 도구에 관한 글이 매일 여러 개씩 올라오는 걸 봅니다. 그런 도구를 기존 워크플로에 통합하는 비용은 높아 보입니다.
모든 3D 파라메트릭 CAD가 이미 하나의 공통 교환 형식으로 수렴했습니다. STEP 파일이고, 시장을 지배하는 커널이라 Parasolid x_t 파일이 그다음입니다.
그러니 모두가 같은 형식으로 파일을 만든다면 통합은 사실 어려운 부분이 아닙니다.
STEP 파일은 그저 '멍청한' 솔리드일 뿐이라, 모델의 피처나 관계를 실제로 편집하려는 경우에는 쓸모가 없습니다. 거의 모든 CAD 소프트웨어는 편집 가능한 실제 모델 정보를 독자 규격 파일 형식에 보관합니다. STEP 파일에서 파트 파일을 만들어 주는 CAD 프로그램도 있고 성공 정도는 제각각인데, CREO나 CATIA 같은 전문 CAD 패키지가 가장 잘합니다. 그래도 조금이라도 복잡한 형상이면 완전한 파트를 만들어 내지 못하는 일이 많습니다. STEP 파일은 대개 완성품을 생산 단계(CNC, 3D 프린팅 등)로 내보낼 때 쓰거나, 간단한 브래킷 같은 흔한 부품을 더 큰 어셈블리에 넣을 때 가끔 씁니다.
지금까지는 그랬죠.
저는 지난 7개월 동안 Aetheris 지오메트리 커널을 만들었습니다. STEP, 특히 AP242를 교환 형식이 아니라 기본 형식으로 쓰는 CAD 소프트웨어를 갖고 싶었기 때문입니다. 성공했다고 말씀드리게 되어 아주 기쁩니다. STEP 203/214 파일에 치수와 GD&T를 추가해서 곧바로 242로 변환할 수 있습니다.
기존 STEP 파일을 직접 편집하는 일은 아직 관통 구멍을 옮기는 정도로 제한되지만, 더 고급 편집을 못 할 이유는 없습니다.
다만 제가 알기로 나열된 것 중에서 쓸 만한 STEP 파일을 출력하는 것은 CadQuery뿐입니다.
Build123D도 OpenCascade 래퍼일 테니 STEP 파일을 출력할 수 있을 것 같은데요.
맞습니다. 다른 많은 형식도 지원하고요.
참고로 PythonSCAD는 소프트 포크라서 OpenSCAD와 계속 동기화됩니다.
이 목록에 FluidCad도 추가하고 싶습니다. 코드 CAD와 GUI CAD를 결합한 아주 흥미로운 도구입니다.
두 분 모두 유용한 목록 감사합니다.
Keeter의 libfive(와 그 'studio')도 그 중간에 (있었죠? 지금도 있나요?) 있습니다: https://news.ycombinator.com/item?id=26930822
참고로 libfive는 PythonSCAD에 통합되어 있습니다(통합되어 있었나요?).
아이러니한 소개입니다. 가장 널리 쓰이는 CAD 소프트웨어인 AutoCAD는 40년 넘게 AutoLISP[0]라는 리스프 방언을 대체 런타임으로 기본 지원해 왔거든요. CAD 업계에서 워낙 널리 쓰이다 보니 다른 업체들까지 이 언어와의 호환성을 채택했습니다.
CAD를 드래프팅 테이블에 빗대어 설명한 것을 보니 반갑습니다. 저는 대부분의 CAD 애플리케이션에 있는 '드래프팅 테이블' 은유와 '월드 모델' 은유가 제공하는 해법이 서로 어떻게 다른지 신규 CAD 사용자들에게 가르치는 데 많은 시간을 씁니다.
[0] https://en.wikipedia.org/wiki/AutoLISP
AutoLISP를 지원하는 오픈소스 CAD 프로그램이 있나요?
FreeCAD에 추가하자는 논의는 여기 있습니다: https://forum.freecad.org/viewtopic.php?t=49989
초기 KiCad 파일 형식을 파싱해야 했던 분들께 경의를 표합니다. 거기서는 S-표현식의 괄호와 따옴표가 규칙이라기보다 권고 사항에 가까웠으니까요.
초기 KiCad는 S-표현식이 아니거나 일부만 그랬고, 새 KiCad가 전부 S-표현식인 걸로 아는데요? 어쨌든 몇 년째 파싱 문제는 없었고, MCAD로 내보내기도 아주 잘 됩니다.
이 모델에서는 모서리에 필릿(fillet)을 어떻게 적용하나요?
저는 구성적 지오메트리(constructive geometry) 방식의 CAD는 써 본 적이 없고 최근에 OnShape으로 CAD를 배우고 있는데, 하고 싶은 작업이 전부 얼마나 쉬운지 정말 고마웠습니다. OpenSCAD 같은 순수 구성적 지오메트리 방식에서는 특정 작업을 구현하기가 더 복잡해질 수 있다고 들었습니다.
줄칼로 갈아서요. /s
안타깝게도 CAD는 GIMP와 포토샵 같은 상황이라, 쓰는 소프트웨어에 따라 목표를 낮춰 잡아야 할 수 있어요. 그래도 마냥 암울한 건 아니에요. 계속 꾸준히 나아지고 있거든요. FreeCAD의 최신 업데이트를 보세요.
저는 AI로 CAD 모델을 만들어 왔습니다. 결과가 의도와 비슷한 경우가 많지만, 실제 세계에 부품을 맞추려면 매개변수와 피처를 손보는 데 여전히 많은 노력이 듭니다. AI가 도움은 되지만, 엔터테인먼트용 생성형 AI 이미지·영상과 달리 CAD 모델링 문제를 해결해 주지는 못합니다.
저는 3D 모델링을 1년에 한 번도 안 해서 잘하지 못합니다. 뭔가 모델링하고 싶어서 Astra로 설명해 봤는데, 원하는 것과 꽤 비슷하게 나왔습니다. 하지만 아주 단순한 걸 생성하는 데 총 처리 시간이 40분쯤 걸렸습니다. Fusion을 잘 다룬다면 Astra가 걸린 시간보다 훨씬 빨리 끝냈을 겁니다.