'AI로 안 되더라'에는 세 가지가 섞여 있습니다

들어가며 — 회의를 끝내는 한 문장

AI 도입 논의를 하다 보면 이 문장이 꼭 한 번은 나옵니다.

“그거, 예전에 AI로 해봤는데 안 되던데요.”

이 한마디가 나오면 대개 그 안건은 접힙니다. 해봤다는 사람이 있고, 안 됐다는 결과가 있으니까요. 반박할 근거가 없습니다.

그런데 저 문장에는 성질이 완전히 다른 세 가지가 섞여 있습니다. 그리고 셋은 다음 행동이 정반대입니다. 구분하지 않으면 셋 다 같은 서랍에 들어가고, 그 서랍은 다시 안 열립니다.

같은 "안 되더라"라도 어느 칸인지에 따라 다음 행동이 완전히 달라집니다. 칸을 안 나누면 셋 다 같은 서랍에 들어갑니다.

1. 막혀 있어서 못 하는 것

첫 번째는 권한·정책·요금제 때문에 막힌 것입니다. 사내 규정상 자료를 못 넣거나, 무료 요금제라 기능이 잠겼거나, 보안 정책이 접근을 막고 있는 경우죠.

이건 잠긴 문입니다. 열쇠가 있으면 열립니다. 그래서 처방도 명확해 보입니다 — 규정을 풀거나 예산을 쓰면 되니까요.

그런데 여기에 함정이 하나 있습니다. 최근에 이걸 정면으로 보여주는 수치가 공개됐습니다.

오픈AI가 지난주(8월 10일) 보안 담당자용 접근 등급을 새로 열면서, 보안 관련 요청을 걸러내던 시스템 안전장치를 통째로 제거한 상태의 모델을 승인된 사용자에게 제공하기 시작했습니다. 그 상태에서 민감한 요청의 완료율이 얼마나 올랐는지가 같이 나왔습니다.

무엇을 쓰는가	완료율
일반 모델	1.5%
안전장치를 제거한 같은 모델	2.0%
보안 전용으로 따로 훈련한 모델	95.0%

막은 걸 통째로 풀었는데 1.5%가 2.0%가 됐습니다. 실제 차이는 규정이 아니라 따로 훈련된 모델에서 났습니다.

이 숫자가 회사 안에서 뜻하는 건 이겁니다. “규정 때문에 못 한다”는 말의 상당수는, 규정을 풀어도 안 됩니다. 그런데 우리는 대개 그 반대로 가정합니다. 풀기만 하면 될 거라고 보고, 풀어 주는 데 몇 달을 씁니다. 그러고 나서 결과가 그대로면 그때는 아무도 책임지지 않습니다.

그래서 처방은 “푼다”가 아니라 “작게 열어서 재본다”입니다. 전면 허용 전에, 한 팀·한 업무·2주로 열어서 결과를 재십시오. 이 구분은 회의실에서는 절대 안 됩니다. 열어 봐야 압니다.

2. 아직 못 하는 것

두 번째는 지금 품질이 부족한 것입니다. 시켜 봤는데 결과가 반쯤 틀렸다, 손보는 게 직접 하는 것보다 오래 걸린다 — 이런 경우죠.

이 판정은 그때 정확했을 겁니다. 문제는 그 판정이 언제 내려졌는지가 어디에도 안 적혀 있다는 겁니다.

지난주 하루 동안 벌어진 일을 예로 들면 이렇습니다. 8월 13일, 구글이 실무용 모델을 새로 내놨는데 직전 모델이 나온 지 23일 만이었습니다. 업무 자동화를 재는 평가에서 점수가 17.0%에서 30.4%로 올랐습니다. 같은 날 오픈AI는 처리 속도를 최대 14배로 올린 등급을 공개했고, 딥시크는 플래그십 모델을 정식 출시했습니다.

“절반이 틀리던” 것이 “셋 중 하나가 틀리는” 것으로 바뀌면 판정이 뒤집힙니다. 절반이 틀리면 사람이 다시 하는 게 빠르지만, 셋 중 하나면 사람이 검수하는 쪽이 빠르니까요. 그 경계는 생각보다 좁습니다.

그러니 이 칸의 처방은 하나입니다. 판정에 날짜와 근거를 같이 적으십시오.

“2026년 3월, 출력 품질 때문에 보류. 근거는 오탐 40%. 재검토 9월.”

이 두 줄이 없으면 그 판정은 영구 보관됩니다. 근거가 값이나 품질이었다면 재검토 주기는 분기가 아니라 달 단위여야 합니다.

여기서 짚어 둘 게 하나 있습니다. 제가 6개월 전에 쓴 지시가 오늘 AI를 방해합니다에서 다룬 건 지시문 안의 줄이 낡는 이야기였습니다. 이 글은 대상이 다릅니다. 낡는 게 지시문만이 아니라 “이건 AI로 안 된다”는 조직의 판정 자체입니다. 전자는 프롬프트를 정비하면 되지만, 후자는 회의록에 박혀서 아무도 안 건드립니다. 그래서 더 오래 남습니다.

3. 원래 안 되는 것

세 번째가 가장 중요합니다. 그리고 대부분 잘못 분류됩니다.

이 칸은 도구를 바꿔도 안 열립니다. 문이 없는 벽이거든요. 그런데 왜 벽이냐 하면, 보통 이런 이유입니다.

사람이 그 일을 어떻게 판단하는지가, 어디에도 적혀 있지 않기 때문입니다.

예를 들면 이런 일들입니다. “이 거래처는 좀 봐줘야 하는 곳”, “이 견적은 통과시키면 안 되는 냄새가 남”, “이 보고서는 임원 취향에 안 맞음”. 실무자는 3초 만에 판단합니다. 그런데 무엇을 보고 그렇게 판단하는지 물어보면 답이 잘 안 나옵니다.

이 상태에서 AI에게 시키면 당연히 안 됩니다. 그리고 우리는 그걸 “AI가 못 하는 일”이라고 기록합니다. 실제로는 “우리가 적어 둔 적 없는 일”인데요.

이 둘은 완전히 다릅니다. 후자는 적으면 문이 생깁니다. 그리고 적어 두면 AI가 못 해도 남는 게 있습니다 — 신입에게 가르칠 수 있고, 담당자가 바뀌어도 안 날아갑니다. AI에게 일을 시키려면 먼저 ‘일’이 뭔지 알아야 한다고 쓴 게 이 자리입니다.

물론 진짜 벽도 있습니다. 데이터 자체가 세상에 없거나, 판단에 책임이 걸려서 사람이 해야만 하는 일이요. 그건 그대로 두면 됩니다. 다만 벽이라고 적기 전에 “적어 본 적은 있나”를 먼저 물어야 합니다.

4. 가르는 질문 세 개

“안 되더라”가 나왔을 때 그 자리에서 물어보실 세 개입니다. 순서대로 물으시면 됩니다.

“권한이나 요금제가 풀리면 됩니까?” → 그렇다면 ①번. 다만 전면 허용 전에 한 팀·2주로 재보십시오.
“마지막으로 시도한 게 언제입니까?” → 석 달이 넘었으면 ②번 후보입니다. 그 판정은 지금 유효하지 않을 수 있습니다.
“그 일, 사람이 할 때는 뭘 보고 판단합니까? 그게 어디 적혀 있습니까?” → 답이 “그냥 감으로 안다”면 ③번입니다. 도구를 바꿀 게 아니라 그 감을 문장으로 꺼내는 게 먼저입니다.

세 번째 질문이 회의 분위기를 바꿉니다. 이건 AI에 대한 질문이 아니라 우리 일에 대한 질문이거든요. 그리고 답이 안 나오면, 그 자체가 이번 논의에서 얻은 가장 값진 정보입니다.

마무리 — 서랍을 셋으로 나누십시오

“AI로 안 되더라” 목록을 가진 조직은 많습니다. 그 목록이 하나짜리 서랍인 것이 문제입니다.

셋으로 나누면 각각 다른 데로 갑니다. ①은 파일럿 설계로, ②는 재검토 일정으로, ③은 업무 정의 작업으로요. 예산도 담당자도 기한도 다릅니다.

그리고 그렇게 나눠 놓으면, 반년 뒤에 다시 열어 볼 수 있는 목록이 됩니다. 지금 목록은 아무도 다시 안 엽니다. 거기 적힌 게 셋 중 무엇인지 아무도 모르니까요.

①의 완료율 수치는 오픈AI 자체 평가이며 상세와 출처는 주간 AI 동향 — 8월 셋째 주에 정리해 두었습니다.