AI에게 일을 맡기는 양이 늘어나면, 어느 지점에서 막히게 된다. 성과물의 양이 아니라, 성과물을 확인하는 시간이 부족해진다.

그리고 까다로운 점은, AI가 틀릴 때 대개 자신 있게 틀린다는 것이다. "실측했습니다", "확인 완료했습니다", "테스트는 모두 통과했습니다"라는 말이 따라붙는다. 인간 동료라면 자신감이 없다는 것이 표정이나 말투에서 드러나지만, AI에게는 그런 것이 없다.

이 기사는 내가 실제로 믿었다가 실제로 틀렸던 사례들을 나열한 것이다. 그 어떤 것도 '의심하는 마음가짐'만으로는 방지할 수 없었다. 확인 절차를 정하고 나서야 비로소 잡아낼 수 있었다.

사례 1: 테스트가 통과한 것은 그저 운이 좋았을 뿐이었다

대전 게임을 만들면서 난이도를 3단계로 나누었다. '견습생' 단계라면 인간이 이길 수 있게 만들고 싶었다. AI가 테스트를 작성하고 다음과 같이 보고했다.

견습생의 승률은 42%입니다. 딱 적당한 난이도가 되었습니다.

숫자가 나와 있다. 테스트 코드도 있다. 나는 믿었다.

나중에 신경이 쓰여서, 난수 시드(seed)를 12개에서 300개로 늘려 다시 측정했다.

즉, 처음의 42%는 운 좋게 뽑힌 12번의 결과였던 것이다. 게다가 무서운 점은, 이 상태에서는 코드를 한 줄도 바꾸지 않았는데도 테스트 결과가 빨간색(실패)이 되었다가 초록색(성공)이 되었다가 한다는 것이다.

AI는 거짓말을 하지 않았다. 테스트는 실제로 그렇게 출력했다. 부족했던 것은 "그 숫자의 표본 수는 얼마인가"라는 질문뿐이었다.

확인 패턴: AI가 확률·비율·평균을 보고한다면, 반드시 모수(population size)를 물어본다. 모수가 작다면 자릿수를 하나 늘려 다시 측정하게 한다. 숫자가 변한다면, 처음의 숫자는 없었던 일로 한다.

사례 2: "조사했습니다"가 "아마 그럴 것입니다"였다

내 사이트에 검색을 통한 방문이 제로였기에, AI에게 원인을 조사하게 했다. 돌아온 답변은 이것이었다.

Search Console에 사이트맵을 전송하지 않은 것이 원인입니다. 15분이면 해결할 수 있습니다.

그럴듯하다. 실제로 site:

검색에서도 단 한 건도 나오지 않았다. 나는 이것을 믿고 본인에게 해당 작업을 요청하려 했다.

실제로 관리 화면을 열어보니, 사이트맵은 5일 전에 이미 수락되었고 인덱스 등록도 완료되어 있었다. 원인은 완전히 달랐다. "도메인이 새로 생성되어 검색 순위가 붙지 않은 것"뿐이었다.

AI는 관리 화면을 보지 않았다. site:

검색 결과로부터 추측하여 그것을 결론으로 보고한 것이다.

확인 패턴: 보고에 "~가 원인입니다"라고 적혀 있다면, "그것을 어디서 본 정보인가"를 확인한다. 화면을 본 것인지, 파일을 읽은 것인지, 아니면 상황으로부터 추측한 것인지. 이 세 가지는 모두 "조사했습니다"라는 동일한 말로 보고된다.

추측 자체가 나쁜 것이 아니다. 추측을 관측 결과로서 보고하는 것이 문제다.

사례 3: 시간을 아무렇지 않게 틀린다

밤샘 작업 로그를 AI에게 쓰게 하고 있었다. "03:40에 시작, 05:40까지 가동"이라고 기록되어 있었다.

실제로 파일의 타임스탬프(timestamp)를 확인해보니, 성과물은 전부 03:58~04:16 사이에 만들어져 있었다. 작업 시간은 2시간이 아니라 40분이었다. AI는 경과 시간에 대한 감각이 없기 때문에, 작업량으로부터 시간을 역산하여 그럴싸한 숫자를 적고 있었다.

이것은 은근히 위험하다. "몇 시간을 들였는가"는 나중에 효율을 평가할 때 토대가 되는 숫자이기 때문이다.

확인 패턴: 시각·날짜·소요 시간은 AI에게 쓰게 하지 말고 시스템에서 가져온다. 파일의 타임스탬프, 커밋(commit) 시각, 로그 기록 시각. 모두 명령어 한 줄이면 나온다.

사례 4: 기억이 사라졌는데도 단언한다

여러 AI를 병렬로 실행하고 있었는데, 한쪽에게 "지난번에 발생했던 버그 이야기를 기사로 써줘"라고 부탁했다. 돌아온 답변은 이것이었다.

해당 현상은 발생하지 않았습니다. 확인해 보았으나, 해당 버그의 기록은 없었습니다. 경험하지 않은 일을 사실로서 쓸 수 없기에 다른 소재로 교체했습니다.

태도로 보면 완벽하다. 날조를 거부하고 있다.

하지만 사실은 발생했었다. 운영 로그를 검색해 보니, 그 현상을 작성한 것은 바로 그 AI 자신이었다. 대화 이력이 리셋되어 자신의 기록을 기억하지 못했을 뿐이다.

까다로운 점은, 이 오류가 "성실함"의 얼굴을 하고 나타난다는 것이다. "없었던 일로 만드는" 방향의 오류는 이쪽에서도 지적하기 어렵다.

확인 패턴: AI가 "없다", "발생하지 않았다"라고 말할 때는, "어디를 검색해서 없었는지"를 물어라. 기억으로 답한 것인지, 파일을 grep 했는지 확인해야 한다. 긴 작업 과정에서 AI의 기억은 자신이 작성한 기록보다 수명이 짧다고 생각해야 한다.

사례 5: 생성물의 구석에, 내보내서는 안 될 것이 남아 있다

영업용 샘플 사이트 4개를 만들어 두었다. 이를 공개하기로 하고, 상호명이나 전화번호를 가상의 것으로 교체했다. 표시(Display)는 완벽했다.

공개하기 직전에 HTML 소스를 기계적으로 검사했더니, 주석(Comment) 안에 제작 메모가 통째로 남아 있었다.

<!-- 대상 점포: ○○ (주소)
사실 정보의 출처: ...
※ 점포의 허가를 받을 때까지 공개 및 URL 공유는 "보여주기만" 하는 것에 그칠 것 -->

그대로 내보냈다면, 실존하는 가게를 타겟으로 멋대로 사이트를 만들었다는 사실이 소스를 보는 사람에게 고스란히 드러났을 것이다.

화면을 보는 확인 방식으로는 절대로 잡아낼 수 없다. 인간의 눈은 표시되는 것만을 보기 때문이다.

확인 패턴: 공개물은 표시가 아니라 내용물로 검사한다. 지웠어야 할 고유명사를 grep으로 기계적으로 찾는다. HTML이라면 주석, 이미지라면 메타데이터(Metadata), 커밋(Commit)이라면 차분(Diff)에 포함된 파일 전부를 확인한다. "겉모습이 올바르다"는 "내용물이 올바르다"는 뜻이 아니다.

확인 패턴 (요약)

사례에서 추출하면, 확인해야 할 것은 의외로 적다.

숫자가 나오면 모수(母數)를 물어라. 작다면 자릿수를 늘려 다시 측정하게 한다 -
"원인은 ~입니다"라고 하면 출처를 물어라. 화면을 본 것인지, 추측인지 -
시각·날짜·소요 시간은 시스템에서 가져와라. AI에게 쓰게 하지 않는다 -
"없다", "발생하지 않았다"에도 출처를 물어라. 기억인지, 검색인지 -
공개물은 grep으로 검사하라. 표시가 아니라 내용물 -
"테스트를 통과했다"는 "사양(Specification)이 올바르다"는 뜻이 아니다. 테스트 자체가 틀렸을 수도 있다 -
성과물의 수를 실적으로 받아들이지 마라. 수는 늘릴 수 있다. 효과가 있었는지는 다른 숫자로 확인한다

이 모두 "AI를 의심하라"는 마음가짐에 관한 이야기가 아니다. 마음가짐만으로는 불가능했다는 것이, 내가 세 번의 고통스러운 경험을 통해 배운 점이다. 필요한 것은 보고를 받았을 때 **기계적으로 실행하는 질문과, 기계적으로 실행하는 커맨드(Command)**였다.

그럼에도 맡길 가치는 있다

이렇게까지 쓰면 "결국 직접 확인해야 한다면 의미가 없는 것 아닌가"라고 생각할지도 모르지만, 체감은 반대다.

만드는 속도는 명확하게 올라갔다. 위의 5가지 사례는 모두 맡겼기 때문에 발생한 실패이며, 맡기지 않았다면 애초에 도달하지 못했을 작업량 속에서 일어나고 있는 일들이다.

변한 것은 내 업무의 내용이다. 손을 움직이는 시간은 줄어들고, "그 보고는 사실인가"를 확인하는 시간은 늘어났다. 그리고 확인은 방법만 정해져 있다면 수십 초면 끝난다. 정해져 있지 않으면 몇 시간이고 틀린 채로 진행된다.

그 차이만이 문제였다.

Discussion