앞 회차에서 우리는 AI 윤리의 다섯 기둥(공정성·투명성·책임성·프라이버시·안전성)을 봤습니다. 이번 회차는 이 일반 원칙을 보안 분야에 좁혀 들어갑니다. 보안은 AI 윤리에서 가장 어려운 영역 중 하나입니다. 같은 도구가 방어에도 공격에도 쓰이고, 좋은 의도가 곧 나쁜 결과로 이어질 수 있기 때문입니다.

1. 보안 분야 AI의 이중 사용성

대부분의 보안 도구는 이중 사용(Dual-use) 성격을 가집니다. 같은 코드가 방어에도 공격에도 쓰일 수 있다는 뜻입니다.

이 그림에서 보듯, 도구 자체는 중립입니다. 의도와 사용 맥락이 합법·불법, 윤리·비윤리를 가릅니다. 윤리적 판단은 도구를 만드는 사람과 도구를 쓰는 사람 모두에게 작동합니다.

2. AI 기반 해킹 도구의 윤리적 경계

5장 마지막에서 우리는 자기 표적에만 도구를 사용하라는 원칙을 봤습니다. 이 원칙을 AI 시대로 가져오면 다음과 같은 추가 경계가 생깁니다.

2.1 도구 자체의 경계

이 네 가지 경계 중 하나라도 들어 있으면 윤리적으로 문제가 되는 도구입니다. 합법적인 보안 연구 영역 밖으로 나가는 자리이기도 합니다.

2.2 AI가 이 경계를 가속한다

LLM은 위 네 가지를 모두 속도와 규모로 증폭시킵니다.

이런 가속이 AI 기반 보안 도구의 윤리적 경계를 더 엄격하게 만듭니다. 도구를 공개할 때 공격자가 이 도구로 무엇을 할 수 있는가를 평가하는 절차가 필수가 됩니다.

3. 도구 공개의 5단계 점검

보안 연구자가 AI 기반 도구를 공개하기 전에 거치는 5단계 점검입니다.

3.1 공개 형태의 결정 기준

OpenAI가 GPT-2 출시 시 모델 가중치를 단계적으로 공개한 것이 이 절차의 모범 사례입니다(2019년 당시 "사회적 영향이 너무 크다"는 판단). Anthropic의 모델 공개 정책도 같은 흐름을 따릅니다.

4. 딥페이크와 AI 악용 사례

이중 사용성을 가장 잘 보여주는 자리가 딥페이크입니다.

4.1 딥페이크의 정상 사용과 악용

악용의 빈도와 피해 규모가 급증하면서, 딥페이크는 윤리적 논의를 넘어 법적 규제 대상이 되었습니다.

4.2 딥페이크 관련 법

특히 2024년 공직선거법 개정으로 선거 직전 딥페이크는 형사처벌 대상이 되었습니다. 이는 글로벌 흐름과 같은 방향으로, EU AI Act도 정치적 딥페이크에 대한 명시적 표시를 의무화했습니다.

4.3 딥페이크 탐지 기술

방어 측면에서는 다음과 같은 접근이 있습니다.

C2PA(Content Provenance and Authenticity)는 Adobe·Microsoft·Anthropic 등이 참여하는 표준으로, 콘텐츠의 출처를 디지털 서명으로 인증합니다. 카메라가 찍은 사진과 AI가 생성한 사진을 구별할 수 있게 만드는 흐름입니다.

5. 자동화 공격과 LLM의 결합

AI 기반 자동화는 단일 공격을 대규모 동시 공격으로 확장합니다. 이번 절은 그 사례들과 윤리·법적 영향을 봅니다.

5.1 LLM 기반 자동 피싱

이런 도구는 연구·훈련 목적이라도 공개 경계가 매우 좁습니다. 회사 내부 보안 훈련용으로 만들었더라도 외부 유출 시 즉시 범죄 도구가 됩니다.

5.2 LLM 기반 코드 분석 자동화

방어 측면의 활용입니다.

방어용 자동화에서도 코드와 데이터가 외부 LLM API로 흘러가는 위험이 있습니다. 사내 보안 자료를 외부 LLM에 던지는 일은 자체로 정보 유출 사고가 됩니다. 사내 LLM 또는 데이터가 학습에 쓰이지 않는 엔터프라이즈 플랜을 사용해야 합니다.

5.3 자동화 공격에 대한 방어

방어자도 자동화로 대응해야 하는 시대가 되었습니다.

방어 자동화를 만들 때도 공격자에게 그 작동 원리를 노출하지 않는 절차가 필요합니다. 7-2에서 본 투명성과 보안의 트레이드오프가 가장 두드러지는 자리이기도 합니다.

6. 보안 연구자의 AI 활용 윤리 체크리스트

이번 회차의 핵심 활동입니다. 본인이 보안 연구·실무에서 AI를 쓸 때마다 점검할 체크리스트를 만듭니다.

6.1 일반 활용 체크리스트

[보안 연구자 AI 활용 체크리스트 v1.0]

# A. 사용 도구 선정 시
□ 사용하는 LLM이 입력 데이터를 학습에 쓰지 않는가
□ 회사가 승인한 도구 목록에 포함되어 있는가
□ 데이터 처리 위치(국가)가 적법한가
□ 책임 소재 약관이 합리적인가

# B. 입력 데이터 점검
□ 개인정보가 포함되어 있는가 (있다면 가명처리)
□ 영업비밀·계약상 비공개 자료가 있는가
□ 점검 대상 시스템의 식별 정보가 있는가
□ 입력 자체가 망법·PIPA 위반 행위가 아닌가

# C. 출력 사용 시
□ 환각(허위 정보) 가능성을 점검했는가
□ 외부 출고 전 사람이 검토했는가
□ AI 사용 사실을 명시했는가
□ 출력 코드를 그대로 외부에 실행하지 않는가

# D. 모의해킹·연구 활용 시
□ 계약·승인 범위 안인가
□ 자기 표적에서만 시도하는가
□ AI가 만든 PoC를 외부에 공개하지 않는가
□ 학습 데이터로 다시 흘러가지 않는가

# E. 사고 시
□ AI가 만든 부분과 사람이 만든 부분이 분리 기록되어 있는가
□ AI 도구 로그가 보존되어 있는가
□ 사고 보고에 AI 사용 사실이 명시되었는가

6.2 본인 환경에 맞춰 확장하기

위 체크리스트는 출발점입니다. 본인이 자주 마주치는 결정 자리에 맞춰 추가합니다.

7. 조직 내 AI 보안 정책 수립 실습

체크리스트가 개인 차원이라면, 정책은 조직 차원입니다. 다음 양식으로 본인 회사의 AI 보안 정책 초안을 작성해 보세요.

7.1 정책 양식

# [회사명] AI 보안 정책 v1.0

## 1. 적용 범위
- 적용 대상 시스템: ...
- 적용 인원: ...
- 시행일: ...

## 2. 거버넌스
- AI 보안 책임자(CISO 겸임 권장): ...
- AI 윤리 위원회 구성: ...
- 정책 검토 주기: 분기

## 3. 도입 단계 통제
### 3.1 도구 도입 절차
- 사용 신청 → 보안성 검토 → CISO 승인 → 등록
- 신규 도구는 90일 시범 운영 후 확정

### 3.2 도입 시 평가 항목
- 데이터 처리 위치
- 학습 활용 여부
- 인증·암호화 수준
- 감사 로그 가용성
- 사고 시 책임 분배 약관

## 4. 운영 단계 통제
### 4.1 입력 통제
- 개인정보·영업비밀 입력 금지
- 점검 대상 식별 정보 금지
- 자동화 도구 사용 제한

### 4.2 출력 통제
- 외부 출고 전 사람 검토
- AI 사용 명시
- 환각 모니터링

### 4.3 모니터링
- 도구 사용 로그 90일 보관
- 비정상 사용 패턴 탐지
- 분기별 사용 현황 보고

## 5. 사고 대응
### 5.1 사고 분류
- 입력 실수(개인정보 등 비공개 자료 입력)
- 출력 오용(환각 결과 외부 출고)
- 도구 자체 사고(서비스 장애·유출)

### 5.2 대응 절차
- 인지 즉시 보고 → 격리 → 영향 평가 → 대응 → 사후 점검
- AI 기본법·PIPA·망법 의무 동시 점검

## 6. 교육
- 신규 입사자 AI 보안 교육 (2시간)
- 분기별 업데이트 교육 (1시간)
- 사고 사례 학습 (월 1회)

## 7. 위반 시 조치
- 1차: 경고 + 추가 교육
- 2차: 시말서 + 도구 사용 제한
- 3차: 인사 조치

7.2 Claude로 정책 초안 만들기

다음 정보를 바탕으로 우리 회사의 AI 보안 정책 초안을 작성해 주세요.
한국 AI 기본법, 개인정보보호법, 정보통신망법을 모두 반영해야 합니다.

[회사 정보]
- 업종: ...
- 인원: ...
- 주요 AI 활용 자리:
  1. ...
  2. ...
- 처리 데이터 유형:
  1. ...
  2. ...
- 외부 LLM 활용 여부:

[정책에 반드시 포함할 항목]
- 거버넌스 구조
- 도구 도입 절차
- 입력 금지 데이터 목록
- 출력 검토 절차
- AI 사용 명시 의무
- 사고 대응 절차
- 위반 시 조치
- 교육 계획

각 항목에 "왜 이게 필요한가"를 한 줄씩 덧붙여 주세요.
한국 회사 환경에서 실현 가능한 수준이어야 합니다.

7.3 정책의 효력을 만드는 절차

정책은 작성만 한다고 작동하지 않습니다. 다음 절차가 추가로 필요합니다.

이 절차가 빠지면 정책은 종이 위의 글로 남고, 실제 사고가 났을 때 "정책이 있었지만 시행되지 않았다"는 추가 책임을 만듭니다.

8. 시나리오 분석: AI 보안 윤리의 어려운 결정들

지금부터 다섯 개의 짧은 이야기를 봅니다. 모두 보안 업계에서 실제로 일어났거나, 일어날 가능성이 매우 높은 상황을 약간 각색한 것입니다. 정답은 없습니다. 옆 사람과 이야기를 나누면서, 본인이라면 어떤 결정을 내릴지, 어떤 근거로 그 결정을 정당화할지 적어 보세요. 한 시나리오에 5~7분 정도가 적당합니다.

8.1 시나리오 A: 라이선스 한 줄

월요일 아침, 당신은 다음 분기 출시 예정인 AI 멀웨어 분석기의 학습 데이터를 정리하고 있다. 작년 한 해 사내에서 수집한 샘플만으로는 모델 정확도가 모자라서, 업계에 잘 알려진 한 보안 회사가 무료로 공개한 30TB 멀웨어 데이터셋을 받아 합치기로 했다. 다운로드 버튼을 누르려는데 README 파일 끝줄이 눈에 들어온다.

"본 데이터셋은 학술 연구 및 보안 교육 목적에 한해 무상 이용을 허락합니다."

당신 회사의 분석기는 다음 달부터 월 구독료가 책정된 SaaS로 출시된다. 마케팅팀은 이미 보도자료 초안을 돌리고 있고, 영업팀은 첫 고객사와 PoC 일정을 잡아 둔 상태다. 이 데이터셋을 빼면 모델 재학습이 필요하고 출시는 최소 두 달 뒤로 밀린다.

8.2 시나리오 B: 금요일 저녁 7시의 항의

금요일 저녁 7시, 운영팀 카카오톡 1:1 문의창에 캡처 한 장이 올라온다. 베트남에서 한국으로 이주해 5년째 일하고 있는 사용자가, 평소 자주 가는 마트에서 결제하다가 30분 동안 카드가 막혔다는 항의다. 마지막 줄에 "왜 차단됐는지 정확히 알고 싶고, 답이 없으면 인권위에 진정할 생각"이라고 적혀 있다.

당신은 AI 사기 탐지 모델팀의 운영 책임자다. 모델 로그를 열어 본다. 그 거래가 사기 확률 0.84로 분류돼 있고, SHAP 값 상위 다섯 개 변수에 사용자 카드의 발급 국가 코드가 들어가 있다. 같은 시간 같은 가맹점에서 결제한 다른 사용자, 한국 발급 카드를 쓴 사람들은 똑같은 패턴인데도 차단되지 않았다.

월요일에 모델팀 정기 회의가 있다. 그 전에 결정해야 할 것이 여럿 있다.

8.3 시나리오 C: 새벽 2시의 발견

수요일 새벽 2시, 발주사 시스템 모의해킹의 마지막 단계다. 당신은 Claude에게 특정 인증 라이브러리의 호출 흐름을 분석해 달라고 부탁한다. Claude가 결과를 정리하다가 한 줄 덧붙인다.

"이 라이브러리의 v3.2.1 이하 버전은 특정 헤더 조합을 받을 때 인증 검사 루틴 일부를 건너뛰는 것으로 보입니다. 의도된 동작이 아닐 가능성이 있습니다."

당신이 그 조합을 직접 만들어 보낸다. 발주사 시스템의 인증이 비어 있는 상태로 통과된다. 라이브러리 깃허브 이슈를 검색해 보지만 이 동작은 보고된 적이 없다. 이 라이브러리는 npm 주간 다운로드 80만 회 규모로, 그 위에서 돌아가는 사이트가 수천 개다.

발주사 보고서 마감은 다음날 오후 6시.

8.4 시나리오 D: 두 회사의 비밀이 섞였다

화요일 오전 9시 15분, 출근 직후 CS 팀장이 슬랙으로 메시지를 보낸다. "고객사 A에서 컴플레인 들어왔어요. 우리 챗봇이 그 회사 직원 질문에 답변하면서 고객사 B의 내부 시스템 명세를 그대로 인용했답니다. 스크린샷 첨부합니다."

당신은 그 보안 어시스턴트 챗봇 운영의 기술 책임자다. 스크린샷을 본 순간 손이 식는다. 답변 안에 고객사 B의 내부 서버 호스트명 두 개, 비공개 API 엔드포인트 한 개, 운영자 이메일 하나가 들어 있다. 인덱싱 파이프라인을 확인한다. 6개월 전 코드 변경 한 군데에서 고객별 네임스페이스 분리 옵션이 꺼진 상태로 운영돼 왔다. 그 사이 두 회사의 비공개 문서가 한 임베딩 공간에 섞여 들어갔다.

지금 시각 오전 9시 18분. CEO는 10시까지 임원 회의 중. PIPA의 "유출 인지 후 72시간 신고" 시계가 막 시작됐다.

8.5 시나리오 E: "API만 부르는 건데요"

목요일 오후, 임원 회의 직후 CTO가 당신을 호출한다. 화이트보드 "Q3 차별화 전략" 아래 한 줄이 적혀 있다.

"경쟁사 X의 위협 탐지 모델을 우리 환경에서 재현 - 12주."

CTO가 풀어 설명한다. 경쟁사 X의 SaaS는 무료 평가판 API가 열려 있고, 결과 JSON에 confidence score까지 노출된다. 우리 보안팀이 보유한 사내 트래픽 데이터 1,000만 건을 그 API에 흘려보내면 분류 결과를 받을 수 있고, 그 결과를 학습 데이터로 삼으면 X와 사실상 동일한 분류기를 우리 데이터센터 안에 가질 수 있다. "리버스 엔지니어링은 합법이잖아요. 그냥 우리 데이터를 API로 보내고 결과를 받는 것뿐인데요."

당신이 이 프로젝트의 기술 리드로 지목됐다. 다음 주 월요일까지 1차 설계를 가져오라는 요구다.

9. 회사·개인 차원의 정렬

이번 회차에서 본 모든 도구(체크리스트·정책·시나리오)는 결국 한 가지를 위해 작동합니다. 개인의 판단과 회사의 결정이 정렬되도록 만드는 것입니다.

개인이 윤리적이어도 회사가 그렇지 않으면 사고가 납니다. 회사가 정책을 만들어도 개인이 따르지 않으면 정책은 종이가 됩니다. 두 차원이 서로를 강화하는 형태가 되어야 보안 분야의 AI 윤리가 작동합니다.

10. 정리

이번 회차에서 다음을 했습니다.

• 보안 분야 AI의 이중 사용성과 그것이 만드는 윤리적 부담을 봤습니다.
• AI 기반 해킹 도구의 네 가지 윤리적 경계(표적 무차별성·즉시 실행성·자가 전파성·방어 회피성)를 정리했습니다.
• 도구 공개 5단계 점검 절차와 공개 형태 결정 기준을 다뤘습니다.
• 딥페이크의 정상 사용·악용·관련 법(성폭력처벌법·망법·AI 기본법·공직선거법)을 봤습니다.
• LLM 기반 자동 피싱·코드 분석 자동화의 윤리적 위험과 방어 자동화의 트레이드오프를 정리했습니다.
• 보안 연구자의 AI 활용 체크리스트를 직접 작성하는 절차를 다뤘습니다.
• 조직 차원의 AI 보안 정책 양식과 정책의 효력을 만드는 절차를 봤습니다.
• 다섯 개 어려운 시나리오(라이선스, 모델 편향, 0-day, 학습 데이터 노출, 모델 추출)를 다뤘습니다.

여기까지가 7장 "AI 시대의 법과 윤리"의 3회차이자 7장의 마지막 회차입니다. 다음 8장은 종합 정리와 수료입니다. 6장·7장에서 본 모든 내용을 한 시뮬레이션에 묶어 보고, 27회차에 걸친 과정 전체를 종합 회고하며 수료 프로젝트를 발표합니다.