"알아서 다 짜주는 거 아니야?" 바이브 코딩 뒤에 숨겨진 현실적인 계산서

느낌(Vibe)만 던져주면 끝난다는 착각

자연어로 대략적인 요구사항만 전달하면 AI가 코드를 완성해 준다는 소위 '바이브 코딩'이 주목받고 있다

그러나 이 접근 방식을 실제 프로덕션 환경에 그대로 적용하면 여러 현실적인 문제에 직면한다

 

프로덕션 레벨의 소프트웨어는 단순히 실행 가능한 코드를 만드는 것 이상의 요구조건을 갖는다

예제가 풍부한 토이 프로젝트나 독립된 스크립트는 몇 마디 지시로 구현할 수 있지만,

실제 비즈니스 시스템은 사내 도메인 특화 규칙, 아키텍처 일관성, 인프라 비용 한도, 응답 지연 시간(Latency), 보안 규정 등을 동시에 충족해야 한다

LLM은 이러한 다차원적인 엔지니어링 제약을 스스로 계산하고 조율하지 못한다.

 

실제로 에이전트 도구를 복잡한 실무 코드베이스에 연결하면 예상치 못한 문제들이 발생한다

사소한 빌드 에러 하나를 해결하기 위해 수십 번의 루프를 돌며 API 토큰을 낭비하고, 개발자가 확인하면 1분 만에 찾을 문제를 15분 동안 도구 호출을 반복하며 지연을 초래한다

동작은 하지만 동시성 이슈를 유발하는 불안정한 코드를 생성하거나, 권한 통제가 미흡한 환경에서 로컬 설정을 임의로 변경하는 일도 빈번하다

 

이번 글에서는 AI 기반 자동화 코딩이 실무 시스템에서 마주하는 구체적인 제약 사항들을 살펴본다

 

AI에게 모든 개발 과정을 위임할 때 발생하는 문제들을 [코드 검증과 구현 난이도], [비용과 지연 시간], [보안과 실행 권한]의 세 가지 관점에서 분석해보았다

 

 

1. 레퍼런스가 없는 고난이도 영역에서 마주하는 한계

 

AI 코딩 도구는 인터넷에 공개된 코드가 많은 영역에서는 준수하게 작동하지만,

레퍼런스가 적거나 난이도가 높은 시스템 영역에서는 급격히 오작동한다.

 

LLM은 스스로 인과관계를 이해하고 설계를 창작하는 지능이 아니라, 대규모 데이터셋의 통계적 패턴을 이어 붙이는 모델이다

따라서 웹 CRUD나 기본 스크립트처럼 오픈소스 예제가 넘쳐나는 영역은 쉽게 모방한다

 

반면 사내 자체 프레임워크, 최신 버전 라이브러리, 복잡한 비동기 라이프사이클이나 저수준 메모리 제어 같은 영역은 학습 데이터 자체가 부족하다

 

참조할 패턴이 없는 상태에서 모델은 존재하지 않는 API를 날조(할루시네이션)하거나 논리적 모순이 있는 코드를 반복 생성한다

존재하지 않는 함수 이름을 당당하게 호출하기도 한다. 프레임워크의 동작 규칙을 무시한 채 표준 문법으로 코드를 덮어써 빌드를 깨뜨리는 일도 흔하다.

 

당 시스템만의 고유한 비즈니스 로직과 복잡한 규칙이 얽혀 있을수록, 알아서 짜달라는 방식은 성립하지 않는다

엔지니어가 시스템 규격과 인터페이스를 명확히 정의하고, 구체적인 기술 명세를 직접 제공하지 않으면 정상적인 구현 자체가 불가능하다

 

 

2. '돌아가는 코드'와 '올바른 코드'의 괴리

AI가 생성한 코드가 에러 없이 당장 동작한다고 해서 프로덕션에 적합한 올바른 코드인 것은 아니다

이를 판별하는 엔지니어의 코드 리뷰 역량이 없다면 시스템은 빠르게 망가진다

 

LLM은 소프트웨어의 유지보수성이나 시스템 라이프사이클을 고려하지 않는다

눈앞의 테스트를 통과하거나 에러 메시지를 없애는 데 가장 부합하는 텍스트 패턴을 찾아낼 뿐이다

 

동작은 하지만 메모리 누수를 유발하는 순환 참조가 남을 수 있다

멀티스레드 환경에서 레이스 컨디션을 일으키거나 기존 아키텍처 원칙을 깨뜨리는 코드도 경고 없이 생성된다

 

직접 코드를 타이핑하는 시간은 줄었다. 하지만 코드가 시스템 전체 관점에서 올바른지 판단하는 검증 역량은 더 중요해졌다

구현을 AI에 맡기더라도 코드 품질과 아키텍처의 최종 승인권은 사람의 코드 리뷰에 있다

 

 

3. 비용과 시간의 역설 (토큰 낭비와 레이턴시)

AI에게 문제 해결을 맡겨두고 루프를 돌릴수록, 비용과 지연 시간(Latency)은 늘어난다

 

에이전트 루프는 상태가 계속 누적된다

도구를 호출하고 결과를 확인할 때마다 이전 대화와 실행 로그가 컨텍스트 창에 쌓인다

루프가 반복될수록 매 턴마다 수만에서 수십만 토큰이 중복으로 소비된다

 

시간도 마찬가지다. 도구 호출과 모델의 추론은 직렬로 실행된다. 작업이 조금만 꼬여도 분 단위의 대기 시간이 발생한다

 

예를들어 로그 한 줄로 1분 만에 오타를 찾을 수 있는 문제다. 하지만 에이전트는 원인을 찾겠다며 엉뚱한 파일 수십 개를 열어본다.빌드와 테스트를 반복하며 15분 동안 도구를 돌린다. 사소한 수정 하나에 수만 원 상당의 API 비용이 소모되기도 한다

 

반복 호출을 줄이는 캐싱과 불필요한 누적 텍스트를 잘라내는 컨텍스트 압축도 강제되어야 한다

 

 

4. 보안과 권한의 공포 (격리와 검증)

AI 코딩 도구를 시스템에 연결하는 순간, 기업의 핵심 자산인 소스 코드가 외부에 노출되며 시스템 자체의 보안 취약점도 급격히 증가한다

 

핵심 자산의 외부 유출 

CLI 기반 도구나 에이전트가 프로젝트를 파악하려면 전체 디렉터리를 스캔해야 한다

이 과정에서 회사의 고유 비즈니스 로직, 사내 프레임워크, 심지어 .env 파일의 API 키와 내부 접속 정보까지 모델 개발사의 서버로 고스란히 전송된다. 기업 보안 규정과 컴플라이언스를 정면으로 위반하는 일이다.

 

보안 자체를 AI에게 의존할 수 없다는 점

LLM은 안전한 코드와 취약한 코드를 근본적으로 구별하지 못한다. 인터넷에 널려 있는 취약한 패턴(SQL 인젝션, 하드코딩된 인증)을 그대로 학습해 출력한다

존재하지 않는 패키지를 지어내거나 악성 라이브러리를 의존성에 추가하는 공급망 공격에도 무방비하다

 

보안 점검을 위해 에이전트를 연결했다가 사내 핵심 인프라 토큰이 포함된 파일 전체가 외부 API 로그에 남는 사고가 대표적이다

또한 에이전트가 성능을 개선하겠다며 인증 로직을 우회하거나 검증되지 않은 외부 패키지를 임의로 설치해 시스템에 보안 구멍을 뚫어놓기도 한다

 

에이전트에게 시스템 접근 권한을 무제한으로 열어둘 수 없다. 민감한 파일과 키를 외부 전송 대상에서 강제로 제외하는 필터링이 필요하다

터미널 실행은 도커 같은 격리된 샌드박스로 가두어야 한다. 데이터베이스 수정이나 패키지 추가 같은 핵심 작업에는 반드시 사람의 승인(Human-in-the-Loop)을 거치도록 강제해야 한다

 

 

결국 코드를 제품으로 만드는 것은 개발자의 역량이다

AI 코딩 도구의 본질은 "알아서 다 해주는 완전한 자율"이 아니다. 엄격한 제약 안에서 통제하며 사용하는 불완전한 도구다.

 

레퍼런스가 부족한 고난이도 도메인의 한계, 동작하는 코드와 올바른 코드 사이의 괴리는 모델이 해결해 주지 않는다

무한 루프로 인한 비용과 지연 시간의 폭증, 코드 자산 유출과 보안 취약점 역시 프롬프트 몇 줄로 막을 수 없다

이 문제들을 통제하는 것은 결국 엔지니어의 코드 검증 역량과 외부 격리 시스템이다

 

대략적인 요구사항만 던지는 바이브 코딩으로 프로토타입을 시작할 수는 있다

하지만 끝내 그 코드를 프로덕션 제품으로 완성하고 지탱하는 것은 엔지니어의 철저한 설계와 통제력이다

 

 

---

Reference

40% of AI-Generated Code Has Security Flaws. Your Code Review Won’t Catch Them. - Blog

New GitHub Copilot Research Finds 'Downward Pressure on Code Quality' - Visual Studio Magagine

About OWASP Top 10 for Large Language Model Applications - OWASP