우리는 모든 것을 “바이브 코딩”이라고 부르는 것을 멈춰야 합니다

오랜 휴식 후 코딩에 다시 복귀했으며, Lovable에서 다시 시작했습니다. 앱들은 보기에도 훌륭했고, 처음 눈에 보이는 대로 작동했으며, 몇 시간 안에 완성되었습니다. 처음에는 놀라웠습니다. 하지만 코드가 무엇을 하고 있는지, 그리고 왜 그렇게 하는지를 알고 싶어지는 순간부터는 충분하지 않았습니다. 그때부터 제 접근 방식이 바뀌기 시작했습니다.

차이는 도구에 있거나 AI가 얼마나 많은 코드를 대신 작성했는가에 있는 것이 아닙니다. 이는 당신이 결과물과 맺는 계약에 관한 것으로, 방금 세상에 내놓은 것을 설명할 수 있는지 여부에 달려 있습니다

바이브 코딩은 원래 의미에서 AI가 생성한 소프트웨어를 그 아래에 무엇이 있는지 제대로 검토하거나 이해하지 않고 받아들이는 것을 의미합니다. AI 지원 개발은 다릅니다. 모델이 여전히 대부분의 코드를 작성할 수 있지만, 시스템을 구축하는 사람은 그 동작을 이해하고, 가정을 테스트하며, 배포할 준비가 되었는지 결정할 책임이 있습니다.

자신의 머신을 떠나지 않는 일회성 실험이라면 이 구분이 큰 영향을 미치지 않을 수도 있습니다. 그러나 소프트웨어가 배포되어 다른 사람이 사용하거나 실제 데이터와 연결되면 그 차이는 엄청나게 중요해집니다.

바이브 코딩이 의미를 잃게 된 과정

The term “vibe coding” was coined 2025년 2월 by Andrej Karpathy, co-founder of OpenAI. His example was deliberately casual: a “throwaway weekend project” built by automatically clicking “Accept All,” ignoring the diffs and allowing the code to grow beyond his understanding.

몇 주 후, 개발자이자 도구 제작자인 Simon Willison은 이 용어가 매우 다르게 사용되고 있음을 발견했습니다: AI 지원 프로그래밍 전체를 의미하는 대체어로 쓰이고 있었으며, 이는 용어를 희석시키고 책임 있는 AI 지원 개발이 달성할 수 있는 것에 대한 잘못된 인상을 준다고 주장했습니다.

흥미로운 점은 Karpathy가 결국 이에 동의했다는 것입니다. 1년 뒤, 그는 보다 체계적인 코딩 에이전트 작업을 위해 다른 용어를 도입했습니다. 그는 ‘에이전시 엔지니어링’을 개발자가 에이전트를 단순히 받아들이는 것이 아니라 지시하고 감독하는 워크플로우라고 설명했습니다. 이 구분은 중요합니다: 전문적인 AI 지원 개발은 캐주얼한 바이브 코딩과 달리 계획, 면밀한 검토 및 책임성을 요구합니다.

경계는 책임이다

Willison의 규칙은 간단하며, 모든 사람에게 시험이 됩니다: 다른 사람에게 설명할 수 없는 코드를 커밋하지 마라. 이는 모든 한 줄씩 읽어야 한다는 뜻은 아닙니다: 에이전트가 한 번에 수백 줄을 생성하므로, 심지어 숙련된 개발자도 이제는 그렇게 하지 않습니다. 핵심 로직을 이해하고 코드가 정확히 왜 그렇게 동작하는지 정당화할 수 있어야 합니다. 가능하다면 모델이 작성했든 당신이 작성했든 상관없습니다: 이는 바이브 코딩이 아니라 도구를 사용해 소프트웨어를 구축하는 것입니다.

2025년 12월에 발표된 연구는 이 구분을 뒷받침합니다. 현장 관찰과 전문 개발자를 대상으로 한 정성적 설문조사를 바탕으로, 연구자들은 경험 많은 실무자들이 전체 과정을 AI에 맡기지 않고 소프트웨어 설계와 구현에 대한 통제를 유지한다는 것을 발견했습니다. 그들은 에이전트를 협업자로 대하고, 작업을 신중히 계획하며, 감독에 계속 참여했습니다.

따라서 경험만으로는 설명되지 않습니다. AI가 만든 결과에 대해 책임을 질 의지가 있는가가 핵심입니다. 이는 모든 개발자가 매 프로젝트마다 반복해서 내리는 결정입니다.

통제가 없을 때 발생하는 일

보안성을 이해하거나 검증하지 않은 채 소프트웨어를 배포하는 결과는 추상적인 것이 아닙니다. 여성의 데이트 안전을 돕기 위한 앱인 Tea는 두 차례의 보안 사고로 수만 장의 신분증 사진과 백만 건이 넘는 개인 메시지를 노출했습니다. 이 실패에는 보안이 취약한 스토리지 버킷과 인증 없이 접근 가능한 별도 데이터베이스가 포함되었습니다.

같은 근본적인 문제—소프트웨어는 정상적으로 작동하는 듯 보이지만 권한 로직이 위험하게 잘못되어 있는 경우—가 Lovable 플랫폼 위에 구축된 애플리케이션에서도 나타났습니다: 보안 연구에서 권한 로직이 뒤바뀐 것이 발견되었습니다. 이로 인해 로그인한 사용자는 차단되고 인증되지 않은 공격자는 자유롭게 들어올 수 있었으며, 학생을 포함한 18,000명 이상의 사용자가 영향을 받았습니다.

이는 “나쁜” 프로젝트에만 일어나는 고립된 사례가 아닙니다. Google의 2025년 DORA 보고서에 따르면, 현재 개발자의 90%가 업무에서 AI를 사용하고 있으며, 약 3분의 1은 AI가 생성한 결과에 거의 신뢰를 두지 않거나 전혀 신뢰하지 않는다고 보고했습니다.

AI 사용은 이제 널리 퍼졌지만, 신뢰는 여전히 제한적입니다. 따라서 생성된 코드가 인증, 권한 또는 민감한 데이터를 다룰 때는 특히 신중한 검토가 중요합니다.

통제는 한 번에 전부가 아니라 계층적으로 구축된다

제 경우, 공식적인 보안 감사를 처음부터 진행하지 않았습니다. 무언가가 왜 그렇게 동작하는지 설명할 수 없을 때마다 진행을 거부했습니다—분석가로서 일할 때 자연스럽게 갖는 본능이죠. 저는 구문보다 결과가 원래 필요했던 것과 일치하는지에 더 신경 씁니다. 일치하지 않을 경우, 계속 파고듭니다.

프로젝트가 더 중요해짐에 따라 제 워크플로우는 더 구조화되었습니다. 프롬프트만에 의존하는 대신, 무언가를 생성하기 전에 사양을 준비하기 시작했습니다. 비즈니스 요구사항, 기술 스택 및 통합을 문서화했습니다. 그 다음에는 주요 사용자 여정을 위한 단위 테스트와 Playwright 테스트를 진행했습니다.

보안 검사는 거의 같은 방식으로 추가되었습니다. AI가 선택한 라이브러리를 검토하고 업로드된 파일에 대한 악성코드 스캔을 도입했습니다. 각 검사는 초기 단계에서 준비한 통제 목록을 따르는 것이 아니라, 다음에 무엇이 잘못될 수 있을지를 스스로 질문하면서 진행되었습니다.

그 습관 덕분에 한 프로젝트에서 문제를 발견했습니다. AI가 제가 사용 중인 프레임워크 버전과 호환되지 않는 라이브러리를 도입했었습니다. 애플리케이션이 즉시 실패하지 않았기 때문에 호환성 문제는 쉽게 눈에 띄지 않을 수 있었습니다. 나중에 발견했다면 원인을 파악하기 훨씬 어려웠을 것입니다.

Tea와 Lovable 사례와 비교하면, 이는 평범한 문제였습니다. 저는 초기에 발견하고 수정한 뒤 진행했습니다. 이것이 실무에서 검토가 보통 어떻게 이루어지는지 보여줍니다. 대부분의 경우, 작은 문제가 커지는 것을 방지합니다.

코드가 AI에 의해 생성됐다고 해서 무조건 불신하지는 않습니다. 또한 애플리케이션이 실행된다고 해서 무조건 신뢰하지도 않습니다. 테스트와 검토를 통해 코드가 의도대로 동작하는지 확인합니다.

바이브 코딩에서 에이전시 엔지니어링으로

Karpathy가 ‘바이브 코딩’에서 ‘에이전시 엔지니어링’으로 전환한 것은 단순히 용어가 바뀐 것이 아닙니다. ‘에이전시 엔지니어링’은 전문 개발이 나아가는 방향을 더 유용하게 명명합니다. 개발자는 직접 작성하는 코드 라인이 줄어들 수 있지만, 이는 책임이 감소한다는 의미는 아닙니다. 대신 시스템이 해야 할 일을 명시하고, 에이전트를 지시하며, 그 출력물을 테스트하고, 배포해도 안전한지를 결정하는 작업으로 전환됩니다.

위험은 AI가 코드를 빠르게 생성한다는 것이 아니라, 생성이 이해보다 빨라질 수 있다는 점입니다. 이런 상황에서는 겉보이는 생산성이 위험을 가릴 수 있습니다 아무도 제대로 검토하지 않았습니다.

지켜야 할 규칙

‘바이브 코딩’이라는 라벨을 모든 형태의 AI 지원 개발에 사용하지 마세요—이는 용어를 희석시키고 중요한 통제 구분을 없애버립니다. 간단한 규칙을 세우세요: 설명할 수 없는 코드는 배포하지 않기. 그리고 프로젝트가 성장함에 따라 통제를 계층적으로 구축하고, 발생하는 위험에 맞춰 검증을 추가하십시오.

AI가 대부분의 코드를 작성할 수 있지만, 이를 배포할 책임은 질 수 없습니다. 그 책임은 여전히 우리에게 있습니다.