AI 도구 유지보수, 아무도 말해주지 않는다 — 비개발자가 만든 도구는 누가 고치나?

뚝딱 만들었다, 그런데 그다음은?

회사에서 AI 활용을 적극 권장한다는 공지가 내려왔습니다. “AI로 업무 자동화하세요”, “AI 써서 효율 올리세요”. 구체적인 방법은 없었지만 방향은 분명했어요. 그래서 저도 해봤습니다. 영업직군 직원들이 정기적으로 봐야 하는 시험, 그걸 웹사이트로 만들어보기로 했죠.

결과는 놀라웠습니다. Python으로 서버를 올리고, 문제은행을 JSON 파일로 관리하고, 점수 집계 기능까지 — 예전이라면 개발자에게 부탁했을 일을 저 혼자 이틀 만에 해냈거든요. AI가 코드를 써줬고, 저는 방향을 잡아줬습니다. 회사 사람들한테 링크를 보냈더니 다들 “오, 이런 걸 만들었어요?” 하는 반응이 돌아왔고요.

그런데 딱 거기서 멈췄어요. 만들고, 뿌듯해하고, 그리고 — 그다음을 생각하지 않았습니다. 시험 문제가 바뀌면? 접속 오류가 생기면? 제가 다른 부서로 옮기거나 퇴직하면? 이 사이트를 아무도 고칠 수 없다는 걸 그때서야 실감했습니다. 내가 만든 건데, 정작 다른 사람 손에 쥐어주는 법을 전혀 생각하지 않았던 거죠.

그 순간이 꽤 불편했습니다. 뿌듯함이 식으면서 불안함이 올라왔어요. 내가 없어도 이 시스템이 살아남을 수 있을까. 그 질문이 머릿속에 남았습니다.

회사는 “AI 써라”, 그다음은 침묵 — AI 도구 유지보수의 공백

회사가 AI 사용을 권장하는 건 좋은 일입니다. 실제로 생산성이 오르고, 이전에 못 했던 것들을 할 수 있게 되니까요. 저처럼 Python 조금 아는 비개발자가 웹사이트를 만들어버리는 시대니까요. 이게 가능하다는 것 자체가 솔직히 놀랍고, 설레기도 합니다.

그런데 회사의 AI 권장 메시지에는 항상 한 가지가 빠져 있습니다. “만들고 나서는 어떻게 할 건가요?”라는 질문이요. 만드는 법은 알려줍니다. ChatGPT 쓰는 법, Claude 쓰는 법, 자동화 툴 세팅하는 법. 근데 그걸 유지하는 법, 다른 사람한테 넘기는 법, 내가 없을 때 고치는 법은 아무도 말하지 않아요.

처음엔 이게 저만의 부주의라고 생각했습니다. “내가 너무 빠르게 만들려고 했나?” 하고요. 그런데 주변을 둘러보니 그게 아니었어요. 팀장님도 AI로 보고서 자동화 툴을 만들었는데 비밀번호를 어디 적어뒀는지 모른다고 했고, 다른 부서 동료는 엑셀 자동화 매크로를 만들었는데 본인이 나가면 아무도 못 쓸 것 같다고 했어요.

AI 도입을 권장하는 속도와 그것을 유지·운영하는 체계를 구축하는 속도 사이에는 심각한 불균형이 존재합니다. 채택은 빠르지만, 책임 소재와 문서화는 뒤따라오지 못하고 있습니다.

 

88%가 도입, 성과 기업은 6% — AI 도구 유지보수가 빠진 자리

McKinsey가 2025년에 발표한 AI 현황 보고서에는 충격적인 수치가 있습니다. 전 세계 기업의 88%가 AI를 정기적으로 사용하고 있습니다. 그런데 실질적인 비즈니스 성과로 이어진 기업은 단 6%에 불과해요. 88%가 도입했는데 6%만 성과를 냈다는 건, 나머지 82%는 도구만 쓰고 있다는 이야기입니다.

왜 이런 격차가 생길까요? 여러 이유가 있겠지만, 저는 그중 하나가 바로 AI 도구 유지보수와 인수인계 체계의 부재라고 생각합니다. 파일럿은 성공했는데 실운영으로 넘어가지 못하는 이유, 개발은 됐는데 아무도 관리하지 못하는 이유 — 이게 핵심입니다. 멋지게 만들어놓고 아무도 돌보지 않으면, 그 도구는 결국 사라집니다.

더 심각한 건 이른바 Shadow AI 문제입니다. 직원의 약 80%가 IT 부서 승인 없이 자신만의 AI 도구를 업무에 활용하고 있다는 연구 결과가 있어요. 그리고 조직의 63%는 이 Shadow AI의 존재 자체를 감지조차 못 하고 있습니다. 아무도 모르는 사이 만들어진 도구들 — 당연히 AI 도구 유지보수도, 인수인계도 없습니다.

저의 영업팀 시험 사이트도 어떻게 보면 Shadow AI의 산물이었습니다. 공식 IT 프로젝트가 아니었고, 문서화도 없었고, 다른 사람이 이어받을 방법도 없었어요. 선의로 만든 도구가 오히려 조직의 의존성과 취약성을 동시에 높인 셈입니다.

“바이브코더는 자기 차의 승객이다. 엔진을 직접 만들지 않았으니, 고장 나면 고칠 수 없다. AI도 맥락 없이는 수리할 수 없고 — 그러면 아무도 고칠 수 없다.”

— Stack Overflow Blog, 2026

바이브코딩의 ‘버스 팩터’ 문제 — AI 도구 유지보수의 딜레마

소프트웨어 개발 세계에 ‘버스 팩터(Bus Factor)’라는 개념이 있습니다. 팀에서 특정 한 명이 버스에 치여 갑자기 사라진다면, 프로젝트가 얼마나 무너질까를 측정하는 개념이에요. 버스 팩터 1이면 그 사람 하나가 없어졌을 때 프로젝트 전체가 멈춘다는 뜻입니다.

AI로 만든 도구들의 버스 팩터는 얼마나 될까요? 솔직히 대부분 1입니다. 만든 사람만 압니다. 어떤 프롬프트를 써서 만들었는지, 어디가 취약한지, 수정하려면 어디를 건드려야 하는지 — 오직 그 사람만 알아요. 그리고 그 사람이 이직하거나 부서를 옮기면? 그 도구는 사실상 블랙박스가 됩니다.

바이브코딩 완벽 가이드를 읽어보신 분들은 아시겠지만, 바이브코딩은 코드를 직접 짜지 않아도 AI와 대화하며 소프트웨어를 만드는 방식입니다. 진입장벽이 낮아졌다는 건 분명히 좋은 일이에요. 하지만 바이브코딩으로 만들어진 도구는 종종 그것을 만든 사람의 맥락, 그 사람의 AI와의 대화 히스토리 속에 갇혀 있습니다. 다른 사람이 유지보수하려면 처음부터 다시 이해해야 하는 거예요.

이게 개발자 세계에서는 기술 부채(Technical Debt)라고 불리는 문제입니다. AI 코드 생성이 확산된 이후, 코드 중복 비율은 8.3%에서 12.3%로 올랐고 리팩토링 비율은 25%에서 10% 미만으로 떨어졌다는 데이터도 있어요. 빠르게 만들되, 나중을 생각하지 않는 패턴입니다. 비개발자가 AI로 만든 도구들은 이 문제가 더 심각할 수 있습니다. 코드는 있는데 왜 그렇게 짰는지 아는 사람이 아무도 없는 상황이요.

그리고 이 문제는 점점 커질 겁니다. YC(와이콤비네이터) 2025년 스타트업의 25%가 코드베이스 대부분을 AI 생성 코드로 구성했다고 합니다. 전 세계에서 작성되는 코드의 41%가 이미 AI가 쓴 코드예요. 이 속도라면, 몇 년 안에 조직 곳곳에 아무도 이해하지 못하는 AI 도구들이 가득 쌓이게 될 겁니다. AI 도구를 어떻게 선택하고 활용할지에 대한 고민만큼이나, 유지보수를 어떻게 할지에 대한 고민이 필요한 시점입니다.

비개발자가 만든 AI 도구, 진짜 유지보수하는 방법 4가지

그렇다면 어떻게 해야 할까요? 저도 이 고민을 하면서 몇 가지 실천 방법을 찾았습니다. 완벽한 해답은 아니지만, 적어도 버스 팩터를 1에서 조금 올릴 수 있는 방법들이에요.

1. “왜 이렇게 만들었는지”를 기록하세요

코드 자체가 아니라, 의도를 기록하는 게 중요합니다. “이 부분은 왜 이렇게 짰나요?”라는 질문에 대답할 수 있는 문서를 만드세요. AI한테 “이 코드를 비개발자가 이해할 수 있는 설명으로 정리해줘”라고 부탁하면 생각보다 잘 해줍니다. 그 설명을 Notion이나 Google Docs에 저장해두세요. 기능 설명, 수정 방법, 주의사항 이 세 가지만 있어도 훨씬 낫습니다.

2. 수정 방법을 영상으로 남기세요

텍스트 문서보다 화면 녹화가 훨씬 효과적입니다. “문제가 바뀌면 이 파일의 이 부분을 열어서 이렇게 고치면 됩니다”를 직접 보여주는 5분 영상 하나가 100줄짜리 문서보다 낫습니다. Loom 같은 도구를 써도 좋고, 핸드폰으로 찍어도 충분해요. 영상이 있으면 AI한테 “이 영상의 내용을 바탕으로 코드를 수정해줘”라고 요청할 수도 있습니다. 맥락이 살아있으니까요.

3. AI와의 대화 이력을 공유 공간에 저장하세요

Claude나 ChatGPT와 주고받은 대화 내용, 특히 “이 부분을 이렇게 만들어달라고 했던” 핵심 프롬프트들을 팀 공유 폴더에 저장해두세요. 나중에 유지보수를 맡게 된 사람이 같은 AI에게 같은 맥락을 주면서 시작할 수 있습니다. 맥락이 있는 AI는 훨씬 정확하게 도움을 줄 수 있거든요. 대화 이력 하나가 인수인계 문서 열 페이지보다 실용적일 수 있습니다.

4. 공동 소유자를 만드세요

혼자 만들었더라도, 다른 한 명에게 함께 유지보수하는 방법을 알려주세요. “인수인계 공동 사용 기간”을 가지는 겁니다. ISACA가 발표한 Shadow AI 관리 보고서에서도 역할 기반 권한 배분과 공동 소유 원칙이 핵심 권고사항으로 나옵니다. 아무리 작은 도구라도 “이 사람이 없으면 아무도 모른다”는 상황은 피해야 합니다. 단 두 명이 알고 있어도, 버스 팩터는 1에서 2로 올라갑니다.

---

내가 없어도 돌아가는 도구 — 그게 진짜 AI 도구 유지보수입니다

저는 요즘 도구를 만들 때 한 가지 질문을 먼저 합니다. “내가 내일 회사를 떠난다면, 이 사람들이 이 도구를 계속 쓸 수 있을까?” 이 질문에 “예스”가 될 때까지, 아직 절반밖에 안 된 거라고 생각합니다.

AI가 만들어준 코드는 완성이 아닙니다. 시작입니다. 그 코드를 누군가가 이해하고, 고치고, 개선할 수 있도록 맥락을 남기는 것 — 그게 비개발자가 AI 도구를 만들 때 반드시 해야 할 두 번째 작업입니다. 만드는 기쁨에 취해서 이 두 번째 작업을 빼먹으면, 결국 그 도구는 나를 닮은 채 사라집니다. 내가 없으면 같이 없어지는 것으로요.

회사들이 “AI 써라”고 말하는 속도가 빨라지는 만큼, 우리도 “AI 도구 유지보수를 어떻게 할 건가요?”를 먼저 물어야 합니다. 이 질문이 귀찮게 느껴진다면, 아마 몇 달 뒤에 훨씬 더 귀찮은 상황이 찾아올 겁니다. 도구는 고장 나 있고, 아무도 고칠 수 없는 채로 방치된 상황이요.

AI 시대의 진짜 자동화는, 사람이 없어도 돌아가는 시스템입니다. 그리고 그 시스템을 만드는 건, 아직 사람의 몫입니다. AI가 코드를 만들어주는 시대에도, 그 코드를 물려주는 건 여전히 우리가 해야 할 일이에요. 어쩌면 AI 시대에 가장 중요한 능력은 코딩 능력이 아니라, 맥락을 남기는 능력일지도 모릅니다.

혹시 AI로 이런저런 도구를 만들어본 분들, 유지보수를 어떻게 하고 계신가요? 댓글로 경험을 나눠주시면 정말 좋겠습니다. AI가 다양한 산업에서 어떻게 활용되는지도 함께 읽어보세요. 우리가 만드는 것들이 더 오래, 더 많은 사람에게 쓰일 수 있도록요.