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

하루에 무엇이 일어났는가

마지막 줄이 이 글의 요지입니다. 검사가 잡은 17건 중 6건이 에이전트 자신의 실수였습니다. 손으로 박은 수치, 없는 이름을 쓴 마크업, 들여쓰기를 눈으로 세다 깨뜨린 코드, 자기가 등록해놓고 두 커밋 뒤에 무력화한 시험.

사람이 그걸 전부 읽어서 찾았다면 하루에 100건은 불가능합니다. 속도는 모델이 만들지 않았습니다. 검사가 만들었습니다.

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

「AI를 도입한다」의 흔한 순서는 도구 → 업무 입니다. 도구를 붙이고 어디에 쓸지 찾습니다. 그러면 결과가 맞는지 볼 방법이 없어서 결국 사람이 검수하고, 검수가 병목이 되고, 안 쓰게 됩니다.

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

이 사이트에서 그것은 세 층입니다 — 계약(수치와 출처가 한 곳에서 온다) · 검사(화면에 뜬 것이 계약에서 왔는가) · 검사의 검사(그 검사가 실제로 무는가). 마지막 층이 없으면 앞의 둘은 있다고 믿는 상태일 뿐입니다.

맡기면서 검사가 함께 늘어야 합니다

결함을 고칠 때마다 같은 결함이 다시 못 들어오게 하는 검사를 함께 세웠습니다. 고침만 하면 다음에 또 같은 것을 고칩니다 — 특히 맡기는 쪽이 사람이 아니라 에이전트일 때 그렇습니다. 에이전트는 어제 무엇을 고쳤는지 기억하지 않습니다.

그래서 규율이 한 줄 더 붙습니다 — 새 검사는 «정말 무는가» 를 시험해서 확인한 뒤에만 셉니다. 오늘 프로브 셋이 앵커를 잃어 「불성립」이 났고, 그중 하나는 에이전트가 자기가 만든 시험을 스스로 무력화한 것이었습니다.

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

하루 동안 에이전트가 하지 않은 것들이 있습니다 — 운영 서버 설정 변경, 외부 검색엔진 통보, 다른 도메인 배포. 전부 먼저 물어보고 승인을 받은 뒤에 했습니다.

기준은 「위험해 보이는가」가 아니라 「되돌릴 수 있는가」 입니다. 되돌릴 수 있으면 맡기고, 없으면 묻습니다. 형상관리가 없는 서버에 덮어쓰는 일은 되돌릴 수 없으므로 묻습니다.

글도 그렇습니다. 이 사이트의 다른 기록들은 전부 실제로 겪은 일만 싣습니다. 재료가 없는 자리는 비워뒀습니다 — 겪지 않은 것을 겪은 것처럼 쓰면 나머지 전부의 신뢰가 같이 떨어집니다.

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

「AI를 배웠는데 정작 일에는 안 씁니다」의 원인은 대개 학습 부족이 아닙니다. 그 일에 「제대로 됐다」의 정의가 없어서입니다. 정의가 없으면 사람이 매번 읽어야 하고, 읽는 비용이 만드는 비용을 넘습니다.

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