AI가 짜준 코드는 돌아가는 것과 안전한 것이 완전히 다릅니다. 로그인 화면이 있다고 인증이 제대로 된 것도 아니고, 잘 열린다고 남이 못 들어오는 것도 아닙니다. 개인 프로젝트라도 인터넷에 올리는 순간 자동 스캐너가 훑고 지나갑니다. 배포 전에 반드시 확인해야 할 보안 항목 10가지와, 이미 키를 올려버렸을 때의 대처법을 정리했습니다.
1. 왜 AI가 만든 코드에 구멍이 생길까
이유는 단순합니다. 우리가 "동작하게 해줘"라고 요청했기 때문입니다. 요청하지 않은 방어 코드는 기본적으로 들어가지 않습니다.
여기에 인터넷에 널린 예제 코드의 관행이 겹칩니다. 예제는 설명이 목적이라 키를 코드에 그대로 적고, 접근 제한을 전부 열어두는 경우가 많습니다. 학습에는 좋지만 그대로 배포하면 곤란합니다.
2. 배포 전 체크리스트 ① ~ ⑤
① 비밀값을 코드에 직접 쓰지 않는다.
API 키, 데이터베이스 비밀번호, 토큰은 .env 같은 환경변수 파일로 분리합니다. 코드에는 이름만 남고 값은 남지 않아야 합니다.
② .gitignore에 .env가 들어 있는지 확인한다.
분리해 놓고도 실수로 함께 커밋되는 사고가 가장 흔합니다. 첫 커밋 전에 무엇이 올라가는지 목록으로 확인하세요.
③ '인증'과 '인가'는 다른 문제다.
로그인했다는 사실만으로 남의 데이터에 접근할 권한이 생기지는 않습니다. 데이터를 꺼낼 때마다 서버에서 "이 사람이 이 데이터의 주인이 맞는가"를 확인해야 합니다.
④ 입력값 검증은 반드시 서버에서 한다.
화면에서 하는 검증은 사용자 편의를 위한 것일 뿐입니다. 브라우저를 거치지 않고 요청을 보낼 수 있으므로
서버에서 다시 검사하지 않으면 검증이 없는 것과 같습니다.
⑤ 데이터베이스 질의문을 문자열로 이어붙이지 않는다.
사용자 입력을 쿼리에 그대로 붙이면 데이터 전체가 노출될 수 있습니다. 반드시 파라미터 바인딩 방식을 쓰세요.
3. 배포 전 체크리스트 ⑥ ~ ⑩
⑥ 비밀번호는 해시로 저장한다.
평문 저장은 물론이고 되돌릴 수 있는 암호화도 안 됩니다. 비밀번호 전용 해시 함수를 쓰고, 직접 구현하지 말고 검증된 라이브러리를 쓰세요.
⑦ 에러 메시지에 내부 정보를 담지 않는다.
사용자 화면에 오류 상세 내용이나 파일 경로가 그대로 나오면 공격에 필요한 정보를 주는 셈입니다. 화면에는 간단한 안내만, 자세한 내용은 서버 로그에 남깁니다.
⑧ 접근 허용 범위를 넓게 열어두지 않는다.
개발할 때 편하다고 모든 출처를 허용해 두고 그대로 배포하는 경우가 많습니다. 관리자 기능이 있다면 주소만 모르면 안전하다는 생각도 버려야 합니다.
⑨ 요청 횟수 제한을 건다.
로그인 시도, 인증번호 발송, 파일 업로드처럼 반복되면 곤란한 기능에는 시간당 횟수 제한이 필요합니다. 없으면 비밀번호를 무한정 대입해 볼 수 있습니다.
⑩ 라이브러리를 최신으로 유지한다.
취약점은 대부분 이미 알려져 있고 패치도 나와 있습니다. 이름이 비슷한 출처 불명 패키지를 잘못 설치하지 않았는지도 함께 확인하세요.
4. 이미 키를 올려버렸다면
가장 많이 하는 착각이 "파일에서 지웠으니 괜찮다"입니다. 깃은 변경 이력을 전부 보관하므로,
파일에서 지워도 과거 기록을 열면 키가 그대로 보입니다.
유일하게 확실한 해결책은 해당 키를 즉시 폐기하고 새로 발급받는 것입니다. 기록 정리는 그다음 문제입니다. 특히 결제나 클라우드 자원이 연결된 키라면 요금이 발생하기 전에 폐기하는 속도가 가장 중요합니다.
⚠️ 주의 공개 저장소에 올라간 키는 사람이 발견하기 전에 자동 수집 프로그램이 먼저 찾아냅니다. "아무도 안 볼 텐데"라는 가정은 성립하지 않습니다.
5. 우선순위를 매긴다면
열 가지를 한 번에 다 하기 부담스럽다면, 사고가 났을 때 피해가 큰 순서로 처리하면 됩니다.
| 1순위 | 비밀값 분리·깃 제외 (①②) | 요금 폭탄, 계정 탈취 |
| 2순위 | 인가 확인·입력값 검증 (③④) | 다른 사용자 데이터 유출 |
| 3순위 | 비밀번호 해시·질의문 처리 (⑤⑥) | 계정 정보 통째 유출 |
| 4순위 | 나머지 (⑦~⑩) | 공격 난이도가 낮아짐 |
개인 프로젝트라면 1순위와 2순위만 지켜도 실질적인 위험 대부분이 사라집니다. 반대로 이 둘을 빼놓고 나머지를 아무리 해도 의미가 없습니다.
6. 클로드에게 점검을 시키는 방법
"보안 검토해줘"라고만 하면 원론적인 답이 돌아옵니다. 확인할 항목을 직접 주고 하나씩 답하게 하는 편이 훨씬 정확합니다.
예를 들어 "위 10개 항목을 기준으로 이 프로젝트를 점검하고, 항목별로 통과·미흡·해당없음으로 판정한 뒤 미흡한 것만 파일 위치와 함께 알려줘"처럼 요청하면 결과를 검증하기도 쉽습니다.
다만 점검 결과를 그대로 믿지는 마세요. 최소한 ①②번(비밀값 분리와 깃 제외 여부)만큼은 직접 눈으로 확인하는 것을 권합니다.
자주 묻는 질문 (FAQ)
Q. 저만 쓰는 개인 프로젝트인데도 필요한가요?
A. 인터넷에 공개되는 순간 주소를 몰라도 자동 스캐너가 찾아냅니다. 특히 클라우드 API 키가 유출되면 요금이 그대로 청구되므로, 규모와 무관하게 비밀값 관리는 반드시 지켜야 합니다.
Q. 보안 기능을 처음부터 다 넣으면 개발이 느려지지 않나요?
A. 10가지 중 대부분은 나중에 넣으면 오히려 더 오래 걸립니다. 특히 인가 확인과 입력값 검증은 구조에 얽혀 있어, 뒤늦게 넣으면 여러 파일을 동시에 고쳐야 합니다.