검사가 전부 통과했다는 결과를 보고, 다 됐다고 말할 뻔한 적이 있었습니다. AI가 저에게 소위 할루시네이션, 거짓을 고한 것도 아니었습니다. 검사는 정해진 대로 돌았고, 저는 본 대로 말하려 했을 뿐이죠. 문제는 그 통과했다는 결과가 정확히 무엇을 검증하고 있었는지, 제가 확인하지 않았다는 데 있었습니다.
중요한 고객사의 일을 맡아 만들던 중에 생긴 일이었습니다. 저는 무언가를 만들면 그걸 검사하는 장치도 같이 만들어 두는 편입니다. 사람 눈으로 매번 처음부터 다시 볼 수는 없으니까요. 그런데 검사를 많이 만들수록, 그 검사들이 무엇을 보장하는지 따져 보는 일은 오히려 줄어들더군요. 초록불이 잔뜩 켜져 있으면 다 괜찮아 보이거든요.
첫째는 검사가 엉뚱한 자료 위에서 돌고 있었던 일입니다.
검사 수백 개가 날마다 통과하고 있었습니다. 그러다 실제로 쓰일 자료와 같은 모양의 자료를 넣고 처음으로 돌려 봤는데, 여덟 건이 깨졌습니다. 그날 바뀐 건 프로그램이 아니라 넣은 자료뿐이었어요. 알고 보니 검사를 돌리던 시험용 자료가 실제와는 꽤 다른 세상이었습니다. 규칙의 개수도 항목의 구성도 달랐고, 시험하면서 어질러 놓은 흔적까지 남아 있었죠.
그러니까 수백 개의 통과는 그동안 실제 상황을 한 번도 증명한 적이 없었던 겁니다. 시험용 자료에서 잘 돈다는 것만 증명하고 있었던 거죠. 검사의 값은 몇 개가 도느냐보다 무엇을 확인하느냐에서 나오는데, 같은 검사라도 넣는 자료가 다르면 다른 것을 검사하게 됩니다.
그 뒤로는 무언가 통과했다고 말하기 전에 어느 자료에서 돌았는지를 먼저 확인합니다. 답이 시험용 자료라면, 그건 시험용 자료에서 잘 돈다는 걸 확인했을 뿐이라고 적어 둡니다. 듣기엔 같은 통과인데, 적어 놓고 보면 꽤 다른 말이더군요.
둘째는 검사가 아무것도 못 잡으면서 이상 없음을 찍고 있었던 일입니다.
화면에서 흔히 생기는 실수를 찾아내는 점검 장치를 만들어 돌렸더니 세 건이 나왔습니다. 그럴듯했어요. 그런데 일부러 실수를 심어 둔 연습용 화면을 따로 만들어 같은 점검을 돌려 보니, 여섯 단계 중 하나가 심어 둔 걸 하나도 못 잡더군요. 들여다보니 그 단계는 따옴표 한 종류만 보고 있었습니다. 마침 그 회사 코드가 그 따옴표를 쓰고 있어서 그때까지 우연히 잡혔던 거고요. 다른 습관으로 짠 코드를 만났다면 그 단계는 통째로 헛돈 채 이상 없음만 찍었을 겁니다.
저는 아무것도 못 잡는 점검이 아예 안 한 것보다 나쁘다고 생각합니다. 돌렸다는 안심을 주니까요. 게다가 바깥에서 보면, 멀쩡해서 조용한 점검과 돌지 않아서 조용한 점검을 구분할 방법이 없거든요. 그래서 같은 점검 장치를 다른 회사 일에 가져갈 때는 연습용 화면부터 돌려 봅니다. 코드를 쓰는 습관이 회사마다 달라서, 같은 규칙이 어디서 조용히 헛돌지 미리 알 수가 없으니까요.
셋째는 검사를 돌리는 장치 자체가 실패를 성공으로 넘기고 있었던 일입니다.
검사 여러 개를 한꺼번에 돌려 주는 장치가 있었는데, 중간에 하나가 에러를 내도 마지막에는 끝까지 잘 돌았다는 신호를 내는 설정으로 되어 있었습니다. 그래서 몇몇 변경은 깨진 채로 전부 통과를 받고 지나갔죠. 이게 드러난 것도 검사 덕분이 아니었습니다. 전혀 다른 걸 시험해 보려고 일부러 틀린 파일을 하나 넣었는데, 통과가 떴거든요.
그 무렵 실제로 깨진 변경이 이미 하나 지나가고 있었는데, 그걸 먼저 짚은 것도 검사가 아니라 "실패하면 고쳐야 하는 거 아닌가?"라는 질문 한마디였습니다. 그 질문을 붙잡고 파 내려가 보니, 그렇게 깨진 채 지나간 변경이 모두 네 건이었습니다. 채점표는 꼼꼼히 시험해 봤는데, 정작 시험장은 한 번도 들여다보지 않은 셈이었어요. 돌이켜 보면 그 장치를 의심할 이유가 없었습니다. 늘 통과가 떴으니까요. 의심할 이유가 없다는 것 자체가 신호였는데, 그때는 그렇게 보이지 않았습니다. 인지편향이었습니다.
세 장면을 나란히 놓으면 같은 모양이 보입니다. 통과 결과는 원래 이 조건에서 이걸 검사해봤더니 괜찮았다는 뜻인데, 저는 매번 앞의 조건을 빼고 괜찮았다는 말만 읽었습니다. 그리고 그 조건이 잘못됐다는 사실은 검사가 실패하는 모습을 보고 나서야 드러났습니다. 검사가 실패하는 모습을 한 번도 본 적이 없다면, 그 검사의 통과 결과는 아무것도 보장하지 않습니다.
그래서 지금은 검사를 새로 만들거나 고칠 때마다, 그 검사를 일부러 깨뜨려 보는 한 줄을 같이 만듭니다. 심어 둔 문제를 전부 잡는지, 멀쩡한 것에서는 아무것도 안 나오는지까지 봅니다. 통과보다 실패를 먼저 확인하는 셈이죠. 완료했다고 적는 순간에도 마찬가지입니다. 기록에 완료라고 쓰기 전에, 그 자리에서 한 번 더 돌려 보고 그 결과를 근거로 씁니다.
보고서에 통과라는 말이 한 번 적히면, 그 통과가 무엇을 검증했는지 다시 묻는 사람은 거의 없습니다. 저도 그랬고요. 이건 만드는 쪽의 얘기지만, 보고를 받는 쪽에서도 동일할 수 있다고 생각합니다. IT 담당자가 따로 없는 회사라면 개발을 맡긴 곳에서 테스트를 다 통과했다는 보고를 받으실 일이 많을 텐데요. 저는 제 일에 다 통과했다고 말하기 전에 이 네 가지를 스스로에게 먼저 따져 봅니다.
1. 그 검사는 어떤 자료로 돌렸는가? 시험용 자료라면 실제로 쓰실 자료와 같은 모양인지까지 함께 확인해야 합니다.
2. 그 검사가 실패하는 걸 본 적 있는가? 일부러 틀린 걸 넣었을 때 정말 잡아내는지, 한 번이라도 확인했는지가 중요합니다.
3. 이상 없음이 나왔을 때, 검사가 정말 끝까지 돌았다는 건 어떻게 알 수 있는가? 중간에 멈추고도 통과를 내는 경우가 있습니다.
4. 고객께 직접 한 번 돌려보시게 했는가? 기록에 적힌 완료보다 눈앞에서 다시 도는 게 훨씬 믿을 만합니다.
물론 이 네 가지로 다 걸러진다고 장담하진 못합니다. 검사를 검사하는 일도 결국 어딘가에서 멈춰야 하는데, 그 선을 어디에 긋는 게 맞는지는 아직 일마다 다르게 정하고 있습니다.
제가 그날 크게 깨달은 건, 테스트의 성공 기준을 무엇으로 정의할 것인가? 이었습니다.