'작동한다'는 말이 얼마나 위험한 문장인지, 3주가 지나서야 깨달은 사례가 있다. Supabase로 사이드 프로젝트를 만들던 개발자가 Claude에게 공개 프로필 페이지를 요청했다. AI는 즉시 SQL 뷰를 생성했고, 코드는 정상 동작했으며 테스트도 전부 통과했다. 그런데 3주 후 확인해보니 anon 키 하나만 있으면 누구든 전체 사용자 이메일을 조회할 수 있는 상태였다. RLS 정책은 켜져 있었고, 정책 자체도 올바르게 설정되어 있었다. 문제는 Postgres 뷰가 기본적으로 뷰 소유자의 권한으로 실행되어 RLS를 완전히 우회한다는 점, 그리고 Supabase가 public 스키마의 모든 객체를 자동으로 API 엔드포인트로 노출한다는 점, 이 두 동작이 조용히 맞물린 데 있었다. AI가 뷰에 포함한 email 컬럼에 대해 개발자가 묻자, 모델은 '부분적인 사용자 데이터'라고 설명했다. 틀린 말은 아니었다. 그냥 가장 중요한 맥락이 빠져 있었을 뿐이다.
이 사건의 구조가 흥미로운 이유는 AI가 잘못된 코드를 만들어서가 아니기 때문이다. AI는 요청받은 대로 공개 프로필 페이지를 만들었다. 코드는 의도한 기능을 정확히 수행했다. 문제는 '내가 렌더링하지 않는 것 중에 무엇이 읽힐 수 있는가'라는 질문을 아무도 하지 않았다는 점이다. 이 질문은 공격자처럼 사고할 때만 떠오른다. 코드 생성 모델은 그렇게 사고하도록 설계되어 있지 않다. 테스트도 마찬가지다. 앱이 무엇을 보여주는지는 검증하지만, 숨길 의도였던 것이 노출되는지는 검증하지 않는다.
이 보안 사고를 더 위험하게 만드는 맥락이 있다. AI 코딩 6개월 후 개발자가 자신의 인지 변화를 기록한 글(dev.to, Josh Matthew)에 따르면, AI 도구를 집중적으로 사용한 이후 코드에 대한 '예측 루프'가 조용히 사라졌다고 한다. 수동으로 코딩할 때는 한 줄을 쓰기 전에 반드시 '이 코드는 X를 반환할 것이다'라는 예측을 먼저 형성했다. 이 예측-확인 루프가 반복되면서 코드에 대한 정신 모델이 쌓인다. AI가 완성된 코드를 먼저 건네는 순간, 이 예측 단계는 선택 사항이 된다. 그리고 마감 압박 아래서 선택 사항은 언제나 건너뛰어진다. 결과는 '이해 없는 소유'다. PR에 내 이름이 붙어 있는데, 그 코드를 처음 보는 사람처럼 읽게 되는 상태.
이 인지 변화는 단순한 개인적 감상이 아니라 팀 단위 보안 리스크와 직결된다. 앞서 설명한 RLS 우회 사건에서 개발자는 뷰가 생성된 직후 코드를 '대충 훑어보고 그럴듯해 보였다'고 기록했다. 예측 루프가 작동하고 있었다면, '이 뷰를 anon 키로 조회하면 무엇이 반환되는가'라는 질문이 자연스럽게 떠올랐을 것이다. 하지만 AI가 이미 완성된 코드를 건넨 상태에서, 그 코드가 작동하는 것을 눈으로 확인한 직후라면, 예측 단계는 이미 생략된 후다. 이해 없이 받은 코드는 검토 없이 배포된다.
더 넓은 관점에서 보면, 'AI로 앱을 만들 수 있지만 그 앱을 이해하지 못하는 사람들'이 늘어나는 현상이 이미 진행 중이다(dev.to, Gamya M). 코딩 배경 없이 하루 만에 인증·DB·UI를 갖춘 앱을 만든 사람의 사례처럼, AI는 결과물을 만드는 능력을 대중화했다. 하지만 그 결과물이 2AM에 예상치 못한 방식으로 깨졌을 때, 고칠 수 있는 정신 모델은 여전히 직접 쌓아야 한다. AI가 작동하는 코드를 만드는 능력과, 왜 작동하는지를 이해하는 능력은 같은 것이 아니다. 그리고 그 차이가 가장 먼저 터지는 곳은 보안이다.
AI-First 팀을 리빌딩하는 테크 리드 입장에서 이 세 사례가 가리키는 시사점은 명확하다. 첫째, 'AI가 만든 코드가 작동한다'는 사실은 보안 검토 면제권이 아니다. Supabase 사례처럼 기능 테스트가 전부 통과해도, 의도하지 않은 데이터가 노출될 수 있다. 코드 리뷰 체크리스트에 '이 코드가 렌더링하지 않는 것 중 접근 가능한 것은 무엇인가'라는 공격자 시점의 질문을 명시적으로 넣어야 한다. 둘째, AI 도구 도입 후 팀원의 예측 루프가 유지되고 있는지 점검해야 한다. PR 리뷰 시 '이 diff가 배포되면 어떤 동작이 바뀌는지 한 줄로 설명해보라'는 질문은 이해도를 확인하는 가장 간단한 방법이다. 셋째, AI 생성 코드의 품질 관리 전략은 도구의 정확도 문제가 아니라 팀의 검증 루프 설계 문제다. 모델이 얼마나 좋아지든, 의도하지 않은 노출은 '요청하지 않은 것'에서 발생한다.
실용적인 대응은 이미 존재한다. Supabase 프로젝트라면 pg_views에서 public 스키마의 뷰를 전수 조회하고, anon 키로 직접 API를 호출해서 반환값을 확인하는 것이 가장 빠른 검증이다. 팀 레벨에서는 AI 생성 코드를 머지하기 전 '이 코드가 노출하는 데이터의 범위를 리뷰어가 직접 설명할 수 있는가'를 기준으로 삼는 것이 현실적이다. 예측 루프를 강제로 복원하는 방식이다. 속도를 포기하자는 말이 아니다. 보안에 직결되는 경계 지점만큼은, AI가 건넨 코드를 그대로 탭하기 전에 한 번 더 예측하자는 것이다.
전망은 냉정하게 봐야 한다. AI 코딩 도구는 더 빠르고 더 정확해질 것이다. 하지만 모델이 공격자처럼 사고하는 능력을 갖추는 것과, 팀이 그 사고를 훈련하는 것은 다른 시간표에서 진행된다. 당분간 AI가 만든 코드의 보안 취약점을 발견하는 예측력은 여전히 개발자가 만들어야 한다. AI-First 워크플로우가 빨라질수록, 그 루프를 의도적으로 설계하지 않으면 팀의 이해도는 속도에 반비례해서 낮아진다. 그리고 이해도가 낮아진 팀이 치르는 비용은 디버깅이 아니라 데이터 유출로 청구서가 날아온다.