리뷰 대기열에 올라온 코드 1개를 통과시키는 일은 예전보다 빨라졌다. 문제는 그다음이다. 정적 스캐너가 2,315개 코드 스니펫을 훑어 48개 파일에서 56개 취약점을 찾아낸 연구가 있었고, 다른 종합 논문은 정확성·보안·유지보수성 결과가 연구마다 엇갈린다고 적었다. AI 코딩 도구의 쟁점은 이제 “빨라졌나”보다 “어떤 조건에서 품질이 흔들리나”에 가깝다.

세 줄 요약

• 핵심 이슈는 AI 생성 코드의 품질을 단일 지표로 정리하기 어렵다는 점이다. 정확성뿐 아니라 보안, 유지보수성, 복잡도를 함께 봐야 한다.
• 이 문제가 중요한 이유는 생산성 이득이 있더라도 작업 유형과 프롬프트 조건에 따라 품질 편차가 커질 수 있고, 실제 워크플로에 바로 적용하기에는 근거가 아직 제한적이기 때문이다.
• 독자는 AI 코드 도구를 도입할 때 “속도”보다 “작업별 허용 리스크”를 먼저 정하고, 정적 분석·수동 리뷰·유지보수성 지표를 함께 검증해야 한다.

현황

이번에 다루는 논문은 Factors Influencing the Quality of AI-Generated Code: A Synthesis of Empirical Evidence다. arXiv에 공개된 초록에 따르면, 이 연구는 LLM 기반 코드 생성 도구의 확산과 함께 품질, 신뢰성, 보안에 대한 우려가 학계와 산업계에서 커지고 있다는 문제의식에서 출발한다. 목적도 분명하다. 기존 경험 연구를 체계적으로 묶어, 무엇이 AI 생성 코드 품질에 영향을 주는지 정리하려는 시도다.

여기서 중요한 점은 “가장 큰 요인 하나”를 성급하게 고르지 않는 태도다. 조사 결과를 보면, 기존 연구들은 프롬프트와 작업 유형의 영향이 크다는 쪽으로 모인다. 다만 질문에 나온 네 범주, 즉 프롬프트·모델 특성·개발자 숙련도·작업 유형 가운데 무엇이 최우선 단일 요인인지까지 종합 논문이 직접 서열화한 문구는 확인되지 않았다. 따라서 프롬프트와 작업 유형이 두드러진다고는 말할 수 있지만, “이것 하나가 전부”라고 단정하기는 어렵다.

작업 유형 차이는 직접적으로 드러난다. GitHub 이슈를 다룬 실증 연구는 ChatGPT가 코드 생성과 구현 같은 과업에서는 더 잘 작동하지만, 코드 설명이나 소프트웨어 공학 정보 탐색에서는 어려움을 겪는다고 적었다. 즉, 같은 도구라도 무엇을 시키는지에 따라 결과가 달라진다. 현업에서는 이 차이가 크다. 보일러플레이트 생성과 레거시 시스템 해설을 같은 기대치로 평가하면 판단이 어긋날 수 있다.

품질 측정 방식도 넓다. 보안은 정적 스캐너와 수동 점검을 함께 써서 취약점 수, 취약 파일 수, CWE나 OWASP 기준 위반 여부를 세는 식으로 정량화했다. 실제로 한 연구는 2,315개 C·C++·C# 스니펫을 분석해 48개 파일에서 56개 취약점을 확인했다. 유지보수성은 SonarQube나 Code Climate 같은 도구로 순환복잡도, 코드 중복, 코드 스멜 같은 정적 품질 지표를 보는 방식이 검색 결과에서 확인된다. 다시 말해 코드가 돌아간다는 사실만으로는 품질을 판단하기 어렵다.

분석

의사결정 관점에서 이 논문의 가치는 분명하다. AI 코딩 도구를 “생산성 제품”만이 아니라 “리스크 관리 대상”으로 보게 만든다. 팀이 짧은 구현 과업, 반복적 패턴, 명확한 입출력 명세에 AI를 붙인다면 이득을 얻을 가능성이 있다. 반대로 작업이 설명 중심이거나, 맥락이 길고, 보안 요구가 높거나, 레거시 제약이 많은 환경이라면 같은 도구가 부채를 늘릴 수 있다. 이때 핵심 변수는 모델 이름보다 과업 구조와 프롬프트 설계다.

한계도 분명하다. 검색된 근거를 보면 보안 연구는 통제된 환경에 치우친 경우가 많았고, 실제 소프트웨어 엔지니어링 워크플로에서의 통합 효과를 다룬 실증 연구는 아직 적다. 종합 논문 발췌에도 정확성, 보안, 유지보수성, 복잡도 결과가 연구마다 가변적이라고 적혀 있다. 따라서 “한 번의 파일럿에서 잘 됐으니 전사 도입” 같은 결정은 위험할 수 있다. 오픈소스 저장소, 기업 내부 저장소, 규제 산업, 대규모 레거시 환경은 서로 조건이 다르다.

실전 적용

그래서 현업 팀의 질문도 바뀌어야 한다. “이 도구가 코드를 잘 쓰나?”보다 “우리 팀의 어떤 작업에서, 어떤 검증 비용을 감수할 때, 사람 대비 순이익이 나나?”를 물어야 한다. 예를 들어 테스트 코드 초안, 단순 CRUD 구현, API 연결 코드처럼 산출물 검증이 쉬운 작업은 도입 후보가 될 수 있다. 반면 인증 로직, 권한 처리, 암호화, 결제, 개인정보 처리처럼 결함 비용이 큰 영역은 생성보다 보조 역할로 한정하는 편이 낫다.

평가 체계도 3층으로 나누는 편이 현실적이다. 1층은 기능 정확성이다. 코드가 돌아가고 테스트를 통과하는지 본다. 2층은 보안이다. 정적 분석과 수동 리뷰를 함께 붙인다. 3층은 유지보수성이다. 복잡도, 중복, 스멜을 따로 본다. 이 세 층 중 하나라도 빠지면 AI 코드는 “빨리 나온 문제”가 될 수 있다.

오늘 바로 할 일 체크리스트 3개

• 팀의 AI 사용 과업을 “반복 구현”, “설명·분석”, “보안 민감”으로 나눠 작업 유형별 허용 기준을 먼저 적어라.
• AI가 만든 코드에는 테스트 통과 여부와 별개로 정적 보안 스캔과 사람 리뷰를 묶어 기본 게이트로 걸어라.
• 복잡도·중복·코드 스멜 지표를 기존 PR 템플릿에 추가해 기능 정확성과 유지보수성을 분리해 기록하라.

FAQ

Q. AI 생성 코드 품질은 결국 프롬프트가 제일 중요한가요?
프롬프트 영향이 크다는 근거는 있습니다. 다만 확인된 범위에서는 프롬프트가 다른 모든 요인보다 항상 가장 중요하다고 단정할 근거는 없습니다. 작업 유형의 영향도 함께 크게 나타납니다.

Q. 테스트만 통과하면 실무에 써도 되나요?
그렇지 않습니다. 테스트 통과는 기능 정확성의 일부일 뿐입니다. 보안 취약점과 유지보수성 문제는 별도 점검이 필요합니다. 정적 분석기와 수동 검토를 함께 쓰는 방식이 연구들에서 확인됩니다.

Q. 기업 개발 워크플로에도 연구 결과를 바로 적용할 수 있나요?
제한적으로 보셔야 합니다. 확인된 근거에 따르면 통제된 환경 연구가 적지 않고, 실제 워크플로 통합을 다룬 실증 연구는 아직 많지 않습니다. 따라서 팀별 파일럿과 작업별 검증 기준이 먼저 필요합니다.

결론

AI 코드 생성의 핵심 변수는 속도보다 조건이다. 어떤 작업에 쓰는지, 어떤 프롬프트를 주는지, 그리고 정확성·보안·유지보수성을 어떻게 따로 검증하는지가 품질에 영향을 준다. 다음으로 볼 지점도 분명하다. 팀이 AI를 어디에 붙일지보다, 어디에는 아직 붙이지 말아야 할지를 먼저 정해야 한다.

다음으로 읽기

• AI 자료 모음 (24h) - 2026-03-27
• 다회전 대화와 유해 조작 평가
• AI 인터뷰 1250명의 의미
• 확률형 AI의 진짜 병목
• 단일 정답을 넘는 후학습

참고 자료

• What characteristics make ChatGPT effective for software issue resolution? An empirical study of task, project, and conversational signals in GitHub issues - link.springer.com
• Secure coding with AI – from detection to repair - link.springer.com
• When LLMs meet cybersecurity: a systematic literature review - link.springer.com
• Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study - arxiv.org
• Assessing Small Language Models for Code Generation: An Empirical Study with Benchmarks - sciencedirect.com
• arxiv.org - arxiv.org