“AutoCAD 도면 작성을 위한 신경망”이라는 검색어에는 명확한 기대가 담겨 있습니다. 기술 사양서를 업로드하면 ESKD(유럽 표준 설계 도면) 규격에 맞춘 도장이 찍힌 완성된 평면도를 얻을 수 있다는 기대 말입니다. 단도직입적으로 말씀드리자면, 그런 버튼은 존재하지 않습니다. 대신 모델이 코드를 작성하거나 AutoCAD 작업을 호출하는 통합(Integration) 방식이 존재합니다.

작동하는 워크플로우(Workflow)는 존재하며, 그 모습은 예상외입니다. 먼저 도면을 위한 requirements.md 파일, 즉 사양(Specification)이 담긴 일반 텍스트 문서를 작성합니다. 신경망(Neural Network)은 이를 코드로 변환하고, AutoCAD는 이 코드를 실행하여 도면을 생성합니다. 이 방법론은 Spec-driven development라고 불리며, 이미 AWS Kiro와 GitHub Spec Kit에 패키징되어 포함되었습니다. 또한 Autodesk Developer Network는 Claude를 도면 환경에 직접 통합하는 공식 샘플을 출시했습니다.

이 글은 반복적인 드로잉 작업에 매몰되어 있는 모든 이들을 위한 것입니다: 설계사, 제도사, 건축가, 회로 설계자, 그리고 건축 전공 학생들입니다. 이 워크플로우의 유일한 조건은 강력한 코드 모델(Code Model)에 대한 API 키를 보유하는 것입니다. provod.ai 링크는 참고용으로 제공되었습니다. 연결 방식에 대해서는 모델 섹션에서 다시 다루겠습니다.

AutoCAD에서 스스로 도면을 그리는 신경망이 존재하는가?

짧게 답하자면: 아니요, 그리고 2026년 현재 세 가지 측면 모두에서 그것이 확인됩니다. AutoCAD 2026의 공식 기능 페이지(2026년 7월 19일 확인)를 보면, 모든 “인공지능(AI)”은 생성기가 아닌 정리 및 레이아웃을 위한 어시스턴트 수준입니다. Neural CAD가 발표되었으나 아직 사용할 수 없습니다. 학술적인 Text-to-CAD는 단순한 기하학적 구조에서만 작동합니다.

Neural CAD는 Autodesk University 2025에서 공개되었습니다. 이 모델은 텍스트 프롬프트(Prompt)로부터 편집 가능한 CAD 기하학 구조를 구축하며, 1,000만 개의 3D 형상을 학습한 실험적 프로젝트인 Project Bernini에서 발전했습니다. 당신이 찾고 있는 바로 그것처럼 들립니다. 하지만 2026년 중반 기준으로 이는 공개적으로 사용할 수 없는 상태입니다. 즉, 도구가 아니라 발표된 계획일 뿐입니다.

과학계 또한 이 문제를 종결짓지 않았습니다. DFKI의 Text2CAD (NeurIPS 2024)는 텍스트로부터 파라메트릭 CAD 모델 (parametric CAD models)을 생성하는 최초의 프레임워크로, 약 17만 개의 모델과 60만 개의 어노테이션 (annotations)이 포함된 DeepCAD 데이터셋으로 학습되었습니다. 출력 결과는 '스케치(sketch) + 돌출(extrude)' 시퀀스로, 기하학적으로 단순한 부품들입니다. 평면도(floor plan)를 이런 방식으로 구성할 수는 없습니다.

AutoCAD 2026에서 AI가 실제로 할 수 있는 것은 무엇인가?

요약하자면: 이미 존재하는 도면 주변의 반복적인 루틴을 가속화합니다. 즉, 객체를 찾고, 이를 블록 (blocks)으로 묶으며, PDF에서 수정 사항을 가져오는 작업입니다. 처음부터 도면을 생성하지는 못합니다. 다음은 2026년 7월 19일 기준 Autodesk의 공식 페이지를 바탕으로 한 요약입니다.

Autodesk는 AutoCAD 2025 대비 파일 열기 속도는 최대 11배, 실행 속도는 최대 4배 빠르다고 주장합니다. 이는 독립적인 측정이 아닌 벤더(vendor)의 주장이며, 인터페이스 속도에 관한 것입니다. 내장된 모든 자동화 기능은 정리 및 재사용에 초점이 맞춰져 있습니다. 즉, 타인의 DWG 파일을 정리하는 데 드는 한 시간은 절약할 수 있지만, 새로운 도면을 그리는 데 드는 8시간은 절약할 수 없습니다.

왜 "도면 이미지를 생성해줘"는 막다른 길인가?

요약하자면: 도면은 이미지가 아니라 레이어 (layers), 선 유형 (line types), 공차 (tolerances), 그리고 표준(GOST)에 따른 도면 테두리와 표제란 (title block)을 포함하는 정밀한 구조입니다. 이미지 기반 모델은 유사한 모사물을 내놓지만, 이는 DWG로 열리지 않으며 규격 검토 (normative control)를 통과할 수 없습니다. 이러한 결과를 이미 '뉴로슬롭 (neuroslop)'이라고 부르기 시작했습니다.

Text2CAD-Bench 벤치마크 (2026년 5월)는 이를 체계적으로 검증했습니다: 600개의 수동 선정 사례, 기초 기하학(L1-L2)부터 위상 구조(L3) 및 응용 도메인(L4)에 이르는 4단계 난이도로 구성되었습니다. 저자들의 결론은 다음과 같습니다: 현대의 LLM (Large Language Models)은 기초 기하학에서는 수용 가능한 수준을 보여주지만, 복잡한 위상 구조와 고급 연산에서는 성능이 현저히 저하됩니다.

과업을 혼동하지 마십시오. 당신의 설명에 따라 벽면의 채색을 수행하거나 셀카를 연필화 스타일로 변형하는 모델은 장식적인 과업을 해결하는 것이며, 이를 아주 잘 수행합니다. 하지만 이 모델은 ESKD(Unified System for Design Documentation) 표준에 따른 도면을 그려내지는 못할 것입니다. 그곳에는 붓터치가 아닌 밀리미터(mm)와 레이어(Layer)가 존재하기 때문입니다. 이는 '아름다운 것'과 '정확한 것'이 갈라지는 전형적인 상황 중 하나입니다.

그렇다면 왜 코드는 작동하는 것일까요? LLM은 본래 텍스트에 최적화되어 있습니다. 프롬프트(Prompt), 문서(Documentation), 프로그램의 로보텍스트(Robotext)는 LLM의 모태가 되는 환경입니다. 반면 B-Rep(Boundary Representation) 토폴로지는 그렇지 않습니다. 즉, 도면을 텍스트 형식으로 변환해야 한다는 뜻입니다. 그리고 이를 위한 준비는 이미 오래전에 끝났습니다.

실무적 우회 방법: 도면은 곧 코드다

요약하자면, 도면 코드의 실행기는 현대의 모든 AutoCAD에 기본적으로 내장되어 있습니다. AutoLISP는 이미 1980년대 중반 Release 2.1 버전부터 API로 등장했으며, LT 2024 버전부터는 저가형 에디션에도 포함되어 있습니다. 이제 남은 것은 신경망이 이 언어로 글을 쓰도록 만드는 것입니다.

구조는 간단합니다. 모델이 설명을 스크립트(Script)로 변환하면, AutoCAD나 라이브러리가 이를 실행합니다. Python 라이브러리인 ezdxf(최신 버전 1.4.4, 2026년 5월 14일 문서 업데이트)는 R12-R2018 버전의 DXF 문서를 생성, 읽기 및 쓰기 할 수 있습니다. 즉, LLM이 Python을 작성하면 결과물로 AutoCAD가 변환기 없이도 이해할 수 있는 파일이 나옵니다.

두 번째 경로는 모델을 도면 환경과 연결하는 MCP(Model Context Protocol)입니다. 이 연결 샘플을 누가 게시했는지를 보면 시사하는 바가 큽니다. 바로 Autodesk Developer Network가 직접 게시했습니다. adn-mcp-autocad 플러그인(2026년 3월 3일 업데이트, MIT 라이선스)은 Claude를 AutoCAD 2025+에 직접 통합합니다. 자연어가 XData 및 확장 사전(Extension Dictionaries) 작업으로 변환되며, Anthropic API 키는 Windows DPAPI를 통해 로컬에 암호화된 상태로 저장됩니다.

커뮤니티의 생생한 증거 - puran-water/autocad-mcp 프로젝트: Claude가 자연어 요청에 따라 AutoLISP를 실행하는 AutoCAD LT용 MCP 서버입니다. 내부적으로는 ezdxf 기반의 백엔드, 실행 취소/다시 실행 (undo/redo), 그리고 P&ID 심볼(CAD Tools Online의 600개 이상의 표기법)을 지원합니다. Claude Desktop 및 Claude Code와 함께 작동합니다.

동일한 패턴이 인접한 CAD 분야에서도 나타납니다. Fusion 360용 CADAgent 애드인(Add-in)의 경우: 부품을 간단한 영어로 설명하면 Claude가 Fusion 360 API 호출 체인을 생성하며, CAD 내부에서 '맹목적인' STEP 파일이 아닌 편집 가능한 피처 트리(feature tree)를 가진 네이티브 파라메트릭 모델 (parametric model)이 구축됩니다. 또한 Zoo는 text-to-CAD를 Zoo Design Studio의 대화형 에이전트인 Zookeeper로 발전시켰습니다. 결론은 하나입니다: CAD 환경 내부에서의 생성이 외부에서의 기하학적 형상 (geometry) 임포트보다 우수합니다.

spec-driven development란 무엇이며 requirements.md와 어떤 관련이 있는가?

요약하자면: 이는 사양 (specification)이 인간과 AI 모두에게 일차적인 산출물 (artifact)이자 진실의 원천 (source of truth)이 되는 방법론입니다. 코드는 사양을 바탕으로 작성되며, 그 반대가 아닙니다. 지난 1년 동안 이 개념은 아이디어 단계에서 AWS 및 GitHub의 도구들로 발전했습니다.

연혁. 2025년 7월 14일, AWS는 개발자들을 'vibe coding에서 프로덕션 준비 완료 (production-ready) 시스템으로' 인도하기 위한 에이전트형 IDE인 Kiro를 퍼블릭 프리뷰로 출시했습니다. 2025년 8월 21일, GitHub은 MIT 라이선스 기반의 Spec Kit을 공개했습니다. 2026년 7월 17일 기준으로 이 프로젝트는 122,205개의 스타를 기록했으며 30개 이상의 코딩 에이전트 (Claude Code, Copilot, Cursor 등)를 지원합니다. 2025년 10월 15일에는 martinfowler.com에 Thoughtworks의 Birgitta Böckeler이 작성한 정전 (canonical) 분석 글이 게시되었습니다. 그리고 2026년 6월 25일, 안정적인 Kiro IDE 1.0이 출시되었습니다 (동시에 Amazon은 Q Developer의 지원을 2027년 4월 30일에 종료하며 서비스를 축소하고 있습니다).

메커니즘은 모두 동일합니다. 세 개의 파일로 구성됩니다. Kiro의 문서에 따르면 각 스펙 (spec)은 requirements.md (스토리 및 수락 기준 (acceptance criteria)), design.md (아키텍처 및 테스트 전략), tasks.md (이산적인 추적 가능한 작업)를 생성합니다. 프로세스는 엄격하게 Requirements, Design, Tasks의 3단계로 진행됩니다. Spec Kit도 동일한 파이프라인을 따릅니다: /speckit.specify -> /speckit.plan -> /speckit.tasks -> /speckit.implement. Böckeler는 성숙도 수준을 추가했습니다: spec-first, spec-anchored, spec-as-source. 그리고 수락 기준 (acceptance criteria)의 형식은 EARS를 사용합니다: "<이벤트>가 발생할 때, <조건>이라면, 시스템은 <동작>해야 한다". 이 구조를 기억해 두세요. 다음 섹션에서 유용하게 쓰일 것입니다.

도면을 위한 requirements.md를 작성하는 방법

요약하자면: 가장 까다로운 실행자를 위한 기술 사양서 (technical specification)와 같습니다. 여섯 가지 부분으로 구성되며, 템플릿을 복사하여 채워 넣을 수 있습니다.

1. 목적: 어떤 도면인지, 축척, 시트, 대상 사용자.
2. 레이어 (layers) 및 용도: "벽체", "전기", "치수" 등 - 각 레이어의 색상과 선 유형 포함.
3. 프리미티브 (primitives) 및 치수: 어떤 객체인지, 어떤 좌표에 있는지, 어떤 허용 오차를 갖는지.
4. 블록 (blocks) 및 프레임: 표준 기호, ESKD 스탬프, 본인의 라이브러리에서 가져오는 항목.
5. EARS 형식의 수락 기준 (acceptance criteria): "스크립트가 실행되었을 때, AutoCAD 2026에서 파일을 열면, 도면은 오류 없이 열려야 하며 '벽체' 레이어에 지정된 수의 객체가 포함되어 있어야 한다."
6. 금지 사항: 예를 들어, 기존 레이어를 건드리지 말 것, 시트의 치수를 벗어나지 말 것 등.

실무적인 두 가지 조언입니다. 첫째: 편집장이 타인의 글을 검토하듯 스펙 (spec)을 읽으세요. 모든 중의적인 해석은 기하학적 오류가 됩니다. 둘째: 문구가 잘 떠오르지 않는다면, 동일한 모델에게 유의어 작성을 요청하세요. 요구 사항을 세 번 재진술하게 한 뒤, 가장 명확한 것을 선택하십시오.

zoo.dev의 "Prompt like a Pro" 섹션(2026년 7월 19일 검증됨)은 디테일이 얼마나 근본적인 차이를 만드는지 보여줍니다. 모호한 "맨홀 뚜껑(a manhole cover)"과 "들어올리기 위한 절개 홈이 있고, 직경 600mm, 두께 50mm이며, 중앙에 200mm 구멍이 있는 맨홀 뚜껑(a manhole cover with cuts for lifting, 600mm diameter, 50mm thick, with a 200mm hole in the middle)"이라는 사양(Specification)을 비교해 보십시오. 즉, 절개 홈이 있고 직경 600mm, 두께 50mm, 중앙에 200mm 구멍이 있는 맨홀 뚜껑입니다. 두 번째 옵션은 정확한 기하학적 구조(Geometry)를 제공하지만, 첫 번째 옵션은 무엇이 나올지 알 수 없습니다. 여러분의 requirements.md는 이 아이디어를 하나의 문서로 확장한 것과 같습니다.

이 파이프라인(Pipeline)에 어떤 모델을 연결해야 할까요?

요약하자면: 러시아에서 API 접근이 가능한 강력한 코드 모델(Code model)이면 무엇이든 가능합니다. 이러한 접근 방식에 대한 수요는 검색 결과에서도 확인할 수 있습니다. "분자(Molecule) 신경망 애그리게이터(Aggregator)"라는 검색어와 그에 대한 리뷰를 보면, 사람들이 여러 모델에 접속할 수 있는 단일 진입점을 찾고 있음을 알 수 있습니다. 아래 목록은 2026년 7월 기준으로 유효합니다.

러시아에서는 단 두 줄, 즉 키(Key)와 통합 API인 provod.ai의 base_url만 변경하면 전체 스키마가 작동합니다. 이 API는 OpenAI SDK (/v1/chat/completions) 및 Anthropic (/v1/messages)와 모두 호환되므로, MCP 서버, IDE 및 자체 스크립트를 코드 수정 없이 그대로 사용할 수 있습니다. 다섯 개의 키 대신 하나의 키만 사용하며, 러시아 카드로 결제하거나 법인의 경우 계약 및 증빙 서류를 통해 계좌 이체가 가능합니다. 이는 설계 사무소가 세계적인 모델들에 접근할 때 겪는 주요 관료적 절차를 해결해 줍니다.

from openai import OpenAI

client = OpenAI(
...

이 코드 조각은 파이프라인의 핵심입니다. 여러분의 requirements.md를 읽고 모델에게 ezdxf를 사용하는 스크립트를 작성하도록 요청합니다. 응답을 .py 파일로 저장하고 실행하면 AutoCAD에서 네이티브로 열 수 있는 DXF 파일을 얻게 됩니다. 모델은 한 줄만 바꾸면 되며, 사양(Spec)은 코드 수정 없이 변경할 수 있습니다.

이 접근 방식이 해결하지 못하는 것은 무엇인가요?

요약하자면: 복잡한 3D 위상 구조(Topology), 엔지니어링 전문 지식, 그리고 서명에 대한 책임입니다. 솔직하게 말해 바로 짚고 넘어가야 할 다섯 가지 한계점입니다.

• 복잡한 기하학(Geometry). Text2CAD-Bench에 따르면 모델은 자유 곡면(Free surfaces)과 응용 도메인에서 성능이 저하됩니다. 신경망은 노래를 몇 초 만에 스템(Stems)으로 분리할 수 있지만, 도면을 '귀로 듣듯이' 레이어로 분리할 수는 없습니다. 오직 사양(Spec)과 반복(Iteration) 작업만이 가능합니다.
• 전문 지식 및 서명. GOST(러시아 국가 표준), 규격 검토(Normocontrol), 그리고 도면 표제란(Stamp)의 서명은 여전히 인간의 영역입니다.
• 코드 내 환각(Hallucinations). 오류가 있는 스크립트는 객체를 무분별하게 생성하거나 조용히 좌표를 이동시킬 수 있습니다. 반드시 파일 복사본에서 실행하십시오.
• 기밀성. 사양(Spec)이 외부 모델로 전송됩니다. 영업 비밀을 다루려면 권한 분리가 이루어진 기업용 폐쇄망(Corporate contour)이 필요합니다.
• 비용. 매 반복마다 토큰(Tokens) 비용이 발생합니다. 모호한 사양은 불필요한 실행 횟수만 늘려 비용을 낭비하게 합니다.

provod.ai가 적합하지 않은 경우는 언제인가요?

요약하자면: 작업이 '접근성, 결제, 단일 API'의 결합 범위를 벗어날 때입니다. 애그리게이터(Aggregator)가 필요 없거나 도움이 되지 않는 네 가지 시나리오입니다.

• 귀하의 부서가 GigaChat에 표준화되어 있는 경우: provod.ai는 이를 제공하지 않으므로 Sber로 직접 가십시오.
• 기밀 프로젝트로 온프레미스(On-prem) 환경이 필요한 경우: 별도의 폐쇄망과 자체 하드웨어가 필요하며, 외부 API는 사용할 수 없습니다.
• Autodesk의 생성형 Neural CAD를 기다리는 경우: 어떤 애그리게이터도 이를 제공할 수 없습니다. 해당 기능은 발표되었으나 현재 어디에서도 사용할 수 없습니다.
• 귀하의 부품 및 블록에 맞춘 자체 모델의 미세 조정(Fine-tuning)이 필요한 경우: 이는 채팅이나 API의 문제가 아니라 리포지토리(Repository)와 GPU의 문제입니다.

클러스터 쿼리 사전

요약하자면: '도면용 신경망' 주변의 검색 결과가 인접한 의도(Intents)들로 오염되어 있습니다. 사람들이 무엇을 함께 검색하는지, 그리고 왜 그것들이 다른 주제인지 설명합니다.

오타나 발음대로 검색되는 챗봇들: