우리 업무로 옮기면 — 2,436건을 찾아낸 건 판단이 아니라 스캔이었습니다

이 코너는 바깥에서 실제로 돌아간 사례를 우리 업무로 옮겨 심습니다. 사례 소개로 끝내지 않습니다.

고르는 기준이 하나 있습니다. 성과 수치가 붙은 사례가 아니라, 과정이 공개된 사례를 고릅니다. “생산성 40% 향상” 같은 문장은 대개 도구를 파는 쪽이 쓴 것이고, 무엇보다 옮겨 심을 수가 없습니다. 뭘 어떻게 했는지가 없으니까요. 과정이 있어야 조각을 뜯어낼 수 있습니다.

1. 무슨 일이 있었나

지난주(8월 14일), AI 모델을 만드는 Z.ai가 새 모델 GLM-5.3을 공개하면서 모델을 만드는 동안 무엇을 했는지를 같이 밝혔습니다.

이 모델로 오픈소스 프로젝트 269개를 훑어 취약점 후보 2,436건을 뽑아냈고, 그중 1,097건이 심각·높음 등급으로 분류됐다고 적었습니다. 리눅스, WebKit, FreeBSD 같은 이름이 목록에 있었습니다.

비슷한 일이 나흘 전에도 있었습니다. 오픈AI가 보안 전용 모델로 크롬의 자바스크립트 엔진에서 알려지지 않은 취약점 두 건을 찾아냈고, 이건 구글이 실제로 패치했습니다(CVE-2026-15903). 이쪽은 외부에서 확인된 산출물이라 조금 더 단단한 근거입니다.

출처 등급을 밝힙니다. 위 숫자는 전부 각 회사가 자기 작업을 자기가 발표한 것이고 독립 검증은 없습니다. 다만 이 글이 쓰려는 건 숫자가 아니라 작업 구조입니다. 구조는 두 회사가 같은 주에 각각 공개했고, 크롬 패치 건은 제3자(구글)가 결과를 받아 처리했습니다.

2. 자동화된 건 도구가 아니라 일의 어느 조각인가

여기가 이 코너의 본체입니다. “AI가 취약점을 찾았다”는 문장을 그대로 받으면 옮길 게 없습니다. 한 겹 뜯어야 합니다.

점검하는 일은 대개 다섯 조각으로 나뉩니다.

사례를 옮길 때 보는 것은 어떤 도구를 썼느냐가 아니라, 일의 어느 조각이 떨어져 나갔느냐입니다. 시간 비율은 설명을 위한 예시입니다.

이번 사례에서 AI가 떼어 간 건 앞의 두 칸입니다.

전수 훑기 — 269개 프로젝트를 하나도 빠뜨리지 않고 다 연다
후보 추리기 — 그중 의심스러운 것만 2,436건으로 좁힌다

나머지 세 칸은 사람 자리로 남았습니다. 2,436건이 전부 진짜 취약점이라는 뜻이 아닙니다. 그중 무엇이 실제 위험인지 가리고(판단), 고치고(처리), 공개 여부와 시점을 정하는 일(책임)은 여전히 사람이 했습니다. 크롬 건도 구글의 보안팀이 받아서 확인하고 패치한 겁니다.

그리고 이게 핵심입니다. 떨어져 나간 두 칸이, 하필 사람이 시간을 가장 많이 쓰던 칸입니다. 269개를 다 열어 보는 일에는 사람이 못 버팁니다. 그래서 현실에서는 어떻게 하냐면 — 안 봅니다. 중요해 보이는 것 몇 개만 표본으로 보고 넘어갑니다.

그러니까 이 사례가 실제로 바꾼 건 속도가 아닙니다. 표본으로 보던 일을 전수로 볼 수 있게 된 것입니다.

3. 우리 회사 어디에 같은 조각이 있나

“전수로 훑어서 후보만 좁히는 일”은 보안에만 있는 게 아닙니다. 대부분의 조직에 이미 있는데, 대개 표본으로 하고 있습니다.

부서	지금 표본으로 하는 일	AI가 떼어 갈 두 칸
법무·구매	계약서 300건 중 몇 건만 열어 위험 조항 확인	전건에서 비표준 조항 후보 추리기
인사·총무	사내 규정·매뉴얼이 낡았는지 가끔 점검	전 문서에서 바뀐 법·제도와 어긋나는 문장 후보 추리기
재무·기획	정산·경비를 규칙 몇 개로만 검사	전 건에서 패턴이 어긋난 건 후보 추리기
영업·CS	상담 기록을 샘플링해서 품질 점검	전건에서 약속·확답이 들어간 건 후보 추리기
교육·기획	작년 교재를 눈으로 훑어 최신화	전 페이지에서 날짜·버전·가격이 박힌 문장 후보 추리기

전부 같은 모양입니다. “다 봐야 하는데 다 못 봐서 몇 개만 보고 있는 일.”

우리 부서에 이런 일이 있는지 확인하는 질문은 하나면 됩니다.

“이 점검, 전수로 하십니까 표본으로 하십니까?”

표본이라고 답하면 그 자리가 후보입니다. 그리고 표본으로 하는 이유가 “그게 맞아서”가 아니라 “사람이 다 못 봐서”라면, 그건 확실한 후보입니다.

4. 오늘 30분으로 만드는 최소 버전

269개로 시작하지 마십시오. 스무 개로 시작합니다.

한 종류의 문서를 스무 개 모읍니다. 계약서든 규정이든 상담 기록이든, 같은 종류여야 합니다.
“무엇을 의심할지”를 먼저 문장으로 적습니다. 이게 제일 중요합니다. 이 문장이 없으면 AI는 자기가 의심스럽다고 생각하는 걸 가져옵니다.
프롬프트는 줄글이 아니라 칸을 나눠서 씁니다. 줄 앞에 ##을 붙이면 그 줄이 칸 제목이 됩니다(마크다운이라고 부르는데, 채팅창에 그대로 치시면 됩니다 — 따로 정리해 둔 글이 있습니다). 제가 교육에서 쓰는 기본형 그대로입니다.

## 상황
첨부한 계약서 20건은 우리 회사가 지난 분기에 체결한 표준 공급계약입니다.
저는 법무 담당이 아니라 구매 담당이고, 조항의 법적 해석까지는 못 합니다.

## 요청
20건을 한 건씩 확인해서, 아래 기준에 걸리는 것만 골라 주세요.
판단하지 말고 후보만 주세요.

## 조건
- 계약 해지 통보 기간이 30일이 아닌 건
- 손해배상 상한이 적혀 있지 않은 건
- 출력은 표로: 문서명 / 걸린 기준 / 해당 문장 원문 / 확신도(상·중·하)
- 애매하면 '하'로 표시해서 포함할 것. 빠뜨리는 것보다 잘못 넣는 쪽이 낫습니다
- 네가 정한 기준은 반드시 한 줄로 밝혀줘

마지막 줄을 빼지 마십시오. “통보 기간”을 어디서부터 세는지, “손해배상 상한”에 무엇을 포함시켰는지를 AI가 조용히 정하고 시작합니다. 그 줄이 있어야 무엇을 기준으로 골랐는지가 화면에 올라옵니다. 이 한 줄만 따로 다룬 글이 요청 끝에 붙이는 한 줄입니다.

결과 표를 사람이 봅니다. 여기가 3번 칸입니다. 스무 건이면 10분이면 됩니다.
오탐률을 셉니다. 스무 개 중 몇 개가 헛것이었는지. 이 숫자가 이 업무에 이 방식을 쓸지 말지를 정합니다.

마지막 줄이 이 절차의 핵심입니다. “빠뜨리는 것보다 잘못 넣는 쪽이 낫습니다”는 취향이 아니라 설계입니다. 후보 추리기는 정답을 내는 일이 아니라 사람이 볼 목록을 짧게 만드는 일이니까요. 너무 깐깐하게 잡으면 진짜를 빠뜨리고, 그러면 전수로 본 의미가 없어집니다.

5. 이 사례가 성립한 전제

여기를 안 적으면 이 코너는 무책임해집니다. 위 사례가 굴러간 데는 조건이 있었습니다.

“정답이 아니라 후보”라는 합의가 있었습니다. 2,436건은 결론이 아니라 검토 목록입니다. 이 합의가 없는 조직에서 같은 걸 돌리면, 목록이 그대로 결론으로 유통되면서 사고가 납니다. AI가 ‘없습니다’라고 하면 그건 못 찾았다는 뜻이라고 쓴 것과 같은 자리입니다 — 목록에 없다고 없는 게 아닙니다.
검증할 사람이 있어야 합니다. 후보를 1,000건 뽑아 놨는데 볼 사람이 없으면, 그건 일을 줄인 게 아니라 밀린 일을 만든 것입니다. 최소 버전을 스무 개로 시작하라고 한 이유가 이겁니다.
오탐 비용이 누락 비용보다 싼 업무여야 합니다. 계약서 검토는 헛것 몇 개를 더 열어 보면 그만이라 맞습니다. 반대로 오탐 한 건이 곧바로 고객에게 나가는 일(자동 발송, 자동 승인)은 이 방식으로 하면 안 됩니다.
권한과 기밀이 정리돼 있어야 합니다. 전수로 훑는다는 건 평소에 안 열던 문서까지 다 연다는 뜻입니다. 표본으로 볼 때는 안 생기던 문제가 여기서 생깁니다.

오늘 가져가실 것

사례를 읽을 때 습관 하나만 바꾸시면 됩니다. “뭘 썼대?”가 아니라 “일의 어느 조각이 떨어져 나갔지?”라고 묻는 겁니다.

도구 이름은 반년이면 바뀝니다. 조각은 안 바뀝니다. 그리고 우리 부서에 같은 조각이 있는지는, 도구를 몰라도 오늘 확인할 수 있습니다.

이 글의 사실관계 출처: Z.ai GLM-5.3 공개 발표(2026-08-14) · OpenAI 데이브레이크·GPT-5.6-Cyber 발표(2026-08-10) · 두 건의 상세 정리는 주간 AI 동향 — 8월 셋째 주에 있습니다. 취약점 건수와 등급 분류는 각 회사 자체 발표이며 독립 검증은 없습니다. 이식 지도와 최소 버전 절차는 박상훈이 구성한 것입니다.