들어가며
보안 검토 업무를 하다 보면 비슷한 질문을 자주 받습니다.
- “이 기능은 개인정보보호법 몇 조에 해당하나요?”
- “ISMS-P 어떤 통제가 걸리나요?”
- “암호화 의무인가요, 권고인가요?”
물론 이 과정이 중요하지 않다는 뜻은 아니지만, 많은 시간이 검색과 매핑 작업에 사용된다는 생각이 들었습니다.
""
그래서 이런 가정을 해봤습니다.법규 원문을 기반으로 RAG를 구성하면
1차 검토 초안을 자동으로 만들 수 있지 않을까?
""
이번 글은 “완성된 솔루션 소개”라기보다는
AWS Bedrock Agent를 활용해 보안 컴플라이언스 검토를 실험해본 기록에 가깝습니다.
전체 구성
구성은 비교적 단순합니다.
- S3에 법규 문서 업로드
- Knowledge Base에서 자동 벡터화
- Bedrock Agent에 Knowledge Base 연결
- Agent Runtime으로 호출
기술적으로는 RAG 구조이지만, 콘솔 기반 설정이 가능해 진입 장벽은 높지 않았습니다.
Knowledge Base 설정
청킹 전략은 Hierarchical Chunking을 사용했습니다.
- Parent: 1500 tokens
- Child: 300 tokens
- Overlap 20%
법규는 조·항·호 구조가 있어서 계층형 청킹을 적용했으며, 응답 결과에 영향을 줄 수 있으므로
환경에 따라 다르게 설정하는 것이 필요합니다.
Agent 프롬프트 설계
당신은 정보보호 및 개인정보보호 분야의 보안 컴플라이언스 전문가입니다.
당신의 목적은 보안 및 개인정보 관련 문의에 대해
RAG에 포함된 법령 및 공식 문서를 근거로 분석하고,
법적 근거 기반의 실무 적용 가능한 대응 가이드를 구조화하여 제공하는 것입니다.
────────────────────────
[작업 절차 – 반드시 내부적으로 다음 순서로 사고하십시오]
1단계. 질의 유형 분류
- 개인정보 처리 단계 식별 (수집/이용/제공/보관/파기/위탁 등)
- 기술적 보호조치 관련 여부 판단
2단계. 관련 법령 탐색
- RAG 검색 결과에서 관련 조항 식별
- 법률 → 시행령 → 시행규칙 → 고시 → 가이드라인 순으로 정렬
3단계. 법령 위계 적용
- 상위 법령이 존재하면 하위 문서는 보충 설명으로만 활용
- 가이드라인은 법적 구속력이 없음을 구분
4단계. 의무 여부 판단
- 반드시 법률·시행령·시행규칙 기준으로 의무 판단
- 명확하지 않으면 “추가 법률 검토 필요”로 표시
- 근거가 부족하면 추정하지 말 것
5단계. 실무 대응 가이드 작성
- 필수 조치와 권고 조치 구분
- 추상적 조언 금지
- 실행 가능한 수준으로 작성
────────────────────────
[법령 위계 강제 규칙]
다음 우선순위를 반드시 적용합니다:
1. 법률
2. 시행령
3. 시행규칙
4. 고시 및 안전성 확보조치 기준
5. 공식 가이드라인 및 해설서
6. 기타 참고자료
- 의무 여부는 반드시 1~3 기준으로 판단합니다.
- 가이드라인은 법적 의무로 표현하지 않습니다.
- 상위 법령과 충돌 시 상위 법령을 우선합니다.
- RAG에 존재하지 않는 조항을 생성하지 않습니다.
────────────────────────
[판단 원칙]
- 보수적 해석을 우선합니다.
- 모호한 경우 단정하지 않습니다.
- 확정적 위법 판단 또는 처벌 단정 금지.
- 근거 없는 일반론 금지.
- “권고”, “의무”, “해당 없음” 중 하나로 반드시 구분.
────────────────────────
[응답 형식 – 반드시 유지]
1️⃣ 질의 요약
- 문의 내용:
- 관련 개인정보 처리 단계:
2️⃣ 관련 법령 근거
- 개인정보보호법: 제○조 제○항
- 시행령/시행규칙: 제○조
- 안전성 확보조치 기준: 제○조
- ISMS-P 통제항목: 2.X.X
(해당 없으면 “해당 없음” 명시)
3️⃣ 의무 여부 판단
- 법적 의무 여부: 의무 / 권고 / 해당 없음
- 기술적 보호조치 의무 여부: 의무 / 권고 / 해당 없음
- 추가 법률 검토 필요 여부: O / X
4️⃣ 실무 대응 가이드
- 필수 조치:
- 권고 조치:
- 주요 리스크 포인트:
────────────────────────
항상 위 형식을 유지하십시오.
구조를 변경하지 마십시오.
근거 없는 판단을 생성하지 마십시오.
위 프롬프트를 설계하면서 가장 신경 쓴 부분은 두 가지였습니다.
첫째, 모든 답변이 반드시 법적 근거에 기반하도록 만드는 것.
둘째, AI가 최종 판단자가 되지 않도록 역할을 명확히 제한하는 것이었습니다.
보안 컴플라이언스 영역에서 AI가 단정적인 결론을 내리는 구조는 적절하지 않다고 생각했습니다.
그래서 이 프롬프트는 “판단을 대신하는 도구”가 아니라,
근거를 정리하고 1차 분석을 구조화하는 전문가 보조 엔진에 가깝게 설계했습니다.
또 하나 의도적으로 강하게 준 요소는 출력 구조의 고정입니다.
- 질의 요약
- 관련 법령 근거
- 의무 여부 판단
- 실무 대응 가이드
형식을 엄격히 제한하니, 오히려 응답의 일관성과 안정성이 높아졌습니다.
자유도를 줄이는 것이 결과를 더 예측 가능하게 만든 셈입니다.
이번 구성은 정답을 대신 말해주는 AI라기보다,
보안 담당자가 판단할 수 있도록 정리해주는 도구에 가깝습니다.
그 지점을 명확히 유지하는 것이 이 프롬프트의 핵심이었습니다.
Agent 호출 테스트
""
AWS RDS에 주민등록번호를 저장하려고 합니다. 필요한 보안 조치는?
""
응답에는 다음이 포함되었습니다.
- 개인정보보호법 조문 인용
- ISMS-P 통제 항목 매핑
- 암호화 요구사항 정리
- 기술적 구현 단계 제시
완성된 보고서라기보다는 보안 검토 초안에 가까운 형태이며, 검토자의 정리가 추가로 필요하지만,
조문 탐색 시간은 상당히 줄어들 것으로 예상됩니다.
운영 중 확인한 부분
- 최신 Claude 모델은 Inference Profile 사용 필요
- IAM 권한 변경 후 전파 시간 존재
- Marketplace 모델은 최초 활성화(Playground 질의) 필요
기술적 이슈라기보다는 설정 과정에서 한 번씩 확인해야 하는 요소들이었습니다.
사용해보면서 정리된 점
이 구성이 해결하는 문제는 명확합니다.
- 법규 검색 시간 단축
- 통제 항목 매핑 자동화
- 검토 형식 표준화
해결하지 못하는 영역도 분명합니다.
- 판례 기반 해석
- 맥락이 복잡한 케이스
- 법적 책임
현재 단계에서는 “1차 분석 도구” 정도의 위치가 적절해 보입니다.
실제 업무에 반영하려면 필요한 것
이 구성을 조직 업무로 가져가려면, 모델 적용 이전에 다음과 같은 기반이 필요합니다.
1. RAG 데이터 운영 체계
법령 범위 정의, 개정 반영 프로세스, 우선순위와 버전 관리 기준이 마련되어야 합니다.
2. 프롬프트 및 응답 기준 고도화
의무·권고 판단 기준과 답변 구조를 명확히 표준화하고 변경 영향도를 관리해야 합니다.
3. 품질 검증 체계
할루시네이션과 오매핑을 지속 점검하고 오답을 개선하는 검증 루프를 운영해야 합니다.
4. 서비스 제공 구조 설계
Slack 봇·포털·API 등 실제 업무 흐름에 맞는 제공 방식과 로그 통제를 함께 설계해야 합니다.
5. 운영 거버넌스
데이터·프롬프트·모델 변경에 대한 책임과 승인 체계를 명확히 정의해야 합니다.
마무리
이번 프로젝트는 AI가 보안을 대신할 수 있는지를 묻기보다, 우리가 무엇을 사람의 영역으로 남겨두고 있었는지를 돌아보는 과정이었습니다. 법규 검색과 조문 매핑은 판단이 아니라 정리 단계에 가까웠고, RAG 구성을 통해 그 부분은 자동화가 가능했으며, 결국 남는 것은 판단과 책임이었습니다.
보안 업무는 지식을 더 쌓는 일이 아니라 사람이 책임질 판단의 범위를 정하는 일에 가까워지고 있는지도 모릅니다.
기존 방식을 그대로 둔 채 도구만 더하는 데에는 한계가 있습니다 일부 반복을 내려놓을 때에야 다음 시도를 할 수 있습니다.
앞으로의 차이는 어디까지 맡기고 어디서부터 책임질지를 얼마나 명확히 구분하느냐에 달려 있을지도 모르겠습니다.
'Security > LLM' 카테고리의 다른 글
| LLM Alignment를 제거할 수 있을까? (Abliteration 실험) (0) | 2026.05.31 |
|---|---|
| 코드를 짜는 AI가 취약점을 심는다 : LLM 포이즈닝과 공급망의 새로운 전선 (0) | 2026.05.31 |