바이브 코딩(Vibe Coding)이 'RPA 문제'를 재연하고 있다: 개인 의존·중복·블랙박스 방지를 위한 최소 거버넌스 설계

GMO Connect의 히라시마입니다.

팀에서 Claude Code를 사용하기 시작하면서, 편리해진 만큼이나 곤란한 상황이 발생하고 있습니다. "누군가 만든 것 같은 Slack 알림 도구", "비슷한 집계 스크립트가 3개나 있음", "만든 본인이 없으면 아무것도 알 수 없음" 😇

이 광경은 2019년경 RPA 보급기에도 본 적이 있는 것 같습니다. 그때 어떻게 극복했는지를 참고하여, 바이브 코딩(Vibe Coding) 시대의 오케스트레이션(Orchestration) 설계를 생각해 보았습니다.

발생하고 있는 일: 바이브 코딩에 의한 '그림자 AI 개발'이 확대되어, 개인 의존·중복·블랙박스화가 진행됨

구조적 유사성: RPA 보급기(2018~2020년)의 '현장 로봇 난립'과 동일한 패턴

필요한 대응책:

레이어	내용	최소 구성
카탈로그	무엇이 존재하는지 목록화	스프레드시트 1장
...

Claude Code나 Cursor로 앱을 만드는 비용이 낮아졌기 때문에, 개인 도구·사내 스크립트·자동화 봇이 급증하고 있습니다. 문제는 그것들이 개인의 로컬·개인의 GitHub 리포지토리·개인의 Slack 알림에 흩어진다는 점입니다.

"이 스크립트 누가 가지고 있지?"라는 대화가 발생하면, Slack 로그를 거슬러 올라가야 합니다.

바이브 코딩으로 태어난 도구의 대부분은, 만든 본인만이 배포할 수 있고 수정할 수 없는 상태가 되기 쉽습니다. AI가 생성한 코드는 작동하고는 있지만, 그 구조를 이해하고 있는 것은 만든 사람뿐인 케이스가 빈번하게 일어납니다.

담당자가 이동하거나 퇴직했을 때 "도구가 멈췄다", "로그인할 수 없다", "애초에 무엇을 하고 있었는지 모르겠다"라는 사태가 벌어집니다.

카탈로그가 존재하지 않으면 "비슷한 것이 이미 있다"는 사실을 깨달을 수 없습니다. Slack 알림을 보내기 위한 스크립트가 부서마다 3개, 데이터 집계 도구가 4개와 같은 중복이 발생합니다. AI를 사용하면 금방 만들 수 있기 때문에, "찾는 것"보다 "만드는 것"이 더 빠르다는 인센티브도 존재합니다.

2018~2020년경의 RPA 보급기에도 같은 일이 일어났습니다.

UiPath, WinActor, Blue Prism이 주목을 받으며, "노코드(No-code)로 업무 자동화를 할 수 있다"는 홍보와 함께 현장 도입이 가속화되었습니다. IT 부서를 통하지 않고 각 부서가 독자적으로 로봇을 만들기 시작했고, 단기간에 조직 전체의 로봇 수가 폭발적으로 늘어났습니다.

문제	RPA 보급기	바이브 코딩 현재
작성자의 개인 의존화	로봇 설계자가 없으면 고칠 수 없음	코드의 구조를 이해하고 있는 것은 만든 본인뿐
...

구조가 같습니다. "개인이라도 쉽게 만들 수 있다", "만드는 비용이 극적으로 낮아졌다"라는 특성이, 거버넌스(Governance) 정비보다 먼저 보급이 진행되는 상황을 만들어내고 있습니다.

RPA 업계가 내놓은 답은 **CoE (Center of Excellence)**와 **오케스트레이터 (Orchestrator)**입니다.

CoE는 사내의 RPA 추진 및 관리를 담당하는 횡단 조직입니다. 각 부서가 마음대로 만든 로봇을 일원 관리하며, 설계 표준·보안 정책·라이프사이클 관리를 정의했습니다. 기술적으로는 UiPath Orchestrator와 같은 플랫폼이 로봇의 실행·감시·권한 관리를 담당했습니다.

IT 부서가 모든 로봇을 만드는 체제로 되돌린 것이 아니라, 현장이 만드는 것은 인정하되 카탈로그·소유자·라이프사이클을 정비한 것입니다. 현장의 자유도를 남기면서 가시화와 인수인계 가능성을 담보한 것이 핵심입니다.

바이브 코딩 시대에도 동일한 접근 방식을 사용할 수 있습니다.

"중후한 체계를 만들기 전에, 최소 구성으로 시작한다"가 기본 방침이라고 생각합니다.

우선 "무엇이 존재하는가"를 목록화하는 것만으로도, 중복 개발과 개인 의존화를 발견하는 속도가 올라갈 것입니다.

관리 항목의 최소 세트:

항목	내용
이름	도구·스크립트의 명칭
...

스프레드시트로 시작해서, 건수가 늘어나면 Notion이나 사내 포털로 이행하면 충분합니다.

바이브 코딩으로 만든 도구에는 최소한 아래 내용을 README에 작성하는 운용이 유효하다고 생각합니다.

## 오너 (Owner)
- 메인: [이름] (Slack: @username)
- 백업: [이름] (Slack: @username)
...

「AI가 생성한 코드라 나 자신도 완전히 파악하지 못하고 있다」라는 상황은 발생합니다. 그럼에도 불구하고 누구에게 물어봐야 하는지·무엇에 의존하고 있는지만 적어둔다면, 인수인계 비용은 크게 낮아질 것입니다.

월 1회, 30분의 정기 점검(Inventory)을 캘린더에 등록해 두는 것이 좋다고 생각합니다. 확인 항목은 심플하게 구성합니다.

• 카탈로그에 등록되지 않은 툴이 늘어나지 않았는가
• 상태가 「현역」으로 되어 있지만 실제로 사용되고 있는가
• 오너(Owner)가 이동 또는 퇴직하지 않았는가

RPA 시대에 보고된 패턴에 따르면, 점검 없이 방치했을 경우 6개월 후에 「아무도 건드릴 수 없는 로봇이 계속 작동하고 있는」 상태가 다수 발생했습니다. AI 툴에서도 동일한 일이 일어날 수 있습니다.

반복적으로 만들어지는 패턴에 대해 템플릿(Template)을 준비하면, 구조의 개인 의존(属人化, Person-dependency)을 방지할 수 있습니다.

사내에서 자주 만들어지는 패턴 예시:

• Slack 알림 스크립트
• 스프레드시트(Spreadsheet) → BigQuery 정기 데이터 가져오기
• API 정기 실행 + 결과 알림

템플릿이 있으면 「AI에게 물어보고 비슷한 것을 만든다」가 「템플릿을 복사하여 필요한 부분만 바꾼다」로 변합니다. 이를 통해 인증(Authentication)·로그(Log)·에러 처리(Error handling) 설계가 통일되기를 기대합니다.

RPA 시대의 실패 패턴을 참고하면, 다음과 같은 3가지가 빠지기 쉬운 함정으로 꼽힙니다.

1. 과도한 사전 심사
「툴을 만들기 전에 심사를 통과한다」라는 메커니즘을 만들면, 바이브 코딩(Vibe Coding)의 최대 장점인 **「생각난 바로 그날에 작동하는 것을 만들 수 있다」**는 점이 사라집니다.

주 1회의 심사 대기가 발생하는 시점에서, 개발자는 심사를 우회하는 방법을 찾기 시작할 것으로 예상됩니다. 결과적으로 「관리되지 않는 툴이 늘어나는」 역효과를 초래할 수 있습니다.

제안: 만드는 것 자체는 자유롭게 한다. 단, 만든 후 7일 이내에 카탈로그에 등록하는 것을 의무화한다.

2. 카탈로그의 방치
카탈로그를 만들어도 업데이트되지 않으면 의미가 없습니다. 「업데이트해 주세요」라는 리마인드(Remind)를 자동화하더라도, 바쁜 시기에는 무시되는 케이스가 많다고 생각됩니다.

제안: 정기 점검을 분기에 1회, 45분 동안 실시한다. 전수 조사가 아니라 「최종 확인일이 3개월 이상 전인 것」만을 대상으로 한다.

3. 형식적인 백업 오너
백업 오너(Backup Owner)를 형식적으로 설정하는 것만으로는 불충분하며, 그 백업 인원이 실제로 작동시킬 수 있는지 확인하는 기회가 없다면 의미가 없습니다.

제안: 분기에 1회, 백업 오너가 툴을 실제로 기동하여 동작 확인을 한다. 이 로그를 README에 남긴다.

• 바이브 코딩은 RPA 보급기와 동일한 개인 의존·중복·블랙박스화의 리스크를 안고 있다
• 최소한의 대응책은 「카탈로그·소유자·점검·템플릿」의 4가지다. 스프레드시트 1장부터 시작할 수 있다
• 무거운 신청 플로우(Flow)보다 「나중에 기록하는」 설계가 더 기능하기 쉽다고 생각한다
• 아직 운용 실적은 없는 제안 단계이지만, RPA의 전철을 밟고 싶지 않다

마지막으로, GMO Connect에서는 서비스 개발 지원 및 기술 지원을 비롯하여 폭넓은 지원을 수행하고 있으므로, 문의 사항이 있으시면 언제든 편하게 연락해 주시기 바랍니다.