AI에게 일자리를 빼앗길 불안으로부터 시작하는 하네스 작성 입문 제19회: 기밀 정보를 LLM에 전달하지 않는 하네스 설계
요약
AI 에이전트 사용 시 발생할 수 있는 기밀 정보 유출 리스크를 분석하고, 이를 방어하기 위한 AI 하네스 설계 방법을 소개합니다. 시스템 엔지니어링의 보안 원칙을 적용하여 입력 필터링과 데이터 마스킹 기술을 활용한 다층 방어 체계 구축을 제안합니다.
핵심 포인트
- AI 에이전트 워크플로우 내 기밀 정보 유출 경로 4가지 식별
- 시스템 엔지니어링의 정보 분류 및 다층 방어(Defense in Depth) 개념 적용
- 정규 표현식을 활용한 입력 필터링 및 데이터 마스킹 기법 활용
- 정보 중요도에 따른 로컬 LLM 활용 등 전략적 판단 필요
AI 에이전트를 업무에서 사용할 때, 가장 신경 쓰이는 리스크 중 하나가 기밀 정보의 유출입니다. 프롬프트(Prompt)에 고객 정보나 사내 비밀번호를 포함해 버리면, 그것이 외부의 API 서버로 전송될 가능성이 있습니다.
SE(System Engineer) 경험자라면, 이 문제에 대한 사고방식을 이미 가지고 있습니다. 정보 분류, 액세스 제어(Access Control), 데이터 마스킹(Data Masking)——이러한 보안 지식은 AI 하네스(Harness) 설계에 그대로 활용할 수 있습니다.
본 기사에서는 LLM에 기밀 정보를 전달하는 리스크를 체계적으로 정리하고, 하네스로 어떻게 방어할지를 보여줍니다.
AI 에이전트의 워크플로우(Workflow) 중에서, 기밀 정보가 LLM에 전달되는 경로는 주로 4가지가 있습니다.
| 경로 | 구체적인 예 | 리스크 레벨 |
|---|---|---|
| 프롬프트 직접 입력 | 사용자가 비밀번호를 붙여넣기 | 높음 |
| ... | ||
| 이 표에서 알 수 있듯이, 리스크는 '프롬프트'뿐만 아니라 RAG나 MCP 도구, 로그 등 여러 경로에 존재합니다. |
SE가 업무 시스템에서 수행하는 정보 분류의 사고방식을 AI 하네스에 적용합니다.
| 정보 레벨 | 설명 | AI 하네스에서의 취급 | 구체적인 예 |
|---|---|---|---|
| 기밀 | 유출 시 영향이 큼 | LLM에 전달해서는 안 됨 | 비밀번호, 비밀키, 개인정보 |
| ... | |||
| 이 분류는 기존 시스템의 '정보 보안 정책(Information Security Policy)'과 같은 사고방식입니다. |
다음은 AI 하네스에서의 기밀 정보 유출 리스크 목록입니다.
| # | 리스크 | 경로 | 영향도 | 발생 확률 | 대책 |
|---|---|---|---|---|---|
| 1 | 프롬프트에 비밀번호 포함 | 직접 입력 | 치명적 | 중간 | 입력 유효성 검사 (Input Validation) |
| ... | |||||
| 리스크 목록을 바탕으로, 하네스에 구축할 방어층을 설계합니다. SE의 '다층 방어 (Defense in Depth)' 사고방식을 그대로 적용합니다. |
| 방어층 | 대상 | 구현 방법 | SE 업무에서의 대응 |
|---|---|---|---|
| 입력 필터 | 프롬프트 | 정규 표현식으로 기밀 패턴을 검출 | 입력 유효성 검사 (Input Validation) |
| ... | |||
| 첫 번째 방어층으로서, 프롬프트에 기밀 정보가 포함되어 있지 않은지 체크하는 입력 필터를 설계합니다. |
검출해야 할 패턴의 예:
| 패턴 | 검출 방법 | 대응 |
|---|---|---|
| 이메일 주소 | 정규 표현식 | 마스킹 또는 경고 |
| ... | ||
| 마스킹(Masking)이란, 기밀 정보를 플레이스홀더(Placeholder)로 교체한 후 LLM에 전달하고, 응답 후에 복원하는 접근 방식입니다. |
마스킹의 흐름:
1. 입력: "다나카 타로 님의 API 키는 sk-abc123입니다"
2. 마스크: "{{NAME_1}} 님의 API 키는 {{API_KEY_1}}입니다"
...
| 정보 종류 | 마스킹 방법 | 복원 가능 여부 |
|---|---|---|
| 개인명 | 플레이스홀더 교체 | 가능 |
| ... | ||
| 기밀 정보의 레벨에 따라, LLM의 이용처를 구분하는 판단 기준을 제시합니다. |
| 정보 레벨 | 권장 LLM | 이유 |
|---|---|---|
| 기밀 | 로컬 LLM만 사용 | 데이터가 외부로 나가지 않음 |
| ... | ||
| 단, 로컬 LLM에는 품질이나 비용의 트레이드오프(Trade-off)가 있습니다. 정답은 하나가 아니며, 프로젝트의 요구사항에 따라 판단해 주십시오. |
구현 시 확인해야 할 체크포인트를 정리합니다.
| 체크 항목 | 확인 내용 | 대응 시기 |
|---|---|---|
| 프롬프트 필터 | 기밀 패턴 검출이 동작하는가 | 구현 시 |
| ... | ||
| 이 분야는 SE 경험자가 가장 강점을 발휘할 수 있는 영역 중 하나입니다. |
| SE의 보안 경험 | AI 하네스에서의 활용 |
|---|---|
| 입력 유효성 검사 (Input Validation) | 프롬프트 필터 설계 |
| ... | |
| 경우에 따라서는 품질이 저하될 가능성이 있습니다. 하지만 "다나카 타로"를 "{{NAME_1}}"로 교체하더라도, 많은 태스크(코드 리뷰, 설계 상담 등)에서는 품질에 미치는 영향이 제한적입니다. 보안과 품질의 트레이드오프를 태스크별로 판단해 주십시오. |
그렇습니다. 다층 방어의 사고방식과 마찬가지로, 단일 대책으로 100%를 목표로 하는 것이 아니라, 여러 층에서 리스크를 저감하는 접근 방식이 현실적입니다.
- 기밀 정보가 LLM에 전달되는 경로는 프롬프트 (Prompt) 뿐만 아니라, RAG · MCP · 로그 (Log)에도 존재
- 정보 분류 · 마스킹 (Masking) · 다층 방어는 SE (System Engineer)의 보안 지식을 직접 활용할 수 있음
- 리스크 목록표를 기반으로, 하네스 (Harness)의 각 계층에 방어책을 포함
- 100%의 안전은 없지만, 다층 방어로 리스크를 관리 가능한 수준으로 유지
제20회에서는 이번에 정리한 마스킹 (Masking)의 기본 설계를 **구체적인 구현 플로우 (Implementation Flow)**로 전환합니다.
구체적으로는 다음과 같은 내용을 다룹니다.
- 마스킹 · 복원 플로우 (Masking · Restoration Flow)의 상세 설계
- Python을 이용한 마스킹 유틸리티 (Masking Utility) 구현
- 마스킹 규칙 (Masking Rule) 설정 파일 설계
- 테스트 케이스 (Test Case) 작성
"리스크는 정리했지만, 실제로 코드로 어떻게 구현하는가?"라는 의문에 답하는 구현 회차입니다. 많은 기대 부탁드립니다.
연재: AI에게 일자리를 빼앗길 불안으로부터 시작하는 하네스 작성 입문
다음 회 (제20회): 프롬프트 투입 전의 마스킹 · 복원 플로우를 설계한다
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기