바이브 코딩의 네 가지 위험 — 데이터로 확인한 것들

지금까지 잘된 이야기를 주로 썼습니다. 1억 견적을 700만 원으로 줄인 이야기, 2주에 시스템을 만든 이야기, 팀으로 퍼진 이야기입니다.

그것만 읽고 판단하면 안 됩니다. 저는 계속 이 방식으로 일할 생각이고, 그래서 오히려 위험을 더 정확히 알아야 합니다. 이번 글은 반대편입니다.

느낌이 아니라 확인된 데이터로 정리했습니다.

1. 빨라졌다는 느낌은 정확하지 않습니다

2025년 7월에 나온 METR의 실험이 있습니다. 숙련 개발자 16명에게 246개의 실제 과제를 주고, AI 도구를 쓸 수 있는 조건과 못 쓰는 조건으로 나눠 비교했습니다.

결과는 이랬습니다.

• 참가자들은 실험 전에 AI가 24% 빠르게 해줄 것으로 예상했습니다.
• 실제로는 19% 더 느렸습니다.
• 그런데 실험이 끝난 뒤에도 참가자들은 AI가 20% 빠르게 해줬다고 믿었습니다.

마지막 항목이 중요합니다. 겪어본 사람이 겪은 다음에도 반대로 인식했습니다.

다만 이 연구는 스스로 한계를 분명히 밝히고 있습니다. 참가자들은 별 2만 개가 넘는 대형 오픈소스 저장소에 수년간 기여한 사람들이었고, 문서화와 테스트와 린팅 같은 암묵적 요구가 많은 환경이었습니다. 연구진 스스로 이 결과가 소프트웨어 개발 전반을 대표한다고 주장하지 않습니다. 학습 곡선 가능성도 언급합니다. 도구를 오래 쓴 경우는 다를 수 있다는 것입니다.

그래서 이 데이터를 "AI가 개발을 느리게 한다"로 읽으면 과장입니다. 제가 읽은 것은 다른 부분입니다. 속도를 체감으로 판단하면 안 된다는 것입니다.

앞선 글에서 운영 2개월 실측치를 적었습니다. 접수 112건, 완료율 61%, 평균 리드타임 153시간. 이 숫자를 굳이 넣은 이유가 여기 있습니다. 좋아진 것 같다는 감각은 근거가 되지 못합니다.

2. 코드가 쌓이면서 유지보수성이 나빠집니다

이쪽이 더 무섭습니다. GitClear가 2023년부터 2026년까지 6억 2천만 건의 코드 변경을 분석한 결과입니다.

• 중복 블록 — 1,000줄당 40.3개(2023)에서 73.0개(2026)로 늘었습니다. 81% 증가이며 기록상 최고 수준입니다.
• 리팩터링 — 전체 변경 중 코드를 옮겨 정리하는 비중이 21%(2022)에서 3.8%(2026)로 떨어졌습니다. 약 5분의 1입니다.
• 복사·붙여넣기 — 9.4%(2022)에서 15.7%(2026년 상반기)로 늘었습니다.
• 파일 간 함수 호출 — 35% 줄었습니다. 코드가 서로 참조하지 않고 각자 복제되고 있다는 뜻입니다.

왜 이렇게 되는지는 짐작이 됩니다. AI는 새로 만드는 일을 잘합니다. "이 기능 만들어줘"에는 잘 답합니다. 반면 "이거랑 저거가 겹치니까 하나로 합쳐줘"는 사람이 먼저 알아차려서 시켜야 합니다.

그리고 정리하는 일은 눈에 보이는 성과가 없습니다. 기능이 늘지 않고 화면도 안 바뀝니다. 빠르게 만들 수 있는 상황에서 이 일에 시간을 쓰기가 더 어려워집니다.

이 문제의 성격이 특별합니다. 지금은 아무 문제가 없다는 것입니다. 만든 것은 잘 돌아가고 사용자도 만족합니다. 문제는 2년 뒤에 그것을 고쳐야 할 때 나타납니다. 중복이 스무 군데 퍼져 있으면 한 곳만 고쳐서는 안 됩니다.

3. 보안은 모델이 좋아져도 나아지지 않았습니다

세 번째가 가장 예상 밖이었습니다. Veracode의 2026년 조사 결과입니다.

AI가 생성한 코드의 보안 테스트 평균 통과율이 56%였습니다. 전년도가 55%였으니 사실상 제자리입니다. 뒤집어 말하면 약 44%에서 위험한 취약점이 나왔다는 뜻입니다.

취약점 종류에 따라 차이가 컸습니다.

• 암호화 알고리즘 — 87%
• SQL 인젝션 — 83%
• 교차 사이트 스크립팅(XSS) — 15%
• 로그 인젝션 — 12%

많이 알려진 취약점은 잘 막고, 덜 알려진 쪽은 거의 못 막습니다. 학습 데이터에 흔한 것과 그렇지 않은 것의 차이로 보입니다.

그런데 정작 중요한 발견은 이것입니다. 모델이 좋아지는 것과 보안이 좋아지는 것은 별개였습니다. 코딩 전용 모델(51%)과 범용 모델(52%)에 차이가 없었고, 모델 크기도 영향이 작았습니다.

이 부분이 판단을 바꿉니다. 코드 품질은 모델이 좋아지면서 개선될 수 있습니다. 그런데 보안은 그렇게 해결되지 않았습니다. 기다려서 나아지는 문제가 아니라 절차로 막아야 하는 문제입니다.

사내 시스템이라 외부에 노출되지 않는다는 것도 위안이 못 됩니다. 사내 시스템일수록 실제 인사·재무·거래 데이터를 다룹니다.

4. 사람에게 묶입니다

네 번째는 데이터가 아니라 제가 지금 겪고 있는 것입니다.

지금까지 만든 것 중 두 건은 제가 만들었습니다. 그 안의 구조를 정확히 아는 사람은 저뿐입니다. 팀원들이 만든 것도 각자 그렇습니다.

만드는 문턱이 낮아진 대신 만든 사람에게 묶이는 정도가 높아졌습니다. 외주로 만들면 최소한 인수인계 문서가 나옵니다. 직접 만들면 그 절차가 없습니다.

지금은 사람이 다 있으니 문제가 없습니다. 이것도 두 번째 리스크와 같은 성격입니다. 지금은 괜찮은데 나중에 드러납니다.

그래서 무엇을 하고 있는가

정리하면 이렇습니다.

체감을 근거로 쓰지 않습니다. 만들 때 관제 화면을 함께 넣어서, 실제로 몇 건이 처리되고 얼마나 걸리는지를 시스템이 집계하게 했습니다.

표준과 리뷰 절차를 만들고 있습니다. 코드 규칙, 공용 저장소, 무엇이 만들어졌는지 등록하는 자리입니다. 중복과 속인화는 개인의 주의력으로 막을 수 없습니다.

보안은 사람이 봅니다. AI가 만든 코드를 그대로 올리지 않습니다. 특히 권한과 입력값 처리는 별도로 확인합니다.

정리하는 시간을 따로 잡습니다. 기능을 더 만드는 대신 중복을 합치는 작업에 의도적으로 시간을 씁니다. 안 그러면 절대 하지 않게 됩니다.

그러면 하지 말아야 하는가

아닙니다. 그리고 이 결론이 중요합니다.

1억 견적이 700만 원이 된 것도 사실이고, 위의 네 가지도 사실입니다. 둘 중 하나를 골라야 하는 것이 아닙니다.

판단해야 하는 것은 할지 말지가 아니라 무엇을 어디까지 하느냐입니다. 되돌릴 수 있는 업무부터 시작하고, 틀리면 실물이 움직이는 영역은 나중으로 미루고, 만드는 속도와 통제 체계를 함께 키우는 것입니다.

그리고 위험을 아는 것이 속도를 늦추지 않습니다. 오히려 반대입니다. 무엇이 위험한지 알면 어디까지 밀어붙여도 되는지를 알게 됩니다. 모르면 겁이 나서 아예 시작하지 못하거나, 아무 생각 없이 밀다가 크게 다칩니다.

발표 자리에서는 성과만 말하기 쉽습니다. 그런데 성과만 듣고 시작한 조직은 첫 문제에서 멈춥니다. 그래서 이 글을 썼습니다.