동작하는 것과 안전한 것은
눈으로 구분되지 않습니다
화면이 잘 돌아가는 것을 보면 다 된 것 같습니다. 그러나 데이터가 누구에게나 열려 있어도 화면은 똑같이 잘 돌아갑니다. 보안의 문제는 증상이 보이지 않는다는 데 있고, 그래서 감이 아니라 목록으로 확인해야 합니다.
위험의 상당수는 빨리 동작하게 하려고 느슨하게 열어 둔 기본값에서 옵니다. 만드는 중에는 편하지만 공개하는 순간 그대로 약점이 됩니다. AI가 특별히 위험한 코드를 쓴다기보다, 동작하는 화면까지 훨씬 빨리 도달하기 때문에 확인 단계가 통째로 생략되기 쉬운 것입니다.
공격의 대부분은 누가 우리 병원을 노려서 일어나지 않습니다. 자동 프로그램이 인터넷 전체를 훑다가 열린 곳을 찾아내는 방식입니다. 규모가 작아서 안전한 것이 아니라 열려 있지 않아서 안전한 것이며, 이 구분이 이 문서의 전제입니다.
위험은 정해진 자리에
모입니다
사고의 종류는 무한하지 않습니다. 비개발자가 만든 사이트에서 실제로 문제가 되는 자리는 대체로 아래 넷이며, 각각의 첫 방어도 함께 정해져 있습니다.
| 갈래 | 무슨 일이 벌어지는가 | 첫 방어 |
|---|---|---|
| 열쇠 노출 | 외부 서비스나 데이터베이스에 접속하는 값이 코드에 그대로 적힌 채 공개되는 경우입니다. 제3자가 우리 이름으로 서비스를 쓰면서 요금이 청구되고, 그 열쇠가 데이터로 향하는 것이었다면 정보까지 열립니다. | 금고에 보관 |
| 열린 데이터 | 예약과 문의가 쌓이는 저장소의 접근 규칙이 느슨한 채로 남는 경우입니다. 화면은 정상으로 보이지만 주소를 아는 누구나 내용을 읽을 수 있는 상태가 됩니다. | 규칙 잠그기 |
| 약한 인증 | 로그인을 직접 만들면서 비밀번호를 안전하지 않게 다루거나 확인 절차를 건너뛰는 경우입니다. 계정 도용은 사고의 크기가 곧바로 커집니다. | 검증된 인증 |
| 공개된 관리자 | 관리자 화면을 주소만 숨긴 채 두는 경우입니다. 주소는 링크와 검색, 자동 탐색으로 드러나며 숨김은 잠금이 아닙니다. | 권한으로 잠금 |
네 갈래 모두 만든 뒤에 고치기보다 만들기 전에 정하는 편이 쉽습니다. 기능 화면을 설계하는 순서는 어려운 것은 화면이 아니라 기능입니다에서, 열쇠를 금고에 두는 이유는 같은 문서의 열쇠 관리 절에서 이어집니다.
공개하기 전에
여섯 가지를 확인하십시오
전문 도구 없이 확인할 수 있는 최소한의 목록입니다. 해당하면 눌러 주십시오 — 점수는 안전을 보증하는 등급이 아니라, 지금 무엇부터 손봐야 하는지 좁히기 위한 도구입니다.
열쇠부터 확인해 보십시오. 코드 안에 길고 무작위한 문자열이 남아 있는지가 가장 흔한 출발점입니다.
같은 실수라도 무게가 다릅니다
일반 사이트에서 불편으로 끝날 일이 병원에서는 환자의 정보가 걸린 문제가 됩니다. 예약과 문의에 들어오는 것은 이름과 연락처, 그리고 증상이기 때문입니다.
무엇이 오가는가이름과 연락처, 증상과 방문 희망 일시 — 일반 쇼핑몰의 주문 정보보다 민감한 축에 듭니다사고가 나면요금 문제로 끝나지 않고 환자에 대한 통지와 신고의 문제로 이어집니다가장 값싼 방어받지 않는 것입니다. 상담 시작에 필요한 최소 항목만 받으면 새어 나갈 것도 그만큼 줄어듭니다가장 흔한 구멍관리자 화면입니다. 주소를 모르면 못 들어온다는 생각이 실제로 가장 자주 깨집니다그래서 병원 홈페이지에서는 기능을 적게 두는 것이 그 자체로 안전 설계가 됩니다. 예약과 문의만 정확히 작동해도 충분한 곳에 회원 기능과 결제를 얹으면, 얻는 것보다 지켜야 할 것이 빠르게 늘어납니다.
이 문서는 법률 자문이 아니며 특정 도구의 안전을 보증하지도 않습니다. 다만 무엇을 확인해야 하는지 아는 것만으로 대부분의 흔한 사고는 예방됩니다. 확인 목록을 기능이 늘 때마다 다시 돌리는 습관이 그 핵심입니다.
확인 목록은 여기에,
설정은 교육에서
이 문서는 위험이 어디에 모이는지와 무엇을 확인해야 하는지까지를 다룹니다. 저장소의 접근 규칙을 실제로 잠그고 권한을 나누며 열쇠를 금고로 옮기는 작업은 교육에서 참가자의 환경을 보며 함께 합니다. 설정값 하나가 결과를 가르는 영역이라 일반화된 절차를 글로 옮기지 않습니다.
보안에서 가장 많이 묻는 것들
AI가 만든 코드는 원래 위험한가요
코드 자체가 특별히 나쁜 것은 아닙니다. 문제는 대개 기본값에서 생깁니다 — 빨리 동작하게 하려고 느슨하게 열어 둔 설정이 그대로 공개되는 경우입니다. 사람이 짠 코드도 같은 실수를 하며, 다만 바이브 코딩은 동작하는 화면까지 훨씬 빨리 도달하기 때문에 확인 없이 공개될 확률이 높아집니다.
동작은 잘 되는데 안전한지 어떻게 아나요
이 둘은 눈으로 구분되지 않습니다. 화면이 잘 돌아도 데이터가 열려 있을 수 있고, 반대로 안전해도 화면은 똑같아 보입니다. 그래서 감이 아니라 목록으로 확인해야 하며, 위 여섯 항목이 그 최소한입니다.
이미 공개했는데 열쇠가 들어 있었다면 어떻게 하나요
해당 열쇠를 폐기하고 새로 발급받는 것이 먼저입니다. 코드에서 지우는 것만으로는 부족합니다 — 저장소의 기록에 남아 있고, 공개된 순간 이미 수집되었다고 보는 편이 안전하기 때문입니다. 그다음 새 열쇠를 금고에 넣고, 그동안 이상한 사용량이 없었는지 확인하십시오.
병원 홈페이지도 공격 대상이 되나요
규모와 무관하게 대상이 됩니다. 대부분의 시도는 사람이 노려서가 아니라 자동 프로그램이 인터넷 전체를 훑다가 열린 곳을 찾아내는 방식이기 때문입니다. 작아서 안전한 것이 아니라, 열려 있지 않아서 안전한 것입니다.
개인정보를 받는데 따로 해야 할 일이 있나요
예약과 문의를 받는 순간 환자의 개인정보를 다루게 되므로 처리방침을 두고 수집 항목과 보관 기간을 밝히는 등의 의무가 따라옵니다. 이 페이지는 법률 자문이 아니며, 병원 홈페이지에서 지켜야 할 표기와 절차는 별도 문서에서 다룹니다.
공개 전에 함께 점검해 보시려면
교육에서는 환경 설정과 실습에 더해 게시 전 점검까지 함께 봅니다. 위 여섯 항목을 참가자의 실제 환경에서 하나씩 확인하는 것이 마지막 순서입니다.
교육 과정 보기