에이전틱 AI 시대의 기업 AI의 품질 및 보안 리스크
에이전틱 AI로 경영·법률·금융까지 코드를 만드는 시대, 그러나 AI 생성 코드의 45%가 보안에 취약합니다. 이에 비개발자 코드의 품질·보안 리스크와 국내 기업이 세워야 할 검증·거버넌스 체계를 아티클에 정리했습니다.
Jul 06, 2026
AI 모델 개발사 Anthropic이 2025년 10월부터 2026년 4월까지 약 23만 5천 명, 40만 건의 Claude Code 사용 기록을 조사한 결과를 보고서로 발표했습니다. 보고서 속 데이터에서 가장 눈에 띈 것은 코드를 가장 빠르게 사용하고 늘린 사람들이 개발자가 아니었다는 점입니다. 컴퓨터·수학 직군 다음으로 비중이 컸던 쪽은 경영과 금융이었고, 증가세가 가장 가팔랐던 직군은 경영·영업·법률 종사자였습니다.
같은 기간 사용자들이 도구를 쓰는 방식도 달라졌습니다. 기존 코드를 손보는 작업(코드 수정)의 비중은 33%에서 19%로 내려갔고, 빈자리는 새 코드 작성(25%)과 문서·프레젠테이션 제작(10%)이 채웠습니다. 보조 도구로 코드를 다듬던 단계를 넘어, 처음부터 무언가를 만들어내는 단계로 넘어간 셈입니다.
불과 1년 사이에 달라진, 이 변화의 동력은 뭘까요. 그것은 바로 에이전틱 AI입니다. 에이전틱 AI란 사람의 지시를 받아 여러 단계의 작업을 스스로 계획하고 실행해 끝까지 완결하는 AI를 의미합니다. 한 줄을 추천하던 자동완성과 달리, 에이전틱 AI는 터미널을 직접 조작하고 여러 파일을 한 번에 고치며 테스트까지 돌립니다. 코드를 짜는 능력의 상당 부분을 도구가 대신하면서, 코딩은 더 이상 특정 직군의 전유물이 아니게 됐습니다.
문턱은 분명히 낮아졌습니다. 그러나 낮아진 것은 코드를 만드는 문턱뿐이고, 그 코드가 안전한지 가려내는 검증의 문턱은 그대로 남아 있습니다. 이 글은 에이전틱 AI 확산으로 비개발자까지 코드를 생산하는 시대에 드러난 품질·보안 리스크를 데이터로 짚고, 국내 기업이 무엇을 준비해야 하는지를 정리합니다.
에이전틱 AI는 어떻게 코딩을 개발자 밖으로 꺼냈나
코딩의 진입 장벽을 무너뜨린 흐름에는 '바이브 코딩(vibe coding)'이라는 이름이 붙었습니다. 자연어로 원하는 바를 설명하면 AI가 코드를 만들어주는 방식으로, 프로그래밍 언어를 따로 배우지 않아도 결과물을 얻을 수 있습니다. 이는, 작년 2025년 콜린스 사전이 올해의 단어로 선정했을 만큼 빠르게 확산됐습니다.
규모는 통계로 여실히 확인됩니다. 소프트웨어 개발 분석 매체 Keyhole Software에 따르면, 2026년 미국 개발자의 92%가 매일 AI 코딩 도구를 쓰고 있고, 새로 작성되는 프로덕션 코드의 41~46%가 이미 AI의 손을 거칩니다. 같은 자료에서 바이브 코딩 사용자의 63%는 자신을 개발자가 아니라고 답했습니다. 코드를 만드는 사람의 다수가 비개발자라는 뜻입니다.
시장도 빠르게 커졌습니다. 매일 새로 생성되는 바이브 코딩 프로젝트는 25만 건에 이르고, 관련 도구들의 연간 반복 매출(ARR) 합계는 2025년 말 2억 달러에서 2026년 3월 4억 달러로 반년 만에 두 배가 됐습니다. 도구 지형도 정리됐습니다. 개발 도구 기업 JetBrains가 1만 명 넘는 개발자를 조사한 결과, 업무 채택률은 GitHub Copilot 29%, Cursor 18%, Claude Code 18%로 세 도구가 앞서갔습니다. 그중 Claude Code는 만족도(CSAT) 91%로 가장 높은 충성도를 기록하며 6개월 만에 채택률이 3%에서 18%로 올랐습니다. 자동완성을 거들던 도구와 작업을 끝까지 수행하는 에이전트형 도구가 갈라지며, 후자가 비개발자의 진입을 빠르게 끌어당겼습니다.
이 확산이 위험하기만 한 신호는 아닙니다. 앞서 본 Anthropic의 분석에서 평균 세션의 추정 경제 가치는 27% 올랐습니다. 업무를 수행하는 사람이 직접 도구를 만들어 쓰는 방식은 분명한 생산성 효과를 냈습니다. 국내에서도 한 대기업 그룹이 임직원 80명을 모아 사내 바이브 코딩 해커톤을 열어 업무 자동화 아이디어를 발굴했을 만큼, 개발 부서 밖으로 도구가 번지는 흐름은 이미 현실입니다. 문제는 그 효과와 함께 실제 그 이면에서 일어나고 있는 현상입니다.
비개발자가 짠 코드의 리스크, 그 실태
코드가 늘어난 만큼 안전해졌다면 걱정할 일이 아닙니다. 그러나 데이터는 그 반대를 가리킵니다. 미국의 애플리케이션 보안 기업 Veracode가 누적 150개 이상의 대형 언어 모델을 대상으로 80개 보안 과제를 평가한 결과, 보안 지침을 명시하지 않으면 AI가 생성한 코드의 45%가 알려진 취약점을 포함했습니다. 더 주목할 점은 이 수치가 2년째 거의 그대로라는 사실입니다. 보안 통과율은 줄곧 55% 안팎에 머물러 있습니다.
같은 기간 코드의 '기능'은 빠르게 좋아졌습니다. 문법 정확도는 50%대에서 95% 이상으로 올랐습니다. 돌아가는 코드를 만드는 능력은 크게 발전한 반면, 안전한 코드를 만드는 능력은 거의 제자리에 머물러 있는 셈입니다. 돌아간다는 것과 안전하다는 것 사이의 격차가 그만큼 벌어졌습니다. Veracode는 AI가 생성한 코드가 사람이 작성한 코드보다 취약점을 끌어들일 확률이 1.88배 높다고 분석했습니다.
취약의 종류도 한 모델에 국한되지 않았습니다. 보안 연구 그룹 AppSec Santa가 여섯 가지 모델로 만든 534개 코드 샘플을 웹 보안 취약점 표준 목록인 OWASP Top 10 기준으로 검증한 결과, 25.1%에서 취약점이 확인됐습니다. 가장 나은 모델도 19.1%였고, 하위 모델들은 29.2%에 머물렀습니다. 어떤 도구를 골라도 다섯 개 중 하나꼴로 위험을 안고 있다는 의미입니다. 오픈소스 코드 감사 보고서로 범위를 넓혀도 흐름은 같습니다. 보안 기업 Black Duck이 947개 코드베이스를 분석한 자료에서 코드베이스당 평균 취약점은 581개로, 1년 전보다 107% 늘었습니다.
품질 지표도 같은 방향을 가리킵니다. 개발 생산성 분석 기업 Uplevel이 개발자 약 800명을 추적한 분석에서, AI 코딩 도구를 도입한 뒤 초기 속도 이득은 41%의 버그율 증가로 상쇄됐습니다. 개발자 스스로의 신뢰도 떨어졌습니다. AI가 생성한 코드의 정확도를 신뢰한다는 응답은 2023~24년 40%대에서 2026년 29%로 내려왔습니다. 쓰는 빈도는 늘고 믿는 정도는 줄어드는, 어긋난 곡선이 굳어지고 있습니다.
이 데이터가 AI와의 코딩을 당장 그만둬야 한다는 의미는 아닙니다. 41~46%의 코드가 이미 AI를 거치는 지금의 환경에서 도구를 걷어내는 선택지는 현실적이지 않습니다. 문제는 생산만 빨라지고 검증은 그대로 멈춰 있다는 데 있습니다. 코드를 찍어내는 속도는 몇 배가 됐는데, 그것을 걸러내는 장치는 함께 자리잡지지 못했습니다.
AI가 짠 코드는 왜 보안에 약한가?
추상적인 수치보다 구체적인 사고 유형이 문제를 분명하게 보여줍니다. IT 전문 매체 CIO의 보도에 따르면, AI는 인증에 쓰이는 API 키를 코드에 그대로 박아 넣는 경우가 잦습니다. 자바스크립트(JavaScript)에 들어간 키는 누구나 브라우저 개발자 도구에서 볼 수 있고, 배포된 뒤 평균 15분 안에 자동화된 봇에 탈취됩니다. AI가 만든 데이터베이스를 검증 없이 배포해 익명 접근 키만으로 전체 데이터를 읽고 쓸 수 있게 되는 사례도 보고됐습니다.
이런 결함은 통계로도 쌓이고 있습니다. 클라우드 보안 연구 조직 CSA Labs는 AI 생성 코드에 직접 기인한 신규 취약점(CVE) 등록이 2026년 1월 6건에서 2월 15건, 3월 35건으로 늘었다고 집계했습니다. 보안 기업 Escape.tech가 1,400개 이상의 바이브 코딩 프로덕션 앱을 스캔한 결과에서는 65%가 보안 이슈를, 58%가 한 개 이상의 치명적 취약점을 안고 있었습니다. AI 보조로 작성된 커밋이 비밀번호·토큰 같은 민감 정보를 노출하는 비율은 3.2%로, 사람이 직접 올린 코드(1.5%)의 두 배가 넘었습니다.
규모가 더 큰 사고도 있었습니다. CIO 보도에 따르면 Anthropic의 에이전틱 코딩 도구가 해커에게 악용돼 최소 17개 기관을 대상으로 한 데이터 유출에 쓰였고, 정부·의료·긴급 서비스 기관의 민감 기록이 빠져나갔습니다. 코드를 만드는 일과 공격에 쓰는 일 모두에서 진입 장벽이 동시에 낮아졌다는 점을 보여주는 사건입니다.
왜 비개발자에게서 리스크가 더 커지나
같은 도구를 써도 리스크의 크기는 사용자에 따라 달라집니다. Anthropic의 40만 세션 분석에서 숙련도별 성공률 격차가 뚜렷하게 나타났습니다. 초보 사용자의 작업 성공률은 약 15%, 실패율은 19%였던 반면, 중급 이상은 성공률 28~33%에 실패율 5~7%였습니다. 도구가 같아도 결과를 판별하고 다듬는 역량에 따라 산출물의 질이 갈렸습니다.
필요한 능력은 코드를 쓰는 쪽에서 코드를 의심하는 쪽으로 옮겨가고 있습니다. AI 코딩 도구가 일상이 된 2026년의 과제는 '코드를 어떻게 짤 것인가'가 아니라 '언제 AI 코드를 믿지 말아야 하는가, AI가 어디에서 반복적으로 실패하는가를 아는 것'이라는 분석이 개발자 커뮤니티에서 힘을 얻고 있습니다. 그런데 비개발자에게는 바로 이 판별과 검증의 경험이 부족합니다. 결과물이 일단 작동하면 안전하다고 받아들이기 쉽습니다.
조직 차원의 병목도 겹칩니다. 프로덕션으로 들어오는 코드의 양은 늘었는데, 그것을 검토할 사람의 용량은 그대로입니다. 이 격차는 에이전틱 코딩 도구를 대규모로 도입한 거의 모든 기업에서 벌어지고 있습니다. 여기에 통제 장치까지 비어 있습니다. 한 거버넌스 조사에서 기업의 91%가 AI 거버넌스 프레임워크를 갖추지 못한 것으로 나타났습니다. 노코드·로우코드 시대에 만들어진 통제 가정은 시민 개발자가 단순한 화면을 조립하던 때를 전제로 합니다. 스스로 논리를 만들고 자율적으로 행동하는 에이전틱 AI 앞에서는 그 가정이 그대로 통하지 않습니다.
검증의 공백은 사용자만의 문제가 아니라 도구의 설계에서도 비롯됩니다. 앞서 본 Veracode의 평가에서 취약점은 '보안 지침을 명시하지 않았을 때' 두드러졌습니다. 무엇을 조심해야 하는지 일러주지 않으면 모델은 가장 흔한 방식, 즉 보안이 약한 방식으로 코드를 채워 넣습니다. 보안 지침을 프롬프트에 넣고, 가드레일을 거는 일은 결국 위험이 어디에 있는지 아는 사람의 몫입니다. 그 경험이 가장 옅은 비개발자에게 도구가 가장 빠르게 번지고 있다는 점에서, 리스크는 사용자층 확산과 같은 방향으로 커집니다.
이 흐름은 일시적 현상으로 보기 어렵습니다. 업계 예측을 종합하면 2026년에는 업무용 도구를 직접 만드는 비즈니스 사용자가 전문 개발자를 4대 1로 앞지를 것으로 전망됩니다. 검토받지 않은 코드를 만드는 사람의 수가 검토할 수 있는 사람의 수를 빠르게 추월하는 구조입니다. 데이터 및 AI 플랫폼 기업 Dataiku는 이 상황을 두고, 노코드 시대의 통제가 정해진 틀 안의 조립을 전제로 설계된 반면 에이전틱 AI는 스스로 논리를 생성하고 행동하기 때문에 기존 거버넌스의 가정 자체가 깨진다고 진단했습니다.
리스크를 통제하는 법: 검증·온보딩·거버넌스
해법은 도구를 바꾸는 데 있지 않습니다. 만들어진 코드를 어떻게 검증하고 통제하느냐가 리스크를 가릅니다. 실무에서 자리 잡고 있는 방법은 분류와 검증, 측정입니다.
먼저 코드의 적용 범위를 명시적으로 나누는 분류 체계입니다. AI가 만든 코드를 그대로 써도 되는 영역(그린 존)과 사람의 검증 없이는 배포할 수 없는 영역(레드 존)을 구분하는 방식입니다. 고객 데이터나 결제처럼 사고의 비용이 큰 영역을 레드 존으로 묶어, AI 도구가 핵심 시스템을 보강하되 대체하지는 못하도록 경계를 긋습니다. 다음은 검증의 제도화입니다. 전통적인 코드 리뷰와 별도로 AI 생성 코드를 위한 전용 점검 항목을 두고, 프로덕션 게이트와 보안 기준을 광범위한 도입 이전에 정의하는 방식입니다. 마지막은 측정입니다. AI에 귀속되는 결함률, 심각도, 리뷰 신뢰도, 배포 후 회귀를 처음부터 계측해 두지 않으면 무엇이 문제인지조차 보이지 않습니다.
측정을 강조하는 데는 이유가 있습니다. 무엇이 얼마나 위험한지 숫자로 보이지 않으면 통제는 구호에 그칩니다. AI에 귀속되는 결함률과 심각도, 리뷰 신뢰도, 배포 후 회귀를 도입 첫날부터 계측해 두면, 어느 영역에서 AI 코드가 반복적으로 실패하는지가 드러나고 그 지점에 검증을 집중할 수 있습니다. 거버넌스를 정책 문서로만 두지 않고 파이프라인에 코드로 심어 상시 작동시키는 접근이 권고되는 것도 같은 맥락입니다. 모든 AI 생성 프로젝트에 담당자를 지정하고, 그 프로젝트가 어떤 데이터를 건드리며 어떤 모델을 호출하는지 처음부터 문서로 남기는 방식입니다.
이런 통제의 필요는 가장 보수적인 산업에서 먼저 제기됐습니다. 글로벌 경영 컨설팅 기업 BCG는 바이브 코딩이 금융권에 들어오는 흐름을 두고 최고재무책임자(CFO) 차원의 가드레일이 필요하다고 짚었습니다. 미국의 IT 연구·자문 회사 Gartner는 거버넌스와 품질 통제 없이 AI 코딩이 확산될 경우 2028년까지 소프트웨어 결함이 최대 2,500% 늘어날 수 있다고 경고했습니다. 국내보다 도입이 빠른 북미에서는 비밀정보 노출과 코드 난립(code sprawl)을 막기 위해 최고정보보안책임자(CISO)들이 저장소에 깊이 결합해 보안과 설계 패턴을 자동으로 점검하는 도구를 배치하기 시작했습니다.
비개발자 코딩, 무엇부터 통제해야 하나?
국내 대형 IT 기업들의 대응이 참고가 됩니다. 시사저널e 보도에 따르면, LG CNS는 에이전틱 AI 개발 플랫폼 'AIND'로 금융권의 코볼(COBOL) 코드를 자바(Java)로 자동 변환하는 작업을 수주 단위에서 분 단위로 줄였습니다. IBM은 코드 현대화 솔루션 'Bob'으로 개발 생산성을 평균 45% 끌어올리고 현대화 속도를 최대 93%까지 높였다고 밝혔으며, 인천시 도입에 이어 9월에는 외부망과 분리된 폐쇄망 구축형 출시를 예고했습니다. 두 사례의 공통점은 성능 자체보다 거버넌스와 보안을 앞세웠다는 데 있습니다. 감사 가능성, 통제, 폐쇄망 적합성이 엔터프라이즈 진입의 실제 열쇠였습니다.
우선순위를 정한다면 출발점은 분류입니다. 우리 조직의 어떤 업무를 비개발자가 AI로 직접 만들어도 되는지, 어디부터는 반드시 검증을 거쳐야 하는지를 먼저 선으로 그어야 합니다. 사내 일정표나 양식 자동화처럼 사고가 나도 피해가 제한적인 영역은 비개발자에게 열어두고, 고객 정보와 결제, 외부 공개 서비스처럼 한 번의 실수가 데이터 유출로 이어지는 영역은 검증 없이는 배포할 수 없도록 닫는 식입니다. 그 위에 AI 코드 전용 리뷰 게이트를 얹습니다. 비밀정보가 코드에 박혀 있지 않은지, 외부에서 데이터에 접근할 통로가 열려 있지 않은지처럼, AI가 반복적으로 실수하는 항목을 전통적인 리뷰와 분리된 점검표로 만들어 배포 직전에 자동으로 거르는 방식입니다.
비개발자 온보딩 과정에는 도구 사용법만이 아니라 'AI 코드를 의심하는 법'을 함께 넣어야 합니다. 결과물이 작동한다는 사실과 안전하다는 사실은 다르다는 것, 이 한 가지를 먼저 가르치는 일이 가장 값쌉니다. 앞서 본 숙련도별 성공률 격차는 비개발자가 더 위험한 사용자라는 뜻이 아니라, 짧은 검증 훈련만으로도 결과물의 질을 끌어올릴 여지가 크다는 뜻으로 읽는 편이 정확합니다.
준비된 조직과 준비되지 않은 조직
에이전틱 AI가 코딩을 개발자 밖으로 꺼낸 흐름은 되돌리기 어려운 추세입니다. 경영·법률·금융 직군이 직접 도구를 만들어 쓰는 방식은 분명한 생산성 효과를 내고 있고, 그래서 더 빠르게 번질 가능성이 높습니다. 통제해야 할 대상은 확산이 아니라 검증의 공백입니다.
지금 손에 쥘 수 있는 행동은 분류와 검증, 교육으로 모입니다. 가장 먼저 AI가 만든 코드의 적용 범위를 위험도에 따라 나누고, 사고 비용이 큰 영역을 사람의 검증 아래 두는 일입니다. 그 위에 전통적인 리뷰와 분리된 AI 코드 전용 검증 게이트를 두어 배포 이전 단계에서 위험을 거릅니다. 마지막으로 비개발자 온보딩에 결과물을 의심하는 훈련을 넣어, 도구를 쥐여주기 전에 의심하는 눈을 먼저 길러 줍니다. 어느 것도 새 도구를 사지 않고 시작할 수 있는 일입니다.
국내 환경에서는 한 가지를 덧붙일 만합니다. LG CNS와 IBM의 사례가 보여주듯, 한국 시장에서 에이전틱 AI 도구가 받아들여지는 기준은 성능 수치보다 감사 가능성과 폐쇄망 적합성이었습니다. 금융과 공공처럼 규제가 강한 영역이 먼저 움직이는 만큼, 통제 체계를 갖춘 조직일수록 비개발자에게 더 넓은 영역을 안전하게 열어줄 수 있습니다. 통제가 탄탄할수록 더 빠르고 넓은 확산을 감당할 수 있습니다.
같은 에이전틱 AI를 들여도 어떤 조직은 생산성을, 어떤 조직은 보안 사고를 얻는 결과로 귀결될 수 있습니다. 그 차이는 검증과 거버넌스를 먼저 세웠는지에서 갈립니다. 비개발자가 짠 코드의 절반이 취약하다는 데이터를 마주한 지금이, 코드를 만드는 속도가 아니라 그 코드를 가려내는 체계를 점검할 때입니다.
참고 문헌
- Veracode, Spring 2026 GenAI Code Security Update (2026-03-24)
- Anthropic Claude Code 사용 기록 40만 건 분석 / 디지털투데이 보도 (2026-06-18)
- Keyhole Software, Vibe Coding Trends 2026 (2026-06-11)
- JetBrains Research, AI 코딩 도구 업무 사용 실태 조사 (2026-04)
- BCG, Vibe Coding Is Coming to Finance. CFOs Need Guardrails (2026)
- 시사저널e, 바이브 코딩 기업 시장 진출 (2026-06-08) / CIO Korea, 바이브 코딩 보안 취약점 보도 (2026)
Share article