Lovable로 만든 웹사이트, GitHub에 올리기 전 어떤 키를 확인해야 할까요?
핵심 요약 (TL;DR)
GitHub가 Lovable·Supabase 등의 새 비밀값 유형을 탐지하도록 secret scanning을 확장했습니다.[1] AI로 웹사이트를 만든 뒤 저장소에 연결하는 분께 유용한 변화입니다. 다만 탐지기가 늘었다는 소식은 모든 키가 보호된다는 보장이 아닙니다. 공개 전에 어떤 값이 코드에 들어갔는지, 경고가 뜨면 무엇을 폐기해야 하는지까지 확인하셔야 합니다.
이번에 무엇을 새로 찾게 되었나요?
GitHub의 10월 5일 공지는 Lovable API 키, Pydantic의 Logfire 토큰과 AI Gateway API 키, Supabase의 OAuth 액세스 토큰과 범위 지정 개인 액세스 토큰을 새 탐지 대상으로 안내합니다.[1] Supabase라는 이름이 있다고 모든 데이터베이스 비밀번호나 모든 종류의 키가 이번에 추가됐다고 읽으면 안 됩니다. 발표는 이름이 명시된 유형에 한정됩니다.
Lovable은 비밀값 탐지 파트너에도 새로 참여했습니다. 공개 저장소에서 파트너의 비밀값을 찾으면 GitHub가 해당 발급사에 전달해 폐기나 교체에 대응할 수 있도록 하는 구조입니다.[1] 이 글은 공식 공지에 근거한 안내이며, 실제 키를 노출해 탐지 속도를 시험한 사용기는 아닙니다.
화면을 만들었는데 왜 저장소까지 봐야 할까요?
문의폼이 잘 열리고 모바일 화면이 예쁘게 보이는 것과, 연결 자격 증명이 안전하게 보관되는 것은 다른 문제입니다. AI에게 외부 서비스를 연결해 달라고 요청하는 과정에서는 코드뿐 아니라 설정 예시와 설명 문서에도 값이 들어갈 수 있습니다.
예를 들어 ‘문의 내용을 저장하는 사이트’를 만든다면, 브라우저에 전달되는 설정과 서버에서만 보관해야 할 비밀값을 먼저 구분해 달라고 요청해 보세요. 이는 이번 공지에 소개된 사고가 아니라 제작 과정에 적용할 점검 제안입니다. AI가 안전하다고 답했는지만 보지 말고, 각 값의 발급 문서에서 용도와 권한을 확인하는 편이 좋습니다.
공개 직전에는 어떤 순서로 확인하면 좋을까요?
먼저 저장소에 들어갈 파일 목록을 살펴보세요. 설정 파일뿐 아니라 튜토리얼, 오류 기록, 복사한 예제에도 실제 값 대신 빈칸이나 명확한 예시가 쓰였는지 확인합니다. 비밀값을 제외하도록 설정했더라도 이미 기록된 변경 이력까지 사라진다고 생각하지 않는 것이 중요합니다.
다음으로 GitHub의 보안 설정과 경고 화면을 확인하세요. 공식 공지는 공개 저장소에서 발급사로 전달되는 Partner 비밀값과, 공개·비공개 저장소에서 경고를 만드는 User 비밀값을 구분합니다.[1] 발급사 통지, 내 저장소의 경고, 업로드를 막는 기능을 하나의 보장처럼 묶지 마세요. 사용 중인 저장소에서 어떤 보호가 적용되는지 따로 확인해야 합니다.
마지막으로 경고에 대응할 담당자와 순서를 정해 두세요. 혼자 만든 사이트라면 나중의 자신이 담당자입니다. 어디서 발급했는지, 어떤 서비스가 쓰는지 알아야 교체 뒤 문의폼이나 데이터 저장이 끊기지 않았는지도 확인할 수 있습니다.
FAQ: 경고가 없으면 공개해도 안전한가요?
경고가 없다는 사실만으로 모든 비밀값이 없다고 확정할 수는 없습니다. 이번 발표 역시 특정 탐지 유형을 추가한 것입니다.[1] 코드·설정 검토와 실제 사이트의 접근 권한 확인은 별도로 남겨 두세요.
FAQ: 실수로 올린 키는 코드에서 지우면 끝인가요?
삭제만으로 이미 노출된 자격 증명의 효력이 없어지지는 않습니다. 발급 서비스에서 폐기·교체 여부를 확인하고, 새 값을 안전하게 연결한 뒤 필요한 기능이 정상 작동하는지 점검하세요. 탐지는 출발점이고, 대응이 끝나야 사이트를 계속 운영할 수 있습니다.
댓글 0
아직 댓글이 없습니다