비개발자를 위한 AI 웹사이트 보안 체크리스트

빠르게 만든 웹사이트도 운영 책임은 남습니다

AI와 웹 제작 도구를 사용하면 코드를 처음부터 배우지 않아도 화면과 기능을 빠르게 만들 수 있습니다. 문제는 “정상적으로 보인다”와 “안전하게 운영할 수 있다”가 같은 뜻이 아니라는 점입니다.

문의 양식이 전송되더라도 개인정보가 어디에 저장되는지 모를 수 있고, 관리자 화면이 열리더라도 서버에서 권한을 확인하지 않을 수 있습니다. AI가 만든 코드는 시작점으로 유용하지만 공개 전 검토와 운영 책임까지 대신하지는 않습니다.

1. AI에 입력하기 전에 데이터를 분류합니다

먼저 입력하려는 자료를 세 단계로 나눠 보세요.

공개 가능: 이미 홈페이지에 공개된 소개, 주소, 일반 안내
내부용: 회의록, 공개 전 기획, 계약 전 견적
민감정보: 고객 명단, 상담 내용, 비밀번호, 결제정보, 건강·신앙 상담처럼 개인을 특정할 수 있는 내용

민감정보는 그대로 붙여 넣지 않습니다. 꼭 필요한 분석이라면 이름, 전화번호, 이메일, 주소, 고유한 사건 설명을 제거하고 가상의 예시로 바꿉니다.

예를 들어 “김OO, 010-1234-5678, 7월 3일 상담 내용” 대신 “사용자 A, 연락처 제거, 일반적인 문의 사례”처럼 목적에 필요 없는 정보를 없앱니다. 익명화했다고 생각해도 작은 단체에서는 상황 설명만으로 사람을 알아볼 수 있으므로 문맥도 함께 살펴야 합니다.

2. 비밀키는 코드와 브라우저에서 분리합니다

API 키, 데이터베이스 비밀번호와 관리자 토큰은 공개 저장소에 올리거나 브라우저 코드에 넣으면 안 됩니다. 화면의 개발자 도구에서 보이는 값은 비밀로 보호할 수 없습니다.

다음 위치를 확인하세요.

저장소의 .env 파일과 과거 커밋
브라우저로 전달되는 환경 변수
오류 메시지와 로그
화면 캡처와 사용 안내 문서
AI 대화에 붙여 넣은 설정 파일

실수로 공개했다면 파일에서 지우는 것만으로 끝나지 않습니다. 이미 노출된 키를 폐기하고 새로 발급한 뒤 사용 기록을 확인해야 합니다.

3. 관리자 페이지는 주소가 아니라 권한으로 보호합니다

/admin 주소를 메뉴에서 숨기거나 복잡하게 만드는 것은 접근 제어가 아닙니다. 로그인한 사용자가 실제 관리자 목록에 포함되는지 서버에서 확인해야 합니다. 글 저장, 삭제, 통계 내보내기 같은 API도 각각 같은 권한 검사를 해야 합니다.

확인할 질문은 다음과 같습니다.

로그아웃 상태에서 관리자 주소를 열면 차단되는가
일반 사용자가 저장 API를 직접 호출해도 거절되는가
관리자 목록은 코드와 공개 화면에 노출되지 않는가
관리자를 제거하면 기존 세션도 적절히 제한되는가
중요한 변경 기록에 작업자와 시간이 남는가

OWASP의 웹 애플리케이션 주요 위험 안내에서도 잘못된 접근 제어와 보안 설정은 중요한 위험 범주로 다룹니다.

4. 수집하는 개인정보의 목적과 삭제 시점을 정합니다

문의 양식에는 답변에 필요한 항목만 받습니다. 단순 광고 문의에 생년월일이나 상세 주소를 추가하면 관리할 위험만 커질 수 있습니다.

개인정보처리방침에는 실제로 수집하는 항목, 이용 목적, 보유기간, 삭제 방법, 외부 서비스 사용을 운영 설정과 맞게 적습니다. 문서에 “수집하지 않는다”고 쓰고 서버 로그나 분석 도구에서 식별자를 보관하면 안 됩니다.

통계가 필요하다면 처음부터 개인별 이동 경로보다 날짜별 합계처럼 목적을 충족하는 최소한의 방식이 가능한지 검토하세요.

5. AI가 제안한 이미지와 폰트의 권리를 다시 확인합니다

AI가 알려준 이미지 주소나 폰트 이름이 실제로 상업적 웹 사용을 허용한다는 보장은 없습니다. 검색 결과의 이미지를 내려받아 사용하거나 다른 사이트의 파일을 직접 연결하지 마세요.

원본 출처와 저작자를 확인했는가
상업적 웹 사용이 허용되는가
수정·재배포·자체 호스팅 조건은 무엇인가
출처 표시가 필요한가
인물, 상표와 건물에 별도 권리가 있는가

확인한 내용은 자산대장에 파일명, 출처, 라이선스, 취득일과 표시 조건으로 남깁니다. 조건이 불분명하면 시스템 글꼴, 직접 촬영한 사진, 권리가 명확한 유료·무료 자산처럼 다른 방법을 선택하세요.

6. 생성된 코드는 정상 상황과 실패 상황을 함께 시험합니다

버튼을 한 번 눌러 성공하는지만 확인하면 부족합니다.

필수 입력값을 비우거나 지나치게 긴 값을 넣기
같은 전송 버튼을 빠르게 두 번 누르기
네트워크를 끊은 상태에서 저장하기
존재하지 않는 주소 열기
권한 없는 상태에서 관리자 API 요청하기
모바일 화면과 키보드만으로 작업하기

오류 메시지는 사용자가 다음 행동을 알 수 있게 작성하되 서버 경로, 데이터베이스 구조와 비밀값을 그대로 보여주지 않아야 합니다.

7. 외부 라이브러리와 서비스의 변경을 관리합니다

AI가 오래된 사용법이나 유지보수가 중단된 패키지를 제안할 수 있습니다. 설치 전에는 공식 문서, 최근 업데이트, 알려진 보안 문제와 라이선스를 확인합니다.

업데이트를 무조건 자동으로 적용하거나 영원히 미루는 두 극단을 피하세요. 변경 내용을 검토하고 테스트 환경에서 빌드한 뒤 운영에 반영하는 순서를 정합니다. 외부 서비스의 요금과 정책이 바뀌었을 때 대체하거나 데이터를 내보낼 방법도 확인합니다.

8. 백업은 복원 시험까지 해야 완성됩니다

데이터베이스 파일이나 내보내기 파일을 보관해도 복원 방법을 모르면 사고 때 사용할 수 없습니다.

백업에는 다음 내용을 함께 기록하세요.

무엇을 얼마나 자주 백업하는가
백업 파일은 어디에 보관하는가
누가 접근할 수 있는가
얼마나 오래 보관하고 언제 삭제하는가
새 환경에 복원하는 순서는 무엇인가
마지막 복원 시험은 언제 성공했는가

코드, 데이터베이스, 업로드 이미지와 도메인 계정은 서로 다른 자산입니다. 하나의 백업만으로 전체 사이트가 복구된다고 가정하지 마세요.

공개 전 15분 최종 체크리스트

화면과 저장소에서 비밀키를 검색했는가
관리자 화면과 모든 변경 API가 권한을 확인하는가
문의 양식이 필요한 정보만 수집하는가
개인정보처리방침이 실제 운영과 일치하는가
이미지·폰트·아이콘의 사용 권한을 기록했는가
모바일, 키보드, 느린 네트워크에서 핵심 작업을 확인했는가
오류 화면이 내부 정보를 노출하지 않는가
백업 파일과 복원 순서를 확인했는가
의존성 보안 검사와 운영 업데이트 담당자를 정했는가
사고가 생겼을 때 연락하고 차단할 담당자가 있는가

문제가 발견됐을 때의 기본 순서

비밀키나 개인정보 노출이 의심되면 새로운 기능 개발보다 먼저 영향을 받는 기능을 차단합니다. 노출된 키를 폐기하고, 접근 기록과 저장 범위를 확인하고, 필요한 통지·신고 의무가 있는지 전문가와 검토합니다. 원인을 수정한 뒤 같은 문제가 다시 생기지 않도록 배포 절차와 점검표를 바꿉니다.

혼자 판단하기 어려운 개인정보, 결제, 의료·상담 정보와 보안 사고는 일반적인 AI 답변만으로 결정하지 말고 해당 분야 전문가의 검토를 받는 것이 안전합니다.

자주 묻는 질문

AI가 “보안 문제가 없다”고 하면 공개해도 되나요?

아닙니다. AI는 실행 환경, 실제 권한 설정과 외부 서비스 상태를 모두 알지 못할 수 있습니다. 자동 검사, 코드 검토와 실제 권한 테스트를 함께 진행해야 합니다.

비밀키를 비공개 GitHub 저장소에 올려도 되나요?

비공개 저장소도 비밀 저장소를 대신하지 않습니다. 접근 권한 실수와 로그 노출 가능성을 고려해 플랫폼의 환경 변수나 비밀 관리 기능을 사용하세요.

개인정보를 전혀 수집하지 않으면 개인정보처리방침이 필요 없나요?

광고, 분석, 서버 로그와 외부 서비스가 어떤 정보를 처리하는지까지 확인해야 합니다. 실제 처리 내용은 서비스 구조와 적용 법령에 따라 달라질 수 있으므로 공개 전 운영 설정과 문서를 함께 검토하세요.

제작 안내: 이 글은 공개된 보안 원칙과 미션랩의 편집 기준을 바탕으로 AI를 활용해 초안을 구성했습니다. 특정 시스템에 대한 보안 진단이나 법률 자문을 대신하지 않습니다.