AI는 어디서 멈추는가
‘AI가 곧 다 하게 될 텐데 지금 소프트웨어를 도입할 필요가 있나.’ 이 질문을 부정하는 것으로 시작하지 않겠습니다. 실제로 많은 것이 대체되고 있습니다. 다만 어디까지 왔고 어디서 멈추는지는 정확히 볼 필요가 있습니다.
게시 2026년 8월 10일·확인 시점 · 2026년 8월
핵심 요약
- 자연어로 Revit에 벽·바닥·지붕·개구부를 만드는 제품은 이미 팔리고 있습니다 — 철근에 대한 언급은 그 제품 페이지 어디에도 없습니다
- 건설업 AI 도입은 사무·관리 45%, 설계 20% — 설계 안에서도 지금 자동화된 것은 형상을 만드는 일입니다
- Revit API에는 철근 생성 기능이 있습니다. 문제는 그 API가 호출자에게 무엇을 이미 알고 있으라 요구하는가입니다
- 이음 길이·정착 길이·피복·이음 위치를 계산하는 인자는 API에 없습니다 — 호출하는 쪽이 정해서 넣어야 합니다
- 그래서 프롬프트든 MCP든 Dynamo든 같은 벽을 만납니다. 자동화된 것은 실행이지 판단이 아닙니다
1먼저, AI는 실제로 여기까지 왔다
부정하고 시작하면 논의가 되지 않습니다. 1차 생성 — 데이터를 만드는 단계 — 에서도 변화는 이미 시작됐습니다. 실물 제품이 있습니다.
“Upload building photos, PDFs, or sketches, and let Claude create native walls, floors, roofs, doors, and windows directly in Revit.”
“Tell Claude ‘add a third floor with six windows’ — and watch it happen.”
— MCP 서버 번들, Revit 2025–2027 지원.
자연어로 Revit 모델이 생깁니다. 마케팅 문구가 아니라 실제 판매되는 제품입니다. 그런데 같은 페이지에 벤더 자신이 이렇게 적어 두었습니다 — “REVIEW & REFINE — Verify dimensions and element placement against field measurements before advancing the model into documentation.”(치수와 요소 배치를 실측과 대조해 검증한 뒤 문서화 단계로 넘기십시오)
그리고 이 제품이 만드는 것은 매스 · 벽 · 바닥 · 지붕 · 개구부입니다. 철근이나 구조 상세에 대한 언급은 제품 페이지 어디에도 없습니다.
도입률도 문항까지 같이 봐야 합니다. 이 분야는 특히 그렇습니다.
| 조사 | 수치 | 읽을 때 주의 |
|---|---|---|
| AGC of America + Sage 2026 Construction Hiring and Business Outlook 2025-11-04~12-15 · 49개 주 · n=951 | “61%가 AI를 쓰거나 투자를 늘릴 계획” 사무·관리 45% · 적산 23% · 설계/시공 전 단계 20% · HR 16% | 61%는 도입률이 아니라 ‘쓰거나 계획’의 합산. 실제로 볼 숫자는 설계 영역 20%이고, 사무 45%의 절반 이하 |
| Autodesk 2026 State of Design & Make: AI Pulse Statista Plus Research · 2026-01~02 · n=2,500 | “AI 도구를 하나라도 쓴다” 거의 100% “얼리 어답터” 19%(n=469) | 앞의 수치는 문항이 “AI가 포함된 도구를 쓰는가”라 벤더의 기능 탑재율을 잰 것에 가깝다. 의미 있는 숫자는 19% — 실제 워크플로에 통합한 비율 |
AI는 실제로 오고 있습니다. 다만 지금 도착한 곳은 사무·관리이고, 설계 안에서 자동화된 것은 형상을 만드는 일입니다.
2Revit API는 철근 생성을 지원한다
사실을 정확히 해 둡니다. Revit API에는 Autodesk.Revit.DB.Structure.Rebar 클래스가 있고, Rebar.CreateFromCurves · CreateFromCurvesAndShape로 철근을 생성할 수 있습니다. Autodesk 개발자 가이드에 Reinforcement 절이 따로 있습니다. 즉 ‘API에 철근 기능이 없어서 안 된다’가 아닙니다.
그렇다면 왜 아직 아무도 자연어로 배근을 팔지 않을까요. 답은 그 API가 호출자에게 무엇을 요구하는지를 보면 분명해집니다.
3API 시그니처가 곧 ‘AI가 정해주지 않는 것들의 목록’이다
Rebar.CreateFromCurvesAndShape가 요구하는 인자입니다. Autodesk 공식 API 문서 그대로입니다.
| 인자 | 공식 문서의 설명 | 실무에서 이것은 |
|---|---|---|
| rebarShape | “A RebarShape element that defines the shape of the rebar” | 철근을 어떤 형상으로 굽힐지 — 이미 정해져 있어야 함 |
| barType | “defines bar diameter, bend radius and material” | 직경 · 굽힘 반경 · 재질 |
| startHook / endHook | “defines the hook for the start of the bar”, or null | 후크 종류 — 90°인지 135°인지 |
| curves | “An array of curves that define the shape of the rebar curves” | 철근이 지나갈 경로 자체 |
| startHookOrient / endHookOrient | Right 또는 Left | 후크가 향하는 방향 |
| hookRotationAngleAtStart / AtEnd | “The out of plane hook rotation angle” | 면 밖 회전각 |
| host | “The element to which the rebar belongs” | 어느 부재에 속하는가 |
이 목록에 없는 것을 보십시오. 이음 길이를 계산하는 인자가 없습니다. 정착 길이를 산출하는 인자도 없습니다. 피복을 판단하는 인자도, 이음 위치를 정하는 인자도 없습니다.
API는 “이 경로를 따라 이 형상, 이 후크로 철근을 놓아라”는 실행을 해 줍니다.
그 경로와 후크를 무엇으로 할지는, 호출하는 쪽이 이미 알고 있어야 합니다.
4그래서 프롬프트도, MCP도, Dynamo도 같은 벽을 만난다
Revit을 자동화하는 경로는 여럿이지만 도착지는 하나입니다. 자연어 프롬프트 · MCP 서버 · Dynamo 그래프 · C# 애드인 — 전부 Revit API를 거쳐 모델에 도달합니다. 그리고 그 지점에서 요구하는 값들은 누가 만들어 넣든 똑같습니다.
Dynamo도 예외가 아닙니다. Dynamo 공식 문서는 Dynamo 노드가 Revit 요소를 가리키는 래퍼이며 “Dynamo 통합자가 어떤 Host API를 노드로 노출할지 선택한다”고 적고 있습니다. Dynamo로 할 수 있는 일은 Revit API가 허용하는 범위 안입니다.
즉 도구를 바꿔도 질문은 남습니다. “이 철근의 후크는 90°인가 135°인가?” 프롬프트를 아무리 잘 써도, 이 값을 아는 사람이 없으면 어떤 도구도 답을 만들어내지 못합니다.
5‘건물 한 동을 자동배근해줘’가 한 번에 안 되는 이유
AI에게 이렇게 시키면 무슨 일이 벌어지는지 생각해 보면 명확합니다. AI는 되묻기 시작합니다 — 콘크리트 강도는? 철근 직경은? 피치는? 이음은 겹침인가 기계식인가? 정착 길이 기준은?
그리고 이 질문들에 답할 수 있는 사람은 이미 배근을 아는 사람입니다. 답할 수 있다면 AI가 없어도 할 수 있고, 답할 수 없다면 AI가 있어도 할 수 없습니다.
출처
본 글은 공표된 자료를 바탕으로 작성한 정리이며, 법령 해석이나 자문이 아닙니다. 제도는 수시로 바뀌므로 실제 적용 시에는 원문과 소관 기관의 최신 공지를 확인하시기 바랍니다.