소프트웨어 검토에서 가장 곤란한 결과는 실패가 아니다. 잘 작동하는데 들여올 이유가 없는 결과다.
이번에 살펴본 것은 색상·서체·차트·기술 스택을 검색해 UI/UX 작업을 돕는 공개 도구였다. 저장소에는 662개 파일이 있었고, 핵심 로컬 검색 엔진은 단위 테스트 153개를 모두 통과했다. 도메인 스모크 테스트는 12/12, 기술 스택 스모크 테스트는 22/22였다. 검색 결과도 나왔고 데이터 검증도 끝났다. 여기까지만 보면 설치 버튼으로 손이 갈 만하다.
그런데 테스트가 답한 질문은 “핵심 검색 엔진이 설계대로 작동하는가”였다. 내가 답해야 했던 질문은 “이 배포물 전체를 기존 UI 작업 절차에 들일 만한가”였다. 둘은 같은 문장이 아니다.
| 확인한 증거 | 증거가 말해 주는 것 | 말해 주지 않는 것 |
|---|---|---|
| 단위 테스트 153개 통과 | 핵심 로컬 검색 엔진의 현재 동작 | 전체 배포물의 채택 가치 |
| 도메인 12/12, 스택 22/22 | 정해진 검색 범위의 응답 가능성 | 기존 절차보다 나은 디자인 판단 |
| 662개 파일과 넓은 카탈로그 | 후보를 많이 꺼낼 수 있는 범위 | 유지보수 비용과 충돌이 작다는 보증 |
범위를 넓혀 보니 명령줄 도구에는 홈 디렉터리와 전역 환경 설치, 강제 덮어쓰기, 전역 npm 자동 업데이트, 재귀 삭제가 들어 있었다. 별도 설정 경로는 Playwright와 브라우저 패키지를 설치했고, 함께 묶인 보조 도구들은 외부 이미지·모델 API와 프로젝트 파일 생성까지 다뤘다. 이것을 악성이라고 부를 근거는 없었다. 다만 읽기 전용 카탈로그 검색을 얻기 위해 떠안을 실행 표면으로는 너무 컸다.
중복도 컸다. 기존 UI 검토 절차는 프로젝트 토큰 우선순위, 접근성, 컴포넌트 상태, 모션 생명주기, 실제 렌더링 증거를 이미 더 엄격하게 다루고 있었다. 새 도구가 분명히 채울 수 있는 틈은 방대한 정적 카탈로그를 검색하고, 검색 품질을 고정된 예제로 시험하는 부분뿐이었다. 전체 교체보다 작은 조회 기능 하나가 더 정확한 처방이었다.
그래서 결론은 설치도 포크도 교체도 아니다. 참고 자료로만 고정해 두고, 실제 UI 작업에서 같은 종류의 카탈로그 조회 실패가 두 번 생길 때까지 기다린다. 그때 필요한 한 분야만 골라 네트워크 연결, 패키지 설치, 프로젝트 쓰기가 없는 읽기 전용 도구로 다시 만든다. 고정 테스트와 출처·라이선스 기록까지 통과한 뒤에야 채택을 다시 논의한다.
테스트가 초록색이라는 사실은 존중할 만하다. 하지만 초록불은 도구가 자기 일을 했다는 증거이지, 내가 그 도구의 모든 짐을 맡아야 한다는 명령은 아니다. 이번 검토에서 통과한 것은 소프트웨어였고, 보류된 것은 도입이었다.