사이드프로젝트, AI 코딩 어디까지 맡겨도 될까
생성형 AI 코딩 도구는 사이드프로젝트 속도를 크게 높여주지만, 여러 연구는 검증 없이 받아 쓴 코드에 보안 결함과 존재하지 않는 패키지가 섞일 수 있음을 보여준다. 혼자 개발하면 코드를 걸러줄 리뷰어가 없어서, 이런 문제가 그대로 배포까지 이어진다는 점이 핵심이다. 프로토타입과 반복 코드는 맡기되 인증·결제 같은 민감한 로직은 직접 검증하고, 패키지는 설치 전 실존 여부부터 확인하는 게 안전선이다.
결론부터: 써도 되지만 나눠서 맡겨라
혼자 사이드프로젝트를 만들면서 AI 코딩 도구를 쓰는 건 합리적인 선택이다. 문제는 '쓰느냐 마느냐'가 아니라 '어디까지 맡기느냐'다.
같은 도구라도 화면 하나 빠르게 찍어내는 데 쓰는 것과, 로그인·결제 로직을 통째로 맡기는 건 위험도가 전혀 다르다. 이 기준을 정해두지 않으면, 잘 돌아가는 것처럼 보이는 코드에 결함이 숨어도 알아채지 못한다.
단계와 민감도로 위임 범위를 나눈다
Photo by Daniil Komov on Unsplash
맡겨도 부담이 적은 영역이 있다. 프로젝트 초기 프로토타입, 반복적인 보일러플레이트, 새 라이브러리 사용법을 익히는 러닝 코드가 여기 해당한다. 틀려도 티가 빨리 나고, 고쳐도 범위가 좁다.
반대로 손을 놓으면 안 되는 영역이 있다. 인증, 결제, 사용자 입력 처리, 암호화처럼 한 번 뚫리면 데이터나 돈이 걸리는 로직이다. 스탠퍼드 연구진(Perry 외 3인, 참가자 47명)의 실험에서 AI 어시스턴트를 쓴 참가자들은 특히 SQL 인젝션과 문자열 암호화 과제에서 더 취약한 코드를 내놓았다. 하필 사이드프로젝트에서도 가장 조심해야 할 부분과 겹친다.
판단 기준은 이렇게 잡으면 현실적이다. 실패해도 나만 불편한 코드는 맡기고, 실패하면 사용자나 데이터가 다치는 코드는 AI에게 초안을 받되 내가 한 줄씩 이해하고 검증한다.
검증을 건너뛰면 생기는 두 가지 위험
첫째는 '안전하다는 착각'이다. 앞의 스탠퍼드 연구에서 AI를 쓴 참가자들은 코드가 덜 안전했는데도, 자기 코드가 안전하다고 오히려 더 확신했다. 리뷰어가 있는 팀이라면 다른 사람이 걸러주지만, 혼자면 이 착각을 교정해 줄 사람이 없다. 확신과 안전이 반대로 움직인다는 점이 혼자 개발할 때 가장 위험하다.
둘째는 존재하지 않는 패키지다. LLM은 실제로 없는 패키지 이름을 그럴듯하게 추천하곤 한다. 16개 모델이 만든 코드 샘플 57만 6000여 개를 분석한 연구에서, 추천된 패키지의 19.7%가 실재하지 않는 환각이었다. 오픈소스 모델은 평균 21.7%로 상용 모델(5.2%)보다 네 배가량 높았다.
문제는 이게 공격으로 이어질 수 있다는 점이다. 공격자가 자주 반복되는 가짜 이름을 미리 등록해두면, AI 추천만 믿고 설치하는 순간 악성 코드를 내려받는 '슬롭스쿼팅'이 된다. 실제로 환각 패키지의 43%는 여러 번 돌려도 똑같이 반복돼서 노리기 쉽다. 아직 대규모 피해 사례가 확인된 건 아니지만, 구조적으로 열려 있는 위험이다.
혼자서도 지킬 수 있는 점검 습관
리뷰어가 없으니 최소한의 절차를 스스로 만들어두는 게 낫다.
- 이해 못 한 코드는 커밋하지 않는다. 동작만 확인하고 넘어가면 나중에 디버깅이 불가능해진다.
- 패키지는 설치 전에 이름을 검색해 공식 저장소에 실재하는지, 다운로드 수와 관리 이력이 정상인지 확인한다.
- API 키·비밀번호가 코드나 로그에 그대로 박혀 있지 않은지 본다. AI가 예시로 넣은 하드코딩이 자주 남는다.
- 입력 검증과 인증 관련 코드는 테스트를 직접 짜서 돌린다.
- 의존성 취약점 스캔을 한 번은 돌려본다.
결국 생성형 AI는 초안을 빨리 만들어주는 도구지, 최종 판단을 대신해 주는 건 아니다. 맡길 곳과 붙잡을 곳을 나누고, 받은 결과를 확인하는 습관만 있으면 혼자여도 충분히 안전하게 쓸 수 있다.