Vibe 코딩을 활용한 AutoCAD 플러그인 제작기

Aug 10. 2025

안녕하세요 코드아키텍트입니다.

스리슬쩍 글을 쓰러 들어왔습니다.

정말 감사하게도, 구독자가 어느새 100명이 되었습니다. 글을 꾸준히 쓰겠다고 약속했지만 그 약속을 다 지키지 못한 저로서는 한편 부끄러운 마음이 큽니다.

최근에 쓴 글에서는 조회 수나 반응이 크지 않아서, 독자분들이 제 글에서 무엇을 보고 싶어 하는지 확신이 잘 서지 않았습니다. 그렇지만 곰곰이 생각해보면, 아마도 제가 직접 부딪히고 경험한 일들을 생생하게 풀어내는 글을 기대하실 것 같아요. 그런 관점에서 오늘은 제가 직접 테스트하고 체감한 내용을 풀어보려 합니다.

프로그래밍은 죽었다? — 바이브 코딩 이야기

요즘 프로그래밍 업계에서는 ‘vibe coding’이라는 단어가 심심치 않게 들립니다. 이 용어는 OpenAI 공동창립자이자 전(前) 테슬라 AI 디렉터인안드레이 카르파시(Andrej Karpathy)가 2025년 2월경 처음 화두를 던지며 유행을 탔습니다.

그가 말한 핵심은 간단합니다.

“코드가 존재한다는 사실조차 잊고, 목표와 의도를 말로만 전달하라. 나머지는 AI가 알아서 한다.”

(출처: Wikipedia — Vibe Coding)

즉, 사람이 프로그래밍 언어를 일일이 입력하는 대신, 자연어로 ‘내가 원하는 것’을 설명하면 AI가 코드로 구현해 주는 방법론입니다. 지금까지의 ‘코파일럿’이 보조자였다면, 바이브 코딩은 AI를 사실상 주 개발자로 두는 셈이죠.

물론 업계에서는 찬반이 갈립니다.

찬성 측: 프로토타입 제작 속도가 비약적으로 빨라지고, 소규모 팀이 대규모 팀의 생산성을 낼 수 있다는 점을 장점으로 듭니다.

반대 측: 코드 품질과 보안, 유지보수 문제에서 AI가 한계가 뚜렷하다는 점을 지적합니다.

저는 이번에 이 개념을 AEC(Architecture, Engineering, Construction) 업계에 직접 적용해 보았습니다.

AEC 업계에서의 바이브 코딩 가능성

바이브 코딩을 LLM(Large Language Model) 기반으로 한정해서 생각해 보겠습니다. LLM은 본질적으로 언어를 이해하고 생성하는 AI입니다.

사람의 언어가 한국어, 영어, 일본어처럼 다양하듯, 컴퓨터 언어도 Python, C#, C, JavaScript 등 여러 종류가 있죠. LLM이 이 언어들을 다룰 수 있다는 것은, 프로그래밍을 텍스트 처리 문제로 환원할 수 있다는 뜻입니다.

여기서 건축·엔지니어링 분야와의 연결 지점이 생깁니다. 우리가 눈으로 보는 형상을 컴퓨터에게 설명할 수 있다면, 그것은 곧 구조화된 텍스트로 변환 가능하다는 의미입니다. 예를 들어 눈앞에 있는 사각형을 ‘네 개의 점과 그 연결 관계’로 정의하면, LLM에게 이를 입력해 처리하게 만들 수 있습니다.

텍스트 기반 형상 표현의 한계

다만, 형상을 텍스트로 표현하는 일은 생각보다 어렵습니다.

데이터 양 문제 형상을 세밀하게 설명하려면 텍스트의 길이가 상당히 길어집니다. LLM이 한 번에 처리할 수 있는 정보량은 컨텍스트 윈도우(Context Window)에 제한을 받습니다. 이 한계를 넘으면 정보가 잘리거나 유실됩니다.

코드 생성 vs 직접 생성 형상을 직접 텍스트로 생성하는 것보다, Dynamo나 Grasshopper처럼 형상을 만들어내는 ‘틀’을 생성하게 하는 것이 훨씬 효율적입니다. 틀만 만들어 놓으면, 수치만 바꿔도 수십, 수백 가지 형태를 빠르게 생성할 수 있습니다.

AutoCAD 플러그인 테스트 경험

저는 ‘바이브 코딩으로 AutoCAD 플러그인을 어디까지 만들 수 있을까?’라는 궁금증이 생겼습니다. 그래서 조건을 간단히 제시했습니다.

사용 언어: C#

프레임워크: .NET

AutoCAD 버전: 명시

기대 결과: 특정 기능 구현

처음에는 깜짝 놀랄 정도로 잘 작동했습니다. 제 의도를 읽고 코드 골격을 빠르게 생성해 주었죠. 하지만 구현이 복잡해질수록 문제가 드러났습니다.

반복 출력: 같은 설명을 계속 반복하거나, 이미 생성한 코드를 다시 내보내는 경우

시각적 판단 불가: 예를 들어 Cursor(코딩 AI)는 CLI 출력은 잘 분석하지만, AutoCAD에서 생성된 형상을 보고 판단하는 건 불가능합니다. 사람이 직접 눈으로 보고 ‘어떤 문제가 있는지’ 설명해 줘야 합니다.

스파게티 코드 문제: 코드를 점점 얽히게 만들어 유지보수가 어렵게 되는 현상. 이를 막으려면 README나 설계 문서를 먼저 작성해두고, AI가 이를 참고하도록 유도하는 것이 필수입니다.

API 문서와 구현 방식

형상을 다루려면, 직접 알고리즘을 구현하기보다 해당 프로그램이 제공하는 API를 호출하는 방법이 훨씬 안정적입니다.

하지만 AI는 종종 API 문서를 무시하고 ‘스스로 구현하려’는 경향이 있습니다. 예를 들어 단순한 ‘선 자르기’ 기능도 API가 있음에도 불구하고, AI가 직접 수학적 연산을 구현하려다 실패한 경우가 있었습니다. 이런 때는 사람이 개입해 “이 문서를 참고하라”거나, “API 호출 방식으로 바꿔라”라고 지시해야 합니다.

이번 실험에서 얻은 교훈

핵심 업무에 집중 가능:
Geometry처럼 내가 잘하고, 하고 싶은 분야에만 집중하고, 주변적인 부분은 AI에게 맡길 수 있는 시대가 왔습니다.

최소한의 주도권 유지:
공자가 말했듯 ‘내가 무엇을 아는지 아는 것’이 중요합니다. 최소한 Pseudo Code 작성 능력과, 관련 API 이해는 필수입니다.

문서화 작업은 AI가 강점:
Mermaid, Ascii Art 등 시각 자료를 포함한 문서화는 AI가 빠르고 깔끔하게 처리합니다.

사람의 개입은 필수:
특히 AI가 잘못된 가정을 고집할 때, 이를 바로잡고 방향을 제시하는 역할은 사람이 해야 합니다.

멀티모달 AI의 3D 한계

멀티모달 AI는 언어, 이미지, 음성, 영상 등 다양한 데이터를 처리합니다(McKinsey). 그러나 3D 형상을 ‘보고’ 문제를 파악하는 단계까지는 아직 가야 할 길이 멉니다. 저는 이번 프로젝트에서 상당히 구체적인 Pseudo Code를 썼지만, 여전히 원하는 결과와는 거리가 있었습니다.

마무리 생각

어느 글에서 읽었는데, AI는 ‘상방을 확장하는 도구’가 아니라 ‘하방을 단단히 다지는 도구’라는 표현이 있었습니다. 정말 공감합니다. AI는 엔트리 레벨 업무를 빠르고 정확하게 처리해 줍니다. 그러나 그 이상의 창의적·고난도 작업에서는 여전히 한계를 보입니다.