얼마 전, 저는 AI가 자신의 "완료" 상태를 신뢰하는 대신 회의적인 타인으로서 자신의 코드를 직접 리뷰하게 함으로써 3개의 버그를 잡아낸 것에 대해 글을 쓴 적이 있습니다.

이번에 그 일이 다시 일어났습니다. 동일한 세션 내에서, 완전히 다른 두 종류의 작업에 대해 두 번이나 발생했습니다. 그리고 그 중 어느 것도 코드가 아니었습니다.

첫째, 오보 (제가 거짓 경보를 울리지 않는다는 것을 알기 위해)

저는 개발 환경을 한 드라이브에서 다른 드라이브로 마이그레이션(migration)하고 있었습니다. 진행 도중, 한 폴더에서 약 12,000개의 파일이 누락되었습니다. 제 어시스턴트(assistant)는 이를 마이그레이션 사고 가능성으로 표시했습니다.

알고 보니 아니었습니다. 그 폴더는 가상 환경(virtual environment) — 프로젝트마다 새로 구축하는 일회용 도구 상자 — 이었으며, 이동 대상에서 의도적으로 제외되었습니다 (해당 폴더는 .gitignore에 바로 명시되어 있었고, 새 위치에서 새로 구축하라는 메모가 있었습니다). 파일들이 누락된 이유는 누락되는 것이 맞았기 때문입니다. 파일들은 이전 경로로 하드코딩(hardcoded)되어 있었고, 어차피 불필요한 데이터였을 것입니다.

최악의 상황을 가정하기 전에 확인을 했습니다. 이 점을 언급할 가치가 있는데, 왜냐하면 이 이후의 모든 사례는 이와 정반대였기 때문입니다. 즉, 괜찮아 보였지만 그렇지 않았던 두 가지 사례입니다.

사례 1: 제가 볼 수 없었던 3가지 허점이 있는 보안 체크리스트

저는 제 앱 여러 개에 적용될 감사 체크리스트(audit checklist) 작성을 막 마친 상태였습니다. 즉, AI가 보안 문제를 점검할 때 따라야 할 규칙들입니다. 내용을 다시 읽어보았을 때 견고해 보였고, 거의 완료했다고 생각했습니다.

대신, 저는 규칙 세트(ruleset)만 두 번째 AI에게 전달하며 그것을 무너뜨려 보라고 요청했습니다.

그 결과 세 가지 허점이 발견되었습니다:

1. 모든 발견 사항이 자동으로 차단 요소(blocker)로 취급되었습니다. 엄격하게 들릴 수 있지만, 이는 사실 탈출구(escape hatch)를 만듭니다. 발견된 내용이 짜증스러울수록, 그것을 단순히 "범위 외(out of scope)"로 재정의하여 그냥 넘어가 버리고 싶은 유혹이 커지기 때문입니다. 미묘한 차이(nuance)가 없는 규칙은 조용히 자기 승인(self-approval)을 유도합니다.
2. "해결됨으로 표시(Marked as resolved)"하는 데 증거가 필요하지 않았습니다. 실제 증거를 첨부하지 않고 그저 확인한 것 같은 "느낌"만으로 점검 항목을 수정된 것으로 표시하는 것을 막을 수 있는 장치가 없었습니다.
3. 권한 설정이 실제로 무엇을 하는지가 아니라, "활성화(enabled)" 여부에 따라 등급이 매겨졌습니다. 권한은 기술적으로 켜져 있을 수 있지만, 설정이 너무 느슨하여 무엇이든 통과시켜 버릴 수 있습니다. 단순히 설정 플래그(config flag)를 읽는 것이 아니라, 실제로 액세스(access)를 테스트해야 합니다.

체크리스트를 작성하는 동안에는 이 중 어느 것도 떠오르지 않았습니다. 작성하지 않은 사람이 읽고 나니 세 가지 모두 명백했습니다.

사례 2: 원문에서 조용히 벗어난 스타일 요약본

다음 날, 별도의 작업이 있었습니다. 명확하게 글을 쓰는 방법에 대한 스타일 가이드(style guide)를 읽고, 문장 길이, 단락 구분 등과 같은 짧은 규칙 세트로 요약했습니다.

저는 동일한 제2의 의견(second-opinion) 프로세스를 사용하여 제 요약본이 원본 소스와 일치하는지 한 줄씩 대조하며 확인해 달라고 요청했습니다.

두 가지 결과가 나왔습니다:

• 저는 "문장당 약 20자"라고 작성했습니다. 하지만 원문은 실제로 "20자 이하"라고 되어 있었습니다. 부드러운 제안이 제가 만들어낸 엄격한 제한(hard limit)으로 변질된 것입니다.
• 저는 "의미 단위(unit of meaning)"에 대한 50자 제한이라는 두 번째 숫자를 추가했는데, 이는 원문의 어디에도 존재하지 않는 내용이었습니다. 다른 곳에서 본 것을 어렴풋이 기억해 낸 것이 원문에 적혀 있었던 것처럼 제 노트에 조용히 합쳐진 것이 분명했습니다.

그리고 이것은 단순히 느낌(vibes)에 기반한 이의 제기가 아니었습니다. 원본 문서에 대한 실제 한 줄씩의 계수(line-by-line count)를 통해 뒷받침되었습니다. 평균 문장 길이는 13자였습니다. 문서 전체에서 20자를 초과하는 줄은 단 4줄뿐이었고, 그중 하나는 의도적으로 작성된 "나쁜 예시(bad example)"였습니다.

왜 이런 일이 계속 발생할까요?

이 중 어느 것도 코드가 아니었습니다. 하나는 제가 작성한 규칙이었고, 다른 하나는 제가 작성한 요약이었습니다. 두 번 모두 결과는 같았습니다.

가장 적절한 설명은 이렇습니다. 무언가를 직접 작성한 당사자라면, 작성할 당시 가졌던 의도를 바탕으로 그것을 읽게 됩니다.