유의사항
본 글은 2026년 8월 4일 기준 공개된 논문 4편을 참고해 작성되었습니다. DANA NOTES의 분석이 함께 포함되어 있습니다.
참고 논문
Chen, J., Huang, H., Lyu, Y., An, J., Shi, J., Yang, C., Zhang, T., Tian, H., Li, Y., Li, Z., Zhou, X., Hu, X., & Lo, D. (2026). SecureVibeBench: Benchmarking secure vibe coding of AI agents via reconstructing vulnerability-introducing scenarios. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 24144–24168). Association for Computational Linguistics.
Almukhtar, M., Ghammam, A., & Ming, H. (2026). Quality and security signals in AI-generated Python refactoring pull requests. In Proceedings of the 3rd ACM International Conference on AI-Powered Software (AIware ’26). Association for Computing Machinery.
Sawada, S., Shirai, T., Kashiwa, Y., Yamaguchi, K., Iwata, H., & Iida, H. (2026). To what extent does agent-generated code require maintenance? An empirical study. In Proceedings of the 30th International Conference on Evaluation and Assessment in Software Engineering (EASE 2026). Association for Computing Machinery.
Orlanski, G., Roy, D., Yun, A., Shin, C., Gu, A., Ge, A., Adila, D., Roberts, N., Sala, F., & Albarghouthi, A. (2026). SlopCodeBench: Benchmarking how coding agents degrade over long-horizon iterative tasks [Preprint]. arXiv.
이 글에서 다루는 내용
개발자는 이미 AI와 함께 코딩하고 있다
개발자는 모든 프로그래밍 문법과 개발 방법을 외우고 일하지 않는다.
기억이 나지 않는 문법을 검색하고, 필요한 기능을 구현하는 방법을 찾아 현재 시스템에 맞게 수정한다. 오류가 발생하면 비슷한 사례를 확인하고, 여러 해결 방법 가운데 기존 시스템에 적합한 방식을 선택한다.
ChatGPT, Claude Code, GitHub Copilot, Cursor 같은 AI 도구는 이 과정에 필요한 시간을 줄여준다. 반복되는 코드를 만들고, 오류 원인을 찾고, 기능 구현의 초안을 작성하는 데 활용할 수 있다.
여러 파일을 탐색하고 직접 수정하는 AI 코딩 에이전트도 등장했다. 사람이 작업을 설명하면 에이전트가 관련 코드를 찾고, 여러 파일을 수정하고, 테스트를 실행하는 방식이다.
그러나 실제 개발에서는 AI가 만든 코드를 아무도 확인하지 않은 채 바로 운영환경에 반영하는 경우가 일반적이지 않다. 개발자가 결과를 검토하고, 기존 시스템과 맞는지 판단하고, 필요한 부분을 고친 뒤 최종적으로 병합과 배포 여부를 결정한다.
따라서 현실적인 비교 대상은 단순한 AI 대 인간이 아니다.
사람이 처음부터 직접 개발하는 방식과, AI가 초안을 만들고 사람이 검토·수정하는 방식의 비교에 가깝다.
기업이 확인해야 할 것도 AI가 사람보다 모든 면에서 우수한 코드까지 혼자 만들 수 있는지가 아니다. AI를 사용했을 때 개발팀 전체의 시간과 비용이 실제로 줄어드는지가 더 중요하다.
AI는 범위가 정해진 작업에 유리하다
AI 코딩 에이전트는 다음 조건이 명확할수록 활용하기 쉽다.
- 무엇을 만들어야 하는가
- 기존 기능 가운데 무엇을 유지해야 하는가
- 어느 파일과 시스템을 수정할 수 있는가
- 어떤 테스트를 통과해야 하는가
- 보안·성능·구조상 어떤 조건을 지켜야 하는가
이 때문에 AI 코딩은 모든 요구사항을 개발 전에 확정하고 순서대로 구현하는 워터폴 모델(Waterfall Model)과 잘 맞는 것처럼 보일 수 있다.
하지만 프로젝트 전체가 반드시 워터폴 방식이어야 한다는 뜻은 아니다. 애자일 개발에서도 하나의 작업 단위에 요구사항과 완료 기준이 명확하게 정의돼 있다면 AI를 활용할 수 있다.
정확히 말하면 AI는 워터폴 모델에 특화됐다기보다, 현재 수행할 작업의 범위와 평가 기준이 일정 기간 고정돼 있을 때 사용하기 쉽다.
문제는 실제 개발에서 이 조건이 오래 유지되지 않는다는 데 있다.
명확한 과제에서도 기능과 보안을 함께 만족하기는 어려웠다
Chen et al. (2026)은 실제 오픈소스 프로젝트에서 인간 개발자가 취약점을 도입했던 사례를 바탕으로 SecureVibeBench를 구성했다.
연구진은 41개 프로젝트에서 105개의 C/C++ 보안 코딩 과제를 만들었다. 짧은 함수 하나를 완성하는 문제가 아니라, 평균 약 2,845개의 파일과 55만 줄 이상의 코드로 구성된 저장소에서 관련 위치를 찾고 여러 파일을 수정해야 하는 과제였다.
평가에서는 요구한 기능이 작동하는지만 확인하지 않았다. 기존 취약점이 다시 들어갔는지, 에이전트가 새로운 보안 위험을 추가했는지도 함께 검사했다.
그 결과 가장 좋은 에이전트와 언어모델 조합도 **기능적으로 정확하면서 보안상 안전한 해결책을 만든 비율이 23.8%**에 그쳤다(Chen et al., 2026).
다만 이 수치는 사람이 AI 결과를 검토하고 수정한 뒤의 최종 성공률이 아니다. 에이전트가 독립적으로 과제를 수행한 결과이며, C/C++의 메모리 안전성 과제에 한정돼 다른 개발환경에 그대로 적용할 수도 없다.
이 연구가 보여주는 핵심은 AI 코딩이 쓸모없다는 것이 아니다.
요구사항과 테스트가 명확하게 주어져도, 기능이 작동하는 코드와 안전한 코드는 서로 다를 수 있다는 점이다.
실제 프로젝트에서는 AI 코드가 상당수 병합됐다
Almukhtar et al. (2026)은 실제 GitHub 프로젝트에서 AI 에이전트가 만든 Python 리팩터링 Pull Request를 분석했다.
리팩터링(Refactoring)은 프로그램의 외부 기능은 유지하면서 코드의 구조와 가독성, 유지보수성을 개선하는 작업이다. Pull Request(PR)는 수정한 코드를 기존 프로젝트에 반영해 달라고 요청하고 다른 개발자가 이를 검토하는 절차다.
연구진이 분석한 438개의 AI 리팩터링 PR 가운데 73.5%인 322개가 병합됐다. AI가 만든 코드가 실험에만 머무르지 않고 실제 개발 과정에서 받아들여지고 있다는 의미다.
그러나 품질 결과는 한 방향으로만 나타나지 않았다.
다섯 가지 품질 속성 가운데 평균적으로 개선이 확인된 비율은 22.5%였다. 사용성은 36.5%에서 개선됐지만, 유지보수성은 14.9%, 모듈성은 9.5%에서만 개선됐다.
수정된 파일의 24.17%에서는 새로운 Pylint 문제가 발생했고, 4.7%에서는 새로운 Bandit 보안 경고가 생겼다. 다만 상당수 Pylint 문제는 긴 코드 줄이나 문서 부족처럼 작성 규칙과 관련된 것이었고, Bandit 결과도 심각한 취약점보다는 위험할 가능성이 있는 코딩 방식에 대한 경고가 중심이었다.
일부 PR은 새로운 경고를 만들면서 기존 경고를 함께 제거하기도 했다(Almukhtar et al., 2026).
따라서 병합률은 코드 품질 점수와 같지 않다.
병합되지 않은 PR에도 중복 작업이나 프로젝트 방향 변경 같은 이유가 있을 수 있다. 반대로 병합된 코드도 장기적인 유지보수성과 운영 효율까지 검증됐다는 뜻은 아니다.
작동하는 코드와 좋은 코드는 같은 말이 아니다
같은 결과를 보여주는 코드도 운영비용은 다를 수 있다.
예를 들어 A와 B 데이터를 화면을 열 때마다 결합할 수도 있고, 자주 사용하는 결과를 C값으로 미리 저장해 C만 읽도록 만들 수도 있다.
첫 번째 방식은 저장공간을 적게 사용하지만 조회 때마다 계산이 필요하다. 두 번째 방식은 데이터가 조금 늘어나는 대신 조회속도와 코드 구조를 개선할 수 있다. 대신 A나 B가 변경될 때 C도 정확하게 갱신해야 한다.
두 방식 모두 기능 테스트는 통과할 수 있다.
그러나 어느 방식이 더 적절한지는 데이터의 조회·변경 빈도, 저장비용, 처리속도와 데이터 일관성 요구에 따라 달라진다.
AI가 기능을 구현하는 능력과, 실제 운영조건을 고려해 적절한 구조를 선택하는 능력은 같은 것이 아니다.
이러한 차이는 코드 검수 단계에서 바로 드러나지 않을 수도 있다. 사용자와 데이터가 늘어난 뒤에야 처리속도나 컴퓨터 자원 사용량의 문제가 확인되는 경우도 있다.
실제 요구사항은 개발 전에 완성되지 않는다
소프트웨어 개발은 완성된 요구사항을 코드로 옮기는 작업처럼 설명되곤 한다.
그러나 실제로는 사용자와 현업 담당자도 처음부터 자신이 무엇을 필요로 하는지 정확히 알지 못하는 경우가 많다. 화면과 초기 기능을 확인한 뒤에야 필요한 기능과 불필요한 기능을 구분하기도 한다.
개발 과정에서는 새로운 기능이 추가되고, 기존 기능이 삭제되며, 업무 처리 순서와 권한 기준이 바뀐다. 다른 시스템과의 연동이나 새로운 예외 상황도 뒤늦게 발견될 수 있다.
개발이 거의 끝난 시점에 요구사항이 달라지는 경우도 있다. 내부 직원만 사용할 예정이던 기능이 외부 고객에게 제공되거나, 한 조직용 시스템이 여러 조직을 지원해야 하는 구조로 바뀔 수 있다.
따라서 실제 개발은 정해진 요구사항을 구현하는 과정인 동시에, 요구사항 자체를 발견하고 조정하는 과정이다.
개발자는 사용자가 말한 내용을 그대로 코드로 바꾸기만 하지 않는다. 서로 충돌하는 요구를 조정하고, 구현비용을 설명하며, 현재 기능을 위해 시스템 전체 구조를 변경하는 것이 적절한지도 판단한다.
AI는 명확하게 주어진 요구사항을 빠르게 구현할 수 있다. 그러나 요구사항이 달라졌을 때 앞서 내린 설계 결정을 다시 검토하는 일은 단순한 코드 생성보다 어렵다.
AI가 만든 코드도 병합 이후 계속 수정됐다
Sawada et al. (2026)은 100개의 GitHub 저장소에서 AI가 생성한 파일 508개와 같은 저장소의 인간 작성 파일 508개를 비교했다.
연구진은 파일 생성 이후 최소 6개월 동안 발생한 3,238개의 후속 커밋을 분석했다. AI 생성 파일은 인간 작성 파일보다 수정 빈도가 낮았고, 한 번에 변경되는 코드의 비율도 더 작았다.
따라서 이 연구에서는 AI 생성 코드가 인간 작성 코드보다 즉각적으로 더 큰 유지보수 부담을 만든다는 결과는 나타나지 않았다.
그러나 수정의 성격에서는 차이가 있었다.
AI 생성 파일의 후속 변경 가운데 가장 많은 유형은 **기능 추가로 21.78%**였다. 버그 수정은 11.73%였다. 반면 인간 작성 파일에서는 버그 수정이 16.76%로 가장 높은 비중을 차지했다.
AI 생성 파일에 발생한 1,543개의 후속 커밋 가운데 83.21%는 인간 개발자가 작성했고, AI 에이전트가 작성한 비율은 16.79%였다(Sawada et al., 2026).
다만 사람이 수정의 대부분을 담당했다는 사실만으로 AI가 요구사항 변경에 실패했다고 단정할 수는 없다. 연구는 수정 주체는 확인했지만, 사람이 후속 작업을 맡은 이유까지 조사하지 않았다.
연구에서 직접 확인된 것은 AI가 생성한 코드도 병합 이후 계속 수정되고 확장됐으며, 현재 그 작업의 대부분을 사람이 수행했다는 점이다.
반복되는 요구사항은 초기 설계의 비용을 드러낸다
일반적인 AI 코딩 평가는 완성된 요구사항을 한 번에 주고 결과를 확인한다.
그러나 실제 개발에서는 처음 만든 코드 위에 새로운 기능이 계속 추가된다. 이때 중요한 것은 현재 테스트를 통과했는지만이 아니다. 에이전트가 자신이 앞에서 만든 구조를 얼마나 안정적으로 확장할 수 있는지도 확인해야 한다.
Orlanski et al. (2026)은 이를 평가하기 위해 SlopCodeBench를 만들었다.
이 벤치마크는 36개의 문제를 196개의 단계로 나눴다. 에이전트는 첫 번째 요구사항에 따라 코드를 만들고, 새로운 요구사항이 추가될 때마다 자신이 앞에서 만든 코드를 계속 수정했다.
예를 들어 처음에는 Python 파일만 검색하는 프로그램을 만들게 한 뒤 다른 프로그래밍 언어와 새로운 검색 기능을 단계적으로 추가했다. 초기에 특정 언어만을 전제로 구조를 만들었다면 이후 기능을 추가할 때 비슷한 코드를 반복하거나 기존 구조를 크게 바꿔야 한다.
연구 결과 어떤 에이전트도 36개 문제 가운데 하나를 모든 단계에 걸쳐 완전히 해결하지 못했다. 가장 높은 엄격 기준 통과율도 전체 단계의 14.8%였다.
반복 개발 과정에서 복잡한 처리가 일부 함수에 집중되는 현상은 전체 작업 경로의 77%에서 증가했고, 중복되거나 불필요하게 긴 코드는 75.5%에서 증가했다.
473개의 실제 Python 오픈소스 저장소와 비교했을 때 에이전트 코드는 평균적으로 2.3배 더 장황했고, 구조적 복잡성의 집중도는 2배 높았다(Orlanski et al., 2026).
이 연구는 아직 프리프린트이며 구성된 Python 평가환경을 사용했다. 따라서 수치를 실제 기업 프로젝트에 그대로 적용하기보다, 반복적인 기능 추가에서 초기 설계의 문제가 누적될 수 있다는 근거로 보는 것이 적절하다.
오늘의 요구사항을 만족하는 코드와 내일의 요구사항을 쉽게 받아들일 수 있는 코드는 다르다.
작업 중인 AI를 멈추고 새 요구사항을 말하면 해결될까
요구사항이 바뀌면 에이전트의 작업을 중지하고 새로운 지시를 입력할 수 있다.
버튼 문구 변경이나 응답 항목 추가처럼 범위가 작은 작업이라면 새 요구를 반영하는 것이 어렵지 않을 수 있다.
하지만 에이전트가 이미 데이터 구조와 API, 테스트를 함께 수정하고 있다면 상황은 달라진다.
새 요구사항이 기존 설계와 충돌할 경우 다음을 다시 판단해야 한다.
- 지금까지 한 변경 가운데 무엇을 유지할 것인가
- 어떤 변경을 되돌릴 것인가
- 수정이 끝난 파일과 중간 상태인 파일을 어떻게 맞출 것인가
- 기존 테스트 가운데 무엇이 더 이상 유효하지 않은가
- 사람이 동시에 수정한 코드와 어떻게 합칠 것인가
이 문제는 단순히 중지 버튼이 있는가로 해결되지 않는다.
진행 중인 작업 상태를 이해하고, 앞서 내린 결정 가운데 필요한 부분만 되돌린 뒤, 바뀐 목표에 맞춰 다시 계획할 수 있어야 한다.
현재 AI 코딩 에이전트는 정해진 작업을 독립적으로 수행하는 능력은 빠르게 발전하고 있다. 그러나 사람과 같은 코드에서 동시에 일하면서 수시로 바뀌는 요구사항과 설계 의도를 공유하는 협업은 아직 자연스럽지 않다.
DANA NOTES 해설
AI 코딩 에이전트의 현재 가치는 개발자를 완전히 대신하는 데 있지 않다.
문법 검색, 반복 구현, 테스트 초안과 범위가 명확한 작업을 빠르게 처리해 개발자의 시간을 줄이는 데 있다.
실제 연구에서도 AI 생성 파일이 인간 작성 파일보다 더 자주 수정된다는 결과는 나타나지 않았고, AI가 만든 리팩터링 PR 상당수는 실제 프로젝트에 병합됐다. 따라서 AI 코딩을 단순히 품질이 낮거나 위험한 방식으로만 설명하는 것은 현실과 맞지 않는다.
그러나 소프트웨어 개발은 첫 번째 코드를 완성하는 것으로 끝나지 않는다. 요구사항은 계속 바뀌고, 기존 코드는 수정·확장되며, 실제 데이터와 사용량이 늘어난 뒤에야 성능과 구조의 문제가 드러나기도 한다.
따라서 기업은 생성된 코드 줄 수나 PR 병합률만으로 AI 코딩의 성과를 평가해서는 안 된다. 다음 요소를 함께 확인해야 한다.
- AI 결과를 검토하고 수정하는 데 걸린 시간
- 요구사항 변경 이후 발생한 재작업과 오류
- 병합 이후의 기능 확장·버그 수정·구조 개선 비용
- 실제 운영환경의 응답속도, 자원 사용량과 장애율
AI에는 반복 코드나 작은 기능처럼 범위가 명확한 작업을 맡기고, 데이터 구조·권한·성능·시스템 구조처럼 전체에 영향을 주는 결정에는 사람이 처음부터 참여해야 한다.
앞으로는 AI 단독 성공률보다 사람과 AI가 함께 개발했을 때의 전체 작업시간, 반복적인 요구사항 변경 이후의 코드 품질, 그리고 기업 시스템에서 장기간 운영한 결과를 확인할 필요가 있다.
AI 코딩의 생산성은 코드를 처음 만드는 속도가 아니라, 개발·검토·변경·운영까지 포함한 전체 비용으로 평가해야 한다.
