AI 툴 선택 기준: 문제 정의부터 파일럿 검증까지

AI 도구는 이름과 기능이 빠르게 바뀐다. "지금 제일 좋은 도구"를 찾는 방식이 오래 가지 못하는 이유다. 바뀌지 않는 것은 우리 팀이 풀려는 문제와 그 문제를 감당할 수 있는 조건이다. 판단 기준을 여기에 두면 도구가 교체돼도 의사결정 과정은 그대로 재사용된다.

고르기 전에 문제를 한 문장으로 고정한다

도구 비교부터 시작하면 기능 목록에 끌려다니게 된다. 순서를 뒤집어, 무엇을 누구를 위해 어느 정도 품질로 처리할지를 먼저 적는다.

작업 유형: 코드 작성·리뷰인가, 문서 요약인가, 비정형 데이터 추출인가, 고객 응대 초안인가. 유형이 다르면 잘하는 도구도 다르다.
합격선: 사람이 손대지 않아도 되는 수준인가, 초안만 나오면 충분한가. 이 선이 없으면 어떤 도구든 "괜찮아 보인다".
실패 비용: 틀린 결과가 나갔을 때 누가 무엇을 감당하는가. 내부 메모와 외부 발송 문서는 요구 수준이 다르다.
사용자 범위: 소수 숙련자가 쓰는가, 전사 배포인가. 후자라면 학습 곡선과 가드레일이 기능보다 중요해진다.

비교는 다섯 축으로 쪼갠다

후보가 셋 이상이면 인상 비교로는 결론이 안 난다. 축을 나눠 놓으면 어떤 항목에서 갈렸는지가 남고, 나중에 재검토할 때도 같은 표를 다시 쓸 수 있다.

축	확인할 질문	놓치기 쉬운 지점
품질	우리 데이터에서 합격선을 넘는가	공개 벤치마크 순위가 우리 업무에서의 성능을 보장하지 않는다
통합	기존 저장소·인증·업무 도구에 붙는가	연동이 안 되면 복사·붙여넣기 노동이 늘어 효과가 상쇄된다
운영·보안	데이터 처리 범위와 보관 정책이 문서로 명시돼 있는가	홍보 문구가 아니라 약관과 정책 페이지에서 확인해야 한다
비용	사용량이 늘 때 요금이 어떤 방식으로 증가하는가	좌석 과금과 사용량 과금은 확산 국면에서 결과가 크게 갈린다
지속성	공급자를 바꿔야 할 때 우리에게 무엇이 남는가	프롬프트·평가셋·로그를 우리 쪽에 남겨야 이전이 가능하다

데모 말고 파일럿으로 확인한다

벤더 데모는 잘 되는 사례로 구성된다. 판단은 우리 데이터로 해야 한다. 실제 업무 샘플을 모아 고정된 평가셋을 만들고, 후보 도구를 같은 입력으로 돌린 뒤 같은 기준으로 채점한다.

# eval/rubric.yaml
task: 문의_티켓_요약
samples: internal/tickets_sample.jsonl   # 실제 업무에서 추출해 고정
criteria:
  - id: accuracy
    weight: 0.4
    question: 원문에 없는 사실을 만들어내지 않았는가
  - id: completeness
    weight: 0.3
    question: 담당자가 조치하는 데 필요한 항목이 모두 있는가
  - id: format
    weight: 0.2
    question: 약속한 JSON 스키마를 지켰는가
  - id: latency
    weight: 0.1
    question: 팀이 합의한 응답 시간 상한을 넘지 않는가
candidates: [tool_a, tool_b, tool_c]

채점은 두 사람 이상이 나눠 맡고, 서로 다르게 매긴 항목은 따로 모아 본다. 기준이 모호했던 것인지 도구가 실제로 흔들린 것인지가 거기서 드러난다. API 형태로 붙일 계획이라면 요청 파라미터와 제약은 Anthropic 공식 문서나 OpenAI 플랫폼 문서 같은 1차 자료에서 확인하는 편이 안전하다. 요금과 한도는 특히 자주 바뀌므로, 요약 글보다 공급자 문서를 기준으로 삼아야 한다.

비용과 락인은 도입 후에 드러난다

과금 단위를 먼저 파악한다. 사용자 수, 요청 수, 처리량 중 무엇에 비례해 늘어나는지에 따라 확산 시점의 청구서가 달라진다.
사용량이 지금의 몇 배가 됐을 때를 가정해 계산해 본다. 파일럿 단계의 비용은 대개 가장 싼 구간이다.
공급자 호출부는 얇은 어댑터 뒤에 둔다. 교체 비용을 낮추는 가장 값싼 보험이다.
프롬프트, 평가셋, 실패 사례 로그는 우리 저장소에 남긴다. 도구를 바꿔도 이것들은 자산으로 남는다.

보안이나 규제 요건이 걸린 조직이라면 NIST의 AI 리스크 관리 프레임워크 같은 공개 자료를 점검 목록의 뼈대로 삼을 수 있다. 다만 프레임워크는 무엇을 점검할지 알려줄 뿐이고, 우리 데이터가 실제로 어디까지 전달되는지는 계약 조건과 설정에서 직접 확인해야 한다.

한계를 인정하고 결정을 기록한다

이 방식에도 약점이 있다. 평가셋은 만든 시점의 업무를 반영하므로 시간이 지나면 낡는다. 사람이 채점하는 이상 편향도 들어간다. 파일럿 기간에는 참여자가 평소보다 신경 써서 쓰기 때문에 성과가 부풀려 보이기도 한다. 그래서 정확한 점수를 뽑는 것보다 후보 간 차이가 분명한지를 보는 편이 낫다. 차이가 작다면 품질이 아니라 통합 난이도, 비용 구조, 운영 부담으로 결정하면 된다.

마지막으로 결정을 짧게 문서로 남긴다. 무엇을 골랐는지, 어떤 대안을 왜 탈락시켰는지, 어떤 조건이 바뀌면 재검토할지. 세 줄이면 충분하다. 새 도구가 나왔을 때 "그때 왜 이걸 골랐지"를 처음부터 다시 논쟁하지 않아도 되고, 재검토 조건이 적혀 있으면 유행이 아니라 근거를 이유로 갈아탈 수 있다.