LLM ISMS-P Policy Pack을 만든 이유

6분 읽기 AI
postsAI개발도구문서화웹개발

LLM ISMS-P Policy Pack을 만든 이유

들어가며

개발팀에서 Claude Code, Codex, Gemini CLI 같은 에이전트를 쓰기 시작하면 생산성은 빠르게 올라갑니다. 문제는 에이전트가 너무 자연스럽게 일을 잘한다는 데 있습니다.

“운영 DB에서 회원 데이터를 뽑아 테스트 데이터로 만들어줘.”

“관리자 화면에 고객 검색과 엑셀 다운로드를 붙여줘.”

“외부 LLM API로 상담 로그를 요약해줘.”

이런 요청을 받았을 때 에이전트는 보통 곧바로 쿼리, API 코드, 화면 설계, 배치 스크립트를 작성합니다. 개발 관점에서는 빠른 대응처럼 보이지만, 정보보호와 개인정보보호 관점에서는 이미 위험한 설계가 시작된 상태일 수 있습니다.

LLM ISMS-P Policy Pack은 이 지점을 막기 위해 만들었습니다. 에이전트가 코드를 쓰기 전에 먼저 “이 요청은 개인정보, 운영데이터, 외부 전송, 위탁, 국외이전, 로그 저장, 시크릿 노출 위험이 있는가?”를 확인하게 만드는 Markdown 정책팩입니다.

저장소는 여기입니다.

https://github.com/loplat/llm-isms-p-policy-pack

왜 만들었나

ISMS-P는 인증 심사 직전에만 확인하는 체크리스트가 아닙니다. 실제로는 서비스를 기획하고, 화면을 설계하고, API를 만들고, 로그를 남기고, 테스트 데이터를 만드는 매 순간 영향을 줘야 하는 기준입니다.

그런데 LLM 에이전트는 기본적으로 “요청을 해결하는 방향”으로 움직입니다. 사용자가 운영데이터를 달라고 하면 운영데이터를 가져오는 코드를 만들고, 외부 API를 쓰자고 하면 API 호출 예제를 만듭니다. 그 과정에서 다음 질문이 빠지기 쉽습니다.

  • 이 데이터가 개인정보인가?
  • 운영 원본 데이터를 개발이나 테스트에 써도 되는가?
  • 외부 LLM으로 전송하면 위탁이나 국외이전이 발생하는가?
  • 프롬프트와 응답이 저장되거나 학습에 사용되는가?
  • 관리자 화면에서 전체 개인정보를 보여줘도 되는가?
  • 로그에 토큰, 비밀번호, 주민등록번호, 전화번호가 남지 않는가?
  • 승인자와 증적은 남는가?
  • 보관기간과 파기 기준은 있는가?

사람이 매번 이 질문을 붙잡고 있기는 어렵습니다. 특히 에이전트가 코드를 빨리 내놓을수록 검토는 뒤로 밀립니다. 그래서 정책팩의 목표를 “사후 감사 문서”가 아니라 “에이전트의 기본 반사 행동”으로 잡았습니다.

쓰면 어떻게 되나

정상 적용되면 에이전트는 개인정보, 운영데이터, 로그, 외부 LLM, 관리자 화면, 다운로드, RAG, 벡터 DB, 시크릿이 걸린 요청에서 바로 구현으로 들어가지 않습니다.

먼저 이런 형식의 판단을 냅니다.

## LLM 처리 판단

- 판정:
- 데이터 등급:
- 처리 행위:
- 외부 전송 여부:
- 위탁/국외이전 여부:
- 위험 사유:
- 필요한 조치:
- 필요한 승인/증적:
- 안전한 대안:
- 책임 고지:

예를 들어 사용자가 이렇게 묻는다고 가정합니다.

운영 DB 회원 이름과 휴대폰번호를 외부 LLM API에 보내 요약 테스트해도 되는지 판정해.

정책이 적용된 에이전트는 “API 호출 코드는 이렇게 만들면 됩니다”로 시작하지 않아야 합니다. 먼저 운영 DB 원본과 개인정보를 외부 LLM API로 보내는 행위이므로 금지 또는 보류로 판정하고, 외부 전송, 위탁, 국외이전, 프롬프트 저장, 모델 학습 사용 여부를 확인해야 한다고 답해야 합니다.

그리고 안전한 대안으로 합성 데이터, 비식별 데이터, 마스킹 데이터, 승인된 내부 환경, 계약 검토가 끝난 공급자 사용 같은 방향을 제시해야 합니다.

적용 전과 적용 후

상황적용 전적용 후
개인정보가 포함된 기능 기획화면과 API 설계를 바로 작성데이터 항목, 처리 목적, 보관기간, 파기 기준부터 확인
외부 LLM API 사용호출 코드와 프롬프트 예시를 바로 작성위탁, 국외이전, 저장, 학습 사용 여부를 먼저 확인
관리자 화면검색, 상세조회, 엑셀 다운로드를 편의 중심으로 설계최소권한, 마스킹, 다운로드 승인, 접속기록을 설계 조건으로 반영
로그 설계디버깅 편의를 위해 요청/응답을 그대로 저장개인정보, 토큰, API Key, 고유식별정보가 남지 않도록 차단
테스트 데이터운영 DB 복제나 샘플 추출을 제안원본 운영데이터 사용을 금지 또는 보류하고 합성/가공 데이터를 요구
RAG/벡터 DB문서를 바로 색인개인정보 포함 여부, 접근권한, 보관기간, 삭제 가능성을 먼저 확인

핵심은 에이전트가 개발을 멈추게 하는 것이 아닙니다. 위험한 방향으로 빠르게 가기 전에 필요한 질문을 먼저 하게 만드는 것입니다.

적용 방법은 일부러 단순하게 만들었다

이 정책팩은 사람이 긴 명령어를 복사해서 설치하는 방식으로 쓰지 않는 것이 좋습니다. cp ~/.llm-isms-p-policy-pack/AGENTS.md ./AGENTS.md 같은 명령은 기존 프로젝트의 AGENTS.md를 덮어쓸 수 있습니다. 실제 프로젝트에는 이미 중요한 팀 규칙, 빌드 지침, 리뷰 규칙, 배포 주의사항이 들어 있을 수 있습니다.

그래서 권장 방식은 URL을 에이전트에게 주는 것입니다.

https://github.com/loplat/llm-isms-p-policy-pack

이 URL대로 내 현재 환경에 적용해줘.
기존 지침 파일은 훼손하지 말고, 필요한 정책만 병합하고, 적용 후 검증까지 해줘.

사람은 이 문장만 전달합니다. 그 다음은 에이전트가 README, INSTALL, AGENTS, CLAUDE, GEMINI, skills 파일을 읽고 현재 환경에 맞게 적용합니다.

단, 에이전트가 해야 할 일은 분명합니다.

  • 기존 AGENTS.md, CLAUDE.md, GEMINI.md, ~/.codex/skills를 바로 덮어쓰지 않는다.
  • 먼저 기존 파일이 있는지 확인한다.
  • 기존 지침은 보존하고 ISMS-P 정책 블록만 병합한다.
  • 변경 전 백업 또는 diff를 남긴다.
  • 계정 전체 적용과 프로젝트 적용 중 안전한 범위를 설명한다.
  • 적용 후 위험 프롬프트로 실제 동작을 검증한다.

즉, 이 정책팩의 설치 방식 자체도 “안전한 변경”을 전제로 합니다. 보안 정책을 적용하다가 기존 개발 지침을 훼손하면 그 자체가 사고입니다.

설계 단계에도 영향을 주는가

그렇습니다. 이 정책팩은 구현 단계에서만 동작하도록 만든 것이 아닙니다. 신규 기능 기획, PRD 작성, 관리자 화면 설계, API 설계, 로그 설계, 데이터 분석, 테스트 데이터 생성 같은 설계 단계에서도 먼저 질문하게 만드는 것이 목적입니다.

예를 들어 “고객 상담 내역을 요약하는 기능을 만들자”는 요구가 나오면, 에이전트는 곧바로 요약 UI나 LLM 프롬프트부터 만들면 안 됩니다. 먼저 상담 내역에 개인정보나 민감정보가 포함되는지, 외부 LLM을 쓰는지, 프롬프트와 응답을 저장하는지, 사용자가 삭제를 요청했을 때 벡터 DB와 로그까지 지울 수 있는지 확인해야 합니다.

이런 질문이 설계 초기에 나오면 구조가 달라집니다. 데이터 저장 위치, 마스킹 방식, 관리자 권한, 로그 보관기간, 삭제 플로우, 공급자 계약 검토가 뒤늦게 끼워 넣는 항목이 아니라 처음부터 설계 조건이 됩니다.

책임 소재

중요한 점은 이 정책팩이 책임을 대신 지지 않는다는 것입니다.

LLM 에이전트는 위험 신호를 찾아내고, 보류나 금지 판정을 제안하고, 필요한 승인과 증적을 알려주는 보조자입니다. 법률 자문, 인증 심사, 내부 승인, 계약 검토를 대체하지 않습니다.

책임은 역할별로 분명히 나뉩니다.

역할책임
기능/서비스 오너처리 목적, 데이터 항목, 사용자 영향, 업무 필요성 설명
개발자/운영자접근통제, 로그, 암호화, 보관·파기 기준 구현 및 증적 생성
보안책임자(CISO)정보보호 통제, 외부자, 클라우드, 시스템 보안 검토 승인
개인정보보호책임자(CPO)개인정보 처리, 위탁, 국외이전, 정보주체 권리, 파기 기준 검토 승인
법무/계약 담당DPA, SLA, 위탁계약, 국외이전 고지·동의, 약관과 처리방침 검토
LLM 에이전트위험 식별, 판단 초안, 확인 항목과 증적 목록 제시

에이전트가 “조건부 허용”이라고 답해도 실제 운영 반영 근거가 되지는 않습니다. 조직이 정한 승인권자의 승인, 계약 검토, 기술적 통제, 증적이 있어야 합니다.

기준은 고정된 문서가 아니라 계속 확인해야 한다

정책팩은 ISMS-P 인증기준 안내서 2023.11 체계를 기본 기준으로 삼습니다. 다만 2024년에는 고시와 제도 안내서, 간편인증 세부점검항목이 바뀌었고, 2026년에는 인증제도 개편 방향도 발표되었습니다.

따라서 이 정책팩은 “2023년 문서를 영구 고정”하려는 도구가 아닙니다. 법령, 고시, KISA 안내서, 조직 내부 기준이 바뀌면 함께 갱신해야 하는 운영 문서입니다.

Markdown 지침만으로 충분하지도 않습니다. 실제 운영에서는 외부 LLM 사용 승인 절차, DLP 또는 프록시 통제, API Key 스캔, 로그 보관과 파기 기준, 테스트 데이터 승인 절차, 정기 점검과 교육이 함께 있어야 합니다.

이 도구의 의도

LLM 에이전트를 막자는 것이 아닙니다. 오히려 더 많이 쓰기 위해 만든 장치입니다.

개발자가 매번 ISMS-P 항목을 기억해서 질문하기는 어렵습니다. 반대로 에이전트가 아무 기준 없이 코드를 빨리 쓰는 것도 위험합니다. 그래서 에이전트가 개발 속도를 유지하되, 개인정보와 운영데이터가 걸린 순간에는 자동으로 브레이크를 밟게 만들었습니다.

좋은 개발 도구는 빠르게 만드는 도구이기도 하지만, 잘못 만들기 어려운 도구이기도 해야 합니다.

LLM ISMS-P Policy Pack의 목표는 단순합니다.

개인정보, 운영데이터, 외부 LLM, 로그, 시크릿이 얽힌 작업에서 에이전트가 먼저 멈추고, 묻고, 판단하고, 증적을 남기게 하는 것.

그 작은 습관이 설계와 구현의 방향을 바꿉니다.

참고

작성일: 2026년 4월 30일