손에 쥐여줄 수 없는 도구를 검증받는 법: 프로그램 대신 출력을 검토받기로 한 결정

3줄 요약

배포를 아직 막아둔 법률 문서 도구를 외부 전문가에게 검증받으려는데, 도구 자체를 손에 쥐여줄 수 없어서 프로그램 대신 도구가 실제로 뽑아낸 출력물을 검토받기로 결정하고, 검토 킷과 모집글을 정직하게 다시 설계했다.
이게 중요한 이유는 외부 검증의 신뢰가 검토자에게 무엇을, 어떻게 보여주느냐에 전부 달려 있기 때문이다. 편하게 세팅하는 순간 검증은 통과 도장을 받는 요식행위로 전락한다.
빌더에게 남는 교훈은 하나다. 검증받는 쪽은 검토자를 자기에게 유리하게 세팅하고 싶은 유혹을 매 단계 접어야 한다. 정직한 검증은 만든 사람에게 불편하도록 설계된다.

도구를 못 주는데 검증은 받아야 한다

외부 검증은 검토자가 무엇을 손에 쥐느냐로 성패가 갈린다. 문제는 정면으로 드러났다. 법률 전문가 검토자를 모집하는 글을 올렸는데, 곧바로 현실적인 구멍이 보였다. 모집은 해놓고 정작 "당장 프로그램을 달라"고 하면 무엇을 줄 것인가. 이 도구는 아직 배포를 막아둔 상태라 손에 쥐여줄 물건이 없었다.

여기서 갈림길은 두 개였다. 하나는 검토자에게 도구를 직접 만지게 하는 핸즈온 방식, 다른 하나는 도구를 주지 않고 결과만 검토받는 방식이었다. 결정은 후자였다. 합성 사건 케이스를 만들고, 그 케이스를 실제로 도구에 돌려 나온 화면과 리포트를 정리해 검토자에게 넘긴다. 검토자는 그 출력이 타당한지, 어디서 사람을 오도할 위험이 있는지를 평가한다.

이 선택에는 이유가 셋 있었다. 배포를 미뤘으니 프로그램을 넘길 수 없다는 것이 첫째. 검토 킷 설계 자체가 이미 "실제 출력을 보존해 평가한다"는 구조라 손으로 직접 만질 필요가 없다는 것이 둘째. 모든 검토자가 똑같은 출력을 보면 비교가 깔끔하다는 것이 셋째. 직접 만져봐야 한다는 요청이 나오면 공개 없이 화상으로 라이브 시연을 하거나, 정식 공개 준비 후 비공개 링크로 2차를 여는 길을 남겨뒀다.

모집글에서 과장을 걷어내다

정직한 검증은 검증받을 물건을 정직하게 소개하는 데서 시작한다. 처음 쓴 모집글 초안에는 지금 상태와 충돌하는 표현이 섞여 있었다. "안전성과 기술 검증이 사실상 완료됐다"는 문장은 아직 공동 판정 중인 현실과 어긋나서 삭제했다. "외부 전송이 없다는 것을 독립 실측으로 검증했다"는 표현은 범위와 독립성을 부풀린 것이었다. 지금까지의 계측은 전부 만든 팀이 스스로 한 것이지, 만들지 않은 사람이 독립적으로 재현한 것이 아니었다. 그래서 "개발팀 자체 계측이며 비구현자의 독립 재현은 진행 중"이라고 정직하게 병기했다.

기능 설명도 낮췄다. 확정된 사실처럼 쓰던 문장을 "시제품 개발 중", "누락 후보", "확인이 필요한 지점"으로 완화했다. 검토자에게 잘 보이려고 부풀린 말은 나중에 검증을 통과시키는 게 아니라 검증 자체를 무의미하게 만든다.

검토가 편향되지 않도록 킷을 설계하다

블라인드 검토의 핵심은 검토자가 기대되는 정답을 미리 알 수 없게 만드는 것이다. 검토 킷 2차 설계는 케이스 20건으로 짰다. 실제 신호가 있는 케이스 9건, 아무 문제 없는 정상 문서를 섞는 음성 대조군 5건, 그리고 특수 상황을 다루는 커버리지 케이스 6건이다. 음성 대조군을 4분의 1로 넣은 이유는 도구가 아무것도 없는 곳에서 없는 것을 지어내지 않는지를 봐야 하기 때문이다.

배포본에서는 케이스 순서를 무작위로 섞고, "이건 신호 케이스", "이건 대조군" 같은 라벨을 전부 떼어냈다. 어느 것이 정답이 있는 케이스인지 검토자가 눈치채면 검토가 오염된다. 정답 라벨과 기대 방향은 교차 검토용 내부 문서에만 두고, 배포본에는 중립적인 번호만 남겼다. 채점도 두 사람이 독립적으로 하고, 오독과 실제 위반을 구분하는 절차를 넣었다. 검토자가 단어를 잘못 읽은 것과 도구가 실제로 틀린 것은 전혀 다른 문제니까.

오늘 하루를 관통한 판단

세 결정을 관통하는 실은 하나였다. 무엇을 검토받을지, 도구를 어떻게 소개할지, 킷을 어떻게 짤지 매 갈림에서 나에게 편한 쪽과 검증에 정직한 쪽이 갈렸고, 매번 정직한 쪽이 나에게 더 불편했다.

정직한 검증은 원래 그렇게 생겼다. 검토자를 유리하게 세팅하고, 자랑스러운 결과만 보여주고, 정답을 흘려주면 통과는 쉬워지지만 그 통과는 아무 가치가 없다. 만든 사람이 불편하도록 설계된 검증만이 바깥에 신뢰를 만든다. 출시는 이 검증이 끝날 때까지 여전히 멈춰 있다.