AI가 쓴 코드는 정말 안전할까요, 프로그래밍 언어 스케일링 법칙이 바꿀 소프트웨어의 미래

🔍 바이브 코딩 시대 AI가 쓴 코드의 함정, 대규모 시스템 구축에 예측 가능성이 필수적인 이유

요즘 개발자들 사이에서 "바이브 코딩"이라는 말이 안 들리는 날이 없죠. AI한테 맥락만 대충 던져줘도 코드가 뚝딱 나오는 시대, 저도 처음 겪었을 때 정말 놀랐어요. 그런데 편리함 뒤에 불편한 진실이 하나 숨어 있습니다. AI가 만든 코드 상당수에 보안 취약점이 있고, 코드베이스가 커질수록 그 문제가 더 심해진다는 점이에요.

그렇다면 AI 코딩 에이전트가 진짜 믿을 만한 소프트웨어를 만들려면 뭐가 달라져야 할까요. 최근 AI 연구자 그원이 던진 연구 제안 하나가 업계에서 화제가 되고 있는데요, 핵심은 "어떤 프로그래밍 언어로 코딩하느냐에 따라 AI의 확장성이 근본적으로 달라진다"는 겁니다. 오늘은 이 이야기를 풀어보려고 해요.

AI가 쓴 코드, 실제로 얼마나 위험할까요

말로만 걱정하는 수준이 아닙니다. 2026년 초 발표된 한 GenAI 코드 보안 리포트에 따르면 AI가 생성한 코드의 45퍼센트가 보안 테스트를 통과하지 못했다고 해요. 특히 크로스사이트 스크립팅(XSS) 방어 로직은 AI 생성 코드의 86퍼센트가 제대로 구현하지 못했다는 결과도 있었습니다.

오픈소스 PR 470건을 분석한 조사에서는 더 놀라운 수치가 나왔어요. AI가 함께 작성한 코드는 사람이 작성한 코드보다 보안 취약점 비율이 약 2.74배 높았습니다. 게다가 AI에게 수정을 반복 요청할수록 상황이 나아지기는커녕, 다섯 번 정도 반복 수정한 뒤에는 취약점이 37.6퍼센트나 더 늘어났다는 연구 결과까지 있었죠.

2026년 초 보안 스타트업이 클로드 코드, 오픈AI 코덱스, 커서, 레플릿, 데빈 등 주요 바이브 코딩 도구 5종을 테스트한 결과도 비슷한 그림입니다. SQL 인젝션이나 XSS 같은 고전적인 취약점은 비교적 잘 피했지만, API 인가 로직과 비즈니스 로직에서는 치명적 수준의 결함이 반복적으로 발견됐어요. 연구진은 "AI 에이전트는 개발자가 가진 상식적인 업무 흐름 이해가 없다 보니, 명시적으로 지시받지 않은 예외 상황에 특히 취약하다"고 설명하더라고요.

한 줄 정리 : 편리한 만큼 위험도 크다는 게 지금 데이터가 보여주는 현실입니다.

스케일링 법칙이 뭔지 먼저 짚고 갈게요

스케일링 법칙이란 AI 모델의 크기나 학습 데이터가 늘어날수록 성능이 얼마나 좋아지는지를 수식으로 나타낸 겁니다. 쉽게 말하면 투자 대비 성능 향상 곡선이라고 보시면 돼요.

챗GPT나 클로드 같은 대규모 언어 모델이 왜 계속 발전하는지, 앞으로 어디까지 좋아질 수 있는지를 예측하는 데 이 스케일링 법칙이 쓰입니다. 그런데 흥미롭게도 코딩 AI에 이 법칙을 체계적으로 적용한 연구는 아직 많지 않아요. 그원의 연구 제안은 바로 이 빈틈을 파고듭니다. 프로그래밍 언어별로 스케일링 법칙을 각각 측정해보자는 거죠.

한 줄 정리 : AI가 더 많은 코드를 볼수록 얼마나 잘 이해하게 되는지, 그 속도를 언어별로 재보자는 아이디어입니다.

사람들이 흔히 하는 오해, 지금 잘한다고 계속 잘하는 게 아니다

많은 분들이 이렇게 생각하세요. "파이썬은 데이터가 많으니까 AI가 잘 쓸 거고, Lean처럼 낯선 언어는 AI가 못 다룰 거야." 어느 정도는 맞는 얘기예요. 실제로 프로그래밍은 데이터에 특히 민감한 분야라, 학습 데이터가 많은 언어일수록 지금 당장의 AI 성능은 뛰어납니다.

그런데 여기 반전이 있습니다. 지금 잘한다고 나중에도 계속 잘하는 건 아니라는 거예요.

파이썬은 작은 코드에서는 AI가 정말 잘 다룹니다. 수백 줄짜리 스크립트라면 AI가 전체 흐름을 한눈에 파악하고 척척 수정하죠. 그런데 코드베이스가 수십만 줄로 커지면 얘기가 달라져요. 동적 타입, 예외 처리, 몽키 패칭 같은 유연한 요소들이 쌓이면서 AI도 전체 구조를 헷갈리기 시작합니다. 어떤 파일이 다른 파일의 동작을 바꾸고 있는지, 숨어있는 전역 변수가 어디서 튀어나오는지 파악하기가 점점 어려워지는 거죠.

한 줄 정리 : 언어의 유연함은 작은 프로젝트에서는 강점이지만, 대규모 코드베이스에서는 AI도 헷갈리게 만드는 독이 됩니다.

예측 가능성이 AI 코딩의 진짜 핵심 지표다

그원이 제안하는 측정 방식은 퍼플렉시티라는 지표를 활용하는 거예요. 퍼플렉시티는 AI가 다음에 올 코드를 얼마나 잘 예측하는지를 수치화한 건데, 쉽게 말해 AI가 얼마나 당황하지 않고 코드를 읽어내는가를 재는 지표입니다.

잘 설계된 코드는 격리된 상태에서도 이해하기 쉬워요. 파일 하나만 읽어도 전체 시스템이 그려지고, 입출력이 명확하죠. 반대로 설계가 나쁜 코드는 모듈 하나를 이해하려고 파일 열 개를 뒤져야 합니다. AI 입장에서는 이게 바로 예측하기 어렵다는 신호로 나타나요.

더 흥미로운 부분은 규모가 커질 때 예측 가능성이 어떻게 변하느냐예요. 좋은 코드는 많이 읽을수록 오히려 이해가 쉬워집니다. 패턴이 눈에 들어오고, 다음에 뭐가 올지 예측하기 쉬워지거든요. 반면 나쁜 코드는 많이 읽어도 답이 없습니다. 보면 볼수록 예외 케이스와 숨은 동작만 더 튀어나오죠.

한 줄 정리 : 코드의 예측 가능성이야말로 AI가 그 언어로 대규모 프로젝트를 잘 다룰 수 있는지 알려주는 핵심 척도입니다.

Lean이라는 언어, 왜 갑자기 주목받나요

Lean은 마이크로소프트 리서치에서 개발하고 지금은 아마존 웹서비스에서 지원하는 오픈소스 언어예요. 단순한 코딩 언어가 아니라 증명 보조기이기도 합니다. 코드가 수학적으로 올바르다는 걸 증명할 수 있다는 뜻이에요.

Lean으로 짠 코드는 메모리 안전성 문제나 경계 오류, 잘못된 형변환 같은 전통적인 보안 취약점이 언어 차원에서 원천 차단됩니다. 2026년에는 파일 압축 라이브러리 zlib를 아예 Lean으로 재작성하는 프로젝트까지 나왔어요. AI가 세상의 소프트웨어를 쓰는 시대에 누가 그걸 검증할 것이냐는 질문에, Lean이 하나의 답을 내놓고 있는 셈이죠.

2025년 5월 기준 Lean의 수학 라이브러리 mathlib에는 정리 21만 개, 정의 10만 개 이상이 형식화돼 있습니다. 딥시크도 2025년 4월에 Lean 전용 AI 모델 DeepSeek-Prover-V2를 발표했을 정도로, 글로벌 AI 기업들이 이미 Lean을 주목하기 시작했어요.

한 줄 정리 : Lean은 코드의 수학적 정합성을 증명할 수 있는 언어로, AI 시대 소프트웨어 보안의 새로운 대안으로 떠오르고 있습니다.

닭이 먼저냐 달걀이 먼저냐, Lean의 딜레마

그럼 Lean이 AI 코딩의 미래라면 왜 아직 주류가 아닐까요. 여기서 구조적인 역설이 등장합니다.

AI가 Lean 코드를 잘 쓰려면 대규모 Lean 코드베이스가 필요합니다. 그런데 대규모 Lean 코드베이스를 만들려면 AI가 Lean을 잘 다뤄야 해요. 전형적인 닭과 달걀 문제입니다.

지금은 Lean 코드의 절대량이 파이썬이나 자바스크립트에 비해 훨씬 적어서, AI의 Lean 실력도 현시점에서는 한계가 뚜렷해요. 하지만 그원의 주장은 여기서 중요해집니다. 지금 당장의 절대 성능이 아니라 스케일링 지수, 즉 데이터가 늘어날 때 성능이 얼마나 빨리 좋아지는가를 봐야 한다는 거예요.

그원의 예측대로라면 파이썬 같은 동적 언어는 초기 성능은 좋지만 스케일링 지수가 나쁩니다. 반면 Lean은 초기 성능은 낮아도 스케일링 지수가 더 좋아요. 어느 시점을 지나면 Lean이 대규모 코드에서 파이썬을 앞설 수도 있다는 뜻이죠.

한 줄 정리 : 지금 Lean이 불리한 건 데이터 부족 때문이지 언어 자체의 한계가 아닙니다. 투자 여부에 따라 역전이 가능하다는 얘기예요.

사람들이 놓치는 부분, 지금이 아니라 교차점을 봐야 한다

이 연구에서 많은 분들이 오해하는 지점이 있어요. "지금 파이썬 AI가 Lean AI보다 훨씬 잘하잖아요, 그럼 파이썬이 계속 이기는 거 아닌가요?"

아닙니다. 그원이 말하려는 핵심은 교차점 개념이에요. 지금은 파이썬이 앞서 있지만, 코드베이스가 충분히 커지는 어느 시점에서 Lean이 역전할 수 있다는 겁니다.

이건 단거리 선수와 마라톤 선수 비교와 비슷해요. 100미터에서는 단거리 선수가 압도적이지만, 42킬로미터를 달리면 결과가 뒤집힙니다. 지금 AI 코딩 평가는 대부분 단거리 경주예요. 수백 줄, 수천 줄짜리 코드로 테스트하죠. 그런데 실제 기업 소프트웨어는 수백만 줄 단위잖아요. 그 스케일에서의 성능은 아직 아무도 제대로 재본 적이 없습니다.

한 줄 정리 : 지금의 AI 코딩 언어별 순위는 작은 스케일 기준일 뿐, 대규모 코드베이스에서는 판도가 완전히 달라질 수 있습니다.

앞으로 어떻게 바뀔까요

이 연구 제안이 실제로 진행되고 예상대로 결과가 나온다면 두 가지 큰 변화를 예상할 수 있어요.

첫째, 기업들이 핵심 시스템을 Lean 같은 형식 검증 언어로 재작성하는 데 투자할 이유가 생깁니다. 특히 금융, 의료, 항공우주처럼 결함이 치명적인 분야에서 먼저 움직일 가능성이 높아요. AI가 Lean 코드를 더 잘 다루게 되면 재작성 비용도 낮아지니, 선순환이 시작되는 거죠.

둘째, 프로그래밍 언어를 고르는 기준 자체가 바뀔 수 있습니다. 지금까지는 개발자 생산성과 생태계 크기가 주요 기준이었어요. 그런데 AI 에이전트가 코드를 쓰는 비중이 점점 커진다면, "이 언어로 AI가 대규모 코드를 얼마나 안전하게 다룰 수 있는가"가 더 중요한 기준이 될 수 있습니다. 실제로 개발자 커뮤니티 조사에서 응답자의 85퍼센트가 코딩과 개발에 AI 도구를 정기적으로 사용한다고 답할 만큼, 이 변화는 이미 빠르게 진행 중이에요.

한 줄 정리 : AI가 코드를 대신 쓰는 시대에는 언어 선택 기준이 바뀝니다. 개발자 편의성보다 AI가 얼마나 안전하고 정확하게 다루는가가 더 중요해질 수 있어요.

마무리

AI 코딩 에이전트의 미래는 모델이 커지는 것만으로 결정되지 않습니다. 어떤 언어로 코딩하느냐, 그 언어가 대규모에서 AI에게 얼마나 예측 가능한가가 핵심 변수예요. 파이썬처럼 지금 당장 편한 언어가 수백만 줄 규모에서도 최선일지는 아직 아무도 검증하지 않았습니다. Lean처럼 지금은 낯설어도 데이터가 쌓이면 AI 코딩의 핵심 언어가 될 수 있다는 게 그원의 핵심 주장이에요.

지금 당장 Lean을 배울 필요는 없어요. 하지만 AI가 소프트웨어 개발의 주역이 되는 시대에, 어떤 언어가 AI와 함께 안전하고 신뢰할 수 있는 대규모 시스템을 만드는 데 적합한지는 이제부터 진지하게 고민해볼 시점입니다. 바이브 코딩으로 뭔가를 빠르게 만드는 건 여전히 매력적이지만, 그 코드가 나중에 얼마나 예측 가능하고 안전한 구조로 자라날지는 지금부터 챙겨봐야 할 문제예요.