사고는 바꾼 것이 아니라 안 바꾼 것에서 납니다

들어가며 — 검사 두 개를 통과한 파일, 표지엔 남의 회사 이름

교육 자료 43장을 만들었습니다. 처음부터 만들지는 않았습니다. 몇 주 전 다른 회사 과정에서 쓴 슬라이드 생성 코드를 그대로 가져와, 데이터와 내용만 이번 프로젝트 것으로 갈아끼웠습니다.

검사도 돌렸습니다. 만들기 전에 한 번 — 내가 넣은 항목 이름을 렌더러가 실제로 읽는지. 만든 뒤에 한 번 — 파일이 규격에 맞는지. 둘 다 통과했습니다.

그리고 슬라이드를 이미지로 뽑아 넘겨보다 첫 장에서 멈췄습니다. 표지 상단에 이전 프로젝트 고객사 이름이 영문 대문자로 박혀 있었습니다.

이미지로 뽑아 눈으로 보는 절차가 있어서 거기서 걸렸습니다. 없었다면 고객사에 타사 이름이 찍힌 표지가 그대로 갔을 겁니다. 그 한 장이면 나머지 42장은 볼 것도 없이 끝입니다.

제가 오래 붙들고 본 건 실수 자체가 아니라 이겁니다. 검사기 두 개는 왜 이걸 못 잡았을까.

1. 검사기가 부실했던 게 아닙니다 — 그건 애초에 검사 대상이 아니었습니다

전에 한 번 쓴 적이 있습니다. 검사를 통과했다는 말은 “맞다”가 아니라 “내가 물어본 것만 맞다”는 뜻이라고요. 그 글의 처방은 명확했습니다 — 한 번 데인 결함은 다짐이 아니라 장치로 막아라.

그래서 장치를 붙였습니다. 두 개나. 그런데도 뚫렸습니다. 이번 건은 그 글보다 한 칸 안쪽에 있습니다.

검사기 두 개는 모두 내가 이번에 넣은 데이터를 검사합니다. 항목 이름이 맞는지, 값이 규격에 맞는지. 그런데 표지의 그 문구는 제가 넣은 데이터가 아니었습니다. 가져온 코드 안에 문자열로 박혀 있던 것이었습니다.

즉 이건 제가 안 물어본 항목이 아니라, 물어볼 목록 자체에 없던 것입니다. 검사를 하나 더 붙였어도 못 잡았을 겁니다. 목록을 만드는 사람이 그게 거기 있는 줄 몰랐으니까요.

항목의 문제가 아니라 범위의 문제입니다. 그리고 범위는 검사를 늘려서 넓혀지지 않습니다.

검토 시선은 이번에 바꾼 자리(밝은 띠)를 따라간다. 그런데 가져온 원본에서 그대로 따라온 자리(어두운 띠)는 「원래 있던 것」으로 처리되어 아예 시선 밖에 놓인다. 그것들도 검증되긴 했다 — 다른 일에서. 검증은 결과물을 따라오지만 맥락은 따라오지 않고, 사고는 늘 그 어두운 띠에서 난다.

2. AI로 일할수록, 결과물의 대부분은 이번에 쓴 것이 아닙니다

이게 왜 지금 문제가 되느냐 — AI로 일하면 재사용이 기본 동작이 되기 때문입니다.

AI가 준 속도의 상당 부분은 새로 만드는 데서 오지 않습니다. 이미 있는 것을 다시 쓰는 데서 옵니다. 지난 제안서를 열어 이번 회사 것으로 바꾸고, 프로젝트에 자료를 올려두고 계속 부르고, 잘 되던 지침을 저장해두고 매번 얹고, 동료가 만들어둔 프롬프트를 받아 씁니다.

그래서 결과물은 두 층으로 만들어집니다.

이번에 내가 바꾼 것 — 지시했고, 방금 만졌고, 기억에 있습니다.
물려받은 것 — 지시하지 않았고, 그래서 그대로 살아남았습니다.

여기서 중요한 건, 그대로 남는 게 고장이 아니라는 점입니다. 지시하지 않은 것을 건드리지 않는 건 AI든 템플릿이든 제대로 동작한 겁니다. 일관성을 지키라고 만든 동작이니까요. 정상 동작의 결과로 남의 맥락이 따라옵니다.

사무직 책상 위에서는 이렇게 나타납니다.

지난 제안서를 복사해 “회사명 바꿔줘”라고 시킵니다. 본문은 깨끗하게 바뀝니다. 머리말, 차트 제목, 표 각주, 파일 이름, 문서 속성의 작성자란에는 지난 회사가 남습니다.
프로젝트에 저장해둔 지침에 석 달 전 규칙이 남아 있습니다. 결과물이 계속 미묘하게 그쪽으로 기웁니다. 매번 프롬프트만 고치니 원인이 안 잡힙니다.
동료가 만든 봇을 받아 씁니다. 잘 돕니다. 그 안에 무슨 지시문이 적혀 있는지는 한 번도 열어본 적이 없습니다.

셋 다 같은 구조입니다. 내가 쓰지 않은 문장이 내 이름으로 나갑니다.

3. 왜 우리 눈은 하필 거기를 안 볼까

검토할 때 시선은 자연스럽게 바꾼 곳을 따라갑니다. 방금 만졌으니 기억에 있고, 확인할 이유도 거기 있습니다.

반대로 안 바꾼 곳은 “원래 있던 것”입니다. 그리고 원래 있던 것은 머릿속에서 조용히 이미 검증된 것으로 처리됩니다. 지난번에 잘 나갔던 파일이니까요.

여기에 함정이 있습니다. 검증된 것이 맞습니다. 다른 일에서.

몇 주 전 그 표지 문구는 완벽하게 옳은 문장이었습니다. 그 프로젝트에서는요. 틀린 문장이 된 건 옮겨온 순간입니다. 결과물은 따라왔는데 그것이 옳았던 조건은 따라오지 않았습니다. 검증은 파일을 따라오지만, 맥락은 따라오지 않습니다.

그래서 이 결함은 엉성한 재료에서 나오지 않습니다. 잘 만들어져서 재사용된 재료에서 나옵니다. 재사용할 만큼 좋았다는 것이 이 사고의 전제 조건입니다. 좋은 자산을 많이 쌓아둔 사람일수록 더 자주 만납니다.

4. 그래서 세 가지를 바꿨습니다

① 물려받은 것에 이름표를 답니다. 새로 만들 때 맨 위에 한 줄 적습니다 — “이건 어느 건에서 가져옴.” 별것 아닌 것 같지만, 무엇을 물려받았는지 모르면 검사할 수도 없습니다. 검사 범위는 목록에서 나오고, 목록은 기억이 아니라 기록에서 나옵니다.

② 고유명사를 사냥합니다. 원본에 있던 고유명사를 목록으로 만듭니다. 이전 고객사, 과정명, 연도, 사람 이름, 제품명. 그리고 결과물 전체에서 검색합니다. 0건이어야 통과입니다. 본문만이 아니라 표지·머리말·꼬리말·파일 이름·문서 속성까지요. 5초면 끝납니다.

AI에게 시켜도 됩니다. 검토를 부탁할 때 이렇게 묻습니다 — “이번에 내가 지정하지 않았는데 그대로 남아 있는 이름·날짜·문구만 뽑아줘.” 잘 썼는지 봐달라는 부탁보다 이쪽이 훨씬 잘 걸립니다. 답이 목록으로 나오니 확인도 빠릅니다.

③ 사람이 안 읽는 자리를 사람이 봅니다. 표지 한 장, 머리말, 마지막 장, 파일 이름. 여기는 내용이 없어서 검사기가 안 보고, 다 아는 자리라서 사람도 안 봅니다. 그런데 받는 사람은 정확히 여기부터 봅니다.

마무리 — 청구서는 품질이 아니라 신뢰로 옵니다

표지 한 장은 43장 중 하나입니다. 내용으로 치면 43분의 1이지만, 받는 사람에게는 100%입니다. 거기 남의 회사 이름이 있으면 나머지 42장의 품질은 아무 의미가 없습니다. 재사용에서 오는 사고는 대개 이런 모양입니다 — 작고, 눈에 잘 안 띄고, 걸리는 순간 전부를 무효로 만듭니다.

AI를 쓰면 만드는 속도가 빨라집니다. 정확히 같은 만큼, 물려받는 양도 늘어납니다. 이번에 내가 쓴 문장의 비율은 계속 줄어들고 있습니다. 그런데 검토 습관은 아직 “내가 쓴 것을 검토한다”에 머물러 있습니다.

바꿀 건 하나입니다. 검토를 시작할 때 던지는 질문을요.

“이번에 바꾼 게 맞나?”가 아니라, “이번에 안 바꾼 것 중에 여기 있으면 안 되는 게 있나?”