생성 AI(Cursor나 GitHub Copilot, Claude 등)의 보급으로 인해, 엔지니어와 비엔지니어를 불문하고 애플리케이션이나 자동화 도구를 경이적인 속도로 개발할 수 있는 시대가 되었습니다. 분위기와 기세로 코드를 써 내려가는 「바이브 코딩 (Vibe Coding)」은 아이디어를 최속으로 형태화하는 수단으로서 압도적인 가치를 지니고 있습니다.

한편, 개발 속도가 가속화된 결과 다음과 같은 과제에 직면하는 현장도 늘어나고 있습니다.

파악할 수 없는 「야생 앱 (Wild App)」의 난립

테스트나 리뷰를 통한 품질 담보가 따라가지 못하는 코드 생성

사양을 언어화·설명할 수 있는 사람이 아무도 없어지는 리스크

이 구도는 과거 Excel VBA(매크로)가 현장 주도로 폭발적으로 보급되었고, 그 후에 「블랙박스화 (Black-boxing)」가 문제가 되었던 시대(EUC: 엔드 유저 컴퓨팅의 전성기)와 매우 흡사합니다.

본 기사에서는 바이브 코딩이 가진 「폭속으로 형태화하는 힘」을 최대한 활용하면서도, 과거의 VBA 난립과 같은 기술적 부채가 되지 않기 위해 우리가 과거의 역사로부터 무엇을 배우고, 어떻게 시스템이나 구조로 받아들여야 할지를 고찰합니다.

2000년대부터 2010년대에 걸쳐 많은 일본 기업에서 「Excel 매크로 (VBA)」가 업무 도구로서 널리 사용되었습니다. 정식 시스템 개발 예산이나 리드 타임(Lead time)을 맞출 수 없는 현장이 자신들의 PC 상에서 도구를 만듭니다. 이를 **EUC (엔드 유저 컴퓨팅, End-User Computing)**라고 부릅니다.

현장에게 Excel은 친숙한 도구였습니다. 스프레드시트 화면 그대로 버튼 하나로 집계나 장표 출력을 할 수 있습니다. IT 부문의 승인을 기다리지 않고 고민거리를 그날 안에 해소할 수 있습니다. 이러한 「즉효성」이 매크로 파일의 증식을 뒷받침했습니다.

하지만 몇 년이 지나면 다음과 같은 상태에 빠지기 일쑤였습니다.

• 「영업관리표(최신)」, 「영업관리표(수정판_다나카)」와 같이 파일이 난립함
• 수천 행에 달하는 VBA를 작성한 담당자만이 만질 수 있음
• 해당 담당자가 이동·퇴직하면 업무가 중단됨
• 경영 판단에 사용하는 수치의 근거를 아무도 설명할 수 없음

결과적으로 정보시스템 부서나 SIer에게 「매크로 해석 및 시스템화」를 의뢰하는 안건이 늘어났습니다. 해석만으로 수백만 엔 규모, 본격적인 이행에는 수천만 엔 규모가 되는 일도 드물지 않습니다.

바이브 코딩이란 생성 AI에게 자연어로 지시를 내리고, 나온 코드를 그대로 실행하며 형태를 만들어가는 개발 스타일입니다. Cursor나 GitHub Copilot, Claude 등의 도구가 보급되면서 비엔지니어도 Web 앱이나 사내 도구를 며칠 만에 구축하는 사례가 늘고 있습니다.

VBA 시대와 마찬가지로 동기는 「정식 개발 프로세스를 기다릴 수 없다」는 것입니다. 벤처 기업에서는 특히 소수 인원으로 MVP를 서둘러 검증을 먼저 진행하고 싶은 압력이 강합니다. AI는 그 압력에 부응하는 최속의 수단이 될 수 있습니다.

단, 생성된 코드에는 다음과 같은 리스크가 뒤따릅니다.

• 작성한 본인이 로직을 설명할 수 없음
• 테스트·리뷰·권한 설계가 생략됨
• API 키나 DB 접속 정보가 그대로 코드에 매립될 가능성
• 클라우드에 공개되는 순간부터 사외에서 액세스 가능해짐

처음에는 「사내의 작은 편리한 도구」였던 것이 어느샌가 고객 데이터를 다루는 본방 서비스(Production Service)가 되어 있습니다. VBA 시대의 「야생 Excel」이 이번에는 「야생 SaaS」로서 늘어날 가능성이 있습니다.

VBA 난립과 바이브 코딩에는 구조적으로 다음과 같은 공통점이 있습니다.

매크로도 AI 생성 코드도 겉보기에는 작동합니다. 하지만 입력 체크·예외 처리·권한·감사 로그가 결여된 채 운용되면, 망가지는 방식을 알 수 없는 상태가 됩니다. VBA 시대에 「검산할 수 없는 집계 매크로」가 문제가 되었던 것과 같은 구도입니다.

작게 시작한 도구일수록 방치되었을 때의 개수 비용(改修コスト)이 불어납니다. SMBC 닛코 증권의 사례에서는 Excel 매크로로 속인화(属人化)되어 있던 업무를 로우 코드(Low-code) 개발 기반으로 이관하여, 블랙박스화 해소와 리스크 관리 강화를 도모하고 있습니다 (TechTarget Japan 보도). 「나중에 고친다」는 선택은 반드시 저렴하지는 않습니다.

「만드는 사람이 주의하면 괜찮다」는 운영 방식은 인원과 시간이 늘어날수록 파탄에 이릅니다. VBA 시대에도 「매크로 금지 사내 규칙」을 세운 기업은 있었으나, 현장의 반발이나 형식화로 인해 효과가 미미해진 사례도 많았습니다. 시스템으로 묶어두지 않는 한, 같은 문제는 반복됩니다.

기술적으로 「작동하는」 것과, 업무 규칙으로서 올바른 것은 별개입니다. VBA 난립이든 바이브 코딩 (Vibe Coding)이든, 나중에 문제가 되는 것은 후자인 경우가 많다고 저는 느끼고 있습니다.

VBA 시대의 전형적인 사례는 성과급 계산, 경비 안분, 마감일 처리와 같은 도메인 특화 계산 (Domain-specific calculation) 입니다. 셀 참조와 If 문이 수백 줄씩 겹쳐진 매크로는, 작성자에게 「왜 이 식인가?」라고 물어도 답변이 애매한 경우가 있었습니다. 감사나 경리 부서에서 「이 숫자의 근거는 무엇인가?」라고 물어도, 코드를 다시 읽어보는 것만으로는 설명이 부족합니다. 결과적으로, 검산용 별도 Excel을 준비하여 「출력이 일치하면 맞다」라고 운영했다는 이야기도 들립니다.

바이브 코딩에서도 구도는 같습니다. 「월말 마감으로 미지급금을 집계해줘」, 「소비세는 내포세(Tax included)로 계산해줘」와 같은 프롬프트(Prompt)를 통해 AI가 비즈니스 로직을 생성합니다. 하지만 프롬프트에 적혀 있지 않은 예외 상황(반품, 할인, 단수 처리)은 AI의 추측에 맡겨지기 쉽습니다. 작성자가 도메인을 깊이 이해하고 있지 않다면, 사양서도 수락 테스트(Acceptance Test)도 없이 실무에 투입하게 됩니다.

두 경우 모두 공통점은, 「누가, 어떤 업무 규칙에 근거하여 올바르다고 판단했는가」라는 증적(Evidence)이 남지 않는다는 점입니다. 코드 리뷰가 있더라도 도메인의 올바름까지는 담보할 수 없습니다. 경영 판단이나 컴플라이언스(Compliance)와 관련된 처리일수록 이러한 결여는 치명적이 됩니다.

비슷하면서도, 바이브 코딩에는 VBA 시대에는 없었던 특성도 있습니다.

VBA에서도 「어느샌가 업무의 본체가 되어 있었다」는 사례는 있었습니다. 하지만 AI 시대에는 그 속도가 한 단계 더 올라가 있습니다. 프로토타입(Prototype)과 본 운영 사이에 「재고 조사·리뷰·이행 판단」의 시간을 끼워 넣을 여유가 조직 측에 남기 어렵습니다. 이것이 가장 큰 차이점이라고 저는 생각합니다.

Excel 매크로는 원칙적으로 사내 파일 범위 내에서 완결되기 쉬웠습니다. 반면, Next.js나 Supabase를 AI로 생성하여 Vercel에 배포하면, 설정 실수 하나로 인터넷상에 공개됩니다. 보안 문제는 「사내 Excel 파일」에서 「전 세계에 보이는 서비스」로 스케일(Scale)할 수 있습니다.

최근에는 생성 AI를 사용하여 VBA 코드로부터 사양을 복원하는 수법도 현실적인 비용 범위 내로 들어왔습니다. 분석은 쉬워지는 한편, 왜 그런 설계가 되었는지 또는 본 운영을 견딜 수 있는지에 대한 판단은 여전히 인간의 책무입니다. 도구가 진화해도 거버넌스(Governance)의 필요성 자체는 사라지지 않습니다.

VBA 난립에 대한 대책은 크게 세 가지 접근 방식으로 정리할 수 있습니다.

참고: 자동화닷컴(自動化ドットコム)의 정리

IT 부서가 규칙을 정하고 현장의 작성 및 개수를 제어하는 방법입니다.

• 매크로 포함 Excel 재고 조사 (파일명, 작성자, 이용 빈도, 중요도)
• 신규 매크로 작성 원칙적 금지, 예외는 승인 프로세스 적용
• 편집 권한 제한, 공유 폴더 통제
• 처리 개요서, 개수 이력, 에러 대응 절차 필수화
• 매크로 활성화 정책, 디지털 서명 검토

효과: 비용을 억제하면서 증식 속도를 늦출 수 있음

한계: 현장의 반발, 규칙의 형식화, 「금지되었기에 오히려 개인 PC에 보관한다」는 역효과

전부 버리지 않고 Excel 상에서 품질을 높이는 방법입니다.

• 코드의 모듈 분할, 주석 및 명명 규칙(Naming Convention) 통일
• 공통 라이브러리화, 버전 관리(Git 등) 도입
• Office Scripts나 Power Automate로의 단계적 이행
• 생성 AI를 통한 VBA 분석 및 사양서 복원

효과: 기존 자산을 활용하면서 종속성(Person-dependency)을 완화할 수 있음

한계: Excel의 구조적 한계(동시 편집, 권한, 감사)는 남음

근본적인 해결책으로서 Web 시스템, SaaS, 로우코드(Low-code) 기반으로 옮기는 방법입니다.

• 중요 업무부터 우선적으로 Web화 (권한 관리, 변경 이력, 동시 이용)
• 기존 매크로와 병행 운영하며 수치 일치를 검증한 후 전환
• SIer나 내재화 팀에 의한 본 개발, 로우코드(OutSystems 등) 활용
• 이행 후에는 「Excel 매크로 신규 작성 금지」를 철저히 시행

효과: 개인화(属人化), 파일 난립, 보안 리스크를 구조적으로 해소하기 쉽다

한계: 비용과 기간이 크다. 이행 대상 툴 자체가 새로운 개인화의 온상이 될 리스크도 있다

많은 기업은 A로 증식을 멈추고, B 또는 C를 통해 중요도가 높은 것부터 순차적으로 손을 댔습니다. 갑자기 전부를 시스템화하는 것이 아니라, 재고 조사(棚卸し) → 우선순위 설정 → 병행 운용 → 전환이라는 단계적인 진행 방식이 실패 사례 보고를 통해서도 반복적으로 언급되고 있습니다.

VBA 시대의 대책을 그대로 AI 개발에 사상(Mapping)하면 다음과 같습니다.

"AI를 사용하는 사람이 보안에 주의해 주세요" 정도로는 부족합니다. 다음과 같은 **시스템(仕組み)**이 유효합니다.

• 운영 환경 배포(Production Deploy) 권한을 IT 부문 또는 한정된 역할(Role)로 집약한다
• 시크릿(Secret)은 환경 변수로 관리하고, 코드에 직접 작성하는 것을 CI에서 탐지한다
• 고객 데이터를 다루는 툴은 처음부터 정식 리포지토리(Repository)와 리뷰 경로를 거치게 한다
• "프로토타입용"과 "운영용" 인프라를 분리한다

벤처 기업에서 MVP를 서둘러야 하는 필요성은 이해합니다. 하지만, 처음부터 관리 불가능한 곳에 두는 것과 나중에 옮길 수 있는 형태로 두는 것은 몇 년 후의 비용이 완전히 다릅니다. Git 관리, 환경 분리, 최소한의 README만이라도 정리해 두는 것만으로도 몇 년 후의 부담이 달라집니다.

동작 확인과 운영 환경 운용은 별개의 문제입니다. 권한 설계, 백업, 장애 발생 시의 연락처가 없다면 그것은 아직 시제품입니다.

VBA 시대와 마찬가지로, 금지만으로는 현장의 니즈를 없앨 수 없습니다. 대체 수단(정식 내재화 창구, 로우코드(Low-code), 단기 개발 프레임워크)이 없다면 섀도 IT(Shadow IT)는 지하화될 뿐입니다.

인수인계 비용은 만든 본인이 있을 때 기록하지 않을수록 치솟습니다. AI 생성 코드일수록 의도의 기록이 결핍되기 쉽습니다. 미뤄둔 설명 책임은 반드시 청구서가 되어 돌아옵니다.

지금까지 생성 AI가 섀도 IT의 증식을 가속화할 수 있는 측면을 써왔습니다. 하지만 동일한 기술은 문제 해결에도 쓰일 수 있습니다. VBA 시대에 고비용이었던 유지보수 활동의 일부는 이미 자동화되고 있습니다.

예를 들어, 개인화된 VBA 매크로를 해석할 때 "어떤 동작을 하는 코드인가"를 AI에게 정리하게 하고, 인간이 도메인 지식(Domain Knowledge)을 바탕으로 검증하는 방식은 현실적인 비용 수준으로 들어오고 있습니다.

바이브 코딩으로 태어난 코드에 대해서도 마찬가지입니다. README나 ADR(Architecture Decision Record)의 초안 작성, 테스트 관점의 나열, 보안상의 우려 지점 파악——기록과 검증의 토대 만들기는 AI가 담당할 수 있습니다.

단, 여기서 중요한 것은 역할 분담입니다.

• AI가 담당할 수 있는 것: 코드 판독, 문서화, 테스트 케이스의 초안 생성
• 인간이 담당해야 하는 것: 업무 규칙으로서 올바른지에 대한 최종 판단, 운영 환경 공개 승인

"비즈니스 도메인의 올바름"은 AI가 사양서를 작성한다고 해서 자동으로 증명되지 않습니다.

생성 AI는 설명 불가능한 것을 설명 가능한 것에 가깝게 만드는 도구이며, 거버넌스(Governance) 그 자체를 대신할 수는 없습니다.

문제를 만드는 쪽과 문제를 정리하는 쪽, 생성 AI는 양쪽 모두에 설 수 있습니다. 역사를 반복하지 않기 위해 필요한 것은 AI로 빠르게 만드는 것과 AI로 빠르게 정돈하는 것 모두를 시스템 안에 포함하는 것이라고 저는 생각합니다.

Excel VBA의 난립과 바이브 코딩은 둘 다 "현장의 즉효성"과 "조직의 통제" 사이에서 발생하는 동일한 유형의 문제입니다. 야생 앱(Wild App), 품질 미확보, 개인화, 파악 불가능——이것들은 새로운 현상이 아니라 EUC(End-User Computing) 시대부터 반복되어 온 패턴입니다.

결정적인 차이는 작성 속도의 빠름과 클라우드 공개에 따른 리스크의 확산입니다. 그렇기에 VBA 시대보다 더 빠른 단계에서 "재고 조사·규칙·이행 대상"을 결정해야 합니다.

당시 기업들이 배운 것은 금지만으로는 부족하며, 전부 한꺼번에 버릴 필요도 없고, 중요한 것부터 단계적으로 정식 시스템으로 옮겨야 한다는 점으로 요약됩니다. AI는 개발을 빠르게 만들지만, 책임의 소재를 없애주지는 않습니다.

저는 바이브 코딩 (Vibe Coding)을 부정하는 것이 아닙니다. 도구로서는 강력합니다. 다만, VBA 난립이 기업을 괴롭혔던 것과 동일한 조건——관리 외 자산의 증식, 설명 불가능한 로직, 추후 발생하는 높은 개수 비용(改修コスト)——이 더 짧은 주기로 재현될 수 있다고 생각합니다.

생성 AI (Generative AI)를 통해 현장 주도로 시스템을 만드는 힘은 과거 어느 때보다 강력해졌습니다.

그렇기에 중요한 것은 "만들 수 있는가"가 아니라 "만든 것을 어떻게 관리할 것인가"입니다.

VBA 시대에 발생했던 문제는 형태를 바꾸며 AI 시대에도 나타나고 있습니다.

역사는 반복될 수 있지만, 우리는 과거의 실패로부터 배울 수도 있습니다.

만드는 속도뿐만 아니라, 정돈하는 속도도 높이는 것.

그것이 AI 시대 거버넌스 (Governance)의 한 형태가 아닐까요?