모델이 똑똑해질수록, 새는 구멍도 넓어진다
지난 5회에서는 규모별로 자동화 예산을 어떻게 짜야 하는지 이야기했습니다. 견적이 정리된 다음 결재자 자리에서 가장 자주 되돌아오는 질문은 정해져 있습니다. "그래서 이거 붙이면, 우리 회사 데이터는 안전한가요?" 5회의 규모별 견적 가이드가 재무 이슈였다면, 6회는 그 견적을 통과시키기 위한 마지막 게이트, 보안과 거버넌스 이야기입니다.
정확히 말하면 문제는 "LLM이 위험하다"가 아닙니다. 자동화 워크플로우에 LLM 노드 하나가 들어가는 순간, 지금까지 사내 시스템 안쪽에 갇혀 있던 데이터가 외부 API로 흘러 나가고, 판단 하나가 사람 손을 거치지 않은 채 결재·발송·업로드로 이어진다는 사실입니다. 이 구조가 만드는 새로운 리스크 4가지를 짚고, 결재자가 최소한 확인해야 할 체크포인트를 정리합니다.
왜 2026년에 이 이야기가 급해졌나
세 가지 흐름이 겹쳤습니다. 첫째, 한국의 AI 기본법이 본격 적용 단계에 들어갔습니다. 둘째, OWASP가 발표한 LLM 애플리케이션 위협 순위에서 "민감정보 노출"이 6위에서 2위로 뛰어올랐습니다. 프롬프트 인젝션으로 대화 로그에서 개인정보를 뽑아내는 공격 사례가 그만큼 늘었다는 뜻입니다. 셋째, 자동화 도구가 SaaS 기반이 되면서, 실무자가 워크플로우 하나 붙일 때 마다 데이터 유출 경로가 하나씩 늘어나는 구조가 됐습니다.
솔직히 처음 자동화를 도입하는 회사에서 이 세 가지를 다 챙기는 경우는 드뭅니다. 오히려 흔한 패턴은 이렇습니다. 총무팀 담당자가 워크플로우 도구에서 챗봇 하나를 만들고, 고객 문의 데이터를 그대로 OpenAI API로 넘긴 뒤, 며칠 지나 법무팀이 "이거 개인정보 처리 위탁 계약 없이 나간 데이터인데요?"라고 물으면서 프로젝트 전체가 멈춥니다. 기술적 사고보다 이런 조직적 사고가 훨씬 자주 일어납니다.
PII 마스킹 — 데이터가 모델에 닿기 전에
첫 방어선은 아주 단순합니다. 개인정보(PII, Personally Identifiable Information)를 모델에 넘기지 않는 것입니다. 주민등록번호, 카드번호, 전화번호, 이메일, 이름 — 이 다섯 개만 자동으로 걸러도 사고의 절반은 예방됩니다.
구현은 크게 두 가지 층에서 이뤄집니다. 프롬프트가 모델로 나가기 직전 정규식 기반 필터로 대체 문자열([MASKED_PHONE], [MASKED_NAME])로 치환하는 게 1차, 응답이 돌아온 뒤 원본 값으로 복원하는 게 2차입니다. 이 왕복 구조가 있으면 로그·벡터 DB·프롬프트 캐시 어디에도 원본 PII가 남지 않습니다.
정규식으로 잡히지 않는 이름 같은 항목은 별도의 소형 NER 모델이나 LLM Gateway 상용 서비스(예: Presidio, OpenGuardrails)를 앞단에 두는 방식이 표준으로 자리 잡고 있습니다. 100% 완벽하지는 않지만, "모든 요청을 사람이 리뷰"라는 비현실적인 대안보다는 훨씬 지속 가능합니다.
감사 로그 — 사고 뒤에 무엇을 재현할 수 있는가
거버넌스에서 가장 뒤늦게 챙기는 부분이 감사 로그(audit log)입니다. 자동화 실행 하나에 대해 다음 4가지가 남아 있어야 합니다: 언제(timestamp), 누가 트리거(user or system), 어떤 프롬프트가 나갔고(input, PII 마스킹 후), 어떤 응답이 왔으며(output), 결과로 어떤 외부 시스템이 호출됐는가(tool_calls).
업무 자동화 관점에서 이 로그가 중요한 이유는 두 가지입니다. 하나는 오류 원인 추적입니다. 자동으로 발송된 견적 이메일에 잘못된 금액이 들어갔을 때, 로그가 없으면 "모델이 이상해서 그랬다"는 말밖에 못합니다. 다른 하나는 감사 대응입니다. 규제 기관이나 고객사 보안 감사에서 "작년 3월 어느 고객의 데이터를 어떤 프로세스가 처리했는가"를 30분 안에 답할 수 있어야 합니다.
실무 팁 하나. 감사 로그는 자동화 워크플로우 도구 자체가 저장하는 실행 이력과는 별개로, 앱 레벨의 이벤트 스트림(예: 별도 로그 테이블 또는 관측성 도구)에 이중으로 남겨두는 것이 안전합니다. SaaS 벤더가 로그를 30일만 보관하는 경우, 규제 대응 기간과 어긋납니다.
출력 가드레일 — JSON 스키마 검증과 재시도
모델 응답이 자유 텍스트인 채로 다음 노드로 흘러가면, 워크플로우 어느 지점에서 반드시 깨집니다. 그래서 출력 가드레일의 첫 번째 원칙은 이렇게 요약됩니다. "자유 텍스트를 절대 신뢰하지 말 것, 스키마로 검증할 것."
실무에서 가장 많이 쓰이는 패턴은 JSON 스키마 강제입니다. 요청 시 응답 포맷을 JSON으로 지정하고, 받은 응답을 스키마 검증기(예: Pydantic, Zod, Guardrails AI)에 통과시킨 뒤, 검증에 실패하면 오류 메시지를 다시 프롬프트에 붙여 재시도합니다. 이 재시도 패턴을 도입해 두면, 실무에서 8% 정도 나오는 포맷 오류가 대체로 1~2회 재시도 안에 정상으로 수렴됩니다.
다만 재시도에는 함정이 하나 있습니다. 모든 실패를 재시도하면 안 됩니다. 포맷 오류·API 일시 오류는 재시도 대상이지만, 비즈니스 규칙 위반(예: 승인 한도 초과 금액)은 재시도가 아니라 사람에게 에스컬레이션해야 합니다. 여기를 구분해 두지 않으면 모델이 세 번 시도한 끝에 "어쨌든 통과되는 답"을 내놓는 방향으로 학습된 것처럼 행동합니다.
결재자가 확인할 5개 체크포인트
기술 상세로 들어가면 끝이 없지만, 결재자·CIO 관점에서는 이 5가지만 팀에 물어보면 충분합니다. "이 자동화 워크플로우는—" ①어떤 개인정보가 어디로 나가고, 어떻게 마스킹됩니까? ②모든 실행에 대한 감사 로그가 몇 달치 남아 있습니까? ③응답 형식은 어떻게 검증되고, 실패 시 어떻게 처리됩니까? ④사람이 반드시 개입해야 하는 지점(휴먼 인 더 루프)은 어디입니까? ⑤외부 LLM 벤더와의 데이터 처리 위탁 계약은 체결됐습니까?
이 다섯 개 답이 준비되지 않은 자동화는, 규모와 관계없이 아직 프로덕션에 올릴 준비가 되지 않은 상태입니다. 반대로 이 다섯 개가 명확하면, 나머지 세부 구현은 팀이 알아서 채워 넣을 수 있습니다.
오늘의 액션 아이템
- PII 카테고리 5개부터 시작: 주민번호·카드번호·전화·이메일·이름을 마스킹 대상으로 지정하고, 이번 주 안에 워크플로우 앞단에 정규식 필터를 붙여봅니다.
- 감사 로그 최소 스키마: timestamp·trigger·input(masked)·output·tool_calls 5개 필드로 로그 테이블 하나를 만듭니다. 완벽함보다 존재가 먼저입니다.
- JSON 스키마 강제 도입: 자유 텍스트로 다음 노드에 넘기는 지점을 1개 찾아, Pydantic이나 Zod로 검증 계층을 넣습니다.
- 휴먼 인 더 루프 지점 명시: 자동으로 완결되는 흐름 중 "금액·계약·발송" 관련 노드는 승인 게이트를 하나 두고 넘어가게 합니다.
- 보안 설계 리뷰 요청: 3자 검토가 필요하다면 보안 설계 리뷰를 요청하실 수 있습니다. 도입 전 리스크 매트릭스를 함께 정리해 드립니다.
이 시리즈의 다음 7회에서는 "자동화 프로젝트 실패 5대 패턴과 회피 체크리스트"를 다룹니다. 오늘 짚은 거버넌스가 부재한 상태로 도입을 밀어붙였을 때 어떤 장면이 벌어지는지, 실제 실무에서 자주 관측되는 패턴 5가지를 정리할 예정입니다.
자주 묻는 질문
PII 마스킹을 하면 모델 응답 품질이 떨어지지 않나요?
단순 대체 문자열([MASKED_NAME]) 방식은 대화의 자연스러움을 일부 해칩니다. 다만 응답을 사용자에게 보여주기 전에 원본 값으로 다시 복원하는 후처리 단계를 두면, 최종 사용자 관점에서는 품질 차이가 거의 느껴지지 않습니다. 오히려 "모델이 이름을 잘못 기억해서 다르게 부르는" 사고를 예방하는 부가 효과가 있습니다.
감사 로그를 어디에 저장하는 것이 가장 안전합니까?
자동화 워크플로우 도구 내부 실행 이력 + 별도 로그 저장소(관측성 도구 또는 자체 DB) 이중 저장을 권장합니다. SaaS 벤더가 서비스를 종료하거나 로그 보관 정책을 바꿔도 감사 대응이 가능하도록 하는 최소 안전장치입니다. 저장 위치 자체는 국내 리전 또는 계약상 명확한 관할권을 가진 리전이면 충분합니다.
소규모 팀에서 이 모든 것을 다 챙기려면 부담이 큽니다. 어디부터 시작해야 합니까?
PII 마스킹 → 감사 로그 → 스키마 검증 순서를 권장합니다. 마스킹은 하루면 붙일 수 있고, 로그는 이틀, 스키마 검증은 대상 노드 수에 따라 며칠 걸립니다. 완벽한 거버넌스보다 "사고가 났을 때 원인을 추적하고, 재발을 막을 수 있는가"라는 최소 기준을 먼저 통과하는 것이 실용적입니다.