🧑🏻💻 Ep.18 | AI가 짠 코드, 보안은 누가 책임지나
그 주는 화요일부터 결제 버그로 시끄러웠습니다. 수요일엔 그 버그를 핫픽스하다가, 마침 손볼 일이 있던 로그인 API를 AI한테 새로 짜달라고 했어요. 깔끔하게 나왔고 돌려보니 잘 동작했습니다. 그대로 PR을 올리려다 코드를 한 번 더 훑었는데, 비밀번호를 평문으로 그냥 비교하고 있더군요.
시키면 바로 고쳐줍니다. 그런데 곰곰이 생각하니 좀 아찔했어요. 버그 하나 잡으러 들어갔다가 더 큰 구멍을 발견한 셈이니까요. 제가 그걸 알아챘으니 고친 거지, 못 봤으면 그대로 운영에 올라갔을 테고요.
AI가 짠 코드는 "동작하는가"는 잘 통과합니다. "안전한가"는 사람이 봐야 통과합니다.
1. 동작하는 코드와 안전한 코드
AI가 "그럴듯하게 틀린다"는 건 이 시리즈에서 여러 번 이야기했는데, 보안에서는 이게 한층 더 고약하게 작동합니다. 보안 결함은 대부분 평소엔 멀쩡하게 동작하거든요.
SQL 인젝션에 뚫리는 쿼리도 정상 입력에는 잘 돕니다. 권한 체크가 빠진 API도 정상 사용자한테는 문제가 없죠. 토큰이 로그에 찍히는 코드도 기능은 완벽합니다. 테스트도 통과하고 데모도 잘 됩니다. 그래서 공격자가 찾기 전까지는 아무도 모릅니다. "동작한다"는 보안의 증거가 못 됩니다.
2. AI가 자주 비우는 자리들
AI가 짠 코드를 리뷰하다 보면, 비슷한 자리에서 반복적으로 구멍이 보입니다.
☑️ 자주 비는 곳
✔️ 입력 검증: 사용자 입력을 그대로 쿼리·명령에 넣는 코드
✔️ 권한 체크: "로그인했는가"만 보고 "이 데이터의 주인인가"는 안 봄
✔️ 비밀 관리: API 키나 토큰을 코드·로그에 그대로 노출
✔️ 에러 메시지: 내부 구조나 스택 트레이스를 사용자에게 그대로 노출
AI가 멍청해서가 아닙니다. "안전하게 짜줘"라고 명시하지 않으면, AI는 가장 간단히 동작하는 코드를 기본값으로 내놓습니다. 명시하지 않으면 스스로 깨닫지 못하는 거죠. 사실 이건 신입에게 자주 하는 피드백이기도 합니다.
3. 빨라진 만큼 빨리 퍼진다
예전엔 취약한 코드를 한 명이 한 줄씩 짰습니다. 지금은 AI가 비슷한 패턴을 여러 곳에 빠르게 복제합니다.
같은 인증 로직을 다섯 개 서비스에 붙여넣었는데 그 원본에 권한 체크가 빠져 있었다면, 구멍 하나가 순식간에 다섯 개가 됩니다. 속도가 빨라졌다는 건 좋은 패턴도 나쁜 패턴도 똑같이 빨리 퍼진다는 뜻이에요.
그래서 "한 번 제대로 검토한 안전한 템플릿"의 가치가 더 커졌습니다. 틀린 걸 복제하기 전에, 맞는 걸 먼저 자리 잡게 해야 합니다.
4. AI를 보안 리뷰어로도 쓰기
조금 아이러니하지만, AI가 만든 보안 구멍을 찾는 데 AI가 꽤 쓸모 있습니다. 단, 시키는 방식이 달라야 해요.
"이 코드 괜찮아?"라고 물으면 "네 잘 짜셨네요"라고 합니다. AI는 칭찬에 후하고 반박을 잘 안 하거든요. 그래서 공격자의 입장을 시킵니다.
☑️ "이 코드를 공격한다면 어디를 노리겠어? OWASP Top 10 기준으로 짚어줘."
"이 입력으로 인젝션이 가능한 경로를 찾아줘", "권한 우회가 가능한 시나리오를 만들어줘", "로그에 새어나갈 수 있는 민감 정보가 있어?" 같은 식이죠. AI는 점검 항목을 빠르게 훑어줍니다. 다만 이건 어디까지나 1차 필터고, 최종 책임은 사람에게 있습니다.
5. 자동화된 안전장치를 깔아둔다.
사람 눈은 피곤하면 놓칩니다. 그러니 보안을 사람의 주의력에만 기대면 안 돼요. 파이프라인에 자동 점검을 깔아두는 게 핵심입니다.
✔️ 시크릿이 커밋에 들어가면 막는 스캐너
✔️ 의존성 취약점을 자동으로 잡는 검사
✔️ 정적 분석(SAST)으로 흔한 패턴을 걸러내기
AI가 코드를 더 빨리 만들수록, 그 코드를 자동으로 검사하는 장치도 같이 있어야 균형이 맞습니다. 사람이 매번 보는 대신 시스템이 항상 보게 만드는 거죠. 어차피 AI에게 도구를 쥐여주는 이야기의 연장이기도 합니다.
6. “AI가 짠 건데요”는 변명이 안 된다
이 시리즈의 첫 글에서 했던 이야기를 다시 합니다. 이번엔 좀 더 무겁게요.
내가 리뷰했고 내가 머지했다면 그건 내 코드입니다. 보안 사고가 터졌을 때 "AI가 그렇게 짰어요"는 책임을 덜어주지 않습니다. 오히려 책임이 더 또렷해졌어요. AI가 빠르게 짜준 만큼, 그걸 검토하고 통과시킨 사람의 판단이 사실상 유일한 안전장치니까요.
7. 보안은 기능이 아니라 기본값이다
가장 좋은 건, 보안을 나중에 점검하는 게 아니라 처음부터 기본값으로 두는 것입니다.
팀의 규칙 파일(
CLAUDE.md)에 "입력은 항상 검증한다", "비밀은 코드에 두지 않는다" 같은 원칙을 박아두고, 안전한 코드 예시를 레퍼런스로 함께 두면 됩니다. 그러면 AI가 내놓는 기본값 자체가 안전해집니다."빠르게 짜줘"라고만 하면 빠른 코드가 나옵니다. "우리 보안 원칙대로 짜줘"라고 하면 안전한 코드가 기본이 됩니다. 그 원칙을 정의하는 일은, 도구가 아무리 발전해도 사람의 몫입니다.
🌱 안전하게 만드는 법을 함께 고민하는 곳, 루퍼스
빠르게 만드는 것만큼 안전하게 만드는 것도 실력입니다. 루퍼스에서는 시큐어 코딩, 인증·인가 설계, 운영 보안 같은 주제를 현업의 경험으로 나눕니다
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article