저는 코딩을 못 합니다. 그런데 지금 제 회사에는 매일 돌아가는 자동화 파이프라인이 여러 개 있고, 그 코드는 전부 AI가 짰습니다. 이걸 요즘 바이브 코딩(vibe coding)이라고 부르죠. 원하는 걸 말로 설명하면 AI가 코드를 뱉고, 돌아가면 그냥 쓰는 방식입니다. 그런데 얼마 전 잘 돌아가던 스크립트 하나가 조용히 멈췄습니다. 고치려고 열어봤는데 문제는 코드가 어렵다는 게 아니었어요. 왜 이렇게 만들어졌는지 아무도 모른다는 것이었습니다. AI한테 물어봐도 소용없습니다. 그때 그 판단을 왜 했는지 AI는 기억하지 못하거든요. 업계에는 이미 이름까지 붙어 있더군요. "90일의 청구서(90-day reckoning)"입니다. 코딩 몰라도 이 바이브 코딩 기술부채, 막을 수 있을까요? 제가 찾은 답과 실제로 바꾼 습관을 정리했습니다.
숫자로 보면 이건 개인의 실수가 아닙니다
먼저 이 흐름이 얼마나 보편적인지부터 보겠습니다. Stack Overflow 개발자 설문에서 AI 코딩 도구 사용률은 84%까지 올라갔는데, 정작 그 결과물을 신뢰한다는 응답은 43%에서 29%로 떨어졌습니다(약 18개월 사이). 다들 쓰긴 쓰는데, 믿지는 않으면서 쓰고 있다는 뜻입니다.
코드 품질 지표도 같은 방향입니다. 여러 2026년 분석을 종합하면 AI 코딩 도구 도입 이후 기술부채는 30~41% 증가, 코드 중복은 48% 증가, 반면 리팩터링(코드 정리 작업) 활동은 60% 감소했습니다. 새로 짜는 속도는 빨라졌는데 정리하는 손길은 사라진 거죠. 개발자 약 800명을 추적한 Uplevel 연구에서는 Copilot 도입 후 버그 발생률이 41% 늘었다는 결과도 나왔습니다. Forrester는 2026년 말까지 기술 의사결정권자의 75%가 중간 이상 수준의 기술부채에 직면할 것으로 봤고, McKinsey 조사에서는 CIO의 60%가 자사 기술부채가 지금도 계속 늘고 있다고 답했습니다. (조사 기관마다 표본과 측정 방식이 달라 수치를 그대로 받아들이긴 어렵지만, 서로 다른 조사가 전부 같은 방향을 가리킨다는 점은 무시하기 어렵습니다.)
정리하면, AI는 코드 생산 속도를 올렸지 코드 유지 능력을 올려주지는 않았습니다. 그리고 그 간극이 벌어지는 데 걸리는 시간이 대략 석 달입니다.
왜 하필 90일 뒤에 문제가 터질까
여러 사례 분석에서 반복적으로 나오는 시간표가 있습니다.
- 30일차: 경고등이 켜집니다. 같은 로직이 여기저기 복사돼 있고, 에러 처리가 빠져 있고, 어디서 왔는지 모르는 의존성이 붙어 있습니다. 하지만 아직 다 잘 돌아가서 아무도 신경 쓰지 않습니다.
- 60일차: 속도가 체감되게 느려집니다. 기능 하나 추가하려는데 건드려야 할 곳이 자꾸 늘어납니다.
- 60~90일차: 첫 진짜 유지보수 순간이 옵니다. 버그를 고치려면 내가 쓰지 않은 코드를 이해해야 하는데, 그 코드를 쓴 AI는 이유를 기억하지 못합니다.
원인은 명확합니다. AI는 "이번 요청이 돌아가게 만드는 것"에 최적화돼 있지, "시간이 지나도 일관된 구조를 유지하는 것"에 최적화돼 있지 않습니다. 매 요청이 독립된 문제 풀이라서 전체를 관통하는 설계 감각이 없습니다. 사람 개발자라면 "이건 저기 있는 함수 재활용하면 되겠네" 하고 넘어갈 걸, AI는 그냥 하나 더 만들어 버립니다. 그게 48% 중복의 정체입니다. 여기에 보안 문제도 겹칩니다. 여러 조사에서 AI 생성 코드의 약 45%에 취약점이 발견된다고 보고합니다. 개인 자동화 스크립트라면 넘어갈 수도 있지만, API 키나 고객 데이터를 만지는 코드라면 얘기가 달라집니다.
바이브 코딩 기술부채, 비개발자는 실제로 어떻게 관리할까
여기서 흔히 나오는 조언이 "그러니 제대로 배우세요"인데, 저 같은 사람에겐 현실적이지 않습니다. 배우는 데 1년 쓰면 사업은 그동안 안 굴러가니까요. 그래서 저는 코드를 이해하는 대신, 코드를 관리 가능하게 만드는 쪽으로 방향을 잡았습니다. 실제로 바꾼 습관 네 가지입니다.
① 덮어쓰지 않고 버전을 남긴다. 이게 제일 효과가 컸습니다. 잘 돌던 코드를
수정할 땐 원본을 지우지 않고 _v2 같은 새 파일로 만들어 테스트합니다. 코드를 못
읽어도 "어제 건 됐고 오늘 건 안 된다"는 건 누구나 압니다. 그럼 롤백하면 끝이죠. 비개발자에게
가장 값싼 보험입니다.
② 코드가 아니라 '왜'를 기록한다. AI는 자기가 왜 그렇게 짰는지 기억 못 하지만, 저는 기록할 수 있습니다. 파일 맨 위에 "이건 뭘 하는 스크립트고, 무슨 문제를 풀려고 만들었고, 건드리면 안 되는 부분은 어디"를 세 줄로 남깁니다. 나중에 다른 AI에게 수정을 시킬 때 이 세 줄이 있느냐 없느냐가 결과를 완전히 갈라놓습니다.
③ 조용한 실패를 막는다. AI가 짠 자동화에서 제일 무서운 건 에러가 뜨는 게 아니라 아무 소리 없이 안 돌아가는 것입니다. 외부 API가 바뀌면 특히 그렇습니다. 그래서 중요한 파이프라인에는 "성공했으면 성공했다고 알려주는" 알림을 꼭 붙였습니다. 실패 알림보다 성공 알림이 중요합니다. 실패는 알림 자체가 안 갈 수 있으니까요.
④ 새로 만들기 전에 "이미 비슷한 게 있나"를 먼저 묻는다. AI에게 그냥 시키면 무조건 새로 만듭니다. 그래서 요청 앞에 "기존 파일 중에 이 기능 하는 게 있는지 먼저 확인해줘"를 붙이는 습관을 들였습니다. 한 줄인데 중복이 눈에 띄게 줄었습니다.
그렇다고 겁먹을 일은 아닙니다
여기까지 읽으면 "역시 AI 코딩은 위험하구나" 싶을 수 있는데, 제 결론은 반대입니다. 기술부채라는 말 자체가 '빚'입니다. 빚은 나쁜 게 아니라 관리 대상이에요. 제가 코딩을 배워서 직접 짰다면 지금 있는 자동화 중 단 하나도 존재하지 않았을 겁니다. 90일 뒤에 청구서가 오더라도, 그 90일 동안 실제로 돌아간 게 있다면 그건 남는 장사입니다.
중요한 건 모든 코드를 똑같이 관리하려 들지 않는 것입니다. 한 번 쓰고 버릴 스크립트는 그냥 대충 만듭니다. 정리 안 해도 됩니다. 반면 매일 돌아가는 것, 돈이나 고객 데이터를 건드리는 것, 멈추면 바로 티가 나는 것 — 이 세 가지에만 위의 네 가지 습관을 적용합니다. 전부 관리하려 들면 1인 기업에서는 그냥 아무것도 못 하게 됩니다.
마치며
바이브 코딩의 진짜 함정은 코드 품질이 아니라 시간차입니다. 이득은 오늘 즉시 오고, 비용은 석 달 뒤에 옵니다. 그러니 지금 잘 돌아가는 자동화가 있다면, 오늘 하나만 해보세요. 파일 맨 위에 세 줄 메모 남기기. 이건 코딩이 아니라 글쓰기라서, 우리도 할 수 있습니다. 저는 이런 1인 AI 회사 운영의 시행착오를 처음부터 끝까지 정리해서 「AI 회사를 만들었습니다 -실전편-」이라는 책으로도 묶어뒀습니다. 코딩 몰라도 자동화를 굴리면서 겪은 삽질들이 궁금하시면 참고하셔도 좋습니다.
출처: Stack Overflow Developer Survey 2025-2026, Uplevel(Copilot 도입 전후 분석), Forrester 2026 기술 전망, McKinsey CIO 조사, "Vibe Coding Technical Debt 2026: The 90-Day Reckoning", arXiv 2606.14796
작성: Art Gourmet