AI가 든 예시는 어디서 왔을까

AI가 든 예시를 쓰기 전 원본으로 되짚어 보는 장면을 담은 이미지입니다.

밤이었습니다.
주문 상세를 띄우는 화면 하나를 고치는 수정 가이드 여섯 개가 제 앞에 떠 있었고, 저는 그걸 바로 넘기기 직전이었습니다.
코드 스니펫까지 친절하게 붙어 있었습니다.
그 한가운데에 itemDisplayName이라는 칸 이름이 단정하게 박혀 있었는데, 너무 자연스러워서 눈이 그냥 미끄러졌습니다.
솔직히 그냥 복사해 넣고 싶었습니다.
그래도 넘기기 전에 검토 도구한테 딱 하나만 시켰습니다.
"이 코드가 쓰는 칸 이름들, 실제 정의가 원본 어디에 어떻게 적혀 있는지 대봐라."

여섯 개 중에 여섯 개가 빨강이었습니다.

그날 제가 붙든 건 습관 하나였습니다.
AI가 코드 한 줄을 내밀면, 그걸 쓰기 전에 30초만 원본으로 되짚어 보는 것.
별것 아닌 습관인데, 그날 밤이 아니었으면 저는 아마 아직도 안 하고 있었을 겁니다.

탐색 도구는 위치를 정확히 맞혔습니다

시작은 깔끔했습니다.
"이 기능이 어느 파일에 있는지 찾아와." 탐색 도구가 후보 파일 세 개를 짚어 왔는데, 하나하나에 '거의 확실' 같은 꼬리표까지 달려 있었습니다.
열어보니 진짜로 맞았습니다.
위치는 하나도 틀린 게 없었습니다.

문제는, 제가 그 '거의 확실'을 다음 단계까지 그대로 끌고 갔다는 겁니다.
위치를 이렇게 잘 짚었으니 그다음도 맞겠거니 했습니다.
지금 돌아보면 그게 첫 단추였습니다.
그 꼬리표는 사실 위치에만 붙은 건데도, 그 뒤에 올 모양까지 미리 믿게 만들었습니다.

"보통 이런 건 이렇게 쓰죠"로 빈칸을 메웠습니다

화면 하나를 고치려면 그 화면이 다루는 데이터에 어떤 칸이 있고, 값을 어떤 순서로 넣고 빼는지를 알아야 합니다.
그러려면 아까 찾은 그 파일을 실제로 펼쳐서, 칸 이름이 진짜 뭐라고 적혀 있는지 한 줄 한 줄 읽어야 합니다.

근데 그 파일을 아무도 안 펼쳤습니다.

메인 AI는 그 빈칸을 "이런 가공이면 보통 이런 칸을 쓰죠"로 채웠습니다.
펼쳐보지도 않은 채로 말입니다.
자주 보던 모양으로 그냥 메운 겁니다.
그럴듯했습니다.
진짜 그럴듯했습니다.
아까 그 itemDisplayName도 그렇게 태어난 이름이었습니다.
화면에 뭘 보여주는 칸이면 으레 중간에 'Display' 한 단어쯤 끼우는 게 흔하니까, 지어낸 이름이 딱 그 관습에 맞아떨어졌습니다.
너무 평범해서 의심이 들 자리조차 없었습니다.
그래서 더 안 걸렸습니다.
여섯 개 가이드가 전부, 한 번도 펼쳐본 적 없는 칸 구조를 전제로 짜였습니다.

여기서 제가 솔직히 위험했던 건, 그 여섯 개가 너무 "끝난 것처럼" 보였다는 점입니다.
들여쓰기가 가지런했습니다.
주석까지 친절하게 달려 있었습니다.
다 된 코드를 받았을 때의 그 안도감 있잖습니까.
손이 이미 복사 단축키 위에 올라가 있었습니다.
검토를 한 번 더 시킨 건 확신이 있어서가 아니라, 그냥 너무 매끄러워서 오히려 한 번 걸렸기 때문이었습니다.

여섯 개를 대보라니까, 한 개도 못 댔습니다

사실 제가 처음 돌린 검사는 이게 아니었습니다.
처음엔 "코드 문법은 맞는지, 안 쓰는 변수는 없는지" 정도만 훑었습니다.
초록불이 떴습니다.
손이 다시 복사 단축키로 갔습니다.
거기서 멈췄으면 여섯 개를 그냥 넘겼을 겁니다.
근데 초록불이 보장하는 건 "글자 모양이 멀쩡하다"지 "이 칸이 진짜 있다"가 아니었습니다.
단축키를 누르기 직전에 그게 걸려서, 검사를 통째로 갈아탔습니다.

넘기기 전에 검토 도구한테는 칭찬을 금지하고 딱 하나만 시켰습니다.
"코드에 나오는 칸 이름마다, 실제 정의가 원본 어디에 어떻게 적혀 있는지 짝지어 와라.
못 짝지으면 그건 지어낸 거다."

짝이 하나도 안 맞았습니다.

제일 먼저 댄 게 그 itemDisplayName이었습니다.
원본 어디에도 그런 칸은 없었습니다.
실제로 거기 있던 건 itemName, 그냥 상품명 한 줄 들고 있는 칸이었습니다.
딱 한 단어 차이였습니다.
'Display'가 중간에 끼었느냐 아니냐, 그거 하나 때문에 코드는 있지도 않은 칸을 붙들고 돌게 돼 있었습니다.
나머지도 비슷했습니다.
있는 줄 알았던 칸이 없었고, 값을 넣고 빼는 순서—그러니까 호출 방식—는 실제와 거꾸로였습니다.
받는 쪽으로 보내야 할 값을 보내는 쪽에서 꺼내 오는 식이었으니, 설령 이름이 맞았더라도 반대로 흘렀을 코드였습니다.
글자 모양만 보면 멀쩡한 코드라, 아까 그 초록불도 그래서 떴던 겁니다.
근데 진짜 원본이랑 한 줄씩 대보는 순간, 여섯 개가 한꺼번에 빨강으로 뒤집혔습니다.
6/6 전부 다시 쓰기.

저는 그걸 한 줄씩 다시 따라가 봤습니다.
첫 번째 가이드에서 가짜 칸 하나, 두 번째에서 또 하나, 그렇게 여섯 개를 내려가는데 멈출 자리가 안 나왔습니다.
어느 하나라도 "이건 내가 직접 못 봤습니다" 한 줄이 붙어 있었으면 거기서 걸렀을 텐데, 그런 표시가 없었습니다.
전부 똑같이 자신만만했습니다.

그 순간 알았습니다.
탐색 도구가 "여기 있습니다"라고 위치를 짚은 것과, 메인 AI가 "이렇게 생겼습니다"라고 모양을 채운 것은 처음부터 다른 주장이었습니다.
위치는 검증을 거쳤고, 모양은 검증된 적이 한 번도 없었습니다.
근데 위치가 정확했다는 그 사실이, 모양까지 맞을 거라는 착각을 깔아줬습니다.
손이 좀 서늘해졌습니다.

이제는 예시부터 원본으로 되짚습니다

그래서 요즘은 AI가 "이 칸을 이렇게 쓰면 됩니다"라고 코드를 내밀면, 그걸 쓰기 전에 30초를 씁니다.
코드가 가리키는 원본 파일을 직접 펼쳐서, 거기 적힌 이름이 진짜 그건지를 봅니다.
위치를 잘 짚어줬다는 말은 그냥 믿어도 됩니다.
근데 칸 이름이 진짜 그렇게 생겼는지는, 펼쳐서 제 눈으로 본 다음에만 믿습니다.

30초가 그렇게 셌던 건, 그게 추측으로는 못 만드는 증거라서입니다.
itemName이라고 대려면 원본을 실제로 펼쳐서 그 글자를 직접 봐야 합니다.
안 펼치면 itemDisplayName처럼 그럴듯한 이름이 나올 수밖에 없고, 짝이 안 맞는 순간 그 자리에서 바로 들통납니다.
(솔직히 이건 AI만의 얘기는 아닙니다.
저도 제가 직접 펼쳐본 자리까지만 의심하니까 말입니다.)

그런데 솔직히 말하면, 위치를 정확히 맞혀줄 때 제가 제일 방심합니다.
잘 짚어줄수록 그다음 모양도 그냥 믿고 싶어지는 그 마음은, 아직 잘 안 고쳐집니다.