편리함의 청구서는 반드시 온다

잘 굴러가던 도구가 어느 날 멈춘다

처음엔 정말 마법처럼 느껴진다. 코드를 한 줄도 몰라도 괜찮다. AI에게 원하는 걸 말로 설명하기만 하면, 며칠씩 붙잡고 있던 반복 업무가 자동화 스크립트 하나로 정리된다. 매출 데이터를 긁어와 시트에 착착 정리해 주고, 새 문의가 들어오면 슬랙으로 알려 주고, 재고를 매일 대신 확인해 주는 도구가 하루 만에 뚝딱 만들어진다. 만든 사람은 뿌듯하고, 팀은 한결 편해진다.

문제는 대개 6개월쯤 뒤에 찾아온다. 연동하던 API의 규격이 바뀌거나, 로그인 방식이 업데이트되거나, 데이터 형식이 살짝 달라진다. 그 순간 도구는 아무 말 없이 조용히 오작동하기 시작한다. 그런데 정작 만든 사람은 그게 왜 멈췄는지 설명하지 못한다. 코드 안에서 무슨 일이 벌어지는지 애초에 이해한 적이 없기 때문이다. 그렇게 '나를 편하게 해주던 도구'는 어느새 '아무도 손대지 못하는 시한폭탄'으로 바뀐다.

요즘은 이런 현상을 바이브 코딩 기술부채라고 부른다. '바이브 코딩(vibe coding)'이라는 말 자체는 2025년 2월 AI 연구자 안드레이 카파시(Andrej Karpathy)가 붙인 것으로, 그해 콜린스 사전이 '올해의 단어'로 꼽을 만큼 순식간에 번졌다. AI에게 '느낌(vibe)'만 던져서 코드를 뽑아내는 방식이 널리 퍼지면서, 그 편리함 뒤에 조용히 쌓이는 빚도 함께 커지고 있다는 이야기다.

'작동한다'와 '이해한다'는 완전히 다른 문제

비개발자가 만든 자동화 도구가 나중에 짐이 되는 이유는, 파고들면 딱 하나로 모인다. 작동하는 것과 이해하는 것은 전혀 다른 일이라는 점이다.

AI가 만들어 준 코드는 첫날엔 대체로 잘 돈다. 하지만 그 코드가 왜 하필 그렇게 짜였는지, 어떤 예외 상황은 처리하지 못하는지, 어디에 위험한 가정이 숨어 있는지는 만든 사람도 모른다. 개발자가 직접 짠 코드라면 사정이 조금 다르다. 최소한 '여기는 내가 대충 처리했으니 나중에 다시 봐야 한다'는 지도가 머릿속에 남아 있다. 그런데 AI가 대신 짠 코드에는 바로 그 지도가 없다.

바이브 코딩의 대표적인 위험은 AI가 생성한 코드의 보안 리스크와 얽히고설킨 아키텍처로 인한 기술 부채다.

— 리모트뷰, 2026

여기서 눈여겨볼 말은 '얽히고설킨(spaghetti)'이다. AI에게 '이것도 좀 넣어줘', '이 부분도 고쳐줘'를 여러 번 반복하다 보면, 전체 설계를 아무도 그리지 않은 채 기능만 덕지덕지 붙은 코드가 된다. 조각 하나하나는 잘 돌아간다. 하지만 그 조각들이 전체로 어떻게 맞물리는지는 아무도 모른다. 실제로 한 체계적 분석(2025)은 이 반복 자체가 코드를 더 위태롭게 만든다는 걸 보여 줬다. AI에게 같은 코드를 거듭 고쳐 달라고 시켰더니 다섯 번 만에 치명적 취약점이 37.6% 늘었고, 손대는 횟수가 쌓일수록 결함은 오히려 비선형으로 불어났다. 이게 바로 나중에 손댈 수 없는 도구가 만들어지는 전형적인 길이다.

비개발자의 자동화 도구에 잘 생기는 세 가지 빚

실무에서 눈에 자주 띄는 빚은 크게 세 종류다. 보안기업 OX시큐리티가 AI로 생성된 코드를 분석했더니 62%가 결함이 있거나 취약한 것으로 나왔을 만큼, 이 빚들은 드문 사고라기보다 기본값에 가깝다.

첫째는 눈에 보이지 않는 보안 구멍이다. API 키나 비밀번호가 코드에 그대로 박혀 있고, 입력값을 걸러 주는 장치가 없어 이상한 데이터가 들어오면 그대로 터진다. 비개발자는 '작동하니까 됐다'며 넘어가지만, 이 코드가 사내 데이터나 고객 정보에 손을 댄다면 사고 한 번에 회사가 통째로 흔들릴 수 있다. 빈말이 아니다. 2025년 보안기업 이스케이프(Escape)가 바이브 코딩 도구로 만든 앱 5,600개를 훑었더니, 그대로 노출된 API 키·토큰이 400건 넘게, 의료·금융 정보 같은 개인정보 노출이 175건 나왔다 — 그것도 모두 실제로 돌아가는 서비스에서.

둘째는 언제 끊길지 모르는 깨지기 쉬운 연결이다. 외부 서비스의 화면 구조나 API에 기대어 데이터를 긁어오는 도구는, 상대가 조금만 바뀌어도 곧장 멈춘다. 그런데 왜 멈췄는지 진단해 줄 사람이 곁에 없다.

셋째는 아무도 남기지 않은 문서와 재현성이다. 이 도구가 어떤 환경에서, 어떤 순서로, 무엇에 기대어 도는지 기록해 둔 사람이 없다. 그래서 만든 사람이 퇴사하거나 담당이 바뀌면, 그 도구는 '건드리면 안 되는 블랙박스'가 되어 조직에 그대로 남는다.

세 가지의 공통점은 분명하다. 이 빚들은 만드는 순간엔 전혀 보이지 않다가, 유지보수 단계에 이르러서야 한꺼번에 청구된다는 것이다.

2026년, 문제의 무게가 달라졌다

예전 같으면 이런 자동화 도구는 개인의 잔재주 수준에서 끝났다. 하지만 지금은 사정이 다르다. 업계에서는 "2026년은 실험이 아니라 운영의 시대"라는 진단이 나온다. AI로 뭔가를 만들어 보던 실험 단계를 지나, 그렇게 만든 것을 실제 업무에 붙여 돌리는 국면으로 넘어갔다는 뜻이다. 실제로 오늘날 새로 짜이는 코드의 상당 부분은 이미 AI의 손을 거친다. 와우테일이 전한 집계로는 전 세계 코드의 41%가 그렇고, Y컴비네이터의 2025년 겨울 배치 스타트업 가운데 4분의 1은 코드베이스의 95% 이상을 AI가 썼다고 밝혔다.

운영의 시대라는 말은 이런 의미다. 개인이 재미 삼아 만든 스크립트가, 어느새 팀의 매출 정산이나 고객 응대 같은 진짜 파이프라인에 물려서 돌아간다는 것이다. 실험용 도구는 망가져도 그만이다. 하지만 운영에 들어간 도구가 조용히 틀린 값을 뱉기 시작하면, 그 피해는 고스란히 현실이 된다. 잘못 집계된 재고 숫자, 어딘가로 사라진 고객 문의, 어긋나 버린 정산. 부채의 이자가 실험실이 아니라 사업 한복판에서 청구되기 시작하는 것이다. 가트너도 같은 방향을 짚는다. 시민 개발자들이 프롬프트만으로 앱을 찍어 내면서, 2028년까지 소프트웨어 결함이 큰 폭으로(가트너는 25배가량으로) 늘어날 것이라는 전망이다.

그렇다면 만들지 말아야 하는가

결론은 '비개발자는 자동화 도구를 만들지 마라'가 아니다. 그건 시대를 거스르는 조언이고, 바이브 코딩이 열어 준 생산성의 값어치를 통째로 부정하는 말이다. 방향은 오히려 반대다. 부채가 될 도구와, 부채가 되지 않을 도구를 구분해서 만드는 것이 핵심이다.

실무에서 그을 수 있는 선이 몇 개 있다.

• 범위를 정직하게 나눈다. 나 혼자 쓰고 망가져도 괜찮은 개인용 도구와, 남이 의존하거나 민감한 데이터를 다루는 도구는 애초에 다른 기준으로 대해야 한다. 뒤쪽 도구는 반드시 아는 사람의 검토를 한 번 거친다.
• AI에게 코드만 받지 말고 설명도 함께 받는다. '이 코드가 무엇을 전제로 깔고 있는지', '어디서 깨질 수 있는지', '보안상 위험한 데는 없는지'를 같이 물어 두면, 훗날을 위한 최소한의 지도라도 손에 남는다.
• 비밀값과 검증만큼은 타협하지 않는다. API 키는 코드에 박아 넣지 않고, 밖에서 들어오는 입력은 늘 한 번 의심한다. 이 두 가지만 지켜도 흔한 사고의 상당수는 미리 막을 수 있다.
• 운영에 붙이기 전에 딱 한 번은 개발자를 태운다. 실험을 운영으로 승격시키는 그 순간이, 기술부채를 갚을지 그냥 굴릴지가 갈리는 지점이기 때문이다.

편리함의 청구서는 반드시 온다

AI 자동화 도구의 진짜 비용은 만드는 순간이 아니라 유지하는 순간에 드러난다. 첫날의 감동은 공짜처럼 느껴진다. 하지만 그 감동은, 미래의 누군가가 대신 갚아야 할 청구서를 담보로 잡고 미리 누리는 것이다.

비개발자가 만든 도구가 짐이 되는 건 그 사람이 무능해서가 아니다. '작동하는 것'까지만 책임지고, '이해하고 유지하는 것'은 아무도 책임지지 않는 구조로 만들어졌기 때문이다. 바이브 코딩이 당연해질수록, 우리가 던져야 할 질문도 바뀌어야 한다. '이걸 만들 수 있는가'가 아니라, '이걸 6개월 뒤에도 감당할 수 있는가'로. 그 질문에 답할 수 있는 도구만이, 짐이 아니라 자산으로 남는다.