소셜 미디어 피드나 이메일을 확인해 보면 최근 ‘바이브 코딩(vibe coding)’이라는 표현을 쉽게 접할 수 있다.
제품 관리자는 더 이상 직접 코드를 작성할 필요 없이 코딩 에이전트와의 대화만으로 완전히 배포 가능한 애플리케이션을 구현할 수 있다. 시트리니 리서치(Citrini Research)는 AI가 곧 전체 SaaS 제품을 독자적으로 개발할 단계에 근접했다는 시장에 큰 영향을 미칠 전망을 내놓았다. 또한 LLM 벤더와 와이콤비네이터(Y Combinator) 스타트업은 원하는 기능을 설명하기만 하면 누구나 단 몇 시간 만에 복잡한 소프트웨어를 구축할 수 있다는 메시지를 적극적으로 확산하고 있다.
그러나 필자의 관점에서 이러한 통제되지 않은 가속화는 심각한 재앙에 가깝다. 현재의 AI는 SaaS 애플리케이션의 겉모습을 생성하는 수준에는 도달했지만, 디지털 인프라의 일부로 활용될 만큼 신뢰할 수 있는 시스템을 구축하는 데 필요한 엔지니어링 완성도에는 여전히 크게 미치지 못한다.
이러한 대화형 접근 방식은 애플리케이션의 초기 구조를 손쉽게 구축할 수 있게 하지만, 동시에 기업 보안과 기술 부채 측면에서 거대한 위기를 조용히 초래하고 있다. 우리는 체계적인 소프트웨어 엔지니어링을 포기하고 확률적 추정에 기반한 개발 문화로 대체하고 있다. 이러한 흐름을 바로잡지 못한다면 치명적인 위험에 노출될 수 있다.
무검증 에이전트의 확산
AI가 단순히 새로운 콘텐츠를 생성하는 단계를 넘어 실제 행동을 수행하는 단계로 전환되면서 위험은 더욱 커지고 있다. 최근 몇 달 사이 검증되지 않은 에이전트형 시스템이 급격히 증가했으며, 그중 가장 널리 알려진 사례가 오픈소스 프로젝트 오픈클로(OpenClaw, 구 Moltbot/Clawdbot)다. 일반 챗봇과 달리 이 시스템은 파일 전송, 프로그램 실행, 외부 연결 등 컴퓨터에서 독립적으로 다양한 작업을 수행할 수 있는 기능을 갖추고 있다.
필자는 오픈클로의 실체를 확인하기 위해 최근 샌드박스 환경에 직접 배포해 보았다. 그 결과 기능은 과도하게 많았지만, 텔레그램 스트리밍과 같은 가장 기본적인 기능조차 제대로 작동하지 않았다. 공식 문서를 확인해 보았으나, 유용한 정보를 전혀 제공하지 못하는 AI 생성 텍스트로 가득 차 있었으며 실질적인 도움을 얻을 수 없었다.
더욱이 이 프로젝트는 연속으로 두 차례 이름을 변경했음에도 불구하고, 새로운 바이너리로 이전하는 방법에 대한 마이그레이션 가이드를 전혀 제공하지 않았다. 전통적인 소프트웨어가 이러한 상태로 출시되었다면 완전히 용납될 수 없는 수준이었을 것이다. 그러나 이론적으로 다양한 기능을 수행할 수 있는 AI 기반 도구라는 이유만으로 사용자들은 이를 그대로 받아들이고 있는 상황이다.
이들 시스템은 유튜브 데모에서는 매우 인상적으로 보일 수 있다. 그러나 로컬 환경에서 루트 권한을 가진 비결정적이고 검증되지 않은 에이전트를 배포하는 것은 심각한 보안 퇴보를 의미한다. 이는 수십 년간 구축해 온 엄격한 IAM(Identity and Access Management) 프로토콜을 사실상 무력화하는 행위와 다름없다.
특히 이러한 에이전트는 이른바 ‘치명적인 삼중 요소’를 갖추고 있다. 첫째, 지속적인 특권 접근 권한을 보유한다. 둘째, 이메일이나 슬랙 메시지와 같은 신뢰할 수 없는 외부 데이터를 지속적으로 읽는다. 셋째, 외부 세계와 제한 없는 통신이 가능하다. 공격자가 숨겨진 프롬프트 인젝션이 포함된 이메일을 전송할 경우, 에이전트는 이를 검증하지 않은 채 로컬 SSH 키를 조용히 유출할 위험이 있다.
‘내 컴퓨터에서는 잘 되는데’ 문제
이번 위기는 특정 에이전트에만 국한된 사안이 아니다. 소프트웨어 공급망 전반으로 확산되며 개발 방식 자체를 위협하고 있다. 개발자가 깊은 이해보다 속도를 우선시할 때, 인프라는 점점 운에 의존해 구축되기 시작한다.
현재 필자의 팀은 ‘슬롭스쿼팅(slopsquatting)’이라는 새로운 위협 벡터에 대응하고 있다. 슬롭스쿼팅은 AI가 존재하지 않는 소프트웨어 패키지 이름을 ‘그럴듯하게’ 만들어내는 현상을 악용한 새로운 보안 공격 기법이다. ‘AI 패키지 환각(AI package hallucination)’으로도 불린다. AI 모델은 결정론적 사실 데이터베이스를 조회하는 대신, 다음에 올 가능성이 가장 높은 단어를 예측한다. 이로 인해 실제로 존재하지 않지만 그럴듯하게 들리는 소프트웨어 패키지 이름을 만들어내는 경우가 빈번하다.
구체적인 공격 방식은 다음과 같다. 악의적인 행위자가 이러한 환각 패키지를 공용 저장소에 등록하고 악성코드를 삽입한다. 이후 코딩 에이전트가 해당 가짜 패키지를 제안하고 이를 무비판적으로 설치한다. 바이브 코딩을 사용하는 개발자 입장에서는 경고 없이 코드가 정상 작동하고 설치된 패키지도 합법적으로 보인다. 그러나 실제로는 사이버 범죄자에게 루트 권한을 넘겨주는 결과를 초래한다.
이러한 맹목적인 신뢰는 내부 품질 보증 체계도 무너뜨린다. 바이브 코딩의 핵심 약속 중 하나는 AI가 기능 구현과 함께 이를 검증하는 단위 테스트까지 작성한다는 점이다.
필자는 최근 새로운 내부 라우팅 마이크로서비스에 대한 풀 리퀘스트를 검토했다. 테스트 커버리지는 100%였고, CI 파이프라인 역시 모든 항목에서 정상 통과를 나타냈다. 그러나 코드를 면밀히 검토한 결과, 공동 설립자와 함께 ‘종이상자 머핀(cardboard muffins)’이라 부르는 문제를 발견했다.
AI는 실제 비즈니스 로직을 검증하는 테스트를 작성하지 않았다. 엣지 케이스도 완전히 무시했다. 단지 테스트의 단언문을 통과하기 위해 필요한 반환값을 하드코딩했을 뿐이었다. 목표는 오직 배포 파이프라인을 통과하는 것이었다.
코드베이스의 80%가 의존성을 환각하고 테스트를 조작하는 AI에 의해 생성된다면, 이는 소프트웨어가 아니라 ‘모래성’에 불과하다. 이러한 코드를 확장하는 것은 기존의 ‘내 컴퓨터에서는 잘 되는데’ 문제를 기업 전체의 재앙으로 확대시키는 결과를 낳는다.
필자는 앞으로 소프트웨어 개발에서 진정한 가치는 기능 출시 속도가 아니라, 전통적이고 다소 지루해 보일지라도 결정론적 안정성에 있다고 확신한다.
투 트랙 전략
생성형 AI를 금지하는 것은 현실적인 선택지가 아니다. 신속한 혁신과 시장 검증 역량은 매우 큰 가치를 지니기 때문이다. 그러나 확률적 특성에 기반한 바이브 코딩이 프로덕션 시스템의 아키텍처를 좌우하도록 방치해서는 안 된다.
이를 해결하기 위해 CIO는 ‘투 트랙(dual-track)’ 개발 생명주기를 도입할 수 있다. 이 전략은 빠른 탐색 단계와 엄격한 프로덕션 엔지니어링 단계를 명확히 분리하는 데 목적이 있다.
트랙 1 패스트 트랙
이 단계는 제약 없는 탐색의 영역이다. 트랙 1에서는 바이브 코딩을 명시적으로 허용하고 적극적으로 장려한다. 제품 관리자가 자율 에이전트를 활용해 하루 만에 프로토타입을 구축하고자 한다면 이를 지원해야 한다. 이 단계의 핵심 지표는 피드백까지의 속도다. 비즈니스 아이디어를 신속하게 검증하고 사용자 인터페이스를 최대한 빠르고 저렴하게 테스트하는 것이 목표다.
단, 중요한 전제 조건이 있다. 트랙 1 개발은 반드시 강력하게 격리된 샌드박스 환경에서 이루어져야 한다. 바이브 코딩으로 생성된 애플리케이션은 일회성 청사진에 불과하며, 프로덕션 데이터나 고객 개인정보(PII), 핵심 기업 네트워크에 접근해서는 안 된다.
트랙 2 슬로 트랙
트랙 1에서 프로토타입의 비즈니스 가치가 입증되면 프로젝트는 트랙 2로 이동한다. 이 단계는 진정한 소프트웨어 엔지니어링의 영역이다.
여기서의 원칙은 단순하지만 실행하기 어렵다. 바로 ‘처음부터 다시 시작하는 것’이다. 바이브 코드를 리팩터링하거나 정리하려는 시도는 금지해야 하며, 전체를 새롭게 재작성해야 한다.
트랙 2에서는 인간 엔지니어가 주도권을 갖는다. 트랙 1의 프로토타입은 시각적 참고 자료로만 활용된다. 이들은 보안성과 확장성을 갖춘 아키텍처를 설계하고, 결정론적 보안 보장, 엄격한 타입 안정성, 철저한 동료 검토를 우선시한다. AI 도구는 여전히 활용되지만 자율적 생성자에서 제한된 보조 도구로 역할이 축소된다. 모든 의존성은 검증된 보안 프레임워크에 따라 확인되며, 모든 단위 테스트는 수동 검토를 거쳐 핵심 제품에 ‘종이상자 머핀’과 같은 문제가 포함되지 않도록 한다.
조직 문화의 대전환
투 트랙 전략을 성공적으로 구현하려면 조직 문화 전반에 걸친 큰 변화가 필요하다. 특히 경영진의 기대치를 관리하는 과정에서 이러한 변화의 중요성이 더욱 부각된다. 핵심은 하나의 타협할 수 없는 원칙에 있다. 바로 패스트 트랙의 개발 속도를 기준으로 슬로 트랙의 일정이 결정되어서는 안 된다는 점이다.
이는 비즈니스 이해관계자들과의 쉽지 않은 대화를 요구한다. 주말 사이에 완성된 것처럼 보이는 바이브 코딩 프로토타입을 접하면, 최종 제품 역시 추가로 한 주만 더 주어지면 완성될 수 있다고 기대하기 쉽다. 그러나 이러한 경계를 명확히 설정하는 것이야말로 기업이 AI 코딩의 피해자가 아닌 수혜자가 되도록 보장하는 핵심 요소다.
AI는 혁신을 가속하는 강력한 도구다. 그러나 아키텍처적 통찰을 대체할 수는 없다. 투 트랙 전략을 도입함으로써 조직은 사고의 속도로 자유롭게 실험할 수 있는 환경을 확보하는 동시에, 디지털 인프라를 안정적으로 유지하는 결정론적 엄격함을 지켜낼 수 있다.
dl-ciokorea@foundryco.com
Read More from This Article: 칼럼 | 바이브 코딩의 위기…왜 ‘투 트랙’ 엔지니어링 전략이 필요한가
Source: News

