개발자들이 AI 어시스턴트로 코딩할 때 어떤 실수를 할까?

Copilot, Claude, Cursor의 내장 모델 같은 AI 어시스턴트들은 코드 작성 속도를 바꿔놨다. 하지만 코드를 얼마나 신중하게 검토해야 하는지는 바꾸지 못했다. AI 보조 코딩으로 본 대부분의 피해는 모델 자체가 아니라 반복되는 습관 몇 가지에서 나온다.

제안을 읽지 않고 수락하기

가장 큰 실수는 자동 완성이 그럴듯해 보이고 컴파일되기만 하면 탭으로 수락하는 것이다. 그럴듯함은 정확함이 아니다. SQL 쿼리가 리팩토링 중 WHERE 절을 조용히 빼먹는데 변수 이름이 맞아서 수락한 경우를 본 적이 있다. 어시스턴트가 건넨 모든 줄을 동료의 풀 리퀘스트를 읽는 것과 같은 속도로 읽지 않으면 이해하지 못한 것을 배포하게 된다. 모든 제안을 빠르지만 코드베이스 규칙을 알지 못하는 주니어 개발자의 초안으로 취급하라.

보안 관련 코드를 신뢰하기

AI 어시스턴트들은 방대한 양의 공개 코드로 학습되는데, 그 코드 상당수는 보안 문제가 있다. 빠른 파일 업로드 핸들러를 요청하면 확장자 검사 없이, 크기 제한 없이, os.path.join이나 안전한 라이브러리 호출 대신 문자열 연결로 경로를 만드는 것을 받기 쉽다. 인증도 마찬가지다: 어시스턴트들은 JWT를 localStorage에 저장하거나 == 대신 상수 시간 비교를 사용하는 걸 자주 제안한다. 이 모든 것은 악의적이지 않고, 학습 데이터에 통계적으로 흔할 뿐이다. 인증, 파일 I/O, 역직렬화, SQL을 다루는 것이라면 로직을 직접 작성하거나 AI 출력을 새 코드에 하는 것과 같은 위협 모델링 질문으로 검증하라: 악의적 입력에 어떻게 되는가, 이 호출이 실패하면 어떻게 되는가, 이 엔드포인트에 누가 접근할 수 있는가.

의존성과 API를 임의로 만들기

모델들은 패키지 이름과 함수 서명을 완벽한 자신감으로 허구를 만든다. 이것이 "slopsquatting" 문제다 — 공격자들이 모델이 자주 제안하는 가짜 패키지 이름을 등록하므로 검증 없는 pip install이나 npm install이 로깅 라이브러리가 아닌 전혀 다른 것을 내려받을 수 있다. 어시스턴트가 추천하는 의존성을 추가하기 전에 PyPI나 npm에 실제로 존재하는지, 다운로드 수와 마지막 발행 날짜를 확인하고, 충분히 작으면 소스를 훑어보라. API 호출도 마찬가지다: 어시스턴트가 모르는 메서드를 참조하면, 존재한다고 가정하기 전에 실제 문서를 확인하라.

자신의 코드에 대한 정신 모델 잃기

코드를 직접 작성할 때는 각 부분이 왜 존재하는지 정신적 지도를 만든다. 세션 전체에 큰 블록의 AI 생성 코드를 수락할 때는 그 지도가 빠르게 얇아진다. 그러면 3주 뒤 버그가 나타나고 직접 작성하지 않은, 완전히 기억하지 못하는 코드를 디버깅하게 된다. 해결책은 AI 생성 코드를 피하는 것이 아니라, 병합하기 전에 각 청크를 자신에게 또는 팀원에게 설명할 만큼 충분히 천천히 하는 것이다. 함수가 무엇을 하는지 왜 그렇게 하는지 설명할 수 없으면 아직 병합하지 말라.

코드 때문에 테스트 건너뛰기