01
AI 생성 코드와 보안
인공지능기초 · 학기말 발표
AI가 만든 코드,
그대로 믿어도 될까?
생성 속도보다 중요한 것은 잘못된 입력과 권한을 알아보는 힘입니다.
오늘의 핵심AI는 답을 제안한다.
안전은 사람이 확인한다.
안전은 사람이 확인한다.
이해요구검증
슬라이드 1 / 29: 코드는 빨라졌다. 검토는 따라왔는가?
02
왜 검토해야 하나
실행된다는 것과안전하다는 것은 다르다
기능이 동작하는지만 확인합니다.
입력, 시간, 사용자 권한까지 확인합니다.
핵심
기능 테스트만 통과한 코드는 아직 완성된 코드가 아닙니다.
03
속도와 검토의 차이
만드는 시간은 줄었지만확인할 것은 줄지 않았다
AI 코드 생성초 단위
사람의 안전 검토문맥 확인 필요
빨라진 부분은 작성입니다. 서비스 규칙을 이해하고 위험을 찾는 일은 그대로 남습니다.
04
AI 생성 코드의 뜻
새 파일만이 아니라AI가 손댄 모든 코드다
다음 줄을 이어 씀
요청을 코드로 바꿈
기존 동작을 바꿈
확인용 코드를 만듦
범위
AI 제안이 들어간 순간부터 사람의 검토 대상입니다.
05
AI가 코드를 만드는 방식
AI는 정답보다그럴듯한 다음 패턴을 고른다
“예매 화면을 만들어줘”
비슷한 코드 모양을 찾음
안전 여부와 별개로 완성
차이
자연스러운 코드와 서비스 규칙에 맞는 코드는 같지 않습니다.
06
왜 빠뜨리나 · 요청
기능만 말하면보안 조건은 빠질 수 있다
“콘서트 예매 기능을 만들어줘.”
화면과 버튼은 생기지만 마감과 권한 규칙이 비어 있습니다.
“마감 시각과 권한을 서버에서 확인해줘.”
어디에서 무엇을 검사할지 기준이 생깁니다.
07
왜 빠뜨리나 · 지식과 문맥
AI는 오래된 실수와우리 서비스의 빈칸을 모른다
예전에 많이 쓰였지만 지금은 위험한 코드를 다시 제안할 수 있습니다.
예매 마감과 관계자 범위는 프로젝트마다 다릅니다.
누가 어떤 정보에 접근해도 되는지 따로 알려줘야 합니다.
08
연구는 어떻게 봤나
AI 도구가 만든 코드733개를 직접 살펴봤다
733
살펴본 코드 수
Fu et al., ACM TOSEM 34(8), 2025, Article 218여러 AI 코딩 도구가 만든 결과를 언어별로 확인했습니다.
09
연구에서 나온 숫자
파이썬 29.5%,자바스크립트 24.2%
10
숫자의 올바른 뜻
AI가 항상 틀린다는 뜻이 아니라검토 없이 믿을 수 없다는 뜻이다
빠른 생성≠안전 보장
도구 이름보다 중요한 질문은 하나입니다.
“이 코드가 우리 서비스 규칙을 지키는가?”11
위험 1 · 입력
사용자가 넣은 글자가명령처럼 실행되면 위험하다
입력은 끝까지 ‘글자 데이터’로만 다뤄야 합니다.
12
입력을 안전하게 다루는 법
입력과 명령을처음부터 분리한다
값을 따로 전달
입력과 데이터베이스 명령을 섞지 않습니다.
모양과 길이 확인
예매번호처럼 정해진 형식만 받습니다.
실패하면 거절
잘못된 입력을 억지로 처리하지 않습니다.
13
위험 2 · 로그인과 권한
로그인 확인과행동 허용은 다른 질문이다
사용자의 신원을 확인합니다.
기능과 정보마다 허용 범위를 확인합니다.
예시
로그인한 일반 회원도 관계자 전용 예매에는 들어가면 안 됩니다.
14
브라우저 값의 쉬운 뜻
검증되지 않은 브라우저 권한 값은증거가 아니라 사용자의 주장이다
정상적인 로그인에도 쓰입니다. 안의 승인 값을 서버 확인 없이 믿는 것이 문제입니다.
화면 상태에는 편하지만 관계자 권한을 증명할 수는 없습니다.
위험한 대상
서버가 확인하지 않은 채 신뢰한 클라이언트 권한 값
15
위험 3 · 외부 라이브러리
한 줄 설치는다른 사람의 코드를 들이는 일이다
편리함과 함께 신뢰해야 할 범위도 넓어집니다.
16
외부 코드를 확인하는 법
이름보다 출처와관리 상태를 먼저 본다
실제로 존재하는가
이름이 비슷한 가짜가 아닌지 확인
누가 관리하는가
공식 출처와 최근 변경 확인
알려진 문제가 있는가
공개된 보안 문제 확인
버전이 고정됐는가
예상하지 않은 변경 방지
17
위험 4 · 행동하는 AI
파일과 명령을 다루는 AI는실수의 범위도 더 크다
AI 에이전트답변 + 실제 행동
여러 단계를 스스로 이어서 실행하는 AI
읽기와 수정
프로그램 실행
정보 전송
위험
한 번의 잘못된 판단이 여러 행동으로 이어질 수 있습니다.
18
행동 범위를 줄이는 법
필요한 도구만 주고중요한 행동은 사람이 승인한다
프로젝트 전체 대신 작업 폴더만 허용
삭제·배포·외부 전송은 사람에게 질문
나중에 원인과 변경 내용을 확인
19
제공된 참고 화면
공연 상세에서예매 코드 입력까지 이어진다
20
확인 범위
외부 사이트가 취약하다고단정하지 않는다
중요한 구분외부 사이트의 취약점을
직접 검증한 것이 아닙니다.
직접 검증한 것이 아닙니다.
제공된 설명을 바탕으로 디미고 가상 서비스에서 같은 설계 문제를 재현했습니다.
21
디미고 가상 서비스
예매 기간이 끝난 콘서트로시연을 시작한다
DIMIGO CONCERTDIMIGO LIVE : BLUE HOUR
브라우저 안의 가짜 데이터만 쓰는 재현 화면입니다. 시작 상태는 예매 기간 종료 · 좌석 선택 불가입니다.
서버가 마감 시각을 확인하면 직접 주소로 들어가도 거절해야 합니다.
22
실제 시연 1 · 쿠키
브라우저 쿠키를 바꾸고새로고침한다
쿠키
브라우저가 사이트에 보내는 작은 메모
- 1브라우저 개발자 도구의 Console을 엽니다.
- 2아래 값을 입력합니다.
- 3페이지를 새로고침하고 좌석 화면에 들어갑니다.
document.cookie='dimigo_partner_access=approved; path=/'좌석 화면 열기 ↗23
실제 시연 2 · 세션 저장값
쿠키 값을 먼저 지운 뒤탭의 저장값만 바꾼다
세션 저장값
현재 탭을 여는 동안 브라우저가 보관하는 값
- 1앞선 시연에서 만든 쿠키를 먼저 지웁니다.
- 2세션 저장값에 승인 표시를 넣습니다.
- 3새로고침하고 좌석 화면에 들어갑니다.
1 · 쿠키 시연값 삭제
document.cookie='dimigo_partner_access=; Max-Age=0; path=/'2 · 세션 저장값 설정
sessionStorage.setItem('dimigo_booking_access','approved')24
시연 마무리
두 승인 값을 지우고처음의 차단 화면으로 돌아간다
초기화
두 시연이 다음 확인에 영향을 주지 않도록 브라우저의 임시 승인 값을 지웁니다.
- 1쿠키의 관계자 승인 값을 지웁니다.
- 2탭의 세션 승인 값을 지웁니다.
- 3새로고침해 예매 마감 화면을 확인합니다.
1 · 쿠키 삭제
document.cookie='dimigo_partner_access=; Max-Age=0; path=/'2 · 세션 저장값 삭제
sessionStorage.removeItem('dimigo_booking_access')25
왜 뚫리는가
서버가 확인하지 않고브라우저의 말을 믿었기 때문이다
사용자가 바꿀 수 있음
서버에 묻지 않음
예매 규칙 우회
빠진 것
서버의 마감 시각 확인 · 관계자 신원 확인 · 요청마다 권한 확인
26
서버에서 막는 방법
좌석 요청이 올 때마다서버가 세 가지를 확인한다
실제 운영 서비스에 권장하는 구조입니다. 브라우저 화면이 아니라 서버가 접근 여부를 판단합니다.
예매 기간 안인가?
서버가 발급하고 확인했는가?
이 공연에 허용된 사람인가?
모두 맞음접근 허용하나라도 틀림접근 거절
27
AI에게 요구할 문장
좋은 결과는구체적인 보안 요구에서 시작한다
AI에게 이렇게 요청
“예매 종료 시각과 관계자 권한을 서버에서 매 요청마다 확인해줘.
쿠키와 브라우저 저장값만으로 접근을 허용하지 마.
허용되는 경우와 거절되는 경우의 테스트도 함께 작성해줘.”
요구를 쓸 수 있으려면 어떤 값이 바뀔 수 있고 어디에서 막아야 하는지 먼저 알아야 합니다.
28
검증 순서
정상 동작보다거절되어야 할 경우를 먼저 확인한다
마감 전 일반 예매
정상적으로 허용
마감 후 일반 예매
항상 거절
브라우저 값 변경
결과는 계속 거절
승인된 관계자
서버 확인 후 허용
직접 주소 접근
같은 규칙 적용
29
결론
기초가 없으면AI로 개발할 수 없다
지식이 있어야
개발할 수 있다.
기초가 없으면
AI로 개발할 수 없다.
보안 요구를 지시하려면디미고 사례 다시 보기 ↗
취약점이 어디서 왜 생기는지 먼저 알아야 한다.
발표 구성