지난주, 저는 한 스타트업의 주니어 개발자가 마이크로서비스 하나를 통째로 프로덕션에 배포하는 것을 목격했습니다. 모든 코드가 AI 코딩 어시스턴트로 작성된 것이었습니다. 그 어떤 사람도 코드를 리뷰하지 않았습니다. 제가 이에 대해 물었을 때, 그는 어깨를 으쓱하며 말했습니다. "테스트 통과했는데요." 그날 밤, 그 대화가 계속 머릿속을 맴돌았습니다.
최근 해커뉴스에 "리뷰되지 않은 AI 생성 코드의 자동화된 검증을 향하여(Toward Automated Verification of Unreviewed AI-Generated Code)"라는 제목의 논의가 올라왔는데, 바로 이 커져가는 불안감을 정면으로 다루고 있습니다. 시기적으로 이보다 적절할 수 없습니다. 우리는 AI가 생성한 코드가 인간이 리뷰할 수 있는 속도보다 빠르게 배포되는 변곡점에 도달했으며, 생성 속도와 검증 역량 사이의 격차는 점점 벌어지고만 있습니다.
대부분의 AI 생성 코드는 제대로 된 리뷰를 받지 못한다
불편한 진실이 하나 있습니다. 대부분의 AI 생성 코드는 제대로 된 리뷰를 받지 못합니다. 개발자들이 게을러서가 아니라, 단순히 양이 감당할 수 없을 정도로 많기 때문입니다. GitHub의 자체 데이터에 따르면 Copilot을 사용하는 개발자들은 코드 제안을 약 30%의 비율로 수락하며, 이 비율은 계속 올라가고 있습니다. 이를 수백만 명의 개발자에 곱해 보면, 모델 출력에서 프로덕션까지 기껏해야 훑어보는 정도로만 거쳐 간 막대한 양의 코드가 존재하는 셈입니다.
저부터 인정하겠습니다. 저도 그랬습니다. 제안을 수락하고, 실행하고, 테스트가 초록불이면 넘어갔습니다. 누구나 그래 봤을 겁니다. 하지만 "동작한다"와 "정확하고, 안전하며, 유지보수 가능하다"는 전혀 다른 이야기입니다.
해커뉴스 논의는 핵심적인 연구 방향을 조명합니다. 인간 리뷰어 수준의 엄격함으로, 혹은 그 이상으로 AI 생성 코드를 검증하는 자동화 시스템을 구축할 수 있다면 어떨까요?
자동화된 검증의 세 가지 접근법, 그리고 그 트레이드오프
그래서 구체적으로 무슨 이야기를 하는 걸까요? 단순히 린터를 돌리는 것이 아닙니다. 논의되고 있는 접근법은 여러 범주로 나뉘며, 각각 흥미로운 트레이드오프를 가지고 있습니다.
형식 검증(Formal verification)은 가장 이상적인 표준입니다. 코드가 의도한 대로 동작한다는 것을 수학적으로 증명하는 방식입니다. Dafny 같은 언어와 SMT 솔버 기반 도구들이 특정 속성을 완전히 검사할 수 있습니다. 문제는요? 역사적으로 극도로 느리고 좁은 영역에만 적용 가능했다는 것입니다. 하지만 여기서 흥미로운 점이 있습니다. LLM 자체가 코드와 함께 형식 명세를 생성할 수 있을지도 모른다는 것입니다. AI가 에세이와 채점 기준을 동시에 작성하는 것이라고 생각하면 됩니다.
속성 기반 테스팅(Property-based testing)은 보다 실용적인 중간 지점에 위치합니다. 정확성을 증명하는 대신, 항상 참이어야 하는 속성을 정의하고 수천 개의 무작위 입력을 코드에 던지는 방식입니다. Python의 Hypothesis나 Haskell의 QuickCheck 같은 도구들이 수년간 이 작업을 해왔습니다. 새로운 관점은 AI를 활용하여 이러한 속성 정의를 자동으로 생성하는 것입니다.
머신러닝 강화 정적 분석(Machine-learning-enhanced static analysis)도 또 다른 경로입니다. 기존의 정적 분석기는 알려진 버그 패턴을 잡아내지만, 새로운 접근법은 대규모 취약점 데이터베이스로 학습된 모델을 사용하여 규칙 기반 시스템이 놓칠 수 있는 의심스러운 패턴을 감지합니다. 본질적으로, 첫 번째 AI의 작업을 의심하도록 두 번째 AI를 훈련시키는 것입니다.
이 접근법들은 각각 단독으로는 심각한 한계가 있습니다. 연구 커뮤니티에서 형성되고 있으며 해커뉴스 논의에서도 반영된 합의는, 여러 방법을 결합하는 다층 검증만이 아마도 유일하게 현실적인 전진 경로라는 것입니다.
AI 생성 코드의 40%에 취약점이 있다. 이제 어떻게 할 것인가?
이것을 좀 더 구체적으로 말씀드리겠습니다. Snyk의 연구에 따르면 AI 생성 코드의 약 40%가 보안 취약점을 포함하고 있습니다. 오타가 아닙니다. 열 개 중 네 개의 코드 제안에 보안 문제가 있다는 것입니다. 이것이 핵심 인프라, 금융 시스템, 의료 애플리케이션에 흘러 들어간다고 상상해 보십시오.
해커뉴스 스레드에 댓글을 단 개발자들이 제 뇌리에 박힌 지적을 했습니다. 한 사람은 우리가 본질적으로 "기술 부채 가속기"를 만들고 있다고 주장했습니다. AI가 더 빠르게 배포할 수 있게 해주는 것은 맞습니다. 하지만 그 코드가 제대로 검증되지 않았다면, 속도를 앞당기는 만큼 재앙을 뒤로 미루고 있을 뿐입니다.
또 다른 관점이 있는데, 저는 이것도 마찬가지로 타당하다고 생각합니다. 자동화된 검증이 실제로 AI 생성 코드를 인간이 작성한 코드보다 *더* 신뢰할 수 있게 만들 수 있다는 것입니다. 인간은 피로해집니다. 컨디션이 안 좋은 날이 있습니다. 마감이 다가오면 리뷰를 건너뜁니다. 자동화된 검증 파이프라인은 지치지 않습니다. 금요일 오후라고 대충 넘어가지 않습니다.
이분법적 신뢰에서 단계적 신뢰도로
이것은 저 자신도 아직 고민 중인 부분입니다. 완벽한 자동화된 검증을 구축하더라도, 더 근본적인 질문이 남습니다. 신뢰를 어떻게 조정할 것인가?
현재 개발자들은 두 진영으로 나뉘는 경향이 있습니다. "AI 맹신론자"는 모든 제안을 의심 없이 수락합니다. 회의론자는 결과물을 신뢰할 수 없다는 이유로 AI 코딩 도구 사용 자체를 거부합니다. 두 입장 모두 틀렸고, 두 입장 모두 이해할 수 있습니다.
자동화된 검증이 제공할 수 있는 것은 신뢰 신호입니다. 이분법적이지 않은, "안전" 또는 "위험"이 아닌, 하나의 스펙트럼입니다. 예를 들어 이런 것입니다. "이 함수는 명세에 대해 높은 신뢰도로 형식 검증되었습니다" 또는 "이 코드는 속성 테스팅을 통과했지만 에러 처리 경로에서 인간의 주의가 필요한 비정상적인 패턴이 포함되어 있습니다."
이런 종류의 세밀한 신호는 팀이 AI를 개발 워크플로에 통합하는 방식을 근본적으로 바꿀 수 있습니다. 인간 리뷰어의 역할이 "모든 것을 확인하라"에서 "자동화 시스템이 불확실성을 표시한 곳에 주의를 집중하라"로 전환됩니다. 이것이 훨씬 더 지속 가능한 모델입니다.
규제가 다가오고 있다. 검증 파이프라인이 먼저여야 한다.
제가 틀릴 수도 있지만, AI 생성 코드의 자동화된 검증이 앞으로 몇 년간 소프트웨어 엔지니어링을 정의하는 핵심 과제 중 하나가 될 것이라고 믿습니다. AI 코드 생성이 느려질 것이기 때문이 아닙니다. 느려지지 않을 것입니다. 대규모로 검증되지 않은 코드가 초래하는 결과가 무시하기에는 너무 위험하기 때문입니다.
우리는 이미 초기 규제 신호를 목격하고 있습니다. EU AI Act에는 고위험 AI 시스템에 관한 조항이 포함되어 있으며, 이는 핵심 애플리케이션의 AI 생성 코드에까지 충분히 확장될 수 있습니다. 검증 없이 AI가 작성한 코드를 의료 기기나 자율주행 차량에 탑재하고 있다면, 규제 기관이 이에 대해 의견을 가질 것입니다. 매우 강한 의견을요.
연구 커뮤니티는 빠르게 움직이고 있습니다. Google DeepMind, Meta의 FAIR 연구소, 그리고 여러 학술 그룹의 팀들이 검증 인식 코드 생성(verification-aware code generation)에 매진하고 있습니다. 모델이 단순히 코드를 작성하는 것이 아니라, 이를 검증하는 데 필요한 증명이나 테스트도 함께 생산하는 방식입니다. 이것이 올바른 방향이라고 느껴집니다.
하지만 우리는 아직 초기 단계입니다. 정말 초기입니다. 도구는 파편화되어 있고, 표준은 아직 존재하지 않으며, 대부분의 조직은 이 문제 자체를 인지조차 하지 못하고 있습니다. 개발자이거나 엔지니어링 리더라면, 지금이 AI 생성 코드에 대한 검증 파이프라인이 어떤 모습이어야 하는지 고민을 시작할 때입니다. "사람이 봤습니다"라는 답변은 점점 현실적이지 않게 되고 있으니까요.
여러분의 생각은 어떠신가요? 우리가 과잉 반응하고 있는 걸까요, 아니면 이것이 진정으로 현대 소프트웨어 개발에서 가장 중요한 미해결 문제 중 하나일까요? 저는 계속 오락가락합니다. 하지만 리뷰 없이 머지되는 AI 생성 풀 리퀘스트를 볼 때마다, 같은 결론 쪽으로 조금씩 더 기울게 됩니다. 이 문제를 해결해야 합니다. 빨리요.