흥미로운 AI 도구의 수는 이미 한 사람이 모두 평가할 수 있는 범위를 넘어섰습니다. 부족한 것은 도구가 아니라, 실제로 작동하는지 확인하는 데 쓸 수 있는 시간입니다.

다음은 그 시간을 효율적으로 쓰기 위한 절차입니다. 가능한 한 빨리 “도입하지 않는다”는 결론에 도달하는 쪽에 무게를 두었습니다.

데모가 아니라 실패 양상부터 살펴보기

모든 프로젝트는 잘하는 일을 먼저 보여 줍니다. 유용한 질문은 무엇을 못하는가이며, 그 답은 대개 README보다 이슈 트래커에 있습니다.

열린 이슈를 댓글이 많은 순서로 정렬하고 상위 10개를 읽어 보십시오. 아무리 많은 문서를 읽는 것보다 5분 안에 더 많은 정보를 얻을 수 있습니다.

인기보다 유지 관리 여부 확인하기

Star 수는 한때 몇 명이 흥미로워 보인다고 생각했는지만 보여 줍니다. 지금도 제대로 작동하는지는 알려 주지 않습니다.

더 나은 신호는 다음과 같습니다.

  • 종속성 업데이트가 아닌 최근 커밋의 날짜
  • 짧게라도 이슈에 답변이 달리는지
  • 최신 릴리스가 아직 존재하는 브랜치에서 만들어졌는지

Star가 800개뿐이어도 유지 관리자가 질문에 답하는 도구가, Star는 3만 개지만 2년 된 이슈가 쌓여 있는 도구보다 안전한 선택입니다.

실제 대상에서 실행하기

데모 저장소는 도구가 잘 보이도록 선택됩니다. 여러분의 저장소는 그렇지 않습니다.

이미 직접 완료한 작업을 맡겨 보십시오. 답을 알고 있으므로 추가 조사 없이 결과를 판단할 수 있습니다. 답을 아는 문제조차 처리하지 못한다면, 답을 모르는 문제도 처리하지 못할 것입니다.

도입하기 전에 이탈 비용 계산하기

중요한 질문은 “좋은가?”가 아니라 “사용을 중단하면 어떻게 되는가?”입니다.

기존 파일을 읽고 일반적인 형식으로 결과를 쓰는 도구는 거의 비용 없이 버릴 수 있습니다. 데이터를 자체 형식에 저장하거나 다른 시스템이 점차 그 도구에 의존하게 된다면 이야기가 달라집니다. 성능이 비슷하다면 되돌리기 쉬운 선택을 우선하십시오. 틀렸을 때 적은 비용으로 빠져나올 수 있는 능력을 사는 셈입니다.

평가를 멈출 시점

전체를 완벽히 이해했을 때가 아니라 답을 얻었을 때 멈추십시오. 대부분의 평가는 한 시간 안에 끝나야 하며, 흔히 “도입하지 않는다”는 결론과 이유를 한 줄로 남기게 됩니다. 다음에 같은 도구를 보더라도 평가를 반복하지 않기 위해서입니다.

그 메모는 나중에 다시 찾을 수 있는 곳에 적어 두십시오. 가장 흔한 평가 시간 낭비는 이미 거절한 도구를 두 번째로 평가하는 일입니다.