결과 예시
아직 실제 결과를 확인하지 않았습니다. 확인 후 예시가 채워집니다.
왜 이렇게 쓰는가
보안 점검 체크리스트를 AI에게 그냥 부탁하면 대개 교과서 목차가 돌아옵니다. 스무 개 남짓한 항목 중 절반은 우리가 쓰지도 않는 기능에 대한 것이고, 정작 이번 배포에서 위험한 자리는 빠져 있습니다. 목록을 다 읽고 나서 "그래서 뭘 확인하지" 가 남습니다.
역할 을 "작은 팀의 배포를 검토해 온 담당자" 로 둔 이유는 분량 때문입니다. 대기업 보안 감사자의 관점으로 답하면 조직 정책과 문서 요구가 앞에 오는데, 사람이 서넛인 팀에서는 손댈 수 없는 항목입니다. 지킬 수 없는 목록은 한 번 훑고 덮게 되니, 처음부터 지킬 수 있는 선에서 뽑는 편이 낫습니다.
목록을 곧바로 뽑지 않고, 공격 경로를 세우는 일과 점검 항목을 만드는 일로 나눠 시킨 것이 핵심입니다. 경로를 먼저 적게 하면 로그인 방식, 파일 업로드 여부, 관리자 페이지 노출처럼 우리 구성에서만 생기는 자리가 드러나고, 뒤이어 나오는 항목이 거기에 붙습니다. 순서를 뒤집으면 일반 목록에 우리 이름만 붙은 결과가 나옵니다.
출력 형식 의 "확인 방법" 열이 목록을 실제 작업으로 바꿉니다. "입력값을 검증한다" 같은 문장은 읽고 나면 할 일이 남지 않지만, 어디를 열어 무엇을 보라고 적혀 있으면 그대로 따라 할 수 있습니다. 마지막 스스로 점검 문단은 첫 단계에서 습관처럼 딸려 나온 항목을 걸러 내는 장치입니다. 다만 ChatGPT로 만든 웹 보안 점검 목록은 어디까지나 출발점이라, 개인정보나 결제를 다룬다면 전문가 확인이 따로 필요합니다.
용어가 낯설면 아하AI에서: role-prompting, output-format
나쁜 예와 비교
웹서비스 배포 전에 확인해야 할 보안 체크리스트 알려줘
어디서나 볼 수 있는 일반 목록이 나옵니다. 우리가 쓰지 않는 기능에 대한 항목을 확인하느라 시간을 쓰고, 자체 구현한 로그인이나 관리자 페이지처럼 이번 서비스에서 가장 위험한 자리는 그냥 지나갑니다. 항목마다 "무엇을 어떻게 확인하는지" 가 없어 팀에 나눠 줄 수도 없고, 결국 아는 사람 한 명이 감으로 훑고 배포하게 됩니다.
변형
이미 배포한 서비스를 점검할 때
이미 운영 중인 {{서비스 종류}} 를 뒤늦게 점검하려 합니다. 만든 방식은 {{기술 스택}} 이고 다루는 정보는 {{다루는 데이터}} 입니다. 서비스를 멈추지 않고 확인할 수 있는 항목과, 점검 시간을 잡아야 하는 항목을 나눠 주세요. 각 항목에 문제가 발견됐을 때 임시로 막을 방법을 한 줄씩 덧붙여 주세요.
운영 중에는 확인 순서가 달라집니다. 서비스를 세우지 않고 볼 수 있는 것부터 처리하면 점검을 미루지 않게 됩니다.
코드 리뷰에서 볼 곳만 뽑을 때
{{기술 스택}} 으로 만든 코드에서 보안 문제가 자주 나는 자리를 리뷰용 목록으로 만들어 주세요. 파일이나 함수 종류별로 묶고, "이런 코드가 보이면 의심하라" 는 형태의 짧은 문장으로 적어 주세요. 항목은 10개 이내로 하고, {{다루는 데이터}} 를 다루는 부분에 해당하는 항목은 앞에 배치해 주세요.
배포 직전이 아니라 코드를 읽는 동안 쓰는 목록입니다. 팀의 리뷰 규칙에 그대로 붙여 넣을 수 있습니다.
모델별 주의
여기서 받은 목록은 스스로 확인할 출발점이지 보안 진단서가 아닙니다. 개인정보나 결제를 다룬다면 전문가 점검을 따로 받으세요
관련 프롬프트
마지막 수정 2026-09-02 · 잘못된 점이 있나요? 알려 주세요