AI로 작성한 코드, 정말 안전할까? AI 생성 코드의 문제점과 실무 대응 전략

나는 아직도 처음으로 “이건 누가 봐도 AI가 쓴 코드네”라고 느꼈던 pull request를 또렷하게 기억한다.

야근하던 밤이었다. 사무실 조명은 미묘하게 윙윙거렸고, 식어버린 커피에서는 씁쓸한 냄새만 남아 있었다. PR은 컸다. 복잡해서가 아니라, 그냥 불필요하게 컸다. 파일은 여기저기 흩어져 있었고, 비슷한 함수들이 반복해서 등장했다. 마치 불안한 사람이 같은 말을 되풀이하듯.

핵심 로직 하나를 짚어 “이 부분은 왜 이렇게 짰나요?”라고 물었을 때, 상대는 잠시 말을 잇지 못했다.

“솔직히… model이 그렇게 하라길래요.”

그 순간이 계속 머릿속에 남았다. 왜냐하면 2025년의 software 개발 현장에서 벌어지는 많은 문제를, 그 한 문장이 너무 정확하게 설명하고 있었기 때문이다.

 

 

---

바쁜 사람을 위한 한 줄 요약

AI-generated code는 분명히 개발 속도를 올려준다. 하지만 그 대가로 security vulnerability, 비대해진 pull request, 취약한 logic, 그리고 ‘우리가 더 빨라졌다는 착각’을 함께 가져온다. 진짜 위험은 AI가 아니라, 생각하는 일까지 AI에게 맡겨버리는 순간에 시작된다.

이 문장은 꼭 기억해두고 싶다.

 

Code review를 건너뛰는 건 일을 없애는 게 아니라, 나중으로 미루는 것뿐이다.

 

이제 조금 천천히, 왜 이게 중요한지 이야기해보자.

 

 

---

AI coding, 이미 되돌릴 수 없는 흐름

2025년 초는 분기점처럼 느껴졌다.

예전에는 AI coding assistant를 대놓고 무시하던 senior developer들조차, 어느 순간부터 조용히 쓰기 시작했고, 곧 자연스럽게 일상 도구로 받아들이게 됐다. 실제로 cloud provider 설문을 보면, 경력 10년 이상의 개발자 중 32%가 이미 AI-generated code를 production에 deploy한 경험이 있다고 한다.

이 숫자가 의미하는 건 단순한 유행이 아니다.

AI-assisted coding은 이제 선택지가 아니라, Git이나 CI처럼 ‘기본 인프라’가 되어가고 있다. 피할 수 없는 흐름이라면, 이제 남은 질문은 하나다.

 

어떻게 하면 덜 위험하게 쓸 수 있을까?

 

 

---

 

불편하지만 외면하기 힘든 진실

 

불편하지만 외면하기 힘든 진실

여기서부터는 솔직해져야 한다.

한 security report에 따르면 AI-generated code의 약 45%가 기본적인 security test를 통과하지 못했다. 거의 절반이다. 그리고 문제는 사소하지 않다. SQL injection, XSS, broken access control 같은 OWASP Top 10 항목들이 그대로 포함돼 있었다.

이건 ‘조금 아쉽다’ 수준이 아니다.

더 놀라운 건, model이 좋아져도 결과는 크게 달라지지 않았다는 점이다. 최신 model을 써도, 비슷한 유형의 취약점은 반복됐다.

그리고 security만의 문제가 아니다.

 

 

---

AI code, bug는 오히려 더 많았다

470개의 open-source GitHub pull request를 분석한 결과는 꽤 직설적이다.

• 전체 issue 수: 1.7배 증가
• critical issue: 1.4배 증가
• major issue: 1.7배 증가
• minor issue: 거의 2배

 

“AI면 실수가 줄어들어야 하는 거 아닌가요?”라는 생각이 든다면, 아주 자연스럽다. 문제는 AI가 ‘틀리지 않는 존재’가 아니라는 데 있다.

AI는 피곤하지 않지만, context를 이해하지도 못한다.

 

 

---

AI-generated code가 자주 무너지는 네 가지 지점

패턴은 분명하다. 문제는 대체로 네 영역에서 반복된다.

 

1. Logic & Correctness

은근히 가장 위험하다.

dependency 순서가 틀리거나, config가 잘못되거나, 실행 흐름이 미묘하게 어긋난다. 특히 AI는 outdated library나 deprecated pattern을 기준으로 코드를 생성하는 경우가 많다.

마치 몇 년 전 지도만 들고 길을 안내하는 navigation 같다.

 

2. Code Quality & Maintainability

코드를 읽다 보면 느낌이 온다.

이름은 애매하고, formatting은 들쭉날쭉하고, 비슷한 로직이 여기저기 복붙돼 있다. AI는 DRY 원칙보다 “일단 돌아가게 만드는 가장 빠른 길”을 택하는 경향이 있다.

결과는? technical debt.

 

3. Security

password handling, injection, unsafe deserialization.

교과서에 나오는 취약점들이 여전히 등장한다. 대부분은 AI 때문이 아니라, 사람이 제대로 안 본 탓이다.

 

4. Performance

불필요한 loop, 중복 호출, 비효율적인 query.

돌아가긴 하지만, 성능은 한참 아쉽다. 기어가 2단에 고정된 차처럼.

 

 

---

진짜 원인은 AI가 아니다

조금 불편한 이야기다.

문제의 핵심은 model이 아니라 사람의 태도다.

• AI가 뭘 할 수 있는지 과대평가하고
• 우리가 무엇을 책임져야 하는지는 과소평가한다

 

AI는 코드를 써줄 수는 있지만, architecture나 business context, edge case까지 이해하지는 못한다. 생각을 넘기는 순간, 통제력은 빠르게 사라진다.

AI는 똑똑하지만 위험한 junior engineer 정도로 대해야 한다. 빠르지만, 혼자 production을 맡기면 안 되는.

 

 

---

커져버린 PR의 함정

AI는 코드를 너무 쉽게 만든다.

그 결과, AI-generated PR은 평균적으로 18% 더 크다. 파일도 많고, 변경점도 넓다. 리뷰어 입장에서는 지친다.

큰 PR은 빨라 보이지만, 실제로는 review quality를 떨어뜨린다. 결국 QA 비용으로 돌아온다.

불 켜지 않은 채 속도를 올리는 것과 비슷하다.

 

 

---

그래서 code review는 더 중요해졌다

내가 요즘 고집처럼 말하는 기준이 있다.

 

본인이 설명 못 하는 코드는 merge하지 말자.

 

 

AI가 썼든, 사람이 썼든 마찬가지다.

author가 코드를 이해하지 못하면, 팀의 신뢰와 knowledge sharing은 무너진다. 한 Google engineer의 말이 딱 맞다.

 

“Review를 생략하는 건 일을 없애는 게 아니라, 연기하는 것이다.”

 

AI 시대에는 이 말이 더 무겁게 들린다. 책임은 언제나 사람에게 돌아오기 때문이다.

 

 

---

AI code review tool, 어디까지 믿어야 할까

아이러니하게도, AI는 code review에서는 꽤 잘한다.

pattern detection, formatting, 구조적인 문제를 빠르게 잡아낸다. 하지만 여기서 많은 팀이 실수한다.

AI review를 최종 승인자처럼 쓰는 것이다.

이건 spell checker를 editor-in-chief로 쓰는 것과 같다.

 

 

---

현실적인 활용 방식

가장 건강한 흐름은 이렇다.

1. 개발자가 code 작성 (AI 도움 가능)
2. local 환경에서 AI review로 1차 정리
3. author가 모든 변경을 이해하고 수정
4. GitHub PR 생성
5. 사람이 logic, intent, architecture를 review

 

AI는 앞단에서 귀찮은 일을 처리하고, 판단은 사람이 한다.

 

 

---

Customization은 힘이지만, 책임도 따른다

AI review tool은 팀의 coding style, naming, rule을 학습할 수 있다. 강력하다.

하지만 rule이 잘못되면, 잘못된 방향으로도 빠르게 확산된다. guardrail은 결국 사람이 설계해야 한다.

 

 

---

결론: AI를 쓰지 말자는 이야기는 아니다

써야 한다.

다만, 눈을 뜨고 써야 한다.

AI는 생산성을 증폭시키는 도구이지, 안전망은 아니다. 좋은 습관도, 나쁜 습관도 함께 증폭시킨다.

목표는 ‘더 빨리 코드 짜기’가 아니라,

우리가 이해하고 책임질 수 있는 software를 만드는 것이다.

 

 

---

마지막으로 남는 질문

늦은 밤, 거대한 PR 앞에서 AI가 “이건 잘 동작합니다”라고 말할 때, 잠깐 멈춰보자.

• 나는 이걸 이해하고 있는가?
• 내일 누군가에게 설명할 수 있는가?
• 사람이 썼어도 신뢰했을까?

 

incident report에 서명하는 건 model이 아니다.

우리다.

 

 

---

2026년, 개발자들이 진짜로 묻는 질문들

AI-generated code는 원래 insecure한가요?
아니다. 다만 review 없이는 위험해질 확률이 높다.

왜 bug가 더 많을까요?
context를 모르고 과거 패턴에 의존하기 때문이다.

junior developer는 AI를 써도 될까요?
오히려 더 적극적으로, 대신 review는 더 강하게.

AI가 code reviewer를 대체할 수 있나요?
아직은 불가능하다.

큰 PR이 정말 문제인가요?
리뷰 품질을 떨어뜨린다.

속도와 안전을 동시에 잡을 수 있을까요?
AI는 앞단, 사람은 마지막에.

가장 흔한 실수는?
confidence를 correctness로 착각하는 것.

앞으로 더 나아질까요?
model은 좋아진다. 하지만 discipline이 더 중요하다.

채용 기준도 바뀔까요?
output보다 이해력과 설명 능력이 중요해질 것이다.

AI 시대에 가장 중요한 개발자 역량은?
자기 코드에 대해 말할 수 있는 능력.