화면에 분명히 있는 글자인데 코드는 없다고 판정했다

무엇이 이상했나

브랜드 언급 여부를 자동으로 판정하는 도구에서, 화면에는 브랜드 이름이 분명히 보이는 결과를 “언급 없음”으로 저장한 사례가 나왔다.

원인을 어떻게 찾았나

같은 상황을 인위적으로 재현해 보니, 같은 한글 문자열이라도 컴퓨터 내부에서 두 가지 다른 방식으로 표현될 수 있다는 것이 원인이었다. 하나는 완성된 글자 형태로 저장되는 방식이고, 다른 하나는 자음과 모음이 분해된 채로 저장되는 방식이다. 사람 눈에는 완전히 같은 글자로 보이지만, 판정에 쓰인 정규식은 그중 한 형태만 인식하도록 짜여 있었다. 분해된 형태로 들어온 문자열은 그 정규식을 통과하지 못해 “일치하지 않음”으로 처리됐다.

어떻게 고쳤나

세 겹으로 대응했다. 첫째, 문자열을 비교하기 전에 항상 같은 정규화 방식으로 통일하고 눈에 보이지 않는 폭 없는 문자와 줄 바꿈 없는 공백도 함께 정리했다. 둘째, 일반 텍스트와 화면에 렌더링된 텍스트 양쪽에서 각각 독립적으로 검사한 뒤 결과를 합치도록 해서, 한쪽 추출 방식에서만 실패해도 다른 쪽이 잡아내게 했다. 셋째, 그래도 브랜드 이름이 문자열 어딘가에 있는데 정규식이 “없음”이라고 판정하면 그 결과를 뒤집고 모순 발생을 표시해 사람이 볼 수 있게 하는 안전망을 뒀다.

왜 눈으로 봐서는 못 잡는 문제인가

두 형태의 문자열은 화면에 렌더링되면 완전히 똑같이 보인다. 사람이 결과 화면을 눈으로 검토해서는 이 문제를 발견할 방법이 없고, 코드로 두 형태를 각각 재현하는 테스트를 만들어야만 잡을 수 있는 종류의 버그였다.

이 사건에서 얻은 교훈

문자열이 “같아 보인다”는 것과 “코드 상 같다”는 것은 다른 문제일 수 있다. 특히 여러 시스템을 거쳐 들어오는 텍스트를 비교할 때는, 비교하기 전에 형태를 통일하는 절차 자체를 설계에 포함해야 한다. 그리고 자동 판정이 확신을 갖고 틀릴 수 있는 지점에는, 그 확신을 뒤집을 수 있는 별도의 안전망을 둬야 한다.