'다음엔 조심하겠습니다'는 대책이 아닙니다

들어가며 — 초록 불 네 개, 그리고 하얗게 죽은 화면

규칙이 촘촘한 도메인 하나를 학습용 앱으로 옮기는 개인 작업을 하고 있습니다. 어제는 AI에게 기능 하나를 더 붙여달라고 했고, 붙여줬습니다. 그리고 검사를 돌렸습니다.

자동 테스트 1,113개 통과. 타입 검사 통과. 문법 검사 통과. 빌드 통과.

초록 불 네 개. 보통은 여기서 손을 뗍니다. 저는 앱을 열어 몇 번 눌러봤습니다. 세 번째 클릭에서 화면이 하얗게 죽었습니다.

이상한 건, 앞의 두 번은 멀쩡했다는 겁니다. 특정 버튼을 누르는 그 순간에만 죽었어요. 콘솔에는 이렇게 적혀 있었습니다 — “아직 만들지도 않은 물건을 쓰려고 했다.”

여기서 대부분은 이렇게 정리합니다. “아, 검사가 부실했구나. 다음엔 더 조심해야지.”

둘 다 틀렸습니다. 검사는 부실하지 않았고, 조심은 대책이 아닙니다.

1. 통과는 “맞다”가 아니라 “내가 물어본 것만 맞다”

같은 날 앞서 이런 일도 있었습니다. 테스트 896개가 전부 초록인데, 앱이 구현한 규칙이 틀려 있었습니다.

왜 초록이었을까요. 답은 싱겁습니다. 아무도 그걸 묻지 않았기 때문입니다. 저는 “A가 제대로 쪼개졌나”는 물었고, “그때 B도 함께 따라가나”는 묻지 않았습니다. 묻지 않은 질문에 대해 기계가 “아니오”라고 답해줄 리가 없죠. 그래서 896개는 정직하게 초록이었습니다.

이건 코드 이야기가 아닙니다. 사무실에서 매일 벌어지는 일입니다.

엑셀에 수식 오류가 없다는 건, 숫자가 맞다는 뜻이 아닙니다. 참조가 깨지지 않았다는 뜻입니다.
보고서에 출처가 붙었다는 건, 그 출처가 그 말을 한다는 뜻이 아닙니다. 각주가 달렸다는 뜻입니다.
맞춤법 검사를 통과했다는 건, 글이 맞다는 뜻이 아닙니다.

검사는 자기가 받은 질문에만 답합니다. 그래서 “검사를 통과했다”는 문장은 언제나 생략된 절반을 갖고 있습니다 — 내가 물어본 것에 한해서.

2. 검사기는 틀린 게 아니라, 다른 걸 봅니다

앞의 하얗게 죽은 화면으로 돌아가면 — 타입 검사가 그걸 못 잡은 건 버그가 아니라 정상입니다. 타입 검사는 “이 순서로 실행될 때 문제가 생기나”를 보는 도구가 아니거든요. 그건 다른 도구의 일입니다. 타입 검사는 틀리지 않았습니다. 그냥 다른 걸 보고 있었을 뿐입니다.

정리하면 이날 하루에 등장한 검사기는 종류가 다 달랐습니다.

자동 테스트는 계산이 맞는지 봅니다.
원문 대조는 규칙이 맞는지 봅니다.
직접 눌러보기는 화면이 맞는지 봅니다.

셋은 서로를 대신하지 못합니다. 계산이 맞아도 규칙이 틀릴 수 있고, 규칙이 맞아도 화면이 죽을 수 있습니다. 그런데 우리는 초록 불 하나를 보고 나머지 둘까지 통과했다고 느낍니다. 이게 무검증보다 위험한 이유입니다 — 초록 불은 안심을 주고, 안심은 사람의 눈을 끕니다.

검사 세 겹이 모두 초록이어도, 아무도 보지 않는 결함은 그대로 통과한다. 한 번 데인 뒤에 할 일은 다짐이 아니라 게이트를 만드는 것이고 — 그 게이트가 진짜 잡는지까지 시험하는 것이다.

여기까지가 진단입니다. 문제는 그다음에 무엇을 하느냐입니다.

3. “다음엔 조심하겠습니다”는 대책이 아닙니다

죽은 화면의 원인은 어이없을 만큼 간단했습니다. 어떤 함수가 파일 아래쪽에 있었고, 그걸 쓰는 계산이 위쪽에 있었습니다. 고치는 데는 한 줄을 옮기면 끝이었어요.

그러면 대책은 뭘까요. “앞으로 선언 순서를 신경 쓰자”?

사람은 그걸 못 지킵니다. 파일이 2,000줄인데 매번 순서를 눈으로 훑을 수는 없습니다. 다짐은 첫 주에만 지켜지고, 둘째 주에는 잊히고, 셋째 주에는 다짐했다는 사실조차 잊힙니다. 그리고 우리는 이 실패를 늘 의지의 문제로 오해합니다.

그래서 다짐 대신 검사기를 하나 만들어 심었습니다. 40줄짜리입니다. “화면 계산이 자기보다 아래에 선언된 걸 쓰고 있으면 실패.” 이제 같은 실수를 하면 사람이 알아채기 전에 기계가 먼저 빨간 불을 켭니다.

이게 이 글에서 가장 하고 싶은 말입니다. 한 번 데인 결함은 “주의”가 아니라 “장치”로 막습니다.

회의 끝에 나오는 그 문장을 떠올려 보세요. “앞으로 유의하겠습니다.” 그 회의는 여섯 달 뒤에 같은 안건으로 다시 열립니다. 유의가 부족해서가 아닙니다. 유의는 원래 확장되지 않기 때문입니다. 사람의 주의력은 자산이 아니라 소모품이에요.

그러니 사고가 났을 때 물어야 할 질문은 “누가 놓쳤나”가 아니라 이겁니다.

“이걸 다음번엔 사람 대신 무엇이 막게 할 것인가?”

AI로 일할 때 이 질문의 값어치는 훨씬 커집니다. AI는 결과물을 사람이 검토할 수 있는 속도보다 빠르게 만들어내니까요. 매번 사람의 주의력으로 걸러내겠다는 계획은, 그 속도 앞에서 반드시 집니다. 걸러내는 일 자체를 장치로 옮겨야 합니다. 문서 템플릿, 자동 대조표, 필수 확인 항목, 원문 링크 강제 — 이름은 뭐든 좋습니다. 핵심은 그게 사람의 기억 밖에 있어야 한다는 겁니다.

4. 그리고, 그 장치가 진짜 작동하는지 시험합니다

여기서 한 걸음 더 갔습니다. 검사기를 심고 나서, 일부러 위반한 가짜 코드를 만들어 넣어봤습니다. 검사기가 그걸 잡아내는지 확인하려고요.

왜 그랬을까요. 검사기가 조용히 아무것도 안 잡고 있을 수 있기 때문입니다.

조건을 잘못 써서 늘 통과시키는 검사기는, 밖에서 보면 정상 검사기와 완벽하게 똑같이 생겼습니다. 둘 다 초록 불을 켭니다. 차이는 하나뿐이에요 — 하나는 지켜보고 있고, 하나는 자고 있습니다. 그리고 자고 있는 검사기는 없는 검사기보다 나쁩니다. 없으면 불안해서 직접 보기라도 하니까요.

이 질문을 조직으로 가져오면 꽤 아픕니다.

우리 팀 체크리스트, 지난 1년간 실제로 무엇을 걸러낸 적이 있습니까?

한 번도 빨간 불이 켜진 적 없는 검사는 두 가지 중 하나입니다. 정말로 아무 문제가 없었거나, 아무것도 보고 있지 않거나. 대개는 후자입니다. 그리고 우리는 그 초록 불을 근거로 결재를 올립니다.

장치를 만들었으면, 그 장치를 시험해야 합니다. 틀린 걸 일부러 한 번 흘려보내고, 그게 걸리는지 봅니다. 안 걸리면 장치가 아니라 장식입니다.

5. 그래서, AI에게 일을 맡기는 모든 사람에게

검증할 수 있는 만큼만 맡길 수 있다고 쓴 적이 있습니다. 검증력이 위임의 한계선이라고요. 오늘 글은 그 문장의 다음 칸입니다.

내 검증이 무엇을 보고 있는지 모르면, 통과는 안심이 아니라 마취입니다.

AI가 “완료했습니다”라고 말할 때, 그건 대개 “시키신 걸 만들었습니다”라는 뜻입니다. 맞다는 뜻이 아니에요. 그리고 우리가 돌린 검사는, 우리가 물어본 것에만 답했습니다. 그러니 결과물을 받아 든 자리에서 세 가지를 하면 됩니다.

무엇이 통과했는지 묻습니다. 초록 불을 보고 “다 됐네”가 아니라 “이 검사는 무엇을 본 거지”를 봅니다.
가장 중요한 것 하나는 원문과 대조합니다. 규칙·숫자·인용은 기계가 아니라 원문이 판정합니다.
한 번 데인 결함은 장치로 옮깁니다. 그리고 그 장치에 틀린 걸 한 번 흘려보내 봅니다.

코드를 읽든 못 읽든 상관없습니다. 오히려 코드를 잘 읽는 사람일수록 “코드가 맞으니 됐다” 에서 멈추고 싶어집니다. 못 읽는 사람은 어차피 눌러볼 수밖에 없고, 그래서 화면이 죽은 걸 먼저 봅니다. 여기선 그게 약점이 아니라 방어선입니다.

자동검사에는 “못 잡는 자리”가 아니라 “정당하게 안 잡는 자리” 가 있습니다. 그 자리를 아는 것, 그리고 그 자리를 다짐이 아니라 장치로 메우는 것 — 도구를 몇 개 아느냐보다 이게 훨씬 오래 남습니다.

초록 불 네 개를 지나 결과물을 깨뜨린 결함은, 아무도 보고 있지 않았습니다. 그때 필요한 건 더 큰 주의력이 아니라, 하나 더 만들어 심을 눈이었습니다.