바이브 코딩 앱 설치를 망설이게 만드는 건 보안보다 유지보수다

해커뉴스에 "바이브 코딩된 앱을 설치하는 걸 꺼리는가"라는 질문이 올라와 댓글 23개가 달렸다. 질문을 던진 사람의 문제의식은 이렇다. 예전에도 공급망 공격은 있었지만, 적어도 사람 프로그래머가 만든 소프트웨어라면 뭔가 이상하다는 걸 알아챌 가능성이라도 있었다. 반면 AI가 코드를 찍어낸 앱은 프롬프트 인젝션으로 바이러스가 섞여 들어가도 아무도 눈치채지 못하는 게 아니냐는 것이다.

이 우려에 대해 "위험이 과장됐다"는 쪽 논리가 상당한 지지를 받았다. 프롬프트 인젝션에 당할 확률은 개발자가 애초에 악의를 품을 확률보다 훨씬 낮다는 것, 그리고 수십 년째 소스가 공개되지 않은 실행 파일을 아무 탈 없이 써 왔다는 지적이다. LLM은 정해진 근무 시간이 없고 번아웃도 겪지 않기 때문에, 사람이 굳이 신경 쓰지 않을 사소한 디테일까지 챙기는 사용자용 소프트웨어가 나온다는 평가도 나왔다. 실제로 한 댓글 작성자는 바이브 코딩으로 만든 포토샵 클론을 쓰고 있다며, 바이너리 크기가 GIMP의 3분의 1 수준이고 실행이 즉각적이라고 했다. GIMP 3가 뜨는 데 5초가 걸린다는 것과 비교한 것이다. 다만 도구와 메뉴를 거의 그대로 베낀 수준이고, 프레임별 애니메이션과 GIF 내보내기는 빠져 있다고 덧붙였다.

그런데 스레드에서 가장 자주 나온 불만은 보안이 아니었다. 바이브 코딩 앱 상당수가 일주일치 커밋을 몰아넣은 뒤 2~3주째 조용하다는 관찰이다. 이런 프로젝트는 대부분 금방 방치되며, "그냥 포크해서 쓰면 되지"는 답이 되지 못한다는 반응이 많았다. 버그를 최소화하고, 소수의 기능을 제대로 수행하고, 시스템 자원을 적게 쓰는 소프트웨어를 원하는데 바이브 코딩 앱은 이 조건을 거의 만족하지 못한다는 것이다. 화려해 보이지만 곧 버려지는 결과물, 거대해진 코드베이스, 성능 문제가 반복적으로 언급됐다.

판별 자체가 불가능하다는 문제도 제기됐다. AI가 만든 코드인지 확실히 알 방법이 없으니 항상 바이브 코딩일 가능성을 전제해야 하고, 그러면 항상 망설일 수밖에 없다는 논리다. 여기에 반론도 만만치 않다. 어떤 앱이든 60%는 지구 반대편 누군가가 관리하는 서드파티 의존성이며 개발자도 그 코드를 들여다보지 않는다는 지적이다. 오픈소스라면 바이브 코딩 여부와 무관하게 코드를 읽을 수 있지만 실제로 읽는 사람은 소수이고, 상용 앱 개발자는 완벽한 보안보다 수익을 우선한다는 점도 다르지 않다.

실무 대응책도 여러 개 나왔다. Trivy 같은 스캐너를 돌리고, 오픈소스 도구를 설치하기 전에 AI에게 GitHub 저장소를 감사하게 시키는 방식이다. 회사가 강제하는 Claude Code 같은 도구를 제외하면 아예 설치하지 않거나 격리된 가상머신 안에서만 실행한다는 사람도 있었다. 기업 환경에서 바이브 코딩 앱을 더 안전하게 배포·공유하도록 돕는 도구를 직접 만들고 있다는 댓글도 눈에 띄었다.

결국 판단 기준은 "AI가 만들었는가"보다 "누가 만들었고 계속 관리되는가"로 옮겨가는 분위기다. GitHub 별점이나 다른 사용자의 평가를 보라는 조언, 앱의 복잡도와 성격에 따라 다르게 판단하라는 의견, 설치형이어야 할 이유가 있느냐고 되묻는 댓글까지 다양한 기준이 오갔다. 리눅스 커널에까지 바이브 코딩이 스며드는 게 걱정된다는 반응도 있었다.

다만 이 스레드는 개인 경험과 인상에 기반한 논쟁이며, 위험 수준을 정량적으로 비교한 자료는 제시되지 않았다. AWS가 자사 코드의 상당 부분을 AI로 생성한다고 내세운다는 언급도 댓글 작성자의 발언 수준에 머문다.