AI를 배웠는데 일에 안 쓰게 되는 건
모델이 부족해서가 아닙니다.

하루에 무엇이 일어났는가

마지막 줄이 이 글의 요지입니다. 점검이 잡은 17건 중 6건이 AI 가 스스로 낸 실수였습니다. 손으로 적어넣어 낡아버린 숫자, 정의가 없는 이름을 부르는 화면, 줄 맞춤을 눈으로 세다 깨뜨린 코드, 자기가 만들어놓고 두 번 만에 스스로 망가뜨린 시험.

사람이 그걸 전부 읽어서 찾아야 했다면 하루 100건은 불가능합니다. 속도를 만든 것은 모델이 아니라 점검이었습니다.

도구를 먼저 붙이면 대개 실패합니다

「AI를 도입한다」의 흔한 순서는 도구 → 업무 입니다. 도구를 붙여놓고 어디에 쓸지 찾습니다. 그러면 결과가 맞는지 볼 방법이 없어서 결국 사람이 전부 읽게 되고, 그 읽는 일이 밀리고, 결국 안 쓰게 됩니다.

반대 순서는 판정 → 위임 입니다. 「이 일이 제대로 됐다」를 기계가 판정할 수 있게 먼저 만들고, 그다음에 그 일을 맡깁니다. 판정할 수 없는 일은 아직 안 맡깁니다.

여기서는 그것이 세 겹입니다 — 한 곳(숫자와 그 출처를 한 파일에만 적는다) · 점검(화면에 뜬 숫자가 정말 거기서 왔는가) · 점검의 점검(그 점검이 실제로 걸러내는가). 마지막 겹이 없으면 앞의 둘은 있다고 믿고 있는 상태일 뿐입니다.

맡기는 만큼 점검도 같이 늘려야 합니다

문제를 고칠 때마다 같은 문제가 다시 못 들어오게 막는 점검을 함께 세웠습니다. 고치기만 하면 다음에 또 같은 것을 고치게 됩니다 — 맡기는 상대가 사람이 아닐 때 특히 그렇습니다. AI 는 어제 무엇을 고쳤는지 기억하지 않습니다.

그래서 규칙이 한 줄 더 붙습니다 — 새 점검은 «정말 거르는가» 를 확인한 뒤에만 «있다»고 칩니다. 오늘 시험 셋이 찾아갈 자리를 잃어 성립조차 안 됐고, 그중 하나는 AI 가 자기가 만든 시험을 스스로 망가뜨린 것이었습니다.

맡기지 않은 것이 맡긴 것만큼 중요합니다

하루 동안 AI 가 혼자 하지 않은 일들이 있습니다 — 운영 중인 서버의 설정을 바꾸는 것, 검색엔진에 알리는 것, 다른 도메인에 올리는 것. 전부 먼저 물어보고 사람의 확인을 받은 뒤에 했습니다.

기준은 「위험해 보이는가」가 아니라 「되돌릴 수 있는가」 입니다. 되돌릴 수 있으면 맡기고, 없으면 묻습니다. 고친 이력이 안 남는 서버를 덮어쓰는 일은 되돌릴 곳이 없으므로 묻습니다.

글도 마찬가지입니다. 이 사이트의 다른 기록은 전부 실제로 겪은 일만 싣습니다. 겪은 것이 없는 자리는 그냥 비워뒀습니다 — 안 겪은 것을 겪은 것처럼 쓰면 나머지 전부가 같이 못 믿을 글이 됩니다.

맡길 수 있는 만큼만 자동화됩니다

「AI를 배웠는데 정작 일에는 안 씁니다」의 원인은 대개 덜 배워서가 아닙니다. 그 일에 「제대로 됐다」가 무엇인지 정해져 있지 않아서입니다. 정해져 있지 않으면 사람이 매번 다 읽어야 하고, 읽는 품이 직접 하는 품을 넘습니다.

그래서 순서는 이렇습니다 — 「됐다」를 기계가 가릴 수 있게 만들고, 그 가림이 실제로 도는지 확인하고, 되돌릴 수 있는 일부터 맡기는 것입니다. 도구를 고르는 일은 그다음이고, 사실 제일 쉬운 부분입니다.