레오는 소프트웨어 개발에 대한 놀라운 지름길을 찾았다고 생각했다.
올해 초, 리드 생성 마케팅 소프트웨어 스타트업을 창업한 레오넬 아세베도(Leonel Acevedo)는 코딩 초보자로서, AI를 활용해 전적으로 작성된 SaaS(서비스형 소프트웨어) 애플리케이션을 출시했습니다. 그는 직접 코드를 건드린 적이 한 번도 없었다. 대신 그는 AI 도구에 프롬프트나 지침을 입력한 뒤, 시스템이 작업을 수행하도록 맡겼다. 그 후, 그는 X( )에 올린 게시물( )을 통해 자신의 성과를 자랑스럽게 세상에 알렸습니다.
큰 실수다.
이틀 뒤, 그가 만든 작품은 공격을 받았다. 해커들은 그의 애플리케이션 프로그래밍 인터페이스(API) 키를 한계치까지 소진시켜, 앱들이 서로 통신하는 방식을 제어하는 시스템을 사실상 마비시켰다. 그들은 유료 회원이 아닌 사용자를 차단하기 위해 마련된 그의 구독 시스템을 우회했다. 그러자 그들은 그의 데이터베이스에 무작위 항목을 생성하기 시작했고, 이를 통해 데이터를 마음대로 조작할 수 있음을 보여주었다.
“제가 저지른 실수를 공개했다는 이유만으로 인터넷 사용자 절반이 제 앱을 무력화시키려 하고 있다”고 아세베도는 적었으며, 곧바로 앱을 중단시켰다. “가장 최악인 게 뭔지 알아? “그들은 그냥 재미로 하고 있는 거예요.”
그 붕괴는 순식간에 일어났고, 많은 교훈을 주었다.
Vibe 코딩(), 즉 AI 모델을 활용해 의 자연어 프롬프트를 바탕으로 완전한 애플리케이션을 생성하는 방식은 소프트웨어 개발의 주류 방식으로 자리 잡았습니다. 구글 브레인(Google Brain)의 창립자 앤드류 응(Andrew Ng)은 월요일 스노우플레이크(Snowflake)의 ‘빌드(Build)’ 컨퍼런스에서 열린 ‘ ’ 강연( )에서 “코딩의 진입 장벽은 이제 그 어느 때보다 낮아졌다”고 말했다. 하지만 바이브 코딩을 그토록 매력적으로 만드는 빠른 개발 속도와 저렴한 비용은, 검토를 거치지 않은 자동 생성 코드를 IT 보안 검토가 거의 또는 전혀 이루어지지 않은 파이프라인에 투입함으로써 위험을 초래하기도 합니다. 그 결과, 점점 더 많은 개인과 조직이 운영을 마비시킬 수 있는 사상 최대 규모의 결함과 해커들이 쉽게 발견하고 악용할 수 있는 취약점을 안고 있는 소프트웨어를 사용하게 될 수밖에 없을 것입니다.
RSA 컨퍼런스(RSAC) 리서치에서 애플리케이션 보안(AppSec) 분야를 담당하는 수석 기술 이사인 에를렌드 오프테달은 “실력 있는 개발자라면 AI로부터 많은 도움을 받을 수 있다. 무엇을 찾아야 하는지, 그리고 AI를 어떻게 유도해야 하는지 알고 있기 때문이다”라고 말했다. “하지만 코딩 실력이 부족한 사람이라면, 자신이 개발 중인 코드를 어떻게 검토해야 하는지 이해하지 못하기 때문에 오히려 상황이 더 나빠질 뿐입니다.” “그냥 무작정 양만 늘리고 있는 거잖아.”
바이브 코딩: 좋은 바이브, 나쁜 바이브, 그리고 그 모든 벤처 캐피털
‘바이브 코딩(vibe coding)’이라는 용어는 AI 연구원 안드레이 카르파티(Andrej Karpathy)가 최근 새로 만든 신조어이며, 지난주 《뉴욕 타임스》( )가 ‘바이브 코딩( )’을 올해의 단어로 선정하기도 했지만, AI를 활용해 코드 작성을 안내하는 관행 자체는 새로운 것이 아니다.
“코딩의 진입 장벽은 이제 그 어느 때보다 낮아졌습니다.”앤드류 응, 구글 브레인 창립자
사실, 이는 2010s년 초반으로 거슬러 올라가는데, 당시 연구자들은 코드 자동 완성 및 프로그램 합성을 위해 머신러닝의 신경망—뇌가 학습하는 방식을 대략적으로 모방해 만든 소프트웨어—를 사용하기 시작했습니다. 이를 계기로 2016 년에 등장한 DeepCoder와 같은 도구 및 구글의 초기 시퀀스-투-시퀀스 모델이 개발될 수 있었으며, 2020s년 초에는 OpenAI의 Codex와 GitHub Copilot과 같은 시스템들이 AI 지원 코딩을 주류로 자리 잡게 했습니다.
이제 그 오랜 노력의 최신 성과가 등장했는데, 의 ChatGPT, GitHub Copilot, Anthropic의 Claude, 그리고 Acevedo가 사용했던 Cursor와 같은 생성형 도구들이 코딩을 훨씬 더 빠르고 쉽게 만들어 주며, 기업들에게도 더욱 매력적인 선택지로 자리 잡고 있습니다. Checkmarx/Censuswide가 실시한 ‘ ’ 설문조사()에 따르면, 지난해 중대형 기업의 개발자 중 90% 이상이 AI를 활용해 코드를 생성한 적이 있다고 응답했다. And 30% to 40% of organizations now actively promote vibe coding, according to a 2024 GitHub survey, presumably to cut costs and accelerate software development lifecycles (SDLs).
[함께 읽어보세요: 바이브 코딩이란 무엇인가요? [장점, 단점 및 논란]
공정하게 말하자면, 소프트웨어 기업들은 경쟁사보다 먼저 시장에 진출하기 위해 코드가 완성되기 전에 출시해 온 것이 사실입니다. 새로운 운영 체제와 애플리케이션에는 수많은 운영 및 보안 결함이 포함되어 있는 것으로 잘 알려져 있으며, 기업이 이를 패치하고 수정하는 데는 수개월이 걸릴 수 있습니다. 의 위험한 관행인 ‘느린 패치 적용’ 이 만연해졌다. 하지만 현재 보안 전문가들이 우려하는 점은, AI를 활용한 코딩이 너무 광범위한 규모의 취약점을 발생시켜 그 중 상당수가 결코 발견되거나 수정되지 못할 수도 있다는 것이다.
사실, 이미 그런 일이 일어나고 있다. 최근 Veracode의 ‘ ’ 연구()에 따르면, 테스트 대상인 100 개 이상의 AI 생성 코드 샘플 중 45%가 보안 테스트에 불합격했으며, 심각한 웹 애플리케이션 보안 위험을 초래한 것으로 나타났습니다.
이러한 우려에도 불구하고, 공급업체와 투자자들은 ‘바이브 코딩’ 열풍에 뛰어들고 있다. In fact, vibe coding tool startups have recently attracted significant venture capital funding, including Cursor-maker Anysphere, which raised $900 million; Replit, which secured $250 million; and Lovable, which raised $200 million.
비록 순수하게 보안에만 초점을 맞춘 것은 아니지만, 이러한 도구 중 상당수는 코드 내 악용 가능한 결함을 검사하는 보안 스캔 기능이나, 노출된 인증 정보가 악용되기 전에 이를 탐지하고 차단하는 자동 API 키 보호 기능 등을 포함하고 있습니다. 그러나 이들은 근본적인 보호 장치가 실제로 제대로 작동하는지 검증하기보다는 문제점을 파악하는 데 그치는 경향이 있다.
Vibe Coding의 가장 과감한 도전가들
새로운 도구의 급증은 또한 ‘바이브 코딩’에서 누가 가장 큰 위험을 감수하고 있는지를 결정짓고 있다. Secure Code Warrior의 공동 창업자이자 CEO인 피터 단히외(Pieter Danhieux)는 스타트업들이 이를 더 적극적으로 도입하는 경향이 있는 반면, 대기업들은 여전히 사람이 결과물을 검토하는 보조 코딩 방식을 고수하고 있다고 말했다.
“민감한 데이터가 포함된 애플리케이션을 보안에 대한 전문 지식 없이 개발하는 것은 재앙을 자초하는 일입니다.”피터 단히외(Pieter Danhieux), Secure Code Warrior 공동 창업자 겸 CEO
“바이브 코딩은 뛰어난 기술력을 갖춘 창업자가 빠르게 진행하고 싶어 하는 소규모 스타트업에서 널리 채택되고 있는 것 같습니다. 이들은 기본적으로 애플리케이션을 직접 검토하지도 않은 채 개발을 시작하고 배포하곤 하죠,”라고 단히외는 말했다.
그는 대기업일수록 더 신중한 편이라고 설명했다. 이 회사의 개발자들은 AI를 활용해 작고 재사용 가능한 코드 조각을 생성할 수는 있지만, 배포 전에는 여전히 결과를 직접 확인합니다.
[관련 기사: 직원들이 ‘섀도우 AI’를 적극적으로 활용하고 있어, 회사 데이터가 위험에 처하고 있다]
겉보기에는 더 안전해 보이지만, 단히외는 그러한 점검이 단지 허울뿐인 안전감만을 줄 뿐일 수 있다고 경고했다.
Secure Code Warrior( )의 연구( )에 따르면, 개발자의 86%가 보안 코딩을 우선순위로 삼지 않는 것으로 나타났으며, 여러 인기 있는 LLM 도구( )들은 보안 코딩 과제, 특히 인증이나 보안 설정 오류와 같이 주관적인 범주에 속하는 문제들을 해결하는 데 어려움을 겪고 있다고( ) Danhieux는 말했다.
Vibe 코딩의 사각지대와 민감한 데이터
단히외는 언어와 취약성 유형에 따라 차이가 있다고 지적했다. 모델은 코드의 철자 오류나 명확한 패턴을 따르는 명백한 문제와 같은 단순한 실수를 포착하는 경향이 있습니다. 하지만 이들은 시스템 설계 방식과 관련된 더 근본적인 문제들, 예를 들어 앱이 누가 어떤 작업을 수행할 수 있는지 제대로 확인하는지 여부를 포함해, 이에 대한 해결에 어려움을 겪고 있다. 이로 인해 사각지대가 발생하는데, AI가 생성한 코드는 겉보기에는 깔끔해 보일 수 있지만 여전히 사용자를 위험에 빠뜨릴 수 있는 취약점을 내포하고 있을 수 있기 때문이다.
“바로 그게 위험입니다. 겉보기에는 그럴듯해 보이고, 실제 운영 환경에서 실행되지만, 제대로 된 검토 과정을 거친 적이 없는 코드를 얻게 됩니다. 버그들은 눈에 띌 만한 곳에 숨어 있다.”RSA 컨퍼런스(RSAC) 리서치 부문 수석 기술 이사, 에를렌드 오프테달
이러한 동향은 애플리케이션 개발 분야 밖에서도 나타나기 시작했는데, 의 ‘VibeScamming’과 같은 악용 사례에서 볼 수 있듯이, 자연어 처리 AI 도구를 의도적으로 활용해 합법적으로 보이지만 기존의 신뢰 신호를 우회하는 피싱 페이지와 사기 인프라를 생성하고 신속하게 반복 개선하고 있다.
단히외는 “노련한 개발자라면 이러한 숨겨진 취약점을 발견할 수도 있겠지만, 초보자들은 이를 파악할 만한 경험이나 직관력이 부족할 것”이라고 말했다. 그는 이러한 위험을 여실히 보여주는 최근 사례를 언급했다. 지난 봄, Lovable AI 코딩 플랫폼에서 생성된 1.645 개 프로젝트를 대상으로 실시한 포괄적인스캔 결과, 해당 도구로 구축된 170 개 애플리케이션에서 303 개의 취약한 엔드포인트가 발견되었으며, 이는 분석 대상 프로젝트의 약 10%에 해당합니다.
“ 의 민감한 데이터 를 포함하는 애플리케이션을, 이를 안전하게 보호할 기술도 없이 코딩하는 것은 재앙을 자초하는 일입니다,”라고 그는 말했다.
현재 이용 가능한 기술은 보안 문제를 포착하는 데 아직 역부족이기 때문에, 특히 코드가 대량으로 생성될 때 상황을 더욱 복잡하게 만들 뿐입니다. RSAC의 오프테달은 “AI 기반 도구가 조만간 탐지에 도움이 될 수는 있겠지만, 그래도 그것만으로는 충분하지 않을 것”이라고 말했다.
“대부분의 기업들은 자사의 오픈소스 거버넌스 가 AI까지 포괄한다고 생각하지만, 사실은 그렇지 않습니다,”라고 그는 말했다. “그게 바로 위험한 점입니다. 겉보기에는 그럴듯해 보이고, 실제 운영 환경에서 실행되지만, 제대로 된 검토 과정을 거친 적이 없는 코드를 얻게 됩니다. “벌레들은 눈에 띌 만한 곳에 숨어 있다.”
[함께 읽어보세요: 자동화를 위한 AI를 올바르게 도입하는 방법 — 효율성을 높이고, 혁신을 주도하며, IT 업무 흐름을 혁신적으로 변화시키는 종합 가이드]
오프테달은 개발자들이 직접 AI에게 더 안전한 코드를 작성하도록 유도하거나, 다른 저명한 개발자들이 채택한 보안 방식을 본받도록 함으로써 기여할 수 있다고 언급했다. 그는 또한 AI에게 작업을 다음 단계로 넘기기 전에 특정 도구를 실행해 작업을 검토하도록 지시할 수도 있다고 말했다.
현황 점검: CEO와 보안 책임자들이 지금 당장 취해야 할 조치들
Danhieux와 Oftedal 같은 전문가들에게 있어, 앞으로 나아갈 길은 ‘ ’가 투명성 과 감독 기능을 확보하는 것에서 시작된다.
“실질적인 ‘설계 단계에서의 보안(secure by design)’ 이니셔티브는… 통제 불능 상태에 빠진 기술 부채와 막대한 비용이 드는 후기 단계의 보안 조치에 대한 해독제입니다.”단히외
기업 리더들이 자사 컴퓨터 네트워크에 연결된 수많은 컴퓨터, 태블릿 및 기타 엔드포인트 에 대한 정보를 파악하고, 운영 체제 및 패치 관리 요구 사항에 대한 실시간 데이터를 확보해야 하는 것처럼, 최고정보보안책임자(CISO) 역시 개발자들이 어떤 AI 코딩 모델을 사용하고 있는지 파악하고 이에 대한 제한을 설정해야 한다고 그들은 말했다. 가격이 저렴하고 구형인 모델은 보안성이 낮은 코드를 생성할 수 있으며, 우선 앱의 구성 요소와 타사 의존성을 나열하는 ‘ ’ 소프트웨어 부품 목록(SBOM)과 같은 감독 체계가 없다면, 조직은 자사 환경에서 어떤 소프트웨어가 실행되고 있는지 전혀 파악하지 못하는 경우가 많습니다.
“어쩌면 개발자들을 위한 안전장치가 마련되는 상황이 올지도 모릅니다. 즉, ‘클로드(Claude) 3 버전 이상과 ChatGPT-4 이상은 사용할 수 있지만, 그보다 낮은 버전은 사용할 수 없다’는 식으로 말이죠. 왜냐하면 그런 버전에서 생성된 코드는 보안상 취약할 것이 분명하기 때문입니다,”라고 단히외는 말했다.
개발자 양성은 이 방정식의 나머지 절반입니다. 작가들이 AI로부터 더 나은 문장을 이끌어내는 법을 배우는 것처럼, 그들도 프롬프트 엔지니어링과 모델을 더 안전한 결과물로 이끄는 방법을 배워야 합니다. 전사적 차원의 도구가 모든 통합 개발 환경 내에서 정책을 강제 적용할 수 있게 될 때까지는, 인식 제고와 교육이 임시 방편이 될 수밖에 없다.
[관련 기사: 최고의 AI 정책이 직원 교육에서 시작되는 이유]
하지만 Danhieux에게 있어 핵심 원칙은 ‘설계 단계부터 보안(secure by design)’이며, 이는 소프트웨어 개발 초기 단계부터 보안을 내재화해야 한다는 것을 의미합니다.
그는 “보안 전문성을 갖춘 개발자들이 주도하는 실질적인 ‘설계 단계부터 보안 고려(secure by design)’ 이니셔티브야말로 통제 불능 상태에 빠진 기술 부채와 막대한 비용이 드는 후기 단계의 보안 조치에 대한 해결책”이라고 말했다. “악의적 행위자들은 이미 기업 보안 팀보다 유리한 입장에 있지만, SDL의 초기 단계에서 보안을 최우선으로 삼는다면 형세를 다시 우리 쪽으로 돌려놓을 수 있습니다.”
Danhieux는 장기적인 우려로, ‘바이브 코딩’이 소프트웨어 개발을 기업 개발 파이프라인에서 거실로 계속 밀어내게 되어, 위협 환경을 확대할 수 있는 취약점이 더 많이 발생할 것이라고 경고했다. 전문 개발자들이 완벽하지는 않을지 몰라도, 그래도 필요한 검증 절차를 거칩니다. 초보 프로그래머들은 그렇지 않으며, 그들의 소프트웨어가 확산됨에 따라 공격 표면은 넓어지고 시스템에 대한 신뢰는 줄어들게 됩니다.
단히외는 이 격차를 해소하는 것이 문제가 더욱 확대되기 전에 반드시 해결해야 할 과제라고 주장한다.““이 보안 문제를 해결하지 못하면, 몇 년 뒤에는 상황이 더 나빠질 것이라고 생각합니다.”라고 그는 말했다.
오프테달도 그 시급성을 강조했습니다.
“벌레들은 이미 밖에 나와 있다”고 그가 말했다. “지금 이 문제를 해결하지 않는다면, 이미 뒤처진 것입니다.”
