AI 3D 도구에는 벤치마크에 대한 맹신이 아닌 제품 평가가 필요하다

만약 당신이 AI 생성 3D 툴링 (AI-generated 3D tooling)을 구축하고 있다면, 공개 벤치마크 (benchmarks)를 제품의 진실이 아닌 **선도 신호 (lead signals)**로 취급하십시오. 모델이 OpenSCAD 스타일의 벤치마크에서 높은 점수를 받을 수 있지만, 당신의 앱 내부에서는 여전히 위험할 수 있습니다. 왜냐하면 당신의 제품은 참조 파일에 대해 텍스트를 채점하는 것이 아니기 때문입니다. 당신의 제품은 사용자에게 생성된 기하학적 구조 (geometry), 측정값, 레이아웃 의도 (layout intent), 그리고 다운스트림 편집 가능성 (downstream editability)을 신뢰할 것을 요구합니다.

이것은 기준을 완전히 바꿉니다. 진짜 질문은 "어떤 모델이 벤치마크 1위를 차지했는가?"가 아닙니다. 진짜 질문은 **"이 모델이 내 워크플로 (workflow) 내부에서 어떤 오류를 범할 수 있으며, 사용자가 비용을 지불하기 전에 얼마나 저렴하게 그 오류를 잡아낼 수 있는가?"**입니다.

CAD 스타일의 도구, 공간 계획 도구 (room planners), 파라메트릭 빌더 (parametric builders), 장면 생성기 (scene generators), 그리고 레이아웃 시스템 (layout systems)의 경우, 그 질문은 리더보드 (leaderboard) 순위보다 더 중요합니다. 벤치마크는 여전히 유용합니다. 후보군을 좁히고 명백한 막다른 길을 피하는 데 도움을 줍니다. 하지만 벤치마크 점수만 보고 제품을 출시한다면, 당신은 제품에 대한 판단을 타인의 태스크 설계 (task design)에 외주를 주는 것과 같습니다.

벤치마크는 유용하지만, 필터로서만 유용하다

벤치마크는 보통 실질적인 무언가를 알려줍니다. 모델이 구조화된 프롬프트 (structured prompts)를 따르는지, 구문적으로 유효한 코드 (syntactically valid code)를 생성하는지, 그리고 특정 계열의 기하학적 작업 (geometry tasks)을 동료 모델들보다 더 잘 처리하는지를 드러낼 수 있습니다. 그것은 가치 있는 일입니다.

하지만 벤치마크가 알려주지 않는 것은 모델이 당신의 실패 경계 (failure boundary)에서 잘 작동하는지 여부입니다.

벤치마크는 실제 프로덕션 도구 (production tool)에 있어 잘못된 것에 보상을 줄 수 있습니다:

기하학적 의도 (geometric intent) 대신 정확한 문자열 또는 AST 유사성
편집 가능한 출력 (edit-safe output) 대신 단순한 객체 생성
안정적인 치수 (stable dimensions) 대신 유효한 코드 생성
실패 후 복구 가능성 (repairability after failure) 대신 원샷 태스크 성공 (one-shot task success)
최악의 경우 발생하는 피해 (worst-case damage) 대신 평균 점수

마지막 포인트가 가장 중요합니다. 3D 툴링에서 평균적인 결과는 종종 보기 흉한 5%의 결과보다 덜 중요합니다. 만약 모델이 가끔씩 자기 교차 메쉬 (self-intersecting meshes), 비매니폴드 솔리드 (non-manifold solids), 겹치는 벽, 불가능한 간격 (impossible clearances), 또는 조용히 틀린 측정값을 생성한다면, 벤치마크 점수는 더 이상 위안이 되지 않습니다.

실질적인 규칙: 공개 벤치마크는 무엇을 신뢰할지가 아니라, 무엇을 테스트할지를 결정하는 용도로 사용하십시오.

만약 어떤 모델이 OpenSCAD 벤치마크에서 좋은 성능을 보인다면, 그것은 해당 모델을 여러분의 평가 세트 (eval set)에 포함시켜야 할 이유가 됩니다. 하지만 그것이 생성된 기하 구조 (geometry)를 유료 사용자에게 직접 노출해도 된다는 근거는 아닙니다.

평가 (evals)는 제품의 계약 (product contract)을 반영해야 합니다

대부분의 팀이 여기서 동일한 실수를 범합니다. 그들은 프롬프트 계층 (prompt layer)에서 모델을 평가하지만, 실제 제품의 리스크는 결과물 계층 (artifact layer)에 존재합니다.

만약 여러분의 제품이 "가운데에 900mm 문이 있고 동쪽 벽에 1.2m 창문이 있는 4x6m 크기의 방을 만들어줘"와 같은 자연어 요청을 수용한다면, 여러분의 평가는 "모델이 그럴듯한 코드를 생성했는가?"에서 멈춰서는 안 됩니다. 생성된 결과물이 실제 계약을 충족하는지 검증해야 합니다:

치수가 허용 오차 (tolerance) 내에서 정확한가?
명시된 제약 조건 (constraints)이 준수되었는가?
출력물이 편집 가능한가?
재생성 (regeneration) 시 의도가 유지되는가?
후속 도구 (downstream tools)가 이를 깔끔하게 가져올 (ingest) 수 있는가?

즉, 여러분의 평가 데이터 세트 (eval dataset)는 제품 특화적 (product-specific)이어야 합니다.

벤치마크의 사소한 지식(trivia)이 아닌 사용자 의도에 기반하여 태스크를 구축하십시오

규모를 더 키우기 전, 좋은 내부 평가 세트에는 보통 30개에서 100개 사이의 태스크가 포함됩니다. 핵심은 데이터 세트의 크기가 아닙니다. 핵심은 여러분의 제품이 실제로 내리는 결정들을 얼마나 포괄 (coverage)하고 있느냐입니다.

방 배치 (room-layout) 도구의 경우, 다음과 같은 항목이 포함될 수 있습니다:

엄격한 치수를 가진 단순한 직사각형 방
모서리로부터 정확한 오프셋 (offset)을 가진 개구부 (openings)
간격 규칙 (clearance rules)이 적용된 가구 배치
시스템이 거부하거나 수정해야 하는 잘못된 요청
제약 조건이 약간씩 다른 유사한 프롬프트
"배치는 그대로 두고, 소파만 벽에서 400mm 떨어뜨려 줘"와 같은 반복적인 편집

파라메트릭 CAD (parametric CAD) 어시스턴트의 경우, 다음을 포함하십시오:

정확한 측정값이 포함된 부품
공차 (tolerance)에 민감한 컷아웃 (cutouts)
반복되는 특징 (features) 및 대칭
초기 생성 이후의 특징 편집
엄격한 제약 조건과 부드러운 미적 의도가 혼합된 프롬프트

핵심은 가능한 경우 각 사례가 **기계로 확인 가능한 성공 조건 (machine-checkable success condition)**을 가져야 한다는 점입니다.

{
  "id": "room-door-window-01",
  "prompt": "남쪽 벽에는 900mm 크기의 중앙 배치된 문을, 동쪽 벽에는 북동쪽 모서리에서 1m 떨어진 곳에 1200mm 크기의 창문을 가진 4m x 6m 크기의 방을 생성하세요.",
...

그러한 구조는 일반적인 프롬프트-응답 (prompt-response) 벤치마크보다 이미 더 유용합니다. 왜냐하면 그것이 당신의 제품에서 실패가 무엇을 의미하는지를 알려주기 때문입니다.

통과율뿐만 아니라 비즈니스 피해에 따른 점수 산정

모든 오류가 동일한 것은 아닙니다. 재질(material) 레이블이 잘못 지정된 것은 짜증스러운 일입니다. 잘못된 컷아웃(cutout) 치수는 제작을 망칠 수 있습니다. 소파가 벽과 겹치는 것은 보기 흉합니다. 불가능한 챌(rise)/런(run) 값을 가진 계단은 안전하지 않습니다.

따라서 평가 (evals)의 가중치를 그에 따라 조절하십시오.

좋은 점수 산정 모델은 보통 다음과 같이 구분합니다:

하드 실패 (hard failures): 제약 조건 위반 (constraint violations), 유효하지 않은 기하 구조 (invalid geometry), 임포트 실패 (import failure)
소프트 실패 (soft failures): 보기 흉한 레이아웃 (ugly layout), 어색한 간격 (awkward spacing), 부족한 스타일 일치 (poor style match)
복구 가능한 실패 (recoverable failures): 사용자가 한 번의 편집으로 수정할 수 있는 경우
독성 실패 (toxic failures): 결과물이 유효해 보이지만 잘못된 치수를 인코딩하고 있는 경우

마지막 카테고리는 벤치마크 맹신이 실제로 무너지는 지점입니다. 치수적으로 틀렸음에도 유창해 보이는 결과물은 명백한 실패보다 훨씬 더 나쁩니다. 왜냐하면 사용자가 그것을 더 오래 신뢰하기 때문입니다.

모델의 세련미보다 기하학적 실패 모드가 더 중요하다

3D 생성 (3D generation)에서 화려한 데모는 값비싼 버그를 숨깁니다. 모델이 구문론적으로는 유효한 (syntactically valid) 출력을 생성하더라도, 운영상으로는 망가진 (operationally broken) 결과를 낼 수 있다고 가정해야 합니다.

그것이 바로 당신의 평가 (evals)가 단순한 텍스트 수준의 점수 산정이 아닌, 기하학적 인지 체크 (geometry-aware checks)를 필요로 하는 이유입니다.

조기에 포착할 가치가 있는 실패 클래스

CAD 스타일 및 레이아웃 도구의 경우, 보통 다음과 같은 것들이 중요합니다:

치수 드리프트 (dimensional drift): 부품이나 방의 형태가 비슷하긴 하지만 정확하지 않음
위상적 무효성 (topological invalidity): 자기 교차 (self-intersections), 열린 쉘 (open shells), 비매니폴드 엣지 (non-manifold edges)
제약 조건 위반 (constraint breakage): 피처가 겹치거나 배치 규칙을 위반함
기준 좌표계 오류 (frame-of-reference mistakes): 잘못된 축, 미러링된 배치, 너비/깊기 바뀜
편집 불안정성 (edit instability): 작은 프롬프트 변경이 전체 구조의 붕괴를 초래함
단위 혼동 (unit confusion): mm vs cm vs m, 또는 정교화 (refinement) 과정 중 암시적인 단위 변화
후속 공정 호환성 문제 (downstream incompatibility): 렌더링은 되지만 슬라이서 (slicer), CAD 임포터 (importer), 또는 씬 파이프라인 (scene pipelines)에서 실패하는 내보내기 결과물

첫날부터 이 모든 것을 위한 완벽한 자동 판정기 (automated judge)가 필요한 것은 아닙니다. 하지만 유효한 텍스트 출력이 충분한 대리 지표 (proxy)인 것처럼 가장하는 것은 멈춰야 합니다.

모델 주변에 결정론적 검증기 (deterministic validators) 추가하기

가장 실용적인 아키텍처는 보통 LLM 단독이 아닌, LLM과 검증기 (verifier)의 결합입니다.

모델이 OpenSCAD, CAD 파라미터, 또는 씬 JSON (scene JSON)을 생성한다면, 생성 후 결과물을 사용자에게 보여주기 전에 결정론적 체크 (deterministic checks)를 실행하십시오. 모델은 합성을 위해 사용하고, 코드는 신뢰를 위해 사용하십시오.

from dataclasses import dataclass

@dataclass
...

이 방식은 화려하지 않으며, 바로 그 점이 핵심입니다. 만약 당신의 제품이 기하학적 형상 (geometry)의 정확성에 의존한다면, 사용자의 신뢰를 지키기 위해 지루한 검증기 (validators)를 앞단에 배치해야 합니다.

생성 대상이 코드 기반인 경우 OpenSCAD와 같은 공식 레퍼런스가 도움이 됩니다. 출력을 결정론적으로 파싱 (parse), 렌더링 (render), 검사 (inspect)할 수 있기 때문입니다. 이는 스크린샷 품질만으로 평가하는 것보다 훨씬 안전합니다.

직접적인 생성 (direct generation)을 출시하기 전에 보호된 워크플로 (guarded workflows)를 출시하라

신뢰를 가장 빠르게 해치는 방법은 생성된 기하학적 형상을 마치 권위 있는 결과물인 것처럼 제시하는 것입니다.

더 안전한 출시 경로는 단계적이어야 합니다.

실행 모드가 아닌 제안 모드로 시작하라

첫 번째 버전에서 모델은 결정하는 것이 아니라 제안해야 합니다.

초기 제품의 좋은 패턴은 다음과 같습니다:

초안을 생성하고 명시적인 사용자 검토를 요구할 것
추론된 제약 조건 (inferred constraints)과 정확한 제약 조건 (exact constraints)을 구분하여 표시할 것
측정값을 검사 가능한 오버레이 (inspectable overlays)로 보여줄 것
신뢰도가 낮은 출력물과 검증이 차단된 항목에 라벨을 붙일 것
조용히 수정(silent fixes)하는 대신 클릭 한 번으로 가능한 복구 제안을 제공할 것

이러한 제품 프레이밍 (product framing)은 매우 중요합니다. 사용자들은 나중에 틀린 것으로 판명되는 "완성된 모델 (done model)"보다 "생성된 초안 (generated draft)"에 대해 훨씬 더 관대합니다.

이는 반복적인 편집 워크플로 (iterative editing workflows)에서 특히 중요합니다. 만약 사용자가 "조리대 깊이를 300mm 더 깊게 만들되 싱크대는 중앙에 유지해줘"라고 요청한다면, 그들은 새로운 환각 (hallucination)을 요구하는 것이 아닙니다. 그들은 **제약 조건 보존 변환 (constraint-preserving transformation)**을 요구하는 것입니다. 이것들은 서로 다른 작업이며, 서로 다른 가드레일 (guardrails)을 가져야 합니다.

복구를 일급 기능 (first-class capability)으로 취급하라

강력한 3D 도구는 단순히 "모델이 이것을 생성할 수 있는가?"라고 묻지 않습니다. 대신 **"모델이 틀렸을 때, 시스템이 저렴한 비용으로 복구할 수 있는가?"**라고 묻습니다.

이는 복구를 지원할 수 있을 만큼 충분한 구조를 저장해야 함을 의미합니다:

명시적 제약 조건 (explicit constraints)
의미론적 객체 라벨 (semantic object labels)
자유 형식의 코드뿐만 아니라 타입이 지정된 필드 (typed fields)로서의 치수
어떤 단계에서 어떤 기능이 생성되었는지에 대한 출처 (provenance)

모든 것을 하나의 최종 텍스트 덩어리 (text blob)로 축소하면, 모든 수정 작업이 전체 재생성으로 이어지게 됩니다. 이는 취약한 방식입니다.

더 나은 패턴은 중간 표현 (intermediate representation)을 우선시하고, 생성된 결과물 (generated artifact)을 그 다음에 두는 것입니다. 모델이 스키마 (schema)를 채우게 하고, 스키마를 검증한 다음, 최종 표현 (final representation)으로 컴파일하십시오.

type LayoutIntent = {
  room: { widthMm: number; lengthMm: number };
  openings: Array<{ 
...

해당 스키마를 통해 검증, 차이 비교 (diff), 복구 및 버전 관리가 가능한 요소를 얻을 수 있습니다. 생성된 장면 (scene)이나 CAD 코드는 유일한 진실의 원천 (source of truth)이 아니라, 컴파일 대상 (compilation target)이 됩니다.

프로덕션 평가 (Production evals)는 출시 후에도 계속되어야 한다

오프라인 평가 (Offline evals)는 필수적이지만, 그것만으로는 충분하지 않습니다. 실제 사용자들이 도구를 사용하기 시작하면, 여러분의 합성 데이터 세트 (synthetic set)가 놓쳤던 엣지 케이스 (edge cases)들을 발견하게 될 것입니다.

올바른 방향은 프로덕션에서의 실패를 다시 평가 케이스 (eval cases)로 전환하는 피드백 루프를 구축하는 것입니다.

프롬프트뿐만 아니라 실패 증거를 기록하세요

생성(generation)이 실패했을 때, 프롬프트 이상의 정보를 캡처해야 합니다:

프롬프트 텍스트 (prompt text)
모델 버전 (model version)
시스템 프롬프트 또는 플래너 버전 (system prompt or planner version)
중간 구조화된 의도 (intermediate structured intent)
검증기 출력값 (validator outputs)
생성 후 사용자의 편집 사항 (user edits after generation)
결과물(artifact)이 수락되었는지, 수정되었는지, 또는 폐기되었는지 여부

그래야만 향후 평가(evals)를 위한 진정한 신뢰할 수 있는 근거(source of truth)를 확보할 수 있습니다. 그렇지 않으면 실패 원인을 분석하는 대신 막연한 느낌(vibes)을 디버깅하게 될 것입니다.

유용한 내부 분류 체계(taxonomy)는 간단합니다:

gen_valid_user_accepted (생성 유효, 사용자 수락)
gen_valid_user_repaired (생성 유효, 사용자 수정)
gen_invalid_blocked_by_validator (생성 무효, 검증기에 의해 차단됨)
gen_invalid_escaped_to_user (생성 무효, 사용자에게 유출됨)
gen_refused_correctly (정상적으로 거부됨)

이제 시스템이 실제로 중요한 방식으로 개선되고 있는지 측정할 수 있습니다.

벤치마크 순위가 아닌 탈출률(escape rate)을 최적화하세요

제가 가장 신경 쓰는 지표는 공개 벤치마크 순위가 아닙니다. 바로 **실패 탈출률 (failure escape rate)**입니다. 즉, 실질적으로 잘못된 결과물(artifact)이 마치 사용 가능한 것처럼 사용자에게 도달하는 빈도입니다.

이 지표는 제품에 대한 신뢰와 직결됩니다.

만약 벤치마크 점수가 8% 향상되었지만 탈출률이 거의 변하지 않았다면, 아마도 안전성(safety)이 아닌 구문(syntax)을 개선했을 가능성이 높습니다. 반면 벤치마크 점수는 그대로인데 사용자에게 전달되는 잘못된 기하 구조(invalid geometry)가 급격히 줄어들었다면, 그것이 진정한 진전입니다.

이것이 개발자들이 받아들여야 할 역발상적인 부분입니다: 당신의 제품에 가장 좋은 모델이 반드시 벤치마크 승자라는 법은 없습니다. 당신의 검증기(validators)와 가장 잘 작동하거나, 제약 조건(constraints)을 더 신뢰성 있게 유지하거나, 더 정직하게 성능 저하를 보이거나, 혹은 당신의 파이프라인이 안전하게 수정할 수 있는 결과물을 만들어내는 모델이 최적의 모델일 수 있습니다.

내가 실제로 할 일

만약 내가 오늘 AI 기반의 3D 또는 CAD 인접 도구를 만든다면, 공개 벤치마크는 후보 모델을 추리는 용도로만 사용할 것입니다. 그다음 엄격한 제약 조건 체크, 기하 구조 검증(geometry validation), 그리고 심각도 가중치 점수(severity-weighted scoring)를 포함한 제품 평가 세트(product eval set)를 구축할 것입니다. 먼저 제안 모드(proposal mode)를 출시하고, 구조화된 중간 표현(structured intermediate representations)을 유지하며, 결정론적 검증(deterministic validation)을 통과하지 못하는 모든 결과물은 차단할 것입니다.

또한 일부 실패 사례는 여전히 빠져나갈 것이라고 가정하며, 따라서 매주 프로덕션(production) 실수를 새로운 평가(eval) 케이스로 전환할 수 있도록 충분한 증거를 기록할 것입니다.

이는 벤치마크(benchmark) 차트를 게시하고 승리를 선언하는 것보다 느린 방식입니다. 하지만 이는 데모에서는 지능적으로 보이지만 실제 사용 시에는 비용만 많이 드는 도구를 출시하는 것을 방지하는 방법이기도 합니다.

실질적인 결정 규칙은 간단합니다: 3D 생성 모델을 신뢰하기 전에, 당신의 검증기(validators)가 모델이 생성한 결과물(artifact)을 얼마나 신뢰하는지를 먼저 확인하십시오. 이 카테고리에서 벤치마크는 시작을 도와줄 뿐입니다. 벤치마크가 제품을 출시해도 안전한 시점을 결정하게 해서는 안 됩니다.

QCode에서 전체 포스트를 읽어보세요: https://qcode.in/how-to-build-ai-generated-3d-tools-without-trusting-benchmarks/