AI 어시스트의 부족한 점과 이를 위해 사람이 취할 수 있는 방지책

ai 어시스트는 개발과정에서 필수적인 요소로 자리잡았고,

많은 조직이나 개인이 코드 변경사항에 기계를 개입시켜서 처리한다.

하지만 이렇게 가속화 되는동안, 몇가지 논점은 계속해서 나왔다.

• 왜 더 많은 결함을 가진코드가 탄생하는걸까?

• 특정한 구성이나 논리부분에서 계속 오류를 발생시키는 이유가 뭘까?

• ai 생성 코드와 이 패턴의 연관성은?

2026-Benchmark-Report.pdf

PDF 다운로드 • 17.79MB

해당 보고서에 따르면 ai는 풀리퀘스트 작성에 도움을 주는 경우가 20% 증가하였고, 풀리퀘스트에서 문제가 발생하는 경우는 23.5% 증가하였다.

이때 ai가 시도한 풀리퀘스트는 어떤식으로 다르기에 문제가 발생되는 것일까?

CodeRabbit - State of AI vs Human Code Generation - Report - Lite.pdf

PDF 다운로드 • 12.53MB

이 보고서에서는 CodeRabbit의 구조화된 이슈 분류 체계를 사용하여 470개의 오픈소스(320: ai + 150: 사람) GitHub 풀 리퀘스트(PR)를 분석했다.

해당 보고서에 따르면 가독성, 예외, 경로문제, 보안문제 등 대부분의 범주에서 AI가 작성한 PR에서 훨씬 더 많은 오류가 발생했다.

또한, AI가 이런 패턴(문제점)을 보이는 이유로 아래 다섯가지를 제시하였다.

1. 로컬에 대한 맥락의 부재: LLM은 광범위한 학습 데이터를 통해 일반적인 패턴을 파악하는 데는 능숙하다.

   하지만 반대로 말하면, 통계에 의존한 결과값이기에 특정 프로젝트만의 고유한 제약 조건이나 규칙과도 같은 부분을 놓치고 넘어가는 경우가 많다.

   
   

2. 안전성이 결여된 흐름: AI가 생성한 코드는 겉보기에는 구조적으로 올바른 것처럼 보일 수 있지만, null 체크, 예외 처리 경로와 같은 필수적인 안전 장치가 누락된 경우가 많아, 실제 실행 시 논리적 결함이나 런타임 오류로 이어질 가능성을 크게 가지고 있다.

   개발자들이 직접 코딩한 결과물에선 케이스에 대한 대처가 구성되어있었지만, ai는 그 부분을 간과하고 놓친것이다.

   
   

3. 로컬/프로젝트 준수의 불일치: 모델은 개별 프로젝트가 가진 규칙이나 관습보단 학습된 일반적인 명명 규칙이나 형식을 가지고 작성한다. 이는 AI PR에서 가독성 문제가 크게 발견되는 주요 원인이다.

   
   

4. 보안 문제 간과: 명시적인 제약 조건이 주어지지 않으면, LLM은 학습 데이터에 포함된 오래되거나 안전하지 않은 예전의 패턴을 그대로 반영하고, 사용한다. 이런 문제점은 부적절한 비밀번호 처리나 안전하지 않은 참조와 같은 보안 취약점을 빈번하게 발생시켜버린다.

   
   

5. 비효율적인 리소스 사용: AI 모델은 별도의 프롬프트 지시가 없는 한, 명확한 코드를 우선시하여 생성하는 경우가 많다. 결과적으로 반복적인 네트워크 호출, 비최적화된 데이터 구조 사용 등 시스템 성능을 저하시키는 코드로 구성하여 리소스를 필요 이상으로 잡아먹게 된다.

이러한 문제에 대해 대처하면서 작업 하는 방법에는 무엇이 있을까?

보고서에서는 결함을 방지하는 로드맵으로 아래 여섯가지를 제공하였다.

1. 모델에 사전 정보로 문맥/프로젝트 정보를 가능한 선에서는 최대한 제공한다.

   AI가 프로젝트의 고유한 특성을 이해할 수 있도록 구성 패턴, 아키텍처 규칙과 같은 프로젝트별 제약 조건을 사전에 제공해야한다.

   모델이 로컬의 정보에 기반을 두도록 유도함으로써 알고리즘 오류와 설정 미스를 줄일 수 있다.

2. 코드 스타일 및 품질 정의를 자동화 공정에 추가한다.

   AI 코드에서 특히 많이 나타나는 가독이나 명명 등의 문제를 해결하기 위해 엄격한 통합을 적용해야 한다.

   포맷터, 린터, 스타일 가이드를 코드로서의 정책으로 고정시켜서 방지할 수 있게 돤다.

3. 정확성을 위한 안전장치를 추가한다.

   모든 비정형 제어 흐름에 대해 예외 사례와 엣지 케이스를 포함한 병합 전 테스트를 요구하여 테스트를 강화하고, 유형 검사로 모듈 경계에서 null 허용 여부 및 유형 어설션으로 타입을 고정한다.

   또한, 예외를 무시하지 않도록 오류 처리 패턴을 표준화하고 처리기를 중앙 집중화시킨다.

4. 보안이나 성능에 대한 기준, 지침이 있어야한다.

   보안 기본값을 코드화하여 자격 증명 및 비밀번호 처리를 중앙집중으로 하고, 임의적인 접근 방식을 방지한다. 또한, SAST 체크와 보안 린터와 같은 분석도구로 안전하지 않은 참조나 주입 위험을 찾아야 한다.

   성능에서도 배치 I/O, 페이지네이션, 관용적인 데이터 구조 사용을 장려하여 최적화를 한다.

5. AI가 제대로 인식후 PR을 개선한것인지 체크리스트 도입하여 쓴다.

   위의 보고서에서는 이런 체크를 예시로 들었다.

   "오류 경로가 테스트되었는가?"

   "동시성 기본 요소가 올바른가?"

   "승인된 도우미를 통해 비밀번호가 처리되었는가?"

6. 제3자 도구로 2차 체크를 한다.

   AI는 본인이 생성한 코드에 대해 고치는 작업을 잘 하지 못한다. 오류를 찾고, 수정하는 절차를 해당 AI가 직접 찾게 하는 것은 신뢰도가 낮고 제대로 고쳐진다고 보기 어렵다.

   때문에 코드베이스의 맥락을 깊이 이해하는 제3자 도구를 활용하는 것이 좋다.

   이 도구들이 AI PR의 대대적인 수정 작업을 대신 수행하고 많은 문제를 잡아내는 데 도움을 줄 것이다.

이런 조치들이 AI의 개발 속도를 유지하면서도 발생할 수 있는 결함을 효과적으로 제어하는 방법이 될 것이다.

그 외에도, 다른 파일들을 같이 읽으면서 구성시켜주는 CLAUDE나, OPEN CLAW, CURSOR 등

AI도 편의성을 늘리면서도 한계점을 개선시킨 모델들이 계속해서 나오고 있다.

AI가 발전하면서 보고서에서 말한 방지책이 계속 줄어들 수 있고, 반대로 지금보다 보안 이슈가 더 크게 생길 수도 있다. 사람이 취해야하는 방지책이 보안 위주로 다시한번 바뀔 수도 있고, MS의 LIGHTBOX와 같은 격리된 공간이 개발에 필수로 자리잡을지도 모른다.

(LIGHTBOX: 호스트의 인터페이스를 최소화 함으로써 취약점(보안 공격)이 되는 부분을 줄이고, 격리된 실행 환경을 구현한 효율적인 인터페이스를 제공하면서 하위계층에 플랫폼 연결로 유연한 구성이 가능한 격리공간이다.)

https://github.com/microsoft/litebox.git