AI가 짠 코드, 정말 믿어도 될까? 3개월 사용기와 보안 함정

AI가 생성한 코드를 검토하는 개발자의 작업 환경은 생산성 향상과 동시에 새로운 보안 과제를 안겨줍니다.

요즘 개발자 커뮤니티나 유튜브를 보면 AI 코딩 도구 없이 일하는 사람을 찾기가 더 어려울 정도예요. 저 역시 뒤늦게나마 깃허브 코파일럿과 커서 같은 도구들을 실무에 도입했고, 어느덧 3개월 정도 꾸준히 사용해봤습니다. 처음에는 그저 신기했어요. 주석만 적어도 함수가 뚝딱 완성되고, 반복적인 CRUD 코드는 탭 키 한 번이면 끝나니까요.

그런데 시간이 지나면서 약간의 불편함과 의심이 생기기 시작했습니다. ‘이 코드가 정말 안전한 걸까?’, ‘내가 모르는 라이브러리를 왜 임포트한 거지?’ 같은 생각이 들더라고요. 특히 보안과 직결된 인증 로직이나 데이터베이스 쿼리 부분에서 AI가 제안한 코드를 그대로 받아들였다가 큰일 날 뻔한 순간도 있었습니다.

이 글은 그 3개월 동안의 솔직한 경험담이에요. AI가 가져다준 놀라운 생산성 향상 뒤에 숨은 보안 함정과, 실제로 제가 어떻게 문제를 발견했는지, 그리고 지금은 어떤 방식으로 AI와 안전하게 협업하고 있는지를 담아보려고 합니다. 코드 리뷰 문화가 약한 소규모 팀이나 사이드 프로젝트를 혼자 하는 분들이라면 더더욱 공감하실 내용이 될 거예요.

생산성은 확실히 올라갔어요

부정적인 이야기부터 꺼내면 AI 도구가 마치 무쓸모한 것처럼 느껴질 수 있으니, 좋았던 점을 먼저 말씀드리는 게 순서일 것 같아요. 결론부터 말하면 생산성 향상은 체감이 확실히 됩니다. 특히 프론트엔드 작업에서 반복되는 컴포넌트를 만들거나, API 응답을 처리하는 타입 정의를 작성할 때는 거의 마법 같았어요.

예를 들어 React로 관리자 대시보드를 만들 때였어요. 테이블 컴포넌트에 정렬, 필터링, 페이지네이션을 붙이는 작업은 누구나 지루하게 느끼는 부분이잖아요. 그런데 코파일럿에게 ‘사용자 목록을 보여주는 테이블 컴포넌트를 만들고, 이름과 가입일 기준으로 정렬 기능을 추가해줘’라고 주석을 적으니, 30줄이 넘는 코드가 순식간에 생성됐습니다. 탭 키만 몇 번 누르니 기본 틀이 완성되더라고요.

백엔드에서도 마찬가지였어요. Node.js로 간단한 REST API를 만들 때, 컨트롤러-서비스-레포지토리 패턴을 반복해서 타이핑하는 건 정말 피곤한 일이에요. 그런데 AI 도구는 앞서 작성한 패턴을 학습해서 다음 엔드포인트의 코드를 거의 정확하게 예측해줬어요. 변수명만 살짝 바꾸면 될 정도로 말이죠. 체감상 이런 반복 작업은 도입 전보다 40%에서 50% 정도 시간을 아낄 수 있었습니다.

다만 여기서 중요한 건 ‘반복 작업’에 한정된다는 점이에요. 비즈니스 로직이 복잡하게 얽히거나 특정 도메인 지식이 필요한 코드는 여전히 사람이 처음부터 끝까지 설계해야 했습니다. AI가 제안한 코드가 완전히 틀린 방향으로 가는 경우도 꽤 있었거든요.

겉으로 보기엔 멀쩡한 코드의 함정

AI가 생성한 코드의 가장 큰 특징은 문법적으로는 거의 완벽하다는 점이에요. 세미콜론 하나 빠지지 않고, 들여쓰기도 깔끔하고, 최신 문법도 잘 반영되어 있어요. 그래서 얼핏 보면 아주 훌륭한 코드처럼 느껴집니다. 문제는 그 ‘얼핏 보면’이라는 데에 있어요.

제가 직접 경험한 사례를 하나 들려드릴게요. 사용자 로그인 기능을 구현하면서 비밀번호 해싱 부분을 AI에게 맡겼습니다. 코파일럿이 제안한 코드는 bcrypt를 사용해서 아주 그럴듯해 보였어요. 그런데 자세히 들여다보니 솔트 라운드가 5로 설정되어 있더라고요. 보안 가이드라인에서는 최소 10 이상, 보통 12를 권장하는데 말이죠. AI는 그냥 인터넷에 떠도는 오래된 예제 코드를 학습해서 그대로 내놓은 거였어요.

또 한 번은 파일 업로드 기능을 만들 때였어요. AI가 제안한 코드는 업로드된 파일의 확장자를 검사하는 로직이 포함되어 있었는데, 단순히 파일명의 마지막 문자열만 확인하는 방식이었습니다. 이건 보안에서 아주 기초적인 실수예요. 공격자가 ‘shell.php.jpg’ 같은 이중 확장자나 MIME 타입 조작을 통해 얼마든지 우회할 수 있거든요.

이런 사례들을 겪으면서 깨달은 건, AI는 ‘보안 컨텍스트’를 이해하지 못한다는 사실이에요. 단지 확률적으로 가장 그럴듯한 토큰을 이어 붙일 뿐, 그 코드가 실제 운영 환경에서 어떤 보안 위협을 초래할지 전혀 고려하지 않습니다.

보안 취약점은 어떻게 발견했나

3개월 동안 AI와 협업하면서 보안 문제를 발견한 건 크게 세 가지 경로였어요. 첫 번째는 정적 분석 도구였고, 두 번째는 동료 개발자의 코드 리뷰, 세 번째는 순전히 제 경험과 직감이었습니다.

정적 분석 도구는 정말 큰 도움이 됐어요. 소나큐브나 시큐어 코드 워리어 같은 도구를 CI/CD 파이프라인에 연동해두니, AI가 생성한 코드에서 SQL 인젝션 가능성이 있는 쿼리나 XSS에 취약한 출력 패턴이 바로 잡히더라고요. 특히 사용자 입력을 그대로 SQL 쿼리에 넣는 코드를 AI가 제안했을 때는 정말 아찔했어요. 요즘은 거의 모든 프레임워크에서 파라미터화된 쿼리를 사용하는데, AI는 오래된 튜토리얼에서 학습한 문자열 연결 방식을 그대로 내놓은 거죠.

두 번째로 효과적이었던 건 사람의 코드 리뷰였어요. 다행히 저희 팀은 모든 PR에 대해 최소 1명 이상의 리뷰어를 지정하는 문화가 있어요. AI가 생성한 코드를 그대로 커밋하고 PR을 올렸을 때, 리뷰어가 JWT 토큰 검증 로직에서 미흡한 부분을 발견해준 적이 있습니다. 토큰의 서명만 확인하고 만료 시간을 체크하지 않는 코드였어요. AI 입장에서는 ‘토큰 검증’이라는 일반적인 패턴만 제시했을 뿐, 구체적인 보안 요구사항까지는 알지 못했던 거죠.

세 번째는 조금 추상적이지만, ‘뭔가 이상하다’는 느낌이에요. AI가 제안한 코드를 그대로 받아들이기 전에 잠시 멈추고 생각하는 습관이 생겼습니다. ‘이 라이브러리는 왜 필요하지?’, ‘이 함수는 정말 안전한가?’ 같은 질문을 스스로에게 던지면서요. 이런 의심이 없었다면 놓쳤을 취약점이 한두 개가 아니었어요.

없는 함수와 가짜 라이브러리의 습격

보안만큼이나 골치 아팠던 건 AI의 ‘환각’ 현상이었어요. 마치 실제로 존재하는 것처럼 없는 함수나 라이브러리를 import 하는 코드를 아주 당당하게 제안하는 거예요. 처음에는 이게 뭔가 싶어서 당황했지만, 알고 보니 AI 코딩 도구의 꽤 흔한 문제라고 하더라고요.

제 경우에는 파이썬으로 데이터 분석 스크립트를 작성할 때였어요. AI가 ‘from advanced_analytics import predictive_model’ 같은 코드를 제안했는데, 그런 라이브러리는 세상에 존재하지도 않았어요. 아마도 학습 데이터에 있던 여러 라이브러리 이름이 확률적으로 조합되면서 만들어진 가상의 결과물이었던 거죠. 이런 코드를 그대로 믿고 실행했다면 당연히 모듈을 찾을 수 없다는 에러만 한참 마주했을 거예요.

또 한 번은 자바스크립트에서 DOM을 조작하는 코드를 작성할 때였어요. AI가 ‘element.safeRemove()’라는 메서드를 사용했는데, 이런 메서드는 표준 API에 없습니다. 아마도 jQuery의 remove()와 ‘safe’라는 단어가 결합된 환각이었을 거예요. 이런 경우 코드가 조용히 실패하거나 런타임 에러를 발생시키기 때문에 디버깅이 꽤 까다로워요.

이런 환각 코드가 특히 위험한 이유는, 겉으로 보기에는 아주 자연스럽고 그럴듯해 보이기 때문이에요. 문법도 맞고, 네이밍 컨벤션도 완벽하고, 심지어 주석까지 달려 있어요. 경험이 적은 개발자라면 ‘내가 모르는 새로운 API인가 보다’ 하고 넘어갈 수도 있는 거죠.

안전하게 AI와 협업하는 제 작업 흐름

3개월 동안 이런저런 시행착오를 겪으면서 나름대로 정착된 작업 방식이 있어요. 완벽한 방법은 아니지만, 적어도 치명적인 실수를 방지하는 데는 꽤 효과적이었습니다.

먼저 AI에게 맡길 작업의 범위를 명확히 구분했어요. 앞서 말씀드린 것처럼 인증, 결제, 개인정보 처리 같은 민감한 로직은 처음부터 끝까지 직접 작성합니다. AI는 단순히 참고용으로만 보고요. 반면에 단위 테스트 코드 작성, 문서화, 반복적인 CRUD, 유틸리티 함수 생성 같은 작업은 AI에게 적극적으로 맡기고 있어요.

두 번째로, AI가 생성한 모든 코드는 반드시 로컬에서 실행해보고 테스트를 통과시킵니다. ‘아마 되겠지’라는 생각으로 커밋하지 않아요. 특히 외부 라이브러리를 import 하는 코드는 실제로 그 라이브러리가 존재하는지, 버전은 최신인지 npm이나 pip에서 확인하는 습관을 들였습니다.

세 번째는 린터와 포매터를 적극 활용하는 거예요. ESLint나 Prettier 같은 도구를 에디터에 연동해두면, AI가 제안한 코드에서 문법 오류나 잠재적 문제를 바로 잡아낼 수 있어요. 예를 들어 사용되지 않는 변수, 정의되지 않은 함수 호출 같은 건 린터가 바로 경고를 띄워주니까 환각 코드를 빠르게 걸러낼 수 있었습니다.

네 번째는 커밋을 아주 잘게 나누는 거예요. AI가 생성한 코드 덩어리를 한 번에 커밋하지 않고, 논리적인 단위로 쪼개서 커밋합니다. 그래야 나중에 문제가 생겼을 때 어떤 변경이 원인인지 빠르게 추적할 수 있거든요. ‘AI가 짠 코드’라는 이유로 뭉뚱그려 커밋하는 건 정말 위험한 습관이에요.

• ✅ AI 코드 사용 전 체크리스트
• ☐ 코드에 사용된 외부 라이브러리가 실제로 존재하는지 확인했나요?
• ☐ 사용자 입력을 처리하는 부분에 SQL 인젝션이나 XSS 위험은 없나요?
• ☐ 비밀번호나 API 키 같은 민감 정보가 하드코딩되어 있지 않나요?
• ☐ 암호화 관련 설정이 최신 보안 권장사항을 따르고 있나요?
• ☐ 로컬에서 직접 실행하고 테스트를 통과했나요?
• ☐ 린터나 정적 분석 도구에서 경고가 발생하지 않나요?
• ☐ 다른 개발자의 코드 리뷰를 받을 준비가 되었나요?

AI 코딩 도구, 앞으로 어떻게 대비할까

AI 코딩 도구는 분명히 앞으로 더 똑똑해질 거예요. 이미 깃허브 코파일럿은 코드의 맥락을 더 잘 이해하는 방향으로 진화하고 있고, 커서 같은 도구는 에디터 전체를 AI가 이해하는 수준까지 왔어요. 그렇다고 해서 ‘AI가 모든 걸 알아서 해주겠지’라는 생각은 여전히 위험하다고 느껴요.

보안 업계의 전망을 보면, AI가 생성한 코드를 노리는 공격 기법도 함께 진화할 거라고 해요. 예를 들어 ‘프롬프트 인젝션’이라는 개념이 있어요. 악의적인 주석이나 코드 조각을 프로젝트에 심어두면, AI가 그걸 학습해서 취약한 코드를 생성하도록 유도할 수 있다는 거죠. 오픈소스 프로젝트에 누군가 고의로 취약한 패턴을 커밋해두고, 그게 AI의 학습 데이터에 포함되기를 기다리는 시나리오도 가능하다고 합니다.

또 하나 고민되는 건 라이선스 문제예요. AI가 학습한 코드 중에는 GPL 같은 강한 카피레프트 라이선스가 적용된 코드도 섞여 있을 수 있어요. 그런 코드를 무심코 사용했다가 나중에 법적 분쟁에 휘말릴 가능성도 배제할 수 없습니다. 실제로 깃허브 코파일럿을 둘러싼 집단 소송도 진행 중이고요.

그래서 제 나름대로 세운 원칙은 이거예요. AI는 ‘똑똑하지만 경험이 부족한 주니어 개발자’라고 생각하자는 거죠. 주니어 개발자가 짠 코드는 당연히 리뷰하고, 테스트하고, 때로는 다시 작성하기도 하잖아요. AI 코드도 똑같이 대하는 거예요. 신뢰는 하되, 검증은 반드시 하는 태도가 필요하다고 생각합니다.

자주 묻는 질문

AI가 짠 코드라는 걸 나중에 어떻게 알 수 있나요?

깃허브 코파일럿 같은 도구는 기본적으로 코드가 AI에 의해 생성되었는지 별도로 표시하지 않아요. 그래서 커밋 메시지에 ‘AI assisted’ 같은 태그를 달아두거나, PR 설명에 어떤 부분을 AI가 생성했는지 명시해두는 팀 문화를 만드는 게 도움이 됩니다. 나중에 문제가 생겼을 때 추적하기 훨씬 수월해져요.

AI 코딩 도구를 사용하면 정말 일자리가 줄어들까요?

단순 반복 작업은 확실히 줄어들 거예요. 하지만 그렇다고 해서 개발자라는 직무 자체가 사라지지는 않을 거라고 생각해요. 오히려 AI가 기본 코드를 생성하는 시간을 아껴주니까, 더 복잡한 문제 해결이나 아키텍처 설계, 보안 감사 같은 고부가가치 업무에 집중할 수 있게 될 거예요. 실제로 많은 기업들이 AI 도구 도입 후 개발자 채용을 줄이기보다는 더 공격적인 제품 개발에 나서고 있다는 보도도 있어요.

어떤 AI 코딩 도구가 가장 안전한가요?

안전성 측면에서 특정 도구가 월등히 낫다고 말하기는 어려워요. 깃허브 코파일럿, 커서, 아마존 코드위스퍼러 모두 비슷한 수준의 보안 문제를 내포하고 있어요. 오히려 도구 자체보다는 그 도구를 어떻게 사용하는지가 더 중요합니다. 어떤 도구를 쓰든 코드 리뷰와 정적 분석을 병행하는 게 핵심이에요.

AI가 생성한 코드에 저작권 문제가 생길 수 있나요?

가능성이 있어요. 앞서 언급한 것처럼 AI가 학습한 데이터에 특정 라이선스가 적용된 코드가 포함되어 있을 수 있거든요. 아직 법적으로 명확히 결론이 난 부분은 아니지만, 최소한 AI가 생성한 코드를 그대로 상업 제품에 사용할 때는 라이선스 검토를 꼭 해보시는 게 좋습니다.

린터나 정적 분석 도구만으로 충분한가요?

충분하지 않아요. 린터는 주로 코드 스타일과 기본적인 오류를 잡아주고, 정적 분석 도구는 알려진 취약점 패턴을 탐지해줘요. 하지만 비즈니스 로직의 오류나 컨텍스트에 따른 보안 문제는 이런 도구로 잡아내기 어려워요. 결국 사람의 리뷰가 병행되어야 합니다.

AI 코딩 도구를 아예 쓰지 말아야 할까요?

그럴 필요는 전혀 없어요. 단지 맹목적으로 신뢰하지 말자는 거예요. 앞서 말씀드린 체크리스트와 작업 흐름을 잘 지키면서 사용하면 생산성 향상이라는 이점을 충분히 누릴 수 있어요. 저도 여전히 매일 AI 도구를 사용하고 있고, 앞으로도 그럴 거예요.

소규모 팀이나 혼자 작업할 때는 어떻게 해야 하나요?

코드 리뷰를 해줄 동료가 없는 환경이라면 더욱 신중해야 해요. 최소한 정적 분석 도구는 꼭 도입하시고, AI가 생성한 코드는 반드시 직접 테스트 코드를 작성해서 검증하는 습관을 들이세요. 그리고 가능하다면 오픈소스 커뮤니티나 온라인 코드 리뷰 플랫폼을 활용해서 다른 사람의 의견을 듣는 것도 좋은 방법이에요.

본 내용은 2025년 7월 기준으로 작성되었으며, AI 코딩 도구의 기능과 보안 특성은 빠르게 변화할 수 있습니다. 특정 도구의 사용 여부나 보안 정책에 대한 최종 판단은 각 조직의 보안 가이드라인과 전문가의 조언을 따르시길 권장합니다. 이 글은 개인적인 경험을 바탕으로 한 정보 제공 목적이며, 법적 또는 기술적 조언으로 간주되어서는 안 됩니다.