앤티그래비티 2.0, OpenSCAD 건축 3D LLM 벤치마크 1위

• ModelRift가 꽤 실전적인 3D LLM 벤치마크를 돌림 — 과제는 참고 이미지 2장을 보고 OpenSCAD로 로마 판테온 만들기였음

  • 단순히 큐브에 구멍 뚫는 수준이 아니라, 로툰다, 돔, 오큘러스, 전면 주랑, 삼각 페디먼트, 기둥 배치까지 어느 정도 읽혀야 하는 과제
  • ModelRift 입장에선 플랫폼의 모든 3D 모델을 OpenSCAD로 생성하니까, LLM의 공간 기하 처리 능력이 곧 제품 품질과 연결됨

• 판테온을 고른 이유가 좋음 — OpenSCAD가 잘하는 영역과 못하는 영역의 경계에 딱 걸쳐 있음

  • OpenSCAD는 유기적인 조각상이나 캐릭터 모델링엔 별로지만, 불리언 연산, 회전 대칭, 반복 배치, 압출, 하드서피스 형태에는 강함
  • 판테온은 원형 로툰다와 돔, 중앙 오큘러스, 직선형 포르티코, 반복 기둥, 계단식 베이스가 섞여 있어서 LLM의 구조 이해를 보기 좋음
  • 약한 결과도 “돔 있는 건물” 정도는 나오지만, 좋은 결과는 둥근 본체와 사각 전면부의 관계까지 맞춰야 해서 차이가 확 드러남

• 결과만 보면 구글 앤티그래비티 2.0과 제미나이 3.5 플래시 하이가 자율 실행 기준 1등임

  • 품질 점수는 4.5/5로 최고였고, 실행 시간은 약 12분이라 속도 점수는 1/5로 낮았음
  • 이 조합은 참고 이미지만 보고 눈대중으로 만들지 않고, 실제 판테온 치수를 찾아 로툰다, 돔, 포르티코, 오큘러스 파라미터에 반영함
  • 다른 자율 에이전트들이 놓친 핵심 디테일도 구현했는데, 판테온 내부 돔의 5개 링, 28개 코퍼 천장 패턴을 OpenSCAD로 만든 게 제일 컸음

• 코덱스 5.5 하이는 디테일 밀도가 가장 높았지만, 최종 결과에서 뼈아픈 문제가 터짐

  • 로툰다, 돔 리브, 오큘러스, 석조 밴드, 전면 포르티코, 기둥, 베이스 디테일, 엔태블러처의 M AGRIPPA L F COS TERTIVM FECIT 문구까지 넣음
  • OpenSCAD에서 텍스트는 그냥 장식이 아니라 배치, 압출, 방향, 두께까지 맞춰야 해서 꽤 까다로운 디테일임
  • 그런데 렌더링 미리보기는 좋아 보였지만 최종 STL에서 포르티코 지붕과 엔태블러처 주변에 이상한 면이 생겨 점수가 3.0/5로 내려감

• 클로드 계열은 결과 성향이 갈렸음

  • Claude Code 2.1 / Sonnet 4.6은 원래 자율 실행 배치에서는 가장 깔끔한 모델이었고, 돔, 드럼, 포르티코, 기둥 구성이 하나의 건물처럼 읽혔음
  • 대신 속도가 느렸고, 품질은 3.4/5로 평가됨. 괜찮은 근사치지만 건축 복원 모델이라고 부를 수준은 아님
  • Claude Code 2.1 / Opus 4.7은 구조는 커서보다 낫고 전면부와 계단식 베이스도 더 명확했지만, 색과 시각적 위계가 단조로워 3.0/5에 그침

• 커서 Composer 2.5는 제일 빠른 대신 결과가 가장 약했음

  • 넓은 의미의 로툰다, 돔, 포르티코, 기둥은 잡았지만 판테온 특유의 비례와 재료감, 건축적 디테일은 많이 빠짐
  • 빠르게 초안 뽑는 용도로는 의미가 있지만, 공개 가능한 3D 모델까지 가려면 후속 수정이 많이 필요해 보임

• ModelRift와 제미나이 플래시 3.0 조합은 “사람이 중간에 시각 피드백을 주는” 방식으로 3.8/5를 받음

  • 완전 자율 벤치마크는 아니고, 브라우저에서 렌더를 보고 화살표나 메모를 달아 AI에게 다시 수정시키는 Annotation Mode를 사용함
  • 약 10분이 걸렸고 클로드 코드보다 대략 2배 느린 수준이라 속도 점수는 낮았지만, 포르티코, 기둥 배치, 지붕, 돔 리브, 전체 매스는 꽤 일관되게 개선됨
  • 공간 문제는 “왼쪽 기둥 간격이 이상함”을 텍스트로 길게 설명하는 것보다, 렌더 위에 바로 표시하는 게 훨씬 정확하다는 얘기

• OpenSCAD는 LLM 생성용 3D 타깃으로 꽤 잘 버텼음

  • 모델이 “반지름 기준으로 기둥 28개 반복”, “돔에서 오큘러스 빼기”, “계단식 링 쌓기” 같은 구조를 코드로 직접 표현할 수 있음
  • 결과물이 텍스트라서 검사, 재현, 수정이 쉽고, OpenSCAD CLI로 PNG 미리보기를 뽑아 반복 개선하기도 좋음
  • Blender MCP 같은 UI 제어 방식은 유용하지만, CAD형 작업에선 장면 상태를 계속 추적해야 해서 간접성이 커짐

• 가장 큰 결론은 “도구 호출 능력”보다 “기하 판단력”이 병목이었다는 것
  • 모든 시스템이 macOS PATH에 있는 OpenSCAD를 문제없이 호출했고, PNG 렌더를 만들며 반복도 했음
  • 차이는 참고 이미지를 얼마나 구조적으로 해석했는지, 카메라와 비례를 얼마나 잘 잡았는지, 최종 메시까지 깨끗하게 냈는지에서 벌어짐
  • 완전 자율 생성은 많이 올라왔지만, 판테온 같은 공간 CAD 작업은 아직 사람이 렌더를 보며 짚어주는 루프가 확실히 강함

---

기술 맥락

• 여기서 OpenSCAD가 중요한 이유는 LLM이 다루기 쉬운 형태의 CAD 언어이기 때문이에요. 일반 3D 툴처럼 화면 안의 오브젝트 상태를 계속 기억하며 조작하는 게 아니라, 반복문과 파라미터로 건축 구조를 설명할 수 있거든요.

• 판테온 과제가 재밌는 이유는 “예쁜 3D 이미지”가 아니라 “구조가 맞는 3D 코드”를 요구하기 때문이에요. 돔, 오큘러스, 주랑, 계단식 베이스는 각각 따로 만들 수 있지만, 이걸 한 건물처럼 보이게 하려면 비례와 위치 관계를 계속 맞춰야 해요.

• 앤티그래비티가 높은 점수를 받은 건 모델 자체만 좋아서가 아니라, 실제 치수를 찾아 파라미터에 넣고 렌더를 보며 수정하는 흐름을 탔기 때문이에요. 특히 5개 링과 28개 코퍼 천장처럼 반복 규칙이 있는 구조는 OpenSCAD와 LLM 조합이 힘을 받는 지점이에요.

• 반대로 코덱스 사례는 실무에서 조심해야 할 포인트를 잘 보여줘요. 미리보기 렌더가 괜찮아도 최종 STL 메시가 깨질 수 있으니, 3D 프린팅이나 모델 배포 파이프라인에서는 렌더 확인과 메시 검증을 분리해서 봐야 해요.

• 결국 이 벤치마크는 “AI가 CAD를 완전히 대체한다”는 얘기보다는, 코드 기반 CAD와 시각 피드백 루프를 붙이면 사람이 직접 모델링하지 않아도 꽤 높은 초안을 얻을 수 있다는 신호에 가까워요. 지금 단계에선 완전 자율보다 사람이 렌더 위에서 방향을 찍어주는 방식이 더 실용적이에요.