1차 결함리포트 20건 중 12건이 사용성이었고, 그 대부분은 코드가 아니라 매뉴얼을 향해 있었습니다. 화면과 매뉴얼 사진이 다른 페이지가 45곳 이상 지목됐고, 프로그램의 기능명과 매뉴얼의 기능명이 달랐고, 제공되는 기능인데 설명이 없는 항목이 열 줄 넘게 나열됐습니다. 시험은 소프트웨어와 문서를 별개로 채점하지 않았습니다. 문서가 틀리면 제품이 틀린 것이었습니다.
마지막 편에서는 문서와 언어, 권한처럼 코드 바깥에 있다고 생각했던 것들이 결함이 된 과정과, 3주가 끝나고 남은 기준을 정리합니다.
기능과 문서가 서로 다른 제품을 설명하고 있었습니다
매뉴얼 결함의 목록은 구체적이었습니다. 노드를 드래그 앤 드롭으로 추가하라고 적혀 있지만 실제로는 클릭으로만 추가되는 페이지, '채팅이력'이라는 화면 기능이 '실행이력'으로 적힌 문서, GraphRAG 쿼리처럼 보편적이지 않은 용어에 설명이 없는 항목. 하나하나는 사소하지만 합쳐지면 사용자가 문서를 신뢰하지 않게 되는 이유가 됩니다.
원인은 명확했습니다. UI는 매주 바뀌는데 매뉴얼은 PDF로 묶여 배포 주기가 따로 놀았습니다. 스크린샷을 다시 찍어 문서를 고치는 속도가 제품이 바뀌는 속도를 이길 수 없는 구조였습니다.
PDF 매뉴얼을 버리고 위키로 옮겼습니다
그래서 매뉴얼 결함의 근본 대응은 오탈자 수정이 아니라 매체 전환이었습니다. 6월 11일 MkDocs 기반의 솔루션 가이드를 만들어 제품 안에 탑재했고, 6월 15일 제품의 기술지원 메뉴가 이 가이드를 열도록 연결했습니다. 문서가 코드와 같은 저장소 흐름을 타면 UI 변경과 문서 변경을 같은 호흡으로 배포할 수 있고, 검색이 되고, 페이지 단위 링크로 특정 기능 설명을 바로 가리킬 수 있습니다.
시험 회신에도 이 방향을 그대로 적었습니다. 처음 제출한 매뉴얼은 주요 기능 중심의 문서였고, 전체 기능은 온라인 가이드로 이관 중이라는 내용이었습니다. 결함 대응이 일회성 수정으로 끝나지 않고 문서 운영 방식 자체를 바꾼 유일한 사례였습니다.
한글 입력과 언어 설정 같은 기본을 다시 챙겼습니다
사용성 결함에는 문서 밖의 항목도 있었습니다. 여섯 개 화면의 검색창에서 한글 입력 시 글자가 뭉개진다는 지적이 있었는데, 원인은 IME 조합이었습니다. 한글은 자모가 조합되는 동안 composition 이벤트가 진행되는데, 이 도중에 외부 상태 동기화가 input 값을 덮어쓰면 조합이 깨집니다. 6월 12일 조합 중에는 외부 값 동기화를 멈추고 조합이 끝나는 시점에 최종 값을 전파하는 공통 검색 입력 컴포넌트로 정리했습니다.
언어 설정도 같은 계열이었습니다. 캔버스 우클릭 메뉴가 영어로 고정돼 있었고, 사이트를 영어로 설정해도 AI 채팅 답변은 한국어로 왔습니다. 메뉴는 사용자 언어 설정을 따르게 하고, AI 답변은 사이트 언어 설정을 프롬프트에 연동해 해당 언어로 답하도록 바꿨습니다. 삭제 버튼에 확인 대화상자가 없던 세 개 화면, 업로드 가능한 확장자와 크기 안내가 없던 업로드 화면들, 권장 해상도 정보가 어디에도 없던 문제도 이 기간에 함께 정리했습니다. 권장 해상도는 기술지원 메뉴에 전용 페이지를 새로 만들었습니다.
권한이 없는 기능은 에러가 아니라 부재로 만들었습니다
시험 계정으로 사용자 삭제를 누르면 "사용자 삭제에 실패했습니다"만 떴습니다. 원인은 버그가 아니라 권한이었습니다. 삭제는 superuser 권한인데 시험 계정은 일반 관리자였고, 그렇다고 superuser를 주면 시험 범위 밖 화면이 전부 열리는 문제가 있었습니다. 시험기관의 요청은 명쾌했습니다. 권한이 없어 동작하지 않는 기능이라면 화면에서 보이지 않게 해 달라는 것이었습니다.
이 요청을 계기로 시험 범위와 계정 권한을 일치시키는 작업을 했습니다. 시험 계정에서 접근 제어 화면을 숨기고, 시험 범위 밖의 노드와 옵션은 노출 자체를 껐습니다. 실패할 수밖에 없는 버튼을 보여 주고 에러를 내는 것보다, 처음부터 보이지 않는 쪽이 정직한 UI라는 결론이었습니다.
인증이 끝나고 남은 것
6월 10일의 3차 리포트가 마지막 결함리포트였고, 접수된 80건은 모두 수정완료로 회신을 마쳤습니다. 돌아보면 이 3주 동안 한 일의 대부분은 새 기능이 아니라 이미 있던 기능을 사용자에게 설명 가능한 상태로 만드는 일이었습니다. 실패는 실패라고 말하고, 옵션은 관찰 가능한 차이를 만들고, 정책은 안내 문구를 갖추고, 문서는 제품과 같은 속도로 움직이게 하는 것.
GS인증은 통과가 목적인 시험이었지만, 남은 것은 시험용 수정이 아니었습니다. "사용자가 화면만 보고 이 동작을 이해할 수 있는가"라는 질문은 인증이 끝난 뒤에도 코드 리뷰마다 따라옵니다. 결함리포트 80건은 그 질문을 80번 반복해서 훈련시킨 셈입니다.
이전 편 → 설정을 바꿔도 결과가 같으면 결함입니다 (4편)
시리즈 처음부터 → GS인증 결함리포트 80건에서 결함의 정의를 다시 배웠습니다 (1편)