AI가 만든 코드는 실제로 안전한가요? 빌더를 위한 FAQ

온보딩 콜을 할 때마다 거의 매번 어떤 형태로든 이 질문을 받습니다. 대개 조심스러운 말투로, 질문하는 사람 스스로도 자신의 걱정이 기우라는 말을 듣고 싶어 하는 것처럼 느껴질 때가 많습니다. 하지만 그런 위안을 받아서는 안 됩니다. 보안은 사람이 짰든 모델이 짰든 상관없이 적당한 정도의 편집증이 정확히 들어맞는 몇 안 되는 영역 중 하나입니다. 아래는 제가 실제로 받는 질문들에 최대한 직접적으로 답한 내용입니다.

AI가 작성한 코드는 사람이 작성한 코드보다 보안이 취약한가요?

평균적으로, 그리고 별도 검증 없이 방치한다면 — 네, 약간 그렇습니다. 몇 년 전 스탠퍼드 연구(Perry 등, 이 주제를 처음 제대로 다룬 연구로 자주 인용됨)에 따르면 AI 코딩 어시스턴트를 사용한 개발자들이 대조군보다 덜 안전한 코드를 작성했고 — 더 걱정스러운 부분은 — 자신의 코드가 실제보다 더 안전하다고 평가했다는 점입니다. 자신감은 올라갔지만 품질은 떨어진 것이죠. Veracode의 최근 GenAI 코드 보안 스캔도 대략적인 수치를 제시합니다. 테스트한 AI 생성 코드 샘플 10개 중 약 4개가 최소 하나의 악용 가능한 결함을 포함하고 있었는데, 대개 입력 검사 누락이나 취약한 기본값 같은 평범한 문제였습니다. 이것이 AI가 작성한 코드가 본질적으로 문제라는 뜻은 아닙니다. 검토받지 않은 AI 코드는 검토받지 않은 사람 코드와 똑같은 리스크를 안고 있으며, 진짜 위험은 바로 '검토받지 않았다'는 부분에 있다는 뜻입니다. 빠르게 코드를 작성하고 한 번도 검토받지 않는 모델은 금요일 오후의 주니어 개발자와 똑같은 실수를 저지르게 됩니다 — 다만 더 빠르고, 더 많이요.

제 API 키와 비밀 정보는 어떻게 되나요?

이건 제가 실제로 잠을 설치게 만드는 문제인데, 드러나기 전까지는 눈에 보이지 않는 실수이기 때문입니다. 실패 양상은 영화적이지 않습니다. 누군가의 서버가 극적으로 뚫리는 게 아니라, 채팅창에 붙여넣은 키가 생성된 파일에 그대로 다시 나타나고, 커밋되고, 6개월 뒤 누군가 호기심에 시크릿 스캐너를 돌려볼 때 저장소 안에 평문으로 조용히 남아 있는 식입니다. 이 플랫폼에서는 비밀 정보가 생성된 소스 코드 안에 절대 존재하지 않습니다 — 런타임에 암호화된 저장소에서 테넌트 범위로 주입되며, 빌드 에이전트는 값이 아니라 이름으로만 참조하도록 지시받습니다. 하지만 다른 곳에서 빌드하거나, 어떤 도구든 채팅창에 자격 증명을 직접 붙여넣는다면, 제공업체가 명시적으로 다르게 밝히지 않는 한 그 텍스트가 어딘가 학습 관련 로그의 일부가 되었다고 가정하세요. 테스트를 마친 그날 원칙적으로 채팅창에 입력했던 모든 것을 교체(rotate)하세요.

프롬프트 인젝션 같은 걸로 누군가 제 사이트를 해킹할 수 있나요?

여기서 서로 다른 두 가지가 혼동되는 경우가 많은데, 이 구분이 중요합니다. 빌더를 대상으로 한 프롬프트 인젝션 — 앱을 만드는 AI를 속여서 요청하지 않은 작업을 하게 만드는 것 — 은 실제로 연구된 위험이며, 그래서 빌드 에이전트는 무제한 셸 접근이 아니라 범위가 제한된 도구 권한으로 실행되고, 파일 시스템이나 배포 파이프라인을 건드리는 모든 작업은 나중에 감사할 수 있는 명시적인 액션 로그를 거칩니다. 출시된 앱을 대상으로 한 프롬프트 인젝션은 별개의 문제로, 앱 자체가 런타임에 LLM을 내장하고 있을 때만 해당됩니다 — 지원 챗봇, AI 검색 기능 같은 것들이죠. 그런 경우라면 사용자가 입력할 수 있는 모든 텍스트를 그 모델에 대한 신뢰할 수 없는 입력값으로 취급하세요. SQL 쿼리에 대한 신뢰할 수 없는 입력값으로 취급하는 것과 마찬가지입니다. 원칙은 오래됐고, 새로운 부분은 어떤 시스템이 그 문자열을 파싱하는지뿐입니다.

빌더는 코드를 배포하기 전에 자체적으로 취약점을 확인하나요?

자동화된 검사는 흔하고 지루한 문제들은 안정적으로 잡아냅니다: 하드코딩된 비밀 정보, 명백히 인증이 필요한 엔드포인트의 인증 누락, 매개변수 대신 문자열 결합으로 만든 SQL, 알려진 CVE가 있는 의존성 등. 하지만 비즈니스 로직 결함은 잘 잡아내지 못합니다 — 개별 코드 줄 하나하나는 모두 정상이지만 아무도 함께 확인할 생각을 못 한 두 기능 사이의 틈에 취약점이 존재하는 경우 말이죠. 추천 코드가 리퍼럴 보너스와 무한히 중첩되는 것. 이메일이 시스템에 존재하는지 여부를 노출하는 비밀번호 재설정 흐름. 이런 것들은 코드가 무엇을 하는지가 아니라 앱이 무엇을 위한 것인지 이해하는 사람이 필요하며, AI든 아니든 어떤 스캐너도 아직 이런 문제를 안정적으로 찾아내지 못합니다. 자동 검토는 바닥선이지 천장이 아닙니다.

빌더가 설치하는 서드파티 패키지는 어떤가요 — 공급망 리스크인가요?

네, 그리고 솔직히 말하면 AI가 작성한 코드 자체보다 현실적으로 더 큰 위험입니다. 대부분의 앱은 줄 수 기준으로 80~95%가 의존성이며, 빌더가 작성하는 코드는 npm, PyPI, 혹은 어떤 생태계든 그 위에 얹힌 얇은 층일 뿐입니다. 악성이거나 탈취된 패키지는 그 주변의 접착 코드를 누가, 무엇이 작성했든 상관없이 여러분을 위험에 빠뜨릴 수 있습니다 — 이런 일이 실제로 어떻게 벌어지는지는 event-stream과 colors.js 사건을 참고하세요. 대응책은 지루하지만 효과적입니다: 최신 버전을 추적하기보다 버전을 고정하고, 지난주에 게시된 패키지보다 실제 유지보수 이력이 있는 패키지를 선호하며, 의존성 감사(`npm audit`, `pip-audit` 등 스택에 맞는 도구)를 출시 전 일회성 단계가 아니라 상시 습관으로 실행하세요.

유출 사고가 발생하면 누구 책임인가요?

거의 항상 법적으로는 사용자 본인입니다 — 만약 그것이 여러분의 앱이고 여러분 고객의 데이터라면요. 'AI가 만들었다'는 사실이 책임을 어딘가로 옮겨줄 거라고 생각하는 사람들에게는 놀라운 사실일 수 있습니다. 그렇지 않습니다. 시공업자를 고용했다고 해서 건축법 위반 책임이 건물 소유주에게서 사라지지 않는 것과 마찬가지입니다. 플랫폼은 자신이 통제하는 인프라에 대한 책임을 집니다: 비밀 정보를 어떻게 저장하는지, 테넌트 데이터를 어떻게 격리하는지, 호스팅 계층 자체에 패치가 되어 있는지 여부 등이죠. 하지만 여러분이 명세한 애플리케이션 로직, 여러분이 수집하기로 선택한 데이터, 여러분이 사용자에게 제시한 이용약관은 여러분의 책임입니다. 결제 정보, 건강 정보, GDPR이나 CCPA에 해당하는 민감한 정보를 다룬다면, 'AI로 만들었다'는 사실이 추가적인 법적 보호막을 의미한다고 가정하지 말고 사용 중인 플랫폼의 실제 데이터 처리 계약서를 읽어보세요. 그런 보호막은 없습니다.

한 창업자가 예전에 반쯤 농담으로 자기 코드보다 AI의 코드를 더 신뢰한다고 말한 적이 있습니다. "적어도 새벽 2시에 지치지는 않으니까요"라면서요. 그럴 수도 있죠. 하지만 지친 사람은 보통 자신이 지쳤다는 걸 압니다. AI는 방금 실수를 저질렀다는 사실을 전혀 모르며, 코드가 완벽하든 구멍투성이든 똑같이 자신 있는 어조로 완성되었다고 말할 겁니다. 자신감은 그 출처가 무엇이든 보안의 신호가 아닙니다.

출시 전에 실제 보안 감사에 비용을 지불해야 할까요?

결제를 처리하거나, 규제 기관이 개인정보(PII)로 분류할 만한 정보를 저장하거나, 어차피 SOC 2 보고서를 요구할 기업 고객을 위해 만드는 앱이라면 — 네, 비용 때문에 망설이지 마세요. 소규모 앱에 대한 집중 감사는 범위에 따라 수백 달러에서 수천 달러 정도이며, 유출 통지서 발송 비용에 비하면 저렴합니다. 취미용 프로젝트, 내부 도구, 실제 사용자 데이터가 걸려 있지 않은 것을 만드는 중이라면 유료 감사는 과합니다. 대신 무료이고 저렴한 계층을 활용하세요 — 의존성 스캔, 모든 인증 경계에 대한 수동 클릭 테스트(URL을 바꾸면 사용자 A가 사용자 B의 정보를 볼 수 있는가?), 그리고 돈이나 비밀번호를 다루는 부분에는 사람의 눈으로 한 번 더 확인하는 것입니다.

사람들이 가장 흔하게 저지르는 보안 실수는 무엇이고, 언제 발생하나요?

출시 시점이 아니라, 앱이 잘 돌아가고 아무도 더 이상 들여다보지 않는 3개월 뒤에 발생합니다. 만든 사람이 자기 계정으로 로그인해서만 테스트했기 때문에 보호되지 않은 채 남은 관리자 경로. 프로덕션 환경에서 전체 스택 트레이스를 반환하는 디버그 엔드포인트. '테스트용'이라던 데이터베이스의 기본 비밀번호가 한 번도 교체되지 않은 것. 이 중 어느 것도 특이한 문제가 아닙니다. 바쁠 때 한 번 문 밑에 여분의 열쇠를 두고는 거기 있다는 사실을 잊어버리는 것과 같은 보안 버전의 실수입니다. 해결책은 더 나은 도구가 아니라 5분짜리 습관입니다: 한 달에 한 번, 자랑스러운 빌더의 시선으로 보기 전에 공격자의 시선으로 5분간 자신의 앱을 살펴보세요.